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

Goat Man goatman.py at gmail.com
Fri Dec 18 00:29:45 CET 2009


Python itself needs to go somewhere on that long list, not just something
that will "probably" be used in all those things.  Blender still can not be
controlled well from larger pipelines because it can not be automatically
launched and passed a python script that takes over - currently one big
limitation is not having all the bpy.ops.wm operators available to the
startup script.  Most studios already have custom pipelines, and Python is
often the glue between the apps and their proprietary tools.  Wouldn't it be
easy to expose all or most of Blender via ctypes, or libffi?
-brett



On Fri, Dec 18, 2009 at 1:15 AM, Aurel W. <aurel.w at gmail.com> wrote:

> 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
> >
> _______________________________________________
> 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