Developers' information regarding the bug processing system

Initially, a bug report is submitted by a user as an ordinary mail message to submit at This will then be given a number, acknowledged to the user, and forwarded to a mailing list (if configured). If the submitter included a Package line listing a package with a known maintainer the maintainer will get a copy too.

The Subject line will have bug#nnn: added, and the Reply-To will be set to include both the submitter of the report and

Closing bug reports

A developer who receives a bug from the tracking system, or sees it on the mailing list, and takes responsibility for it should hit Reply in their favourite mailreader, and then edit the To field to say instead of (nnn-close is provided as an alias for nnn-done).

The address of the original submitter of the bug report will be included in the default To field, because the bug system included it in the Reply-To.

Where applicable, please supply a Version line in the pseudo-header of your message when closing a bug, so that the bug tracking system knows which releases of the package contain the fix.

`Done' messages are automatically forwarded to the emacs-bug-tracker mailing list, if the mailing list has been set up.

The person closing the bug and the person who submitted it will each get a notification about the change in status of the report.

Followup messages

If a developer wishes to reply to a bug report they may simply reply to the message (that will not mark the bug as done). Their reply will (by default, if they respect the Reply-To: header) go to, and to the original submitter of the bug report (note: this is two distinct addresses). The bug tracking system will receive the message at, pass it on to the package maintainer, file the reply with the rest of the logs for that bug report and forward it to a designated mailing list (owner at

A developer may explicitly mail the bug's submitter with an email to

If you wish to send a followup message which is not appropriate for any mailing list you can do so by sending it to or Mail to is filed in the bug Tracking System but is not delivered to any individuals or mailing lists. Mail to is filed in the bug Tracking System and is delivered only to the maintainer of the package in question.

Do not use the `reply to all recipients' or `followup' feature of your mailer unless you intend to edit down the recipients substantially. In particular, see that you don't send followup messages both to and to submit at, because the bug system will then get two copies of it and each one will be forwarded to the designated mailing list separately.

Severity levels

The bug system records a severity level with each bug report. This is set to normal by default, but can be overridden either by supplying a Severity line in the pseudo-header when the bug is submitted (see the instructions for reporting bugs), or by using the severity command with the control request server. Separate multiple tags with commas, spaces, or both.

The severity levels are:

makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package.
makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package.
in the package maintainer's or release manager's opinion, makes the package unsuitable for release.
a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.
the default value, for normal bugs.
a problem which doesn't affect the package's usefulness, and is presumably trivial to fix.
for any feature request, and also for any bugs that are very difficult to fix due to major design considerations.

Tags for bug reports

Each bug can have zero or more of a set of given tags. These tags are displayed in the list of bugs when you look at a package's page, and when you look at the full bug log.

Tags can be set by supplying a Tags line in the pseudo-header when the bug is submitted (see the instructions for reporting bugs), or by using the tags command with the control request server.

The current bug tags are:

A patch or some other easy procedure for fixing the bug is included in the bug logs. If there's a patch, but it doesn't resolve the bug adequately or causes some other problems, this tag should not be used.
This bug won't be fixed. Possibly because this is a choice between two arbitrary ways of doing things and the maintainer and submitter prefer different ways of doing things, possibly because changing the behaviour will cause other, worse, problems for others, or possibly for other reasons.
This bug can't be addressed until more information is provided by the submitter. The bug will be closed if the submitter doesn't provide more information in a reasonable (few months) timeframe. This is for bugs like "It doesn't work". What doesn't work?
This bug can't be reproduced on the maintainer's system. Assistance from third parties is needed in diagnosing the cause of the problem.
This bug is fixed or worked around, but there's still an issue that needs to be resolved.
This issue is not a bug.
A fix is waiting on something (e.g. a new release).
The maintainer is requesting help with dealing with this bug.
This bug describes a security problem.
The maintainer has looked at, understands, and basically agrees with the bug, but has yet to fix it. (Use of this tag is optional; it is intended mostly for maintainers who need to manage large numbers of open bugs.)
This bug should be easy to fix. For example, such bugs may be suitable for newcomers to the project to work on fixing.

Recording that you have passed on a bug report

If a developer forwards a bug report to the maintainer of some other package (e.g. a library responsible for an error in the package) that does not use this tracker, they should note this in the bug tracking system as follows:

Make sure that the To field of your message to the author has only the author(s) address(es) in it; put both the person who reported the bug, and in the CC field.

Ask the author to preserve the CC to and when they reply, so that the bug tracking system will file their reply with the original report. These messages are only filed and are not sent on; to send a message as normal, send them to as well.

When the bug tracking system gets a message at nnn-forwarded it will mark the relevant bug as having been forwarded to the address(es) in the To field of the message it gets, if the bug is not already marked as forwarded.

You can also manipulate the `forwarded to' information by sending messages to control at

Changing bug ownership

In cases where the person responsible for fixing a bug is not the assigned maintainer for the associated package (for example, when the package is maintained by a team), it may be useful to record this fact in the bug tracking system. To help with this, each bug may optionally have an owner.

The owner can be set by supplying an Owner line in the pseudo-header when the bug is submitted (see the instructions for reporting bugs), or by using the owner and noowner commands with the control request server.

Reopening, reassigning and manipulating bugs

It is possible to reassign bug reports to other packages, to reopen erroneously-closed ones, to modify the information saying to where, if anywhere, a bug report has been forwarded, to change the severities and titles of reports, to set the ownership of bugs, to merge and unmerge bug reports, and to record the versions of packages in which bugs were found and in which they were fixed. This is done by sending mail to control at

The format of these messages is described in another document available on the World Wide Web or in the file bug-maint-mailcontrol.txt. A plain text version can also be obtained by mailing the word help to the server at the address above.

More-or-less obsolete subject-scanning feature

Messages that arrive at submit or bugs whose Subject starts Bug#nnn will be treated as having been sent to This is both for backwards compatibility with mail forwarded from the old addresses, and to catch followup mail sent to submit by mistake (for example, by using reply to all recipients).

A similar scheme operates for maintonly, done, quiet and forwarded, which treat mail arriving with a Subject tag as having been sent to the corresponding address.

Messages arriving at plain forwarded and done - ie, with no bug report number in the address - and without a bug number in the Subject will be filed under `junk' and kept for a few weeks, but otherwise ignored.

Other pages:

Last modified: Thu, 31 Dec 2009 15:56:38 UTC

Debian bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.