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.
DTP Ganymede Milestone Rampdown Process
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.
- If the current code base has changes that should not be included in the milestone, the committer(s) responsible for the impacted plug-in(s) takes a copy of those plug-ins from the milestone tag, creates a new folder in their CVS module called "R1.6X" where "X" is the milestone/release candidate number, resolves the bug on the plug-in(s) in that new folder, and the build team produces a new milestone build using that folder for the involved plug-in(s) and the milestone tag for the rest.