TreeCleaner Policy

1.  Policy

Removal Criteria

The goal of the tree cleaning project is not to remove packages that developers are willing to work on. To this end there exists certain criteria that must be met for a package to be eligible for removal by the tree cleaning project. They are:

1. The Package has open bugs on the Gentoo bugzilla. These open bugs are assigned to maintainer-needed and have typically been neglected for some time. It is the policy of the treecleaner project to attempt to fix simple bugs (such as a bad DEPEND atom, minor QA violations, and simple revbumps).
2. Package has no active maintainer. This can mean any of the following:
   • The package has no metadata.xml.
   • The package is assigned to maintainer-needed.
   • The team who oversees the package's herd has been contacted and no one has shown interest.
   • The listed maintainer has shown no interest and does not respond to e-mails or on bugs.gentoo.org.
   • The listed maintainer is no longer a Gentoo developer.
3. The package should have dead or unresponsive upstream. If upstream isn't taking or fixing bugreports this causes problems as Gentoo relies heavily on upstream in many cases. Note the wording here is should, packages are not required to have a dead upstream, this is merely a heuristic that the tree cleaning project relies on.

Using Bugzilla

Tracking bugs is an important part of the TreeCleaner project. Improper tracking leads to lost packages (not assigned to anyone useful) or packages assigned that are not canidates for removal. To avoid this some general policy must be set up.

1. Only take bugs from maintainer-needed unless you have spoken with the current herd or maintainer. We are here to clean out packages no one is maintaining or that the maintainer/herd deems horribly broken and unfixable.
2. When taking a bug, keep maintainer-needed in the CC field. Some people actually watch that alias and the goal is not to hide progress (or lack thereof) from maintainer-needed. Don't disturb their mailflow.
3. When assigning a bug from maintainer-needed be sure you are going to either work on the bug; the goal is not to dump maintainer-needed on treecleaners. The goal is to have a focussed set of bugs that the treecleaner project is currently working on. Don't assign a bug to treecleaners unless you have spoken to a project member on irc, or e-mail the alias and be like "hey this package sucks take a look at it for me." Generally inappropriately assigning bugs angers project members and they will assign it back to the original assignee.
4. PMASKED is a keyword we use to indicate that we have package.masked the package in question. Use it when you know that the package is in pmask.
5. PENDING REMOVAL [yyyy-mm-dd] is a status whiteboard phrase we use to indicate when the package is scheduled for removal. PENDING REMOVAL implies you have sent last rites for the package. Please do not forget to send last rites for a package that you masked.
6. VOTE is a status whiteboard phrase we used to indicate when a package is up for a removal vote. A vote typically requires 1/3rd of the TreeCleaner project to vote in an affirmative manner. See the above section on the removal process for more information

When you are working on a particular bug for TreeCleaners and it has dependencies or blockers do NOT close them until the package is removed. There have been cases when a package was masked and the dependencies were closed only to have the package taken over by a developer. Please close the dependencies when the package is removed

Removal Process

Heuristics
Treecleaners search the tree using basic heuristics; things like:

• When the package was last touched via cvs
• Packages that have no maintainer and/or no herd
• Packages that missed major Gentoo upgrades, for example things unported to modular X or things that don't compile with gcc-4
• Packages that have multiple open bugs that have been open many months with what appears to be no interested from the community

Once located, a package is inspected by a Treecleaner project member. The developer attempts to ascertain the package's problem and tries to find a solution. This may involve asking a related herd for advice, revbumping the package in question, making QA ebuild fixes, patching the software, or a number of other tasks.

If the Treecleaner decides that the package is beyond fixing they must notify the rest of the Treecleaner project and the project will vote on the package. In order for a Vote to be had, the developer in question must present a case for removing the package. If 1/3rd of the team agrees with the presented case the packages will be 'voted off' survivor style.

The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.