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

[Bastien Montagne]

I would consider daily bot-built blender’s as “Beta”… After all, we 
never (intentionally) break /trunk, so those builds should always be 
usable, even though not strictly tested. Isn’t it the definition of 
“beta” release?

Bastien

On 29/07/2013 13:56, Jürgen Herrmann wrote:
> Hi,
>
> I think 3 months would be great to introduce an additional beta build right before the RC.
>
> This could help to find regressions before we build a RC.
>
> /Jürgen
>
> Am 29.07.2013 um 13:43 schrieb Campbell Barton<ideasman42 at gmail.com>:
>
>> Last meeting we discussed changes to release because of bad
>> regressions in recent releases.
>> It was suggested that we move to 3 month release cycles.
>>
>> I believe this wont help, since its not really solving the problem,
>> consider that we had 1 week extra to fix bugs for 2.68 (and we _did_
>> fix a lot of bugs), but even then bad regressions still got in.
>>
>> To be clear there were 3 regressions that I'd consider show stoppers.
>> - Crash deleting a sequence strip r58374
>> - Removing vertex colors crashes r58436
>> - Painting Undo Enable Face paint Crash r58509
>>
>> Notice all 3 were caused by `fixes` made after 2.68 RC (made r57908)
>> (There were other bad bugs but not regressions AFAIK)
>>
>>
>> I think there are 2 problems with how we are doing releases currently.
>>
>> - We're making risky changes/fixes too close to the release date.
>>
>> - RC's are not really 'release-candidates', we are asking users to
>> test a build, then making many changes afterwards that aren't properly
>> tested.
>>
>>
>> So I'd propose rather then change the time between releases, we should
>> be more disciplined _not_ to make fixes which have hard-to-predict
>> side effects just before release.
>>
>> After the last release candidate is a good time to only focus on show
>> stopper bugs. We could also use BCON4, as long as it doesn't last too
>> long, (IMHO more then 2 weeks would become inefficient).
>>
>> Some guidelines...
>> - Simple fixes such as NULL checks, array index range checks, obvious
>> memory leaks... etc, are fine.
>> - If the fix is more involved but not a show-stopper or regression,
>> then postpone until next release.
>> - If there is some exception (for whatever reason is really important
>> to resolve), then review throughly (have 2 other devs review for eg).
>>
>> Just listing guidelines to make it more clear the kind of change I'm suggesting.
>> This doesn't have to be any change in policy or new rules, we could
>> just agree not to make risky changes after an RC (or right before the
>> release) I think this would be enough.
>>
>>
>>
>> Other things to look into (which I'm not covering)...
>>
>> - We should really investigate automated testing in areas shown to
>> have caused problems in previous releases (big topic).
>>
>> - Since we can't completely avoid bug-fix releases, we could try to
>> make the process less onerous, minor releases shouldn't be difficult,
>> if they are, we could look into automating this more too, or sharing
>> tasks with more devs.
>>
>> -- 
>> - Campbell
>> _______________________________________________
>> 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