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 t...@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 <a...@phatcore.com> > wrote: >> On Thu, Aug 18, 2011 at 3:22 AM, Nathan Vegdahl <ces...@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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers