Jump to: navigation, search

Difference between revisions of "DTP Ganymede Milestone Rampdown Process"

(New page: {{Back To|name=DTP Main Page|href=Data Tools Platform Project}} ==Status== [2/11/08] This document is a '''draft''' and should not be considered DTP policy until approved by the DTP PMC an...)
 
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{Back To|name=DTP Main Page|href=Data Tools Platform Project}}
 
{{Back To|name=DTP Main Page|href=Data Tools Platform Project}}
==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==
 
==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.
 
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.

Latest revision as of 14:33, 11 February 2008

Back to DTP Main Page

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.