summaryrefslogtreecommitdiff
path: root/includes/lenny/common/doc/bug-maint-mailcontrol.txt
diff options
context:
space:
mode:
Diffstat (limited to 'includes/lenny/common/doc/bug-maint-mailcontrol.txt')
-rw-r--r--includes/lenny/common/doc/bug-maint-mailcontrol.txt391
1 files changed, 0 insertions, 391 deletions
diff --git a/includes/lenny/common/doc/bug-maint-mailcontrol.txt b/includes/lenny/common/doc/bug-maint-mailcontrol.txt
deleted file mode 100644
index 56ddd08c0..000000000
--- a/includes/lenny/common/doc/bug-maint-mailcontrol.txt
+++ /dev/null
@@ -1,391 +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,
- 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.
-
- #...
- 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.
- _________________________________________________________________
-