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 | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
