trunk/developers-reference/developer-duties.dbk

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
    "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
  <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
]>
<chapter id="developer-duties">
<title>Debian Developer's Duties</title>

<section id="package-maintainer-duties">
<title>Package Maintainer's Duties</title>
<para>As a package maintainer, you're supposed to provide
high-quality packages that are well integrated
in the system and that adhere to the Debian Policy.</para>

<section id="help-release">
<title>Work towards the next stable release</title>
<para>
Providing high-quality packages in unstable is not enough, most users will
only benefit from your packages when they are released as part of the next
stable release. You are thus expected to collaborate with the release team
to ensure your packages get included.
</para>
<para>
More concretely, you should monitor whether your packages are migrating
to testing (see <xref linkend="testing"/>). When the migration doesn't happen
after the test period, you should analyze why and work towards fixing this.
It might mean fixing your package (in the case of release-critical bugs or
failures to build on some architecture) but it can also mean updating (or
fixing, or removing from testing) other packages to help complete a
transition in which your package is entangled due to its dependencies. The
release team might provide you some input on the current blockers of a
given transition if you are not able to identify them.
</para>
</section>

<section id="maintain-stable">
<title>Maintain packages in stable</title>
<para>
Most of the package maintainer's work goes into providing updated
versions of packages in unstable, but his job also entails taking care
of the packages in the current stable release.
</para>
<para>
While changes in stable are discouraged, they are possible. Whenever a
security problem is reported, you should collaborate with the security
team to provide a fixed version (see <xref linkend="bug-security"/>). When
bugs of severity important (or more) are reported against the stable
version of your packages, you should consider providing a targeted fix.
You can ask the stable release team whether they would accept such an
update and then prepare a stable upload (see <xref
linkend="upload-stable"/>).
</para>
</section>

<section id="rc-bugs">
<title>Manage release-critical bugs</title>
<para>
Generally you should deal with bug reports on your packages as described in
<xref linkend="bug-handling"/>.  However, there's a special category of bugs
that you need to take care of — the so-called release-critical bugs (RC
bugs). All bug reports that have severity <literal>critical</literal>,
<literal>grave</literal> or <literal>serious</literal> make the package
unsuitable for inclusion in the next stable release.
They can thus delay the Debian release (when they affect a package in
testing) or block migrations to testing (when they only affect the package
in unstable). In the worst scenario, they will lead to the package's
removal. That's why these bugs need to be corrected as quickly as possible.
</para>
<para>
If, for any reason, you aren't able fix an RC bug in a
package of yours within 2 weeks (for example due to time constraints, or
because it's difficult to fix), you should mention it clearly in the
bug report and you should tag the bug "help" to invite other
volunteers to chime in. Be aware that RC bugs are frequently the targets
of Non-Maintainer Uploads (see <xref linkend="nmu"/>) because they
can block the testing migration of many packages.
</para>
<para>
Lack of attention to RC bugs is often interpreted by the QA team as a sign
that the maintainer has disappeared without properly orphaning his package.
The MIA team might also get involved, which could result in your packages
being orphaned (see <xref linkend="mia-qa" />).
</para>
</section>

<section id="upstream-coordination">
<title>Coordination with upstream developers</title>
<para>
A big part of your job as Debian maintainer will be to stay in contact with the
upstream developers.  Debian users will sometimes report bugs that are not
specific to Debian to our bug tracking system.  You have to forward these bug
reports to the upstream developers so that they can be fixed in a future
upstream release.
</para>
<para>
While it's not your job to fix non-Debian specific bugs, you may freely do so
if you're able.  When you make such fixes, be sure to pass them on to the
upstream maintainers as well.  Debian users and developers will sometimes
submit patches to fix upstream bugs — you should evaluate and forward these
patches upstream.
</para>
<para>
If you need to modify the upstream sources in order to build a policy compliant
package, then you should propose a nice fix to the upstream developers which
can be included there, so that you won't have to modify the sources of the next
upstream version.  Whatever changes you need, always try not to fork from the
upstream sources.
</para>
<para>
If you find that the upstream developers are or become hostile towards Debian
or the free software community, you may want to re-consider the need to
include the software in Debian. Sometimes the social cost to the
Debian community is not worth the benefits the software may bring.
</para>
</section>

</section>

<section id="administrative-duties">
<title>Administrative Duties</title>
<para>A project of the size of Debian relies on some administrative
infrastructure to keep track of everything. As a project member, you
have some duties to ensure everything keeps running smoothly.</para>

<section id="user-maint">
<title>Maintaining your Debian information</title>
<para>
There's a LDAP database containing information about Debian developers at
<ulink url="&url-debian-db;"></ulink>.  You should enter your
information there and update it as it changes.  Most notably, make sure that
the address where your debian.org email gets forwarded to is always up to date,
as well as the address where you get your debian-private subscription if you
choose to subscribe there.
</para>
<para>
For more information about the database, please see <xref linkend="devel-db"/>.
</para>
</section>

<section id="key-maint">
<title>Maintaining your public key</title>
<para>
Be very careful with your private keys.  Do not place them on any public
servers or multiuser machines, such as the Debian servers (see <xref
linkend="server-machines"/>).  Back your keys up; keep a copy offline.  Read
the documentation that comes with your software; read the <ulink
url="&url-pgp-faq;">PGP FAQ</ulink>.
</para>
<para>
You need to ensure not only that your key is secure against being stolen, but
also that it is secure against being lost.  Generate and make a copy (best also
in paper form) of your revocation certificate; this is needed if your key is
lost.
</para>
<para>
If you add signatures to your public key, or add user identities, you can
update the Debian key ring by sending your key to the key server at
<literal>&keyserver-host;</literal>.
</para>
<para>
If you need to add a completely new key or remove an old key, you need to get
the new key signed by another developer.  If the old key is compromised or
invalid, you also have to add the revocation certificate.  If there is no real
reason for a new key, the Keyring Maintainers might reject the new key.
Details can be found at <ulink
url="http://&keyserver-host;/replacing_keys.html"></ulink>.
</para>
<para>
The same key extraction routines discussed in <xref linkend="registering"/>
apply.
</para>
<para>
You can find a more in-depth discussion of Debian key maintenance in the
documentation of the <systemitem role="package">debian-keyring</systemitem>
package.
</para>
</section>

<section id="voting">
<title>Voting</title>
<para>
Even though Debian isn't really a democracy, we use a democratic process to
elect our leaders and to approve general resolutions.  These procedures are
defined by the <ulink url="&url-constitution;">Debian
Constitution</ulink>.
</para>
<para>
Other than the yearly leader election, votes are not routinely held, and they
are not undertaken lightly.  Each proposal is first discussed on the
&email-debian-vote; mailing list and it requires several
endorsements before the project secretary starts the voting procedure.
</para>
<para>
You don't have to track the pre-vote discussions, as the secretary will issue
several calls for votes on &email-debian-devel-announce; (and
all developers are expected to be subscribed to that list).  Democracy doesn't
work well if people don't take part in the vote, which is why we encourage all
developers to vote.  Voting is conducted via GPG-signed/encrypted email
messages.
</para>
<para>
The list of all proposals (past and current) is available on the <ulink
url="&url-vote;">Debian Voting Information</ulink> page, along
with information on how to make, second and vote on proposals.
</para>
</section>

<section id="inform-vacation">
<title>Going on vacation gracefully</title>
<para>
It is common for developers to have periods of absence, whether those are
planned vacations or simply being buried in other work.  The important thing to
notice is that other developers need to know that you're on vacation so that
they can do whatever is needed if a problem occurs with your packages or other
duties in the project.
</para>
<para>
Usually this means that other developers are allowed to NMU (see <xref
linkend="nmu"/>) your package if a big problem (release critical bug, security
update, etc.) occurs while you're on vacation.  Sometimes it's nothing as
critical as that, but it's still appropriate to let others know that you're
unavailable.
</para>
<para>
In order to inform the other developers, there are two things that you should
do.  First send a mail to <email>debian-private@&lists-host;</email> with
[VAC] prepended to the subject of your message<footnote><para> This is so that
the message can be easily filtered by people who don't want to read vacation
notices.  </para> </footnote> and state the period of time when you will be on
vacation.  You can also give some special instructions on what to do if a
problem occurs.
</para>
<para>
The other thing to do is to mark yourself as on vacation in the
<link linkend="devel-db">Debian developers' LDAP database</link> (this
information is only accessible to Debian developers).  Don't forget to remove
the on vacation flag when you come back!
</para>
<para>
Ideally, you should sign up at the <ulink
url="&url-gpg-coord;">GPG coordination pages</ulink> when booking a
holiday and check if anyone there is looking for signing.  This is especially
important when people go to exotic places where we don't have any developers
yet but where there are people who are interested in applying.
</para>
</section>

<section id="s3.7">
<title>Retiring</title>
<para>
If you choose to leave the Debian project, you should make sure you do the
following steps:
</para>
<orderedlist numeration="arabic">
<listitem>
<para>
Orphan all your packages, as described in <xref linkend="orphaning"/>.
</para>
</listitem>
<listitem>
<para>
Send an gpg-signed email about why you are leaving the project to
<email>debian-private@&lists-host;</email>.
</para>
</listitem>
<listitem>
<para>
Notify the Debian key ring maintainers that you are leaving by opening a ticket
in Debian RT by sending a mail to &email-keyring; with the words 'Debian
RT' somewhere in the subject line (case doesn't matter).
</para>
</listitem>
</orderedlist>
</section>
</section>

</chapter>

1	debacle	4902	<?xml version="1.0" encoding="utf-8"?>
2			<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
3	debacle	4910	"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
4	debacle	4911	<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
5	debacle	4910	]>
6	debacle	4902	<chapter id="developer-duties">
7			<title>Debian Developer's Duties</title>
8	hertzog	8577
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	hertzog	8579	<section id="help-release">
16			<title>Work towards the next stable release</title>
17			<para>
18			Providing high-quality packages in unstable is not enough, most users will
19			only benefit from your packages when they are released as part of the next
20			stable 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 testing (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 testing) 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 stable</title>
38			<para>
39			Most of the package maintainer's work goes into providing updated
40			versions of packages in unstable, but his job also entails taking care
41			of the packages in the current stable release.
42			</para>
43			<para>
44			While changes in stable 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 stable
48			version of your packages, you should consider providing a targeted fix.
49			You can ask the stable release team whether they would accept such an
50			update and then prepare a stable upload (see <xref
51			linkend="upload-stable"/>).
52			</para>
53			</section>
54
55	hertzog	8578	<section id="rc-bugs">
56	hertzog	8579	<title>Manage release-critical bugs</title>
57	hertzog	8578	<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	hertzog	8579	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 stable release.
64			They can thus delay the Debian release (when they affect a package in
65			testing) or block migrations to testing (when they only affect the package
66			in unstable). 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	hertzog	8578	</para>
69			<para>
70	hertzog	8579	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 "help" 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 testing migration of many packages.
77	hertzog	8578	</para>
78	hertzog	8579	<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 his 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	hertzog	8578	</section>
85	hertzog	8577
86	hertzog	8578	<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	hertzog	8577	</section>
116
117	hertzog	8578	</section>
118
119	hertzog	8577	<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	debacle	4902	<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	debacle	4910	<ulink url="&url-debian-db;"></ulink>. You should enter your
130	debacle	4902	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	taffit-guest	7422	For more information about the database, please see <xref linkend="devel-db"/>.
137	debacle	4902	</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	taffit-guest	7381	linkend="server-machines"/>). Back your keys up; keep a copy offline. Read
146	debacle	4902	the documentation that comes with your software; read the <ulink
147	debacle	4911	url="&url-pgp-faq;">PGP FAQ</ulink>.
148	debacle	4902	</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	debacle	4910	<literal>&keyserver-host;</literal>.
159	debacle	4902	</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	debacle	4910	url="http://&keyserver-host;/replacing_keys.html"></ulink>.
167	debacle	4902	</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	debacle	4910	defined by the <ulink url="&url-constitution;">Debian
185	debacle	4902	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	debacle	4911	&email-debian-vote; mailing list and it requires several
191			endorsements before the project secretary starts the voting procedure.
192	debacle	4902	</para>
193			<para>
194			You don't have to track the pre-vote discussions, as the secretary will issue
195	debacle	4911	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	debacle	4902	</para>
201			<para>
202			The list of all proposals (past and current) is available on the <ulink
203	debacle	4910	url="&url-vote;">Debian Voting Information</ulink> page, along
204	debacle	4902	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	taffit-guest	7381	linkend="nmu"/>) your package if a big problem (release critical bug, security
220	debacle	4902	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	debacle	4910	do. First send a mail to <email>debian-private@&lists-host;</email> with
227	debacle	4902	[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	taffit-guest	7381	url="&url-gpg-coord;">GPG coordination pages</ulink> when booking a
242	debacle	4902	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	taffit-guest	7381	Orphan all your packages, as described in <xref linkend="orphaning"/>.
258	debacle	4902	</para>
259			</listitem>
260			<listitem>
261			<para>
262			Send an gpg-signed email about why you are leaving the project to
263	debacle	4910	<email>debian-private@&lists-host;</email>.
264	debacle	4902	</para>
265			</listitem>
266			<listitem>
267			<para>
268			Notify the Debian key ring maintainers that you are leaving by opening a ticket
269	taffit-guest	7381	in Debian RT by sending a mail to &email-keyring; with the words 'Debian
270	debacle	4902	RT' somewhere in the subject line (case doesn't matter).
271			</para>
272			</listitem>
273			</orderedlist>
274			</section>
275	hertzog	8577	</section>
276	debacle	4902
277			</chapter>
278