diff options
Diffstat (limited to 'includes/etch/common/doc/bug-maint-mailcontrol.txt')
| -rw-r--r-- | includes/etch/common/doc/bug-maint-mailcontrol.txt | 390 |
1 files changed, 0 insertions, 390 deletions
diff --git a/includes/etch/common/doc/bug-maint-mailcontrol.txt b/includes/etch/common/doc/bug-maint-mailcontrol.txt deleted file mode 100644 index a0b7c9e..0000000 --- a/includes/etch/common/doc/bug-maint-mailcontrol.txt +++ /dev/null @@ -1,390 +0,0 @@ -Introduction to the bug control and manipulation mailserver - - Just as request@bugs.debian.org allows the retrieval of bug data and - documentation by email, control@bugs.debian.org allows bug reports to - be manipulated in various ways. - - The control server works just like the request server, except that it - has some additional commands; in fact, it's the same program. The two - addresses are only separated to avoid users making mistakes and - causing problems while merely trying to request information. - - Since the commands specific to the control server actually change the - status of a bug, a notification about processing the commands is sent - to the maintainer of the package(s) the changed bugs are assigned to. - Additionally the mail to the server and the resulting changes are - logged in the bug report and thereby available in the WWW pages. - - Please see the introduction to the request server available on the - World Wide Web, in the file bug-log-mailserver.txt, or by sending help - to either mailserver, for details of the basics of operating the - mailservers and the common commands available when mailing either - address. - - The reference card for the mailservers is available via the WWW, in - bug-mailserver-refcard.txt or by email using the refcard command. - -Commands available at the control mailserver - - General Versioning Duplicates Misc. - - reassign - severity - tag - retitle - submitter - - found | notfound - fixed | notfixed - reopen - - merge | unmerge - forcemerge - clone - - thanks - # - forwarded | notforwarded - owner | noowner - block | unblock - archive | unarchive - - reassign bugnumber package [ version ] - Records that bug #bugnumber is a bug in package. This can be - used to set the package if the user forgot the pseudo-header, - or to change an earlier assignment. No notifications are sent - to anyone (other than the usual information in the processing - transcript). - - If you supply a version, the bug tracking system will note that - the bug affects that version of the newly-assigned package. - - You can assign a bug to two packages at once by separating the - package names with a comma. However, you should only do this if - the bug can be fixed by a change to either package. If this is - not the case, you should clone the bug and reassign the clone - to the other package. - - reopen bugnumber [ originator-address | = | ! ] - Reopens #bugnumber if it is closed. - - By default, or if you specify =, the original submitter is - still as the originator of the report, so that they will get - the ack when it is closed again. - - If you supply an originator-address the originator will be set - to the address you supply. If you wish to become the new - originator of the reopened report you can use the ! shorthand - or specify your own email address. - - It is usually a good idea to tell the person who is about to be - recorded as the originator that you're reopening the report, so - that they will know to expect the ack which they'll get when it - is closed again. - - If the bug is not closed then reopen won't do anything, not - even change the originator. To change the originator of an open - bug report, use the submitter command; note that this will - inform the original submitter of the change. - - If the bug was recorded as being closed in a particular version - of a package but recurred in a later version, it is better to - use the found command instead. - - found bugnumber [ version ] - Record that #bugnumber has been encountered in the given - version of the package to which it is assigned. - - The bug tracking system uses this information, in conjunction - with fixed versions recorded when closing bugs, to display - lists of bugs open in various versions of each package. It - considers a bug to be open when it has no fixed version, or - when it has been found more recently than it has been fixed. - - If no version is given, then the list of fixed versions for the - bug is cleared. This is identical to the behaviour of reopen. - - This command will only cause a bug to be marked as not done if - no version is specified, or if the version being marked found - is equal to the version which was last marked fixed. (If you - are certain that you want the bug marked as not done, use - reopen in conjunction with found.) - - This command was introduced in preference to reopen because it - was difficult to add a version to that command's syntax without - suffering ambiguity. - - notfound bugnumber version - Remove the record that #bugnumber was encountered in the given - version of the package to which it is assigned. - - This differs from closing the bug at that version in that the - bug is not listed as fixed in that version either; no - information about that version will be known. It is intended - for fixing mistakes in the record of when a bug was found. - - fixed bugnumber version - Indicate that bug #bugnumber was fixed in the given version of - the package to which it is assigned. - - This does not cause the bug to be marked as closed, it merely - adds another version in which the bug was fixed. Use the - bugnumber-done address to close a bug and mark it fixed in a - particular version. - - notfixed bugnumber version - Remove the record that bug #bugnumber has been fixed in the - given version. - - This command is equivalent to found followed by notfound (the - found removes the fixed at a particular version, and notfound - removes the found.) - - submitter bugnumber originator-address | ! - Changes the originator of #bugnumber to originator-address. - - If you wish to become the new originator of the report you can - use the ! shorthand or specify your own email address. - - While the reopen command changes the originator of other bugs - merged with the one being reopened, submitter does not affect - merged bugs. - - forwarded bugnumber address - Notes that bugnumber has been forwarded to the upstream - maintainer at address. This does not actually forward the - report. This can be used to change an existing incorrect - forwarded-to address, or to record a new one for a bug that - wasn't previously noted as having been forwarded. - - notforwarded bugnumber - Forgets any idea that bugnumber has been forwarded to any - upstream maintainer. If the bug was not recorded as having been - forwarded then this will do nothing. - - retitle bugnumber new-title - Changes the title of a bug report to that specified (the - default is the Subject mail header from the original report). - - Unlike most of the other bug-manipulation commands when used on - one of a set of merged reports this will change the title of - only the individual bug requested, and not all those with which - it is merged. - - severity bugnumber severity - Set the severity level for bug report #bugnumber to severity. - No notification is sent to the user who reported the bug. - - Severities are critical, grave, serious, important, normal, - minor, and wishlist. - - For their meanings please consult the general developers' - documentation for the bug system. - - clone bugnumber NewID [ new IDs ... ] - The clone control command allows you to duplicate a bug report. - It is useful in the case where a single report actually - indicates that multiple distinct bugs have occurred. "New IDs" - are negative numbers, separated by spaces, which may be used in - subsequent control commands to refer to the newly duplicated - bugs. A new report is generated for each new ID. - - Example usage: - - clone 12345 -1 -2 - reassign -1 foo - retitle -1 foo: foo sucks - reassign -2 bar - retitle -2 bar: bar sucks when used with foo - severity -2 wishlist - clone 123456 -3 - reassign -3 foo - retitle -3 foo: foo sucks - merge -1 -3 - - merge bugnumber bugnumber ... - Merges two or more bug reports. When reports are merged - opening, closing, marking or unmarking as forwarded and - reassigning any of the bugs to a new package will have an - identical effect on all of the merged reports. - - Before bugs can be merged they must be in exactly the same - state: either all open or all closed, with the same - forwarded-to upstream author address or all not marked as - forwarded, all assigned to the same package or package(s) (an - exact string comparison is done on the package to which the bug - is assigned), and all of the same severity. If they don't start - out in the same state you should use reassign, reopen and so - forth to make sure that they are before using merge. Titles are - not required to match, and will not be affected by the merge. - Tags are not required to match, either, they will be joined. - - If any of the bugs listed in a merge command is already merged - with another bug then all the reports merged with any of the - ones listed will all be merged together. Merger is like - equality: it is reflexive, transitive and symmetric. - - Merging reports causes a note to appear on each report's logs; - on the WWW pages this is includes links to the other bugs. - - Merged reports are all expired simultaneously, and only when - all of the reports each separately meet the criteria for - expiry. - - forcemerge bugnumber bugnumber ... - Forcibly merges two or more bug reports. The first bug listed - is the master bug, and its settings (the settings which must be - equal in a normal merge) are assigned to the bugs listed next. - To avoid typos erroneously merging bugs, bugs must be in the - same package. See the text above for a description of what - merging means. - - Note that this makes it possible to close bugs by merging; you - are responsible for notifying submitters with an appropriate - close message if you do this. - - unmerge bugnumber - Disconnects a bug report from any other reports with which it - may have been merged. If the report listed is merged with - several others then they are all left merged with each other; - only their associations with the bug explicitly named are - removed. - - If many bug reports are merged and you wish to split them into - two separate groups of merged reports you must unmerge each - report in one of the new groups separately and then merge them - into the required new group. - - You can only unmerge one report with each unmerge command; if - you want to disconnect more than one bug simply include several - unmerge commands in your message. - - tags bugnumber [ + | - | = ] tag [ tag ... ] - Sets tags for the bug report #bugnumber. No notification is - sent to the user who reported the bug. Setting the action to + - means to add each given tag, - means to remove each given tag, - and = means to ignore the current tags and set them afresh to - the list provided. The default action is adding. - - Example usage: - - # same as 'tags 123456 + patch' - tags 123456 patch - - # same as 'tags 123456 + help security' - tags 123456 help security - - # add 'fixed' and 'pending' tags - tags 123456 + fixed pending - - # remove 'unreproducible' tag - tags 123456 - unreproducible - - # set tags to exactly 'moreinfo' and 'unreproducible' - tags 123456 = moreinfo unreproducible - - Available tags currently include patch, wontfix, moreinfo, - unreproducible, help, pending, fixed, fixed-in-experimental, - fixed-upstream, security, upstream, confirmed, d-i, ipv6, lfs, - l10n, potato, woody, sarge, sarge-ignore, etch, etch-ignore, - sid, and experimental. - - For their meanings please consult the general developers' - documentation for the bug system. - - block bugnumber by bug ... - Note that the fix for the first bug is blocked by the other - listed bugs. - - unblock bugnumber by bug ... - Note that the fix for the first bug is no longer blocked by the - other listed bugs. - - close bugnumber [ fixed-version ] (deprecated) - Close bug report #bugnumber. - - A notification is sent to the user who reported the bug, but - (in contrast to mailing bugnumber-done@bugs.debian.org) the - text of the mail which caused the bug to be closed is not - included in that notification. The maintainer who closes a - report needs to ensure, probably by sending a separate message, - that the user who reported the bug knows why it is being - closed. The use of this command is therefore deprecated. See - the developer's information about how to close a bug properly. - - If you supply a fixed-version, the bug tracking system will - note that the bug was fixed in that version of the package. - - package [ packagename ... ] - Limits the following commands so that they will only apply to - bugs filed against the listed packages. You can list one or - more packages. If you don't list any packages, the following - commands will apply to all bugs. You're encouraged to use this - as a safety feature in case you accidentally use the wrong bug - numbers. - - Example usage: - - package foo - reassign 123456 bar 1.0-1 - - package bar - retitle 123456 bar: bar sucks - severity 123456 normal - - package - severity 234567 wishlist - - owner bugnumber address | ! - Sets address to be the "owner" of #bugnumber. The owner of a - bug claims responsibility for fixing it. This is useful to - share out work in cases where a package has a team of - maintainers. - - If you wish to become the owner of the bug yourself, you can - use the ! shorthand or specify your own email address. - - noowner bugnumber - Forgets any idea that the bug has an owner other than the usual - maintainer. If the bug had no owner recorded then this will do - nothing. - - archive bugnumber - Archives a bug that had been archived at some point in the past - but is currently not archived if the bug fulfills the - requirements for archival, ignoring time. - - unarchive bugnumber - Unarchives a bug that was previously archived. Unarchival - should generally be coupled with reopen and found/fixed as - appropriate. Bugs that have been unarchived can be archived - using archive assuming the non-time based archival requirements - are met. - - #... - One-line comment. The # must be at the start of the line. The - text of comments will be included in the acknowledgement sent - to the sender and to affected maintainers, so you can use this - to document the reasons for your commands. - - quit - stop - thank - thanks - thankyou - thank you - -- - On a line by itself, in any case, possibly followed by - whitespace, tells the control server to stop processing the - message; the remainder of the message can include explanations, - signatures or anything else, none of it will be detected by the - control server. - _________________________________________________________________ - - 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. - _________________________________________________________________ - |