Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal (original) (raw)
- To: Development of Debian <debian-devel@lists.debian.org>, debian-qa <debian-qa@lists.debian.org>
- Subject: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
- From: Arno Töll <arno@debian.org>
- Date: Fri, 28 Sep 2012 18:48:22 +0200
- Message-id: <[🔎] 5065D4D6.9070005@debian.org>
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.
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.
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).
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.
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
Reply to:
- Follow-Ups:
- Prev by Date:FTWCA irker (another CIA.vc alternative)
- Next by Date:Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
- Previous by thread:FTWCA irker (another CIA.vc alternative)
- Next by thread:Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
- Index(es):