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

[Joseph Mansfield]

Hi,

I have a feeling that often the current BCon level is not on everyone's
minds when they commit. I'm not sure if this is possible, but is there any
way we could have an SVN hook that reports the current BCon level and
during BCon 4 asks for confirmation that it's either a very simple or
show-stopper fix. Is this doable?

Joe


On 29 July 2013 12:43, Campbell Barton <ideasman42 at gmail.com> wrote:

> 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
>