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="rc-bugs">
  16 <title>Managing release-critical bugs</title>
  17 <para>
  18 Generally you should deal with bug reports on your packages as described in
  19 <xref linkend="bug-handling"/>.  However, there's a special category of bugs
  20 that you need to take care of — the so-called release-critical bugs (RC
  21 bugs).  All bug reports that have severity <literal>critical</literal>,
  22 <literal>grave</literal> or <literal>serious</literal> are considered to
  23 have an impact on whether the package can be released in the next stable
  24 release of Debian.  These bugs can delay the Debian release and/or can justify
  25 the removal of a package at freeze time.  That's why these bugs need to be
  26 corrected as quickly as possible.
  27 </para>
  28 <para>
  29 Developers who are part of the <ulink url="&url-debian-qa;">Quality
  30 Assurance</ulink> group are following all such bugs, and trying to help
  31 whenever possible.  If, for any reason, you aren't able fix an RC bug in a
  32 package of yours within 2 weeks, you should either ask for help by sending a
  33 mail to the Quality Assurance (QA) group
  34 <email>debian-qa@&lists-host;</email>, or explain your difficulties and
  35 present a plan to fix them by sending a mail to the bug report.  Otherwise,
  36 people from the QA group may want to do a Non-Maintainer Upload (see <xref
  37 linkend="nmu"/>) after trying to contact you (they might not wait as long as
  38 usual before they do their NMU if they have seen no recent activity from you in
  39 the BTS).
  40 </para>
  41 </section>
  42
  43 <section id="upstream-coordination">
  44 <title>Coordination with upstream developers</title>
  45 <para>
  46 A big part of your job as Debian maintainer will be to stay in contact with the
  47 upstream developers.  Debian users will sometimes report bugs that are not
  48 specific to Debian to our bug tracking system.  You have to forward these bug
  49 reports to the upstream developers so that they can be fixed in a future
  50 upstream release.
  51 </para>
  52 <para>
  53 While it's not your job to fix non-Debian specific bugs, you may freely do so
  54 if you're able.  When you make such fixes, be sure to pass them on to the
  55 upstream maintainers as well.  Debian users and developers will sometimes
  56 submit patches to fix upstream bugs — you should evaluate and forward these
  57 patches upstream.
  58 </para>
  59 <para>
  60 If you need to modify the upstream sources in order to build a policy compliant
  61 package, then you should propose a nice fix to the upstream developers which
  62 can be included there, so that you won't have to modify the sources of the next
  63 upstream version.  Whatever changes you need, always try not to fork from the
  64 upstream sources.
  65 </para>
  66 <para>
  67 If you find that the upstream developers are or become hostile towards Debian
  68 or the free software community, you may want to re-consider the need to
  69 include the software in Debian. Sometimes the social cost to the
  70 Debian community is not worth the benefits the software may bring.
  71 </para>
  72 </section>
  73
  74 </section>
  75
  76 <section id="administrative-duties">
  77 <title>Administrative Duties</title>
  78 <para>A project of the size of Debian relies on some administrative
  79 infrastructure to keep track of everything. As a project member, you
  80 have some duties to ensure everything keeps running smoothly.</para>
  81
  82 <section id="user-maint">
  83 <title>Maintaining your Debian information</title>
  84 <para>
  85 There's a LDAP database containing information about Debian developers at
  86 <ulink url="&url-debian-db;"></ulink>.  You should enter your
  87 information there and update it as it changes.  Most notably, make sure that
  88 the address where your debian.org email gets forwarded to is always up to date,
  89 as well as the address where you get your debian-private subscription if you
  90 choose to subscribe there.
  91 </para>
  92 <para>
  93 For more information about the database, please see <xref linkend="devel-db"/>.
  94 </para>
  95 </section>
  96
  97 <section id="key-maint">
  98 <title>Maintaining your public key</title>
  99 <para>
 100 Be very careful with your private keys.  Do not place them on any public
 101 servers or multiuser machines, such as the Debian servers (see <xref
 102 linkend="server-machines"/>).  Back your keys up; keep a copy offline.  Read
 103 the documentation that comes with your software; read the <ulink
 104 url="&url-pgp-faq;">PGP FAQ</ulink>.
 105 </para>
 106 <para>
 107 You need to ensure not only that your key is secure against being stolen, but
 108 also that it is secure against being lost.  Generate and make a copy (best also
 109 in paper form) of your revocation certificate; this is needed if your key is
 110 lost.
 111 </para>
 112 <para>
 113 If you add signatures to your public key, or add user identities, you can
 114 update the Debian key ring by sending your key to the key server at
 115 <literal>&keyserver-host;</literal>.
 116 </para>
 117 <para>
 118 If you need to add a completely new key or remove an old key, you need to get
 119 the new key signed by another developer.  If the old key is compromised or
 120 invalid, you also have to add the revocation certificate.  If there is no real
 121 reason for a new key, the Keyring Maintainers might reject the new key.
 122 Details can be found at <ulink
 123 url="http://&keyserver-host;/replacing_keys.html"></ulink>.
 124 </para>
 125 <para>
 126 The same key extraction routines discussed in <xref linkend="registering"/>
 127 apply.
 128 </para>
 129 <para>
 130 You can find a more in-depth discussion of Debian key maintenance in the
 131 documentation of the <systemitem role="package">debian-keyring</systemitem>
 132 package.
 133 </para>
 134 </section>
 135
 136 <section id="voting">
 137 <title>Voting</title>
 138 <para>
 139 Even though Debian isn't really a democracy, we use a democratic process to
 140 elect our leaders and to approve general resolutions.  These procedures are
 141 defined by the <ulink url="&url-constitution;">Debian
 142 Constitution</ulink>.
 143 </para>
 144 <para>
 145 Other than the yearly leader election, votes are not routinely held, and they
 146 are not undertaken lightly.  Each proposal is first discussed on the
 147 &email-debian-vote; mailing list and it requires several
 148 endorsements before the project secretary starts the voting procedure.
 149 </para>
 150 <para>
 151 You don't have to track the pre-vote discussions, as the secretary will issue
 152 several calls for votes on &email-debian-devel-announce; (and
 153 all developers are expected to be subscribed to that list).  Democracy doesn't
 154 work well if people don't take part in the vote, which is why we encourage all
 155 developers to vote.  Voting is conducted via GPG-signed/encrypted email
 156 messages.
 157 </para>
 158 <para>
 159 The list of all proposals (past and current) is available on the <ulink
 160 url="&url-vote;">Debian Voting Information</ulink> page, along
 161 with information on how to make, second and vote on proposals.
 162 </para>
 163 </section>
 164
 165 <section id="inform-vacation">
 166 <title>Going on vacation gracefully</title>
 167 <para>
 168 It is common for developers to have periods of absence, whether those are
 169 planned vacations or simply being buried in other work.  The important thing to
 170 notice is that other developers need to know that you're on vacation so that
 171 they can do whatever is needed if a problem occurs with your packages or other
 172 duties in the project.
 173 </para>
 174 <para>
 175 Usually this means that other developers are allowed to NMU (see <xref
 176 linkend="nmu"/>) your package if a big problem (release critical bug, security
 177 update, etc.) occurs while you're on vacation.  Sometimes it's nothing as
 178 critical as that, but it's still appropriate to let others know that you're
 179 unavailable.
 180 </para>
 181 <para>
 182 In order to inform the other developers, there are two things that you should
 183 do.  First send a mail to <email>debian-private@&lists-host;</email> with
 184 [VAC] prepended to the subject of your message<footnote><para> This is so that
 185 the message can be easily filtered by people who don't want to read vacation
 186 notices.  </para> </footnote> and state the period of time when you will be on
 187 vacation.  You can also give some special instructions on what to do if a
 188 problem occurs.
 189 </para>
 190 <para>
 191 The other thing to do is to mark yourself as on vacation in the
 192 <link linkend="devel-db">Debian developers' LDAP database</link> (this
 193 information is only accessible to Debian developers).  Don't forget to remove
 194 the on vacation flag when you come back!
 195 </para>
 196 <para>
 197 Ideally, you should sign up at the <ulink
 198 url="&url-gpg-coord;">GPG coordination pages</ulink> when booking a
 199 holiday and check if anyone there is looking for signing.  This is especially
 200 important when people go to exotic places where we don't have any developers
 201 yet but where there are people who are interested in applying.
 202 </para>
 203 </section>
 204
 205 <section id="s3.7">
 206 <title>Retiring</title>
 207 <para>
 208 If you choose to leave the Debian project, you should make sure you do the
 209 following steps:
 210 </para>
 211 <orderedlist numeration="arabic">
 212 <listitem>
 213 <para>
 214 Orphan all your packages, as described in <xref linkend="orphaning"/>.
 215 </para>
 216 </listitem>
 217 <listitem>
 218 <para>
 219 Send an gpg-signed email about why you are leaving the project to
 220 <email>debian-private@&lists-host;</email>.
 221 </para>
 222 </listitem>
 223 <listitem>
 224 <para>
 225 Notify the Debian key ring maintainers that you are leaving by opening a ticket
 226 in Debian RT by sending a mail to &email-keyring; with the words 'Debian
 227 RT' somewhere in the subject line (case doesn't matter).
 228 </para>
 229 </listitem>
 230 </orderedlist>
 231 </section>
 232 </section>
 233
 234 </chapter>
 235