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
staging area)
- 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.
Ralph
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
