<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.106 $">
+ <!entity cvs-rev "$Revision: 1.107 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
<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.
+for details. However handling the bugs on your own packages is
+even more important.
<p>
-&FIXME;Talk about tags, forwarding bugs, or else break it into
-different sections...
+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 informatory 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,
+he 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 inacceptable, 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).
+<!-- FIXME: Follow the procedure described at
+ tech-ctte-url (there's no such url yet). -->
+ <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 availabe in the <em>unstable</em>
+distribution, you can close the bug. This can be done automatically,
+read <ref id="upload-bugfix">.
+</enumlist>
<sect1 id="upload-bugfix">When bugs are closed by new uploads
several mailing lists. By following them, you will make Debian's quality
even better.
+ <sect id="packaging-tools">
+ <heading>Packaging tools and common cases</heading>
+
+ <sect1 id="helper-scripts">Helper scripts
+ <p>
+ &FIXME; debhelper best, debmake obsolete, yada exists. Custom
+ rules files are ok too: http://people.debian.org/~srivasta/rules
+ Tools are great but you still have to understand what they do
+ => read their documentation.
+
+ <sect1 id="pkg-mgmt-cvs">Managing a package with CVS
+ <p>
+ &FIXME; presentation of cvs-buildpackage, updating sources
+ via CVS (debian/rules refresh).
+
+ <sect1 id="multiple-patches">Package with multiple patches
+ <p>
+ &FIXME; presentation of "dbs", example package: hello-dbs
+
+ <sect1 id="multiple-binary">Multiple binary packages
+ <p>
+ &FIXME; dh_install, example of packages with multiple
+ configure/make cycles
+ Example packages: vim (custom system)
+
+ <sect1 id="handling-debconf-translations">Handling debconf translations
+ <p>
+ &FIXME; Denis Barbier is going to write it.
+
+
+ <sect id="specific-practices">
+ <heading>Specific packaging practices</heading>
+
+ <sect1 id="bpp-kernel">Kernel modules/patches
+ <p>
+ &FIXME; Heavy use of kernel-package. provide files in
+ /etc/modutils/ for module configuration.
+
+ <sect1 id="bpp-libraries">Libraries
+ <p>
+ &FIXME; http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
+
+ <sect1 id="bpp-other-specific-practices">Other specific packages
+ <p>
+ &FIXME; perl, python, ocaml, java, emacs.
+ ocaml:
+ /usr/share/doc/ocaml/ocaml_packaging_policy.gz
+ a good example are packages libzip-ocaml{,-dev}
+ perl:
+ http://www.debian.org/doc/packaging-manuals/perl-policy/
+ libdbd-pg-perl binary package, libmldbm-perl arch all package
+ emacs:
+ http://www.debian.org/doc/packaging-manuals/debian-emacs-policy
+ java:
+ http://people.debian.org/~opal/java/policy.html/
+ python:
+ /usr/share/doc/python/python-policy.txt.gz in python package
+
+ <sect id="config-mgmt">
+ <heading>Configuration management</heading>
+
+ <sect1 id="config-wise-debconf">The wise use of debconf
+ <p>
+ &FIXME; debconf-devel(8) is a MUST read
+
+ <sect1 id="custom-config-files">Custom configuration files
+ <p>
+ &FIXME; speak of "ucf", explain solution with a template,
+ explain conf.d directories
+
+ <sect1 id="config-with-db">Use of an external database
+ <p>
+ &FIXME; The software may require a database that you need to setup.
+ But the database may be local or distant. Thus you can't depend
+ on a database server but just on the corresponding library.
+
+ sympa may be an example package
+
+
<sect id="misc-advice">
<heading>Miscellaenous advice</heading>
~ianmdlvl / developers-reference.git / commitdiff