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