diff options
| author | Andrew Hyatt | 2016-01-01 15:07:53 -0500 |
|---|---|---|
| committer | Andrew Hyatt | 2016-01-01 15:07:53 -0500 |
| commit | 222796697a6d1cae1d965df80fc42613f5fb1f89 (patch) | |
| tree | 280902cf86bbbf61224db6dee31e9f56e984aadb /admin/notes | |
| parent | ee0117c4a859f7d8c37661c60aa4736add4dd53f (diff) | |
| download | emacs-222796697a6d1cae1d965df80fc42613f5fb1f89.tar.gz emacs-222796697a6d1cae1d965df80fc42613f5fb1f89.zip | |
Add notes on bug triage procedure
* CONTRIBUTE: In section on the issue tracker, point to new triage file.
* admin/notes/triage: New file explaining triage procedure.
Diffstat (limited to 'admin/notes')
| -rw-r--r-- | admin/notes/triage | 68 |
1 files changed, 68 insertions, 0 deletions
diff --git a/admin/notes/triage b/admin/notes/triage new file mode 100644 index 00000000000..bc91b6c26f7 --- /dev/null +++ b/admin/notes/triage | |||
| @@ -0,0 +1,68 @@ | |||
| 1 | HOW TO TRIAGE EMACS BUGS -*- outline -*- | ||
| 2 | |||
| 3 | This document just describes the procedure of triaging bugs, for information on | ||
| 4 | how to work with the bug tracker, see the bugtracker file in this same directory | ||
| 5 | for the basics. You can also install the debbugs ELPA package for access to M-x | ||
| 6 | debbugs-gnu, an emacs interface to debbugs, and M-x debbugs-org, an emacs | ||
| 7 | interface via org-mode. | ||
| 8 | |||
| 9 | * Bug backlog triage procedure | ||
| 10 | |||
| 11 | The goal of this triage is to prune down the list of old bugs, closing | ||
| 12 | the ones that are not reproducible on the current release. | ||
| 13 | |||
| 14 | 1. To start, enter debbugs mode (either debbugs-gnu, debbugs-org, or via the | ||
| 15 | web browser), and accept the default list option of bugs that have severity | ||
| 16 | serious, important, or normal. | ||
| 17 | 2. This will also show closed bugs that have yet to be archived. You can | ||
| 18 | filter these out in debbugs-gnu with "x" (debbugs-gnu-toggle-suppress). | ||
| 19 | 3. For each bug, do the following: | ||
| 20 | - Read the mail thread for the bug. Find out if anyone has been able to | ||
| 21 | reproduce this on the current release. | ||
| 22 | - If someone has been able to, then your work is finished for this bug. | ||
| 23 | - Make sure there's enough information to reproduce the bug. It should be | ||
| 24 | very clear how to reproduce. If not, please ask for specific steps to | ||
| 25 | reproduce. If you don't get them, and you can't reproduce without them, | ||
| 26 | you can close as "doneunreproducible". | ||
| 27 | - If no one has mentioned being able to reproduce on the current release, | ||
| 28 | read the bug description and attempt to reproduce on an emacs started | ||
| 29 | with "emacs -Q" (the goal is to not let our personal configs interfere | ||
| 30 | with bug testing). | ||
| 31 | - If you can reproduce, then reply on the thread (either on the original | ||
| 32 | message, or anywhere you find appropriate) that you can reproduce this on | ||
| 33 | the current release. If your reproduction gives additional info (such as | ||
| 34 | a backtrace), then add that as well, since it will help whoever attempts | ||
| 35 | to fix it. | ||
| 36 | - If you can't reproduce, state that you can't reproduce it on the current | ||
| 37 | release, ask if they can try again against the current release. Tag the | ||
| 38 | bug as "unreproducable". Wait a few weeks for their reply - if they can | ||
| 39 | reproduce it, then that's great, otherwise close as "doneunreproducible". | ||
| 40 | - If the bug ends up still open, make sure the priority and other tags | ||
| 41 | seems reasonable. | ||
| 42 | 4. Your changes will take some time to take effect. After a period of minutes | ||
| 43 | to hours, you will get a mail telling you the control message has been | ||
| 44 | processed. At this point, if there were no errors detected, you and | ||
| 45 | everyone else can see your changes. If there are errors, read the error | ||
| 46 | text - if you need help, consulting the bugtracker documentation in this | ||
| 47 | same directory. | ||
| 48 | |||
| 49 | * New bug triage process | ||
| 50 | |||
| 51 | The goal of the new bug triage process is similar to the backlog triage process, | ||
| 52 | except that the focus is on prioritizing the bug, and making sure it is has | ||
| 53 | necessary information for others to act on. | ||
| 54 | |||
| 55 | For each new bug, ask the following questions: | ||
| 56 | |||
| 57 | 1. Is the bug report written in a way to be easy to reproduce (starts from | ||
| 58 | emacs -Q, etc.)? If not, ask the reporter to try and reproduce it on an | ||
| 59 | emacs without customization. | ||
| 60 | 2. Is the bug report written against the lastest emacs? If not, try to | ||
| 61 | reproduce on the latest version, and if it can't be reproduced, ask the | ||
| 62 | reporter to try again with the latest version. | ||
| 63 | 3. Is the bug the same as another bug? If so, merge the bugs. | ||
| 64 | 4. What is the priority of the bug? Add a priority: critical, grave, serious, | ||
| 65 | important, normal, minor, or wishlist. | ||
| 66 | 5. Who should be the owner? This depends on what component the bug is part | ||
| 67 | of. You can look at the admin/MAINTAINERS file (then you can just search | ||
| 68 | emacs-devel to match the name with an email address). | ||