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 <[email protected]>: > 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
