Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek <firstname.lastname@example.org> writes:
> On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
>> > 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. It also makes the process a whole lot more
>> complicated than it needs to be,
> No, it makes the process based on *consensus*, which is a minimum
It also means that the salvager has to do more work. By the time we get
to salvaging, other means of getting the package fixed/updated have
already been exhausted - that's quite a lot of work already, and by that
time, it should be very clear that salvaging is the way to go forward.
I do agree that the salvager should seek consensus, and should make a
reasonable effort to get some feedback on his/her intention, BUT I would
not make that mandatory (seeking acks - yes; not being able to go
forward until N acks - no), as that will stall the process for far too
long in case of less popular packages (and as far as I see, those less
popular packages would benefit most from the salvaging process).
THAT is what I'm concerned about.
And seriously, if noone ACKs or NACKs a salvaging proposal for an
extended period of time, to me, that means noone cares enough. If noone
cares, noone minds, then I would put my trust behind the developer, to
know what he's doing, and let him proceed. Would a mistake be made, that
can always be corrected.
>> which in turn allows the package to suffer unmaintainance longer,
>> decreasing the distributions overall quality.
>> As said elsewhere in the thread, the process needs to be easy and
>> efficient. Hunting ACKs is neither easy, nor efficient.
> The debian-qa list served this purpose fine for *years*. It's not
> acceptable to use handwavy assertions about manpower to justify an
> antisocial process.
If the debian-qa list continues to serve this purpose well, then there
is no issue: we'll never see the case I'm worried about, and I'll be the
happiest person on earth.
If we do end up in such situations, though...