1
Developers' information regarding the bug processing system
1
3
Initially, a bug report is submitted by a user as an ordinary mail
2
4
message to submit@bugs.debian.org. This will then be given a number,
3
5
acknowledged to the user, and forwarded to debian-bugs-dist. If the
4
6
submitter included a Package line listing a package with a known
5
7
maintainer the maintainer will get a copy too.
7
The Subject line will have Bug#nnn: added, and the Reply-To will be set
8
to include both the submitter of the report and nnn@bugs.debian.org.
9
__________________________________________________________________
9
The Subject line will have Bug#nnn: added, and the Reply-To will be
10
set to include both the submitter of the report and
12
_________________________________________________________________
11
14
* Closing bug reports
12
15
* Followup messages
19
22
* Subscribing to bugs
20
23
* More-or-less obsolete subject-scanning feature
21
24
* Obsolete X-Debian-PR: quiet feature
22
__________________________________________________________________
25
_________________________________________________________________
24
27
Closing bug reports
26
Debian bug reports should be closed when the problem is fixed. Problems
27
in packages can only be considered fixed once a package that includes
28
the bug fix enters the Debian archive.
29
Debian bug reports should be closed when the problem is fixed.
30
Problems in packages can only be considered fixed once a package that
31
includes the bug fix enters the Debian archive.
30
33
Normally, the only people that should close a bug report are the
31
submitter of the bug and the maintainer(s) of the package against which
32
the bug is filed. There are exceptions to this rule, for example, the
33
bugs filed against unknown packages or certain generic pseudo-packages.
34
When in doubt, don't close bugs, first ask for advice on the
35
debian-devel mailing list.
34
submitter of the bug and the maintainer(s) of the package against
35
which the bug is filed. There are exceptions to this rule, for
36
example, the bugs filed against unknown packages or certain generic
37
pseudo-packages. When in doubt, don't close bugs, first ask for advice
38
on the debian-devel mailing list.
37
40
Bug reports should be closed by sending email to
38
41
nnn-done@bugs.debian.org. The message body needs to contain an
131
134
difficult to fix due to major design considerations.
133
136
Certain severities are considered release-critical, meaning the bug
134
will have an impact on releasing the package with the stable release of
135
Debian. Currently, these are critical, grave and serious. For complete
136
and canonical rules on what issues merit these severities, see the list
137
of Release-Critical Issues for Lenny.
137
will have an impact on releasing the package with the stable release
138
of Debian. Currently, these are critical, grave and serious. For
139
complete and canonical rules on what issues merit these severities,
140
see the list of Release-Critical Issues for Lenny.
139
142
Tags for bug reports
143
146
when you look at the full bug log.
145
148
Tags can be set by supplying a Tags line in the pseudo-header when the
146
bug is submitted (see the instructions for reporting bugs), or by using
147
the tags command with the control request server. Separate multiple
148
tags with commas, spaces, or both.
149
bug is submitted (see the instructions for reporting bugs), or by
150
using the tags command with the control request server. Separate
151
multiple tags with commas, spaces, or both.
150
153
The current bug tags are:
159
162
This bug won't be fixed. Possibly because this is a choice
160
163
between two arbitrary ways of doing things and the maintainer
161
164
and submitter prefer different ways of doing things, possibly
162
because changing the behaviour will cause other, worse, problems
163
for others, or possibly for other reasons.
165
because changing the behaviour will cause other, worse,
166
problems for others, or possibly for other reasons.
166
169
This bug can't be addressed until more information is provided
167
170
by the submitter. The bug will be closed if the submitter
168
171
doesn't provide more information in a reasonable (few months)
169
timeframe. This is for bugs like "It doesn't work". What doesn't
172
timeframe. This is for bugs like "It doesn't work". What
173
176
This bug can't be reproduced on the maintainer's system.
264
This is a release tag, which has two effects. When set on a bug,
265
the bug can only affect lenny (though it may also affect other
266
releases if other release tags are set) but otherwise normal
267
buggy/fixed/absent rules apply. The bug also should not be
268
archived until it is fixed in lenny.
267
This is a release tag, which has two effects. When set on a
268
bug, the bug can only affect lenny (though it may also affect
269
other releases if other release tags are set) but otherwise
270
normal buggy/fixed/absent rules apply. The bug also should not
271
be archived until it is fixed in lenny.
271
274
This release-critical bug is to be ignored for the purposes of
274
277
authorization from them.
277
This is a release tag, which has two effects. When set on a bug,
278
the bug can only affect squeeze (though it may also affect other
279
releases if other release tags are set) but otherwise normal
280
buggy/fixed/absent rules apply. The bug also should not be
281
archived until it is fixed in squeeze.
280
This is a release tag, which has two effects. When set on a
281
bug, the bug can only affect squeeze (though it may also affect
282
other releases if other release tags are set) but otherwise
283
normal buggy/fixed/absent rules apply. The bug also should not
284
be archived until it is fixed in squeeze.
284
287
This release-critical bug is to be ignored for the purposes of
287
290
authorization from them.
290
This is a release tag, which has two effects. When set on a bug,
291
the bug can only affect sid (though it may also affect other
292
releases if other release tags are set) but otherwise normal
293
buggy/fixed/absent rules apply. The bug also should not be
294
archived until it is fixed in sid.
293
This is a release tag, which has two effects. When set on a
294
bug, the bug can only affect sid (though it may also affect
295
other releases if other release tags are set) but otherwise
296
normal buggy/fixed/absent rules apply. The bug also should not
297
be archived until it is fixed in sid.
297
This is a release tag, which has two effects. When set on a bug,
298
the bug can only affect experimental (though it may also affect
299
other releases if other release tags are set) but otherwise
300
normal buggy/fixed/absent rules apply. The bug also should not
301
be archived until it is fixed in experimental.
303
The meanings of the latter 8 distribution-specific tags have changed
304
recently; the -ignore tags ignore the bug for the purposes of testing
305
propagation. The release tags indicate that the bug in question should
306
not be archived until it is fixed in the set of releases specified. The
307
release tags also indicate that a bug should only be considered buggy
308
in the set of releases specified. [In other words, the bug is absent in
309
any release whose corresponding release tag is not set if any release
310
tags are set; otherwise the normal found/fixed rules apply.]
312
Release tags should not be used if proper versioning of the bug would
313
achieve the desired effect, as they require manual addition and
314
removal. If you are unsure if a release tag is required, contact the
315
Debian BTS Administrators (owner@bugs.debian.org) or the release team
300
This is a release tag, which has two effects. When set on a
301
bug, the bug can only affect experimental (though it may also
302
affect other releases if other release tags are set) but
303
otherwise normal buggy/fixed/absent rules apply. The bug also
304
should not be archived until it is fixed in experimental.
306
The meanings of the latter 8 tags have changed recently; the ignore
307
tags ignore the bug for the purpose of a testing propagation. The
308
release tags, which used to only indicate which bugs affected a
309
specific release, now indicate when a bug can be archived and the set
310
of releases for which a bug can be considered to be found or fixed.
318
312
Recording that you have passed on a bug report
320
When a developer forwards a bug report to the developer of the upstream
321
source package from which the Debian package is derived, they should
322
note this in the bug tracking system as follows:
314
When a developer forwards a bug report to the developer of the
315
upstream source package from which the Debian package is derived, they
316
should note this in the bug tracking system as follows:
324
318
Make sure that the To field of your message to the author has only the
325
319
author(s) address(es) in it; put the person who reported the bug,
326
320
nnn-forwarded@bugs.debian.org and nnn@bugs.debian.org in the CC field.
328
Ask the author to preserve the CC to nnn-forwarded@bugs.debian.org when
329
they reply, so that the bug tracking system will file their reply with
330
the original report. These messages are only filed and are not sent on;
331
to send a message as normal, send them to nnn@bugs.debian.org as well.
322
Ask the author to preserve the CC to nnn-forwarded@bugs.debian.org
323
when they reply, so that the bug tracking system will file their reply
324
with the original report. These messages are only filed and are not
325
sent on; to send a message as normal, send them to nnn@bugs.debian.org
333
328
When the bug tracking system gets a message at nnn-forwarded it will
334
329
mark the relevant bug as having been forwarded to the address(es) in
367
362
It is possible to reassign bug reports to other packages, to reopen
368
363
erroneously-closed ones, to modify the information saying to where, if
369
anywhere, a bug report has been forwarded, to change the severities and
370
titles of reports, to set the ownership of bugs, to merge and unmerge
371
bug reports, and to record the versions of packages in which bugs were
372
found and in which they were fixed. This is done by sending mail to
373
control@bugs.debian.org.
364
anywhere, a bug report has been forwarded, to change the severities
365
and titles of reports, to set the ownership of bugs, to merge and
366
unmerge bug reports, and to record the versions of packages in which
367
bugs were found and in which they were fixed. This is done by sending
368
mail to control@bugs.debian.org.
375
The format of these messages is described in another document available
376
on the World Wide Web or in the file bug-maint-mailcontrol.txt. A plain
377
text version can also be obtained by mailing the word help to the
378
server at the address above.
370
The format of these messages is described in another document
371
available on the World Wide Web or in the file
372
bug-maint-mailcontrol.txt. A plain text version can also be obtained
373
by mailing the word help to the server at the address above.
380
375
Subscribing to bugs
382
377
The bug tracking system also allows bug submitters, developers and
383
378
other interested third parties to subscribe to individual bugs. This
384
379
feature can be used by those wishing to keep an eye on a bug, without
385
having to subscribe to a package through the PTS. All messages that are
386
received at nnn@bugs.debian.org, are sent to subscribers.
380
having to subscribe to a package through the PTS. All messages that
381
are received at nnn@bugs.debian.org, are sent to subscribers.
388
383
Subscribing to a bug can be done by sending an email to
389
384
nnn-subscribe@bugs.debian.org. The subject and body of the email are
394
389
It is also possible to unsubscribe from a bug. Unsubscribing can be
395
390
done by sending an email to nnn-unsubscribe@bugs.debian.org. The
396
391
subject and body of the email are again ignored by the BTS. Users will
397
be sent a confirmation message which they must reply to if they wish to
398
be unsubscribed from the bug.
392
be sent a confirmation message which they must reply to if they wish
393
to be unsubscribed from the bug.
400
By default, the address subscribed is the one found in the From header.
401
If you wish to subscribe another address to a bug, you will need to
402
encode the address to be subscribed into the subscription message. This
403
takes the form of: nnn-subscribe-localpart=example.com@bugs.debian.org.
404
That example would send localpart@example.com a subscription message
405
for bug nnn. The @ sign must be encoded by changing it to an = sign.
406
Similarly, an unsubscription takes the form
395
By default, the address subscribed is the one found in the From
396
header. If you wish to subscribe another address to a bug, you will
397
need to encode the address to be subscribed into the subscription
398
message. This takes the form of:
399
nnn-subscribe-localpart=example.com@bugs.debian.org. That example
400
would send localpart@example.com a subscription message for bug nnn.
401
The @ sign must be encoded by changing it to an = sign. Similarly, an
402
unsubscription takes the form
407
403
nnn-unsubscribe-localpart=example.com@bugs.debian.org. In both cases,
408
404
the subject and body of the email will be forwarded to the email
409
405
address within the request for confirmation.
417
413
example, by using reply to all recipients).
419
415
A similar scheme operates for maintonly, done, quiet and forwarded,
420
which treat mail arriving with a Subject tag as having been sent to the
421
corresponding nnn-whatever@bugs.debian.org address.
416
which treat mail arriving with a Subject tag as having been sent to
417
the corresponding nnn-whatever@bugs.debian.org address.
423
Messages arriving at plain forwarded and done -- ie, with no bug report
424
number in the address -- and without a bug number in the Subject will
425
be filed under "junk" and kept for a few weeks, but otherwise ignored.
419
Messages arriving at plain forwarded and done -- ie, with no bug
420
report number in the address -- and without a bug number in the
421
Subject will be filed under "junk" and kept for a few weeks, but
427
424
Obsolete X-Debian-PR: quiet feature
430
427
forwarding anywhere messages it received at debian-bugs, by putting an
431
428
X-Debian-PR: quiet line in the actual mail header.
433
This header line is now ignored. Instead, send your message to quiet or
434
nnn-quiet (or maintonly or nnn-maintonly).
435
__________________________________________________________________
430
This header line is now ignored. Instead, send your message to quiet
431
or nnn-quiet (or maintonly or nnn-maintonly).
432
_________________________________________________________________
437
434
Debian BTS administrators <owner@bugs.debian.org>
439
436
Debian bug tracking system
440
437
Copyright � 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
441
438
1994-1997 Ian Jackson.
442
__________________________________________________________________
439
_________________________________________________________________
added
removed
includes/squeeze/common/doc/bug-maint-info.txt
