On Thu, Oct 11, 2012 at 11:27:03AM +0200, Arno Töll wrote: > Hi, > > On 11.10.2012 07:50, Bart Martens wrote: > >> - 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). > > | 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. > > I don't think "intend to orphan" (ITO) is a good name. First of all, it > is wrong, because if you file such a bug, you eventually don't want to > orphan a package, but quite the contrary revive its maintenance.
I explained this here, see the explanation about the "two activities" : http://lists.debian.org/debian-devel/2012/10/msg00261.html > Moreover, its name suggests it would be a WNPP bug, which it isn't and > wouldn't be. I agree that ITO sounds like a wnpp bug. We could clarify this in the procedure (as suggested by Charles Plessy), or we could simply make ITO a wnpp bug. I have no strong opinion on which one to choose. > > Aside I welcome Lucas and your initiative to move on with this > discussion. After all, I'm happy with any solution which finds > consensus, but I still don't like the DD seconding for the reasons > outlined before. At very least we could allow DMs to make votes too. > Eventually it's just some key in a keyring which is required to > authenticate people. I've read some people objecting against non-DDs voting in this context. I follow your reasoning that the DMs can be identified with they key, so that would be no reason to exclude them. I have a slight preference to only count votes from DDs, but I won't object if there is a consensus to include DMs. > > Some additional thoughts on the seconding: > > * can we really be sure that random developers flying by, care enough > to look into a package they may not care about, inspect its situation > and ack/nack? > The whole new mechanism could be bypassed by feedback > timeout. Frankly, many packages which could be salvaged in future are > not on of these which draw much attraction. In my opinion, yes. I expect the cc's to debian-qa to draw sufficient attention from DDs to get ack/nack's within reasonable time. At least I would be one of the DDs regularly looking at these packages. > > * You cannot require a 3:1 majority without giving a time window to > raise objections. The way Bart proposed it in his draft, one couldn't > make sure a 3:1 majority is reached before 75% of *all* developers > agreed for the opened case. I don't think that's desired or realistic. I have no strong opinion on whether an unanimous consensus would be required or a majority would be sufficient, and which majority that would be. The time window would be one month after opening the bug (suggestion by Charles Plessy). I don't expect this to be a problem. Obviously we don't need "75% of *all* developers" taking part of the voting. I don't see where this comes from. > > * How would you validate binding votes on a salvage process? You would > need to require to send signed mails to the list for seconding. > Otherwise we did not win anything over votes allowed by anyone. I remember that someone else also suggested to use signed messages. That's OK for me. The good thing is that everyone in this thread so far seems to agree that some packages in Debian need salvaging by a new maintainer, and that we need a new practical procedure to enable that. I also see people pooring water in their wine towards a consensus, so in my opinion this discussion has been surprisingly constructive so far for the sensitive/controversial subject. I intend to wait a few more days for additional comments before making a new updated draft (but anyone, please feel free to make an updated draft without waiting for me). 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/20121014083026.gg...@master.debian.org
