[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lusque).

[Sean Olson]

This conversation brings me directly back to a link that Ton posted a couple
weeks ago:
http://www.codesimplicity.com/post/open-source-community-simplified/

I keep seeing the same arguments popping up again and again about
documentation, and I think it highlights a larger problem with
our development process.   As stated in the link above, we have long "bug
fix" phases that no new features are added to Blender.  I think this would
be just fine if they lasted a couple of weeks, or even a month.   But this
'bug fixing' phase has now lasted at least 5 months if we take the "Sintel"
online release as the date of the start of the bug fixing phase.   There are
now developers who have been chomping on the bit for near half a year to get
their hard work into our product to help us!   Just as changing the way the
code works in late development is bad for documenters, making eager
developers wait for half a year to get code integrated is bad and very
frustrating for developers. This will make all but the most stubborn
developers lose interest and leave.  This most definitely is not good for
the community as a whole.   (I for one am still eagerly awaiting many of the
improvements from the last SoC to be integrated, even as the next one is
almost upon us).

Once again, the article above highlights quite possibly a very good
solution.  When working towards a release have a release tagged branch for
any 'bug only fixes' and always keep trunk as the development branch.  When
commiting bug fixes - commit to both the tagged release branch and the
trunk.   It's more overhead, but it would lead to much happier documenters
because they could write a book on a not constantly changing program, and it
would make the developers much happier because they could work on what they
love to work on, adding cool new features, improving workflow, and doing
whatever else makes our ever changing product so much fun to work on.

If blokes want the 'bleeding edge' they get trunk - otherwise go for a
tagged and well documented release.

Food for thought
-Sean




On Wed, Feb 16, 2011 at 6:43 PM, Jason van Gumster <
jason at handturkeystudios.com> wrote:

>
> Michael Fox <mfoxdogg at gmail.com> wrote:
>
> > This goes against all of the 2.5 UI design principles and pardigms and
> > show be removed or onlt be visible when needed, as its a clear case of
> > craming chikens into a basket, a big ugly mess
>
> I'd like to reaffirm this. Not only is this antithetical to the 2.5 design,
> but
> it simply makes *less* sense from the end-user perspective. There must be a
> better way of doing it than this. I would suggest that this be reverted
> until a
> properly designed solution is presented. I understand the rationale for
> creating this panel, but the panel looks like a grab-bag of mixed
> functionality. It's a UI change for worse.
>
> This only barely makes sense in the context of node-based materials. If
> it's
> critical that these options be grouped together, why not put this in the
> Properties region of the Node Editor for materials and leave the Materials
> section of the Properties editor as it was?
>
>  -Jason
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
||------------------ Instant Messengers ----------------------
||                     ICQ at 11133295
||                 AIM at shatterstar98
||  MSN Messenger at shatter98 at hotmail.com
||              Yahoo Y! at the_7th_samuri
||----------------------------------------------------------------------