[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Debian BTS Cleanup HOWTO

Hi everyone!

In the Viennese Debian Group[1] Maximilian Attems (from the linux-2.6 team) 
held once a small tutorial on kernel bug triage. I tested the techniques then 
on the kernel bugs and later on kopete's quite unmaintained bugs. Here I 
present my methods and a few text templates for further reference. 

I would welcome any feedback about style and content as well as suggestions 
whether this could/should be posted at some accessible location.


Debian BTS Cleanup HOWTO


A significant count of packages in Debian have huge amounts of bugs clogging 
the bug report logs to the point of unusability. This leads to a death 
spiral: too many bug reports cause more duplicates (because nobody scans 200+ 
existing bug reports), less fixes (because everyone looses the big picture 
and forgets to close bugs when possible) and probably the worst of all: it 
demotivates people who want to help, because it is too much at once.

The goal therefore is to reduce the amount of bugs and at the same time 
improve the quality of the remaining ones without burning out in the process. 
The key point then becomes user participation: Teach, prod, delegate.


As with every big adventure, some planning and preparation is in order.

The End

Plan something to do afterwards. Dinner at eight, television at ten. 
Something, anything! Stop a few minutes before you reach this time. Stop now, 
if you have less than two hours.

The Surveillance

Subscribe to all BTS messages of the package by sending 

subscribe <sourcepackage> [<emailaddress>]
keyword <sourcepackage> [<emailaddress>] = bts bts-control

to pts@qa.debian.org and answering the challenge mail.

For more information about the PTS see the Developer Reference:

The Sanity

Configure a filter for all @bugs.debian.org mail into a separate folder, so 
you can ignore this traffic when you have no time. Configure your mail client 
to check every few minutes (5-10) for new mail. Keep an eye on quick answers.

Intelligence Gathering

Become familiar with the various versions of the package available in Debian 
by looking at http://packages.debian.org/<package> . Is the testing version 
current? Is the unstable version current? Is there a backport on 
http://www.backports.org/ available? Is there a newer development build 
available in experimental? How much has changed since the last stable 

Browse a bit through upstream's BTS. Is it a known tracking system? Do you 
need/have an account there? Where are the bugs for <package> located? Are 
there recurring problems? How does upstream react to these? Are there any 
canonical bug reporting templates? How can I address a particular bug from 
the outside?

Bug Hygiene

Start composing a mail to control@bugs.debian.org ; this can be used to 
collect all minor BTS commands (retitle, merge, severity, etc) as you go. 
Send it every half hour or when you have ten commands collected.

Fetching the Work

Fetch a list of currently pending bugs in the BTS by using the new "Options" 
section at the bottom of each package's page and activate the "Show bugs 
applicable to <version>" as appropriate.


The goal is to have a major effect on the package's bugs. This cannot be 
achieved by solving the bugs alone, but only in soliciting cooperation from 
the submitters. While scanning the bug report log, try to work on _every_ 
bug, but don't get wound up in one. Often the status of the bug can be judged 
by the first and the last message. Read them first.

Unless otherwise specified, send mails

* To: <bugnumber>-submitter@bugs.debian.org
* Cc: <bugnumber>@bugs.debian.org to notify the maintainer of your work,
* If there are any other stakeholders ("Me too!"-ers, other developers) add
  them to a X-Debbugs-CC: header in the first line of the mail body

Set the Reply-To header to <bugnumber>@bugs.debian.org, so that the user 
replies into the bug report.

Copy the bug title as Subject.

While you go through the bug reports check 

* the bug title: is it an accurate description of the problem? does it start 
with the package name?
* is it a duplicate of another report?
* is the severity correct?

These things can be fixed by adding BTS commands to the control@ mail.

The following techniques are sorted by increasing effort.

The Ancient Close

The bug was already old when stable released and there was no or not much 
discussion. Chances are good that the bug is irrelevant by now. Close it by 
sending a short explanation to <bugnumber>-done@bugs.debian.org:

> Hi <submitter>!
> Your bug report is for an ancient version of <package>, I'm therefore 
> closing it. If you have any remaining problems with <package> and <original
> problem> (or anything else of course), please feel free to submit 
> another bugreport using the reportbug tool.
> Thank you for your cooperation!
> <signature>

The Fixed Close

You are using the product yourself and the described problem doesn't exist 
with your version. Chances are that the problem is fixed for good, but nobody 
cared to close the bug. Close it by sending a short explanation to 

> Version: <version containing the fix>
> Hi <submitter>!
> Using a current version (<version>) of <package> I have not experienced this
> problem when doing <X>. Therefore I close this report for this version.
> Thank you for your bug report!
> <signature>

The Test Prod

The bug may be still relevant, but there are already new versions available. 
Most users are happy to provide help if they knew how and what. The simplest 
thing therefore is to kindly ask the user to check if the problem still 

Depending on the staleness of the bug, some parts of this template have to be 
edited. A significant criterion is whether the report has the same upstream 
version as testing. 

> Hi <bugsubmitter>!
> There are new versions of <package> in [stable (<version>) as well as]
> testing (<version>) and unstable (<version>) available. Could you please
> test if one of those already <fixes your problem with X>? 
> Please report your findings by sending "found" or "close" followed by
> the bug number (<bugnumber>) and the respective version to
> control@bugs.debian.org
> For example:
> found 123456 <stable version>
> close 123456 <testing version>
> <additional remarks>
> Thank you for your cooperation!
> <signature>

While the "close" command is deprecated, I hope it is proper to direct a user 
to close his _own_ report if the problem is solved. At least it is easier 
than to distinguish between "send 'found' to control@" and else 
send "Version: <version>" to <bugnumber>-done@bugs. 
Perhaps something which could be improved on the BTS side.

The Information Prod

Sometimes the bug might be fresh and appropriate, but there is no way to tell, 
because critical information is missing from the report. Use the Prod 
template and add a short paragraph about proper bug contents as additional 
remarks. Of course this is highly problem dependant but includes things as

* Which versions where in use?
* What actions led to this problem?
* Does it happen under a fresh/new user?
* Ask for backtraces (KDE/GNOME) with the appropriate -dbg packages installed
* Ask for gdb backtraces with the appropriate -dbg packages installed
* Ask for a strace of the problem
* Ask for a valgrind run of the problem
* Ask for test cases

Remember to direct the user to <bugnumber>@bugs.debian.org, so that this 
information is not lost.


tags <bugnumber> + moreinfo

to your control@ mail.

The Forward

The bug is fresh, not a obvious duplicate and the bug submitter included 
enough information. Great! Problems with Debian's infrastructure (packaging, 
dependencies, file system layout, too much or too few compiled/installed 
features, etc) are best left to the maintainer. Problems with the program 
itself are often already noted in the upstream BTS. Locate it and notify 
everyone about everyone else.

First note it in the Debian BTS. Send a mail to the usual recipients and add a 
CC to control@bugs.debian.org

> forward <bugnumber> <URL>
> thanks
> Hi <submitter>!
> The bug you have reported is already present in upstream's bug tracking
> system at <URL>.
> Thanks for your cooperation!
> <signature>

This adds the "Forwarded" link to upstream's BTS in the bug report log. If 
there is any additional information or a workaround in the upstream bug, make 
the user aware of it. For example:

> Upstream has requested to test <X>. Please submit this at your convenience
> either here (<bugnumber>@bugs.debian.org) or directly in upstream's bug
> tracker.


> Upstream recommends <X> for the time being to mitigate this problem. A real 
> fix is expected with version <Y>. 

Second, add a pointer to upstream's tracker about Debian's bug report, again 
adding information as necessary.

> The same problem has surfaced in the debian package <version>. <submitter>
> has sent a bug report which is available at
> http://bugs.debian.org/<bugnumber> . Additionally, the submitter has noticed
> that <X> and <Y>.

Further Activities

When the clock runs out, finish your last mail and do not forget to send the 
collected commands to control@bugs.debian.org. Recheck your mail and reload 
the overview page. Is everything where it should be? Good. Have a nice 

Over the next few days users will start to report back. Some won't respect 
your Reply-To header. You can just redirect these mails to the appropriate 
bug report. Some will botch the BTS commands. Fix it unobtrusively while not 
forgetting to CC the user. Most will just do what is necessary, closing the 
bug or reporting new occurrences. Be proud.

After a week or two another pass over the reports can help in weeding out 
unreproducible problems, unresponsive submitters and similar things, further 
reducing the count of open bugs. 

Depending on your temperament, technical interest and personal dependence on 
the package in question you can now move on to the next package or start 
trying to reproduce/fix the bugs yourself.


Regards, David

[1] http://www.debienna.at/ , sorry, german only
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Reply to: