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

[Campbell Barton]

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