chiark / gitweb /
Removed mention of Gandi's discontinued discount.
[developers-reference.git] / developer-duties.dbk
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;
5 ]>
6 <chapter id="developer-duties">
7 <title>Debian Developer's Duties</title>
8
9 <section id="package-maintainer-duties">
10 <title>Package Maintainer's Duties</title>
11 <para>As a package maintainer, you're supposed to provide
12 high-quality packages that are well integrated
13 in the system and that adhere to the Debian Policy.</para>
14
15 <section id="help-release">
16 <title>Work towards the next <literal>stable</literal> release</title>
17 <para>
18 Providing high-quality packages in <literal>unstable</literal> is not enough, most users will
19 only benefit from your packages when they are released as part of the next
20 <literal>stable</literal> release. You are thus expected to collaborate with the release team
21 to ensure your packages get included.
22 </para>
23 <para>
24 More concretely, you should monitor whether your packages are migrating
25 to <literal>testing</literal> (see <xref linkend="testing"/>). When the migration doesn't happen
26 after the test period, you should analyze why and work towards fixing this.
27 It might mean fixing your package (in the case of release-critical bugs or
28 failures to build on some architecture) but it can also mean updating (or
29 fixing, or removing from <literal>testing</literal>) other packages to help complete a
30 transition in which your package is entangled due to its dependencies. The
31 release team might provide you some input on the current blockers of a
32 given transition if you are not able to identify them.
33 </para>
34 </section>
35
36 <section id="maintain-stable">
37 <title>Maintain packages in <literal>stable</literal></title>
38 <para>
39 Most of the package maintainer's work goes into providing updated
40 versions of packages in <literal>unstable</literal>, but their job also entails taking care
41 of the packages in the current <literal>stable</literal> release.
42 </para>
43 <para>
44 While changes in <literal>stable</literal> are discouraged, they are possible. Whenever a
45 security problem is reported, you should collaborate with the security
46 team to provide a fixed version (see <xref linkend="bug-security"/>). When
47 bugs of severity important (or more) are reported against the <literal>stable</literal>
48 version of your packages, you should consider providing a targeted fix.
49 You can ask the <literal>stable</literal> release team whether they would accept such an
50 update and then prepare a <literal>stable</literal> upload (see <xref
51 linkend="upload-stable"/>).
52 </para>
53 </section>
54
55 <section id="rc-bugs">
56 <title>Manage release-critical bugs</title>
57 <para>
58 Generally you should deal with bug reports on your packages as described in
59 <xref linkend="bug-handling"/>.  However, there's a special category of bugs
60 that you need to take care of — the so-called release-critical bugs (RC
61 bugs). All bug reports that have severity <literal>critical</literal>,
62 <literal>grave</literal> or <literal>serious</literal> make the package
63 unsuitable for inclusion in the next <literal>stable</literal> release.
64 They can thus delay the Debian release (when they affect a package in
65 <literal>testing</literal>) or block migrations to <literal>testing</literal> (when they only affect the package
66 in <literal>unstable</literal>). In the worst scenario, they will lead to the package's
67 removal. That's why these bugs need to be corrected as quickly as possible.
68 </para>
69 <para>
70 If, for any reason, you aren't able fix an RC bug in a
71 package of yours within 2 weeks (for example due to time constraints, or
72 because it's difficult to fix), you should mention it clearly in the
73 bug report and you should tag the bug <literal>help</literal> to invite other
74 volunteers to chime in. Be aware that RC bugs are frequently the targets
75 of Non-Maintainer Uploads (see <xref linkend="nmu"/>) because they
76 can block the <literal>testing</literal> migration of many packages.
77 </para>
78 <para>
79 Lack of attention to RC bugs is often interpreted by the QA team as a sign
80 that the maintainer has disappeared without properly orphaning their package.
81 The MIA team might also get involved, which could result in your packages
82 being orphaned (see <xref linkend="mia-qa" />).
83 </para>
84 </section>
85
86 <section id="upstream-coordination">
87 <title>Coordination with upstream developers</title>
88 <para>
89 A big part of your job as Debian maintainer will be to stay in contact with the
90 upstream developers.  Debian users will sometimes report bugs that are not
91 specific to Debian to our bug tracking system.  You have to forward these bug
92 reports to the upstream developers so that they can be fixed in a future
93 upstream release.
94 </para>
95 <para>
96 While it's not your job to fix non-Debian specific bugs, you may freely do so
97 if you're able.  When you make such fixes, be sure to pass them on to the
98 upstream maintainers as well.  Debian users and developers will sometimes
99 submit patches to fix upstream bugs — you should evaluate and forward these
100 patches upstream.
101 </para>
102 <para>
103 If you need to modify the upstream sources in order to build a policy compliant
104 package, then you should propose a nice fix to the upstream developers which
105 can be included there, so that you won't have to modify the sources of the next
106 upstream version.  Whatever changes you need, always try not to fork from the
107 upstream sources.
108 </para>
109 <para>
110 If you find that the upstream developers are or become hostile towards Debian
111 or the free software community, you may want to re-consider the need to
112 include the software in Debian. Sometimes the social cost to the
113 Debian community is not worth the benefits the software may bring.
114 </para>
115 </section>
116
117 </section>
118
119 <section id="administrative-duties">
120 <title>Administrative Duties</title>
121 <para>A project of the size of Debian relies on some administrative
122 infrastructure to keep track of everything. As a project member, you
123 have some duties to ensure everything keeps running smoothly.</para>
124
125 <section id="user-maint">
126 <title>Maintaining your Debian information</title>
127 <para>
128 There's a LDAP database containing information about Debian developers at
129 <ulink url="&url-debian-db;"></ulink>.  You should enter your
130 information there and update it as it changes.  Most notably, make sure that
131 the address where your debian.org email gets forwarded to is always up to date,
132 as well as the address where you get your debian-private subscription if you
133 choose to subscribe there.
134 </para>
135 <para>
136 For more information about the database, please see <xref linkend="devel-db"/>.
137 </para>
138 </section>
139
140 <section id="key-maint">
141 <title>Maintaining your public key</title>
142 <para>
143 Be very careful with your private keys.  Do not place them on any public
144 servers or multiuser machines, such as the Debian servers (see <xref
145 linkend="server-machines"/>).  Back your keys up; keep a copy offline.  Read
146 the documentation that comes with your software; read the <ulink
147 url="&url-pgp-faq;">PGP FAQ</ulink>.
148 </para>
149 <para>
150 You need to ensure not only that your key is secure against being stolen, but
151 also that it is secure against being lost.  Generate and make a copy (best also
152 in paper form) of your revocation certificate; this is needed if your key is
153 lost.
154 </para>
155 <para>
156 If you add signatures to your public key, or add user identities, you can
157 update the Debian key ring by sending your key to the key server at
158 <literal>&keyserver-host;</literal>.
159 </para>
160 <para>
161 If you need to add a completely new key or remove an old key, you need to get
162 the new key signed by another developer.  If the old key is compromised or
163 invalid, you also have to add the revocation certificate.  If there is no real
164 reason for a new key, the Keyring Maintainers might reject the new key.
165 Details can be found at <ulink
166 url="http://&keyserver-host;/replacing_keys.html"></ulink>.
167 </para>
168 <para>
169 The same key extraction routines discussed in <xref linkend="registering"/>
170 apply.
171 </para>
172 <para>
173 You can find a more in-depth discussion of Debian key maintenance in the
174 documentation of the <systemitem role="package">debian-keyring</systemitem>
175 package.
176 </para>
177 </section>
178
179 <section id="voting">
180 <title>Voting</title>
181 <para>
182 Even though Debian isn't really a democracy, we use a democratic process to
183 elect our leaders and to approve general resolutions.  These procedures are
184 defined by the <ulink url="&url-constitution;">Debian
185 Constitution</ulink>.
186 </para>
187 <para>
188 Other than the yearly leader election, votes are not routinely held, and they
189 are not undertaken lightly.  Each proposal is first discussed on the
190 &email-debian-vote; mailing list and it requires several
191 endorsements before the project secretary starts the voting procedure.
192 </para>
193 <para>
194 You don't have to track the pre-vote discussions, as the secretary will issue
195 several calls for votes on &email-debian-devel-announce; (and
196 all developers are expected to be subscribed to that list).  Democracy doesn't
197 work well if people don't take part in the vote, which is why we encourage all
198 developers to vote.  Voting is conducted via GPG-signed/encrypted email
199 messages.
200 </para>
201 <para>
202 The list of all proposals (past and current) is available on the <ulink
203 url="&url-vote;">Debian Voting Information</ulink> page, along
204 with information on how to make, second and vote on proposals.
205 </para>
206 </section>
207
208 <section id="inform-vacation">
209 <title>Going on vacation gracefully</title>
210 <para>
211 It is common for developers to have periods of absence, whether those are
212 planned vacations or simply being buried in other work.  The important thing to
213 notice is that other developers need to know that you're on vacation so that
214 they can do whatever is needed if a problem occurs with your packages or other
215 duties in the project.
216 </para>
217 <para>
218 Usually this means that other developers are allowed to NMU (see <xref
219 linkend="nmu"/>) your package if a big problem (release critical bug, security
220 update, etc.) occurs while you're on vacation.  Sometimes it's nothing as
221 critical as that, but it's still appropriate to let others know that you're
222 unavailable.
223 </para>
224 <para>
225 In order to inform the other developers, there are two things that you should
226 do.  First send a mail to <email>debian-private@&lists-host;</email> with
227 [VAC] prepended to the subject of your message<footnote><para> This is so that
228 the message can be easily filtered by people who don't want to read vacation
229 notices.  </para> </footnote> and state the period of time when you will be on
230 vacation.  You can also give some special instructions on what to do if a
231 problem occurs.
232 </para>
233 <para>
234 The other thing to do is to mark yourself as on vacation in the
235 <link linkend="devel-db">Debian developers' LDAP database</link> (this
236 information is only accessible to Debian developers).  Don't forget to remove
237 the on vacation flag when you come back!
238 </para>
239 <para>
240 Ideally, you should sign up at the <ulink
241 url="&url-gpg-coord;">GPG coordination pages</ulink> when booking a
242 holiday and check if anyone there is looking for signing.  This is especially
243 important when people go to exotic places where we don't have any developers
244 yet but where there are people who are interested in applying.
245 </para>
246 </section>
247
248 <section id="s3.7">
249 <title>Retiring</title>
250 <para>
251 If you choose to leave the Debian project, you should make sure you do the
252 following steps:
253 </para>
254 <orderedlist numeration="arabic">
255 <listitem>
256 <para>
257 Orphan all your packages, as described in <xref linkend="orphaning"/>.
258 </para>
259 </listitem>
260 <listitem>
261 <para>
262 Send an gpg-signed email about why you are leaving the project to
263 <email>debian-private@&lists-host;</email>.
264 </para>
265 </listitem>
266 <listitem>
267 <para>
268 Notify the Debian key ring maintainers that you are leaving by opening a ticket
269 in Debian RT by sending a mail to &email-keyring; with the words 'Debian
270 RT' somewhere in the subject line (case doesn't matter).
271 </para>
272 </listitem>
273 </orderedlist>
274 <para>
275 It is important that the above process is followed, because finding inactive
276 developers and orphaning their packages takes significant time and effort.
277 </para>
278 </section>
279
280 <section id="returning">
281 <title>Returning after retirement</title>
282 <para>
283 A retired developer's account is marked as "emeritus" when the process in
284 <xref linkend="s3.7"/> is followed, and "disabled" otherwise. Retired
285 developers with an "emeritus" account can get their account re-activated as
286 follows:
287 </para>
288
289 <itemizedlist>
290 <listitem>
291 <para>
292 Contact &email-debian-account-manager;.
293 </para>
294 </listitem>
295 <listitem>
296 <para>
297 Go through a shortened NM process (to ensure that the returning developer
298 still knows important parts of P&amp;P and T&amp;S).
299 </para>
300 </listitem>
301 <listitem>
302 <para>
303 Prove that they still control the GPG key associated with the account, or
304 provide proof of identify on a new GPG key, with at least two signatures from
305 other developers.
306 </para>
307 </listitem>
308 </itemizedlist>
309 <para>
310 Retired developers with a "disabled" account need to go through NM again.
311 </para>
312 </section>
313 </section>
314
315 </chapter>
316