On Oct 27, 2010, at 9:14 AM, Jeff Squyres wrote:
> On Oct 26, 2010, at 5:52 PM, Barrett, Brian W wrote:
>>> B. Sync the trunk to the 1.5 branch en masse. Stabilize that and call it 1.5.2.
>>> 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.
>> 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).
> FWIW, I outlined the reasons on the call why I thought B was appropriate. Here's the (very) short version:
> - We state that changes may be large in feature release series. The goal of a feature series is features. Here's specifically what we state:
> o Even minor release numbers are part of "super-stable"
> release series (e.g., v1.4.0). Releases in super stable series
> are well-tested, time-tested, and mature. Such releases are
> recomended for production sites. Changes between subsequent
> releases in super stable series are expected to be fairly small.
> o Odd minor release numbers are part of "feature" release
> series (e.g., 1.3.7). Releases in feature releases are
> well-tested, but they are not necessarily time-tested or as
> mature as super stable releases. Changes between subsequent
> releases in feature series may be large.
> - I'd prefer not to end the 1.5 series prematurely. I.e., let's give it time to get mature before going v1.6.
> - There are a lot of new features on the trunk that are worth bringing over / releasing to the world in the not-distant future.
> You're right that there may be some stuff that isn't ready for prime time on the trunk. Your portals stuff is the first thing to be called out specifically, but we can handle that (e.g., not update the portals directories on the v1.5 branch).
I understand what you're saying. But the fact still remains that our release process is supposed to be features move as needed/requested/ready from the trunk to the development release. This is not that at all - this is "we're lazy, so we're going to do a wholesale sync whether features are ready or not". That's a bad plan. If you want developers to list the features that should move, that's fine. But just saying "we've decided everything is ready because it's easier" seems like a bad precedent.
Brian W. Barrett
Dept. 1423: Scalable System Software
Sandia National Laboratories