Hi Lucas, Thanks for coming back on this.
On Thu, Oct 11, 2012 at 12:04:33AM +0200, Lucas Nussbaum wrote: > On 28/09/12 at 18:48 +0200, Arno Töll wrote: > > Hello, > > > > we may all agree that the maintenance of some (many?) packages in Debian > > is in a unclear situation. There is a transient state, where people are > > interested to bring a package in shape but the strong role of a package > > maintainer in Debian effectively blocks any commitment beyond fixing > > important issues in minimally invasive non-maintainer uploads. > > > > [...] > > Hi, > > So, reading this thread (which was surprisingly quiet, given the topic), > it seems that everybody agrees that such a procedure would be a good > thing (nobody had fundamental concerns). But now we have two proposed > procedures: > - one which is based on a set of criterias > - one which is based on seconds > > It seems that the second[s] one gets slightly more traction, but requires > some minor changes: > - the submitter of the "intent to orphan" bug must Cc > debian...@lists.debian.org, and file the bug with severity:serious (this > was part of the "criterias" proposal). > This aims at increasing the publicity of the process, thus avoiding the > "cabal" effect where a group of DDs secretly act together to orphan a > package: everybody can watch the flow of orphanings and react if necessary. Yes, the cc to debian-qa is a good idea for the reason you described. I'm not sure about severity:serious but I don't object. > > - the number of seconds should probably be tuned a bit. For example, people > could also NACK the proposal to orphan the package. I propose that we wait > until: > + three DD have ACKed the proposal (not counting the initial submitter) > AND > + a 3/1 majority is reached between ACKers and NACKers (same as the TC > for overriding developers) Yes, including NACKs the way you described is an improvement. > > So, how do we move forward? > It seems we need someone to update the proposal, and turn it into a form > suitable for further comments Here's an updated proposal based on the second propsal using criteria from the first proposal and using some of your newest comments : | 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. > (typically a draft dev-ref patch). I have not yet done that, but I'm willing to do that once we've reached a larger consensus on the text. > > Some ideas: > - the proposal should stress that everybody is welcomed to participate in the > discussion, even if only DDs can ACK/NACK. Specifically, having feedback > from users is always very useful in those discussions. I've added that in the updated text above. > - 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. > - 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. > > I don't think that we need something big like a GR to make the process active. > This could probably simply be described as a recommended procedure in dev-ref: > that way, in case of backfire, people following the procedure would have the > backing of a recommended procedure described in a semi-official document. I agree that the procedure should at least be included in developers-reference. I have no strong opinion on whether a GR would be needed. > > So, any takers for shaping up an updated proposal? I will probably try to do > it > if nobody does it by the end of the month. See updated text above. I'm looking forward to a consensus. 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/20121011055051.gb5...@master.debian.org
