diff options
Diffstat (limited to 'includes/lenny/common/doc/bug-maint-mailcontrol.txt')
| -rw-r--r-- | includes/lenny/common/doc/bug-maint-mailcontrol.txt | 390 |
1 files changed, 390 insertions, 0 deletions
diff --git a/includes/lenny/common/doc/bug-maint-mailcontrol.txt b/includes/lenny/common/doc/bug-maint-mailcontrol.txt new file mode 100644 index 0000000..a0b7c9e --- /dev/null +++ b/includes/lenny/common/doc/bug-maint-mailcontrol.txt @@ -0,0 +1,390 @@ +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. + _________________________________________________________________ + |