|
Size: 1738
Comment:
|
Size: 5079
Comment: Make important text stand out
|
| 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: |
| * 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 exists * 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 |
How to do bug triage on the BugTracker. |
| Line 12: | Line 6: |
| == Priorities and what they mean: == | /!\ This page is intended for developers. |
| Line 14: | Line 8: |
| * critical - data loss or security issue * urgent - bug that is blocking development * bug - bug that's not blocking development * feature - it's not a bug, it's a feature * wish - would be nice |
<<TableOfContents>> |
| Line 20: | Line 10: |
| == Triage == | == Definitions == === 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 |
| Line 22: | Line 21: |
| * 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. * 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) |
=== 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 == How to do triage == === 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 {i} There is a hook installed on an hourly mirror of main that causes HgBot to update the BugTracker according to changelog commit messages. Summaries containing '(issueNNNN)' will automatically move issues to the testing state. References to `issueNNNN` in the body of the message will create references in that issue to the changeset. You can also explicitly write `closes issueNNN` or `fixes issueNNN` to move the bug into testing, or `see issueNNN` or `addressesNNN` to create a reference in the issue. === Dealing with third-party issues === If the third-party project is large enough to have its own BTS: * assign to project maintainer ``or`` add URL for proper BTS * mark the issue done-cbb For smaller projects, we'll allow using our BTS to track issues if the maintainer is a known BTS user: * assign to project maintainer * reduce priority to bug or lower * mark done-cbb if bug remains inactive For any other projects: * link to project homepage or extension page on wiki * mark the issue done-cbb === Dealing with patches on the BTS === We don't accept patches on the BTS: * they are hard to view * they are hard to comment on * they are hard to apply * only people who are nosy on an issue see them * there is no easy way to search the BTS for unapplied patches so if a patch isn't immediately applied, it is forgotten So when someone adds a patch to the BTS (which already contains a link to ContributingChanges next to the attach button!), do the following immediately so the patch doesn't sit in limbo for years: * immediately assign the bug to them * mark the issue in-progress * add a comment that says "Read http://mercurial.selenic.com/wiki/ContributingChanges" === 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
There is a hook installed on an hourly mirror of main that causes HgBot to update the BugTracker according to changelog commit messages. Summaries containing '(issueNNNN)' will automatically move issues to the testing state. References to issueNNNN in the body of the message will create references in that issue to the changeset. You can also explicitly write closes issueNNN or fixes issueNNN to move the bug into testing, or see issueNNN or addressesNNN to create a reference in the issue.
2.2. Dealing with third-party issues
If the third-party project is large enough to have its own BTS:
assign to project maintainer or add URL for proper BTS
- mark the issue done-cbb
For smaller projects, we'll allow using our BTS to track issues if the maintainer is a known BTS user:
- assign to project maintainer
- reduce priority to bug or lower
- mark done-cbb if bug remains inactive
For any other projects:
- link to project homepage or extension page on wiki
- mark the issue done-cbb
2.3. Dealing with patches on the BTS
We don't accept patches on the BTS:
- they are hard to view
- they are hard to comment on
- they are hard to apply
- only people who are nosy on an issue see them
- there is no easy way to search the BTS for unapplied patches so if a patch isn't immediately applied, it is forgotten
So when someone adds a patch to the BTS (which already contains a link to ContributingChanges next to the attach button!), do the following immediately so the patch doesn't sit in limbo for years:
- immediately assign the bug to them
- mark the issue in-progress
add a comment that says "Read http://mercurial.selenic.com/wiki/ContributingChanges"
2.4. 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.5. 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