> 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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers