DTP 1.0 Endgame Plan Updated frequently to reflect current status

Status

Tues. November 21, 2006: There will be nightly builds from HEAD each night until we stabilize on a DTP 1.0 release candidate. Thereafter, there will be additional builds only as necessary to incorporate new fixes into DTP 1.0. 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

November 2006
		22	Wed 08:00 EDT	Transition to fix and polish mode	details
		22	Wed 08:00 EDT	Start 7 day fix pass	rules
December 2006		1	Fri 9:00 EDT	Release Candidate 1 build	goals
		1	Fri 12:00 EDT	Start 3 day test pass against RC1	details
		6	Wed 08:00 EDT	Start 7 day fix pass	rules
		15	Fri 9:00 EDT	Release Candidate 2 build	goals
		15	Fri 12:00 EDT	Start 3 day test pass against RC2	details
		20	Wed 9:00 EDT	Last possible DTP 1.0 build
		22	Fri 23:59 EDT	DTP 1.0 release available	details

Useful Links

DTP 1.0 Project Plan

What is the game plan?

The DTP 1.0 release endgame involves a sequence of test/fix passes leading to the official DTP 1.0 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. 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 November 22 to polishing and fixing bugs for remainder of release cycle. PMC approval is required for feature work including API changes being done after November 22.

RC1

Goals:

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

Test pass using RC1

Notes:

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

RC2

Goals:

Accurate prioritization of all outstanding defects. No outstanding P1 defects. 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, searching for regressions and on the lookout for undiscovered "stop ship" defects.

DTP 1.0 Release

Goal:	Be ready to ship DTP 1.0 during the week on December 18, pending only IP approval from Eclipse legal.
Notes:	There is no formal test pass for RC2 and beyond other than to check for last minute regressions. We will perform sanity checking focused on documentation. The DTP 1.0 release should be complete and available for download as soon as we are satisfied with it and have Eclipse legal approval.

Fix pass rules of engagement

November 22 -- November 30

contributions to RC1

Focus:	(1) P1 defects, (2) approved features, (3) P2 defects. Fixing other defects has lower priority.
Fix approval:	None, though testing to ensure that no regressions are injected is strongly suggested.
API change approval:	Describe any changes in comments to bug #164877, so the ISV documentation can be updated accordingly.
Notification requirements:	Announce bug numbers of non-doc and non-unit test enhancements added to the DTP 1.0RC1 target milestone to dtp-dev@eclipse.org mailing list.
Extra checking requirements:	None. (However extra checking is always a good idea.)

December 6 -- December 14
contributions to RC2

Focus:	(1) P1 defects, (2) P2 defects. Fixing other defects has a lower priority.
Fix approval:	Project lead must approve changes. 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. Describe any changes in comments to bug #164877, so the ISV documentation can be updated accordingly.
Notification requirements:	Announce bug numbers of non-doc and non-unit test bugs/enhancements added to the DTP 1.0RC2 target milestone to dtp-dev@eclipse.org mailing list.
Extra checking requirements:	We strongly urge committers to obtain verification of bug fixes from reporters as soon as possible after delivering.

December 15 – DTP 1.0 release
contributions post RC2

Focus:	(1) P1 defects, (2) P2 defects. Fixing other defects has a lower priority.
Fix approval:	PMC majority vote must approve all non-doc work on a component. 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. Describe any changes in comments to bug #164877, so the ISV documentation can be updated accordingly.
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.