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

Campbell Barton ideasman42 at gmail.com
Mon Jul 29 21:00:53 CEST 2013


On Tue, Jul 30, 2013 at 4:41 AM, Tom M <letterrip at gmail.com> wrote:
> On Mon, Jul 29, 2013 at 3:43 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
>
>> 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
>
> Since all 3 of these would be caught by Clang and Coverity, why not do
> a coverity/Clang build the day of the RC and then do one the day you
> plan to do a release build - compare the two - if there are any new
> items that are in the release build not in the RC, then don't do the
> release till they are fixed or confirmed to not be an issue.
>
> LetterRip

We did use both Clang and Coverity, and these tools didn't find any of
these problems,
they did expose other problems though and are very useful.

There are various other things we do to help automatically detect errors,
defines: DEBUG_STRSIZE, DEBUG_BACKTRACE, DEBUG_THREADS. And I've found
-fsanitize=address build option great to quickly detect bad memory
access, all these things help but only get us so far, I think we still
need automated testing to detect bugs.


More information about the Bf-committers mailing list