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
- 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?
For corporate legal information go to: