Re: Handling of poorly maintained and useless packages
Lucas Nussbaum wrote:
Hi,
Hi Lucas
Current status
--------------
Michael Ablassmeier and me filed some bugs some time ago on packages
that were good candidates for orphaning or removal from Debian. The list
can be viewed at [1]. However, we haven't orphaned/removed the packages
so far.
Only 47 bugs need to be solved anymore... I'm brave enough to ask for
removal/orphan the packages if needed :-)
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.
Proposed workflow
-----------------
Suspicious packages are found by combining different metrics into a
scoring system:
- popcon score
definitely: almost not used packages have less chance to get bugs filed
and much used packages are no good candidates for removal
- number of RC bugs
I would rather use these criterion as a yes/no criterion than a number...
- number of bugs
I would rather use some tresholds than numbers... or look at the number
of bugs per popcon user of the package.
- 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...
- 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...
- 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.
- 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.
- 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
Step 1:
- Based on the scoring system, find a suspicious package.
- Review the package manually (look at bugs, etc)
- If the package needs action, file a bug:
- severity: serious
- explaining what are the problems with the package
- proposing a solution (orphaning the package, or removing it
from Debian, or finding co-maintainers)
- make it clear that, without answer, the proposed solution will
be carried out
Step 2: (when the problems haven't been solved)
- Review the package again
- Take the proposed actions
Right, these steps look fine.
Delays and control:
-------------------
It's important to decide on reasonable delays.
- If the procedure takes too long, it will be discouraging
- If the procedure is too short, decisions will be contested
I think that the following makes sense:
- For packages where orphaning was proposed: 50 days
- For packages where removal was proposed: 100 days
Additionally, before removals, at least one DD should second the removal
request (after reviewing the package).
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.
Cheers
Luk
Reply to: