Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "DTP Ganymede Milestone Rampdown Process"
| Line 13: | Line 13: | ||
DTP currently places a CVS tag on each milestone code base, so a historical perspective is available. One can not deliver changes simply to a CVS tag however, and the CVS mechanism designed for this situation (branches) has proven problematic and probably more than is necessary to meet the conditions cited above. | DTP currently places a CVS tag on each milestone code base, so a historical perspective is available. One can not deliver changes simply to a CVS tag however, and the CVS mechanism designed for this situation (branches) has proven problematic and probably more than is necessary to meet the conditions cited above. | ||
| + | ==Process== | ||
| + | *The DTP build team will tag each milestone/release candidate code base | ||
| + | *DTP committer can continue to work as usual with the current DTP code line | ||
| + | *During the period between the DTP and release train milestone dates, if a bug must be fixed in the DTP milestone the committer(s) responsilble for the plug-in(s) impacted can: | ||
| + | **If the current code line for the involved plug-in(s) is acceptable for use in the milestone, the committer makes the necessary bug fix, the build team moves the milestone tag ahead for the involved plug-in(s), and a new milestone build is produced using this code base. | ||
| + | ** | ||
Revision as of 11:34, 11 February 2008
Status
[2/11/08] This document is a draft and should not be considered DTP policy until approved by the DTP PMC and project leads.
Introduction
DTP is a "+1 dependency" for the Eclipse coordinated release trains. Since there are +/- 3 levels of dependencies, there is a gap between when DTP is ready to produce a milestone/release candidate and when the overall release train milestone/release candidate is complete. During the time between the DTP milestone/release candidate and closing of the release train milestone/release candidate, downstream consumers of DTP might finds bugs that are severe enough to require a new DTP build. Thus, DTP milestone/release candidate are not really "done" until the everyone on the release train is done.
The question then become how to maintain progress in DTP while keeping open the possibility of reacting to release train rebuild requests. More bluntly, how can we allow (sometimes substantial) changes to the DTP code base when we might be called on to resolve specific bugs (and limit risk by not introducing further changes)? Thus, the purpose of the process is to define a method by which the following constraints can be met:
- Maintain DTP progress even before a release train milestone/release candidate completes
- React to necessary bug fixes for the release train without unnecessarily introducing further changes
- Require only the minimal amount of work for committers to address these occasional emergencies
- Not complicate the process/source code tree of DTP for specific, contained, and relatively uncommon events
DTP currently places a CVS tag on each milestone code base, so a historical perspective is available. One can not deliver changes simply to a CVS tag however, and the CVS mechanism designed for this situation (branches) has proven problematic and probably more than is necessary to meet the conditions cited above.
Process
- The DTP build team will tag each milestone/release candidate code base
- DTP committer can continue to work as usual with the current DTP code line
- During the period between the DTP and release train milestone dates, if a bug must be fixed in the DTP milestone the committer(s) responsilble for the plug-in(s) impacted can:
- If the current code line for the involved plug-in(s) is acceptable for use in the milestone, the committer makes the necessary bug fix, the build team moves the milestone tag ahead for the involved plug-in(s), and a new milestone build is produced using this code base.