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. There is also a dynamic
7 list, generated on request, but since there are many bug reports this
8 is slow and not recommended.
10 ** How do I report a bug in Emacs now?
11 The same way as you always did. Send mail to bug-gnu-emacs@gnu.org,
12 or use M-x report-emacs-bug.
14 The only differences are:
16 i) Your report will be assigned a number and generate an automatic reply.
18 ii) Optionally, you can set some database parameters when you first
19 report a bug (see "Setting bug parameters" below).
21 iii) If you want to CC: someone, use X-Debbugs-CC: (this is important;
24 Once your report is filed and assigned a number, it is sent out to the
25 bug mailing list. In some cases, it may be appropriate to just file a
26 bug, without sending out a copy. To do this, send mail to
27 quiet@debbugs.gnu.org.
29 ** How do I reply to an existing bug report?
30 Reply to 123@debbugs.gnu.org, replacing 123 with the number
31 of the bug you are interested in. NB this only sends mail to the
32 bug-list, it does NOT (?) send a CC to the original bug submitter.
33 So you need to explicitly CC him/her (and anyone else you like).
35 (Many people think the submitter SHOULD be automatically subscribed
36 to subsequent discussion, but this does not seem to be implemented.
37 See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078)
39 Do NOT send a separate copy to the bug list, since this may generate a
40 new report. The only time to send mail to the bug list is to create a
43 Gnus users can add the following to message-dont-reply-to-names;
44 similarly with Rmail and rmail-dont-reply-to-names:
46 "\\(emacs-pretest-bug\\|bug-gnu-emacs\\)@gnu\\.org\\|\
47 \\(submit\\|control\\|owner\\)@debbugs\\.gnu\\.org"
49 The "owner@debbugs.gnu.org" entry is there because it appears in the
50 "Resent-To" header. For a long time Rmail erroneously included such
51 headers in replies. If you correspond with an Rmail user on a bug,
52 these addresses may end up in the Cc. Mailing to them does nothing
53 but create duplicates and errors. (It is possible you might want to
54 have a dialog with the owner address, outside of normal bug
57 ** When reporting a bug, to send a Cc to another address
58 (e.g. bug-cc-mode@gnu.org), do NOT just use a Cc: header.
59 Instead, use "X-Debbugs-CC:". This ensures the Cc address will get a
60 mail with the bug report number in. If you do not do this, each reply
61 in the subsequent discussion will end up creating a new bug. This is
64 Note that the way this feature works is perhaps not ideal (Bug#1720).
65 If X-Debbugs-CC: was specifed by a real header, that header is removed
66 in the mail sent out to the bug list, and the addresses merged into
67 the Resent-CC header (see below). They don't appear as an explicit CC:
68 header, nor do they appear in the Reply-To: header. So people you
69 X-Debbugs-CC are not included in any following discussion unless they are
70 manually cc'd. So this feature really only serves to notify them that
71 a bug has been filed. It's then up to them to follow any subsequent
74 If X-Debbugs-CC were merged into the Reply-To header, this might work
75 more the way people expect.
77 ** How does Debbugs send out mails?
79 The mails are sent out to the bug list with From: and To: unchanged.
80 Eg if you file a bug with "submit@debbugs.gnu.org", that
81 remains in the To: address. They reach the bug list by being resent.
83 Mails arriving at the bug list have the following Resent-* headers:
85 Resent-From: person who submitted the bug
86 Resent-To: owner@debbugs.gnu.org
87 Resent-CC: maintainer email address, plus any X-Debbugs-CC: entries
89 The "maintainer email address" is "bug-gnu-emacs@gnu.org" in most cases.
93 Reply-To: bug submitter, 123@debbugs.gnu.org
94 Mail-Followup-To: bug submitter, 123@debbugs.gnu.org
96 ** To not get acknowledgement mail from the tracker,
97 add an "X-Debbugs-No-Ack:" header (with any value). If you use Gnus,
98 you can add an element to gnus-posting-styles to do this automatically, eg:
100 ("gnu-emacs\\(-pretest\\)?-bug"
101 ("X-Debbugs-No-Ack" "yes"))
103 (adjust the regexp according to the name you use for the bug lists)
105 ** To record a bug in the tracker without sending mail to the bug list.
106 This can be useful to make a note of something discussed on
107 emacs-devel that needs fixing. In other words, this can be the
108 equivalent of adding something to FOR-RELEASE.
110 To: quiet@debbugs.gnu.org
116 Remember to fix FOO, as discussed on emacs-devel at http://... .
118 ** Not interested in tracker control messages (tags being set, etc)?
119 Discard mails matching:
121 ^X-Emacs-PR-Message: transcript
123 When you close a bug, you get a message matching:
125 ^X-Emacs-PR-Message: closed
127 ** How to avoid multiple copies of mails.
128 When you reply to a bug, respect the Reply-To address, ie send mail
129 only to the submitter address and the numbered bug address. Do not
130 send mail direct to bug-gnu-emacs or emacs-pretest-bug unless you are
133 ** To close bug #123 (for example), send mail
135 To: 123-done@debbugs.gnu.org
137 with a brief explanation in the body as to why the bug was closed.
138 There is no need to cc the address without the "-done" part or the
139 submitter; they get copies anyway so this will just result in more
142 ** Setting bug parameters.
143 There are two ways to set the parameters of bugs in the database
144 (tags, severity level, etc). When you report a new bug, you can
145 provide a "pseudo-header" at the start of the report, eg:
151 Optionally, add a sub-package, eg Package: emacs,calendar.
152 This can include tags. Some things (e.g. submitter) don't seem to
155 Otherwise, send mail to the control server, control@debbugs.gnu.org.
156 At the start of the message body, supply the desired commands, one per
159 command bug-number [arguments]
161 quit|stop|thank|thanks|thankyou|thank you
163 The control server ignores anything after the last line above. So you
164 can place control commands at the beginning of a reply to a bug
165 report, and Bcc: the control server (note the commands have no effect
166 if you just send them to the bug-report number). Bcc: is better than Cc:
167 in case people use Reply-to-All in response.
169 Some useful control commands:
171 *** To reopen a closed bug:
174 *** Bugs can be tagged in various ways (eg wontfix, patch, etc).
175 The available tags are:
176 patch wontfix moreinfo unreproducible fixed notabug
177 Note that the list at http://debbugs.gnu.org/Developer#tags
178 is incorrect, at least for Emacs.
179 The list of tags can be prefixed with +, - or =, meaning to add (the
180 default), remove, or reset the tags. E.g.:
186 See <http://wiki.debian.org/bugs.debian.org/usertags>
188 "Usertags" are very similar to tags: a set of labels that can be added
189 to a bug. There are two differences between normal tags and user
192 1) Anyone can define any valid usertag they like. In contrast, only a
193 limited, predefined set of normal tags are available (see above).
195 2) A usertag is associated with a specific email address.
197 You set usertags in the same way as tags, by talking to the control
198 server. One difference is that you can also specify the associated
199 email address. If you don't explicitly specify an address, then it
200 will use the one from which you send the control message. The address
201 must have the form of an email address (with an "@" sign and least 4
202 characters after the "@").
206 a) In a control message:
208 user bug-gnu-emacs@gnu.org
209 usertags 1234 any-tag-you-like
211 This will add a usertag "any-tag-you-like" to bug 1234. The tag will
212 be associated with the address "bug-gnu-emacs@gnu.org". If you omit
213 the first line, the tag will be associated with your email address.
215 The syntax of the usertags command is the same as that of tags (eg wrt
216 the optional [=+-] argument).
218 b) In an initial submission, in the pseudo-header:
220 User: bug-gnu-emacs@gnu.org
223 Again, the "User" is optional.
225 *** Searching by usertags
227 The search interface is not as advanced as for normal tags. You need
228 to construct the relevant url yourself rather than just typing in a
229 search box. The only piece you really need to add is the "users"
230 portion, the rest has the same syntax as normal.
232 **** To find all bugs usertagged by a given email address:
234 http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org
236 (Supposedly, the "users" field can be a comma-separated list of more
237 than one email address, but it does not seem to work for me.)
239 **** To find bugs tagged with a specific usertag:
241 This works just like a normal tags search, but with the addition of a
244 http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org;tag=calendar
247 Eg when bad replies create a bunch of new bugs for the same report.
248 Bugs must all be in the same state (e.g. same package(s) and severity
249 -- see `reassign' and `severity' below), but need not have the same
250 tags (tags are merged). E.g.:
252 merge 123 124 125 ...
254 Note that merging does not affect titles. In particular, a "retitle"
255 of merged bugs only affects individual bugs, not all of them.
258 Like `merge', but bugs need not be in the same state. The packages
259 must still match though (see `reassign' below). The first one listed
262 forcemerge 123 124 125 ...
264 Note: you cannot merge with an archived bug - you must unarchive it first.
267 To disconnect a bug from all bugs it is merged with:
271 This command accepts only one bug number.
274 Useful when one report refers to more than one bug.
276 clone 123 -1 [-2 ...]
277 retitle -1 second bug
280 The negative numbers provide a way to refer to the cloned bugs (which
281 will be assigned proper numbers).
283 NB you cannot clone a merged bug. You'd think that trying to do so
284 would just give you an unmerged copy of the specified bug number, but no:
286 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474742
288 You must unmerge, clone, then re-merge.
291 severity 123 critical|grave|serious|important|normal|minor|wishlist
293 See http://debbugs.gnu.org/Developer#severities for the meanings.
295 *** To set the owner of a bug:
296 owner 123 A Hacker <none@example.com>
298 The shorthand `!' means your own address.
300 *** To remove the owner of a bug:
303 *** To mark a bug as fixed in a particular version:
306 *** To remove a "fixed" mark:
309 *** To assign or reassign a bug to a package or list of packages:
310 reassign 1234 emacs,cc-mode
312 ** To remove spam from the tracker, move it to the `spam' pseudo-package:
315 ** To change the title of a bug:
316 retitle 123 Some New Title
318 ** To change the submitter address:
319 submitter 123 none@example.com
321 Note that it does not seem to work to specify "Submitter:" in the
322 pseudo-header when first reporting a bug.
324 ** How does archiving work?
325 You can still send mail to a bug after it is closed. After 28 days with
326 no activity, the bug is archived, at which point no more changes can
327 be made. If you try to send mail to the bug after that (or merge with
328 it), it will be rejected. To make any changes, you must unarchive it first:
332 The bug will be re-archived after the next 28 day period of no activity.
334 ** The web-page with the list of bugs is slow to load
336 It's a function of the number of displayed bugs. You can speed things
337 up by only looking at the newest 100 bugs:
339 http://debbugs.gnu.org/cgi-bin/pkgreport.cgi?newest=100;package=emacs
341 The above page is accessible from the "Options" section at the end of
342 the "main list of bugs" page. Select bugs "in package" = emacs;
343 "newest bugs" = 100. (I have no idea how you get to that Options
344 section without having to go through the bug list page first...)
346 ** Mails to the bug tracker disappear
348 Apparently it has some kind of spam filter that sometimes silently
349 discards valid mails. Adding a subject (pointless in control messages)
354 *** When you fix a bug, it can be helpful to put the bug number in the
355 ChangeLog entry, for example:
357 * foo.el (foofunc): Fix the `foo' case. (Bug#123)
359 Then the relevant bug can be found for easy reference. If it's an
360 obvious fix (e.g. a typo), there's no need to clutter the log with the
363 Similarly, when you close a bug, it can be helpful to include the
364 relevant ChangeLog entry in the message to the bug tracker, so people
365 can see eaxctly what the fix was.
367 *** bug-reference-mode
369 Activate `bug-reference-mode' in ChangeLogs to get clickable links to
374 http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00440.html
376 ** Gnus-specific voodoo
378 *** Put point on a bug-number and try: M-x gnus-read-ephemeral-emacs-bug-group
380 *** If the above is not available:
381 (add-hook 'gnus-article-mode-hook
383 (setq bug-reference-url-format "http://debbugs.gnu.org/%s")
384 (bug-reference-mode 1)))
386 and you can click on the bug number in the subject header.
391 The following are technical notes on how it works. These are just for
392 reference, you don't need to read these as a user of the system.
394 Getting mail from the Emacs bug list into the tracker requires the
395 assistance of sysadmin at gnu.org. The test tracker set-up was, I
396 think, [gnu.org #359140]:
397 http://lists.gnu.org/archive/html/savannah-hackers/2008-03/msg00074.html
398 http://lists.gnu.org/archive/html/savannah-hackers/2008-04/msg00034.html
400 ** The debbugs.gnu.org setup was handled in [gnu.org #510605].
401 There are two pieces (replace AT with @ in the following):
403 i) fencepost has an /etc/aliases entry:
404 emacs-pretest-bug: submit AT debbugs.gnu.org
409 senders = !Debian-debbugs AT debbugs.gnu.org
410 local_parts = bug-gnu-emacs
412 data = submit AT debbugs.gnu.org
414 This says, for mail arriving at bug-gnu-emacs, only allow it through
415 to the list if it was sent from debbugs.gnu.org. Otherwise, send
416 it to the submit address at the bug-tracker.
418 FIXME There's probably an issue with the mail-news gateway here that
419 still needs to be addressed (bug#936).
421 ** fencepost's /etc/exim4/local_domains configuration needs a line
422 !debbugs.gnu.org adding [gnu.org #503532]. Otherwise people on
423 fencepost can't report bugs, since *.gnu.org addresses are assumed to
424 be handled locally on fencepost, unless otherwise specified.
426 ** All mail arriving at debbugs.gnu.org is first run through SpamAssassin.
427 Obvious spam is rejected, the rest is sent on to the moderated list
428 debbugs-submit. Approved mail is passed on to the tracker.
429 (Note this means that messages may appear out of sequence in the
430 tracker, since mail from whitelisted senders goes straight through.)
432 NOTE: An alternative to this would be to use listhelper AT nongnu.org
433 as a moderator address. Eg the emacs-bug-tracker list uses this.
434 It does basic spam processing on the moderator requests and
435 automatically rejects the obviously bogus ones. Someone still has to
436 accept the good ones though. The advantage of this would not be having
437 to run and tune our own spam filter. See
438 http://savannah.nongnu.org/projects/listhelper
440 An "X-Debbugs-Envelope-To" header is used to keep track of where the
441 mail was actually bound for:
442 http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01211.html
444 ** Mailing list recipient/sender filters.
445 The following mailman filters are useful to stop messages being
446 needlessly held for moderation:
449 (quiet|control|submit)@(debbugs\.gnu\.org|emacsbugs\.donarmstrong\.com)
450 [0-9]+(-done|-quiet|-subscribe)?@(debbugs\.gnu\.org|emacsbugs\.donarmstrong\.com)
451 (bug-gnu-emacs|emacs-pretest-bug)@gnu\.org
453 *** emacs-bug-tracker
454 sender: bug-gnu-emacs AT gnu.org
455 recipient: emacs-bug-tracker AT debbugs\.gnu\.org
457 The latter is because that is the address that debbugs actually sends to.
458 An /etc/aliases entry redirects it to the real emacs-bug-tracker address.