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