Developers' information regarding the bug processing system Initially, a bug report is submitted by a user as an ordinary mail message to submit@bugs.debian.org. This will then be given a number, acknowledged to the user, and forwarded to debian-bugs-dist. 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 nnn@bugs.debian.org. ______________________________________________________________________ * Closing bug reports * Followup messages * Severity levels * Tags for bug reports * Recording that you have passed on a bug report * Incorrectly listed package maintainers * Reopening, reassigning and manipulating bugs * More-or-less obsolete subject-scanning feature * Obsolete X-Debian-PR: quiet feature ______________________________________________________________________ Closing bug reports Debian bug reports should be closed when the problem is fixed. Problems in packages can only be considered fixed once a package that includes the bug fix enters the Debian archive. Normally, the only people that are allowed to close a bug report are the submitter of the bug and the maintainer(s) of the package against which the bug is filed. There are exceptions to this rule, for example, the bugs filed against unknown packages or certain generic pseudo-packages. When in doubt, don't close bugs, first ask for advice on the debian-devel mailing list. Bug reports should be closed by sending email to nnn-done@bugs.debian.org. The message body needs to contain an explanation of how the bug was fixed. With the emails received from the bug tracking system, all you need to do to close the bug is to make a Reply in your mail reader program and edit the To field to say nnn-done@bugs.debian.org instead of nnn@bugs (nnn-close is provided as an alias for nnn-done). The person closing the bug, the person who submitted it and the debian-bugs-closed mailing list will each get a notification about the change in status of the report. The submitter and the mailing list will also receive the contents of the message sent to nnn-done. Followup messages The bug tracking system will include the submitter's address and the bug address (nnn@bugs) in the Reply-To header after forwarding the bug report. Please note that these are two distinct addresses. If a developer wishes to reply to a bug report they should simply reply to the message, respecting the Reply-To header. This will not close the bug. The bug tracking system will receive the message at nnn@bugs, pass it on to the package maintainer, file the reply with the rest of the logs for that bug report and forward it to debian-bugs-dist. A developer may explicitly mail the bug's submitter with an email to nnn-submitter@bugs. If you wish to send a followup message which is not appropriate for debian-bugs-dist you can do so by sending it to nnn-quiet@bugs or nnn-maintonly@bugs. Mail to nnn-quiet@bugs is filed in the Bug Tracking System but is not delivered to any individuals or mailing lists. Mail to nnn-maintonly@bugs 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 to submit@bugs.debian.org. 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. The severity levels are: critical 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. grave makes the package in question unuseable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. serious is a severe violation of Debian policy (that is, it violates a "must" or "required" directive), or, in the package maintainer's opinion, makes the package unsuitable for release. important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. normal the default value, applicable to most bugs. minor a problem which doesn't affect the package's usefulness, and is presumably trivial to fix. wishlist for any feature request, and also for any bugs that are very difficult to fix due to major design considerations. fixed for bugs that are fixed but should not yet be closed. This is an exception for bugs fixed by non-maintainer uploads. Note: the "fixed" tag should be used instead. Certain severities are considered release-critical, meaning the bug will have an impact on releasing the package with the stable release of Debian. Currently, these are critical, grave and serious. 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: patch 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. wontfix 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. moreinfo 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? unreproducible This bug can't be reproduced on the maintainer's system. Assistance from third parties is needed in diagnosing the cause of the problem. help The maintainer is requesting help with dealing with this bug. pending The problem described in the bug is being actively worked on, i.e. a solution is pending. fixed This bug is fixed or worked around (by a non-maintainer upload, for example), but there's still an issue that needs to be resolved. This tag replaces the old "fixed" severity. security This bug describes a security problem in a package (e.g., bad permissions allowing access to data that shouldn't be accessible; buffer overruns allowing people to control a system in ways they shouldn't be able to; denial of service attacks that should be fixed, etc). Most security bugs should also be set at critical or grave severity. upstream This bug applies to the upstream part of the package. potato This bug particularly applies to the potato release of Debian. woody This bug particularly applies to the (unreleased) woody distribution. sid This bug particularly applies to an architecture that is currently unreleased (that is, in the sid distribution). The latter three tags are intended to be used mainly for release critical bugs, for which it's important to know which distributions are affected to make sure fixes (or removals) happen in the right place. Recording that you have passed on a bug report When a developer forwards a bug report to the developer of the upstream source package from which the Debian package is derived, they should note this in the bug tracking system as follows: Make sure that the To field of your message to the author to has only the author(s) address(es) in it; put both the person who reported the bug and nnn-forwarded@bugs.debian.org in the CC field. Ask the author to preserve the CC to nnn-forwarded@bugs when they reply, so that the bug tracking system will file their reply with the original report. 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. You can also manipulate the `forwarded to' information by sending messages to control@bugs.debian.org. Incorrectly listed package maintainers If the maintainer of a package is listed incorrectly, this is usually because the maintainer has changed recently, and the new maintainer hasn't yet uploaded a new version of the package with a changed Maintainer control file field. This will be fixed when the package is uploaded; alternatively, the archive maintainers can override the maintainer record of a package manually, for example if a rebuild and reupload of the package is not expected to be needed soon. Contact override-change@debian.org for changes to the override file. 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 and to merge and unmerge bug reports. This is done by sending mail to control@bugs.debian.org. 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 nnn@bugs. 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 nnn-whatever@bugs 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. Obsolete X-Debian-PR: quiet feature It used to be possible to prevent the bug tracking system from forwarding anywhere messages it received at debian-bugs, by putting an X-Debian-PR: quiet line in the actual mail header. This header line is now ignored. Instead, send your message to quiet or nnn-quiet (or maintonly or nnn-maintonly). _________________________________________________________________ Debian BTS administrators Debian bug tracking system Copyright © 1999 Darren O. Benham, 1994-97 Ian Jackson, 1997 nCipher Corporation Ltd, 1995 Steven Brenner. ______________________________________________________________________