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
Regards,
Bart Martens
Reply to: