DTP Ganymede Milestone Rampdown Process
[2/11/08] This document is a draft and should not be considered DTP policy until approved by the DTP PMC and project leads.
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.