IMHO "B" will require a lot of attention from all developers/vendors, as well it maybe quite time consuming task (btw, I think it is q couple of openib btl changes that aren't on the list). So probably it will be good to ask all btl (or other modules/features) maintainers directly.
Personally I prefer option C , A.
On Oct 26, 2010, at 5:07 PM, Jeff Squyres wrote:
> On the teleconf today, two important topics were discussed about the 1.5.x series:
> 1. I outlined my plan for a "small" 1.5.1 release. It is intended to fix a small number of compilation and portability issues. Everyone seemed to think that this was an ok idea. I have done some tomfoolery in Trac to re-target a bunch of tickets -- those listed in 1.5.1 are the only ones that I intend to apply to 1.5.1:
> (there's one critical bug that I don't know how to fix -- I'm waiting for feedback from Red Hat before I can continue)
> *** Does anyone have any other tickets/bugs that they want/need in a short-term 1.5.1 release?
> 2. We discussed what to do for 1.5.2. Because 1.5[.0] took soooo long to release, there's now a sizable divergence between the trunk and the 1.5 branch. The problem is that there are a number of wide-reaching new features on the trunk, some of which may (will) be difficult to bring to the v1.5 branch in a piecemeal fashion, including (but not limited to):
> - Paffinity changes (including new hwloc component)
> - --with-libltdl changes
> - Ummunotify support
> - Solaris sysinfo component
> - Notifier improvements
> - OPAL_SOS
> - Common shared memory improvements
> - Build system improvements
> - New libevent
> - BFO PML
> - Almost all ORTE changes
> - Bunches of checkpoint restart mo'betterness (including MPI extensions)
> There seem to be 3 obvious options about moving forward (all assume that we do 1.5.1 as described above):
> A. End the 1.5 line (i.e., work towards transitioning it to 1.6), and then re-branch the trunk to be v1.7.
> B. Sync the trunk to the 1.5 branch en masse. Stabilize that and call it 1.5.2.
> C. Do the same thing as A, but wait at least 6 months (i.e., give the 1.5 series time to mature).
> Most people (including me) favored B. Rich was a little concerned that B spent too much time on maintenance/logistics when we could just be moving forward, and therefore favored either A or C.
> Any opinions from people who weren't there on the call today?
> Jeff Squyres
> For corporate legal information go to:
> devel mailing list