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 -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories
