Hi, This mail tries to address the problem of not orphaned, poorly maintained or useless packages in Debian. The proposal below tries to address both cases, because they are often related. (useless packages tend to be poorly maintained, and vice-versa).
[I originally planned to discuss this during the QA meeting. But it might be a better idea to first start the discussion on the mailing list, so we get a rough idea of the things that have to be discussed in the meeting. Also, this was originally posted to [EMAIL PROTECTED] Since it didn't degenerate into a flamewar, I'm posting this to -devel@ after doing some minor changes to get opinions from a larger audience.] Why is it bad to have those packages in Debian? ----------------------------------------------- Some distributions have a "the more, the better" policy. I don't think that it is what we want for Debian, because: - we (try to) support all packages the same way. Which means we have to support those packages as well. - such packages eat DD time. Bugs are filed against them when doing archive-wide QA, people fix RC bugs in them, etc. - some poorly maintained packages are actually useful, and have people willing to take over maintenance, but it's currently difficult to hijack packages, especially when the maintainer is unresponsive. - such packages eat user time: when trying to find a package doing X, it's better if users only have to evaluate 4 packages, instead of 6 packages, with 2 packages being clearly inferior solutions. Even worse, some users might be using the inferior packages, ignoring that there are better alternatives. 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. In 2005, Marc Brockschmidt did the same kind of bug filing, but was brave enough to orphan/file removal requests. 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. Of course, this looks like overkill, but the resulting workflow is simple. Proposed workflow ----------------- Suspicious packages are found by combining different metrics into a scoring system: - popcon score - RC bugs - number of bugs (possibly per popcon inst) - age of last maintainer upload - testing status (in testing? trying to migrate? for how long?) Some additional info might also be useful: - age of last upload - WNPP status (O, RFH, RFA) (for how long?) - Maintainer's MIA status - number of packages maintained by the maintainer - number of maintainers for the package - is the package team maintained? 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 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 a bit harder to reverse (need to fetch the package from snapshot.d.n), thus the longer delay and the seconder. So, what do you think about that? Any proposed changes? [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=proposed-orphan,proposed-removal;[EMAIL PROTECTED];nam0=Proposals;pri0=tag:proposed-removal,proposed-orphan;ttl0=Proposed%20to%20be%20removed,Proposed%20to%20be%20orphaned;nam1=Status;pri1=severity:serious,normal;ttl1=No%20answer%20yet,acknowledged;nam2=Progress;pri2=pending:pending,done;ttl2=In%20progress,Solved -- | 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]