|Description||Proxy maintainers is a group of developers maintaining abandoned packages on behalf of Gentoo users|
|Parent Project||Quality Assurance|
Proxy maintainers is a group of developers maintaining abandoned packages on behalf of Gentoo users.
- 1 Project Description
- 2 Project Goals
- 3 Herds
- 4 Contact
- 5 How do I know which packages are orphaned?
- 6 What it takes to be a Proxied Maintainer
- 7 Help for Users who act as proxied maintainers
- 8 Help for Developers who act as proxy maintainers
Gentoo currently has quite a few packages that lack a maintainer. To prevent treecleaners from removing 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'.
To enhance the user-developer cooperation in maintaining packages.
The Proxy Maintainers project maintains the following herds:
|proxy-maintainers||hwoarang, maksbotan, mrueg, pinkbyte, qnikst, swift, titanofold, xmw, yngwin, zlogene||Orphaned packages maintained by Gentoo's proxy-maintainers team|
The Proxy Maintainers project is available at email@example.com
How do I know which packages are orphaned?
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 are essentially the person in charge of that package in Gentoo. When users have questions regarding a package and how it works in Gentoo, you and 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 your 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 you 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 Proxy-Maintain 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 (many 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 have a brief look on 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, not much initially happens.
Your Name, and contact details will be injected into the
metadata.xml of the package you've claimed the maintainership of.
<pkgmetadata> <herd>perl</herd> <herd>proxy-maintainers</herd> <maintainer> <email>firstname.lastname@example.org</email> <name>A. U. Thor</name> <description>Proxy-Maintainer. Assign bugs to him</description> </maintainer> </pkgmetadata>
This means when somebody files a bug on the relevant package, you'll be assigned/cc'd the bug, so you'll get an email about the bug.
Then, your job is to resolve the bug as best as you see fit.
If the resolution of the bug requires new ebuilds and 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 solution files to the bug.
Once the solution files are attached, it may be helpful to reassign to email@example.com.
Then a helpful member of the Proxy maintainers team will hopefully eventually see the solution, and double check it for consistency prior to committing it to tree.
If you, as proxied maintainer see that theres an available upstream update, you may wish to initiate the update yourself.
To do this, simply file a bug on the relevant package as you would if you were simply a user, and then simply attach relevant ebuilds and patches on the newly opened bug (again, doing as much as you can to make the work for the final committer as little as possible, ensuring quality work).
It is also possible to create a pull request at Proxy Maintainers Github Overlay, instead of filling a bug.
Help for Developers who act as proxy maintainers
Bugs assigned to firstname.lastname@example.org
Developers who participate in this project 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. : https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers Kind regards, <Devname>
This article is based on a document formerly found on our main website gentoo.org.
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.