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

[Brecht Van Lommel]

Hi Ton,

To me the problem seems to be exactly that people are focusing on
stabilizing right up until the release. We get 100 bugfixes in those
last weeks, and some of those fixes will inevitably break something
else. If we want things to be tested well we need to freeze the code
for a while except for a few critical fixes, otherwise there is no
time for users to actually test them.

If you look at the bugs that required a and b releases they were often
introduced by late bugfixes. I'd love to see more people help out with
bug fixing of course and this will help with Blender stability
overall, but I don't think it would avoid this particular problem, it
might make things worse actually if they all start doing that in the
last two weeks without a proper freeze period.

Further I don't think the code in branches not getting tested is a
problem in practice, what's in the branch is a snapshot of trunk and
the bugs in the branch will also be in trunk, except for things which
were accidentally fixed there, but I think that's rare.

Brecht.

On Tue, Jul 30, 2013 at 4:43 PM, Ton Roosendaal <ton at blender.org> wrote:
> 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers