[Bf-committers] Sunday meeting minutes, 25th feb 2007

Martin Poirier theeth at yahoo.com
Tue Feb 27 23:07:39 CET 2007


--- Ton Roosendaal <ton at blender.org> wrote:

> My personal stance remains to release as often as
> possible. The past  
> release cycle was very long. Let's do one short
> cycle to compensate  
> (with enough time for 64 bits cleaning and tests)
> and then go to do the  
> bigger jobs again.

If two months would be too long, would it be possible
to shorten it to 6 weeks (would it be possible in that
time to fix 64 bits code)?

Then, we could have 2.44 as a "stable" release, with
bug fixes from 2.43, slight new functionality (stuff
that can be finished in that timeframe) and most of
all, a 64bit version.

> Or: just do 1 more week bugfix only, make 2.43a, and
> then go back to  
> work?

If we do that, we have a lot of reverting to do in BPY
(I'm thinking we should have had a longer "bug fixes
only" freeze after release).

The more I think about it, the more I think we should
roll those changes back anyway to have a 2.44 release
as close as possible to 2.43 (assuming we're going for
2.44). Two months is barely enough time for people to
maintain their scripts (built-in AND outside scripts).

> (On 26 Feb, 2007, at 3:07, Matt Ebb wrote:)
> > What would this really achieve, apart from pushing
> away the promised  
> > refactor work yet again? The papers/design stage
> is what b-con 1 is  
> > for. Why can't these other brand new projects just
> be done in parallel  
> > with other planned 2.5 work?

> And I bet you can think of more things. The more we
> can all agree on it  
> in advance, the easier the implementation will go.
> Having 2 month  
> creative & design phase for this project, before the
> actual  
> implementation starts, is really not bad. And, if we
> then can just  
> manage to do a small release before, isn't that
> wonderful? It then  
> might really need 6 months before we can do another.

Moreover, if 2.44 is supposed to be a quick release
with mainly bug fixes, we could branch for the
refactors during this release cycle and then merge
back when 2.44 is released.

That way, it shouldn't hinder them too much (I must
stress though that if we do that, 2.44 NEEDS to be
limited to bug fixes and small changes and have a
quick release, otherwise, merging back will be hell).


Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.

More information about the Bf-committers mailing list