On 16/08/11 14:55, Campbell Barton wrote: > On Tue, Aug 16, 2011 at 7:52 AM, Michael Fox<mfoxd...@gmail.com> wrote: >> On 15/08/11 22:40, Sergey I. Sharybin wrote: >>> Hi, devs! >>> >>> We've already got thread about release cycles, but it was a bit long and >>> seems like there's no final decision made. We've discussed that proposal >>> with Campbell and also investigated why we've run into some problems >>> with current release. There are some comments which i'd prefer be final >>> decision about our release cycle (most people are already ok with it, >>> just to make things 100% clear). >>> >>> Few first weeks of cycle (B-Con 1 and B-Con 2) aren't so critical for >>> this discussion and we've already agreed with this levels. >>> >>> More critical to make work clear in few weeks (1-2) before release (i >>> mean before starting commiting new splash/changelogs and so). What is >>> needed there: >>> >>> - Only _critical_ bugs should be fixed. Critical doesn't mean "i can >>> make blender crash in few clicks" but it mostly means this bug was >>> introduced in current cycle and it stops normal workflow. If this bug >>> was present in previous release or if it's not making general usage >>> unusable we'd prefer to keep this bug untouched. Fixing such bugs >>> wouldn't make real sense on general workflow and if it wasn't noticed in >>> previous release then it doesn't annoy artists. But fixing such bugs >>> easily produces new bugs which difficult to predict and we wouldn't have >>> enough time to test everything. >>> >>> - We need clear "FREEZE" and "UNFREEZE" AHOYs. If freezing will happen a >>> bit earlier -- it's not so critical. But unfreezing should be done quite >>> accurate -- when everybody who is familiar with making release would say >>> it's ok to unfreeze. >>> >>> - We'll need tag for every release. It should be created even for >>> "initial" release (not corrective release like 'a' or 'b' releases). >>> this is needed to make platform maintainers' life more clear. If stopper >>> is discovered during archive preparation, fix for this stopper can be >>> easily commited to trunk and merged to tag. It'll help a lot for release >>> process when most of core/BF developers are offline -- no need to wait >>> someone to prepare archive. >>> >>> - Most probably we'll need guy who is familiar with svn who will make >>> tag and solve possible issues of platform maintainers. It shouldn't be >>> "constantly" defined developer, prefer to choose one for each release -- >>> it's needed to be sure he can be available during release. >>> >>> - So, FREEZE happens, new tag is creating and AHOY could happen. Day or >>> two after this normal life of trunk could be restored. But _nobody_ >>> should commit anything than fixes for stopper/fixes for build >>> environment until _official_ unfreeze. Even commit of stylefix could be >>> confusing in the future (if more serious problem was discovered, i.e.). >>> >>> - If 'a' release is needed, we shouldn't re-tag. We should merge fixes >>> for _stoppers only_ into tag and do not include fixes for all bugs which >>> were made since release. This is a way to avoid 'b' releases. >>> >>> So, short summary: fix only _really_ critical bugs last week before >>> release-related commits; make clear FREEZE/UNFREEZE messages in ML. >>> create tag for release just before AHOY, if 'a' release is needed only >>> stoppers for previous release (for which 'a' is creating) should be >>> ported into tag. >>> >>> I hope only Campbell/Ton/Brecht make minor changes to this message or >>> write things i've forgot to tell about. But again. i don't want this >>> message start new discussion thread and i hope it'll be final decision now. >>> >> I thought this is what we already do, its just in the 2.5 series we have >> become very lazy in these regards, now that 2.5 is final and stable, we >> should really adopt our old methodology again with no set freeze period, >> we aim for a date and set freeze a few days before it, and only release >> if the code is deemed releasable > This goes against the fixed 8 week release cycle, "release when its > ready" might sound good but blender is getting so big that we can > always point at some part > (py-api/input-support/bug-on-some-OS/some-new-library/ffmpeg/sequencer) > and say its not ready *and be right*, but then end up not releasing > even though many bugs _are_ being fixed between releases and useful > improvements made. > > With time based releases only consider show-stoppers as new bugs which > were introduced since the last release or anything that makes blender > unstable for common use. > I never agreed with the 8 week release cycle anyway, as it causes you to rush your work resulting in ugly hacked together code and features and results also in releases with little substance. Such a cycle works for Chrome and FF because they are at each other throats trying to out do each other and fix 100s of bugs a day.
This proposal for 8 weeks is foolish, we have always prided ourselves on clean(ish) code and well thought out mature features and releases filled to the brim with stuff and never put 1 bug above another all bugs are the same and the community loves us and loves blender for that as we don't belittle their problems. i know i should have said this earlier but what i say has very little meaning anymore like what i said here will be ignored as always _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers