1 NOTES ON THE EMACS BUG TRACKER -*- outline -*-
3 The Emacs Bug Tracker can be found at http://debbugs.gnu.org/
5 For a list of all bugs, see http://debbugs.gnu.org/db/pa/lemacs.html
6 (this is a static page, updated once a day)
8 ** How do I report a bug in Emacs now?
9 The same way as you always did. Send mail to bug-gnu-emacs@gnu.org,
10 or use M-x report-emacs-bug.
12 The only differences are:
14 i) Your report will be assigned a number and generate an automatic reply.
16 ii) Optionally, you can set some database parameters when you first
17 report a bug (see "Setting bug parameters" below).
19 iii) If you want to CC: someone, use X-Debbugs-CC: (this is important;
22 Once your report is filed and assigned a number, it is sent out to the
23 bug mailing list. In some cases, it may be appropriate to just file a
24 bug, without sending out a copy. To do this, send mail to
25 quiet@debbugs.gnu.org.
27 ** How do I reply to an existing bug report?
28 Reply to 123@debbugs.gnu.org, replacing 123 with the number
29 of the bug you are interested in. NB this only sends mail to the
30 bug-list, it does NOT (?) send a CC to the original bug submitter.
31 So you need to explicitly CC him/her (and anyone else you like).
33 (Many people think the submitter SHOULD be automatically subscribed
34 to subsequent discussion, but this does not seem to be implemented.
35 See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078)
37 Do NOT send a separate copy to the bug list, since this may generate a
38 new report. The only time to send mail to the bug list is to create a
41 Gnus users can add the following to message-dont-reply-to-names;
42 similarly with Rmail and rmail-dont-reply-to-names:
44 [FIXME needs updating for debbugs.gnu.org]
46 "\\(emacs-pretest-bug\\|bug-gnu-emacs\\)@gnu\\.org\\|\
47 \\(\\(submit\\|control\\|owner\\)@emacsbugs\\.\\|bug-submit-list@\\)\
50 The "bug-submit-list@donarmstrong.com" and
51 "owner@debbugs.gnu.org" entries are there because they can
52 appear in the "Resent-To" and "Resent-CC" headers, respectively. For a
53 long time Rmail erroneously included these headers in replies. If you
54 correspond with an Rmail user on a bug, these addresses may end up in
55 the Cc. Mailing to them does nothing but create duplicates and errors.
56 (It is possible you might want to have a dialog with the owner
57 address, outside of normal bug reporting.)
59 ** When reporting a bug, to send a Cc to another address
60 (e.g. bug-cc-mode@gnu.org), do NOT just use a Cc: header.
61 Instead, use "X-Debbugs-CC:". This ensures the Cc address will get a
62 mail with the bug report number in. If you do not do this, each reply
63 in the subsequent discussion will end up creating a new bug. This is
66 Note that the way this feature works is perhaps not ideal (Bug#1720).
67 If X-Debbugs-CC: was specifed by a real header, that header is removed
68 in the mail sent out to the bug list, and the addresses merged into
69 the Resent-CC header (see below). They don't appear as an explicit CC:
70 header, nor do they appear in the Reply-To: header. So people you
71 X-Debbugs-CC are not included in any following discussion unless they are
72 manually cc'd. So this feature really only serves to notify them that
73 a bug has been filed. It's then up to them to follow any subsequent
76 If X-Debbugs-CC were merged into the Reply-To header, this might work
77 more the way people expect.
79 ** How does Debbugs send out mails?
81 The mails are sent out to the bug list with From: and To: unchanged.
82 Eg if you file a bug with "submit@debbugs.gnu.org", that
83 remains in the To: address. They reach the bug list by being resent.
85 Mails arriving at the bug list have the following Resent-* headers:
87 [ FIXME needs updating for debbugs.gnu.org ]
89 Resent-From: person who submitted the bug
90 Resent-To: bug-submit-list@donarmstrong.com
91 Resent-CC: maintainer email address, plus any X-Debbugs-CC: entries
93 The "maintainer email address" is "Emacs Bugs <bug-gnu-emacs@gnu.org>"
98 Reply-To: bug submitter, 123@debbugs.gnu.org
100 ** To not get acknowledgement mail from the tracker,
101 add an "X-Debbugs-No-Ack:" header (with any value). If you use Gnus,
102 you can add an element to gnus-posting-styles to do this automatically, eg:
104 ("gnu-emacs\\(-pretest\\)?-bug"
105 ("X-Debbugs-No-Ack" "yes"))
107 (adjust the regexp according to the name you use for the bug lists)
109 ** To record a bug in the tracker without sending mail to the bug list.
110 This can be useful to make a note of something discussed on
111 emacs-devel that needs fixing. In other words, this can be the
112 equivalent of adding something to FOR-RELEASE.
114 To: quiet@debbugs.gnu.org
120 Remember to fix FOO, as discussed on emacs-devel at http://... .
122 ** Not interested in tracker control messages (tags being set, etc)?
123 Discard mails matching:
125 ^X-Emacs-PR-Message: transcript
127 When you close a bug, you get a message matching:
129 ^X-Emacs-PR-Message: closed
131 ** How to avoid multiple copies of mails.
132 When you reply to a bug, respect the Reply-To address, ie send mail
133 only to the submitter address and the numbered bug address. Do not
134 send mail direct to bug-gnu-emacs or emacs-pretest-bug unless you are
137 ** To close bug #123 (for example), send mail
139 To: 123-done@debbugs.gnu.org
141 with a brief explanation in the body as to why the bug was closed.
142 There is no need to cc the address without the "-done" part or the
143 submitter; they get copies anyway so this will just result in more
146 ** Setting bug parameters.
147 There are two ways to set the parameters of bugs in the database
148 (tags, severity level, etc). When you report a new bug, you can
149 provide a "pseudo-header" at the start of the report, eg:
155 Optionally, add a sub-package, eg Package: emacs,calendar.
156 This can include tags. Some things (e.g. submitter) don't seem to
159 Otherwise, send mail to the control server, control@debbugs.gnu.org.
160 At the start of the message body, supply the desired commands, one per
163 command bug-number [arguments]
165 quit|stop|thank|thanks|thankyou|thank you
167 The control server ignores anything after the last line above. So you
168 can place control commands at the beginning of a reply to a bug
169 report, and Bcc: the control server (note the commands have no effect
170 if you just send them to the bug-report number). Bcc: is better than Cc:
171 in case people use Reply-to-All in response.
173 Some useful control commands:
175 *** To reopen a closed bug:
178 *** Bugs can be tagged in various ways (eg wontfix, patch, etc).
179 The available tags are:
180 patch wontfix moreinfo unreproducible fixed notabug
181 Note that the list at http://debbugs.gnu.org/Developer#tags
182 is incorrect, at least for Emacs.
183 The list of tags can be prefixed with +, - or =, meaning to add (the
184 default), remove, or reset the tags. E.g.:
190 See <http://wiki.debian.org/bugs.debian.org/usertags>
192 "Usertags" are very similar to tags: a set of labels that can be added
193 to a bug. There are two differences between normal tags and user
196 1) Anyone can define any valid usertag they like. In contrast, only a
197 limited, predefined set of normal tags are available (see above).
199 2) A usertag is associated with a specific email address.
201 You set usertags in the same way as tags, by talking to the control
202 server. One difference is that you can also specify the associated
203 email address. If you don't explicitly specify an address, then it
204 will use the one from which you send the control message. The address
205 must have the form of an email address (with an "@" sign and least 4
206 characters after the "@").
210 a) In a control message:
212 user bug-gnu-emacs@gnu.org
213 usertags 1234 any-tag-you-like
215 This will add a usertag "any-tag-you-like" to bug 1234. The tag will
216 be associated with the address "bug-gnu-emacs@gnu.org". If you omit
217 the first line, the tag will be associated with your email address.
219 The syntax of the usertags command is the same as that of tags (eg wrt
220 the optional [=+-] argument).
222 b) In an initial submission, in the pseudo-header:
224 User: bug-gnu-emacs@gnu.org
227 Again, the "User" is optional.
229 *** Searching by usertags
231 The search interface is not as advanced as for normal tags. You need
232 to construct the relevant url yourself rather than just typing in a
233 search box. The only piece you really need to add is the "users"
234 portion, the rest has the same syntax as normal.
236 **** To find all bugs usertagged by a given email address:
238 http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org
240 (Supposedly, the "users" field can be a comma-separated list of more
241 than one email address, but it does not seem to work for me.)
243 **** To find bugs tagged with a specific usertag:
245 This works just like a normal tags search, but with the addition of a
248 http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org;tag=calendar
251 Eg when bad replies create a bunch of new bugs for the same report.
252 Bugs must all be in the same state (e.g. same package(s) and severity
253 -- see `reassign' and `severity' below), but need not have the same
254 tags (tags are merged). E.g.:
256 merge 123 124 125 ...
258 Note that merging does not affect titles. In particular, a "retitle"
259 of merged bugs only affects individual bugs, not all of them.
262 Like `merge', but bugs need not be in the same state. The packages
263 must still match though (see `reassign' below). The first one listed
266 forcemerge 123 124 125 ...
268 Note: you cannot merge with an archived bug - you must unarchive it first.
271 To disconnect a bug from all bugs it is merged with:
275 This command accepts only one bug number.
278 Useful when one report refers to more than one bug.
280 clone 123 -1 [-2 ...]
281 retitle -1 second bug
284 The negative numbers provide a way to refer to the cloned bugs (which
285 will be assigned proper numbers).
287 NB you cannot clone a merged bug. You'd think that trying to do so
288 would just give you an unmerged copy of the specified bug number, but no:
290 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474742
292 You must unmerge, clone, then re-merge.
295 severity 123 critical|grave|serious|important|normal|minor|wishlist
297 See http://debbugs.gnu.org/Developer#severities for the meanings.
299 *** To set the owner of a bug:
300 owner 123 A Hacker <none@example.com>
302 The shorthand `!' means your own address.
304 *** To remove the owner of a bug:
307 *** To mark a bug as fixed in a particular version:
310 *** To remove a "fixed" mark:
313 *** To assign or reassign a bug to a package or list of packages:
314 reassign 1234 emacs,cc-mode
316 ** To remove spam from the tracker, move it to the `spam' pseudo-package:
319 ** To change the title of a bug:
320 retitle 123 Some New Title
322 ** To change the submitter address:
323 submitter 123 none@example.com
325 Note that it does not seem to work to specify "Submitter:" in the
326 pseudo-header when first reporting a bug.
328 ** How does archiving work?
329 You can still send mail to a bug after it is closed. After 28 days with
330 no activity, the bug is archived, at which point no more changes can
331 be made. If you try to send mail to the bug after that (or merge with
332 it), it will be rejected. To make any changes, you must unarchive it first:
336 The bug will be re-archived after the next 28 day period of no activity.
338 ** The web-page with the list of bugs is slow to load
340 It's a function of the number of displayed bugs. You can speed things
341 up by only looking at the newest 100 bugs:
343 http://debbugs.gnu.org/cgi-bin/pkgreport.cgi?newest=100;package=emacs
345 The above page is accessible from the "Options" section at the end of
346 the "main list of bugs" page. Select bugs "in package" = emacs;
347 "newest bugs" = 100. (I have no idea how you get to that Options
348 section without having to go through the bug list page first...)
350 ** Mails to the bug tracker disappear
352 Apparently it has some kind of spam filter that sometimes silently
353 discards valid mails. Adding a subject (pointless in control messages)
358 *** When you fix a bug, it can be helpful to put the bug number in the
359 ChangeLog entry, for example:
361 * foo.el (foofunc): Fix the `foo' case. (Bug#123)
363 Then the relevant bug can be found for easy reference. If it's an
364 obvious fix (e.g. a typo), there's no need to clutter the log with the
367 Similarly, when you close a bug, it can be helpful to include the
368 relevant ChangeLog entry in the message to the bug tracker, so people
369 can see eaxctly what the fix was.
371 *** bug-reference-mode
373 Activate `bug-reference-mode' in ChangeLogs to get clickable links to
378 http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00440.html
380 ** Gnus-specific voodoo
382 *** Put point on a bug-number and try: M-x gnus-read-ephemeral-emacs-bug-group
384 *** If the above is not available:
385 (add-hook 'gnus-article-mode-hook
387 (setq bug-reference-url-format "http://debbugs.gnu.org/%s")
388 (bug-reference-mode 1)))
390 and you can click on the bug number in the subject header.