[cdt-dev] CDT 2.0 Planning

[Kleanthis Hapitas <khapitas@xxxxxxxxxx>]

All,

We need to start the planning for the
next major release, which is CDT 2.0. A rough target date for this release
is Q2 2004, since one of the major goals of CDT 2.0 is to align it with
the latest Eclipse platform release, which will be the 3.0 release scheduled
for the spring of 2004. In order to start generating some planning momentum,
we have borrowed the format the Eclipse project uses for their release
planning and created a DRAFT CDT 2.0 plan. You can see it by navigating
to:

    http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-home/plans/CDT_R2.0_plan.html?cvsroot=Tools_Project

This is essentially a copy of the generic
information found in the Eclipse 3.0 DRAFT plan, with some proposed milestone
dates for the 2.0 release and a section  where we have started capturing
proposed changes/enhancements that should make up the CDT 2.0 release.
 

From a planning perspective, content
and scheduling are the two major themes we need to start tackling now.
Any thoughts regarding the use of this
format to capture and publish our plan are most welcome.


CONTENT

To facilitate communication around the
proposals for the release, the Eclipse team follows the convention of creating
bugzilla entries for all items (features, changes, enhancements, etc.)
that are under consideration for the release, with the following attributes:

       - keyword
= plan
       - summary
begins with: "[plan item]"
       - target
release = whatever the next release is.

Somewhere in the body of the DRAFT plan,
there is a link to a bugzilla query that would produce this list of planning
items. Since we don't have any such items in bugzilla for the CDT yet,
the query will return NOTHING. To get an idea of how the Eclipse team use
this, there is also a link to the planning list for the Eclipse 3.0 project.

           
               
               
               
              
PROPOSAL #1:  We
should follow the same convention and create bugzilla entries for all items
under consideration for the next CDT release. As these entries get created,
I can ensure that the contents section of the CDT 2.0 plan get updated
to reflect the current state (what items are proposed, which ones are committed,
etc). When its time to gather and hammer out the details of the next release,
we'll have a common basis for discussion, and items can easily be marked
as committed, deferred, etc.


SCHEDULING

The Eclipse platform follows a milestone
(iterative) based strategy, with milestones roughly every six weeks. The
draft CDT 2.0 plan proposal is therefore based on the same strategy, with
the goal of producing "stable builds reflecting progress". We
should be able to communicate to the verification and end-user community
what is new in each iteration (complete or partial features, enhancements,
etc). Getting stuff into the hands of our testers and other users early
is the single greatest risk mitigation action we can take! 

At this early stage, the draft CDT 2.0
plan has four such milestones:

M1 - Stable build that
runs on Eclipse 3.0 M5 - Nov 21, 2003

M2 - Stable build that
runs on Eclipse 3.0 M6 - Jan 16, 2004

M3/RC0 - Release Candidate 0
- Feb 27, 2004 
This is the freeze date, by which all
planned features have been implemented and are testable (working). After
this point, only defects related to the new features or other high priority/severity
defects are pushed to the stream. Between this point and GA, we go through
a number of test/fix cycles until all show-stoppping issues have been addressed.
Typically these cycles are a couple of weeks, but that will depend on how
long it takes to go through the testing of each release candidate. We should
probably expect to have to get together every couple of weeks on a conference
call to evaluate the findings of the current cycle and to decide what will
be fixed.

GA - General Availability - End
of April 2003 ( approx 9 weeks after RCO, providing enough time for at
least three test/fix cycles).


PROPOSAL #2: Without worrying
too much about the specific dates mentioned so far, we adopt a scheduling
& end-game process that is similar to the one the Eclipse project follows.
To make that work, it means specifically  that we:

• Enforce the freeze (RC0) milestone by being strict about what patches get applied after that date. Specifically, only defects with a priority above a certain threshold (say P1 & P2) should be considered. This should definitely help catch surprises with enough time left before GA to properly address them, and also minimize risky churn leading up the release.

• Prepare test plans in advance that will be run on each release candidate (RC) build. These test plans would typically be made up of Junit test cases that have been written plus other manual tests required to exercise the new/changed code. If we have bugzilla entries for the new work development items to be undertaken, it will be very easy to see which test plans cover which work and to identify any gaps.

• Each team takes responsibility for executing their test plan during the test cycle that immediately follows an RC build and recording all new issues as bugzilla defects.

• Following each test pass, we collectively analyze and prioritize the outstanding defects we'll address, with priority going to stop-ship and regression problems. The criteria for which bugs will be addressed will be progressively narrowed.

I'd like to generate some discussion
around how we'll do things for the 2.0 release early in the game,  so
please let us know what you think of the proposals mentioned here. Do you
agree, disagree, would you like to suggest any changes or something different?
Based on many discussions I was involved in during the 1.2 development
cycle, I believe most participants agree that we need to take a more structured
approach for the 2.0 release. What that approach should be is certainly
open for discussion, I've just borrowed from Eclipse to get us started.
The most important thing is that we all work from a common understanding.

I look forward to reading your responses.
We are also working to set up a CDT 2.0 kick-off meeting in the near future,
which will provide an opportunity to further discuss these issues and hopefully
close on them.

Cheers,

Kleo Hapitas
Program Manager
IBM Software Group - Rational
Tel: (613) 591 2913