On 11/10/12 at 05:50 +0000, Bart Martens wrote: > | Anyone can mark a package as orphaned after the following steps have been > | completed : Someone submits an "intent to orphan" (ITO) in the bts with > an > | explanation of why he/she thinks that the package needs a new > maintainer. The > | explanation should cover aspects like how long there was no visible > activity, > | whether there are NMUs not yet acknowledged, wheter the package blocks > progress > | elsewhere in Debian, release critical bugs, public comments from the > maintainer > | revealing lack of interest in the package, ... etc. The bug must have > severity > | "serious" and a cc must be sent to the debian-qa mailing list. Anyone > can > | submit this "intent to orphan". At least three DDs (not counting the > initial > | submitter) second the "intent to orphan" on the same bug report with a > cc to > | the maintainer. If some DDs send NACKs instead, then a 3/1 majority is > needed > | between ACKers and NACKers.
> And the maintainer does not respond within one month after the the third > second. I'm not sure about this delay. This procedure should be used for uncontroversial cases, where orphaning is obviously the right choice. If it's not that obvious, of course common sense dictates to wait for some time to give the maintainer time to comment. But that can also be achieved by someone NACKing saying "Mmmh, I'm not so sure about that, there hasn't been any big task awaiting action from the maintainer. Are you really sure that the maintainer would understand that the current level of maintenance is suboptimal? Have you tried re-contacting him?" Maybe rephrase that into "Before taking action, it could also be a good idea to wait for comments from the maintainer, especially if he/she is otherwise active in Debian." > During this process anyone is welcome to add > | comments on the bug. Maybe rephrase into: During the process, everyone is of course welcomed and encouraged to contribute to the discussion. Comments from users of the package that suffer from the level of maintenance are especially useful. > > - the proposal should include a list of criterias the the submitter could > > check to reinforce his initial email: the more "proofs" that the package > > is > > a good target, the better. The criterias from Arno's proposal look very > > good as a starting point. > > I have added some of them in the updated text above. I have skipped the part > about the MIA database because I want people without access to the MIA > database > to be able to submit an "intent to orphan". The three DDs adding seconds can > still consult the MIA database. I like the fact that this process focuses on *packages* and not on *maintainers*. This makes thing a lot less confrontational. So I'm fine with not including MIA in the checklist, since this typically focuses on the maintainer. > > - the proposal could stress that the proposed adopter can start working on > > the package right away and use NMUs to address open issues. > > In my opinion, the NMU procedure already sufficiently describes when an NMU is > appropriate. I suggest to simply follow the existing NMU rules. OK, fair enough 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/20121011062036.ga7...@xanadu.blop.info
