[Bf-committers] Blender Release Cycle

[Campbell Barton]

On Wed, Aug 17, 2011 at 10:47 AM, Matt Ebb <matt at mke3.net> wrote:
> 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.
>
> cheers
>
> Matt

Hi Matt, I'm with you on this, more often then not big changes ==
breakages/bugs/dropping-support-for-corner-cases/glitches.

I think problem with code quality of branches needs to be solved by
some tangible changes to the process and what we accept.
like saying "lets not write buggy code" - it sort of meaningless
unless its followed up with some real changes to how we work.

Here are some suggestions
*disclaimer that this is colored by my own experience & preferences, I
may be overlooking some issues*



1) don't accept changes from branches that are outside the branches scope.

Sounds obvious but devs add features or fix bugs (in gsoc too), which
are not related to the branches main purpose, IMHO this is really bad
for a few reasons.

* makes reviewing the branch difficult since its not always obvious
why the change is made, Ive had to follow this up with the authors -
sometimes to find it was some test left in by accident or just a
change they thought was a better default.

* adds communication overhead to branch review OR it just slips
through into trunk which can also be really bad if the change has
unforeseen side effects.

* makes svn annotations harder to follow when new bugs resolve to
lines from a merge which isn't even supposed to be touching this area.

For devs who already made unrelated changes in their branch it just
means submitting unrelated changes as patches on trunk.


2) Code should be reviewed - as in "a developer read over the
changes", sounds obvious too but currently we don't always do it.

Of course code review still allows for bugs in behavior, but from
reading diff's some bugs are obvious.

With large changes to blender which I find suspicious, I'll copy
blenders source tree and view the source tree before/after the change
using a visual diffing tool - since reading the diff on its own isn't
easy to follow.
I did this recently from a merge and found lines like "Fix this
tomorrow", and some obvious hacks that should have been dealt with
before the merge - This was in code I wrote so I'm confident they were
not-good-changes, but the point is nobody reviewed the branch!

We have 4 employees for BF now, we should be able to manage this? :)


3) Improve testing on branches

This is hard to enforce, I think we can only try to help users to get
branches before they merge.

Suggest to have buildbot running for branches that we plan on merging
each cycle, probably other ways to help with this too - have testing
link from our download page, have a better way to report bugs in
branches... realize this is a big topic and someone has to take time
to set it all up :S.


-- 
- Campbell