Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
Hi Lucas,
Thanks for coming back on this.
On Thu, Oct 11, 2012 at 12:04:33AM +0200, Lucas Nussbaum wrote:
> On 28/09/12 at 18:48 +0200, Arno Töll wrote:
> > 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.
> >
> > [...]
>
> Hi,
>
> So, reading this thread (which was surprisingly quiet, given the topic),
> it seems that everybody agrees that such a procedure would be a good
> thing (nobody had fundamental concerns). But now we have two proposed
> procedures:
> - one which is based on a set of criterias
> - one which is based on seconds
>
> It seems that the second[s] one gets slightly more traction, but requires
> some minor changes:
> - the submitter of the "intent to orphan" bug must Cc
> debian-qa@lists.debian.org, and file the bug with severity:serious (this
> was part of the "criterias" proposal).
> This aims at increasing the publicity of the process, thus avoiding the
> "cabal" effect where a group of DDs secretly act together to orphan a
> package: everybody can watch the flow of orphanings and react if necessary.
Yes, the cc to debian-qa is a good idea for the reason you described. I'm not
sure about severity:serious but I don't object.
>
> - the number of seconds should probably be tuned a bit. For example, people
> could also NACK the proposal to orphan the package. I propose that we wait
> until:
> + three DD have ACKed the proposal (not counting the initial submitter)
> AND
> + a 3/1 majority is reached between ACKers and NACKers (same as the TC
> for overriding developers)
Yes, including NACKs the way you described is an improvement.
>
> So, how do we move forward?
> It seems we need someone to update the proposal, and turn it into a form
> suitable for further comments
Here's an updated proposal based on the second propsal using criteria from the
first proposal and using some of your newest comments :
| Anyone can mark a package as orphaned after the following steps have been
| completed : Someone submits an "intent to orphan" (ITO) in the bts with an
| explanation of why he/she thinks that the package needs a new maintainer. The
| explanation should cover aspects like how long there was no visible activity,
| whether there are NMUs not yet acknowledged, wheter the package blocks progress
| elsewhere in Debian, release critical bugs, public comments from the maintainer
| revealing lack of interest in the package, ... etc. The bug must have severity
| "serious" and a cc must be sent to the debian-qa mailing list. Anyone can
| submit this "intent to orphan". At least three DDs (not counting the initial
| submitter) second the "intent to orphan" on the same bug report with a cc to
| the maintainer. If some DDs send NACKs instead, then a 3/1 majority is needed
| between ACKers and NACKers. And the maintainer does not respond within one
| month after the the third second. During this process anyone is welcome to add
| comments on the bug.
> (typically a draft dev-ref patch).
I have not yet done that, but I'm willing to do that once we've reached a
larger consensus on the text.
>
> Some ideas:
> - the proposal should stress that everybody is welcomed to participate in the
> discussion, even if only DDs can ACK/NACK. Specifically, having feedback
> from users is always very useful in those discussions.
I've added that in the updated text above.
> - the proposal should include a list of criterias the the submitter could
> check to reinforce his initial email: the more "proofs" that the package is
> a good target, the better. The criterias from Arno's proposal look very
> good as a starting point.
I have added some of them in the updated text above. I have skipped the part
about the MIA database because I want people without access to the MIA database
to be able to submit an "intent to orphan". The three DDs adding seconds can
still consult the MIA database.
> - the proposal could stress that the proposed adopter can start working on
> the package right away and use NMUs to address open issues.
In my opinion, the NMU procedure already sufficiently describes when an NMU is
appropriate. I suggest to simply follow the existing NMU rules.
>
> I don't think that we need something big like a GR to make the process active.
> This could probably simply be described as a recommended procedure in dev-ref:
> that way, in case of backfire, people following the procedure would have the
> backing of a recommended procedure described in a semi-official document.
I agree that the procedure should at least be included in developers-reference.
I have no strong opinion on whether a GR would be needed.
>
> So, any takers for shaping up an updated proposal? I will probably try to do it
> if nobody does it by the end of the month.
See updated text above. I'm looking forward to a consensus.
Regards,
Bart Martens
Reply to: