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 -qa@. 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;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 |