Hello,
we may all agree that the maintenance of some (many?) packages in Debian
is in a unclear situation. There is a transient state, where people are
interested to bring a package in shape but the strong role of a package
maintainer in Debian effectively blocks any commitment beyond fixing
important issues in minimally invasive non-maintainer uploads.
I realize this is going to be controversial (a bit?), but eventually I'm
hoping to allow people to make Debian better. Truth is, as a good
citizen of Debian Town, there few possibilities for unapproved changes
someone else's packages.
Therefore, this is not an approach to take packages away from people.
Instead, I'm trying to find a procedure where people don't need to be
afraid of the good work they are interested to deliver, while there is a
good chance, the original maintainer is unavailable and unresponsive for
a substantial time. Our goal ought to be to make Debian better - if
people are interested to make a package better, why should we refuse
their work?
Prior discussion on that matter was on this year's DebConf [6][7]. While
I didn't base my work directly on the argumentation from that DebConf
BoF, many ideas I am proposing are being derived from it. I tried to
address concerns, but also problems mentioned there.
Some more work was approached by Michael Gilbert in #681833 [8],
introducing "liberal NMUs", a concept to weaken the NMU requirements in
case of a maintainer missing in action. Note, my proposal (somewhat) is
in conflict with this proposal.
The actual proposal follows below, but first let me address some questions:
Q: Why do you call it a salvage, not hijack? You DO eventually hijack a
package
Well, that's right. As for me, I do not mind continue to call my salvage
process a hijack, if people prefer. However, the term hijacking has a
negative connotation, implying a rude and hostile action. My "weak
hijack", however, tries to be as nice to (previous) maintainers as
possible. Also, I'm trying to work out explicitly what I mean by
"salvaging" and what I still consider to be a "hijack".
Having that said, I am not interested to debate later on whether a
package was salvaged or whether it was hijacked ("You waited 23 seconds
too little - you hijacked it!"). So, please, let's concentrate on facts,
not wording.
Q: What? You only want to wait X weeks before considering a package
unmaintained? or, alternatively: What? Why do you want me to wait so
long, until the package is finally considered orphaned?
Truth is, we won't ever agree on that. I tried to find a compromise
being longer than any usual or typical vacation or "work has caught me"
period, but shorter than a typical Debian release cycle letting people
time to actually work on a package.
Having that said, I'm entirely open to any other waiting times, people
may find more appropriate.
While I am taking the blame for piping this proposal to a larger
audience, I'd like to thank gregor herrmann, Laurent Bigonville, David
Prévot, Stuart Prescott and Steve McIntyre, Jakub Wilk for commenting
previously and working out this proposal together with me.
Actual proposal follows:
Adopting an unmaintained package
===========================
Packages being marked as orphaned, or those being up for adoption can be
immediately taken over. This is currently the status quo. The wnpp
pseudo-package [1][2] holds packages being up for adoption ("RFA" bugs),
or being orphaned ("O" bugs). Moreover, packages maintained by the QA
Team [3] can be taken over without further discussion.
Salvaging a package
=================
Salvaging is the process by which, one attempts to save a package from a
state where it is poorly maintained or appears not maintained at all,
without being officially orphaned. This is a weaker and faster procedure
than orphaning a package officially through powers of the MIA team [4].
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 maintainer transition for a
single package only, leaving any other package or Debian membership or
upload rights (when applicable) untouched. However, during the salvage
process, the MIA team will be informed (see below). This might be
considered by them as a kick-off to start the MIA procedure as well.
That's a desired side effect when found beneficial by MIA team members.
Reasons to salvage a package
----------------------------------------
The package 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; AND there is the need to upload the
package to deal with these issues; AND at least one of these criterias
applies:
* There is no visible activity regarding the package [5] for /six months/.
* There is no visible activity regarding the package [5], and the
maintainer of the package in question is tracked in the MIA database
already, and there was no recorded activity in the MIA tracker for
/three months/.
* A previous NMU was not acknowledged, and at least another issue
justifying another NMU is pending for /one month/ [5].
* The last upload was an NMU and there was no maintainer upload within
/one year/.
* The package blocks a sourceful transition or the implementation of a
release goal for /six months/ after a transition or release goal bug was
filed against the package in question.
Procedure to salvage a package
-----------------------------------------
If any of the criteria denoted above are fulfilled, anyone interested
can start the salvage procedure. For Debian Developers, it should be
checked whether they are on vacation.
1) A bug with severity "serious" against the package in question must be
filed, expressing the intent to take over maintainership of the package.
The reporter may also offer co-maintenance of the package.
2) The maintainer, or any current uploader of the package in question
may object publicly in response to the bug filed within 14 days. Of
course, current maintainers may also agree to the intent to salvage a
package by filing a (signed) public response to the bug. In such a case,
a new package can be uploaded immediately thereafter by the new
maintainer(s).
3) After waiting at least the required 14 days, another warning must be
sent to the bug report, this time also the MIA team shall be informed
and all maintainers or uploaders of the package shall be contacted
explicitly as well.
4) After waiting another 14 days, the package can be salvaged. An upload
replacing the former maintainers of the package can be made. The salvage
bug should be closed by maintainer upload, and the DELAYED/7 queue
should be used for the upload.
Hijacking a package
================
Hijacking a package should be considered as a very last step. Hijacking
a package happens, whenever a package does not qualify for the salvaging
criteria above, and was not formally orphaned by the MIA team either.
Also, any case where any salvage criterion is fulfilled, but the current
maintainer of a package explicitly objects to give up his package is
considered a hijack, if no agreement can be found otherwise.
In such cases the maintainer must be overruled by a resolution of the
Technical Committee (tech-ctte).
[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp
[2] http://wnpp.debian.net/?sort=installs;desc
[3] http://qa.debian.org/developer.php?login=packages@qa.debian.org
[4] http://wiki.debian.org/qa.debian.org/MIATeam
[5] Activity may 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 criterias. If a package lacks uploads, there is
no visible bug triaging, and - if applicable - the source package's VCS
does not show commits this is an indication, a package lacks an active
maintainer.
[6] http://penta.debconf.org/dc12_schedule/events/926.en.html
[7] https://lists.debian.org/debian-project/2012/07/msg00003.html
[8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681833
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
Attachment:
signature.asc
Description: OpenPGP digital signature