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

[Jürgen Herrmann]

Hi Bastien,

IMHO the build bot builds are more of nightly development builds. Most users don't even look at them.
A real beta could be built at the beginning of BCON4 and advertised on the website so users are aware if that.
Then we do a RC after regressions are fixed and release the final build a week or two later.
We could get a much longer testing time and more feedback.

/Jürgen

Am 29.07.2013 um 14:06 schrieb Bastien Montagne <montagne29 at wanadoo.fr>:

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