On Wed, Aug 17, 2011 at 3:06 PM, Campbell Barton <ideasma...@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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers