Re: Handling of poorly maintained and useless packages
Lucas Nussbaum wrote:
On 10/10/07 at 11:35 +0200, Luk Claes wrote:
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.
The number of RC bugs is no better metric IMHO. Maybe it should better
go about having RC bugs without maintainer activity for X days?
- 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.
Which is a perfect example of circumstances...
- 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.
Well it doesn't belong in the same list IMHO. Though having the same
info for these packages might indeed be a good idea.
- 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.
Which only illustrates that there is already a process for it which
probably uses also some other metrics...
- 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.
A perfect candidate to report to the MIA team I would say...
- 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.
I thought we were talking about what parameters are used for scoring
(which influences the transition from step 1 to step 2)? Of course I
would welcome more information for step 2 (deciding what to do with the
suspicious packages).
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?
snapshot.debian.net
Cheers
Luk
Reply to: