...
 
Commits (40)
......@@ -675,7 +675,7 @@ maintainer script.
If you need to check for the existence of a command, you should use something
like
</para>
<programlisting>if which install-docs > /dev/null; then ...</programlisting>
<programlisting>&if-which-install-docs;</programlisting>
<para>
You can use this function to search <varname>$PATH</varname> for a command
name, passed as an argument. It returns true (zero) if the command was found,
......
......@@ -20,7 +20,7 @@
<!ENTITY codename-oldstable "jessie">
<!ENTITY codename-stable "stretch">
<!ENTITY codename-testing "buster">
<!ENTITY codename-nexttesting "buster">
<!ENTITY codename-nexttesting "bullseye">
<!ENTITY version-oldoldstable "7.0">
<!ENTITY version-oldstable "8">
<!ENTITY version-stable "9">
......@@ -110,6 +110,7 @@
<!ENTITY url-ddtp "http://ddtp2.debian.net/">
<!ENTITY url-l10n "https://&www-debian-org;/intl/l10n/">
<!ENTITY url-dep3 "http://dep.debian.net/deps/dep3/">
<!ENTITY url-wiki-salvaging-packages "https://wiki.debian.org/PackageSalvaging">
<!ENTITY url-incoming "http://incoming.debian.org/">
<!ENTITY url-testing-maint "https://www.debian.org/devel/testing">
......@@ -140,6 +141,7 @@
<!ENTITY url-pgp-faq "http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/">
<!ENTITY url-rfc2440 "https://www.rfc-editor.org/rfc/rfc2440.txt">
<!ENTITY url-openpgp-best-practices "https://riseup.net/en/security/message-security/openpgp/best-practices">
<!ENTITY url-openpgp-best-practices-de "https://riseup.net/de/security/message-security/openpgp/best-practices">
<!ENTITY url-openprojects "https://www.freenode.net/">
<!ENTITY url-oftc "http://www.oftc.net/oftc/">
<!ENTITY url-l10n-tp "https://translationproject.org/html/welcome.html">
......@@ -188,6 +190,8 @@
<!ENTITY cron-bug-report '0 17 * * fri echo "index maint <replaceable>address</replaceable>" | mail request@&bugs-host;'>
<!ENTITY if-which-install-docs "if which install-docs > /dev/null; then ...">
<!--
misc, non-debian
-->
......
This diff is collapsed.
......@@ -140,6 +140,8 @@ For more information about the database, please see <xref linkend="devel-db"/>.
<section id="key-maint">
<title>Maintaining your public key</title>
<para>
<!-- TRANSLATORS: For &url-openpgp-best-practices translated versions exits. Please
link to those. See common.ent (German translation) for an example.-->
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
......
......@@ -1471,15 +1471,20 @@ packages listed in the WNPP, please take a look at the aforementioned page for
information and procedures.
</para>
<para>
It is not OK to simply take over a package that you feel is neglected — that
would be package hijacking. You can, of course, contact the current maintainer
and ask them if you may take over the package. If you have reason to believe a
maintainer has gone AWOL (absent without leave), see <xref linkend="mia-qa"/>.
It is not OK to simply take over a package without assent
of the current maintainer — that would be package hijacking.
You can, of course, contact the current maintainer and ask them for
permission to take over the package.
</para>
<para>
Generally, you may not take over the package without the assent of the current
maintainer. Even if they ignore you, that is still not grounds to take over a
package. Complaints about maintainers should be brought up on the developers'
However, when a package has been neglected by the maintainer, you might
be able to take over package maintainership by following the package
salvaging process as described in <xref linkend="package-salvaging"/>.
If you have reason to believe a maintainer is no longer active at all,
see <xref linkend="mia-qa"/>.
</para>
<para>
Complaints about maintainers should be brought up on the developers'
mailing list. If the discussion doesn't end with a positive conclusion, and
the issue is of a technical nature, consider bringing it to the attention of
the technical committee (see the <ulink
......@@ -2334,6 +2339,145 @@ start your changelog entry with the following line:
</section>
<section id="package-salvaging">
<title>Package Salvaging</title>
<para>
Package salvaging is the process by which one attempts to save a
package that, while not officially orphaned, appears poorly maintained or
completely unmaintained. This is a weaker and faster procedure than
orphaning a package officially through the powers of the MIA team.
Salvaging a package is not meant to replace MIA handling, and differs
in that it does not imply anything about the overall activity of a
maintainer. Instead, it handles a package maintainership transition for
a single package only, leaving any other package or Debian membership or
upload rights (when applicable) untouched.</para>
<para> Note that the process is only intended for actively taking over
maintainership. Do not start a package salvaging process when you do not intend
to maintain the package for a prolonged time. If you only want to fix certain
things, but not take over the package, you must use the NMU process,
even if the package would be eligible for salvaging. The NMU process is
explained in <xref linkend="nmu"/>.</para>
<para> Another important thing to remember: It is not acceptable to
hijack others' packages. If followed, this salvaging process will help
you to ensure that your endeavour is not a hijack but a (legal)
salvaging procedure, and you can counter any allegations of hijacking with a
reference to this process. Thanks to this process, new contributors should no
longer be afraid to take over packages that have been neglected or entirely
forgotten.</para>
<para> The process is split into two phases: In the first phase you
determine whether the package in question is
<emphasis>eligible</emphasis> for the salvaging process. Only when the
eligibility has been determined you may enter the second phase, the
<emphasis>actual</emphasis> package salvaging. </para>
<para> For additional information, rationales and FAQs on package
salvaging, please visit the <ulink
url="&url-wiki-salvaging-packages;">Salvaging Packages</ulink> page on the Debian
wiki.</para>
<section id="ps-eligibility">
<title>When a package is eligible for package salvaging</title>
<para>
A package becomes eligible for salvaging when it has been neglected by the
current maintainer. To determine that a package has really been
neglected by the maintainer, the following indicators give
a rough idea what to look for: </para>
<itemizedlist>
<listitem> <para>NMUs, especially if there has been more than one NMU
in a row. </para></listitem>
<listitem> <para>Bugs filed against the package do not have answers
from the maintainer. </para></listitem>
<listitem> <para>Upstream has released several versions, but despite
there being a bug entry asking for it, it has not been packaged.
</para></listitem>
<listitem> <para>There are QA issues with the package.
</para> </listitem>
</itemizedlist>
<para>
You will have to use your judgement as to whether a given combination
factors constitutes neglect; in case the maintainer disagrees they have
only to say so (see below). If you're not sure about your judgement or
simply want to be on the safe side, there is a more precise (and
conservative) set of conditions in the <ulink
url="&url-wiki-salvaging-packages;">Package Salvaging</ulink> wiki
page. These conditions represent a current Debian consensus on
salvaging criteria. In any case you should explain your reasons for
thinking the package is neglected when you file an Intent to Salvage bug
later.
</para>
</section>
<section id="ps-guidelines">
<title>How to salvage a package </title>
<para>
If and <emphasis>only</emphasis> if a package has been determined to be eligible
for package salvaging, any prospective maintainer may start the following
package salvaging procedure. </para>
<orderedlist numeration="arabic">
<listitem> <para> Open a bug with the severity "important" against the package
in question, expressing the intent to take over maintainership of the package.
For this, the title of the bug should start with <literal>ITS:
package-name</literal><footnote><para>ITS is shorthand for <emphasis>"Intend
to Salvage"</emphasis></para></footnote>. You may alternatively offer to only
take co-maintenance of the package. When you file the bug, you must inform
all maintainers, uploaders and if applicable the packaging team explicitly by
adding them to <literal>X-Debbugs-CC</literal>. Additionally, if the
maintainer(s) seem(s) to be generally inactive, please inform the MIA team by
adding <literal>mia@qa.debian.org</literal> to <literal>X-Debbugs-CC</literal>
as well. As well as the explicit expression of the intent to salvage, please
also take the time to document your assessment of the eligibility in the bug
report, for example by listing the criteria you've applied and adding some
data to make it easier for others to assess the situation.
</para></listitem>
<listitem> <para>
In this step you need to wait in case any objections to the salvaging are
raised; the maintainer, any current uploader or any member of the associated
packaging team of the package in question may object publicly in response to
the bug you've filed within <literal>21 days</literal>, and this terminates
the salvaging process. </para>
<para>The current maintainers may also agree
to your intent to salvage by filing a (signed) public response to the the bug.
They might propose that you become a co-maintainer instead of the sole
maintainer. On team maintained packages, a member of the associated team can
accept your salvaging proposal by sending out a signed agreement notice to the
ITS bug, alternatively inviting you to become a new co-maintainer of the
package. The team may require you to keep the package under the team's
umbrella, but then may ask or invite you to join the team. In any of these
cases where you have received the OK to proceed, you can upload the new
package immediately as the new (co-)maintainer, without the need to utilise
the <literal>DELAYED</literal> queue as described in the next step.
</para> </listitem>
<listitem> <para>
After the 21 days delay, if no answer has been sent to the bug from the
maintainer, one of the uploaders or team, you may upload the new release of
the package into the <literal>DELAYED</literal> queue with a minimum delay of
<literal>seven days</literal>. You should close the salvage bug in the
changelog and you must also send an nmudiff to the bug ensuring that copies
are sent to the maintainer and any uploaders (including teams) of the package
by <literal>CC'ing</literal> them in the mail to the BTS. </para>
<para>
During the waiting time of the <literal>DELAYED</literal> queue, the
maintainer can accept the salvaging, do an upload themselves or (ask to)
cancel the upload. The latter two of these will also stop the salvaging
process, but the maintainer must reply to the salvaging bug with more
information about their action.
</para> </listitem>
</orderedlist>
</section>
</section>
<section id="collaborative-maint">
<title>Collaborative maintenance</title>
<para>
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.