5.8.3. Bug housekeeping

As a package maintainer, you will often find bugs in other packages or have bugs reported against your packages which are actually bugs in other packages. The bug tracking system’s features are described in the BTS documentation for Debian developers. Operations such as reassigning, merging, and tagging bug reports are described in the BTS control server documentation. This section contains some guidelines for managing your own bugs, based on the collective Debian developer experience.

Filing bugs for problems that you find in other packages is one of the civic obligations of maintainership, see Bug reporting for details. However, handling the bugs in your own packages is even more important.

Here’s a list of steps that you may follow to handle a bug report:

1. Decide whether the report corresponds to a real bug or not. Sometimes users are just calling a program in the wrong way because they haven’t read the documentation. If you diagnose this, just close the bug with enough information to let the user correct their problem (give pointers to the good documentation and so on). If the same report comes up again and again you may ask yourself if the documentation is good enough or if the program shouldn’t detect its misuse in order to give an informative error message. This is an issue that may need to be brought up with the upstream author.

   If the bug submitter disagrees with your decision to close the bug, they may reopen it until you find an agreement on how to handle it. If you don’t find any, you may want to tag the bug wontfix to let people know that the bug exists but that it won’t be corrected. Please make sure that the bug submitter understands the reasons for your decision by adding an explanation to the message that adds the wontfix tag.

   If this situation is unacceptable, you (or the submitter) may want to require a decision of the technical committee by filing a new bug against the tech-ctte pseudo-package with a summary of the situation. Before doing so, please read the recommended procedure.

2. If the bug is real but it’s caused by another package, just reassign the bug to the right package. If you don’t know which package it should be reassigned to, you should ask for help on IRC channels or on debian-devel@lists.debian.org. Please inform the maintainer(s) of the package you reassign the bug to, for example by Cc:ing the message that does the reassign to packagename@packages.debian.org and explaining your reasons in that mail. Please note that a simple reassignment is not e-mailed to the maintainers of the package being reassigned to, so they won’t know about it until they look at a bug overview for their packages.

   If the bug affects the operation of your package, please consider cloning the bug and reassigning the clone to the package that really causes the behavior. Otherwise, the bug will not be shown in your package’s bug list, possibly causing users to report the same bug over and over again. You should block “your” bug with the reassigned, cloned bug to document the relationship.

3. Sometimes you also have to adjust the severity of the bug so that it matches our definition of the severity. That’s because people tend to inflate the severity of bugs to make sure their bugs are fixed quickly. Some bugs may even be dropped to wishlist severity when the requested change is just cosmetic.

4. If the bug is real but the same problem has already been reported by someone else, then the two relevant bug reports should be merged into one using the merge command of the BTS. In this way, when the bug is fixed, all of the submitters will be informed of this. (Note, however, that emails sent to one bug report’s submitter won’t automatically be sent to the other report’s submitter.) For more details on the technicalities of the merge command and its relative, the unmerge command, see the BTS control server documentation.

5. The bug submitter may have forgotten to provide some information, in which case you have to ask them for the required information. You may use the moreinfo tag to mark the bug as such. Moreover if you can’t reproduce the bug, you tag it unreproducible. Anyone who can reproduce the bug is then invited to provide more information on how to reproduce it. After a few months, if this information has not been sent by someone, the bug may be closed.

6. If the bug is related to the packaging, you just fix it. If you are not able to fix it yourself, then tag the bug as help. You can also ask for help on debian-devel@lists.debian.org or debian-qa@lists.debian.org. If it’s an upstream problem, you have to forward it to the upstream author. Forwarding a bug is not enough, you have to check at each release if the bug has been fixed or not. If it has, you just close it, otherwise you have to remind the author about it. If you have the required skills you can prepare a patch that fixes the bug and send it to the author at the same time. Make sure to send the patch to the BTS and to tag the bug as patch.

7. If you have fixed a bug in your local copy, or if a fix has been committed to the VCS repository, you may tag the bug as pending to let people know that the bug is corrected and that it will be closed with the next upload (add the closes: in the changelog). This is particularly useful if you are several developers working on the same package.

8. Once a corrected package is available in the archive, the bug should be closed indicating the version in which it was fixed. This can be done automatically; read When bugs are closed by new uploads.