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
Introduction
============
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.
Preparation
===========
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:
http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system
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
release?
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.
Techniques
==========
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
<bugnumber>-done@bugs.debian.org:
> 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
exists.
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.
Add
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.
or
> 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
evening.
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: