I think bringing the large changes from the trunk via patches in the CMR style is a non-starter, so I am glad that none of the options include this. So I am for any of the options proposed.
I would just like the development branch (whether it be v1.5.X or v1.7) to be released more often. The original intention was that it would happen once every month or two. We missed that mark by quite a lot, which only compounds the problem with this particular decision. So I vote for any of the three options :) -- Josh On Oct 30, 2010, at 3:16 PM, Shamis, Pavel wrote: > 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 > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > ------------------------------------ Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey
