Development Resources/HOWTO/Bugzilla Use

A common question new projects ask is "how should we use Bugzilla effectively?". The Bugzilla documentation describes the basic mechanics and outlines the bug lifecycle that is designed into Bugzilla:

The Eclipse projects have different schemes for using Bugzilla, but a common one is as follows:

• Users "own": component, version, platform, OS, severity, summary, and description
• The Committers "own": status, resolution, and priority.
• Users may not change the Committer owned fields - this is enforced by social convention.
• Bugzilla provides a mechanism to watch another email address and developers are expected to use this to watch the component owner's address to monitor the incoming bugs for their projects/components.

1. At the start of each day, each project/component team lead does bug triage. He or she assesses each NEW bug:
   • Validation
     1. verify if the bug is really a bug or if it belongs to this component
     2. if the bug needs more information to be validated as a bug, add a request for more information/steps to reproduce, etc. The bug remains in the NEW state until enough information is received to validate it.
     3. if there is no response within a week, close the bug (RESOLVED INVALID or WONTFIX) telling the submitter to re-open once they have more info
     4. the bug may get moved to another component/product
     5. the bug may be a user problem, or may be intended behavior - these get annotated with the reason/information and RESOLVED to INVALID or WONTFIX or WORKSFORME (generally, INVALID means the report is just bogus, WORKSFORME means the report is not a problem, and WONTFIX is used for things that are valid requests, but that the team can't do).
     6. once a bug is validated, it goes to prioritization
   • Prioritization
     1. If the bug is a feature request, change the severity to enhancement
     2. If the bug should be fixed in the current release, the status gets changed to ASSIGNED and a target milestone is set appropriately.¹
     3. If the fix is critical, the target will be the next milestone (like 3.1M3), otherwise it will go into the general 3.1 milestone, meaning we intend to address in this release
     4. If the bug/feature will not be fixed in the current release, it is set to RESOLVED LATER
     5. Set the priority with these guidelines:
        • P1 - stop ship fix, need immediate attention
        • P2 - must fix before the release, but can make progress without fix
        • P3 - should/would like to fix for the next release
        • P4 - would be nice, but not critical, can ship without fixing
     6. The severity tags aren't used much, except to distinguish enhancements from bugs. Typically the users specify severities as they see fit.
     7. The bug will stay as ASSIGNED to the "inbox" account until a developer takes the bug, or the team lead assign it to them
2. The developers then work on the bug
   • When a developer fixes the bug, the status is set to RESOLVED - FIXED, and it is assigned to another committer on the team to verify. It is important that the verifier be a different person than the fixer because the fixer is too close to the code and thus may not be as diligent at testing the corner cases.
   • When a developer commits code, she includes the bug#(s) in the commit message.
   • It is possible for a bug to be RESOLVED WONTFIX or INVALID as well if the developer discovers that the fix is too complex/risky or that it is not really a bug
3. Verify
   • All bugs should be verified before the next integration build
   • When a committer verifies a fix, the status is changed to VERIFIED
4. When the project does a major release, the VERIFIED bugs are changed to CLOSED.

Managing Requirements

Projects should be using Bugzilla as part of their requirements process. A future version of this document will describe recommended techniques for doing so.

Writing Good Bug Reports

There are many ways to write a good bug report and even more ways to write a bad one. The community suggests that these are some of the best bug reports submitted to date:

• 22122 - in this bug, not only is the problem accurately described, but a patch is provided to our core test suites that tests various permutations of the failure condition.
• 76541 - feature request with screen cast
• 95401
• 97211
• 113206 - note the flash movie in comment #5 that illustrates the problem, complete with text overlays and pauses during the movie to illustrate the error condition.
• 114496
• 116682 - describes the expected behavior and contains a patch
• 117181 - contains build ID and simple self-contained steps to reproduce the problem in a very short time

We should all strive to emulate these authors when writing bug reports.

See also: Bug Reporting FAQ

¹Some projects do not set the target milestone here; instead they use a milestone planning meeting to set them all at once.