On 10/11/2010 06:11 AM, Jeff Squyres wrote:
On Oct 10, 2010, at 7:49 AM, Terry Dontje wrote:
At first glance this sounds like a sane approach but didn't we start with this
same approach with 1.5.0? I know it was kind of required to do it for 1.5.0
but we did go off track with delivery. I believe to be successful at making a
deadline for 1.5.1 we need to consider the following. Do we think the initial
stablization is going to take weeks or months?
I *think* weeks. The trunk is pretty stable right now. But then again, that's
why I'm asking here -- what do others think? Are there half-baked features in
the trunk that are not / nowhere near ready for the v1.5.1?
I don't have my half bake features in the trunk, yet :-).
While we stablize what will be the rules of doing CMRs to 1.5.1? What will be
the rules for doing CMRs to 1.5.1 after stablization?
I think the CMRs will be pretty much the same. However, we do reserve the right to have the more
aggressive CMRs -- e.g., something "big" can be "ok, Terry/CMR committer, you have
the v1.5 branch for 3 days. Bring your feature over to it." (might not be necessary if we
re-sync, but we still reserve the right to do it ;-) ).
Did I misunderstand the commitment we had for quick dot feature releases
earlier this year? The above sounds like we'll repeat the 1.5.0 release
schedule and possibly end up not releasing 1.5.1 until 8 months from
now. Unless the trunk doesn't have any major features/changes I'd
almost be more inclined to say the stablization of the trunk merge be
the 1.5.1 release and plan for a 1.5.2 based on CMRs (no CMR no putback
to 1.5.2). However, that is really dependent on the merge happening and
what amount of wide spread changes that end up being put back into the
trunk that makes backporting to 1.5 branch difficult to impossible. I
would even be somewhat supportive of periodic trunk sync ups to
alleviate such backport pain.
--td
--td
On 10/8/2010 5:13 PM, Jeff Squyres wrote:
As we discussed on the call last week, since there is already a bit of a
divergence between the trunk and the v1.5 branch, how's this for a wild idea:
What if we re-sync the entire trunk to the v1.5 branch, stabilize that,
and call it v1.5.1?
The assumption here is that it will be [far] easier to just re-sync the trunk
to the v1.5 branch than to try to bring over stuff in a piecemeal fashion.
There's a *bunch* of new stuff on the trunk that is not on the v1.5 branch -- there's
more than enough "meat" to call it a new release.
*** Put differently: is there anything on the trunk that is *not* ready to go
to the v1.5 series?
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Oracle
Terry D. Dontje | Principal Software Engineer
Developer Tools Engineering | +1.781.442.2631
Oracle * - Performance Technologies*
95 Network Drive, Burlington, MA 01803
Email terry.don...@oracle.com <mailto:terry.don...@oracle.com>
