-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 <url id="&url-bts-control;" name="BTS
-instructions"> document the technical operations of the BTS, such as
-how to file, reassign, merge, and tag bugs. This section contains
-some guidelines for managing your own bugs, based on the collective
-Debian developer experience.
- <p>
-Filing bugs for problems that you find in other packages is one of
-the "civic obligations" of maintainership, see <ref id="submit-bug">
-for details. However handling the bugs on your own packages is
-even more important.
- <p>
-Here's a list of steps that you may follow to handle a bug report:
-<enumlist>
- <item>
-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 his 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 to the upstream author.
- <p>
-If the bug submitter disagree 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 <tt>wontfix</tt>
-to let people know that the bug exists but that it won't be corrected.
-If this situation is unacceptable, you (or the submitter) may want to
-require a decision of the technical committee by reassigning the bug
-to <package>tech-ctte</package> (you may use the clone command of
-the BTS if you wish to keep it reported against your package). Before
-doing so, please read the <url id="&url-tech-ctte;" name="recommended procedure">.
- <item>
-If the bug is real but it's caused by another package, just reassign
-the bug the right package. If you don't know which package it should
-be reassigned to, you may either ask for help on &email-debian-devel; or
-reassign it to <package>debian-policy</package> to let them decide which
-package is in fault.
- <p>
-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.
- <item>
-The bug submitter may have forgotten to provide some information, in that
-case you have to ask him the information required. You may use the
-<tt>moreinfo</tt> tag to mark the bug as such. Moreover if you can't
-reproduce the bug, you tag it <tt>unreproducible</tt>. 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.
- <item>
-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 <tt>help</tt>. You can
-also ask for help on &email-debian-devel; or &email-debian-qa;. 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 that you send at the
-same time to the author. Make sure to send the patch in the BTS and to
-tag the bug as <tt>patch</tt>.
- <item>
-If you have fixed a bug in your local copy, or if a fix has been
-committed to the CVS repository, you may tag the bug as
-<tt>pending</tt> to let people know that the bug is corrected and that
-it will be closed with the next upload (add the <tt>closes:</tt> in
-the <file>changelog</file>). This is particularly useful if you
-are several developers working on the same package.
- <item>
-Once a corrected package is available in the <em>unstable</em>
-distribution, you can close the bug. This can be done automatically,
-read <ref id="upload-bugfix">.
-</enumlist>
-
- <sect1 id="bug-security">Handling security-related bugs
- <p>
-Due to their sensitive nature, security-related bugs must be handled
-carefully. The Debian Security Team exists to coordinate this
-activity, keeping track of outstanding security problems, helping
-maintainers with security problems or fix them themselves, sending
-security advisories, and maintaining security.debian.org.
-
-<!-- information about the security database goes here once it's ready -->
-<!-- (mdz) -->