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...@lists.debian.org (e.g. using X-Debbugs-Cc: debian...@lists.debian.org) of the process. The MIA team should also be notified (by Ccing m...@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...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121023092743.ga11...@xanadu.blop.info