[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Tue, Oct 23, 2012 at 11:27:43AM +0200, Lucas Nussbaum wrote:
> Hi,
> Here is an attempt at summarizing & building a proposal out of the
> "Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal"
> thread that was started at [1].
> The following aims at being written in a form suitable for inclusion in 
> developers-reference.
> -------------------------------------------------------------->8
> Orphaning another maintainer's packages
> It is not uncommon for some packages to end up in an unclear situation,
> with a maintainer without enough time to maintain them properly. The NMU
> procedure (described in developers-reference section 5.11) enables other
> contributors to fix severe problems when a maintainer is unavailable,
> but maintaining packages through NMUs is not a viable long term
> solution, and it is sometimes required to transfer the maintenance of a
> package to another contributor.
> This section describes the recommended procedure to orphan a package,
> thus giving candidate adopters the possibility to take over the
> maintenance of a package. This procedure aims at being efficient at
> addressing simple and obvious cases. It is not suitable for more
> difficult or controversial cases (e.g. active but non-cooperative
> maintainer) -- in such cases, the issue should be brought to the
> Technical Committee, as described in the Debian Constitution, section
> 6.1.
> 1. Someone opens an ITO (Intent to Orphan) bug against the package whose 
>    orphaning is suggested, with the 'serious' severity. The submitter
>    notifies debian-qa@lists.debian.org (e.g. using X-Debbugs-Cc:
>    debian-qa@lists.debian.org) of the process.  The MIA team should also
>    be notified (by Ccing mia@qa.debian.org) if the situation affects
>    several packages.  The bug report should contain a detailed analysis
>    of the state of the package, explaining why it should be orphaned.
>    The analysis should focus on the package, not on the maintainer,
>    and great care should be taken to avoid formulations that would 
>    be offensive for the maintainer.
>    Relevant information include: release critical bugs, whether
>    the package blocks progress elsewhere in Debian, history of NMUs,
>    lack of any recent activity on that package by the maintainer, public
>    comments of the maintainer showing a lack of intesting in the package, 
>    previous attempts to contact the maintainer, etc.
> 2. The submitter should seek comments from the package maintainer 
>    (e.g., by sending a private mail notifying him/her of the process).
> 3. Debian Developers can then ACK or NACK the proposed orphaning (using
>    signed mails sent to the bug and to debian-qa@lists.debian.org).
>    Everybody is welcomed to contribute to the discussion, e.g. to comment
>    on problems experienced by users due to the level of maintenance.
> 4. When/if consensus has been reached, the package can be orphaned by
>    retitling and reassigning the ITO bug accordingly. It is recommended to
>    wait for at least a 3/1 majority between ACKers and NACKers (and to give
>    a couple of days for potential NACKers to speak up).
>    In some cases, it is also recommended to give additional time for the
>    maintainer to respond, especially if the maintainer is otherwise active
>    in Debian.
>    Finally, it should be remembered that this procedure is designed for 
>    obvious and simple cases. More complex cases should be forwarded to the 
>    technical committee.
> ------------------------------------------------------------->8

This text is OK for me.

> Some things mentioned in the thread:
> Q: (from Ian Jackson in [2]) A successful salvage is then a quiet
> operation where we take this burden from the maintainer and they don't
> have to feel too bad about it. [...] I don't think seconding fits well
> into this.  It would encourage dogpiles and noise.  If it achieves
> anything it will be to make the maintainer feel worse and perhaps make
> them stubborn.
> A: I agree, but I think that the benefits of a public process outweight
> this problem... Note that -qa@ is not a very visible list, though, and
> that I've tried to reinforce the "focus on the package, not on the
> maintainer" point in the proposal.

I'm with Lucas on this.

> ------
> Q: what about adding a mandatory delay?
> A: first, this procedure is only a recommendation, so there's no point
> in adding "mandatory" steps, or being too precise about delays. The
> current formulation recommends giving additional time for the maintainer
> to respond *in some cases*. Basically, I'd like to allow obvious cases
> (e.g. maintainer who has been inactive for years, and that only maintain
> that package) to be solved without additional delay.  See [3] for
> details on this topic.

I'm OK with the text without precise delays.  Any DD can still send a NACK and
change it to ACK after some reasonable delay to give the maintainer a chance to
react.  In obvious cases there is no delay needed.

> -----
> Q: What about DM seconding?
> A: From [4]: [..] when you sign up to be a DM, you're signing up to do a
> good job of maintaining one or more packages. [..] a part of the
> additional commitment in agreeing to be a DD is to think about the
> broader issues of the project, for example, the social implications of
> your decision, to try and help build Debian as a community and team.  I
> think that broader view is important when doing something that is likely
> to have social consequences like an ITO.

I follow Lucas' reasoning on this.

> -----
> Q: the original proposal was about salvaging, but here we only talk
> about orphaning?
> A: From [5]: I see two activities that can be done by different people.
> One activity is identifying unmaintained packages.  Getting these
> packages marked as orphaned makes them more visible as needing a new
> maintainer.  The second activity is the salvaging process itself.  It
> already exists : it's adopting the package and bringing the package back
> in good shape.  Anyone interested can choose to contribute on only one
> or both activities.

Thanks for quoting this.

> -----
> Q: shouldn't we say something about maintainer in VAC ?
> A: VAC status is private information, so it cannot be used in a public 
> process.  However, as said in [6]:
> So, we are talking about a case where a maintainer would have been on
> VAC for a long enough time to allow a package to become in such a
> terrible state that NMUs are no longer sufficient to maintain its
> quality at a reasonable level. In that case, I would not consider it
> unreasonable to orphan the package. After all, We should prioritize the
> distribution's quality higher than the ownership of packages.

I'm with Lucas on this.

> -----
> [1] Original thread on salvaging packages on -devel@
>     http://lists.debian.org/debian-devel/2012/09/msg00654.html
> [2] http://lists.debian.org/debian-devel/2012/10/msg00014.html
> [3] http://lists.debian.org/debian-devel/2012/10/msg00158.html
> [4] http://lists.debian.org/debian-devel/2012/10/msg00199.html
> [5] http://lists.debian.org/debian-devel/2012/10/msg00261.html
> [6] http://lists.debian.org/debian-devel/2012/10/msg00242.html


Bart Martens

Reply to: