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

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

Bart Martens <bartm@debian.org> writes:

> On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
>> Steve Langasek <vorlon@debian.org> 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.

On the other hand, ACKing an ITO is much more responsibility, becasue
it's not only about a package, but about taking over a package too. An
ITO will also contain quite a lot of info about previous attempts at
updating the package - that's not simple to review either. It is less
technical too, which can be off-putting to some.

>> 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
>> quality.
> It's not so complicated to find three DDs to agree with the ITO.

Not terribly so, perhaps. But if the salvager has already gone to great
lengths to save a package, pushing even more work on him is not going to

(Mind you, I'm not against the ACK/NACK system, I'm only arguing for
being able to proceed without N acks after a reasonable amount of time.)

>> 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.

Indeed, it is. Partly because as far as I understand it, it only
recommends a 3/1 majority, and does not demand it. That's perfectly


Reply to: