[Bf-committers] Blender Release Cycle
blender at dingto.org
Wed Aug 17 12:06:09 CEST 2011
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
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
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.
Am 17.08.2011 07:59, schrieb Matt Ebb:
> On Wed, Aug 17, 2011 at 3:06 PM, Campbell Barton<ideasman42 at 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!
> Bf-committers mailing list
> Bf-committers at blender.org
Blender Developer, Artist and Musician
More information about the Bf-committers