Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Le Tue, Oct 23, 2012 at 11:27:43AM +0200, Lucas Nussbaum a écrit :
> The following aims at being written in a form suitable for inclusion in
first of all, thank you for the summary. At the end, the final text may not
please everybody, but my feeling is that ojections, including mine, are more
worries that things are too simple or too complex, too conflictual or to
consensual, rather than critical points that would make the proposal
> 3. Debian Developers can then ACK or NACK the proposed orphaning (using
> signed mails sent to the bug and to email@example.com).
> Everybody is welcomed to contribute to the discussion, e.g. to comment
> on problems experienced by users due to the level of maintenance.
ACK and NACK is jargon that is not obvious to everybody, and in my impression
it sounds like an invitation to not explain one's position. I propose that you
rephrase with more common words, such as "support or object".
> 4. When/if consensus has been reached, the package can be orphaned by
> retitling and reassigning the ITO bug accordingly. It is recommended to
> wait for at least a 3/1 majority between ACKers and NACKers (and to give
> a couple of days for potential NACKers to speak up).
> In some cases, it is also recommended to give additional time for the
> maintainer to respond, especially if the maintainer is otherwise active
> in Debian.
> Finally, it should be remembered that this procedure is designed for
> obvious and simple cases. More complex cases should be forwarded to the
> technical committee.
I think that this point is vague, and may be a source of conflict. The
3/1 majority is "recommended", the delay to let pepole answers is "a couple
of days", and the maintainer deserves "additional time". In my impression,
it will happend that people will argue over these terms.
I still support the idea of a one-month period to reach consensus. And if the
scope is just orphaning, I would agree that no reaction is a consensus to
orphan the package. Altogether, this approach makes the outcome more
predictable and potentially less conflictual than voting and resetting the
clock each time one opinion is expressed, and I think that it would ease the
planning of the further work on the package.
This said, I agree in advance with the outcome of this second round of
discussion. Let's revise the procedure if it does not work well.
Tsurumi, Kanagawa, Japan