X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=ab5b26f621930ec37d376aadffc170d095cc06e4;hb=d03c6635e55f988ef2a7b6264da28d0d93e635b9;hp=70755c7cec6f1de536618959c753fdac4a2db609;hpb=07ba622edfeb6dbc1164f46399d6fa0a71eab70b;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index 70755c7..ab5b26f 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -6,7 +6,7 @@ %commondata; - +

The Package Tracking System (PTS) is basically a tool to track by mail the activity of a source package. You just have to subscribe @@ -1566,7 +1580,7 @@ It is technically possible to upload a package into several distributions at the same time but it usually doesn't make sense to use that feature because the dependencies of the package may vary with the distribution. In particular, it never makes sense to combine the experimental -distribution with anything else. +distribution with anything else (see ). Uploads to stable

@@ -1829,13 +1843,23 @@ according to their licensing, e.g. main, contrib and non-free. This is described in another section, . - Handling package bugs + Handling bugs

-Often as a package maintainer, you find bugs in other packages or else -have bugs reported to your packages which need to be reassigned. The - can tell you how -to do this. Some information on filing bugs can be found in . +Every developer has to be able to work with the Debian . This includes knowing how to file bug +reports properly (see ), how to update them and +reorder them, and how to process and close them. +

+The bug tracking system's features interesting to developers are described +in the . +This includes closing bugs, sending followup messages, assigning severities, +tags, marking bugs as forwarded and other issues. +

+Operations such as reassigning bugs to other packages, merging separate +bug reports about the same issue, or reopening bugs when they are +prematurely closed, are handled using the so-called control mail server. +All of the commands available in this server are described in the +. Monitoring bugs

@@ -3066,22 +3090,22 @@ documentation and examples (in /usr/share/doc/dpatch). Multiple binary packages

A single source package will often build several binary packages, -either to provide several flavors of the same software (examples are -the vim-* packages) or to make several small +either to provide several flavors of the same software (e.g., +the vim source package) or to make several small packages instead of a big one (e.g., if the user can install only the subset she needs, and thus save some disk space).

The second case can be easily managed in debian/rules. You just need to move the appropriate files from the build directory into the package's temporary trees. You can do this using -install (vanilla approach) or dh_install -(from debhelper). Be sure to check the different +install or dh_install +from debhelper. Be sure to check the different permutations of the various packages, ensuring that you have the inter-package dependencies set right in debian/control.

The first case is a bit more difficult since it involves multiple -recompiles of the same software but with different configure -options. The vim is an example of how to manage +recompiles of the same software but with different configuration +options. The vim source package is an example of how to manage this using an hand-crafted debian/rules file. @@ -3643,21 +3687,39 @@ members in choosing what they want to work on and in choosing the most critical thing to spend their time on. - Bug reporting + Bug reporting

We encourage you to file bugs as you find them in Debian packages. In fact, Debian developers are often the first line testers. Finding and -reporting bugs in other developer's packages improves the quality of +reporting bugs in other developers' packages improves the quality of Debian.

+Read the in the Debian . +

Try to submit the bug from a normal user account at which you are -likely to receive mail. Do not submit bugs as root. +likely to receive mail, so that people can reach you if they need +further information about the bug. Do not submit bugs as root. +

+You can use a tool like to +submit bugs. It can automate and generally ease the process. +

+Make sure the bug is not already filed against a package. +Each package has a bug list easily reachable at +http://&bugs-host;/packagename +Utilities like can also +provide you with this information (and reportbug +will usually invoke querybts before sending, too). +

+Try to direct your bugs to the proper location. When for example +your bug is about a package that overwrites files from another package, +check the bug lists for both of those packages in order to +avoid filing duplicate bug reports.

-Make sure the bug is not already filed against a package. Try to do a -good job reporting a bug and redirecting it to the proper location. For extra credit, you can go through other packages, merging bugs -which are reported more than once, or setting bug severities to -`fixed' when they have already been fixed. Note that when you are +which are reported more than once, or tagging bugs `fixed' +when they have already been fixed. Note that when you are neither the bug submitter nor the package maintainer, you should not actually close the bug (unless you secure permission from the maintainer). @@ -3666,7 +3728,7 @@ From time to time you may want to check what has been going on with the bug reports that you submitted. Take this opportunity to close those that you can't reproduce anymore. To find out all the bugs you submitted, you just have to visit -http://&bugs-host;/from:<your-email-addr>. +http://&bugs-host;/from:<your-email-addr>. Reporting lots of bugs at once

@@ -4374,6 +4436,9 @@ it.