1
Introduction to the bug control and manipulation mailserver
3
In addition to the mailserver on request@bugs.debian.org which allows
4
the retrieval of bug data and documentation by email, there is another
5
server on control@bugs.debian.org which also allows bug reports to be
6
manipulated in various ways.
8
The control server works just like the request server, except that it
9
has some additional commands; in fact, it's the same program. The two
10
addresses are only separated to avoid users making mistakes and
11
causing problems while merely trying to request information.
13
Since the commands specific to the control server actually change the
14
status of a bug, a notification about processing the commands is sent
15
to the maintainer of the package(s) the changed bugs are assigned to.
16
Additionally the mail to the server and the resulting changes are
17
logged in the bug report and thereby available in the WWW pages.
19
Please see the introduction to the request server available on the
20
World Wide Web, in the file bug-log-mailserver.txt, or by sending help
21
to either mailserver, for details of the basics of operating the
22
mailservers and the common commands available when mailing either
25
The reference card for the mailservers is available via the WWW, in
26
bug-mailserver-refcard.txt or by email using the refcard command.
28
Commands available at the control mailserver
30
reassign bugnumber package [ version ]
31
Records that bug #bugnumber is a bug in package. This can be
32
used to set the package if the user forgot the pseudo-header,
33
or to change an earlier assignment. No notifications are sent
34
to anyone (other than the usual information in the processing
37
If you supply a version, the bug tracking system will note that
38
the bug affects that version of the newly-assigned package.
40
reopen bugnumber [ originator-address | = | ! ]
41
Reopens #bugnumber if it is closed.
43
By default, or if you specify =, the original submitter is
44
still as the originator of the report, so that they will get
45
the ack when it is closed again.
47
If you supply an originator-address the originator will be set
48
to the address you supply. If you wish to become the new
49
originator of the reopened report you can use the ! shorthand
50
or specify your own email address.
52
It is usually a good idea to tell the person who is about to be
53
recorded as the originator that you're reopening the report, so
54
that they will know to expect the ack which they'll get when it
57
If the bug is not closed then reopen won't do anything, not
58
even change the originator. To change the originator of an open
59
bug report, use the submitter command; note that this will
60
inform the original submitter of the change.
62
If the bug was recorded as being closed in a particular version
63
of a package but recurred in a later version, it is better to
64
use the found command instead.
66
found bugnumber [ version ]
67
Record that #bugnumber has been encountered in the given
68
version of the package to which it is assigned.
70
The bug tracking system uses this information, in conjunction
71
with fixed versions recorded when closing bugs, to display
72
lists of bugs open in various versions of each package. It
73
considers a bug to be open when it has no fixed version, or
74
when it has been found more recently than it has been fixed.
76
If no version is given, then the list of fixed versions for the
77
bug is cleared. This is identical to the behaviour of reopen.
79
This command was introduced in preference to reopen because it
80
was difficult to add a version to that command's syntax without
83
notfound bugnumber version
84
Remove the record that #bugnumber was encountered in the given
85
version of the package to which it is assigned.
87
This differs from closing the bug at that version in that the
88
bug is not listed as fixed in that version either; no
89
information about that version will be known. It is intended
90
for fixing mistakes in the record of when a bug was found.
92
submitter bugnumber originator-address | !
93
Changes the originator of #bugnumber to originator-address.
95
If you wish to become the new originator of the report you can
96
use the ! shorthand or specify your own email address.
98
While the reopen command changes the originator of other bugs
99
merged with the one being reopened, submitter does not affect
102
forwarded bugnumber address
103
Notes that bugnumber has been forwarded to the upstream
104
maintainer at address. This does not actually forward the
105
report. This can be used to change an existing incorrect
106
forwarded-to address, or to record a new one for a bug that
107
wasn't previously noted as having been forwarded.
109
notforwarded bugnumber
110
Forgets any idea that bugnumber has been forwarded to any
111
upstream maintainer. If the bug was not recorded as having been
112
forwarded then this will do nothing.
114
retitle bugnumber new-title
115
Changes the title of a bug report to that specified (the
116
default is the Subject mail header from the original report).
118
Unlike most of the other bug-manipulation commands when used on
119
one of a set of merged reports this will change the title of
120
only the individual bug requested, and not all those with which
123
severity bugnumber severity
124
Set the severity level for bug report #bugnumber to severity.
125
No notification is sent to the user who reported the bug.
127
Severities are critical, grave, serious, important, normal,
130
For their meanings please consult the general developers'
131
documentation for the bug system.
133
clone bugnumber NewID [ new IDs ... ]
134
The clone control command allows you to duplicate a bug report.
135
It is useful in the case where a single report actually
136
indicates that multiple distinct bugs have occurred. "New IDs"
137
are negative numbers, separated by spaces, which may be used in
138
subsequent control commands to refer to the newly duplicated
139
bugs. A new report is generated for each new ID.
145
retitle -1 foo: foo sucks
147
retitle -2 bar: bar sucks when used with foo
151
retitle -3 foo: foo sucks
154
merge bugnumber bugnumber ...
155
Merges two or more bug reports. When reports are merged
156
opening, closing, marking or unmarking as forwarded and
157
reassigning any of the bugs to a new package will have an
158
identical effect on all of the merged reports.
160
Before bugs can be merged they must be in exactly the same
161
state: either all open or all closed, with the same
162
forwarded-to upstream author address or all not marked as
163
forwarded, all assigned to the same package or package(s) (an
164
exact string comparison is done on the package to which the bug
165
is assigned), and all of the same severity. If they don't start
166
out in the same state you should use reassign, reopen and so
167
forth to make sure that they are before using merge. Titles are
168
not required to match, and will not be affected by the merge.
169
Tags are not required to match, either, they will be joined.
171
If any of the bugs listed in a merge command is already merged
172
with another bug then all the reports merged with any of the
173
ones listed will all be merged together. Merger is like
174
equality: it is reflexive, transitive and symmetric.
176
Merging reports causes a note to appear on each report's logs;
177
on the WWW pages this is includes links to the other bugs.
179
Merged reports are all expired simultaneously, and only when
180
all of the reports each separately meet the criteria for
183
forcemerge bugnumber bugnumber ...
184
Forcibly merges two or more bug reports. The first bug listed
185
is the master bug, and its settings (the settings which must be
186
equal in a normal merge) are assigned to the bugs listed next.
187
To avoid typos erroneously merging bugs, bugs must be in the
188
same package. See the text above for a description of what
191
Note that this makes it possible to close bugs by merging; you
192
are responsible for notifying submitters with an appropriate
193
close message if you do this.
196
Disconnects a bug report from any other reports with which it
197
may have been merged. If the report listed is merged with
198
several others then they are all left merged with each other;
199
only their associations with the bug explicitly named are
202
If many bug reports are merged and you wish to split them into
203
two separate groups of merged reports you must unmerge each
204
report in one of the new groups separately and then merge them
205
into the required new group.
207
You can only unmerge one report with each unmerge command; if
208
you want to disconnect more than one bug simply include several
209
unmerge commands in your message.
211
tags bugnumber [ + | - | = ] tag [ tag ... ]
212
Sets tags for the bug report #bugnumber. No notification is
213
sent to the user who reported the bug. Setting the action to +
214
means to add each given tag, - means to remove each given tag,
215
and = means to ignore the current tags and set them afresh to
216
the list provided. The default action is adding.
220
# same as 'tags 123456 + patch'
223
# same as 'tags 123456 + help security'
224
tags 123456 help security
226
# add 'fixed' and 'pending' tags
227
tags 123456 + fixed pending
229
# remove 'unreproducible' tag
230
tags 123456 - unreproducible
232
# set tags to exactly 'moreinfo' and 'unreproducible'
233
tags 123456 = moreinfo unreproducible
235
Available tags currently include patch, wontfix, moreinfo,
236
unreproducible, help, pending, fixed, fixed-in-experimental,
237
fixed-upstream, security, upstream, confirmed, d-i, ipv6, lfs,
238
l10n, potato, woody, sarge, sarge-ignore, etch, etch-ignore,
239
sid, and experimental.
241
For their meanings please consult the general developers'
242
documentation for the bug system.
244
block bugnumber by bug ...
245
Note that the fix for the first bug is blocked the the other
248
unblock bugnumber by bug ...
249
Note that the fix for the first bug is no longer blocked the
250
the other listed bugs.
252
close bugnumber [ fixed-version ] (deprecated)
253
Close bug report #bugnumber.
255
A notification is sent to the user who reported the bug, but
256
(in contrast to mailing bugnumber-done@bugs.debian.org) the
257
text of the mail which caused the bug to be closed is not
258
included in that notification. The maintainer who closes a
259
report needs to ensure, probably by sending a separate message,
260
that the user who reported the bug knows why it is being
261
closed. The use of this command is therefore deprecated. See
262
the developer's information about how to close a bug properly.
264
If you supply a fixed-version, the bug tracking system will
265
note that the bug was fixed in that version of the package.
267
package [ packagename ... ]
268
Limits the following commands so that they will only apply to
269
bugs filed against the listed packages. You can list one or
270
more packages. If you don't list any packages, the following
271
commands will apply to all bugs. You're encouraged to use this
272
as a safety feature in case you accidentally use the wrong bug
278
reassign 123456 bar 1.0-1
281
retitle 123456 bar: bar sucks
282
severity 123456 normal
285
severity 234567 wishlist
287
owner bugnumber address | !
288
Sets address to be the "owner" of #bugnumber. The owner of a
289
bug claims responsibility for fixing it and will receive all
290
mail regarding it. This is useful to share out work in cases
291
where a package has a team of maintainers.
293
If you wish to become the owner of the bug yourself, you can
294
use the ! shorthand or specify your own email address.
297
Forgets any idea that the bug has an owner other than the usual
298
maintainer. If the bug had no owner recorded then this will do
302
One-line comment. The # must be at the start of the line. The
303
text of comments will be included in the acknowledgement sent
304
to the sender and to affected maintainers, so you can use this
305
to document the reasons for your commands.
311
Tells the control server to stop processing the message; the
312
remainder of the message can include explanations, signatures
313
or anything else, none of it will be detected by the control
315
_________________________________________________________________
317
Debian BTS administrators <owner@bugs.debian.org>
319
Debian bug tracking system
320
Copyright � 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
321
1994-1997 Ian Jackson.
322
_________________________________________________________________
added
removed
templates/common/doc/bug-maint-mailcontrol.txt
