Re: Report on Coverity

On 25/10/2012 6:05 p.m., Alex Rousskov wrote:
> On 10/24/2012 06:07 PM, Amos Jeffries wrote:
>
>> If we were to take up this scanning I think it would be more beneficial
>> to run periodically and check for new bugs rather than constantly. Once
>> per year (~100K lines of code change each year) or after any large logic
>> changes should be sufficient to check for new issues.
> I was told Coverity is pretty good at isolating new defects from the old
> ones. We have not tested those features yet, but if true, the tests
> should be integrated with Jenkins and new issues reported as they
> surface IMO, just like we do with build issues.

Yes their database of issues had timestamps for the scans in which each
issue existed which could be useful for that.

However, I don't see how that kind of tracking can be of much use to us.
The things they scan for we tend to fix immediately on discovery and
backport to all supported releases easily using our own portage system
to track where it is needed.

> With proper configuration, there should not be too much noise. We might
> even demand cleaner code during review because we would know that the
> scan will complain about known problems :-).
>
> Why wait a few months for a crash bug report from an upset admin if
> static analysis can discover the problem shortly after commit?

cost/benefit will determine that. If we can run it as easily as every
commit or two by all means run it along with the BuildFarm, it woudl be
a good addition there. If its going to cost more for more uses then we
can cope easily with less frequent scanning, like we do with the
coadvisor scans for now.

Amos
Received on Thu Oct 25 2012 - 06:25:56 MDT