Here's the log from todays IRC chat. The main topics were what to do with
the sandbox code and the contents an M2 release. Not so many decisions
reached.
Session Start: Mon Jun 19 16:09:49 2006
Session Ident: #tuscany
* Now talking in #tuscany
* jsdelfino has joined #tuscany
* Venkat has joined #tuscany
* rfeng has joined #tuscany
* kgoodson has joined #Tuscany
* haleh has joined #tuscany
* ChanServ has quit IRC (Shutting Down)
* ChanServ has joined #tuscany
* irc.freenode.net sets mode: +o ChanServ
* jli1 has joined #tuscany
* jli1 has quit IRC (Client Quit)
* jli1 has joined #tuscany
* jboynes has joined #tuscany
<ant_> hi guys, its 4:30!
<kgoodson> ho
<ant_> shall we start or wait a few minutes for others?
<jsdelfino> hi
* monxton has joined #tuscany
<jboynes> while we wait, who's going to be in Dublin?
<dkulp> Good morning.
<rfeng> hi
<ant_> i will
<Venkat> hello
<jboynes> I'll be there tue night through fri
* gwinn has joined #tuscany
<dkulp> Not me (wife is due in 10 days), but IONA will have a bunch of folks
there.
<jboynes> congrats
* elegoff has joined #tuscany
* jmarino has joined #tuscany
<dkulp> Thanks
* slaws has joined #tuscany
* oisin has joined #tuscany
<ant_> for the late joiners - anyone else besides me an jboynes going to be
in dublin for apachecon?
<jmarino> yes me
<oisin> me too
<jsdelfino> what's the agenda for today's chat? from my side, I'd like to
talk about the plan for M2, are we going to have an M2 sometime? what
function (admin, deploy, hosts, spec support) are we gonna have in M2? are
we going to have a plan on Wiki? or the dev list? who's gonna volunteer as
release manager? etc
<dkulp> I'd also like to know the status of moving from sandbox to a "full"
branch or trunk.
<ant_> so those two sound like good topics for today - M2 and the sandbox
code
<ant_> anything else?
<Venkat> from me... when all other critical discussions r over... the
sdo2xsd generator
<ant_> ok. do we need to do the sandbox b4 the m2 discussion?
<jboynes> we suggested last week moving it to a branch but jsdelfino wanted
to wait
<haleh> IMHO sandbox is an input to m2. We can have m2 content discussion
regardless.
<jboynes> has anything changed?
<jmarino> regarding heleh's statement I'd be interested in hearing other
proposals
<jsdelfino> I think it would be a good idea to discuss what we want to do
for M2, have the main directions defined, then moving code around,
integrating code etc. should come naturally as part of the plan
<jsdelfino> but moving code from one place to another without having a plan
for M2 does not make sense to me
<ant_> how about M2 supports everything we had working in M1 plus support
for all the spec changes
<jmarino> I don't think we need to do that
* isilval has joined #tuscany
<haleh> Also Venkat mentioned something.. sdo2xsd generator
<dkulp> Don't need to do the spec changes or everything we had working?
<rfeng> so why don't we cover the topics in this order: M2, sandbox, AOB?
<jmarino> exactly everything we had working. I'd like to discuss specifics
not really broad things
<jboynes> we need to do the spec changes
<jmarino> yes agree with that
<jboynes> we need to have more function than M1 but I don't think it's a
no-regression thing
<jboynes> as stuff in the spec changed incompatibly
<jmarino> yes better said than mine
<jboynes> e.g. we will need a new version of bigbank and other samples
<haleh> what do you mean - no-regression thing?
<oisin> what about the other direction: is there feedback to the specs to be
done as a result of implementation experience?
<ant_> ok, spec changes + the samples (bigbank and varrious helloworlds) +
tomcat integration
<jsdelfino> rfeng, I agree, we should discuss M2, and identify which spec
changes we want in M2, and when we're all on the same page on that plus all
the other things we want in M2, then we can discuss the best way to get
there
<jmarino> I don't think we need backward compat
<jboynes> oisin, I think we have new ideas that can be fed into the spec as
well
<jboynes> e.g the constructor stuff should be prototyped
<jboynes> and we need to provide input on deployment
<jli1> where or when can we take a look at the new spec?
<jboynes> they are working on a public draft soon
<jboynes> that is everything up to around the J1 timeframe
<jmarino> well, I've been re-writing the Java one. Once it's done I can see
about the mechanics for sharing it. In the meantime, I can post things to
wiki and email
<jsdelfino> can we come up with a precise list of spec changes, actually a
map of the function from the spec that we want to support in M2?
<jsdelfino> put that on the Wiki?
<jboynes> that would be a great thing to have
<jmarino> sure if someone volunteers to do that
<jsdelfino> any volunteers?
<haleh> wouldn't the people who work on spec know about the spec changes?
<rfeng> we need to have someone with good understandings/involvements on the
spec side about the changes, directions, etc
<jboynes> it would also be a good way for someone else to get up to speed
<ant_> is there likely to be a public spec draft in the near future? it
would be easier if we could just refer to that and say section x.y is in/out
of M2
<jsdelfino> yes exactly
<jmarino> yes ant there will be
<jsdelfino> when?
<jmarino> July I believe
<jmarino> depends on how many distractions etc
<jmarino> we're now about 9 companie
<jmarino> s
<jsdelfino> jim you were just talking about rewriting and sharing a doc,
what is it?
<jmarino> have the spec made public
<jmarino> I can give overviews of the changes. What I don't have time to do
is a mapping like you described. Would be good for someone else to do that
<jsdelfino> so is that the doc for july? or something else?
<jmarino> it's for July
<jsdelfino> I didn't suggest a mapping
<haleh> Jim when in July? Begining of July?
<jsdelfino> I suggested a map (outline if you prefer) of the function in the
spec
<jsdelfino> and we can all decide what we want in/out
<jmarino> I would imagine it needs to be finished toward the beginning for
legal review which is usually 2 weeks or so
<jsdelfino> I think an outline listing all the functions would be sufficient
<jmarino> that's a lot of work. I'd prefer we get a copy of the spec
<jli1> unless we can have detailed spec changes posted somewhere(wiki?),
otherwise guys who r not involoved in spec group have nothing to do before
Mid July
<jmarino> I think a spec by July fits the timeframes anyway, correct?
<jsdelfino> isn't the outline from the spec doc already set? if the spec is
going to be ready by july, I'd imagine we already know the outline...
<jmarino> I'm not sure what is required. Do you want a delta of changes from
.9 to this new version?
<rfeng> something like the change history from 0.9 --> 0.91 (?)?
<jmarino> that's a lot of work. I think it is easier to just provide the new
document
<jboynes> jli1, there's a lot still to do, we're not constrained by whats in
the spec
<jmarino> yes, I'd actually like to see us innovate around constructor
injection and deployment
<jsdelfino> wrt M2, I think we need to have a list of functions we need to
support, anything that can help us get there will help, a list of changes,
an outline of the new spec
<jsdelfino> and on top of that we can innovate...
<jsdelfino> but we need a base, something like we had for M1, a basic
plan...
<jsdelfino> that's just my 2c
<haleh> So, can we say what we had for M1 + changes required for recursive
model/composites as a base for M2?
<haleh> plus something in deployment
<jmarino> I think there is something more fundamental to all of those
<haleh> more info please
<jmarino> I'm coming at things from a different perspective, less "feature"
driven
<jmarino> I'd like to see us achieve an architecture that is solid,
extensible and approachable
<jsdelfino> ok the other question I guess is: does anyone volunteer to be
release manager for M2, that guy should help drive the plan I think
<jboynes> I'd suggest its a little early for that
<ant_> think i agree with jboynes (unless someone is leaping forward...)
<jboynes> I'm afraid I'm going to need to drop off soon
<haleh> can someone summarise where we are with M2 discussion :)
<rfeng> what's the main tune for M2? build the architecture, implement spec
changes, or add/mature features?
<jmarino> I think it is all of the above :)
* gwinn has quit IRC (Read error: 104 (Connection reset by peer))
* gwinn has joined #tuscany
<ant_> pages 4-8 of the sandbox code presentation has some detail about spec
changes, could we say M2 would do those pages?
<jmarino> those are some of the key ones yes
<ant_> so those pages have:
<ant_> Modules become Composites
<ant_> Composites are a compound Component Type
<ant_> Entry Point eliminated, Service provides same function
<ant_> External Service eliminated, Reference provides same function
<ant_> Recursive Composition
<ant_> Complex Property Types
<ant_> those are the main ones
<jmarino> scopes will change as well
<ant_> so how about M2 is M1 changed to do all those + whatever other
inovation people want to do
<jmarino> I think there is a more fundamental issue around the architecture
<jmarino> also quality
<ant_> So if we have a less feature driven approach what do we need to do
and how do we know when we've done M2?
<jmarino> by setting appropriate metrics
<ant_> could you suggest some examples?
<jmarino> code coverage
<jli1> and in terms of extention, the architecture should be straightfoward
and easy to allow us writing any new binding, services, references etc. I
have took a look at sandbox, I believe this code base is much neater and
simplier than M1 in terms of how to write extension
<jmarino> yes some of the metrics will be heuristic as well
<jsdelfino> what about supporting specific hosts? any deployment/packaging
story for subsystems? any admin capabilities? and also extensibility apis
for databindings? hosts? transports?
<jmarino> subsystems go away. I'd like to see us get a deployment story that
we can propose the spec group
<jsdelfino> I think we need a clear picture on what we want in M2 on these
subjects, otherwise we just code away without any clear direction
<jmarino> Admin is also something that has been brought up too
<jmarino> yes agreed, I just believe some of the direction may not come from
features but other areas
<jsdelfino> right, so now we need to be a little more precise in terms of
what we're going to support in terms of admin, bringing up is good, but not
sufficient :)
<rfeng> I have started to look into databinding extensibility
<jmarino> Yes but I'd like to see us evolve to that. I think there are
several iterations of goals that go into increasing detail
<jsdelfino> some of the direction may come from features, some from other
areas, I'm just saying we need to have the direction written in a plan on
wiki, a set of emails in the dev list... somewhere, so the team can share
common accepted goals for M2
<jmarino> maybe I'm a little looser. I'd like to get a plan but I don't
think we need to do it as detailed upfront ala waterfall style dev
* elegoff_ has joined #tuscany
<jmarino> i'd like to see us to smaller iterations
* elegoff has quit IRC (Read error: 110 (Connection timed out))
<jsdelfino> do u think the plan we had for M1 had the correct level of
detail? too much? not enough?
<jsdelfino> our M1 Wiki page...
<rfeng> for better communication, I would like to see a list of things we
have have in mind for M2
<jmarino> I think the M1 was too much like commercial software...that's
another topic. I'd like to see very broad goals and some smaller iterations
before we get to an M2 plan
<jmarino> kind of like small steps and then build up to M2 again
<jmarino> small steps measured in days/a week at a time
<jsdelfino> can u elaborate a little? what do u mean by small steps? are u
saying we don't need a plan for M2?
<ant_> ok small itterations sound ok. what kind of things do you think could
be in the next iteration or 2?
<rfeng> maybe start with major goals and break them down as we go?
<jmarino> no I think we need to get some small steps done first and then we
can iterate to M2 instead of plan all upfront
<jsdelfino> what do u mean by small steps? can u give some examples?
<jmarino> e.g. an *iterative* architecture design
<jmarino> a design for admin, etc.
<jmarino> by design,not docs but more code
<jmarino> basically very small goals like "better test coverage in area X"
<jmarino> or databinding extensibility
<jmarino> on Raymond's question I think we need "big" goals like "better
architecture" "move to new spec support", etc. but not necessarily feature
detail upfront
<ant_> (I have to leave sorry)
* ant_ is now known as ant_away
<rfeng> I think the high level list will help. Now the question is that how
does it allow us to drill down? by coding?
<jmarino> yea high-level things obviously will help. I'd like to see us make
some short-term progress first before we start listing M2 feature sets
though. This will also make it easier to get others involved
* monxton has quit IRC ("Bye")
<jmarino> I'd actually also like to see M2 less monolithic but we can bring
that up later
* Venkat has quit IRC
<rfeng> do we still have time to talk about sandbox?
<jmarino> I've got about 10 mins - it's a little late here
<jli1> shall we have a quick discussion about sandbox? before it moves to
branch, when can we have a working example of helloworld?
<jmarino> sure
<jli1> that helps, i think
* oisin has quit IRC
<jli1> for example, make java\samples\sca\helloworld working in the new
sandbox?
<jmarino> if people want t move it now, I'm happy to do that. I'm also happy
to keep it where it is. Also, if people have other ideas for a way forward,
I think we should do a proposal like the other week. Basically, I'm saying
I'm open to suggestions :)
<jmarino> do you think we need a sample working or just major "subsystems"
<jmarino> also I guess that presupposes the sandbox code is what people
want, so if people disagree, they should mention that
* isilval has quit IRC ("Trillian (http://www.ceruleanstudios.com";)
<jli1> for me, I feel i working simple sample helps. as runnnig this sample
at least helps me to make sure i didnt break anything seriously with my
changes. there arnt enough unit tests yet.
<jmarino> yea one of the big items I'd like to see is getting to a point
when unit tests tell us that because the samples only exercise small paths.
But yes, if you think hello world helps things we could wait for that
<jli1> also i can debug the process flow of the simple sample to better
understand the new architecture. its quicker than reading code.
<jmarino> I think we've relied way too much on samples to do testing and it
hit us in M1
<jmarino> agree on the sample helping although would unit tests that
exercised specific areas help you better understand flow?
<jli1> thats true.ideally we would like to see a test coverage of 75%.
<jmarino> yea on SPI i'd like to see 90-95% if possible
<jmarino> on other areas we can relax a bit
<jmarino> what I'm getting at is there may be more requirements than just
the sample, like specific unit tests, etc.
<jli1> a good unit test does helps a lot. though I think a working example
help us to understand the big picture. how bootstroop works, how component
is loaded, then how componenet get wired together. basicly how things work
together in the new architecture.
<jsdelfino> from my side, I would like to see simple samples working (and
not for testing purposes) to allow me to understand the overall flow,
without simple scenarios working it's really difficult to understand the
behavior of the runtime in an end to end interaction
<jli1> Agree with jsdelfino
<dkulp> I agree too. A simple sample to load into eclipse and step through
is invaluable.
<jmarino> k would a simple sample be enough?
* slaws has quit IRC (Read error: 104 (Connection reset by peer))
<jli1> well, at least it provides a good starting point. for example, based
on the simple hellowork, then i can try to add a helloworld example using
Celtix binding
<jsdelfino> basic samples that demonstrate enough of the end to end
interaction
<jsdelfino> just a helloworld that does nothing is not really useful - cause
it does nothing :)
<jsdelfino> interaction with a binding and a sample with wiring are really
key IMHO
<jsdelfino> helloworld does not even show wiring...
<jmarino> one option is we could branch the M1 code and move the sandbox up,
assuming people agree that the sandbox is the right way to go. That would
not inhibit anything. This of course assumes people buy into the sandbox
code. If people believe that the sandbox is not the way to go, or there is
not enough information, then we can wait. If there is not enough
information, people should be posting questions to the list as well.
* gwinn has left #tuscany
<jsdelfino> I'm gonna repeat myself I think, but for me to understand the
end to end interactions with the sandbox code, I need simple working end to
end samples, without this it's really tough to understand the flow
<jsdelfino> at the moment I am not able to run even helloworld and run it
through the debugger...
<jsdelfino> just speaking for myself, I'm not sure if others have been able
to go further
<jmarino> so do you have specific areas you have questions about? We could
start by posting emails to the list.
<jmarino> the wiring flows can be debugged so while not ideal like a sample,
it is pretty easy to step through them
<jmarino> there are a bunch of test cases that do this
<jsdelfino> maybe it's just me but I'm not able to understand the overall
flow by just running low level unit test cases
<rfeng> I agree, stepping into the debugger to see how all the code work
together to deliver an end-to-end scenario is a nice way to understand the
architectural contracts
<jmarino> there are some pretty high level ones like component A invokes B
too. It would be good if people could start posting questions and engaging
sooner rather than later
<jli1> i kind of agree with jsdelfino too.
<jsdelfino> I must sound like a broken record, being able to run simple
samples in a debugger and step through the code is invaluable
<jsdelfino> without that, I cannot understand the flow
<jmarino> I'm also happy to just wait until the samples are complete
<jmarino> I'm curious why you can't understand the flow?
<jmarino> is there something that is not clear in the architecture?
<jmarino> I agree a sample helps end-to-end but I think people can engage
sooner
<jsdelfino> because I don't have the overall flow, I can understand some of
the small pieces, but not the overall flow
<jsdelfino> so like you said, a sample helps understand the end-to-end
picture
<jmarino> so you can understand how the invocation flow works, how
composites are handled, etc.? It's more with deployment and XML loading?
<jli1> I believe some high level unit tests might help, provide similar
things to sample, but without pointing out which unit test is the test shows
overflow, its hard for me to walk through all unit tests and find out the
one i want to debug by myself
<rfeng> by reading the code and unit tests, it's fairly reasonable to
understand the sub-flows, but it's a challenge to connect all the sub-flows
together to get the whole picture without a end-to-end sample working
<jsdelfino> exactly
<jsdelfino> I think a number of people are saying the same thing
<jmarino> Yes I get the sample end-to-end thing. My point was several fold.
First, if people don't understand certain things, it would be helpful to
post on the list.
<jmarino> the other thing is I think people can engage and start helping out
if they believe the sandbox is the way to go. For example, Jervis has
voluntered to help with the Celtix port
<jmarino> the final point was I'd like to hear alternative proposals
<jsdelfino> I think that the trouble is that to ask good questions we need
to have the overall high-level picture clear, and for me at least, being
able to step through a sample is the starting point to get a clear picture
<jmarino> we're the slides not enough for people to start asking questions?
<jsdelfino> when I have that, I'm planning to start working on a sample
binding and component type, using the SPIs and comparing with the M1 ones,
and I'll raise questions/comments/issues on the dev list then
<jsdelfino> or maybe in a wiki doc
<jmarino> you can't look at the Groovy or Spring examples now?
<jmarino> granted they are not complete but it is a way to engage
<jsdelfino> not sure about the groovy or jruby one, I've made a copy of the
jruby one for that experiment, I want to understand how to handle
references, lifecycle etc. which I'm a little lost with at the moment
<jsdelfino> did I miss something or did u complete the groovy one to do
anything with references? last time I looked it just did nothing at all...
<jmarino> it should do references
<jmarino> there are unit tests in there that describe the features
<jmarino> if people want to wait before we move it, I'm happy to maintain
the status quo
<jsdelfino> ok I'll try to replicate this with the ruby one and see if I can
understand what I have to do
<jmarino> if you need help let me know. Also, I never see you online anymore
<jsdelfino> I'll let you know
<jmarino> try to get on google talk some time :). It's late so I'm going to
leave since I'm still in the office
<jmarino> ttyl
<jsdelfino> ttyl
<rfeng> bye
* jsdelfino has left #tuscany
* jmarino has quit IRC (Remote closed the connection)
* jli1 has quit IRC ("Download Gaim: http://gaim.sourceforge.net/";)
* elegoff_ has quit IRC ("Leaving")
<haleh> exit
<haleh> oops
* jsdelfino has joined #tuscany
* haleh has left #tuscany
* oisin has joined #tuscany
* pombreda has joined #tuscany
* jsdelfino has left #tuscany
* ChanServ has quit IRC (ACK! SIGSEGV!)
* ChanServ has joined #tuscany
* irc.freenode.net sets mode: +o ChanServ
* pombred1 has joined #tuscany
* pombreda has quit IRC (Read error: 110 (Connection timed out))
* pombred1 has quit IRC (Read error: 104 (Connection reset by peer))
* pombreda has joined #tuscany
* pombreda has quit IRC (Read error: 104 (Connection reset by peer))
* pombreda has joined #tuscany
* dkulp has quit IRC (Remote closed the connection)
