Revision 1 as of 2011-12-16 18:36:52

Clear message


The product strategy team in side of Canonical has licensed Coverity to help increase the quality of various projects that we are working on. Each commit to the trunk of the projects that fall under the Unity umbrella will be scanned by the Coverity Static Analyzer to determine defects in the codebase. These defects can range from NULL pointer dereferencing to more complex memory issues.

Coverity is a proprietary tool that we unfortunately can't distribute to the community, but we have built tools to publish the information that Coverity provides in Launchpad so that everyone in the greater Unity community can see the results of the runs. We expect both Canonical developers and community developers' primary interaction with Coverity to be through the Launchpad bugs, but Canonical developers do have access to the server itself. If someone in the community does need more information that isn't exported on a bug, please contact a Canonical developer and we'd be happy to get that for you. If you believe that a piece of information should consistently be exported and you know Python, patches to the sync script are welcome as well.

Bugs in Launchpad

Coverity tracks a specific issue through a variety of transformations that it could go through. This includes through difference series of the code base, or as the code moves throughout the project. It also merges defects from discrete series into a single bug.


We're using a variety of bug tags to give extra information about the bug and how it relates to Coverity.

  • coverity -- this tag marks the bug as being found by the Coverity static analyzer

  • coverity-checker-* -- there are a variety of different checks that the analyzer does, and each of them is named by the type of error that it finds. These tags mark the type of error that Coverity has found and can be used for filtering bugs.


We use the description field to give quick information about the issue that Coverity found and some structured data to be able to track back to the Coverity tracker. One of the fields there is the CID, which is the Coverity Unique ID in the Coverity tracker. This is irrelevant except for tracking back to the Coverity database, which could sometimes be required.


The Coverity sync tool will create new bugs with status of "New". It is expected that the developers on the project will adjust the status to track the bug all the way through to the "In Progress" state. When there is a commit to the trunk of the project and Coverity is able to verify the fix it will set the state to "Fix Committed". It is expected that the release manager for the project would then move the status of the bug to "Fix Released" when the bug is released by the project. If Coverity detects that a bug has reemerged in the codebase it will change it from "Fixed *" back to "New."


The priority is the bug is set initially by the script using a set of metrics based on the checker as provided by Coverity. Mostly this relates to the severity of what happens when the bug is hit. The Coverity sync script does not change the severity if it is modified by developers, it is expected they may reprioritize based on area of code or whether this bug is important to the development team.


On each bug there are also several attachments which provide more information about the error that Coverity has found. This can include things like extra information on which conditionals are being used and where there are perhaps other errors that may contribute. These are largely free form in their description of the error and designed to provide more information to the developer. Individual developers may prefer to use this information differently.

Tasks and Series

Coverity will look to understand which series of the project that it is parsing and can link the various defects across those series. It will maintain the status on the series target for the bug.