Dear all,
so, I think we are now ready to proceed in the topic of the salaving
process...
The changes on the text on the etherpad and wiki were mostly only of
editorial nature, like spelling, grammar and wiki syntax fixes and
rewordings to make it less awkyard for native speakers. Again, thanks to
all the editors!
The only exception is, that I've added a clause to the wiki, that
changes to the conservative criteria needs discussion and consent with
debian-devel as discussion platform.
As a consequence that there was not too much changes to be incorporated,
we are quite in ahead of the anticipated schedule [1], because due to
that "adapting text to input received" is already done and as there were
no substantional changes, there'd be not much to review either.
So I propose that I start working on the patch against dev-ref in the
next few days, latest next weekend. (If you see that different and
object, let me know).
For the Wiki, you can see the changes here:
https://wiki.debian.org/PackageSalvaging?action=diff&rev2=19&rev1=11
For the etherpad, I paste the diff below.
[1] https://lists.debian.org/debian-devel/2018/08/msg00207.html
Cheers,
--
tobi
For your convenience, links to the texts:
https://pad.riseup.net/p/debian-salvaging-packages-keep
https://wiki.debian.org/PackageSalvaging
Diff of the etherpad (between revision 5826 and latest, which is 6161)
--- debian-salvaging-packages-keep-5826.txt 2018-09-02 18:22:11.581817797 +0200
+++ debian-salvaging-packages-keep-6161.txt 2018-09-02 18:19:51.127549284 +0200
@@ -1,5 +1,7 @@
# Package Salvaging
+
+
# Links:
BoF: https://debconf18.debconf.org/talks/149-lets-start-salvaging-packages/
Thread: https://lists.debian.org/debian-devel/2018/07/msg00453.html
@@ -56,71 +58,71 @@
<title>Package Salvaging</title>
<para>
-Package salvaging is the process by which, one attempts to save a
-package that, while not officially orphaned, appear poorly maintained or
+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 powers of the MIA team.
-Salvaging a package is not meant to replace MIA handling, and in
-contrast to it, it does not comment about the overall activity of a
+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 do salvaging, when you do not intend to maintain
+maintainership. Do not do salvaging when you do not intend to maintain
the package for a prolonged time. If you only want to fix certain
-things, but not taking over the package, you must use the NMU process,
-even if the package would be eligble for salvaing. The NMU process is
+things, but not take over the package, you must use the NMU process,
+even if the package would be eligble 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 endaveour is not a hijack, but a (legal)
-salvaging procedure and you can counter any allegations of hijack with a
-reference to this process. This ensurance should especially help new
+you to ensure that your endeavor is not a hijack but a (legal)
+salvaging procedure, and you can counter any allegations of hijacking with a
+reference to this process. This should especially help new
maintainers to Debian to have confidence taking over packages by
salvaging. </para>
<para> The process is split into two phases: In the first phase you
determine whether the package in question is
-<emphasis>eligble</emphasis> for the salvaging process. Only when the
-eligbiliy has been determined, you can enter the second phase, the
-<emphasis>actual</emphasis> package salvalging. </para>
+<emphasis>eligible</emphasis> for the salvaging process. Only when the
+eligibiliy has been determined can you enter the second phase, the
+<emphasis>actual</emphasis> package salvaging. </para>
-<para> For an addtional informations, rationales and FAQs on package
+<para> For additional information, rationales and FAQs on package
salvaging, please visit the <ulink
url="&wiki-salvaging-packages;">Salvaging Packages page on the Debian
wiki</ulink>. </para>
<section id="ps-eligibility">
-<title>When a package is eligble for package salvaging</title>
+<title>When a package is eligible for package salvaging</title>
<para>
-A package becomes elible for salvaging when it has been neglected by the
+A package becomes eligible for salvaging when it has been neglected by the
current maintainer. To determine that a package has really been
-negelected by the maintainer, the following coarse indicators might give
+neglected by the maintainer, the following rough indicators might give
an idea what to look for: </para>
<itemizedlist>
- <listitem> <para>NMUs, especially if there have been more than one NMU
+ <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
- a bug entry exists asking for it, it has not been packaged
+ there being a bug entry asking for it, it has not been packaged.
</para></listitem>
- <listitem> <para>There are QA issues with the package
+ <listitem> <para>There are QA issues with the package.
</para> </listitem>
</itemizedlist>
<para>
-As said, the above list is only a very coarse. The wiki page <ulink
+Again, the above list is only a very rough guide. The wiki page <ulink
url="&wiki-salvaging-packages;">Salvaging Packages</ulink> expands on
-eligbility criterias for package salvaging, you are recommended follow
-them to determine eligbility. Though you are allowed to deviate from
-the guidlines on a case-by-case basis, but you will be required to
-document the deviations and your reasoning when filing the intent to
-salvage bug later.
+eligibility criteria for package salvaging; you are recommended to follow
+them to determine eligibility. Though you are allowed to deviate from
+the guidelines on a case-by-case basis, you will be required to
+document the deviations and your reasoning when filing the Intent to
+Salvage bug later.
</para>
</section>
@@ -129,7 +131,7 @@
<title>How to salvage a package </title>
<para>
-<emphasis>Only</emphasis> if a package has been determined to be eligble
+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>
@@ -140,59 +142,59 @@
question, expressing the intent to take over maintainership of the
package. For this, the bug-title should start with <literal>ITS:
package-name</literal>v<<footnote(ITS is shorthand for
- <emphasis>"Intend to Salvage"</emphasis>)>>. You may also offer
+ <emphasis>"Intend to Salvage"</emphasis>)>>. 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-Debuggs-CC.</literal>.
- Additionally, if the maintainer(s) seems to be generally inactive,
+ 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. Beside the explicit expression of the intent to salvage,
- please also take the time to document your assessment of the eligbilty,
- for example by listing the criterias you've applied and add some data to
- make it more easy to assess the situation for others.
+ as well. As well as the explicit expression of the intent to salvage,
+ please also take the time to document your assessment of the eligibilty,
+ 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 if there are any objection to the
- salvaging brought up: The maintainer, any current uploader or any member
+ 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 offer you
- to become co-maintainer instead of the sole maintainer. On team
+ 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 an signed agreement notice to the ITS
- bug, alternatively inviting you to become a new Co-Maintainer of the
+ 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 may ask or invite you to join the team. In any of these
- cases where you have gotten the OK to proceed, you can uploaded the new
- package immediately as the new (co-)maintainer(s), without the need to
- utlize the DELAYED queue as described in the next step.
+ 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
+ utilize the DELAYED queue as described in the next step.
</para>
</listitem>
<listitem>
<para>
- After the 21 days delay, if no answer from the maintainer, one of the
- uploaders or team has been sent to the bug, you may upload the new
- release of the packaged into the <literal>DELAYED QUEUE</literal> with a
+ 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 send an nmudiff to the bug
- along with the upload and ensure that copies being sent to the
- maintainer and any uploader – including teams – of the package by
+ 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 DELAY queue, the maintainer can accept
- the salvaging, do an upload themselves or (ask to) cancel the upload.
- The latter two which will also stop the salvaging process, but the
- maintainer must reply to the salvaging bug with more information about
- their action.
+ 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>
Attachment:
signature.asc
Description: PGP signature