1
<?xml version="1.0" encoding="utf-8"?>
2
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
3
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
4
<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
6
<chapter id="beyond-pkging">
7
<title>Beyond Packaging</title>
9
Debian is about a lot more than just packaging software and maintaining those
10
packages. This chapter contains information about ways, often really critical
11
ways, to contribute to Debian beyond simply creating and maintaining packages.
14
As a volunteer organization, Debian relies on the discretion of its members in
15
choosing what they want to work on and in choosing the most critical thing to
18
<section id="submit-bug">
19
<title>Bug reporting</title>
21
We encourage you to file bugs as you find them in Debian packages. In fact,
22
Debian developers are often the first line testers. Finding and reporting bugs
23
in other developers' packages improves the quality of Debian.
26
Read the <ulink url="&url-bts-report;">instructions for
27
reporting bugs</ulink> in the Debian <ulink
28
url="&url-bts;">bug tracking system</ulink>.
31
Try to submit the bug from a normal user account at which you are likely to
32
receive mail, so that people can reach you if they need further information
33
about the bug. Do not submit bugs as root.
36
You can use a tool like <citerefentry> <refentrytitle>reportbug</refentrytitle>
37
<manvolnum>1</manvolnum> </citerefentry> to submit bugs. It can automate and
38
generally ease the process.
41
Make sure the bug is not already filed against a package. Each package has a
42
bug list easily reachable at
43
<literal>http://&bugs-host;/<replaceable>packagename</replaceable></literal>
44
Utilities like <citerefentry> <refentrytitle>querybts</refentrytitle>
45
<manvolnum>1</manvolnum> </citerefentry> can also provide you with this
46
information (and <command>reportbug</command> will usually invoke
47
<command>querybts</command> before sending, too).
50
Try to direct your bugs to the proper location. When for example your bug is
51
about a package which overwrites files from another package, check the bug
52
lists for <emphasis>both</emphasis> of those packages in order to avoid filing
53
duplicate bug reports.
56
For extra credit, you can go through other packages, merging bugs which are
57
reported more than once, or tagging bugs `fixed' when they have already been
58
fixed. Note that when you are neither the bug submitter nor the package
59
maintainer, you should not actually close the bug (unless you secure permission
63
From time to time you may want to check what has been going on with the bug
64
reports that you submitted. Take this opportunity to close those that you
65
can't reproduce anymore. To find out all the bugs you submitted, you just have
67
<literal>http://&bugs-host;/from:<replaceable><your-email-addr></replaceable></literal>.
69
<section id="submit-many-bugs">
70
<title>Reporting lots of bugs at once (mass bug filing)</title>
72
Reporting a great number of bugs for the same problem on a great number of
73
different packages — i.e., more than 10 — is a deprecated practice. Take
74
all possible steps to avoid submitting bulk bugs at all. For instance, if
75
checking for the problem can be automated, add a new check to <systemitem
76
role="package">lintian</systemitem> so that an error or warning is emitted.
79
If you report more than 10 bugs on the same topic at once, it is recommended
80
that you send a message to &email-debian-devel; describing
81
your intention before submitting the report, and mentioning the fact in the
82
subject of your mail. This will allow other developers to verify that the bug
83
is a real problem. In addition, it will help prevent a situation in which
84
several maintainers start filing the same bug report simultaneously.
87
Please use the programms <command>dd-list</command> and if appropriate
88
<command>whodepends</command> (from the package devscripts) to generate a list
89
of all affected packages, and include the output in your mail to
93
Note that when sending lots of bugs on the same subject, you should send the
94
bug report to <email>maintonly@&bugs-host;</email> so that the bug report
95
is not forwarded to the bug distribution mailing list.
101
<section id="qa-effort">
102
<title>Quality Assurance effort</title>
103
<section id="qa-daily-work">
104
<title>Daily work</title>
106
Even though there is a dedicated group of people for Quality Assurance, QA
107
duties are not reserved solely for them. You can participate in this effort by
108
keeping your packages as bug-free as possible, and as lintian-clean (see <xref
109
linkend="lintian"/> ) as possible. If you do not find that possible, then you
110
should consider orphaning some of your packages (see <xref
111
linkend="orphaning"/> ). Alternatively, you may ask the help of other people
112
in order to catch up with the backlog of bugs that you have (you can ask for
113
help on &email-debian-qa; or
114
&email-debian-devel;). At the same time, you can look for
115
co-maintainers (see <xref linkend="collaborative-maint"/> ).
119
<section id="qa-bsp">
120
<title>Bug squashing parties</title>
122
From time to time the QA group organizes bug squashing parties to get rid of as
123
many problems as possible. They are announced on
124
&email-debian-devel-announce; and the announcement explains
125
which area will be the focus of the party: usually they focus on release
126
critical bugs but it may happen that they decide to help finish a major upgrade
127
(like a new perl version which requires recompilation of all the binary
131
The rules for non-maintainer uploads differ during the parties because the
132
announcement of the party is considered prior notice for NMU. If you have
133
packages that may be affected by the party (because they have release critical
134
bugs for example), you should send an update to each of the corresponding bug
135
to explain their current status and what you expect from the party. If you
136
don't want an NMU, or if you're only interested in a patch, or if you will deal
137
yourself with the bug, please explain that in the BTS.
140
People participating in the party have special rules for NMU, they can NMU
141
without prior notice if they upload their NMU to DELAYED/3-day at least. All
142
other NMU rules apply as usually; they should send the patch of the NMU to the
143
BTS (to one of the open bugs fixed by the NMU, or to a new bug, tagged fixed).
144
They should also respect any particular wishes of the maintainer.
147
If you don't feel confident about doing an NMU, just send a patch to the BTS.
148
It's far better than a broken NMU.
154
<section id="contacting-maintainers">
155
<title>Contacting other maintainers</title>
157
During your lifetime within Debian, you will have to contact other maintainers
158
for various reasons. You may want to discuss a new way of cooperating between
159
a set of related packages, or you may simply remind someone that a new upstream
160
version is available and that you need it.
163
Looking up the email address of the maintainer for the package can be
164
distracting. Fortunately, there is a simple email alias,
165
<literal><package>@&packages-host;</literal>, which provides a way to
166
email the maintainer, whatever their individual email address (or addresses)
167
may be. Replace <literal><package></literal> with the name of a source
171
You may also be interested in contacting the persons who are subscribed to a
172
given source package via <xref linkend="pkg-tracking-system"/> . You can do so
173
by using the <literal><package>@&pts-host;</literal> email
176
<!-- FIXME: moo@packages.d.o is easily confused with moo@packages.qa.d.o -->
179
<section id="mia-qa">
180
<title>Dealing with inactive and/or unreachable maintainers</title>
182
If you notice that a package is lacking maintenance, you should make sure that
183
the maintainer is active and will continue to work on their packages. It is
184
possible that they are not active any more, but haven't registered out of the
185
system, so to speak. On the other hand, it is also possible that they just
189
There is a simple system (the MIA database) in which information about
190
maintainers who are deemed Missing In Action is recorded. When a member of the
191
QA group contacts an inactive maintainer or finds more information about one,
192
this is recorded in the MIA database. This system is available in
193
/org/qa.debian.org/mia on the host qa.debian.org, and can be queried with a
194
tool known as <command>mia-query</command>. Use <command>mia-query --help</command>
195
to see how to query the database. If you find that no information has been
196
recorded about an inactive maintainer yet, or that you can add more
197
information, you should generally proceed as follows.
200
The first step is to politely contact the maintainer, and wait a reasonable
201
time for a response. It is quite hard to define reasonable time, but it is
202
important to take into account that real life is sometimes very hectic. One
203
way to handle this would be to send a reminder after two weeks.
206
If the maintainer doesn't reply within four weeks (a month), one can assume
207
that a response will probably not happen. If that happens, you should
208
investigate further, and try to gather as much useful information about the
209
maintainer in question as possible. This includes:
214
The echelon information available through the <ulink
215
url="&url-debian-db;">developers' LDAP database</ulink>, which indicates
216
when the developer last posted to a Debian mailing list. (This includes
217
uploads via debian-*-changes lists.) Also, remember to check whether the
218
maintainer is marked as on vacation in the database.
223
The number of packages this maintainer is responsible for, and the condition of
224
those packages. In particular, are there any RC bugs that have been open for
225
ages? Furthermore, how many bugs are there in general? Another important
226
piece of information is whether the packages have been NMUed, and if so, by
232
Is there any activity of the maintainer outside of Debian? For example, they
233
might have posted something recently to non-Debian mailing lists or news
239
A bit of a problem are packages which were sponsored — the maintainer is not
240
an official Debian developer. The echelon information is not available for
241
sponsored people, for example, so you need to find and contact the Debian
242
developer who has actually uploaded the package. Given that they signed the
243
package, they're responsible for the upload anyhow, and are likely to know what
244
happened to the person they sponsored.
247
It is also allowed to post a query to &email-debian-devel;,
248
asking if anyone is aware of the whereabouts of the missing maintainer. Please
249
Cc: the person in question.
252
Once you have gathered all of this, you can contact
253
&email-mia;. People on this alias will use the
254
information you provide in order to decide how to proceed. For example, they
255
might orphan one or all of the packages of the maintainer. If a package has
256
been NMUed, they might prefer to contact the NMUer before orphaning the package
257
— perhaps the person who has done the NMU is interested in the package.
260
One last word: please remember to be polite. We are all volunteers and cannot
261
dedicate all of our time to Debian. Also, you are not aware of the
262
circumstances of the person who is involved. Perhaps they might be seriously
263
ill or might even have died — you do not know who may be on the receiving
264
side. Imagine how a relative will feel if they read the e-mail of the deceased
265
and find a very impolite, angry and accusing message!
268
On the other hand, although we are volunteers, we do have a responsibility. So
269
you can stress the importance of the greater good — if a maintainer does not
270
have the time or interest anymore, they should let go and give the package to
271
someone with more time.
274
If you are interested in working in the MIA team, please have a look at the
275
README file in /org/qa.debian.org/mia on qa.debian.org where the technical
276
details and the MIA procedures are documented and contact
281
<section id="newmaint">
282
<title>Interacting with prospective Debian developers</title>
284
Debian's success depends on its ability to attract and retain new and talented
285
volunteers. If you are an experienced developer, we recommend that you get
286
involved with the process of bringing in new developers. This section
287
describes how to help new prospective developers.
289
<section id="sponsoring">
290
<title>Sponsoring packages</title>
292
Sponsoring a package means uploading a package for a maintainer who is not able
293
to do it on their own, a new maintainer applicant. Sponsoring a package also
294
means accepting responsibility for it.
296
<!-- FIXME: service down
298
If you wish to volunteer as a sponsor, you can sign up at <ulink
299
url="http://www.internatif.org/bortzmeyer/debian/sponsor/">http://www.internatif.org/bortzmeyer/debian/sponsor/</ulink>.
303
New maintainers usually have certain difficulties creating Debian packages —
304
this is quite understandable. That is why the sponsor is there, to check the
305
package and verify that it is good enough for inclusion in Debian. (Note that
306
if the sponsored package is new, the ftpmasters will also have to inspect it
307
before letting it in.)
310
Sponsoring merely by signing the upload or just recompiling is <emphasis
311
role="strong">definitely not recommended</emphasis>. You need to build the
312
source package just like you would build a package of your own. Remember that
313
it doesn't matter that you left the prospective developer's name both in the
314
changelog and the control file, the upload can still be traced to you.
317
If you are an application manager for a prospective developer, you can also be
318
their sponsor. That way you can also verify how the applicant is handling the
319
'Tasks and Skills' part of their application.
323
<section id="s7.5.2">
324
<title>Managing sponsored packages</title>
326
By uploading a sponsored package to Debian, you are certifying that the package
327
meets minimum Debian standards. That implies that you must build and test the
328
package on your own system before uploading.
331
You cannot simply upload a binary <filename>.deb</filename> from the sponsoree.
332
In theory, you should only ask for the diff file and the location of the
333
original source tarball, and then you should download the source and apply the
334
diff yourself. In practice, you may want to use the source package built by
335
your sponsoree. In that case, you have to check that they haven't altered the
336
upstream files in the <filename>.orig.tar.gz</filename> file that they're
340
Do not be afraid to write the sponsoree back and point out changes that need to
341
be made. It often takes several rounds of back-and-forth email before the
342
package is in acceptable shape. Being a sponsor means being a mentor.
345
Once the package meets Debian standards, build and sign it with
348
dpkg-buildpackage -k<replaceable>KEY-ID</replaceable>
351
before uploading it to the incoming directory. Of course, you can also use any
352
part of your <replaceable>KEY-ID</replaceable>, as long as it's unique in your
356
The Maintainer field of the <filename>control</filename> file and the
357
<filename>changelog</filename> should list the person who did the packaging,
358
i.e., the sponsoree. The sponsoree will therefore get all the BTS mail about
362
If you prefer to leave a more evident trace of your sponsorship job, you can
363
add a line stating it in the most recent changelog entry.
366
You are encouraged to keep tabs on the package you sponsor using <xref
367
linkend="pkg-tracking-system"/> .
371
<section id="s7.5.3">
372
<title>Advocating new developers</title>
374
See the page about <ulink
375
url="&url-newmaint-advocate;">advocating a prospective
376
developer</ulink> at the Debian web site.
380
<section id="s7.5.4">
381
<title>Handling new maintainer applications</title>
383
Please see <ulink url="&url-newmaint-amchecklist;">Checklist
384
for Application Managers</ulink> at the Debian web site.
added
removed
.svn/text-base/beyond-pkging.dbk.svn-base
