Hey Matt and Campnell, I generally agree with you here, but I don't agree with 5) All new features are developed in a branch What defines a new feature? How big must the impact be for it? I mean it's senseless to write a small feature which only affects a few lines in some areas to be developed in a branch. So we need to define what features must be developed in a branch and not. Also I don't really want to take away the module owners rights really. The code should be checked better, but it doesn't make sense really for core devs. I think it's better to give us the possibility to say "This is not good enough" and revert , if it gives us issues, rather than forcing a module owner to develop everything in a branch too.
Another thing that came up yesterday by some devs in IRC, is that we might better increase the cycle to 12 weeks. And on second thought, it's really a lot of work to have 6 really stable releases a year, 4 would be sufficient imho. This way, we would have more time in trunk to do bug fixing after the big merges in bcon 1/2. And I have to agree with it, better not rush releases out. Fixed cycles and planning yes, but give it a bit more time. In general I definitely agree with you Matt, we have to be more strict, otherwise it can get worse. Best regards, Thomas Am 17.08.2011 07:59, schrieb Matt Ebb: > 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 -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers