[Bf-committers] Blender Release Cycle

[Matt Ebb]

On Wed, Aug 17, 2011 at 3:06 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

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

+1  !

Here are some more ideas of mine:

4) Improve testing on branches (continued)

The problem with branches is that not many people use them, everyone just
wants to use trunk, because that's where the action is. At least from my
perception, most of the time when people do use branches, its just to see
some new feature, poke at it a bit, then leave it alone - not really pushing
it to the limit in real work.

A solution for this could be to make trunk the 'boring' branch with mostly
just bug fixes etc, and have a development branch which people can merge
their own branches into for testing (like the gsoc salad branch).

Another idea that Ton had many years ago which I still like is for coders to
find an artist 'buddy' to help them throughout the development process,
someone with whom the developer can work with closely for feedback and
testing. A good portfolio of work done with a branch can go a long way to
vouch for its readiness for inclusion into trunk.

5) All new features are developed in branches

For all substantial new features everyone must use branches - core devs and
module owners included. Module owners are capable of committing
weird/bad/unreliable/poorly tested code, just like anyone else, and this
code should be tested in quarantine as well.

6) Documentation

Ton says this every year or so, but anyway again - before review/merge into
trunk, a new feature should have at least a minimal form of user
documentation, and some brief code/design documentation. Shouldn't have to
be too comprehensive, but should at least help reviewers/module owners/etc
understand the code they're reviewing, or find any design flaws up front.

7) Enforcement

Technically there are policies like these already in place (eg. should have
documentation) but they're never/rarely enforced. Most of the time now, if
people commit weird/bad/undocumented/untested stuff to svn everybody just
shrugs their shoulders and moves on. These will only work if project admins
and committers agree to call each other out on these points and also accept
it when they have to abide by them.

So if something is checked into trunk without going through a branch, or
without proper documentation, or without enough testing, it must get
reverted out of trunk. There can't be a stigma or fear of hurting people's
egos here, it's just a matter of doing what's right for the project. And
ideally with a short release cycle, it's not the end of the world if your
code doesn't make it in to a release anyway, since the next release is just
around the corner.


Anyway, I really do think this is a serious issue - the last couple of years
show that pretty well, and there's the potential for it to get a lot worse
as blender gets more and more complicated, and takes on new scope. In the
end, limiting the addition of code that's not up to scratch results in more,
better features, as less core dev time and resources are spent on bugs, and
more on the cool stuff!


cheers

Matt