383 lines
34 KiB
HTML
383 lines
34 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 7. Beyond Packaging</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /><link rel="home" href="index.html" title="Debian Developer's Reference" /><link rel="up" href="index.html" title="Debian Developer's Reference" /><link rel="prev" href="best-pkging-practices.html" title="Chapter 6. Best Packaging Practices" /><link rel="next" href="l10n.html" title="Chapter 8. Internationalization and Translations" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. Beyond Packaging</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="best-pkging-practices.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="l10n.html">Next</a></td></tr></table><hr /></div><div class="chapter" title="Chapter 7. Beyond Packaging"><div class="titlepage"><div><div><h2 class="title"><a id="beyond-pkging"></a>Chapter 7. Beyond Packaging</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="beyond-pkging.html#submit-bug">7.1. Bug reporting</a></span></dt><dd><dl><dt><span class="section"><a href="beyond-pkging.html#submit-many-bugs">7.1.1. Reporting lots of bugs at once (mass bug filing)</a></span></dt></dl></dd><dt><span class="section"><a href="beyond-pkging.html#qa-effort">7.2. Quality Assurance effort</a></span></dt><dd><dl><dt><span class="section"><a href="beyond-pkging.html#qa-daily-work">7.2.1. Daily work</a></span></dt><dt><span class="section"><a href="beyond-pkging.html#qa-bsp">7.2.2. Bug squashing parties</a></span></dt></dl></dd><dt><span class="section"><a href="beyond-pkging.html#contacting-maintainers">7.3. Contacting other maintainers</a></span></dt><dt><span class="section"><a href="beyond-pkging.html#mia-qa">7.4. Dealing with inactive and/or unreachable maintainers</a></span></dt><dt><span class="section"><a href="beyond-pkging.html#newmaint">7.5. Interacting with prospective Debian developers</a></span></dt><dd><dl><dt><span class="section"><a href="beyond-pkging.html#sponsoring">7.5.1. Sponsoring packages</a></span></dt><dt><span class="section"><a href="beyond-pkging.html#advocating-new-developers">7.5.2. Advocating new developers</a></span></dt><dt><span class="section"><a href="beyond-pkging.html#become-application-manager">7.5.3. Handling new maintainer applications</a></span></dt></dl></dd></dl></div><p>
|
||
Debian is about a lot more than just packaging software and maintaining those
|
||
packages. This chapter contains information about ways, often really critical
|
||
ways, to contribute to Debian beyond simply creating and maintaining packages.
|
||
</p><p>
|
||
As a volunteer organization, Debian relies on the discretion of its members in
|
||
choosing what they want to work on and in choosing the most critical thing to
|
||
spend their time on.
|
||
</p><div class="section" title="7.1. Bug reporting"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="submit-bug"></a>7.1. Bug reporting</h2></div></div></div><p>
|
||
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 developers' packages improves the quality of Debian.
|
||
</p><p>
|
||
Read the <a class="ulink" href="http://www.debian.org/Bugs/Reporting" target="_top">instructions for
|
||
reporting bugs</a> in the Debian <a class="ulink" href="http://www.debian.org/Bugs/" target="_top">bug tracking system</a>.
|
||
</p><p>
|
||
Try to submit the bug from a normal user account at which you are likely to
|
||
receive mail, so that people can reach you if they need further information
|
||
about the bug. Do not submit bugs as root.
|
||
</p><p>
|
||
You can use a tool like <span class="citerefentry"><span class="refentrytitle">reportbug</span>(1)</span> to submit bugs. It can automate and
|
||
generally ease the process.
|
||
</p><p>
|
||
Make sure the bug is not already filed against a package. Each package has a
|
||
bug list easily reachable at
|
||
<code class="literal">http://bugs.debian.org/<em class="replaceable"><code>packagename</code></em></code>.
|
||
Utilities like <span class="citerefentry"><span class="refentrytitle">querybts</span>(1)</span> can also provide you with this
|
||
information (and <span class="command"><strong>reportbug</strong></span> will usually invoke
|
||
<span class="command"><strong>querybts</strong></span> before sending, too).
|
||
</p><p>
|
||
Try to direct your bugs to the proper location. When for example your bug is
|
||
about a package which overwrites files from another package, check the bug
|
||
lists for <span class="emphasis"><em>both</em></span> of those packages in order to avoid filing
|
||
duplicate bug reports.
|
||
</p><p>
|
||
For extra credit, you can go through other packages, merging bugs 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).
|
||
</p><p>
|
||
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
|
||
<code class="literal">http://bugs.debian.org/from:<em class="replaceable"><code>your-email-addr</code></em></code>.
|
||
</p><div class="section" title="7.1.1. Reporting lots of bugs at once (mass bug filing)"><div class="titlepage"><div><div><h3 class="title"><a id="submit-many-bugs"></a>7.1.1. Reporting lots of bugs at once (mass bug filing)</h3></div></div></div><p>
|
||
Reporting a great number of bugs for the same problem on a great number of
|
||
different packages — i.e., more than 10 — is a deprecated practice. Take
|
||
all possible steps to avoid submitting bulk bugs at all. For instance, if
|
||
checking for the problem can be automated, add a new check to <code class="systemitem">lintian</code> so that an error or warning is emitted.
|
||
</p><p>
|
||
If you report more than 10 bugs on the same topic at once, it is recommended
|
||
that you send a message to <code class="email"><<a class="email" href="mailto:debian-devel@lists.debian.org">debian-devel@lists.debian.org</a>></code> describing
|
||
your intention before submitting the report, and mentioning the fact in the
|
||
subject of your mail. This will allow other developers to verify that the bug
|
||
is a real problem. In addition, it will help prevent a situation in which
|
||
several maintainers start filing the same bug report simultaneously.
|
||
</p><p>
|
||
Please use the programs <span class="command"><strong>dd-list</strong></span> and if appropriate
|
||
<span class="command"><strong>whodepends</strong></span> (from the package <code class="systemitem">devscripts</code>) to generate a list
|
||
of all affected packages, and include the output in your mail to
|
||
<code class="email"><<a class="email" href="mailto:debian-devel@lists.debian.org">debian-devel@lists.debian.org</a>></code>.
|
||
</p><p>
|
||
Note that when sending lots of bugs on the same subject, you should send the
|
||
bug report to <code class="email"><<a class="email" href="mailto:maintonly@bugs.debian.org">maintonly@bugs.debian.org</a>></code> so that the bug report
|
||
is not forwarded to the bug distribution mailing list.
|
||
</p><div class="section" title="7.1.1.1. Usertags"><div class="titlepage"><div><div><h4 class="title"><a id="usertags"></a>7.1.1.1. Usertags</h4></div></div></div><p>
|
||
You may wish to use BTS usertags when submitting bugs across a number of
|
||
packages. Usertags are similar to normal tags such as 'patch' and 'wishlist'
|
||
but differ in that they are user-defined and occupy a namespace that is
|
||
unique to a particular user. This allows multiple sets of developers to
|
||
'usertag' the same bug in different ways without conflicting.
|
||
</p><p>
|
||
To add usertags when filing bugs, specify the <code class="literal">User</code> and
|
||
<code class="literal">Usertags</code> pseudo-headers:
|
||
</p><pre class="screen">
|
||
To: submit@bugs.debian.org
|
||
Subject: <em class="replaceable"><code>title-of-bug</code></em>
|
||
|
||
Package: <em class="replaceable"><code>pkgname</code></em>
|
||
<em class="replaceable"><code>[ ... ]</code></em>
|
||
User: <em class="replaceable"><code>email-addr</code></em>
|
||
Usertags: <em class="replaceable"><code>tag-name [ tag-name ... ]</code></em>
|
||
|
||
<em class="replaceable"><code>description-of-bug ...</code></em>
|
||
</pre><p>
|
||
Note that tags are seperated by spaces and cannot contain underscores. If you
|
||
are filing bugs for a particular group or team it is recommended that you
|
||
set the <code class="literal">User</code> to an appropriate mailing list after describing
|
||
your intention there.
|
||
</p><p>
|
||
To view bugs tagged with a specific usertag, visit
|
||
<code class="literal">http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=<em class="replaceable"><code>email-addr</code></em>&tag=<em class="replaceable"><code>tag-name</code></em></code>.
|
||
</p></div></div></div><div class="section" title="7.2. Quality Assurance effort"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="qa-effort"></a>7.2. Quality Assurance effort</h2></div></div></div><div class="section" title="7.2.1. Daily work"><div class="titlepage"><div><div><h3 class="title"><a id="qa-daily-work"></a>7.2.1. Daily work</h3></div></div></div><p>
|
||
Even though there is a dedicated group of people for Quality Assurance, QA
|
||
duties are not reserved solely for them. You can participate in this effort by
|
||
keeping your packages as bug-free as possible, and as lintian-clean (see <a class="xref" href="tools.html#lintian" title="A.2.1. lintian">Section A.2.1, “<code class="systemitem">lintian</code>”</a>) as possible. If you do not find that possible, then you
|
||
should consider orphaning some of your packages (see <a class="xref" href="pkgs.html#orphaning" title="5.9.4. Orphaning a package">Section 5.9.4, “Orphaning a package”</a>). Alternatively, you may ask the help of other people
|
||
in order to catch up with the backlog of bugs that you have (you can ask for
|
||
help on <code class="email"><<a class="email" href="mailto:debian-qa@lists.debian.org">debian-qa@lists.debian.org</a>></code> or
|
||
<code class="email"><<a class="email" href="mailto:debian-devel@lists.debian.org">debian-devel@lists.debian.org</a>></code>). At the same time, you can look for
|
||
co-maintainers (see <a class="xref" href="pkgs.html#collaborative-maint" title="5.12. Collaborative maintenance">Section 5.12, “Collaborative maintenance”</a>).
|
||
</p></div><div class="section" title="7.2.2. Bug squashing parties"><div class="titlepage"><div><div><h3 class="title"><a id="qa-bsp"></a>7.2.2. Bug squashing parties</h3></div></div></div><p>
|
||
From time to time the QA group organizes bug squashing parties to get rid of as
|
||
many problems as possible. They are announced on
|
||
<code class="email"><<a class="email" href="mailto:debian-devel-announce@lists.debian.org">debian-devel-announce@lists.debian.org</a>></code> and the announcement explains
|
||
which area will be the focus of the party: usually they focus on release
|
||
critical bugs but it may happen that they decide to help finish a major upgrade
|
||
(like a new <span class="command"><strong>perl</strong></span> version which requires recompilation of all
|
||
the binary modules).
|
||
</p><p>
|
||
The rules for non-maintainer uploads differ during the parties because the
|
||
announcement of the party is considered prior notice for NMU. If you have
|
||
packages that may be affected by the party (because they have release critical
|
||
bugs for example), you should send an update to each of the corresponding bug
|
||
to explain their current status and what you expect from the party. If you
|
||
don't want an NMU, or if you're only interested in a patch, or if you will deal
|
||
yourself with the bug, please explain that in the BTS.
|
||
</p><p>
|
||
People participating in the party have special rules for NMU, they can NMU
|
||
without prior notice if they upload their NMU to DELAYED/3-day at least. All
|
||
other NMU rules apply as usually; they should send the patch of the NMU to the
|
||
BTS (to one of the open bugs fixed by the NMU, or to a new bug, tagged fixed).
|
||
They should also respect any particular wishes of the maintainer.
|
||
</p><p>
|
||
If you don't feel confident about doing an NMU, just send a patch to the BTS.
|
||
It's far better than a broken NMU.
|
||
</p></div></div><div class="section" title="7.3. Contacting other maintainers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contacting-maintainers"></a>7.3. Contacting other maintainers</h2></div></div></div><p>
|
||
During your lifetime within Debian, you will have to contact other maintainers
|
||
for various reasons. You may want to discuss a new way of cooperating between
|
||
a set of related packages, or you may simply remind someone that a new upstream
|
||
version is available and that you need it.
|
||
</p><p>
|
||
Looking up the email address of the maintainer for the package can be
|
||
distracting. Fortunately, there is a simple email alias,
|
||
<code class="literal"><em class="replaceable"><code>package</code></em>@packages.debian.org</code>, which provides a way to
|
||
email the maintainer, whatever their individual email address (or addresses)
|
||
may be. Replace <em class="replaceable"><code>package</code></em> with the name of a source
|
||
or a binary package.
|
||
</p><p>
|
||
You may also be interested in contacting the persons who are subscribed to a
|
||
given source package via <a class="xref" href="resources.html#pkg-tracking-system" title="4.10. The Package Tracking System">Section 4.10, “The Package Tracking System”</a>. You can do so
|
||
by using the <code class="literal"><em class="replaceable"><code>package</code></em>@packages.qa.debian.org</code> email
|
||
address.
|
||
</p></div><div class="section" title="7.4. Dealing with inactive and/or unreachable maintainers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="mia-qa"></a>7.4. Dealing with inactive and/or unreachable maintainers</h2></div></div></div><p>
|
||
If you notice that a package is lacking maintenance, you should make sure that
|
||
the maintainer is active and will continue to work on their packages. It is
|
||
possible that they are not active any more, but haven't registered out of the
|
||
system, so to speak. On the other hand, it is also possible that they just
|
||
need a reminder.
|
||
</p><p>
|
||
There is a simple system (the MIA database) in which information about
|
||
maintainers who are deemed Missing In Action is recorded. When a member of the
|
||
QA group contacts an inactive maintainer or finds more information about one,
|
||
this is recorded in the MIA database. This system is available in
|
||
<code class="filename">/org/qa.debian.org/mia</code> on the host <code class="literal">qa.debian.org</code>,
|
||
and can be queried with the <span class="command"><strong>mia-query</strong></span> tool.
|
||
Use <span class="command"><strong>mia-query --help</strong></span> to see how to query the database.
|
||
If you find that no information has been recorded about an inactive maintainer yet,
|
||
or that you can add more information, you should generally proceed as follows.
|
||
</p><p>
|
||
The first step is to politely contact the maintainer, and wait a reasonable
|
||
time for a response. It is quite hard to define reasonable time, but it is
|
||
important to take into account that real life is sometimes very hectic. One
|
||
way to handle this would be to send a reminder after two weeks.
|
||
</p><p>
|
||
If the maintainer doesn't reply within four weeks (a month), one can assume
|
||
that a response will probably not happen. If that happens, you should
|
||
investigate further, and try to gather as much useful information about the
|
||
maintainer in question as possible. This includes:
|
||
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
The <code class="literal">echelon</code> information available through the <a class="ulink" href="https://db.debian.org/" target="_top">developers' LDAP database</a>, which indicates
|
||
when the developer last posted to a Debian mailing list. (This includes
|
||
mails about uploads distributed via the <code class="email"><<a class="email" href="mailto:debian-devel-changes@lists.debian.org">debian-devel-changes@lists.debian.org</a>></code> list.)
|
||
Also, remember to check whether the maintainer is marked as on vacation in
|
||
the database.
|
||
</p></li><li class="listitem"><p>
|
||
The number of packages this maintainer is responsible for, and the condition of
|
||
those packages. In particular, are there any RC bugs that have been open for
|
||
ages? Furthermore, how many bugs are there in general? Another important
|
||
piece of information is whether the packages have been NMUed, and if so, by
|
||
whom.
|
||
</p></li><li class="listitem"><p>
|
||
Is there any activity of the maintainer outside of Debian? For example, they
|
||
might have posted something recently to non-Debian mailing lists or news
|
||
groups.
|
||
</p></li></ul></div><p>
|
||
A bit of a problem are packages which were sponsored — the maintainer is not
|
||
an official Debian developer. The <code class="literal">echelon</code> information is not
|
||
available for sponsored people, for example, so you need to find and contact the
|
||
Debian developer who has actually uploaded the package. Given that they signed
|
||
the package, they're responsible for the upload anyhow, and are likely to know
|
||
what happened to the person they sponsored.
|
||
</p><p>
|
||
It is also allowed to post a query to <code class="email"><<a class="email" href="mailto:debian-devel@lists.debian.org">debian-devel@lists.debian.org</a>></code>,
|
||
asking if anyone is aware of the whereabouts of the missing maintainer. Please
|
||
Cc: the person in question.
|
||
</p><p>
|
||
Once you have gathered all of this, you can contact
|
||
<code class="email"><<a class="email" href="mailto:mia@qa.debian.org">mia@qa.debian.org</a>></code>. People on this alias will use the
|
||
information you provide in order to decide how to proceed. For example, they
|
||
might orphan one or all of the packages of the maintainer. If a package has
|
||
been NMUed, they might prefer to contact the NMUer before orphaning the package
|
||
— perhaps the person who has done the NMU is interested in the package.
|
||
</p><p>
|
||
One last word: please remember to be polite. We are all volunteers and cannot
|
||
dedicate all of our time to Debian. Also, you are not aware of the
|
||
circumstances of the person who is involved. Perhaps they might be seriously
|
||
ill or might even have died — you do not know who may be on the receiving
|
||
side. Imagine how a relative will feel if they read the e-mail of the deceased
|
||
and find a very impolite, angry and accusing message!
|
||
</p><p>
|
||
On the other hand, although we are volunteers, we do have a responsibility. So
|
||
you can stress the importance of the greater good — if a maintainer does not
|
||
have the time or interest anymore, they should let go and give the package to
|
||
someone with more time.
|
||
</p><p>
|
||
If you are interested in working in the MIA team, please have a look at the
|
||
<code class="filename">README</code> file in <code class="filename">/org/qa.debian.org/mia</code> on
|
||
<code class="literal">qa.debian.org</code> where the technical details and the MIA procedures are
|
||
documented and contact <code class="email"><<a class="email" href="mailto:mia@qa.debian.org">mia@qa.debian.org</a>></code>.
|
||
</p></div><div class="section" title="7.5. Interacting with prospective Debian developers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="newmaint"></a>7.5. Interacting with prospective Debian developers</h2></div></div></div><p>
|
||
Debian's success depends on its ability to attract and retain new and talented
|
||
volunteers. If you are an experienced developer, we recommend that you get
|
||
involved with the process of bringing in new developers. This section
|
||
describes how to help new prospective developers.
|
||
</p><div class="section" title="7.5.1. Sponsoring packages"><div class="titlepage"><div><div><h3 class="title"><a id="sponsoring"></a>7.5.1. Sponsoring packages</h3></div></div></div><p>
|
||
Sponsoring a package means uploading a package for a maintainer who is not able
|
||
to do it on their own. It's not a trivial matter, the sponsor must verify
|
||
the packaging and ensure that it is of the high level of quality that
|
||
Debian strives to have.
|
||
</p><p>
|
||
Debian Developers can sponsor packages. Debian Maintainers can't.
|
||
</p><p>
|
||
The process of sponsoring a package is:
|
||
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>The maintainer prepares a source package (<code class="filename">.dsc</code>) and puts it online
|
||
somewhere (like on <a class="ulink" href="http://mentors.debian.net/cgi-bin/welcome" target="_top">mentors.debian.net</a>) or even better, provides
|
||
a link to a public VCS repository (see <a class="xref" href="resources.html#servers-vcs" title="4.4.5. The VCS servers">Section 4.4.5, “The VCS servers”</a>) where
|
||
the package is maintained.</p></li><li class="listitem"><p>The sponsor downloads (or checkouts) the source package.</p></li><li class="listitem"><p>The sponsor reviews the source package. If she finds issues, she
|
||
informs the maintainer and asks her to provide a fixed version (the
|
||
process starts over at step 1).</p></li><li class="listitem"><p>The sponsor could not find any remaining problem. She builds the
|
||
package, signs it, and uploads it to Debian.</p></li></ol></div><p>
|
||
</p><p>
|
||
Before delving in the details of how to sponsor a package, you should
|
||
ask yourself whether adding the proposed package is beneficial to Debian.
|
||
</p><p>
|
||
There's no simple rule to answer this question, it can depend on many
|
||
factors: is the upstream codebase mature and not full of security holes?
|
||
Are there pre-existing packages that can do the same task and how do they
|
||
compare to this new package? Has the new package been requested by users
|
||
and how large is the user base? How active are the upstream developers?
|
||
</p><p>
|
||
You should also ensure that the prospective maintainer is going
|
||
to be a good maintainer. Does she already have some experience with other
|
||
packages? If yes, is she doing a good job with them (check out some bugs)?
|
||
Is she familiar with the package and its programming language?
|
||
Does she have the skills needed for this package? If not, is she able
|
||
to learn them?
|
||
</p><p>
|
||
It's also a good idea to know where she stands towards Debian: does
|
||
she agree with Debian's philosophy and does she intend to join Debian?
|
||
Given how easy it is to become a Debian Maintainer, you might want
|
||
to only sponsor people who plan to join. That way you know from the start
|
||
that you won't have to act as a sponsor indefinitely.
|
||
</p><div class="section" title="7.5.1.1. Sponsoring a new package"><div class="titlepage"><div><div><h4 class="title"><a id="sponsoring-new-package"></a>7.5.1.1. Sponsoring a new package</h4></div></div></div><p>
|
||
New maintainers usually have certain difficulties creating Debian packages —
|
||
this is quite understandable. They will do mistakes. That's why sponsoring
|
||
a brand new package into Debian requires a thorough review of the Debian
|
||
packaging. Sometimes several iterations will be needed until the package
|
||
is good enough to be uploaded to Debian. Thus being a sponsor implies being
|
||
a mentor.
|
||
</p><p>
|
||
Don't ever sponsor a new package without reviewing it. The review
|
||
of new packages done by ftpmasters mainly ensures that the software
|
||
is really free. Of course, it happens that they stumble on packaging
|
||
problems but they really should not. It's your task to ensure that
|
||
the uploaded package complies with the Debian Free Software Guidelines and
|
||
is of good quality.
|
||
</p><p>
|
||
Building the package and testing the software is part of the review, but
|
||
it's also not enough. The rest of this section contains a non-exhaustive
|
||
list of points to check in your review.
|
||
<sup>[<a id="idp17385752" href="#ftn.idp17385752" class="footnote">7</a>]</sup>
|
||
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Verify that the upstream tarball provided is the same that has been
|
||
distributed by the upstream author (when the sources are repackaged for
|
||
Debian, generate the modified tarball yourself).</p></li><li class="listitem"><p>Run <span class="command"><strong>lintian</strong></span> (see <a class="xref" href="tools.html#lintian" title="A.2.1. lintian">Section A.2.1, “<code class="systemitem">lintian</code>”</a>). It will catch many common
|
||
problems. Be sure to verify that any <span class="command"><strong>lintian</strong></span> overrides setup by the
|
||
maintainer is fully justified.</p></li><li class="listitem"><p>Run <span class="command"><strong>licensecheck</strong></span> (part of <a class="xref" href="tools.html#devscripts" title="A.6.1. devscripts">Section A.6.1, “<code class="systemitem">devscripts</code>”</a>) and verify that
|
||
<code class="filename">debian/copyright</code> seems correct and complete. Look for
|
||
license problems (like files with “All rights reserved”
|
||
headers, or with a non-DFSG compliant license). <span class="command"><strong>grep -ri</strong></span>
|
||
is your friend for this task.</p></li><li class="listitem"><p>Build the package with <span class="command"><strong>pbuilder</strong></span> (or any similar tool, see <a class="xref" href="tools.html#pbuilder" title="A.4.3. pbuilder">Section A.4.3, “<code class="systemitem">pbuilder</code>”</a>) to ensure that the build-dependencies are
|
||
complete.</p></li><li class="listitem"><p>Proofread <code class="filename">debian/control</code>: does it follow the
|
||
best practices (see <a class="xref" href="best-pkging-practices.html#bpp-debian-control" title="6.2. Best practices for debian/control">Section 6.2, “Best practices for <code class="filename">debian/control</code>”</a>)? Are the dependencies
|
||
complete?</p></li><li class="listitem"><p>Proofread <code class="filename">debian/rules</code>: does it follow the
|
||
best practices (see <a class="xref" href="best-pkging-practices.html#bpp-debian-rules" title="6.1. Best practices for debian/rules">Section 6.1, “Best practices for <code class="filename">debian/rules</code>”</a>)? Do you see some
|
||
possible improvements?</p></li><li class="listitem"><p>Proofread the maintainer scripts (<code class="filename">preinst</code>,
|
||
<code class="filename">postinst</code>, <code class="filename">prerm</code>,
|
||
<code class="filename">postrm</code>, <code class="filename">config</code>): will the
|
||
<code class="filename">preinst</code>/<code class="filename">postrm</code> work when the dependencies are not
|
||
installed? Are all the scripts idempotent (i.e. can you run them multiple
|
||
times without consequences)?</p></li><li class="listitem"><p>Review any change to upstream files (either in <code class="filename">.diff.gz</code>, or in
|
||
<code class="filename">debian/patches/</code> or directly embedded in the <code class="filename">debian</code>
|
||
tarball for binary files). Are they justified? Are they properly
|
||
documented (with <a class="ulink" href="http://dep.debian.net/deps/dep3/" target="_top">DEP-3</a> for patches)?</p></li><li class="listitem"><p>For every file, ask yourself why the file is there and whether it's
|
||
the right way to achieve the desired result. Is the maintainer following
|
||
the best packaging practices (see <a class="xref" href="best-pkging-practices.html" title="Chapter 6. Best Packaging Practices">Chapter 6, <em>Best Packaging Practices</em></a>)?</p></li><li class="listitem"><p>Build the packages, install them and try the software. Ensure you can
|
||
remove and purge the packages. Maybe test them with <span class="command"><strong>piuparts</strong></span>.
|
||
</p></li></ul></div><p>
|
||
If the audit did not reveal any problem, you can build the package and
|
||
upload it to Debian. Remember that even if you're not the maintainer,
|
||
the sponsor is still responsible of what he uploaded to Debian. That's
|
||
why you're encouraged to keep up with the package through the
|
||
<a class="xref" href="resources.html#pkg-tracking-system" title="4.10. The Package Tracking System">Section 4.10, “The Package Tracking System”</a>.
|
||
</p><p>
|
||
Note that you should not need to modify the source package to put your name
|
||
in the <code class="filename">changelog</code> or in the <code class="filename">control</code> file. The <code class="literal">Maintainer</code>
|
||
field of the <code class="filename">control</code> file and the
|
||
<code class="filename">changelog</code> should list the person who did the
|
||
packaging, i.e. the sponsoree. That way she will get all the BTS mail.
|
||
</p><p>Instead you should instruct <span class="command"><strong>dpkg-buildpackage</strong></span> to use your key for
|
||
the signature. You do that with the <code class="literal">-k</code> option:</p><pre class="screen">
|
||
dpkg-buildpackage -k<em class="replaceable"><code>KEY-ID</code></em>
|
||
</pre><p>If you use <span class="command"><strong>debuild</strong></span> and <span class="command"><strong>debsign</strong></span>, you can even configure it permanently
|
||
in <code class="filename">~/.devscripts</code>:</p><pre class="programlisting">
|
||
DEBSIGN_KEYID=<em class="replaceable"><code>KEY-ID</code></em>
|
||
</pre></div><div class="section" title="7.5.1.2. Sponsoring an update of an existing package"><div class="titlepage"><div><div><h4 class="title"><a id="sponsoring-update"></a>7.5.1.2. Sponsoring an update of an existing package</h4></div></div></div><p>
|
||
You will usually assume that the package has already gone through a full
|
||
review. So instead of doing it again, you will carefully analyze the
|
||
difference between the current version and the new version prepared by the
|
||
maintainer. If you have not done the initial review yourself, you might
|
||
still want to have a more deeper look just in case the initial reviewer
|
||
was sloppy.
|
||
</p><p>
|
||
To be able to analyze the difference you need both versions. Download the
|
||
current version of the source package (with <span class="command"><strong>apt-get source</strong></span>)
|
||
and rebuild it (or download the current binary packages with
|
||
<span class="command"><strong>aptitude download</strong></span>). Download the source package to sponsor
|
||
(usually with <span class="command"><strong>dget</strong></span>).
|
||
</p><p>
|
||
Read the new changelog entry, it should tell you what to expect during the
|
||
review. The main tool you will use is <span class="command"><strong>debdiff</strong></span> (provide by
|
||
the <code class="systemitem">devscripts</code> package), you can run it with two source packages (<code class="filename">.dsc</code>
|
||
files), or two binary packages, or two <code class="filename">.changes</code> files (it will then
|
||
compare all the binary packages listed in the <code class="filename">.changes</code>).
|
||
</p><p>
|
||
If you compare the source packages (excluding upstream files in the case
|
||
of a new upstream version, for example by filtering the output of <span class="command"><strong>debdiff</strong></span>
|
||
with <span class="command"><strong>filterdiff -i '*/debian/*'</strong></span>), you must understand all the
|
||
changes you see and they should be properly documented in the Debian
|
||
changelog.
|
||
</p><p>
|
||
If everything is fine, build the package and compare the binary packages
|
||
to verify that the changes on the source package have no unexpected
|
||
consequences (like some files dropped by mistake, missing dependencies,
|
||
etc.).
|
||
</p><p>
|
||
You might want to check out the Package Tracking System (see <a class="xref" href="resources.html#pkg-tracking-system" title="4.10. The Package Tracking System">Section 4.10, “The Package Tracking System”</a>) to verify if the
|
||
maintainer has not missed something important. Maybe there are translations
|
||
updates sitting in the BTS that could have been integrated. Maybe the package
|
||
has been NMUed and the maintainer forgot to integrate the changes from the
|
||
NMU in his package. Maybe there's a release critical bug that he has left
|
||
unhandled and that's blocking migration to <code class="literal">testing</code>. Whatever. If you find
|
||
something that she could have done (better), it's time to tell her so that
|
||
she can improve for next time, and so that she has a better understanding
|
||
of her responsibilities.
|
||
</p><p>
|
||
If you have found no major problem, upload the new version. Otherwise
|
||
ask the maintainer to provide you a fixed version.
|
||
</p></div></div><div class="section" title="7.5.2. Advocating new developers"><div class="titlepage"><div><div><h3 class="title"><a id="advocating-new-developers"></a>7.5.2. Advocating new developers</h3></div></div></div><p>
|
||
See the page about <a class="ulink" href="http://www.debian.org/devel/join/nm-advocate" target="_top">advocating a prospective
|
||
developer</a> at the Debian web site.
|
||
</p></div><div class="section" title="7.5.3. Handling new maintainer applications"><div class="titlepage"><div><div><h3 class="title"><a id="become-application-manager"></a>7.5.3. Handling new maintainer applications</h3></div></div></div><p>
|
||
Please see <a class="ulink" href="http://www.debian.org/devel/join/nm-amchecklist" target="_top">Checklist
|
||
for Application Managers</a> at the Debian web site.
|
||
</p></div></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.idp17385752" href="#idp17385752" class="para">7</a>] </sup>
|
||
You can find more checks in the wiki where several developers share their own
|
||
<a class="ulink" href="http://wiki.debian.org/SponsorChecklist" target="_top">sponsorship checklists</a>.
|
||
</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="best-pkging-practices.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="l10n.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 6. Best Packaging Practices </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 8. Internationalization and Translations</td></tr></table></div></body></html>
|