Steve Langasek <vor...@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 attention. 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 agreement. 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.) -- |8] -- 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/87haphy8ql....@luthien.mhp
