Re: [cdt-dev] CDT Roadmap Proposal

[David Daoust <ddaoust@xxxxxxxxxx>]

As part of this proposal,  the
2.0.1 schedule involves IBM doing some validation on the build.  
 Can everybody with defects that are open with a target milestone
of 2.0.1 please go through them and determine if they will be fixed in
the next week or so.  If they will not be fixed, can we move the target
milestone to 2.1?

This will help us build test plans and
to ensure that we focus our validation on areas that have changed.  
( I am assuming that not all of these will actually get fixed ).

Here is a query that will return the
open list of 2.0.1 defects:

https://bugs.eclipse.org/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&product=CDT&target_milestone=2.0.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&namedcmd=2.0+unverified+reported+by+Kleos+team&newqueryname=&field0-0-0=noop&type0-0-0=noop&value0-0-0=


        -
Dave

Douglas Schaefer/Ottawa/IBM@IBMCA
Sent by: cdt-dev-admin@xxxxxxxxxxx

08/11/2004 02:51 PM

Please respond to
cdt-dev

To	cdt-dev@xxxxxxxxxxx
cc
Subject	[cdt-dev] CDT Roadmap Proposal

Hey gang,

There is a lot of planning work going on which is great to see! As well,
we have more companies than ever interested in including the CDT in their
product plans. It is critical for all these activities that we understand
when we are going to put out CDT releases and what is going to be in each
of these releases.

To help this along, I would like to propose a roadmap so that we can all
be on the same page. Please feel free to provide your feedback and propose
changes that would better meet your needs. Here we go:

Currently, on the table we have our (IBM's) proposal to release the 2.0.1
snapshot of the 2.0 maintenance stream by the end of August. We would like
to propose that the final build for this snapshot be on Thurs morning Aug
26. We have committed resources to do regression testing on this release
and will ask for a respin as necessary. This release, as is true for all
maintenance releases, is only for bug fixing. The biggest change we have
made is to bring in some major improvements to parser performance.

Also on the table is QNX's proposal to release 2.1 off of the main branch
by the end of October (the illustrious Halloween release!). You guys can
correct me if I miss anything but I believe this release will contain 
improvements and completion of the type hierarchy and class browser 
features introduced in 2.0 and some major debugger enhancements. As well
we may try to squeeze even more performance enhancements to the parser
if 
we have time after taking a breath from 2.0.1. There is also expressed
desire to bring some of the managed build enhancements to this release
if 
possible.

With those out of the way, I'd like to propose a somewhat regular schedule
that we can count on for our collective future product planning. Despite
objections, the feedback I've received from various sources is that it
is 
critical that we line up with major Eclipse platform releases. These 
appear to be happening yearly. Eclipse 3.1 is scheduled for 2Q05 so I'd
like to propose that CDT 3.0 be scheduled to release on the same day as
Eclipse 3.1. This will require a good understanding of the changes Eclipse
is planning and a good working relationship with them to ensure we don't
repeat the Eclipse 3.0/CDT 2.0 experience. This release would have the
work by Intel and others on managed build as well as our planned scalable
AST (DOM) work. I'm sure we'll see other goodies like the remote systems
model.

Beyond that if Eclipse stays on a yearly schedule, I can see where we 
still need to be more often than that. As such, I'd like to propose that
we keep on a 6 month release cycle. As the CDT matures, we should be able
to move to yearly releases as well.

As for maintenance releases. I propose creating branches at RC0 time for
each release. From that point on only bug fixing should go into the branch
and committers should make every effort to ensure that people can take
a 
snapshot at any time after the release and use it for commercial purposes.
We would release official CDT maintenance releases only if someone steps
up to do regression testing on the release (as happened with 1.2.1 and
will happen with 2.0.1).

Thoughts?

Doug Schaefer, IBM's Eclipse CDT Architect
Ottawa (Palladium), Ontario, Canada
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev