On Wed, Feb 11, 2009 at 5:05 PM, Raymond Feng <enjoyj...@gmail.com> wrote:
> Please see my comments inline. > > Thanks, > Raymond > > *From:* ant elder <ant.el...@gmail.com> > *Sent:* Wednesday, February 11, 2009 7:06 AM > *To:* dev@tuscany.apache.org > *Subject:* Re: [2.x] Java SCA 2.0 next milestones release > > > > On Mon, Feb 9, 2009 at 10:49 PM, Luciano Resende <luckbr1...@gmail.com>wrote: > >> On Mon, Feb 9, 2009 at 2:35 PM, Simon Laws <simonsl...@googlemail.com> >> wrote: >> > >> > What do you mean by short? Monthly? Six weekly? I think it should be >> down at >> > this sort of order. >> > >> >> I was thinking on something around 4 weeks or less. >> >> >> > Not sure we explicitly have to alternate but I like the idea of themes. >> > Maybe this results in the same thing but I wouldn't want to pre-judge >> it. >> > >> >> I just want to avoid loosing focus, and having multiple people going >> in multiple directions. Alternating focus between OASIS spec items and >> Tuscany infrastructure/extensions would allow us to get the right >> balance, and would allow active collaboration towards a common goal >> and I hope better results at the end. >> >> > +1 on not loosing focus, but i think we may need to have multiple people > going in multiple directions if we're to get this done in time. Remember the > date we're aiming for 2.0 is June, just three and a bit months away so not > much time. > > Doing a release takes time away from other work so too short a release > cycle will impact productivity, a release every few weeks is too often IMHO, > it might work with the point releases we've done to fix bugs in 1.x.x type > releases but for this type of milestone development it would mean an > unnecessarily high percentage of our available time gets sucked up in > release work. 6 weeks seems more realistic to me and that could give an M2 > at end of March, M3 end of April, perhaps beta1 end of May and then 2.0 > final tracks the OASIS date. > > A 6-week cycle sounds reasonable. > > So fitting the work and themes into into those three releases could be: > > M2 - port as much as possible from 1.x to 2.x > > IMO, it is probably too early to do this in M2. Porting non-OASIS > extensions won't help the OASIS compliance and I'm afraid that we will have > to do it again as the core and SPIs will change quite a bit. We need to > adjust the XSDs, models and processors for the assembly, policy and other > OASIS bindings/implementations so that the Tuscany runtime can consume the > OASIS composites. We should try to get some of the key infrastructures such > as Endpoint and Policy in place first. (The policy work can be spanning over > two milestones) > > We can start with the extensions that are defined by OASIS specs and defer > other extensions to a later stage. > > When will the Domain/Node story to be completed? > > M3 - work on OASIS compliance > > We should try to pass all of the OASIS compliance tests. > > Beta1 - stabilize all functional changes > > I think it's the time that we port non-OASIS extensions to 2.x and > stabilize the code. > > and then only bug fixes in a 2.0 branch till the 2.0 final release > Let's try to dump out the all the items toward an OASIS-compliant SCA > runtime first and then plug them into the milestones. > > > I think we're on similar pages. The contents of M2 is still a bit hazy but i think thats fine, these are themes not rules so we can work it out as we go along. I don't think we should restrict things to only spec defined items though, there are also other things we do need to do such as the Node story and webapp integration we need to get done and they're not defined in any specs, bringing up non OASIS extensions will help verify SPIs, provide opportunities for people to help and get involved in the 2.x code, and they provide a easier entry point to learning 2.x than diving right in to something like implementation.bpel. We've also the results from the user survey that shows us what people are using so that can help prioritize work. Agree with that last point, we've the 2.0 draft release notes and 2.x JIRA lists we've started on the other threads about this to help guide us, if we keep adding JIRAs as we thing of things then it will help see what needs to be done ...ant
