RE: [cdt-dev] Progressing towards 2.0 GA

[Douglas Schaefer <dschaefe@xxxxxxxxxx>]

This is getting long, I'll put my comments on top.

After considering your point for a while and talking to the guys here, we 
have decided to do the parser work on a side stream as you suggest. This 
will certainly be safer for everyone but will cause us more headaches as 
we try to merge back to both head and the 2.0 stream.

Doug Schaefer, IBM's Eclipse CDT Architect
Ottawa (Palladium), Ontario, Canada



Sebastien Marineau <sebastien@xxxxxxx> 
Sent by: cdt-dev-admin@xxxxxxxxxxx
06/28/2004 02:20 PM
Please respond to
cdt-dev


To
"'cdt-dev@xxxxxxxxxxx'" <cdt-dev@xxxxxxxxxxx>
cc

Subject
RE: [cdt-dev] Progressing towards 2.0 GA






Hi Doug,
 
> 
> cdt-dev-admin@xxxxxxxxxxx wrote on 06/28/2004 09:33:27 AM:
> 
> > Hi Doug,
> > 
> > 
> > > On the subject of the 2.0 branch, I guess we should do it as 
> > > soon as the 
> > > RC build is done on Monday. As we have mentioned, we will 
> be doing 
> > > performance work on the parser and that is likely to blow 
> > > everything up 
> > > right away. The sooner we get started on this the more time 
> > > we will have 
> > > to recover. We will likely do this work on the 2.0 branch and 
> > > merge it 
> > > back to head once we're stable again. That'll let the 2.1 
> guys march 
> > > ahead.
> > 
> > On the subject of parser work, should we not take the 
> reverse approach,
> > e.g. do the work on the head and move it to the release 
> branch (2.0.x)
> > after?
> > This way the 2.0 branch remains stble and shippable?
> 
> The work we are planning on doing for the parser is to allow the 2.0 
> branch to be shippable. The current parser performance is not 
> acceptable 
> from our perspective (see 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=59468). We're 
> not planning 
> on massive architectural changes but it will be disruptive 
> for a couple of 
> weeks. Our plan is to return to stability by the end of 
> August (in time 
> for 2.0.1?).

Right, I understand that part. I know the parser mods will make it way
better :-)

However (from a branch/src management), this is a departure of what we've 
done in the past where the release branches remain stable post-release and
we 
back-port work from the head. We should make it really clear to folks 
that the 2.0 branch will be in flux for a while (and I don't know if 
we want to start modifying it right away but rather let the GA 
"prove itself" for a few days). 

> 
> > 
> > The second question is with the branch itself -- do you 
> want to do the 
> > branch, or shall I? Either way works for me...
> > 
> 
> I can do it. I have to tag the RC1 versions anyway.

Cool, thanks!

Seb

> 
> > > 
> > > An interesting discussion also revolves around the 3.0 work 
> > > and where that 
> > > would go. Having too many streams will kill us, but I would 
> > > love to see 
> > > the managed build work march ahead as soon as we can. I'm not 
> > > sure we can 
> > > get that all done and stable by the end of October, tough.
> > 
> > Right. Any way we could stage it such that 2.1 becomes a 
> mini-release
> > along the way to 3.0 with a subset of the features? This 
> also has the
> > benefit of
> > getting the new features "out there" and getting some 
> feedback on them
> > before
> > 3.0.
> 
> That's probably the way it has to go. We had talked about not 
> doing short 
> releases again but it looks inevitable.
> 
> Right now the CDT is being pulled to meet contributing teams product 
> delivery schedules. As more parties get involved, this is going to be 
> difficult to manage. My feel is that the CDT needs to have a 
> life of its 
> own with a regular and predictable schedule, likely tied 
> somewhat to the 
> Eclipse schedule. That would help contributing members plan their 
> participation and product schedules. Maybe this is an area that the 
> Eclipse Foundation planning committee will get involved in.
> 
> Thanks!
> Doug
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev