I've been asked (or been criticised through indirect media) about why packages are removed and as I've just done quite a lot of removals at the
Cambridge BSP (I've done some uploads too, it's not one-sided), I thought I'd explain my rationale in the hope that it will encourage others to remove more packages and fix those which warrant fixing. This, is an approximation of the kind of
scoring I would use when assessing whether to fix a package or remove it. All bug counts are for the entire source package, including all bugs reported against binaries built from that source.
R - Release critical bugs - count the bugs cumulatively - 1 point for 1 bug, 3 points for two (1+2), 6 points for 3 (1+2+3) etc.
U - Uninstallable binary packages - extra points if a -dev package is involved as this will cause FTBFS in reverse dependencies. 1 point for every unrelated package affected. Add extra points if the uninstallable packages are reported as bugs rather than just as notices in the PTS. Add further points for each follow-up message to those bugs. (Filing or following up to a bug report is an indication of user impact as someone had to actually make a contribution.)
B - Blocking other bugs - extra points for every RC bug which is blocking any other bug of any severity.
B - Blocking transitions or release goals - extra points for every bug which is blocking a release transition. (Note this is not the same as being involved in the transition, it matters if the package is blocking the transition by making other packages involved in the transition unable to be rebuilt or migrate.)
I - Interest - popcon is not much use here, "Interest" is a multiplier of the total of previous points. If the package is in testing, multiply the previous points total by the number of days the package has been waiting to enter testing beyond the normal limit. If it is blocking other packages from migrating, add the total number of excess days of all blocked packages. If the package is only in unstable, multiply the previous points total by the number of months the package has been waiting.
S - Security - Count up the number of days the CVE has been waiting longer than a week, multiply that number of days by three and multiply the points so far by the result.
H - Help - whether anyone has done any work at all, including the maintainer. Subtract 1 for any patches, 2 if the patches still apply and work. (It's not much for patches because if a patch exists and works, the excuses not to upload are less believable). Double the points so far for any working patches which have been ignored for more than a month (more than a week for a CVE or packages blocking transitions.
RUBBISH - easy to remember, maybe.
If someone comes up with a UDD query which can resolve the above as an algorithm, a) I'll buy them a beer at DebConf and b) it could be a useful addition to the PTS...
