On Oct 26, 2010, at 3:52 PM, Barrett, Brian W wrote:
> On Oct 26, 2010, at 3:07 PM, Jeff Squyres wrote:
>> 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?
> I'd vote for !B.. It goes against the whole branch and stabilize approach. The fact that we've been bad about pushing changes to v1.5 is no reason to whole-sale throw out our release philosophy. Plus, I know there's stuff in the trunk that shouldn't be in 1.5 (like my recent portals work that's nowhere near ready for prime time).
As I said on the call, this doesn't matter to me. However, I will offer this in support of Brian's position.
There is a sense out there in user-land that OMPI is no longer reliable - tends to be buggy. This may not totally be fair (I think there is confusion about "feature" release series), but there is validity to that sentiment in that we don't test our features.
The problem, IMO, is that almost all of these features are not related to the MPI standard - they are runtime features, or new components, or other such things that are not tested by our MTT runs because they require flags to activate them. Thus, while those of us who develop the features test them on our systems, they are not generally tested across the range of supported platforms.
In addition, new features are rarely tested in subsequent releases as testing them is at the discretion of individuals (who, like me, tend to forget to go back and see if that thing still works).
My point: we may need to rethink the "feature" series idea as it appears to be eroding confidence in user-land, and we should rethink how we test release candidates. Given those suggestions, it would seem that syncing the trunk to the 1.5 series would be a bad idea, even if we subsequently prune thinks like Brian's portal work.
> Brian W. Barrett
> Dept. 1423: Scalable System Software
> Sandia National Laboratories
> devel mailing list