This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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