Double thumbs up from my end also. There's a lot to be said about stricter discipline for commits to trunk.
Martin --- On Sun, 3/13/11, Ton Roosendaal <t...@blender.org> wrote: > From: Ton Roosendaal <t...@blender.org> > Subject: Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond > To: "bf-blender developers" <bf-committers@blender.org> > Received: Sunday, March 13, 2011, 11:08 AM > Hi Brecht, > > > I strongly believe we should switch to short, fixed > release cycles, > > and be much more strict in only accepting > functionality in trunk that > > is reviewed and can be stabilized in a short time. > > > Fully agree! :) > > -Ton- > > ------------------------------------------------------------------------ > Ton Roosendaal Blender Foundation t...@blender.org > www.blender.org > Blender Institute Entrepotdok 57A > 1018AD Amsterdam The Netherlands > > On 13 Mar, 2011, at 15:52, Brecht Van Lommel wrote: > > > Hi, > > > > I think we should make major modifications to the > release cycle, to > > avoid problems that we've been having with 2.5 and > also releases > > before that. In my opinion a migration schedule for > new features as we > > have done before does not work, because it's > unpredictable when > > developers will be available to work on things, and > worse, developers > > are blocked a long time waiting. > > > > There's this dynamic which I think we should try to > break: unstable > > features push back release dates, then after a while, > core developers > > in other areas get impatient and add another unstable > feature, which > > agains pushes things back further, while branches get > even bigger and > > harder to merge. > > > > I strongly believe we should switch to short, fixed > release cycles, > > and be much more strict in only accepting > functionality in trunk that > > is reviewed and can be stabilized in a short time. So, > this is what I > > propose we do: > > > > > > RELEASE SCHEDULE > > > > Releases are unpredictable, it's not clear when they > will happen or > > when new features can get in. I propose we use a fixed > release > > schedule, to make it more predictable, ensure regular > releases, and to > > encourage good development practices. > > > > For example, we could have a 8 week schedule (or even > shorter!): > > weeks 1-3: new features can be merged > > weeks 4-6: stablizing and enhancing > > weeks 7-8: critical bugfixes only > > > > If a feature is not stable or not documented by week > 7, it gets moved > > to the next release (and preferably we find this out > earlier). If you > > expect a feature is too big to stabilize in the given > time, split it > > up. > > > > BRANCHES > > > > There is the issue of how to do such a release > schedule in terms of > > branches. Most power users are simply using trunk and > not releases, so > > having separate branches for development and stable > releases is not a > > viable option in my opinion. I propose to center > everything around > > trunk, and let developers use short lived branches > while trunk is > > locked if they want to. > > > > If we keep the release cycle sufficiently short, > developers know they > > can merge things soon. I think we should try to avoid > branches that > > live too long. Features don't get good testing, it's > demotivating for > > developers, and merging them destabilizes trunk too > much. Just split > > up things if it doesn't fit the release schedule. > > > > Existing major branches should be merged in pieces if > they risk > > destabilizing things too much. If code can't be > stabilized in a few > > weeks, it simply should not go in trunk, in my > experience it is always > > possible to split things up. > > > > > > Brecht. > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers