#: developer-duties.dbk:7 msgid "Debian Developer's Duties" msgstr "" #. type: Content of: <chapter><section><title> #: developer-duties.dbk:10 msgid "Package Maintainer's Duties" msgstr "" #. type: Content of: <chapter><section><para> #: developer-duties.dbk:11 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:16 msgid "Work towards the next <literal>stable</literal> release" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:18 msgid "" "Providing high-quality packages in <literal>unstable</literal> is not " "enough, most users will only benefit from your packages when they are " "released as part of the next <literal>stable</literal> release. You are thus " "expected to collaborate with the release team to ensure your packages get " "included." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:24 msgid "" "More concretely, you should monitor whether your packages are migrating to " "<literal>testing</literal> (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 <literal>testing</literal>) " "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:37 msgid "Maintain packages in <literal>stable</literal>" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:39 msgid "" "Most of the package maintainer's work goes into providing updated versions " "of packages in <literal>unstable</literal>, but his job also entails taking " "care of the packages in the current <literal>stable</literal> release." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:44 msgid "" "While changes in <literal>stable</literal> 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 <literal>stable</literal> version of your packages, you " "should consider providing a targeted fix. You can ask the " "<literal>stable</literal> release team whether they would accept such an " "update and then prepare a <literal>stable</literal> upload (see <xref " "linkend=\"upload-stable\"/>)." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:56 msgid "Manage release-critical bugs" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:58 msgid "" "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 <literal>stable</literal> release. " "They can thus delay the Debian release (when they affect a package in " "<literal>testing</literal>) or block migrations to " "<literal>testing</literal> (when they only affect the package in " "<literal>unstable</literal>). 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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:70 msgid "" "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 <literal>help</literal> 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 " "<literal>testing</literal> migration of many packages." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:79 msgid "" "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\" />)." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:87 msgid "Coordination with upstream developers" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:89 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:96 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:103 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:110 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><title> #: developer-duties.dbk:120 msgid "Administrative Duties" msgstr "" #. type: Content of: <chapter><section><para> #: developer-duties.dbk:121 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:126 msgid "Maintaining your Debian information" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:128 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:136 msgid "" "For more information about the database, please see <xref " "linkend=\"devel-db\"/>." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:141 msgid "Maintaining your public key" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:143 msgid "" "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>." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:150 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:156 msgid "" "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>." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:161 msgid "" "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>." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:169 msgid "" "The same key extraction routines discussed in <xref " "linkend=\"registering\"/> apply." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:173 msgid "" "You can find a more in-depth discussion of Debian key maintenance in the " "documentation of the <systemitem " "role=\"package\">debian-keyring</systemitem> package." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:180 msgid "Voting" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:182 msgid "" "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>." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:188 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:194 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:202 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:209 msgid "Going on vacation gracefully" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:211 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:218 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para><footnote><para> #: developer-duties.dbk:227 msgid "" "This is so that the message can be easily filtered by people who don't want " "to read vacation notices." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:225 msgid "" "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<placeholder " "type=\"footnote\" id=\"0\"/> 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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:234 msgid "" "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!" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:240 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:249 msgid "Retiring" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:251 msgid "" "If you choose to leave the Debian project, you should make sure you do the " "following steps:" msgstr "" #. type: Content of: <chapter><section><section><orderedlist><listitem><para> #: developer-duties.dbk:257 msgid "Orphan all your packages, as described in <xref linkend=\"orphaning\"/>." msgstr "" #. type: Content of: <chapter><section><section><orderedlist><listitem><para> #: developer-duties.dbk:262 msgid "" "Send an gpg-signed email about why you are leaving the project to " "<email>debian-private@&lists-host;</email>." msgstr "" #. type: Content of: <chapter><section><section><orderedlist><listitem><para> #: developer-duties.dbk:268 msgid "" "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)." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:275 msgid "" "It is important that the above process is followed, because finding inactive " "developers and orphaning their packages takes significant time and effort." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:281 msgid "Returning after retirement" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:283 msgid "" "A retired developer's account is marked as \"emeritus\" when the process in " "<xref linkend=\"s3.7\"/> is followed, and \"disabled\" otherwise. Retired " "developers with an \"emeritus\" account can get their account re-activated " "as follows:" msgstr "" #. type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: developer-duties.dbk:292 msgid "Contact &email-debian-account-manager;." msgstr "" #. type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: developer-duties.dbk:297 msgid "" "Go through a shortened NM process (to ensure that the returning developer " "still knows important parts of P&P and T&S)." msgstr "" #. type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: developer-duties.dbk:303 msgid "" "Prove that they still control the GPG key associated with the account, or " "provide proof of identify on a new GPG key, with at least two signatures " "from other developers." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:310 msgid "Retired developers with a \"disabled\" account need to go through NM again." msgstr ""

# SOME DESCRIPTIVE TITLE # Copyright (C) YEAR Free Software Foundation, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2011-09-10 14:01-0400\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: Content of: #: developer-duties.dbk:7 msgid "Debian Developer's Duties" msgstr "" #. type: Content of: <chapter><section><title> #: developer-duties.dbk:10 msgid "Package Maintainer's Duties" msgstr "" #. type: Content of: <chapter><section><para> #: developer-duties.dbk:11 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:16 msgid "Work towards the next <literal>stable</literal> release" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:18 msgid "" "Providing high-quality packages in <literal>unstable</literal> is not " "enough, most users will only benefit from your packages when they are " "released as part of the next <literal>stable</literal> release. You are thus " "expected to collaborate with the release team to ensure your packages get " "included." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:24 msgid "" "More concretely, you should monitor whether your packages are migrating to " "<literal>testing</literal> (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 <literal>testing</literal>) " "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:37 msgid "Maintain packages in <literal>stable</literal>" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:39 msgid "" "Most of the package maintainer's work goes into providing updated versions " "of packages in <literal>unstable</literal>, but his job also entails taking " "care of the packages in the current <literal>stable</literal> release." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:44 msgid "" "While changes in <literal>stable</literal> 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 <literal>stable</literal> version of your packages, you " "should consider providing a targeted fix. You can ask the " "<literal>stable</literal> release team whether they would accept such an " "update and then prepare a <literal>stable</literal> upload (see <xref " "linkend=\"upload-stable\"/>)." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:56 msgid "Manage release-critical bugs" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:58 msgid "" "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 <literal>stable</literal> release. " "They can thus delay the Debian release (when they affect a package in " "<literal>testing</literal>) or block migrations to " "<literal>testing</literal> (when they only affect the package in " "<literal>unstable</literal>). 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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:70 msgid "" "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 <literal>help</literal> 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 " "<literal>testing</literal> migration of many packages." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:79 msgid "" "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\" />)." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:87 msgid "Coordination with upstream developers" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:89 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:96 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:103 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:110 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><title> #: developer-duties.dbk:120 msgid "Administrative Duties" msgstr "" #. type: Content of: <chapter><section><para> #: developer-duties.dbk:121 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:126 msgid "Maintaining your Debian information" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:128 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:136 msgid "" "For more information about the database, please see <xref " "linkend=\"devel-db\"/>." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:141 msgid "Maintaining your public key" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:143 msgid "" "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>." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:150 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:156 msgid "" "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>." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:161 msgid "" "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>." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:169 msgid "" "The same key extraction routines discussed in <xref " "linkend=\"registering\"/> apply." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:173 msgid "" "You can find a more in-depth discussion of Debian key maintenance in the " "documentation of the <systemitem " "role=\"package\">debian-keyring</systemitem> package." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:180 msgid "Voting" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:182 msgid "" "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>." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:188 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:194 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:202 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:209 msgid "Going on vacation gracefully" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:211 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:218 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><para><footnote><para> #: developer-duties.dbk:227 msgid "" "This is so that the message can be easily filtered by people who don't want " "to read vacation notices." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:225 msgid "" "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<placeholder " "type=\"footnote\" id=\"0\"/> 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." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:234 msgid "" "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!" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:240 msgid "" "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." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:249 msgid "Retiring" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:251 msgid "" "If you choose to leave the Debian project, you should make sure you do the " "following steps:" msgstr "" #. type: Content of: <chapter><section><section><orderedlist><listitem><para> #: developer-duties.dbk:257 msgid "Orphan all your packages, as described in <xref linkend=\"orphaning\"/>." msgstr "" #. type: Content of: <chapter><section><section><orderedlist><listitem><para> #: developer-duties.dbk:262 msgid "" "Send an gpg-signed email about why you are leaving the project to " "<email>debian-private@&lists-host;</email>." msgstr "" #. type: Content of: <chapter><section><section><orderedlist><listitem><para> #: developer-duties.dbk:268 msgid "" "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)." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:275 msgid "" "It is important that the above process is followed, because finding inactive " "developers and orphaning their packages takes significant time and effort." msgstr "" #. type: Content of: <chapter><section><section><title> #: developer-duties.dbk:281 msgid "Returning after retirement" msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:283 msgid "" "A retired developer's account is marked as \"emeritus\" when the process in " "<xref linkend=\"s3.7\"/> is followed, and \"disabled\" otherwise. Retired " "developers with an \"emeritus\" account can get their account re-activated " "as follows:" msgstr "" #. type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: developer-duties.dbk:292 msgid "Contact &email-debian-account-manager;." msgstr "" #. type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: developer-duties.dbk:297 msgid "" "Go through a shortened NM process (to ensure that the returning developer " "still knows important parts of P&P and T&S)." msgstr "" #. type: Content of: <chapter><section><section><itemizedlist><listitem><para> #: developer-duties.dbk:303 msgid "" "Prove that they still control the GPG key associated with the account, or " "provide proof of identify on a new GPG key, with at least two signatures " "from other developers." msgstr "" #. type: Content of: <chapter><section><section><para> #: developer-duties.dbk:310 msgid "Retired developers with a \"disabled\" account need to go through NM again." msgstr ""