DTP 0.9
Endgame Plan

Updated frequently to reflect current status

 

Status

Mon. April 24, 2006: There will be nightly builds from HEAD each night until we stabilize on a DTP Callisto release candidate. Thereafter, there will be additional builds only as necessary to incorporate new fixes into DTP Callisto.  Committers should obtain the nightly build every day to ensure adequate testing. It is critical that all changes released to HEAD be solid.

Detailed Timeline

April 2006 

 

24

Mon 08:00 EDT

  Transition to fix and polish mode

  

  details

  

 

24

Mon 08:00 EDT

  Start  7 day fix pass

  

  rules

  

 

 

 

 

 

 

  

May 2006 

3

Wed 9:00 EDT

 Release Candidate 2 build

 

 goals

 

 

3

Wed 12:00 EDT

  Start 3 day test pass against RC2

  

  details

  

 

 

 

 

 

 

 

 

8

Mon 08:00 EDT

  Start 7 day fix pass

  

  rules

  

 

 

 

 

 

 

 

 

17

Wed 9:00 EDT

  Release Candidate 3 build

  

  goals

  

 

17

  Wed 12:00 EDT

  Start 3 day test pass against RC3

 

details

 

 

 

 

 

 

  

  

 

22

Mon 08:00 EDT

  Start 5 day fix pass

  

  rules

  

 

 

 

 

 

 

 

 

29

Mon 9:00 EDT

  Release Candidate 4 build

 

  goals

  

 

 

 

 

 

rules

 

 

 

 

 

 

 

 

 

 

 

RC builds will be run as necessary

 

  

 

 

 

 

after May 29 to meet Callisto goals.  

 

  

  

 

 

 

 

 

 

 

June 2006 

 

 

 

 

 

 

 

19

Mon 9:00 EDT

 Release Candidate 5 build

 

goals

 

 

 

 

(Only if required by bugs.)

 

rules

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

30

Fri 23:59 EDT

  DTP Callisto release available

  

  details

  

Useful Links

DTP Project Calendar

What is the game plan?

The DTP 0.9 release endgame involves a sequence of test/fix passes leading to the official Callisto release. Throughout the process, we are most concerned with "stop ship" (P1) bugs that must be fixed before we can declare that we have a release. If we discover a "stop ship" bug late in the process, we may have to slip the schedule to allow it to be fixed and retested. This is why it is so important to ferret out "stop ship" bugs as early as possible, while there is still time left in the schedule to address them. Most of the bugs that will be uncovered will be less serious. During the fix passes, we prioritize the less serious bugs and try to fix as many of the important ones as possible without jeopardizing the schedule or the overall stability of the release. We're always on the look out for "regression" type bugs where we somehow manage to break something that had been working fine before. Regressions are an important warning sign that our optimism and enthusiasm is outpacing our understanding and abilities. Calling special attention to regressions helps us to collectively bring our head back in line with our feet, so to speak. With each cycle, we gradually raise the bar on the kinds and numbers of changes that we will consider making, until we reach a point where we would only fix "stop ship" bugs and regressions. (The lesser bugs that we don't end up fixing will be reconsidered for the next release.) Because of this progressive tightening, the windows of opportunity for fixing problems within the schedule are relatively narrow. As it is virtually impossible to work out all the details in advance, we will be updating this page regularly to reflect current status and current testing emphasis. General announcements during the endgame are posted to the dtp-dev@eclipse.org mailing list.

 

Release Candidate - Release candidate builds are like milestone builds. We test each release candidate to find serious bugs and to increase our confidence in what we have. We then fix the serious bugs in each release candidate to get the next release candidate, which ought to be even better. Each release candidate build is kicked off at the indicated time, with the goal being to have a release candidate available within 24 hours. It is critical that we have enough time to do test passes.

Test Pass - Once we have a release candidate build in hand, we enter an intensive test pass for a limited period of time. Each component team is responsible for staffing and carrying out their testing each cycle. Each component team is expected to have most of the team testing throughout each test pass (a small subset of the team may be focused on concurrently preparing candidate fixes for "stop ship" bugs or other high priority tasks). Everyone in the Eclipse community is encouraged to participate in test passes and report bugs to bugzilla. Ideally, the bug report should explicitly call attention to regressions and potential "stop ship" problems.

Fix Pass - After each test pass, we analyze and prioritize the set of outstanding bugs and enter an intensive fix pass for a limited period of time where we try to fix the most pressing problems and other approved items. The bugs that we intend to fix for the next release candidate are tagged accordingly. "Stop ship" bugs and regressions are always given first priority; less severe problems are addressed by decreasing priority and as many as possible are fixed in the time available. With each successive release candidate, we also tighten the rules for the kinds of changes will be allowed to the code base and increase the number of people that check the changes before they are released. The rules apply to any and all changes to the code. All committers for a component have the right to veto a change (with an explanation) even after it has been released into the code base. If such a veto occurs, the change automatically comes out until the vetoing committer's concerns are addressed. The committer who releases a given change, the person that checks the change, and the component leads that approved making the change in the first place, are jointly responsible for seeing it through. In other words, we expect a strong commitment to personally help fix any problems caused by changes made in fix passes. Finally, individual projects are allowed to make and enforce additional fix rules, as long as they do not conflict with the guidelines herein, and as long as a posting to dtp-dev@eclipse.org details them for comments, before stating to use them.

 

Details

Transition to fix and polish

Notes:

  • All components transition on April 24 to polishing and fixing bugs for remainder of release cycle.
  • PMC approval is required for feature work including API changes being done after April 24.

RC2

Goals:

  • Accurate prioritization of all outstanding defects.
  • As few P1 defects as possible.
  • As few P2 defects as possible.

Test pass using RC2

Notes:

Concerted 3 day testing effort on RC2 involving entire community including all component teams. In an effort to mix things up and hold off the onset of "tester fatigue", each component team will be designating one team member that will be assigned to test some other component.

RC3

Goals:

  • Accurate prioritization of all outstanding defects.
  • No outstanding P1 defects.
  • As few P2 defects as possible.

Test pass using RC3

Notes:

Concerted 3 day testing effort on RC3 involving entire community including all component teams, searching for regressions and on the lookout for undiscovered "stop ship" defects.

RC4

Goals:

  • Unit tests and documentation complete.
  • Accurate prioritization of all outstanding defects.
  • Stable code base; no outstanding P1 defects.

RC5

 Goal:

 Build occurs only if required to include stop-ship bugs.

Callisto Release

Goal:

Ship DTP 0.9 during the week on June 28.

Notes:

There is no formal test pass for RC4 and beyond other than to check for last minute regressions. We will perform sanity checking focused on documentation. DTP Callisto release should be complete and available for download as soon as we are satisfied with it.

 

Fix pass rules of engagement

April 24 -- May 3
contributions to RC2

Focus:

(1) P1 defects, (2) approved features, (3) P2 defects. Fixing other defects has lower priority.

Fix approval:

Component lead must approve all work on a component. No changes are to be released without prior approval and associated bug report. (Ongoing changes to component documentation and unit tests do not require special approval.)

API change approval:

PMC must approve all API changes. No changes are to be released without prior approval and associated bug report.

Notification requirements:

None.

Extra checking requirements:

None. (However extra checking is always a good idea.)

May 8 -- 17

contributions to RC3

Focus:

(1) P1 defects, (2) approved features, (3) P2 defects. Fixing other defects has lower priority.

Fix approval:

Component lead must approve all work on a component. No changes are to be released without prior approval and associated bug report. (Ongoing changes to component documentation and unit tests do not require special approval.)

API change approval:

PMC must approve all API changes. No changes are to be released without prior approval and associated bug report.

Notification requirements:

Announce bug numbers of intended non-doc and non-unit test changes to dtp-dev@eclipse.org mailing list.

Extra checking requirements:

None. (However extra checking is always a good idea.)

May 22 -- 29
contributions to RC4

Focus:

(1) P1 defects, (2) P2 defects. Fixing other defects has a lower priority.

Fix approval:

Component lead plus one other component lead must approve all work on a component. No changes are to be released without prior approval and associated bug report. (Ongoing changes to component documentation and unit tests do not require special approval.)

API change approval:

PMC must approve all API changes. No changes are to be released without prior approval and associated bug report.

Notification requirements:

Announce bug numbers of intended non-doc and non-unit test changes to dtp-dev@eclipse.org mailing list. PMC chair must post non-doc and non-unit test bugs to Callisto mailing list for visibility.

Extra checking requirements:

One additional committer must check all code changes prior to release. Person who reported bug should mark the bug as verified once they have retested.

May 29 – DTP Callisto release
contributions post RC4
(RC5 build only if necessary)

Focus:

(1) P1 defects, (2) P2 defects. Fixing other defects has a lower priority.

Fix approval:

Component lead plus two other component leads must approve all non-doc work on a component. In addition, any component lead can veto a change with cause. No changes are to be released without associated bug report, including risk assessment and prior approvals. (Ongoing changes to component documentation and unit tests do not require special approval.)

API change approval:

PMC must approve all API changes. No changes are to be released without prior approval and associated bug report.

Notification requirements:

Announce bug numbers of intended non-doc and non-unit test changes to dtp-dev@eclipse.org mailing list.

Extra checking requirements:

Two additional committers must check all code changes prior to release. Person who reported bug should mark the bug as verified once they have retested. PMC chair must post non-doc and non-unit test bugs to Callisto mailing list for visibility.