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. My 0.02c - Pasha 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: > > https://svn.open-mpi.org/trac/ompi/report/15 > > (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 > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
