Dear fellow Debinites,
many of you know already that there is currently a discussion about
establishing a package salvaging process within Debian. The discussion
is taking place at debian-devel, but I'd like make people aware which
are not subscribed to -devel.
For those how did not knew about it, the thread starts at:
https://lists.debian.org/debian-devel/2018/07/msg00453.html,
The forwarded mail is the call for discussion and sent to
-devel last Sunday: (I've updated the Wiki text as some people already
contributed with some language fixes to the text)
You can find the original mail here:
https://lists.debian.org/debian-devel/2018/08/msg00277.html
Note that I've set Reply-To to -devel to avoid having too much noise on
-announce. Please reply to -devel, (I hope I have set the email headers
correctly ;-))
Thanks for your attention!
--
tobi
----- Forwarded message from Tobias Frost <tobi@debian.org> -----
Date: Sun, 19 Aug 2018 18:06:47 +0200
From: Tobias Frost <tobi@debian.org>
To: debian-devel@lists.debian.org
Subject: Let's start salvaging packages! -- draft text now available
User-Agent: Mutt/1.10.1 (2018-07-13)
Dear -devel,
as announced earlier, I have together with worked on the text for the
salvaging process. You can find the texts here: Titanpad [1] for dev-ref
and the accompanying Wikipage [2]. Credits to Pierre-Elliott Bécue, as
he wrote the first draft and thereby helped me a lot.
For the timeline, as earlier communicated I think we should discuss this
until Sepember 1st and then I will start incooporating received intput
to have a final text available soon.
[1] https://pad.riseup.net/p/debian-salvaging-packages-keep
[2] https://wiki.debian.org/PackageSalvaging
For your convenience (and for easier replies) here is the full text
for bith parts (the dev-ref part and the wiki raw text).
(The dev-ref needs modification in 5.9.5, therefore this is provided as
a patch.)
Cheers,
--
tobi
Patch for section 5.9.5: ("Adopting a package")
-----------------------------------------------
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -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 you 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
--- (end of patch)
Text for section between nmu (5.11) and collaborative maintaince (5.12)
=======================================================================
<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, appear 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
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
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
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
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>
<para> For an addtional informations, 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>
<para>
A package becomes elible 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
an idea what to look for: </para>
<itemizedlist>
<listitem> <para>NMUs, especially if there have 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
</para></listitem>
<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
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.
</para>
</section>
<section id="ps-guidelines">
<title>How to salvage a package </title>
<para>
<emphasis>Only</emphasis> if a package has been determined to be eligble
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 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
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,
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.
</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
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
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
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.
</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
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
<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.
</para>
</listitem>
</orderedlist>
</section>
</section>
Wiki-Page:
#language en
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: none-~
----
'''WIP -- this process is still being made and not effective at the moment.'''
Package Salvaging is the process by which, one attempts to save a
package that, while not officially orphaned, appear 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
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.
For the description of the package salvaging process, please see the
Developer's reference <add link when ready here>.
<<TableOfContents(2)>>
== Eligibility requirements for a package ==
=== How to use the criteria ===
The following criteria can be used to determine whether a package is
eligible for salvaging or not. This criteria are conservative on
purpose, to enable especially new maintainers to assess the eligibility
without the need to fear for be called a hijacker later. More
experienced maintainers are allowed to deviate from them on a
case-by-case basis but must be prepared to defend their point of view
when challenged.
=== The (conservative) criteria ===
A package is eligible for salvaging if it is in clear need of some love
and care, i.e. there are ''open bugs'', ''missing upstream releases'',
or there is ''work needed'' from a ''quality-assurance perspective'';
<<BR>> '''AND''' there is the ''need to upload the package'' to deal
with these issues; <<BR>> '''AND''' at least ''one'' of these criteria
applies:
* There is no visible activity regarding the package for '''six months''', '''OR'''
* A previous NMU was not acknowledged, and a bug justifying another NMU
is pending for '''one month''' <<footnote(A NMU is automatically
ACKED if there is a subsequent upload of the maintainer including the
content/fixes of the NMU.)>>, '''OR'''
* The last upload was an NMU and there was no maintainer upload within '''one year''', '''OR'''
* Bugs exist for more than one major missing upstream
version<<footnote(Can also be one bug, constantly modified when new
upstream versions became available)>> and the first bug is older than
'''one year''', '''OR'''
* The package blocks a sourceful transition for '''six months''' after
a transition bug was filed against the package in question.
The Level of activity should be defined "in favor" of the maintainer if
in doubt. A maintainer may ask for help or welcome a NMU. This counts as
activity with respect to salvage criteria. If a package lacks uploads,
there is no visible bug triaging or no answers to bugs at all, and – if
applicable – the source package's VCS does not show commits, this is an
indication, that the package is not well maintained.
== FAQs ==
'''Q: Are team maintained packages also subject to salvaging?'''<<BR>>
A: Team-maintained packages are not really special in this aspect and
the process should be applicable for them too. Like any maintainer and
uploader on the package, members of the listed packaging team can also
actively veto or allow salvaging (but not against the expressed will of
the maintainer).
'''Q: The salvaging step says that I might be offered co-maintainership
instead, but this is not something I want to do. Or the maintainer asks
me to be maintainer instead of co-maintainer, but I do not want to do
this. Do I have to? Do I really have to join the team or offer the
salvager to join the team? ''' <<BR>>
A: Of course you are not obliged to do anything in Debian you do not
want to. On the other hand, you cannot salvage a package if the current
maintainer/uploaders/team disagrees with the conditions. On the other
hand, those offers provides beneficial opportunities to all parties, so
they should be at least considered. Beside, I encourage you to discuss
that with the maintainers/teams to find mutually agreeable solutions.
'''Q: The new upstream version is not suitable for Debian! How can I
avoid my package being salvaged?'''<<BR>>
'''Q: I do not have time to
fix that bug at the moment, but I will do so before the freeze. How to
avoid being salvaged?'''<<BR>>
A: Explain that in a response to the bug in question. That's activity
shown on the package and makes it ineligible for salvaging. (Though it
would be great if you could add some background information/explanations
as well.)
'''Q: There are many loopholes in the process, allowing a (malicious)
maintainer to game things!'''<<BR>>
A: The process foundation is on "honest" maintainers not wanting to harm
Debian on purpose. (for which we'd have other kind of processes).
Attachment:
signature.asc
Description: PGP signature