Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
Le Thu, Oct 11, 2012 at 05:50:51AM +0000, Bart Martens a écrit :
>
> | 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.
Hi Bart,
here are some comments.
- It would be more straight to the point to submit an "Intend To Salvage" (ITS) and
focus on such takeovers, because merly orphaning the package does not guarantee
that it will be actively maintained.
- You may clarify that the bug is to be reported to the package, not to the
wnpp pseudo-package.
- How about requesting that the explanation contains the plans for future work on
the package ?
- I am not found of the voting procedure, and would rather propose to follow a
similar process as for the modification of the Policy and the Developers
Reference, where at least three DDs need to indicate that, in their conclusion,
a consensus has been reached. I think that if a package is orphaned with for
instance a 16:3 majority, it indicates a problem rather than a consensus. Also
if the maintainer opposes, this shows lack of consensus and a vote can only
aggravate the situation.
- For response delay, it think that one month after the bug is opened would be
a good compromise. It also makes the deadline more predictable, as opposed
to voting or counting consensus assessments. We can not use private
information such as vacation flag of the LDAP database in public bug records,
so we must assume that the maintainer may not be available. This said perhaps
we can request that DDs must not post ITS on pacakges where the maintainer has
declared being on vacation in the LDAP ?
- Lastly, how about an expiration date ? If we all agree on a one-month delay
for the maintainer's response, we can also use it as an expiration date. If
within a month there is no reaction of the maintainer, but on the other hand
the proposer does not manage to attract support or even positive comments, then
it either signals unwritten problems, or it asks the question whether the package
should really stay in Debian.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: