|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.|
Last elected: 2015/10/01
(and inherited members)
|Parent Project||Quality Assurance|
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 'firstname.lastname@example.org'.
- 1 Goals
- 2 Contact
- 3 What it takes to be a Proxied Maintainer
- 4 Help for users who act as proxied maintainers
- 5 Policies for the project
- 6 Maintainer needed vs. Maintainer wanted
To enhance the user-developer cooperation in maintaining packages.
The Proxy Maintainers project is available at email@example.com
The IRC channel of the project is at #gentoo-proxy-maint in Freenode IRC Network.
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.
<pkgmetadata> <maintainer type="project"> <email>firstname.lastname@example.org</email> <name>>Gentoo Perl Project</name> </maintainer> <maintainer type="project"> <email>email@example.com</email> <name>Gentoo Proxy Maintainers Project</name> </maintainer> <maintainer type="person"> <email>firstname.lastname@example.org</email> <name>A. U. Thor</name> <description>Proxied maintainer; set to assignee in all bugs</description> </maintainer> </pkgmetadata>
This means when a bug is filed for the relevant package, you'll be assigned or CC'd within the bug, and expected to resolve the bug as best as you see fit.
Ideally, a package will list both a project that deals with the category of the package, exemplified in this example by the Perl Project, along with the Proxy Maintainers Project. Like any other, the members of the projects share authority to review submissions by the proxied maintainer and will commit when considered 'up to standard'. In terms of priority, the specialised herd is the 'first', or preferred, to supervise and commit. In practice, the proxy maintainers' members can step in on occasions when the primary project's members are away or otherwise occupied.
In practice, there are many packages that are supervised solely by the Proxy Maintainers Project.
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.
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 re-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 proxied maintainer, or
- beyond a timeout period of one month, and at the discretion of the supervising developer of the package, if one is listed in metadata.
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.
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.
Maintainer needed vs. Maintainer wanted
"What is the difference between email@example.com and firstname.lastname@example.org?"?
The subtle difference lies in here:
- you won't find ebuilds in portage of which the maintainer is set to "email@example.com",
- orphaned packages are assigned to "maintainer-needed@" reflecting that they indeed need a maintainer.
Often, the maintainer of a package of the former may have dropped maintainership due to:
- poverty of time
- loss of interest over time
- the herd / project overseering the package in question disbanded
When a user opens a bug report in bugzilla in which it states (s)he would like to have software of <package> packaged, bug wranglers first analyse the report and try to ascertain the nature of the request. By default, bug wranglers assign ebuild requests to "maintainer-wanted@" and add CC to the relevant teams depending on the nature of the package; Java, Ruby, Perl, what have you. Unfortunately, not all requests are fulfilled by virtue of a litany of influences, typically lack of manpower of the host project's member list, general disinterest, an excessive effort required to add the packaged, and so forth. Consequently, the bug report can sit in bugzilla for years... However, a bug with full validity need be processed at some point.
A simple and succinct summary:
- firstname.lastname@example.org: address used for ebuilds already in portage but orphaned. It is essentially unmaintained.
- email@example.com: address used when a bug report is lodged for a package that doesn't exist in the Portage tree which expresses the desire of the user for the software to be packaged. The bug essentially awaits a maintainer, be it a proxied user or a developer, to write the ebuild and to maintain it.
Bugs assigned to firstname.lastname@example.org
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.
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:
Hello, This package has no maintainer so this bug may go unnoticed for a long time. Gentoo has a dedicated team for assisting users in maintaining orphaned packages. If you are interested in maintaining this package, please contact email@example.com or join #gentoo-proxy-maint on Freenode IRC. : https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers Kind regards, <Devname>
Bugs assigned to firstname.lastname@example.orgWe have created a subproject to help with bugs assigned to maintainer-wanted@. This task doesn't required peculiar Gentoo skills, only clicking links and checking whether projects are still alive. Want to help? This way.
This article is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Markos Chandras, Alec Warner, Sergey Popov, Kent Fredric
They are listed here as the Wiki history does not allow for any external attribution. If you edit the Wiki article, please do not add yourself here; your contributions are recorded on the history page.