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>
|