[Bf-committers] Blender Release Cycle

[Ton Roosendaal]

Hi all,

That's a long thread already :) It's not easy to get the issues  
collected we generally agree on... but as a great old wise Dutch  
philosopher once said "strict in what we agree, freedom in our doubts,  
love for everyone!".

I personally also don't like to manage much by rules, it's just  
guidelines... managing by reponsibilities and empowering people is  
more succesful I think. This is where our module owners/teams have to  
step in for. They can get some flexibility to define 'feature' or  
'fix' or when a branch is required or not.

I'll try to get a new summary/proposal for this topic tomorrow  
morning, hope it gets a bit less fuzzy for me in morning time!

Laters,

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 18 Aug, 2011, at 16:19, Campbell Barton wrote:

> On Thu, Aug 18, 2011 at 9:39 AM, Alex Fraser <alex at phatcore.com>  
> wrote:
>> On Thu, Aug 18, 2011 at 3:22 AM, Nathan Vegdahl <cessen at cessen.com>  
>> wrote:
>>>> 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.
>>
>> +1; this would be unworkable without DVCS.
>>
>> Alex
>
> @Nicholas Bishop, +1 for you're suggestions for how to apply changes
> from a branch in steps.
>
>
> @Matt, +1 on you're extended items to my initial list - all features
> in a branch Im not against either but need to use some common sense
> here, some cases this could just be impractical - when to branch, when
> to share branch, which feature is so small its not needed.... etc.
>
>
> @Michael Fox, I find the tone in you're last mail odd and totally not
> my impression of the state of blender, I'm interested to know if this
> is only you're POV or if many devs/users are thinking this???
>
> Reply to 2 points...
>
> - Blender bug tracker has more bugs because more people are testing
> blender!, many bugs that are fixed are not reported so infact the
> number of bugs in the tracker should be much higher, and 6months back
> should have been 100's more then it was.
>
> - Regarding "not calling bugs show-stoppers belittling users reports",
> and that _any_ bug could be a showstopper.... eeeh,
> well yes - of course any bug can be a showstopper but the line has to
> drawn somewhere, else we just end up in release paralysis, I think it
> should be enough that we try fix bugs when we find time, holding back
> a release means users who stick to stable builds are not getting the
> fixes we HAVE done, think we just have to try use our best judgment
> here.
>
>
> @Knapp, don't think comparing blender to kubuntu makes sense in, a
> collection of packages and a single software project are very
> different - Enough distros manage to get this right so expect they
> have internal troubles getting enough maintainers or quality of
> packages.
>
>
> @ *DVCS Issue*, think this is a bigger topic and I'm worry that
> everyone just agrees DVCS is awesome, this thread fizzles out and
> nothing happens.
>
> DVCS asside we still need to settle on what to do for the release
> cycle, and until we do the actual switch to DVCS - or state that some
> git-svn combination (for eg) is the way-to-go, we still should set
> some policy on merges as Matt and I are suggesting.
>
> Last I checked moving to DVCS (GIT actually) needs some experienced
> admin with time to devote to managing issues with large binary files
> we have in SVN so I think we first have to find this person to show
> its even something we can pull off.
>
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>