Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] CDT 2.0 Planning


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


Back to the top