Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Development Resources/HOWTO/Bugzilla Use"
(2 intermediate revisions by 2 users not shown) | |||
Line 12: | Line 12: | ||
#* Validation | #* Validation | ||
#*# verify if the bug is really a bug or if it belongs to this component | #*# 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. | + | #*# 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. |
#*# 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 | #*# 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 get moved to another component/product | ||
Line 19: | Line 19: | ||
#* Prioritization | #* Prioritization | ||
#*# If the bug is a feature request, change the severity to enhancement | #*# 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.<sup> | + | #*# If the bug should be fixed in the current release, the status gets changed to ASSIGNED and a target milestone is set appropriately.<sup>1</sup> |
#*# 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 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 | #*# If the bug/feature will not be fixed in the current release, it is set to RESOLVED LATER | ||
Line 32: | Line 32: | ||
#* 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 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. | #* When a developer commits code, she includes the bug#(s) in the commit message. | ||
− | #* It is possible for a bug to be RESOLVED | + | #* 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 |
# Verify | # Verify | ||
#* All bugs should be verified before the next integration build | #* All bugs should be verified before the next integration build | ||
Line 55: | Line 55: | ||
We should all strive to emulate these authors when writing bug reports. | We should all strive to emulate these authors when writing bug reports. | ||
− | |||
− | |||
− | '' | + | '''See also:''' [[Bug Reporting FAQ]] |
+ | |||
+ | |||
+ | |||
+ | <sup>1</sup>Some projects do not set the target milestone here; instead they use a milestone planning meeting to set them all at once. | ||
+ | |||
+ | |||
+ | |||
[[Category:Development_Resources]] | [[Category:Development_Resources]] | ||
[[Category:How to Contribute]] | [[Category:How to Contribute]] |
Latest revision as of 10:14, 27 August 2010
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:
- Validation
- 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.
- 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
- 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.1
- 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
- Validation
- 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
- Verify
- 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.
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
1Some projects do not set the target milestone here; instead they use a milestone planning meeting to set them all at once.