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

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

Stefano Zacchiroli <zack@debian.org> wrote:

>On Tue, Oct 23, 2012 at 05:19:37PM +0000, Sune Vuorela wrote:
>> 1) report a bug 'should this package be orphaned?' against the
>> with a more or less defalut templated text and a serious severity
>> 2) sleep 4*7*24*3600
>> 3) if bug silent, orphan it (and maybe adopt it)
>According to the interpretation I suggested in [1], this is actually
>degenerate case of the proposal that is being discusses. If no-one ACKs
>--- which IMHO is what would happen by default anyhow in quite a number
>of cases --- and if the interested person chooses to sleep 4*7*24*3600,
>your point (3) will be the natural conclusion.
>[1]: https://lists.debian.org/debian-devel/2012/10/msg00471.html
>Otherwise stated, the proposal is *exactly* what you're proposing, plus
>some consensus-based best practice to deal with the missing "else"
>branch of your point (3).
>I'm convinced that "else" branch will be quite uncommon (unless
>mandated, see below), and that ACKs/NACKs are just a different way of
>putting what already happens when we discuss on a mailing list the
>salvation of a package.
>But you could either have the unsupervised "if" branch, or what Steve
>suggests in https://lists.debian.org/debian-devel/2012/10/msg00475.html
>i.e. maintainers explicitly looking for ACKs to support their action as
>a requirement to complete the procedure. It has its merits (e.g. a
>surefire extra review layer). But if you consider ACKs as "votes", as
>Scott put it, and you see that as bad, you won't accept this.

I don't object to ACKs, but the requirement to get a certain ACK/NACK ratio.  I see risk of this devolving into a popularity contest.  

I think it should either be unanimous or there is a dispute that the tech ctte needs to resolve.

Sune's proposal certainly seems simpler (and I see simplicity as a virtue), but modulo the voting issue, I think either would be fine.

Scott K

Reply to: