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

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


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
  - 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
   + three DD have ACKed the proposal (not counting the initial submitter)
   + 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.


Reply to: