Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
On 11/10/12 at 18:44 +0900, Charles Plessy wrote:
> 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.
That makes the assumption that the requester will be able to salvage the
package. I would prefer if we stick to the fact: what's it's about is
orphaning the package.
Note that this procedure could also be used as a lightweight replacement
to the MIA procedure, for example if a maintainer has only one package.
In that case, it would make sense to orphan the package without the
promise to salvage it, simply to reflect the fact that the maintainer is
long gone (that way, people using wnpp-alert will identify the package
as being up for adoption).
> - You may clarify that the bug is to be reported to the package, not to
> the wnpp pseudo-package.
(ack)
> - How about requesting that the explanation contains the plans for future work on
> the package ?
See above.
> - 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.
It should be outlined that this procedure is a lightweight process that
describes how it's considered acceptable to orphan package in simple and
obvious situations. I personally would NACK all attempts to "steal"
packages from active maintainers, and I'm quite sure that I would not be
the only one. :-) We have a procedure (bring the case to the TC) for
those situations, the problem is that it would not scale to bring
all such simple situations to the TC.
Similarly, when discussions show that the situation is not simple and
obvious, I would be inclined to NACK on the basis that the situation is
sufficiently complex to be brought to the TC. (And again, I'm quite sure it
will be easy to find more DDs agreeing with that, than 3X more DDs
willing to go fast).
> - 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.
(I made my point about delays in another mail, so I'm not replying here)
> 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 ?
So, we are talking about a case where a maintainer would have been on
VAC for a long enough time to allow a package to become in such a
terrible state that NMUs are no longer sufficient to maintain its
quality at a reasonable level. In that case, I would not consider it
unreasonable to orphan the package. After all, We should prioritize the
distribution's quality higher than the ownership of packages.
> - 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.
I'm not sure about that. I would prefer if we implemented a simple
procedure first, and then improved it if we find serious problems with
it.
Lucas
Reply to: