> 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.
When branches are expensive, yeah, that's true. Perhaps that's a good argument for switching to a DVCS: it makes it a lot easier to manage this kind of a workflow, since anyone can publish their own branch. I mean, if someone wants to develop a new feature for Blender are they going to have to ask for their own branch right now? And how do we decide when someone gets to have their own branch? Is it just "ask and you shall receive?" Seems like this could spin out of control pretty quickly with something like Subversion. Either that or it becomes a walled garden. I think especially with this kind of release cycle/workflow there are important practical advantages to DVCS. --Nathan On Wed, Aug 17, 2011 at 3:06 AM, Thomas Dinges <blen...@dingto.org> wrote: > 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 > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers