diff options
Diffstat (limited to 'includes/squeeze/common/doc/bug-maint-info.txt')
| -rw-r--r-- | includes/squeeze/common/doc/bug-maint-info.txt | 443 |
1 files changed, 0 insertions, 443 deletions
diff --git a/includes/squeeze/common/doc/bug-maint-info.txt b/includes/squeeze/common/doc/bug-maint-info.txt deleted file mode 100644 index 332541279..000000000 --- a/includes/squeeze/common/doc/bug-maint-info.txt +++ /dev/null @@ -1,443 +0,0 @@ - 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 should 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 - or release manager'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 Lenny. - -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 is a distribution tag, which has two effects. When set on a - bug, the bug can only affect sarge (though it may also affect - other distributions if other distribution tags are set) but - otherwise normal buggy/fixed/absent rules apply. The bug also - 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 is a distribution tag, which has two effects. When set on a - bug, the bug can only affect etch (though it may also affect - other distributions if other distribution tags are set) but - otherwise normal buggy/fixed/absent rules apply. The bug also - 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. - - lenny - This is a release tag, which has two effects. When set on a bug, - the bug can only affect lenny (though it may also affect other - releases if other release tags are set) but otherwise normal - buggy/fixed/absent rules apply. The bug also should not be - archived until it is fixed in lenny. - - lenny-ignore - This release-critical bug is to be ignored for the purposes of - releasing lenny. This tag should only be used by the release - manager(s); do not set it yourself without explicit - authorization from them. - - squeeze - This is a release tag, which has two effects. When set on a bug, - the bug can only affect squeeze (though it may also affect other - releases if other release tags are set) but otherwise normal - buggy/fixed/absent rules apply. The bug also should not be - archived until it is fixed in squeeze. - - squeeze-ignore - This release-critical bug is to be ignored for the purposes of - releasing squeeze. This tag should only be used by the release - manager(s); do not set it yourself without explicit - authorization from them. - - sid - This is a release tag, which has two effects. When set on a bug, - the bug can only affect sid (though it may also affect other - releases if other release tags are set) but otherwise normal - buggy/fixed/absent rules apply. The bug also should not be - archived until it is fixed in sid. - - experimental - This is a release tag, which has two effects. When set on a bug, - the bug can only affect experimental (though it may also affect - other releases if other release tags are set) but otherwise - normal buggy/fixed/absent rules apply. The bug also should not - be archived until it is fixed in experimental. - - The meanings of the latter 8 distribution-specific tags have changed - recently; the -ignore tags ignore the bug for the purposes of testing - propagation. The release tags indicate that the bug in question should - not be archived until it is fixed in the set of releases specified. The - release tags also indicate that a bug should only be considered buggy - in the set of releases specified. [In other words, the bug is absent in - any release whose corresponding release tag is not set if any release - tags are set; otherwise the normal found/fixed rules apply.] - - Release tags should not be used if proper versioning of the bug would - achieve the desired effect, as they require manual addition and - removal. If you are unsure if a release tag is required, contact the - Debian BTS Administrators (owner@bugs.debian.org) or the release team - for advice. - -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@bugs.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. - __________________________________________________________________ - |