I think that this sounds reasonable. It's actually not too much of a
change from the existing CMR process:
- if your commit is applicable to the trunk, do so
*** if you intend your commit to go to the v1.3 branch, also commit it
there (potentially adjusting the patch to commit cleanly in the v1.3
- file a CMR for the r number in the v1.3 staging area
- the release tech will merge the v1.3 staging commit to the v1.3 tree
*** is the only new step.
On Dec 10, 2008, at 5:55 PM, Ralph Castain wrote:
> Hi all
> I'm a tad concerned about our ability to test proposed CMR's for the
> 1.3 branch. Given the long delays in getting 1.3 out, and the
> rapidly looming 1.4 milestones that many of us have in our
> individual projects, it is clear that the trunk is going to quickly
> diverge significantly from what is in the 1.3 branch. In addition,
> we are going to see quite a few commits occurring within a
> restricted time period.
> Thus, the fact that some proposed change does or does not pass MTT
> tests on the trunk at some given point in time is no longer a
> reliable indicator of its behavior in 1.3. Likewise, it will be
> difficult to isolate that "this commit is okay" when MTT can really
> only tell us the state of the aggregated code base.
> Let me hasten to point out that this has been a recurring problem
> with every major release. We have discussed the problem on several
> occasions, but failed to reach consensus on a solution.
> I would like to propose that we create a 1.3 staging branch. This
> branch would be opened on an individual-at-a-time basis for them to
> commit proposed CMR's for the 1.3 branch. We would ask that people
> please include the staging branch in their MTT testing on occasions
> when a change has been made. Once the proposed change has been
> validated, then it can be brought over as a single (and easy) merge
> to the 1.3 release branch.
> I realize this may slow the passage of bug fixes somewhat, and
> obviously we should apply this on a case-by-case basis (e.g., a
> simple removal of an unused variable would hardly merit such a
> step). However, I believe that something like the IOF patch that
> needs to eventually move to 1.3, and the Windows upgrade, are
> examples that probably do merit this step.
> Just a suggestion - hope it helps.
> devel mailing list