diff options
Diffstat (limited to 'includes/squeeze/common/doc/bug-maint-mailcontrol.txt')
| -rw-r--r-- | includes/squeeze/common/doc/bug-maint-mailcontrol.txt | 430 |
1 files changed, 0 insertions, 430 deletions
diff --git a/includes/squeeze/common/doc/bug-maint-mailcontrol.txt b/includes/squeeze/common/doc/bug-maint-mailcontrol.txt deleted file mode 100644 index 10fb802af..000000000 --- a/includes/squeeze/common/doc/bug-maint-mailcontrol.txt +++ /dev/null @@ -1,430 +0,0 @@ - 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 - affects - summary - - 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. version may be a fully - qualified version, of the form sourcepackagename/version. - - 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. - version may be a fully qualified version, of the form - sourcepackagename/version. - - 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 or greater than the highest version 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. version may be a - fully qualified version, of the form sourcepackagename/version. - - 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. version may be a fully - qualified version, of the form sourcepackagename/version. - - 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. version may be a fully qualified version, of the - form sourcepackagename/version. - - This command is equivalent to found followed by notfound (the - found removes the fixed at a particular version, and notfound - removes the found) with the exception that the bug is not - reopened if the found version is greater than any existing fixed - version. It is intended for fixing mistakes in the record of - when a bug was fixed; in most cases, you actually want found, - not notfixed. - - 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. address should - generally be a URI, or possibly an email address. Using a URI - where possible allows tools to query a remote bug tracking - system (such as bugzilla) for a bug's status. - - Example usage: - - forwarded 12345 http://bugz.illa.foo/cgi/54321 - - 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). Will also - change the titles of all bug reports which this bug is merged - with. - - 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. - - affects bugnumber [ + | - | = ] package [ package ... ] - Indicates that a bug affects another package. In the case where - bugnumber causes breakage in package even though the bug is - actually present in the package to which it is assigned, this - causes the bug to be listed by default in the package list of - package. This should generally be used where the bug is severe - enough to cause multiple reports from users to be assigned to - the wrong package. - - summary bugnumber [message number] - Selects a message to use as a summary of a bug. The first - non-pseudoheader paragraph of that message is parsed and set as - the summary of the bug which is displayed on the top of the bug - report page. This is useful in cases where the original report - doesn't correctly describe the problem or the bug has many - messages which make it difficult to identify the actual problem. - - If message number is not given, clears the summary. message - number is the message number as listed in the bugreport cgi - script output. - - 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 settings of the - first bug listed 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 ... ] [ + | - | = 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 tag following, - means to remove each tag following, - and = means to set the following tags to the list provided. - Intervening +, -, or = change the action for the tags following. - 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 - - # remove the moreinfo tag and add a patch tag - tags 123456 - moreinfo + patch - - 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, - lenny, lenny-ignore, squeeze, squeeze-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. You - should not be using unarchive to make trivial changes to - archived bugs, such as changing the submitter; its primary - purpose is to allow for the reopening of bugs which have been - archived without the intervention of BTS administrators. - - #... - 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. - __________________________________________________________________ - |