summaryrefslogtreecommitdiff
path: root/includes/common/doc/bug-maint-info.txt
diff options
context:
space:
mode:
Diffstat (limited to 'includes/common/doc/bug-maint-info.txt')
-rw-r--r--includes/common/doc/bug-maint-info.txt396
1 files changed, 0 insertions, 396 deletions
diff --git a/includes/common/doc/bug-maint-info.txt b/includes/common/doc/bug-maint-info.txt
deleted file mode 100644
index 1a450eb..0000000
--- a/includes/common/doc/bug-maint-info.txt
+++ /dev/null
@@ -1,396 +0,0 @@
-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
- * Changing bug ownership
- * Incorrectly listed package maintainers
- * Reopening, reassigning and manipulating bugs
- * Subscribing to 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.debian.org (nnn-close is provided as an alias for nnn-done).
-
- 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.
-
- 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.debian.org) 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.debian.org, 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.
-
- Sending a message to nnn-submitter@bugs.debian.org will explicitly
- email the submitter of the bug and place a copy in the Bug tracking
- system. The message will not be sent to package maintainer.
-
- 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.debian.org or nnn-maintonly@bugs.debian.org. Mail to
- nnn-quiet@bugs.debian.org is filed in the Bug Tracking System but is
- not delivered to any individuals or mailing lists. Mail to
- nnn-maintonly@bugs.debian.org 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.
-
- For more information about headers to suppress ACK messages and how to
- send carbon copies using the Bug Tracking System, see the instructions
- for reporting bugs.
-
-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 Etch.
-
-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 should not be archived until it is fixed in sarge.
-
- 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 them.
-
- etch
- This bug should not be archived until it is fixed in etch.
-
- etch-ignore
- This release-critical bug is to be ignored for the purposes of
- releasing etch. This tag should only be used by the release
- manager; do not set it yourself without explicit authorization
- from them.
-
- sid
- This bug should not be archived until it is fixed in sid.
-
- experimental
- This bug should not be archived until it is fixed in
- experimental.
-
- The meanings of the latter 6 tags have changed recently; the ignore
- tags ignore the bug for the purpose of a testing propagation. The
- release tags, which used to indicate which bugs affected a specific
- release now indicate when a bug can be archived.
-
-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 the person who reported the bug,
- nnn-forwarded@bugs.debian.org and nnn@bugs.debian.org in the CC field.
-
- Ask the author to preserve the CC to nnn-forwarded@bugs.debian.org
- 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 nnn@bugs.debian.org
- 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@bugs.debian.org.
-
-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.
-
-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, 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@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.
-
-Subscribing to bugs
-
- The bug tracking system also allows bug submitters, developers and
- other interested third parties to subscribe to individual bugs. This
- feature can be used by those wishing to keep an eye on a bug, without
- having to subscribe to a package through the PTS. All messages that
- are received at nnn@debian.org, are sent to subscribers.
-
- Subscribing to a bug can be done by sending an email to
- nnn-subscribe@bugs.debian.org. The subject and body of the email are
- ignored by the BTS. Once this message is processed, users are sent a
- confirmation message that they will need to reply to before they are
- sent the messages relating to that bug.
-
- It is also possible to unsubscribe from a bug. Unsubscribing can be
- done by sending an email to nnn-unsubscribe@bugs.debian.org. The
- subject and body of the email are again ignored by the BTS. Users will
- be sent a confirmation message which they must reply to if they wish
- to be unsubscribed from the bug.
-
- By default, the address subscribed is the one found in the From
- header. If you wish to subscribe another address to a bug, you will
- need to encode the address to be subscribed into the subscription
- message. This takes the form of:
- nnn-subscribe-localpart=example.com@bugs.debian.org. That example
- would send localpart@example.com a subscription message for bug nnn.
- The @ sign must be encoded by changing it to an = sign. Similarly, an
- unsubscription takes the form
- nnn-unsubscribe-localpart=example.com@bugs.debian.org. In both cases,
- the subject and body of the email will be forwarded to the email
- address within the request for confirmation.
-
-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.debian.org. 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.debian.org 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, 1997, 2003 nCipher Corporation Ltd,
- 1994-1997 Ian Jackson.
- _________________________________________________________________
-