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"
(New page: A common question new projects ask is "how should we use Bugzilla effectively?". The [http://www.bugzilla.org/docs/2.18/html/using.html Bugzilla documentation] describes the basic mechanic...) |
|||
Line 1: | Line 1: | ||
A common question new projects ask is "how should we use Bugzilla effectively?". The [http://www.bugzilla.org/docs/2.18/html/using.html Bugzilla documentation] describes the basic mechanics and outlines the bug lifecycle that is designed into Bugzilla: | A common question new projects ask is "how should we use Bugzilla effectively?". The [http://www.bugzilla.org/docs/2.18/html/using.html Bugzilla documentation] describes the basic mechanics and outlines the bug lifecycle that is designed into Bugzilla: | ||
+ | <center> | ||
+ | [[Image:BzLifecycle.png]] | ||
+ | </center> | ||
+ | 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.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 | ||
+ | #* 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 | ||
+ | # 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: | ||
+ | * [https://bugs.eclipse.org/22122 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. | ||
+ | * [https://bugs.eclipse.org/76541 76541] - feature request with screen cast | ||
+ | * [https://bugs.eclipse.org/95401 95401] | ||
+ | * [https://bugs.eclipse.org/97211 97211] | ||
+ | * [https://bugs.eclipse.org/113206 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. | ||
+ | * [https://bugs.eclipse.org/114496 114496] | ||
+ | * [https://bugs.eclipse.org/116682 116682] - describes the expected behavior and contains a patch | ||
+ | * [https://bugs.eclipse.org/117181 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. | ||
+ | |||
+ | <references/> | ||
''This page is moderated by Anne Jacko and Bjorn Freeman-Benson (Eclipse Foundation)'' | ''This page is moderated by Anne Jacko and Bjorn Freeman-Benson (Eclipse Foundation)'' | ||
[[Category:Development_Resources]] | [[Category:Development_Resources]] | ||
[[Category:How to Contribute]] | [[Category:How to Contribute]] |
Revision as of 19:26, 25 August 2008
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.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
- 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
- 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 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
- 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.
This page is moderated by Anne Jacko and Bjorn Freeman-Benson (Eclipse Foundation)