          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 unusable 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 (roughly, 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.

   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. For
   complete and canonical rules on what issues merit these severities,
   see the list of Release-Critical Issues for Sarge.

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. Separate
   multiple tags with commas, spaces, or both.

   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
          A solution to this bug has been found and an upload will be
          made soon.

   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.

   confirmed
          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.)

   fixed-upstream
          The bug has been fixed by the upstream maintainer, but not yet
          in the package (for whatever reason: perhaps it is too
          complicated to backport the change or too minor to be worth
          bothering).

   fixed-in-experimental
          The bug has been fixed in the package of the experimental
          distribution, but not yet in the unstable distribution.

   d-i
          This bug is relevant to the development of debian-installer. It
          is expected that this will be used when the bug affects
          installer development but is not filed against a package that
          forms a direct part of the installer itself.

   ipv6
          This bug affects support for Internet Protocol version 6.

   lfs
          This bug affects support for large files (over 2 gigabytes).

   l10n
          This bug is relevant to the localisation of the package.

   potato
          This bug particularly applies to the potato release of Debian.

   woody
          This bug particularly applies to the woody distribution.

   sarge
          This bug particularly applies to the (unreleased) sarge
          distribution.

   sarge-ignore
          This release-critical bug is to be ignored for the purposes of
          releasing sarge. This tag should only be used by the release
          manager; do not set it yourself without explicit authorization
          from him.

   sid
          This bug particularly applies to an architecture that is
          currently unreleased (that is, in the sid distribution).

   experimental
          This bug particularly applies to the experimental distribution.

   The latter five 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 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, if the bug is not already marked
   as forwarded.

   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 <owner@bugs.debian.org>
    Debian bug tracking system
    Copyright  1999 Darren O. Benham, 1994-1997 Ian Jackson, 1997
    nCipher Corporation Ltd.
   ______________________________________________________________________

