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