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

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

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?

We need some convergence here.

> Taking over unmaintained packages should not be hard. We need people to
> do it. We need people to do it more than they do today. We need to make
> it easy.

I agree. But what you need to make easy are the common cases. The
difficult cases will be difficult no matter what.

Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Attachment: signature.asc
Description: Digital signature

Reply to: