[SUMMARY/PROPOSAL] Orphaning another maintainer's packages
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
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.
------
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.
-----
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.
-----
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.
-----
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.
-----
[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
Lucas
Reply to: