[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Steve Langasek <vorlon@debian.org> writes:

>> > > No, it makes the process based on *consensus*, which is a minimum
>> > > requirement.
>> > It also means that the salvager has to do more work.
>> I expect the cc to debian-qa to draw sufficient DD's attention.  And the
>> ACKs are about agreeing on marking a package as orphaned.  That's the easy
>> part.
>> The salvaging part goes via the existing ITA procedure.  That's the hard
>> part.
> Exactly.  Anyone who can't be bothered to find N other DDs to agree with him
> that a package should be orphaned (for some value of N <= 3 - as far as I'm
> concerned, 1 or 2 acks w/ 0 nacks is sufficient) shouldn't be considering
> themselves a candidate for maintaining the package anyway.

I am then unfit to maintain any package, since I would not be willing to
do more than CC -qa@ by the time it comes to an ITO, to draw

If I get no answer to that, no acks, no nothing (and similar things did
happen in the past, perhaps not on -qa, but I have mails on -devel@ and
-release@ unanswered, or complained about months later after the fact),
I would not want to go out of my way to find consensus. I take no
replies (within a reasonable timeframe) as not caring, as silent

By the time -qa@ is mailed, the salvager had to do enough visible work
to draw attention to the eventual ITO, so mailing -qa@ should be enough,
whether that gets the salvager any acks or not. In case of no acks, it
is *NOT* the salvagers fault that noone cares, and therefore it is not
the salvager who should be punished with more gruntwork, either.

I don't really see the point of requiring consensus if there are *zero*
replies to an ITO CC'd to -qa@ for, say, 2-3 weeks.

On a similar note, the original proposal did not mention how much time
needs to pass before the salvager can proceed, after getting a
majority. THAT too, needs a timeout, and if it does, why would it hurt
to bake in a worst-case scenario with no acks or nacks? (I can accept
defaulting to no too, after a timeout, as long as there's one. I would
find the result pointless and silly, but at least it puts an end to it,
which the current proposal doesn't.)


Reply to: