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.
- At the start of each day, each project/component team lead does bug triage. He or she assesses each NEW bug:
- verify if the bug is really a bug or if it belongs to this component
- 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.1
- 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
- the bug may get moved to another component/product
- 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).
- once a bug is validated, it goes to prioritization
- If the bug is a feature request, change the severity to enhancement
- If the bug should be fixed in the current release, the status gets changed to ASSIGNED and a target milestone is set appropriately.2
- 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
- If the bug/feature will not be fixed in the current release, it is set to RESOLVED LATER
- 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
- The severity tags aren't used much, except to distinguish enhancements from bugs. Typically the users specify severities as they see fit.
- The bug will stay as ASSIGNED to the "inbox" account until a developer takes the bug, or the team lead assign it to them
- 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 to LATER or WONTFIX or INVALID as well if the developer discovers that the fix is too complex/risky or that it is not really a bug
- All bugs should be verified before the next integration build
- When a committer verifies a fix, the status is changed to VERIFIED
- When the project does a major release, the VERIFIED bugs are changed to CLOSED.
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
- 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.
- 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.
This page is moderated by Anne Jacko and Bjorn Freeman-Benson (Eclipse Foundation)