Re: Handling of poorly maintained and useless packages
On 10/10/07 at 11:35 +0200, Luk Claes wrote:
>> Why do we need a workflow for that?
>> -----------------------------------
>> There's an authority problem in Debian. Even if nobody disagrees that a
>> package should be removed, if the maintainer is unresponsive, usually,
>> nobody takes the decision to remove it. Having some "rules" one could
>> refer to would help. Also, we have to agree on common "rules", so
>> everybody processes this stuff the same way.
>
> You're clearly speaking about packages that are not orphaned... indeed it
> would be good to have a workflow to handle questionable packages.
Yes. We probably need a workflow for packages that have been orphaned a
long time ago. But I'm trying to address packages that aren't orphaned.
>> Proposed workflow
>> -----------------
>> Suspicious packages are found by combining different metrics into a
>> scoring system:
[...]
>> - number of RC bugs
>
> I would rather use these criterion as a yes/no criterion than a number...
Some packages have had RC bugs for a while, but are actively maintained.
If you use a yes/no criterion for this, you will probably get false
positives.
>> - number of bugs
>
> I would rather use some tresholds than numbers... or look at the number of
> bugs per popcon user of the package.
Yes, I thought about something like that as well. Regarding
implementation, it would be nice to have a way to generate the summary
data for each of these criteria, and then a way to tune the scoring
mechanism, so you can look for packages with similar problems.
>> - age of last maintainer upload
>> - age of last upload
>
> Age of last upload would only be interesting if approven or acked by the
> maintainer IMHO.
>
>> - testing status (in testing? trying to migrate? for how long?)
>
> This really depends on previous criteria and circumstances...
not entirely: it could be blocked because of another package, for
example.
>> - WNPP status (O, RFH, RFA) (for how long?)
>
> This is outside the scope of this proposal IMHO as it is already covered by
> some processes though could probably also need some refinements...
yes, but having this info displayed in a listing of packages, with all
the other info, is helpful. Even if it doesn't participate in the
scoring.
>> - Maintainer's MIA status
>
> This is also outside the scope of the proposal IMHO as MIA maintainers and
> their packages are already covered by the MIA team.
I don't think that packages are always orphaned by MIA: it depends on
what the maintainer answers.
>> - number of packages maintainer by the maintainer (1 is bad, 100 might
>> be as well)
>
> Bogus IMHO, it all depends on the quality of the maintenance: 1 can be good
> for someone who is only cares about one or has only time for one, 100 can
> be good for a maintainer with lots of time or many similar packages.
Agreed, but a package that is suspicious because of other criterions,
and is also the only package of the maintainer, is likely to be an even
better candidate.
>> - number of maintainers for the package
>> - is the package team maintained?
>
> I wonder if you think it would be good or bad as team maintenance can be a
> blessing, but can also mean noone cares enough anymore... it also depends
> on the importance of and maintenace work for a package IMHO
True, but still, it's information that it would be useful to display in
a package list.
>> Rationale: orphaning can be easily reversed in case the maintainer
>> suddenly wakes up again. Removal is harder to reverse, thus the longer
>> delay and the seconder.
>
> Removal is not hard to reverse at all: it's just uploading the package with
> a higher version number... though about 2 or 3 months sounds sane.
Is there an easy way to get the last version of the package in Debian,
before its removal?
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: