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...@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
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 -- 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/20121023164812.ga18...@master.debian.org