comparison admin/notes/bugtracker @ 106995:001a0729d255

Add a quick-start guide. Add details of what happens when a bug is closed.

106994:8b0707b50290

NOTES ON THE EMACS BUG TRACKER   -*- outline -*-

The Emacs Bug Tracker can be found at http://debbugs.gnu.org/

For a list of all bugs, see http://debbugs.gnu.org/db/pa/lemacs.html
This is a static page, updated once a day.  There is also a dynamic
list, generated on request, but since there are many bug reports this
is slow and not recommended.

Remember to fix FOO, as discussed on emacs-devel at http://... .

** Not interested in tracker control messages (tags being set, etc)?
Discard mails matching:

^X-Emacs-PR-Message: transcript

When you close a bug, you get a message matching:

^X-Emacs-PR-Message: closed

** How to avoid multiple copies of mails.
If you reply to reports in the normal way, this should work fine.
Basically, reply only to the numbered bug address (and any individual
people's addresses). Do not send mail direct to bug-gnu-emacs or

with a brief explanation in the body as to why the bug was closed.
There is no need to cc the address without the "-done" part or the
submitter; they get copies anyway so this will just result in more
duplicate mail.

** Setting bug parameters.
There are two ways to set the parameters of bugs in the database
(tags, severity level, etc).  When you report a new bug, you can
provide a "pseudo-header" at the start of the report, eg:

106995:001a0729d255

NOTES ON THE EMACS BUG TRACKER   -*- outline -*-

The Emacs Bug Tracker can be found at http://debbugs.gnu.org/

* Quick-start guide

This is 95% of all you will ever need.

** How do I report a bug?
Use M-x report-emacs-bug, or send mail to [e-mail].
If you want to Cc someone, use an "X-Debbugs-CC" header instead.

** How do I comment on a bug?
Reply to a mail on the bug-gnu-emacs list in the normal way.
Or send a mail to [e-mail].

If the bug is old and closed, you may have to unarchive it first.
Send a mail to [e-mail] with
unarchive 123
on the first line of the body.

** How do I close a bug?
Send a mail to [e-mail].  In the body, explain
why the bug is being closed.

** How do I set bug meta-data?
By mailing commands to [e-mail].  Place commands at the
start of the message body, one per line.

severity 123 serious|important|normal|minor|wishlist
tags 123 moreinfo|unreproducible|wontfix|patch

* More detailed information

For a list of all bugs, see http://debbugs.gnu.org/db/pa/lemacs.html
This is a static page, updated once a day.  There is also a dynamic
list, generated on request, but since there are many bug reports this
is slow and not recommended.

Remember to fix FOO, as discussed on emacs-devel at http://... .

** Not interested in tracker control messages (tags being set, etc)?
Discard mails matching:

^X-Emacs-PR-Message: (transcript|closed)

** How to avoid multiple copies of mails.
If you reply to reports in the normal way, this should work fine.
Basically, reply only to the numbered bug address (and any individual
people's addresses). Do not send mail direct to bug-gnu-emacs or

with a brief explanation in the body as to why the bug was closed.
There is no need to cc the address without the "-done" part or the
submitter; they get copies anyway so this will just result in more
duplicate mail.

** Details of closing a bug.
(For information only)
Sending a mail to 123-done does the following:

1) Mark the bug as closed in the database.

2) Send a mail to the original submitter telling them that their bug
has been closed.  This mail has a header:

X-Emacs-PR-Message: they-closed 123

3) Send a mail to you and to the emacs-bug-tracker list confirming
that the bug has been closed.  This mail has a header:

X-Emacs-PR-Message: closed 123

4) Send a copy of your mail to the bug-gnu-emacs list in exactly the
same way as if you had sent mail to "123" (sans -done). This mail has
headers:

X-Emacs-PR-Message: cc-closed 123
Mail-Followup-To: [e-mail], ...

(This is Emacs-specific.  Normally the bug list gets the same mail as in 3).

** Setting bug parameters.
There are two ways to set the parameters of bugs in the database
(tags, severity level, etc).  When you report a new bug, you can
provide a "pseudo-header" at the start of the report, eg: