[Bf-committers] Blender Release Cycle

[Nicholas Bishop]

> 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.

On a related note, I think it might be helpful to break branches up
into a series of smaller patches. I think a lot of branches can
probably be split into at least three sets:
1) First would come very general changes to existing code. This would
include things like bug fixes for trunk, but also things like adding
an extra parameter to a Blen[lib/kern] function to make it more
general, or adding better comments to an existing module. There are
often a lot of changes like this that can be reviewed entirely
independently of whatever feature the branch is actually focused on.
2) The second set would be more in-depth refactoring within one or
more modules. For example, a new sculpting/painting mode might want to
refactor some of the generic paint stroke code to expose some new
feature to all the painting modes. Or maybe some new data structure
has been created that could be submitted as a new Blenlib interface.
Essentially this set is more complex/bigger changes than the first
set, but still stuff that can be reviewed independently of any new
features.
3) The third and final set would contain the new feature itself. The
goal here is that this patch should be as simple as possible, relying
on refactoring and infrastructure changes from the previous two sets.

Obviously the above three descriptions are a bit general and would
need be interpreted a bit on a case by case basis, but I think this
could be a helpful guideline. I've been doing something like this for
my own experimental patches; there are a number of new features I've
worked on like Ptex and the skin modifier that simply aren't ready to
go in trunk yet, but I've still been able to extract some useful code
and put it in trunk (things like adding better comments to the PBVH
struct, cleaning up the GPU VBO code, and refactors in the paint
code.)

-Nicholas