Project:Treecleaner/Policy

Removal criteria

Treecleaning is not an exact science. We do not remove packages as soon as they meet a specific criteria. Instead, we try to determine the state of the package, the scale of the problem, the resulting usefulness of the package and its most likely future.

Some of the facts suggesting removal of a package include:

• lack of an active Gentoo maintainer (i.e. a maintainer that does not reply to bugs in a reasonable time is not active),
• lack of an active upstream with an indication that the package is going to require continuous downstream patching,
• vulnerabilities that are not addressed,
• major unsolved issues (e.g. build failures),
• a large number of minor issues,
• lack of direct usefulness and no reverse dependencies (e.g. unused libraries, Python modules that are not likely useful),
• blocking a tree-wide migration/cleanup (e.g. using obsolete EAPI, eclass, dependency on a package being cleaned).

Some of the facts leaning towards keeping the package include:

• willing of the maintainer to fix the bug (in a reasonable time),
• interest of potential (proxied) maintainers,
• a large number of reverse dependencies (might be worthwhile to ping their maintainers to take the package).

Generally, Treecleaners delay planned removals if they expect action from (potential) maintainers. However, this action should bring measurable results, i.e. it's not acceptable to just say you're going to fix it and/or update the maintainer without actually solving the problems.

Typical workflow

Most of the time, Treecleaners take action based on Gentoo bug reports. The exception is when they are asked by maintainers directly to clean their packages. When using Bugzilla, the typical workflow is:

1. One or more bugs are reported against the package (by anyone), and are not fixed in a reasonable time. Bugzilla is considered the reliable way of communicating with maintainers, and therefore determining whether they are active. Please make sure that the maintainers have not fixed the issue, they sometimes forget to close the bugs.
2. Treecleaners (treecleaner@g.o) are CC-ed to the bug. This could be done by another user noticing the problem, or by Treecleaner member itself. This indicates that the project should investigate the package.
3. One of the Treecleaner members investigates the package and determines its state. If he determines that it should be removed, he follows the last rites procedure and lefts a comment on the bug.
4. If the package is not fixed and there is no clear effort to fix it (e.g. by new potential maintainers) within the determined time, the package is removed.