[Bf-committers] Blender Release Cycle

Matt Ebb matt at mke3.net
Wed Aug 17 02:47:32 CEST 2011

On Tue, Aug 16, 2011 at 2:55 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

> With time based releases only consider show-stoppers as new bugs which
> were introduced since the last release or anything that makes blender
> unstable for common use.

For what it's worth, I really like the idea of time-based releases, but
there's a big caveat which I think hasn't been properly solved yet. The
whole idea is based on keeping trunk stable (i.e. not allowing it to go into
long periods of instability while coders work on things heavily in situ),
and to use branches for work-in-progress stuff and merge them into trunk
when they're properly ready and won't disturb trunk.

This is great in concept, but it's also this part that is the problem here.
Time and time again, branches aren't tested well enough before merging. I've
seen it so many times over the last several years - features getting added
without having major bugs found by testers, dodgy code getting added without
a proper code review or oversight from other committers, and when these
things happen, the code tends to stick around. (I'm sure I'm not blameless
in the past here myself, either). For the last couple of releases it wasn't
so bad since there weren't any major new features (but even then there are
still plenty of bugs), but I'm a bit concerned about what will happen
especially now the kids on the internet are getting all excited about
opening the floodgates of new code for 2.6, which probably hasn't had nearly
enough testing/review either.

I think for this to work, project admins will need to be much stricter about
what is acceptable to go into trunk. If there are still signs of problems in
a newly merged bit of code when coming up to release time, it needs to be
ruthlessly pulled out before release (in order for the developer to work on
it some more before the next cycle), and not just allowed to slip through.

I think if the last year or two of blender development has shown anything,
it's that quality control is a huge issue, and that blender needs *quality
code* much more than it needs *more code*. It's quite an inefficient use of
resources when the more experienced and skilled blender developers (the ones
on the BF payroll) are spending their time bogged down fixing silly bugs. At
least when I was doing it, I found it rather demotivating too.

So I think this shorter release cycle can be an improvement, but if and only
if it's taken as an opportunity to be stricter about the inclusion of
insufficiently tested/poorly written code. If not, it'll probably make
things much worse.



More information about the Bf-committers mailing list