Le Thu, Oct 11, 2012 at 05:50:51AM +0000, Bart Martens a écrit : > > | 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. During this process anyone is welcome > to add > | comments on the bug.
Hi Bart, here are some comments. - It would be more straight to the point to submit an "Intend To Salvage" (ITS) and focus on such takeovers, because merly orphaning the package does not guarantee that it will be actively maintained. - You may clarify that the bug is to be reported to the package, not to the wnpp pseudo-package. - How about requesting that the explanation contains the plans for future work on the package ? - I am not found of the voting procedure, and would rather propose to follow a similar process as for the modification of the Policy and the Developers Reference, where at least three DDs need to indicate that, in their conclusion, a consensus has been reached. I think that if a package is orphaned with for instance a 16:3 majority, it indicates a problem rather than a consensus. Also if the maintainer opposes, this shows lack of consensus and a vote can only aggravate the situation. - For response delay, it think that one month after the bug is opened would be a good compromise. It also makes the deadline more predictable, as opposed to voting or counting consensus assessments. We can not use private information such as vacation flag of the LDAP database in public bug records, so we must assume that the maintainer may not be available. This said perhaps we can request that DDs must not post ITS on pacakges where the maintainer has declared being on vacation in the LDAP ? - Lastly, how about an expiration date ? If we all agree on a one-month delay for the maintainer's response, we can also use it as an expiration date. If within a month there is no reaction of the maintainer, but on the other hand the proposer does not manage to attract support or even positive comments, then it either signals unwritten problems, or it asks the question whether the package should really stay in Debian. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20121011094453.gb27...@falafel.plessy.net
