Hi,
[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.]
There's a number of packages in Debian that are poorly maintained, or
that have been become useless. This mail addresses both cases, because
they are often related (useless packages tend to be poorly maintained).
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.
Proposed workflow
-----------------
Suspicious packages are found by combining different metrics into a
scoring system:
- popcon score
- number of RC bugs
- number of bugs
- age of last maintainer upload
- age of last upload
- testing status (in testing? trying to migrate? for how long?)
- WNPP status (O, RFH, RFA) (for how long?)
- Maintainer's MIA status
- number of packages maintainer by the maintainer (1 is bad, 100 might
be as well)
- 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 harder to reverse, thus the longer
delay and the seconder.
So, what do you think about that? Any seconders? Or proposed
changes?
[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=proposed-orphan,proposed-removal;users=debian-qa@lists.debian.org;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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Attachment:
signature.asc
Description: Digital signature