[Bf-committers] Blender Release Cycle
ideasman42 at gmail.com
Thu Aug 18 16:19:32 CEST 2011
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.
@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
@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
@ *DVCS Issue*, think this is a bigger topic and I'm worry that
everyone just agrees DVCS is awesome, this thread fizzles out and
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.
More information about the Bf-committers