Project:Proxy Maintainers/Old User Guide
This page is obsolete and is preserved for historical reasons. Please use the new guide instead.
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:
metadata.xml<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<maintainer type="person">
<email>author@somedomain.com</email>
<name>A. U. Thor</name>
</maintainer>
<maintainer type="project">
<email>perl@gentoo.org</email>
<name>>Gentoo Perl Project</name>
</maintainer>
<maintainer type="project">
<email>proxy-maint@gentoo.org</email>
<name>Proxy Maintainers</name>
</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 specialized project 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.
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 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.
Staying active
As a proxied maintainer, not only you will be maintaining ebuilds, you will also be responsible for any bugs related to your package. We expect you to act professionally in a timely manner. You may lose your maintainership privileges as a result of prolonged inactivity and your package may be given to somebody else.
Commit Policy for users
For quality assurance purposes, repoman full -x MUST return clean for files that were added/modified by you. The -x option forces the metadata.xml file to be checked as well. If an older version of an ebuild that you haven't touched has QA violations, you are not required to fix it as long as the new ebuild which is committed is fine.
For committing changes, "repoman commit" is the RECOMMENDED way of committing a package as per Gentoo Developer Manual. Among other things, it provides a fail-safe by explicitly regenerating the Manifest file before each commit.
As an alternative, provided that the submission passes all the QA checks of repoman full, the commit can be made with git commit when absolutely necessary.