Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
> Steve Langasek <email@example.com> writes:
> > On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote:
> >> > 4. When/if consensus has been reached, the package can be orphaned by
> >> > retitling and reassigning the ITO bug accordingly.
> >> I fear a bit the situation "nobody care enough to comment", being
> >> interpreted as lack of consensus. But I do think in that case we should
> >> _eventually_ allow the orphaning to happen (after all 1/0 > 3/1 ACK/NACK
> >> </joke>).
> >> Any suggestion on how to word that properly, without adding yet another
> >> timeout rule carved in stone?
> > I disagree on this point. If you can't get anyone to ack that you should go
> > ahead with the orphaning, then the system is not working as designed and
> > consensus has not been achieved. It's then incumbent on the person looking
> > to orphan the package to rattle the cage and get developers to pay
> > attention.
> On the other hand, it is already hard to find people willing to review
> other peoples work. Mandating acks means trusting that there will be
> enough manpower to review something potentially unknown. I can't see
> that happening reliably.
I think that sufficient DDs will review the ITOs. Note that most work is
already done by the ITO submitter. Sponsoring a package at mentors ("review
other peoples work") is, in my opinion, much more work than reading an ITO and
sending an ACK.
> It also makes the process a whole lot more
> complicated than it needs to be, which in turn allows the package to
> suffer unmaintainance longer, decreasing the distributions overall
It's not so complicated to find three DDs to agree with the ITO.
> As said elsewhere in the thread, the process needs to be easy and
> efficient. Hunting ACKs is neither easy, nor efficient.
The proposed text is quite easy, in my opinion.