[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

Hi Lucas,

Thanks for coming back on this.

On Thu, Oct 11, 2012 at 12:04:33AM +0200, Lucas Nussbaum wrote:
> 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.

Yes, the cc to debian-qa is a good idea for the reason you described.  I'm not
sure about severity:serious but I don't object.

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

Yes, including NACKs the way you described is an improvement.

> 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

Here's an updated proposal based on the second propsal using criteria from the
first proposal and using some of your newest comments :

  |  Anyone can mark a package as orphaned after the following steps have been
  |  completed : Someone submits an "intent to orphan" (ITO) in the bts with an
  |  explanation of why he/she thinks that the package needs a new maintainer.  The
  |  explanation should cover aspects like how long there was no visible activity,
  |  whether there are NMUs not yet acknowledged, wheter the package blocks progress
  |  elsewhere in Debian, release critical bugs, public comments from the maintainer
  |  revealing lack of interest in the package, ... etc.  The bug must have severity
  |  "serious" and a cc must be sent to the debian-qa mailing list.  Anyone can
  |  submit this "intent to orphan".  At least three DDs (not counting the initial
  |  submitter) second the "intent to orphan" on the same bug report with a cc to
  |  the maintainer.  If some DDs send NACKs instead, then a 3/1 majority is needed
  |  between ACKers and NACKers.  And the maintainer does not respond within one
  |  month after the the third second.  During this process anyone is welcome to add
  |  comments on the bug.

> (typically a draft dev-ref patch).

I have not yet done that, but I'm willing to do that once we've reached a
larger consensus on the text.

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

I've added that in the updated text above.

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

I have added some of them in the updated text above.  I have skipped the part
about the MIA database because I want people without access to the MIA database
to be able to submit an "intent to orphan".  The three DDs adding seconds can
still consult the MIA database.

> - the proposal could stress that the proposed adopter can start working on 
>   the package right away and use NMUs to address open issues.

In my opinion, the NMU procedure already sufficiently describes when an NMU is
appropriate.  I suggest to simply follow the existing NMU rules.

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

I agree that the procedure should at least be included in developers-reference.
I have no strong opinion on whether a GR would be needed.

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

See updated text above.  I'm looking forward to a consensus.


Bart Martens

Reply to: