[Bf-committers] Development plan proposal for after the 2.6 series

Aurel W. aurel.w at gmail.com
Thu Dec 17 18:15:46 CET 2009


Hi,

if one distinctive part needs to be exceedingly improved, it makes
sense to focus on it. However, if so many different things need work
anyway, it's more efficient not to focus too much. Otherwise too many
developers are working on the same thing, which causes overhead,
confusing and makes decisions much more difficult.

It also takes a long time to get familiar with the code base in a
certain part to work efficiently. So if only a few developers focus on
one special topic, get to know it well and then work on it, is better
than a huge number of devs learning the ropes for 2-3 weeks, working
efficiently for maybe another 4 and then move on to a completely
different part of blender.

Also, sometimes you just have to let things 'grow' and shouldn't
enforce faster development than possible. Designing something and
coming up with good ideas, just takes some time and can't be sped up
by assigning more and more developers. I guess it's not a good idea to
rush. Also development relies on constant user feedback and you are
stuck in this long and slow cycle anyway.

I am not saying, that having some sort of cycle, where development
slightly focuses on one area shouldn't be considered. But don't overdo
it.

Aurel

2009/12/17 Kent Mein <mein at cs.umn.edu>:
> In reply to Tom M (letterrip at gmail.com):
>
> Hi Tom,
>
> It's a good idea, but I'm afraid it will chase away developers if
> we lock things down too much.  Most of the people work on what they
> want to work on.  What your suggesting sounds an awful lot like
> hey lets make the developers focus on things we want them to focus on.
>
> I'm not saying we shouldn't try it but remember opensource != comercial
> development.  Over blender's history I think that the appropriate things
> have been developed at the right time.  I don't think we have a problem
> there.  I do think we need more patch review and that patch review
> is good.  It's not a fun job though...  We can incourage this, but lets
> keep it in mind that you can't force dev's to do something you'll just
> chase them away...
>
> Kent
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list