[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Progressing towards 2.0 GA
|
Hi Doug,
Thanks for the added thoughts -- don't want to burden folks too much, so how
about doing the work straight on the head and merging back to 2.0? Would
that make
it any easier?
Sebastien
> -----Original Message-----
> From: Douglas Schaefer [mailto:dschaefe@xxxxxxxxxx]
> Sent: Monday, June 28, 2004 2:38 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: RE: [cdt-dev] Progressing towards 2.0 GA
>
>
> 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
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
