[Bf-committers] Blender Release Cycle

[Campbell Barton]

On Tue, Aug 16, 2011 at 5:35 PM, Michael Fox <mfoxdogg at gmail.com> wrote:
> On 16/08/11 14:55, Campbell Barton wrote:
>> On Tue, Aug 16, 2011 at 7:52 AM, Michael Fox<mfoxdogg at 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

Michael, its not that you are ignored but can you give some examples
of why this is bad, the last few releases we did kept quite close to 8
weeks and I think it worked well for us, and helps keep developers on
track with stabilizing frequently, having frequent releases != merging
unfinished work, IMHO its a separate issue which we need to deal with
too but can fit in with shorter release cycles.
If this really fails as you suggest I think it will become obvious
that its not working for the upcoming GSOC merges and we can
re-evaluate.