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 "DSDP/MTJ/Proposed Bug Processing/Triage Documents"
(Introduce TM Bug Process Page) |
(Provided initial modifications to TM entries) |
||
| Line 1: | Line 1: | ||
I have taken the TM Bug Process and from http://www.eclipse.org/dsdp/tm/development/bug_process.php and pasted it here to allow us to look at it and edit it. I do not have the links from the top of their page that refelects their queries. | I have taken the TM Bug Process and from http://www.eclipse.org/dsdp/tm/development/bug_process.php and pasted it here to allow us to look at it and edit it. I do not have the links from the top of their page that refelects their queries. | ||
| + | |||
| + | Subsequent edits are an attempt to turn this into a MTJ Process. | ||
| + | I have done some editing for the wiki, but not all. I propose this page ultimately be part of our project documentation as a web page, like TM, but thought this was a good way to edit it along the way. | ||
== Bug Process == | == Bug Process == | ||
| − | + | MTJ Bug Process | |
| + | |||
| + | This documents how the Mobile Tools for the Java Platform (MTJ) Project uses Bugzilla to handle bug reports, enhancement requests, patches etc. It covers basic lifecycle information and clarifications for how to use the various Bugzilla fields. | ||
| − | + | ==Bugzilla Management== | |
Interesting Bugzilla Queries | Interesting Bugzilla Queries | ||
| − | + | (These entries have not been edited to reflect MTJ) | |
| − | + | * RSE open bugs with patches attached | |
| − | + | * RSE open P1, P2 bugs | |
| − | + | * RSE open API bugs | |
| − | + | * RSE open major or critical bugs | |
| − | + | * RSE Assigned to Inbox | |
Reports for Release Review | Reports for Release Review | ||
| − | + | (These entnries have not been edited to reflect MTJ) | |
| − | + | * RSE Report: All Bugs, Severity vs. Status | |
| − | + | * RSE Report: All Bugs, Severity vs. Resolution | |
Reports and queries needed less frequently | Reports and queries needed less frequently | ||
| + | (These entnries have not been edited to reflect MTJ) | ||
| + | * RSE Report: User-submitted Open Bugs (Committer-submitted bugs filtered out) | ||
| + | * RSE Report: All Open, Assignee vs. Priority - Helps to see who is working on high priority issues | ||
| + | * RSE Report: All Open, Reporter vs. Severity - Helps to see who found the most important bugs | ||
| + | * RSE Report: All Bugs, Reporter vs. Resolution - Helps to find reporters who frequently make invalid or duplicate reports | ||
| + | * RSE All Open Bugs | ||
| + | * RSE All Fixed Bugs | ||
| − | + | ==Bug Lifecycle== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Anybody - users and developers - may apply for a Bugzilla account and submit bug reports or enhancement requests. | |
| − | + | * Submit a new bug | |
| + | * Request an enhancement | ||
| + | * Request a new feature | ||
| − | + | Once the bug report is filed, contributors and committers work on it, including updates to bug status. All users may contribute to the discussion by adding comments (but typically not change the status fields). The Eclipse Process Guidelines contain some good information and a handy diagram for understanding the lifecycle of an issue in Bugzilla. Committers can reasign and transfer bugs to appropriate parties. Note: Bug contributions are governed by the terms and conditions in [http://www.eclipse.org/legal/termsofuse.php] | |
| − | + | ||
| − | + | ==Bug Acceptance / Triage== | |
| − | + | When a bug is enterred, it will be evaluated by .... | |
| − | + | '''Can we have an email alias as the initial recipient to the designated triage team????''' | |
| − | + | ===States used to mark bugs for action=== | |
| − | + | Use a combination of Priority and Severity. Creators can only set Severity. | |
| − | + | ||
| − | + | * Severity Values are | |
| − | + | ** blocker | |
| − | + | ** critical | |
| + | ** major | ||
| + | ** normal | ||
| + | ** minor | ||
| + | ** trivial | ||
| + | ** enhancement | ||
| + | |||
| + | |||
| + | * Priority Values are | ||
| + | ** P1 | ||
| + | ** P2 | ||
| + | ** P3 | ||
| + | ** P4 | ||
| + | ** P5 | ||
| + | |||
| + | |||
| + | * Resolution values are | ||
| + | ** FIXED | ||
| + | ** INVALID | ||
| + | ** WONTFIX | ||
| + | ** LATER | ||
| + | ** REMIND | ||
| + | ** WORKSFORME | ||
| + | |||
| + | |||
| + | ===How to defer bugs=== | ||
| + | |||
| + | Strategies for deferring bugs: | ||
| + | |||
| + | * Set the Priority according to personal judgement of importance: Even bugs with a high priority can be deferred to an upcoming release if time just dont permit fixing them. | ||
| + | * Set Resolved, Resolution=INVALID for requests that do not make sense. | ||
| + | * Set Resolved, Resolution=WONTFIX for bugs that we will supposedly never address e.g. because there is a suitable workaround or the effort is just too high although the request makes sense. | ||
| + | * Set Resolved, Resolution=LATER for bugs that make sense but are too much effort for the current release. They should be triaged again for the next release, and potentially be documented as known limitations in the release notes. | ||
| + | * Set the target milestone for bugs that we want to address in the current release cycle, but not quite the upcoming milestone. | ||
| + | * Assign bugs to the ??org.eclipse.tm.rse-inbox@eclipse.org?? if you have no idea what to do with a request and also dont know who else could handle it. It will triaged again by all committers together in the next committer meeting. | ||
How to verify and close | How to verify and close | ||
| − | + | * Bugs that are set RESOLVED are candidates for verification. | |
| − | + | * Ideally, the person who filed a bug should also verify it and set it to VERIFIED if OK. | |
| − | + | * During the final release test cycle, all RESOLVED and even VERIFIED bugs will be checked again. If they pass the test, they will be set CLOSED. | |
| − | + | * Enhancement requests and applied patches can also be set CLOSED right after checkin, especially if they do not apply to testable product functionality but rather some code cleanliness. | |
Clarification of Fields | Clarification of Fields | ||
| − | + | * Platform and OS: These should be set by the submitter of a bug to describe the platform and OS on which a bug was detected. This does not mean that the bug would occur only on this particular platform. | |
| − | + | o Use Platform All only if you have good evidence that a bug actually occurs on all platforms. | |
| − | + | o When you are sure that a bug occurs only on a particular platform, please indicate so in the Summary field by adding a tag lice [mac] or [linux] | |
| + | |||
| + | '''I would not do what is below for now. I don't thin it will help us''' | ||
| + | * Summary field: We use tags in square brackets to indicate certain categories of bugs. Please use the following tags as indication: | ||
| + | ** [api] - API problem (typically not user visible) | ||
| + | ** [apidoc] - API documentation issue | ||
| + | ** [doc] - User documentation issue | ||
| + | ** [linux] - Bug occurs on Linux only | ||
| + | ** [mac] - Bug occurs on MacOS X only | ||
| + | ** [persistence] - RSE Persistency support issue | ||
| + | ** [ssh] - Bug occurs on ssh subsystem only | ||
| + | ** [team] - RSE Team support issue | ||
| + | ** [updating] - Problem with update status of items in RSE | ||
| + | ** [windows] - Bug occurs on Windows only | ||
| + | |||
| + | ===Submitting a Patch === | ||
| − | + | ''' I would like to know if experience has added this section, and if we think it is necessary, or just the general term's and use provide this, and we can leave the committer part at the bottom''' | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | |||
Every user may submit a patch for an issue he finds, by attaching the code to the corresponding Bugzilla item. Submitting patches turns the ordinary user into a contributor, for which he or she will be given credit to. | Every user may submit a patch for an issue he finds, by attaching the code to the corresponding Bugzilla item. Submitting patches turns the ordinary user into a contributor, for which he or she will be given credit to. | ||
Please attach only patches on bugzilla for which you have the right to attach them. In the typical case, if you put a legal notice like the following alongside your contribution, it will speed up the contribution process: | Please attach only patches on bugzilla for which you have the right to attach them. In the typical case, if you put a legal notice like the following alongside your contribution, it will speed up the contribution process: | ||
Revision as of 10:39, 27 September 2006
I have taken the TM Bug Process and from http://www.eclipse.org/dsdp/tm/development/bug_process.php and pasted it here to allow us to look at it and edit it. I do not have the links from the top of their page that refelects their queries.
Subsequent edits are an attempt to turn this into a MTJ Process. I have done some editing for the wiki, but not all. I propose this page ultimately be part of our project documentation as a web page, like TM, but thought this was a good way to edit it along the way.
Contents
Bug Process
MTJ Bug Process
This documents how the Mobile Tools for the Java Platform (MTJ) Project uses Bugzilla to handle bug reports, enhancement requests, patches etc. It covers basic lifecycle information and clarifications for how to use the various Bugzilla fields.
Bugzilla Management
Interesting Bugzilla Queries (These entries have not been edited to reflect MTJ)
- RSE open bugs with patches attached
- RSE open P1, P2 bugs
- RSE open API bugs
- RSE open major or critical bugs
- RSE Assigned to Inbox
Reports for Release Review (These entnries have not been edited to reflect MTJ)
- RSE Report: All Bugs, Severity vs. Status
- RSE Report: All Bugs, Severity vs. Resolution
Reports and queries needed less frequently (These entnries have not been edited to reflect MTJ)
- RSE Report: User-submitted Open Bugs (Committer-submitted bugs filtered out)
- RSE Report: All Open, Assignee vs. Priority - Helps to see who is working on high priority issues
- RSE Report: All Open, Reporter vs. Severity - Helps to see who found the most important bugs
- RSE Report: All Bugs, Reporter vs. Resolution - Helps to find reporters who frequently make invalid or duplicate reports
- RSE All Open Bugs
- RSE All Fixed Bugs
Bug Lifecycle
Anybody - users and developers - may apply for a Bugzilla account and submit bug reports or enhancement requests.
- Submit a new bug
- Request an enhancement
- Request a new feature
Once the bug report is filed, contributors and committers work on it, including updates to bug status. All users may contribute to the discussion by adding comments (but typically not change the status fields). The Eclipse Process Guidelines contain some good information and a handy diagram for understanding the lifecycle of an issue in Bugzilla. Committers can reasign and transfer bugs to appropriate parties. Note: Bug contributions are governed by the terms and conditions in [1]
Bug Acceptance / Triage
When a bug is enterred, it will be evaluated by ....
Can we have an email alias as the initial recipient to the designated triage team????
States used to mark bugs for action
Use a combination of Priority and Severity. Creators can only set Severity.
- Severity Values are
- blocker
- critical
- major
- normal
- minor
- trivial
- enhancement
- Priority Values are
- P1
- P2
- P3
- P4
- P5
- Resolution values are
- FIXED
- INVALID
- WONTFIX
- LATER
- REMIND
- WORKSFORME
How to defer bugs
Strategies for deferring bugs:
- Set the Priority according to personal judgement of importance: Even bugs with a high priority can be deferred to an upcoming release if time just dont permit fixing them.
- Set Resolved, Resolution=INVALID for requests that do not make sense.
- Set Resolved, Resolution=WONTFIX for bugs that we will supposedly never address e.g. because there is a suitable workaround or the effort is just too high although the request makes sense.
- Set Resolved, Resolution=LATER for bugs that make sense but are too much effort for the current release. They should be triaged again for the next release, and potentially be documented as known limitations in the release notes.
- Set the target milestone for bugs that we want to address in the current release cycle, but not quite the upcoming milestone.
- Assign bugs to the ??org.eclipse.tm.rse-inbox@eclipse.org?? if you have no idea what to do with a request and also dont know who else could handle it. It will triaged again by all committers together in the next committer meeting.
How to verify and close
- Bugs that are set RESOLVED are candidates for verification.
- Ideally, the person who filed a bug should also verify it and set it to VERIFIED if OK.
- During the final release test cycle, all RESOLVED and even VERIFIED bugs will be checked again. If they pass the test, they will be set CLOSED.
- Enhancement requests and applied patches can also be set CLOSED right after checkin, especially if they do not apply to testable product functionality but rather some code cleanliness.
Clarification of Fields
- Platform and OS: These should be set by the submitter of a bug to describe the platform and OS on which a bug was detected. This does not mean that the bug would occur only on this particular platform.
o Use Platform All only if you have good evidence that a bug actually occurs on all platforms. o When you are sure that a bug occurs only on a particular platform, please indicate so in the Summary field by adding a tag lice [mac] or [linux]
I would not do what is below for now. I don't thin it will help us
- Summary field: We use tags in square brackets to indicate certain categories of bugs. Please use the following tags as indication:
- [api] - API problem (typically not user visible)
- [apidoc] - API documentation issue
- [doc] - User documentation issue
- [linux] - Bug occurs on Linux only
- [mac] - Bug occurs on MacOS X only
- [persistence] - RSE Persistency support issue
- [ssh] - Bug occurs on ssh subsystem only
- [team] - RSE Team support issue
- [updating] - Problem with update status of items in RSE
- [windows] - Bug occurs on Windows only
Submitting a Patch
I would like to know if experience has added this section, and if we think it is necessary, or just the general term's and use provide this, and we can leave the committer part at the bottom
Every user may submit a patch for an issue he finds, by attaching the code to the corresponding Bugzilla item. Submitting patches turns the ordinary user into a contributor, for which he or she will be given credit to. Please attach only patches on bugzilla for which you have the right to attach them. In the typical case, if you put a legal notice like the following alongside your contribution, it will speed up the contribution process:
Legal Message: I, {name}, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. {I am authorized by my employer to make this contribution under the EPL.} If this message does not apply for you (e.g. because you did use 3rd party materials), please contact the dsdp-tm-dev@eclipse.org Developer Mailing List to seek assistance of a committer. Once your contribution is attached to Bugzilla, a committer will pick it up and follow the Committer HOWTO guidelines to merge your contribution. code without being allowed to do so by the copyright owner).