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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Hi Zack,

On Tue, Oct 23, 2012 at 11:19:34PM +0200, Stefano Zacchiroli wrote:
> On Tue, Oct 23, 2012 at 05:19:37PM +0000, Sune Vuorela wrote:
> > 1) report a bug 'should this package be orphaned?' against the package
> > with a more or less defalut templated text and a serious severity
> > 2) sleep 4*7*24*3600
> > 3) if bug silent, orphan it (and maybe adopt it)

> According to the interpretation I suggested in [1], this is actually the
> degenerate case of the proposal that is being discusses. If no-one ACKs
> --- which IMHO is what would happen by default anyhow in quite a number
> of cases --- and if the interested person chooses to sleep 4*7*24*3600,
> your point (3) will be the natural conclusion.

> [1]: https://lists.debian.org/debian-devel/2012/10/msg00471.html

> Otherwise stated, the proposal is *exactly* what you're proposing, plus
> some consensus-based best practice to deal with the missing "else"
> branch of your point (3).

> I'm convinced that "else" branch will be quite uncommon (unless
> mandated, see below), and that ACKs/NACKs are just a different way of
> putting what already happens when we discuss on a mailing list the
> salvation of a package.

> But you could either have the unsupervised "if" branch, or what Steve
> suggests in https://lists.debian.org/debian-devel/2012/10/msg00475.html
> i.e. maintainers explicitly looking for ACKs to support their action as
> a requirement to complete the procedure. It has its merits (e.g. a
> surefire extra review layer). But if you consider ACKs as "votes", as
> Scott put it, and you see that as bad, you won't accept this.

> So, can people comment on Steve's proposal?

> Similarly, Steve: can you comment on the criticism of "voting" on
> packages, why don't you see it as a problem?

"Voting" implies that the majority rules.  I am certainly not in favor of
any sort of voting mechanism where we tally those in favor and those against
orphaning the package.  The standard I expect to see applied here is
*consensus*, not voting.

A lone voice in the wilderness, with no one saying either yay or nay, is not
a consensus.

20 DDs saying the package should be orphaned, and the maintainer saying it
shouldn't (or some other DD saying it shouldn't), is not a consensus.

We should not need a heavyweight process here at all.  It seems that some of
the participants in this discussion are unaware that some of us are
subscribed to debian-qa specifically *for* dealing with questions of
unmaintained packages (MIA, salvaging, or coordination of QA uploads).  The
only real requirements for such a process are:

 - Make an appropriate effort to notify the maintainer of your concern
 - Make the rest of Debian aware of your plans in the designated public
 - Get some (small) number of your peers to agree via public review that
   this is the correct course of action for the package in question
 - Wait a reasonable amount of time for objections
 - If consensus is not reached, refer to the TC

And if my frustration is showing through in this thread, it's because *I am
not proposing a new process*.  This was the process that was used for
*years* via debian-qa.  But, evidently because this process was never
adequately codified in the developer's reference, here we are now having a
long, drawn-out discussion not only about reinventing the wheel but also
about what we should define a wheel to be, and entertaining solutions in
search of a problem from people who have never used that existing and proven

It is not going to be hard to get the necessary handful of acks when
following an appropriate process, nor is it hard to wait a fixed period to
give time for any nacks to arrive before taking action on a package to be
salvaged.  A package salvage is NOT an urgent matter, ever.  Urgent matters
should be dealt with by NMU.  Salvaging is for longer-term questions of
maintainership, and where maintainership is concerned we should be duly
respectful of the existing maintainer's committment to Debian instead of
enacting a buggy process that allows for a maintainer to come back from a
vacation/hospital stay/computer outage to find her package has been
rewritten without so much as a thank you.  If you really intend to commit to
maintaining the package for the foreseeable future, you can bloody well sit
on your hands for a month and wait for the maintainer to react first.

So in sum, I'm broadly in favor of Lucas's patch, except:

 - A single nack is evidence of a lack of consensus.  If consensus can't be
   achieved, it should be referred to the TC instead of making a political
   mess of things for the rest of the project.
 - There does need to be a mandatory minimum waiting period.  This process
   is going to be seen as "blessed" via the devref; we should not be
   blessing a process with an obvious bug that permits abuse by a DD and
   three of her friends pulling off a hostile takeover of a package before
   anybody has a chance to say no.  Even though such an act *can* be
   appealed to the TC, we shouldn't put ourselves in the situation that it
   has to be.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: