[Bf-committers] Avoiding regressions, changes to the release cycle.

[Ton Roosendaal]

Hi Brecht and Campbell.

I can't follow this renaming proposal really... 

For as long we work with communities and volunteers out there, we should assume them to be preferring to use "the latest" svn checkout any time. For that reason moving release candidates to branches will just mean it gets not used, not tested nor compiled by anyone else than less than a handful of devs here.

That's why we added the 'BCon' cycle, where the last 2 cycles were meant for everyone to stop coding new stuff for 3+ weeks, and focus on stabilizing and fixing and testing of trunk (and *not* work on branches).

In practice however, attention of many people now goes to own branches and local gits... just waiting for these annoying BCons to be over to add code again. :)

This could be a reason to extend BCon cycles again to be 3-4 months. Just to get at least a couple of moments per year when everyone (everyone!) agrees on a period to focus on a release, instead of just a small minority here.

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 30 Jul, 2013, at 12:53, Brecht Van Lommel wrote:

> Regrading the original mail in this thread, I completely agree with
> being more strict in the week before release. That's a rule that is
> supposed to be there already but we don't follow it well, so we can
> agree as core developers to enforce that better for the next release.
> The only thing I fear is that we'll be under time pressure again and
> become lax again, but if there's 1 or 2 developers kicking others it
> can be done.
> 
> On Tue, Jul 30, 2013 at 11:25 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> @Brecht
>> re: branching stable (keeping trunk for development)
>> 
>> This topic has come up before, IIRC Ton is against doing this since it
>> means developers focus less on stabilizing and users who build are
>> less likely to update svn and use the version of blender we will
>> release (valid points IMHO).
>> If we rename our 'release' -> 'RC', and '2.68a' -> 'release',
>> then this is exactly what we do already (since the bugfix release is
>> made from a tag of trunk).
>> Though I worry too many issues get conflated and then we don't agree on basics.
> 
> If we can somehow turn the release into RC and 2.68a into 2.68 then I
> think that is a step forward.
> 
> Maybe I should try to convince Ton about this.. in my opinion we can't
> really focus on stabilizing and have trunk frozen at the same time,
> either we continue bugfixing or we wait for critical issues.
> 
> 
> Brecht.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers