Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
On 28/09/12 at 18:48 +0200, Arno Töll wrote:
> Hello,
>
> we may all agree that the maintenance of some (many?) packages in Debian
> is in a unclear situation. There is a transient state, where people are
> interested to bring a package in shape but the strong role of a package
> maintainer in Debian effectively blocks any commitment beyond fixing
> important issues in minimally invasive non-maintainer uploads.
>
> [...]
Hi,
So, reading this thread (which was surprisingly quiet, given the topic),
it seems that everybody agrees that such a procedure would be a good
thing (nobody had fundamental concerns). But now we have two proposed
procedures:
- one which is based on a set of criterias
- one which is based on seconds
It seems that the second[s] one gets slightly more traction, but requires
some minor changes:
- the submitter of the "intent to orphan" bug must Cc
debian-qa@lists.debian.org, and file the bug with severity:serious (this
was part of the "criterias" proposal).
This aims at increasing the publicity of the process, thus avoiding the
"cabal" effect where a group of DDs secretly act together to orphan a
package: everybody can watch the flow of orphanings and react if necessary.
- the number of seconds should probably be tuned a bit. For example, people
could also NACK the proposal to orphan the package. I propose that we wait
until:
+ three DD have ACKed the proposal (not counting the initial submitter)
AND
+ a 3/1 majority is reached between ACKers and NACKers (same as the TC
for overriding developers)
So, how do we move forward?
It seems we need someone to update the proposal, and turn it into a form
suitable for further comments (typically a draft dev-ref patch).
Some ideas:
- the proposal should stress that everybody is welcomed to participate in the
discussion, even if only DDs can ACK/NACK. Specifically, having feedback
from users is always very useful in those discussions.
- the proposal should include a list of criterias the the submitter could
check to reinforce his initial email: the more "proofs" that the package is
a good target, the better. The criterias from Arno's proposal look very
good as a starting point.
- the proposal could stress that the proposed adopter can start working on
the package right away and use NMUs to address open issues.
I don't think that we need something big like a GR to make the process active.
This could probably simply be described as a recommended procedure in dev-ref:
that way, in case of backfire, people following the procedure would have the
backing of a recommended procedure described in a semi-official document.
So, any takers for shaping up an updated proposal? I will probably try to do it
if nobody does it by the end of the month.
Lucas
Reply to: