|
Size: 1506
Comment:
|
Size: 3358
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Bug statuses and what they mean: == | #pragma section-numbers 2 = Managing Bugs = |
| Line 3: | Line 4: |
| How to do bug triage on the BugTracker. /!\ This page is intended for developers. <<TableOfContents>> == Definitions == === Status levels: === |
|
| Line 7: | Line 16: |
| * In-progress - a partial fix exists * Testing - a patch is merged, but poster has not confirmed it works |
* In-progress - a partial fix exist or fix exists but isn't yet integrated * Testing - a patch is merged, but poster has not confirmed it works, or it didn't reach the main repo yet |
| Line 10: | Line 19: |
| * Resolved - problem is fixed | * Resolved - problem is fixed or was not a bug |
| Line 12: | Line 21: |
| == Priorities and what they mean: == |
=== Priorities === |
| Line 15: | Line 23: |
| * urgent - bug that is blocking development | * urgent - bug that's blocking development or is a regression |
| Line 20: | Line 28: |
| == Triage == | == How to do triage == |
| Line 22: | Line 30: |
| Here's a useful [http://www.selenic.com/mercurial/bts/issue?@columns=title,id,activity,status,assignedto&@sort=status,activity&@group=priority&@filter=status,priority,status,priority&@pagesize=100&@startwith=0&status=-1,1,3,5&priority=1,2,3&@dispname=triage triage query] | === Handling Individual Bugs === |
| Line 24: | Line 32: |
| * Sort open issues by priority and activity * Diagnose issues and add appropriate people to the nosy list * Merge duplicates by setting superseder in the more recent bug, copy its nosy list to the older bug, and add a pointer to the new issue in the old issue if it contains new info * Improve bug titles to be more informative * Add appropriate categories * Set appropriate priorities (eg degrade urgent issues with workarounds to bug) |
* Get diagnostics first, give suggestions later (see [[Advice]]) * Respond to new bugs as quickly as possible, especially where more info would be useful * Make sure its priority is set appropriately * Make sure its title is useful (ie convert commands should mention the backend) * Add appropriate developers to nosey * Add appropriate topics * If it is a common issue, mark it as a duplicate * Bugs that have long been fixed in main should be marked resolved * Bugs that have been marked 'testing' can be marked resolved after two weeks if the user doesn't confirm earlier * Bugs that have recently accepted patches should be marked testing * Bugs with active work, including patches that aren't in main should be marked in progress * Bugs that require more info from the user should be marked need-eg * Bugs that remain in the need-eg state for an extended period may be closed * Features and wishes that have been decided against should move to done-cbb {i} Commits summaries containing '(issueNNNN)' will automatically move issues to the testing state. === Marking Duplicates === * Choose whichever bug is resolved (or has a clear description) as the master * Set superseder on the duplicate to point to the master, add a note, and set the bug as resolved * If the master is not resolved, copy the nosy list from the duplicate and add a message pointing back to 'issueXXX' === Reducing Backlog === * Close out bugs that have been in testing and need-eg state too long * Similarly, check if bugs marked in-progress are really in-progress * Sort open issues by priority and activity - here is a [[http://www.selenic.com/mercurial/bts/issue?@columns=title,id,activity,status,assignedto&@sort=status,activity&@group=priority&@filter=status,priority,status,priority&@pagesize=100&@startwith=0&status=-1,1,3,5&priority=1,2,3&@dispname=triage|triage]] and a [[http://www.selenic.com/mercurial/bts/issue?@columns=title,id,activity,priority,status&@sort=activity&@filter=status&@pagesize=100&@startwith=0&status=-1,1,2,3,4,5,6,7&@dispname=unloved|unloved]] query * Degrade long-standing bugs to features and features to wishes where appropriate == See also == * WritingTests ---- CategoryBugs CategoryDeveloper CategoryProcess |
Managing Bugs
How to do bug triage on the BugTracker.
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
This page is intended for developers.
Contents
1. Definitions
1.1. Status levels:
- Unread - no one's ever responded to this bug (bad)
- Deferred - we've decided not to deal with this problem now
- Chatting - we're discussing a solution
- Need-eg - we need more information to progress
- In-progress - a partial fix exist or fix exists but isn't yet integrated
- Testing - a patch is merged, but poster has not confirmed it works, or it didn't reach the main repo yet
- Done-cbb - (could be better or couldn't be bothered) not perfect, but we've done as much as we're going to do
- Resolved - problem is fixed or was not a bug
1.2. Priorities
- critical - data loss or security issue
- urgent - bug that's blocking development or is a regression
- bug - bug that's not blocking development
- feature - it's not a bug, it's a feature
- wish - would be nice
2. How to do triage
2.1. Handling Individual Bugs
Get diagnostics first, give suggestions later (see Advice)
- Respond to new bugs as quickly as possible, especially where more info would be useful
- Make sure its priority is set appropriately
- Make sure its title is useful (ie convert commands should mention the backend)
- Add appropriate developers to nosey
- Add appropriate topics
- If it is a common issue, mark it as a duplicate
- Bugs that have long been fixed in main should be marked resolved
- Bugs that have been marked 'testing' can be marked resolved after two weeks if the user doesn't confirm earlier
- Bugs that have recently accepted patches should be marked testing
- Bugs with active work, including patches that aren't in main should be marked in progress
- Bugs that require more info from the user should be marked need-eg
- Bugs that remain in the need-eg state for an extended period may be closed
- Features and wishes that have been decided against should move to done-cbb
Commits summaries containing '(issueNNNN)' will automatically move issues to the testing state.
2.2. Marking Duplicates
- Choose whichever bug is resolved (or has a clear description) as the master
- Set superseder on the duplicate to point to the master, add a note, and set the bug as resolved
- If the master is not resolved, copy the nosy list from the duplicate and add a message pointing back to 'issueXXX'
2.3. Reducing Backlog
- Close out bugs that have been in testing and need-eg state too long
- Similarly, check if bugs marked in-progress are really in-progress
Sort open issues by priority and activity - here is a triage and a unloved query
- Degrade long-standing bugs to features and features to wishes where appropriate