Project:Proxy Maintainers

From Gentoo Wiki
Jump to: navigation, search
Proxy Maintainers
Description Proxy maintainers is a group of developers initially maintaining abandoned packages on behalf of Gentoo users. Activity of members now extends to maintaining established packages relinquished by developers.
IRC Channel #gentoo-proxy-maint
Last elected: 2015/10/01
(and inherited members)
Parent Project Quality Assurance
Project listing

Gentoo currently has quite a few packages that lack a maintainer. To prevent treecleaners from having to remove those packages, a maintainer has to be found as soon as possible. The overall goal of this project is to act as a primary contact point between developers and users who want to maintain abandoned packages. Users are more than welcome to contact us and express their interest in maintaining a package assigned to ''.


To enhance the user-developer cooperation in maintaining packages.


The Proxy Maintainers project is available at

The IRC channel of the project is at #gentoo-proxy-maint in Freenode IRC Network.

How do I know which packages are orphaned?

Treecleaners maintain an up-to-date list of orphaned packages. Choose your favorite package and contact us to express your interest.

Please note that packages which have been abandoned by their upstream maintainers do not qualify as orphaned packages. We don't want to maintain dead packages and they will be removed in the near future.

What it takes to be a Proxied Maintainer


Proxied maintainers should be interested in the packages that they are maintaining. By becoming a proxied maintainer you become essentially the person in charge of that package in Gentoo. When users have questions regarding a package and how it works in Gentoo, you will be the person that those questions are directed towards. We would like you to enjoy the maintenance and not feel as though it is a chore. To that end we are looking for enthusiastic people.


Your work will be reviewed by a member of the team for violations of Gentoo QA policy; much of the policy is based more on common sense and less on specific rules. If your work does not meet our QA standards, one of us will notify you of where this occurs and will help you fix the problems to ensure that your work meets guidelines and can be included in the Gentoo package repository. Please do not take offense to these suggestions; all criticism should be intended as constructive criticism.


Similarly in the vein above, don't apply as a proxied maintainer for a package you know very little about unless you are dead sure you can get up to speed on it. For many packages this is not a big problem, because they are quite small. However for larger applications and/or libraries it is important to have prior knowledge about the package in question. Bugs about the package will be directed toward you (and also your Committer). However, as proxied maintainer you are responsible for responding to the bugs with patches/comments/etc. Be prepared to do this.


Due to the increased number of packages this team maintains, we may forget or be slow in committing your fixes. Please be patient with us; however, don't be afraid to prod every once in a while on the status of your patches or ebuilds if we are not responsive.

QA/Required Knowledge and Tools

We understand that you may have limited experience with Gentoo ebuilds. Therefore, you should make a brief read of the devmanual and the required tools in order to make sure your ebuild meets our QA standards.

Help for Users who act as proxied maintainers

How proxy maintainership works

When you're assigned as proxied maintainer, your name and contact details will be included in the metadata.xml of the package you've claimed maintainership of.

For example:

FILE metadata.xml
		<name>A. U. Thor</name>
		<description>Proxied maintainer; set to assignee in all bugs</description>

This means when a bug is filed for the relevant package, you'll be assigned/cc'd to the bug, and expected to resolve the bug as best as you see fit.

Resolving Bugs

If the resolution of the bug requires new ebuilds and or patches (after checking the new ebuilds via the standards laid out by the Gentoo Development Guide, and checking them with repoman), then simply attach the proposed solution files to the bug.

A bug filed to be managed by a proxy maintainer, like any other, is to have the maintainer made the assignee, and co-maintainers and related herds or projects CC'd.

Then a member of the Proxy maintainers team will see the proposed solution, and double check it for consistency prior to committing it to the tree.

Initiating Updates

As a proxied maintainer, you can initiate updates on packages you maintain when there is an upstream update. To do this, simply file a bug on the relevant package as you would if you were simply a user, and attach relevant ebuilds and patches on the newly opened bug. Please take extra care to ensure the quality of your submission so as to minimize the work for the final committer.

It is also possible to create a pull request at Gentoo's GitHub mirror instead of filing a bug.

Policies for the Project

Policy for Designation of Maintainer

If the maintainer is inactive and a bug of the package has input from other users, the users actively contributing may be offered the option of becoming a co-maintainer without consultation of the actual maintainer. Because a maintainer's absence may be transitory:

  • Substituting a maintainer requires confirmation of notice of withdrawal by the maintainer, or
  • beyond a timeout period of one month and at the discretion of the supervising developer of the project.

If the maintainer returns to re-affirm their wish to pursue the package, sanity need prevail; they can be re-assigned with apt negotiation.

Policy for Retention of Ebuilds

The proxied maintainer is to be given opportunity, in discussion with a proxy developer, to select which ebuilds should be declared redundant and removed or retained from Gentoo's repository. If the proxied maintainer does not do so, the proxy developer may opt to remove old versions, upon commit, at his / her discretion in order to keep the tree clean.

Policy for Authority to Commit

This policy implements a priority approach to ascertain which developers may commit a proxied user's contribution and accounts for the current possible scenarios. The fora currently used now include:

  • The list of orphaned packages commonly labelled maintainer-needed.
  • Regular packages dropped by a developer picked up by user maintainers.
  • Pull requests submitted via the new Gentoo GitHub mirror.

The first priority is given to members of the project, second to developers with established knowledge in the field of the category of the package. Since the project hosts a full scope of packages, negotiations between developers are taken as an 'understood' and required approach in determining authority. Commits by 'non member' developers without contact with members of the project are discouraged and fall short of respecting the set processes / operations of the project.

With regard to the newly established Gentoo's GitHub mirror, this policy states that:

  • Those developers need first prompt the project's members, via IRC or the alias, offering the option of committing.
  • Once this proves fruitless, developers of the GitHub mirror are free to commit the pull request on behalf of the user.
  • Recommended timeout period, 1 week and up to the discretion of the developers.

Bugs assigned to

Member developers of the Proxy Maintainers team should encourage users to participate in this project when they notice a open bug for an orphaned package.

Such template (or a similar one) can be used to inform users about this project:


This package has no maintainer so this bug may go unnoticed for a long time.
Gentoo has a dedicated team[1] for assisting users in maintaining orphaned
packages. If you are interested in maintaining this package, please contact or join #gentoo-proxy-maint on Freenode IRC.


Kind regards,


This article is based on a document formerly found on our main website
The following people have contributed to the original document: Markos Chandras, Alec Warner, Sergey Popov, Kent Fredric
They are listed here as the Wiki history does not provide for any attribution. If you edit the Wiki article, please do not add yourself here; your contributions are recorded on the history page.