Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
Hi Charles,
On Thu, Oct 11, 2012 at 06:44:53PM +0900, Charles Plessy wrote:
> 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.
I'm with Lucas on this. Lucas wrote : "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."
I see two activities that can be done by different people. One activity is
identifying unmaintained packages. Getting these packages marked as orphaned
makes them more visible as needing a new maintainer. The second activity is
the salvaging process itself. It already exists : it's adopting the package
and bringing the package back in good shape. Anyone interested can choose to
contribute on only one or both activities.
>
> - You may clarify that the bug is to be reported to the package, not to the
> wnpp pseudo-package.
I agree that this would be a useful clarification.
>
> - How about requesting that the explanation contains the plans for future work on
> the package ?
See above, about the two activities.
>
> - 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'm OK with following a similar process as for the modification of the Policy
and the Developers Reference.
> I think that if a package is orphaned with for
> instance a 16:3 majority, it indicates a problem rather than a consensus.
I agree. Do you suggest to require an unanimous consensus ? That would be OK
for me.
Actually I would like to get a simple procedure started without too much
discussion on which majority would be needed, because I expect that most cases
will get unanimous consensus anyway.
> Also
> if the maintainer opposes, this shows lack of consensus and a vote can only
> aggravate the situation.
I would allow the maintainer to cancel the ITO simply by closing the ITO bug.
(If the maintainer continues to sit on the package without updating it, we can
still go to the TC.)
>
> - For response delay, it think that one month after the bug is opened would be
> a good compromise.
I agree. Let's use this.
> 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 ?
As I wrote above, I'm OK with following a similar process as for the
modification of the Policy and the Developers Reference. That is in fact a
form of voting, so I'm confused on the part "as opposed to voting or counting
consensus assessments". I would keep the three required seconds from DDs for
the ITO (not ITS, see above about the two activities) who can consult the MIA
database and the information in LDAP to base their decision on.
>
> - 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 OK with adding an expiration date or a maximum duration. What maximum
duration do you suggest ? I agree that the expiration would raise the questions
you mentioned, to be looked at package per package.
Regards,
Bart Martens
Reply to: