[Bf-committers] Blender Release Cycle

[Sergey I. Sharybin]

Campbell Barton wrote:
> @Nicholas Bishop, +1 for you're suggestions for how to apply changes from a branch in steps.
I'll agree with this.
> @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.
As Thomas wrote already, not every new feature should have a branch. 
Most of developers are commiting almost finished features (almost in 
terms some additional testing could discover bugs, branches would be 
affected with the same problem before merging to trunk). We also have 
got code review which is useful, imo.

But we need to be more active there to review patches (simple sample -- 
i've sent patch there a week ago and still have got no feedback).
> @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.
I'll agree with Campbell here. Some of friends of mine haven't used 
blender until 2.57 because it was alpha/beta. And i think it's not only 
my friends (which i know personally) used to think in the same way.
> - 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.
IMO showstopper is only bug which was added in release cycle and which 
prevents general use case. If bug was in previous cycle or it happens 
only on special case which isn't so general, then it could be treated as 
non-stopper. If bug was already in tracker then most probably it wasn't 
fixed because it's not so critical. If bug was discovered just before 
release -- i also don't think it was so critical -- otherwise it was 
already reported (but ofcourse exceptions of this rule happens and we'll 
handle them).
It it's impossible to fix all bugs before release. And i'll also agree 
with Campbell -- we need that line to know when to release. We aren't so 
lazy and we're fixing hundreds of bugs each release and adding new 
features. IMO, it's what users want -- they don't want to wait year or 
so to have 100% bugless Blender.
> @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.
Linux distro is more a ecosystem which should be stable and predictable 
and it doesn't release so often. Blender is more a tool so it could be 
releases more often. We just have to pay a bit more attention of code 
review for fixes/features to prevent regressions and each next release 
will bring users bugfixes and new features (which i hope wouldn't have 
serious problems).
> @ *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.
DVCS is nice for code. We have also got libs/regressions tests which are 
quite large binary repos. Lats time i've tested git it wasn't handling 
this repos well (but i use git-svn for source tree which works pretty nice).
I'm nto such guru of git to tell solution for this problem. But IMO we'd 
peter host all repos in the save VCS system. Otherwise it'll be more 
like a chaos and wouldn't be so useful.

-- 
With best regards, Sergey I. Sharybin