Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
On Thu, Oct 11, 2012 at 11:27:03AM +0200, Arno Töll wrote:
> On 11.10.2012 07:50, Bart Martens wrote:
> >> - the submitter of the "intent to orphan" bug must Cc
> >> email@example.com, 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" :
> 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
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).