summaryrefslogtreecommitdiff
path: root/templates/iso/doc/bug-maint-mailcontrol.txt
blob: 1167b1055b14afa0d8920e0bc76bea24187a8279 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
Introduction to the bug control and manipulation mailserver

   In addition to the mailserver on request@bugs.debian.org which allows
   the retrieval of bug data and documentation by email, there is another
   server on control@bugs.debian.org which also 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

   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.

   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 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.

   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 the the other
          listed bugs.

   unblock bugnumber by bug ...
          Note that the fix for the first bug is no longer blocked the
          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 and will receive all
          mail regarding 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.

   #...
          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...
   --...
          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.
     _________________________________________________________________