Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
On 11/10/12 at 05:50 +0000, Bart Martens wrote:
> | 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.
I'm not sure about this delay. This procedure should be used for
uncontroversial cases, where orphaning is obviously the right choice.
If it's not that obvious, of course common sense dictates to wait for
some time to give the maintainer time to comment. But that can also be
achieved by someone NACKing saying "Mmmh, I'm not so sure about that,
there hasn't been any big task awaiting action from the maintainer.
Are you really sure that the maintainer would understand that the
current level of maintenance is suboptimal? Have you tried re-contacting
him?"
Maybe rephrase that into "Before taking action, it could also be a good
idea to wait for comments from the maintainer, especially if he/she is
otherwise active in Debian."
> During this process anyone is welcome to add
> | comments on the bug.
Maybe rephrase into:
During the process, everyone is of course welcomed and encouraged to
contribute to the discussion. Comments from users of the package that
suffer from the level of maintenance are especially useful.
> > - 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.
I like the fact that this process focuses on *packages* and not on
*maintainers*. This makes thing a lot less confrontational. So I'm fine
with not including MIA in the checklist, since this typically focuses on
the maintainer.
> > - 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.
OK, fair enough
Lucas
Reply to: