1 HOW TO TRIAGE EMACS BUGS -*- outline -*-
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.
9 * Bug backlog triage procedure
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.
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, we want to primarily make sure it is still
20 reproducible. A bug can and should stay open as long as it is
21 still a bug and no one has fixed it. The following is a
22 suggested checklist to follow for handling these bugs, along with
23 example replies. Closing, tagging, etc., are done
24 with debbugs control messages, which in debbugs-gnu is initiated
26 [ ] Read the mail thread for the bug. Find out if anyone has
27 been able to reproduce this on the current release. If
28 someone has been able to, then your work is finished for this
30 [ ] Make sure there's enough information to reproduce the bug.
31 It should be very clear how to reproduce. If not, please ask
32 for specific steps to reproduce. If you don't get them, and
33 you can't reproduce without them, you can close as
34 "doneunreproducible". Sometimes there is specific hardware
35 involved, such as particular models of keyboards, or it may
36 simply involve a platform you don't have access to. It's
37 fine to ignore those, and let a future triager that is better
38 equipped to reproduce it handle it.
40 An example reply asking for clear reproduction steps would be
41 something like: "Hi! In the interest of seeing whether this
42 is reproducible, and to aid anyone who will look at this bug
43 in the future, can you please give instructions on how to
44 reproduce this bug starting from an emacs without
45 configuration ("emacs -Q")?
46 [ ] If there is enough detail to reproduce, but no one has
47 mentioned being able to reproduce on the current release,
48 read the bug description and attempt to reproduce on an emacs
49 started with "emacs -Q" (the goal is to not let our personal
50 configs interfere with bug testing).
52 If you can reproduce, then reply on the thread (either on the
53 original message, or anywhere you find appropriate) that you
54 can reproduce this on the current release. If your
55 reproduction gives additional info (such as a backtrace),
56 then add that as well, since it will help whoever attempts to
59 Example reply: "I'd just like to add that I can reproduce
60 this on the latest version of Emacs, Emacs 25."
62 If you can't reproduce, state that you can't reproduce it on
63 the current release, ask if they can try again against the
64 current release. Tag the bug as "unreproducable". Wait a
65 few weeks for their reply - if they can reproduce it, then
66 that's great, otherwise close as "doneunreproducible".
68 Example reply: "I've attempted to reproduce this on the
69 latest version of emacs, Emacs 25, but haven't been able to.
70 Can you try to reproduce this on this version, and let us
71 know if you are able to? If I don't hear back in a few
72 weeks, I'll just close this bug as unreproducible."
73 [ ] Check that the priority is reasonable. Most bugs should be
74 marked as normal, but crashers and security issues can be
76 4. Your changes will take some time to take effect. After a period of minutes
77 to hours, you will get a mail telling you the control message has been
78 processed. At this point, if there were no errors detected, you and
79 everyone else can see your changes. If there are errors, read the error
80 text - if you need help, consulting the bugtracker documentation in this
83 * New bug triage process
85 The goal of the new bug triage process is similar to the backlog triage process,
86 except that the focus is on prioritizing the bug, and making sure it is has
87 necessary information for others to act on.
89 For each new bug, ask the following questions:
91 1. Is the bug report written in a way to be easy to reproduce (starts from
92 emacs -Q, etc.)? If not, ask the reporter to try and reproduce it on an
93 emacs without customization.
94 2. Is the bug report written against the latest emacs? If not, try to
95 reproduce on the latest version, and if it can't be reproduced, ask the
96 reporter to try again with the latest version.
97 3. Is the bug the same as another bug? If so, merge the bugs.
98 4. What is the priority of the bug? Add a priority: serious, important,
99 normal, minor, or wishlist.
100 5. Who should be the owner? This depends on what component the bug is part
101 of. You can look at the admin/MAINTAINERS file (then you can just search
102 emacs-devel to match the name with an email address).
104 In the debbugs-gnu buffer, bugs are marked in the "State" column
105 according to the communication flow. Red bugs mean that nobody has
106 answered, these bugs need primary attention. Green bugs flag that
107 there is a recent communication about, and orange bugs flag that the
108 bug hasn't been touched for at least two weeks.