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

[Jürgen Herrmann]

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