Project Talk:Proxy Maintainers

Changing Project Policy
This policy sets a process for which any potential policy changes must undergo to become official, project policy. As proposed on IRC on (04 February 2016), all proposed changes to project policy must be submitted to the project email address as a RFC. This provides all stakeholders, whether they be developers or proxied-maintainers, to provide their input regarding the proposed change before its implementation.

Choice of tool to make commits
1) "repoman full -x" MUST return clean for files that were modified. This means that if an older version of an ebuild uses a banned EAPI that should not matter as long as the new ebuild which is committed is fine. The -x is for checking xml files too if any of those were modified. This means that a commit may be made with git instead of with repoman, provided that it complies with the above.

2) "repoman commit" is RECOMMEND, because it is the recommended means for committing a package as per the Devmanual, it automatically runs "repoman full" before a commit (obviating the need to remember to run it), and amongst other things, re-generates the Manifest file if necessary.

Sometimes how to fix a repoman error is not always obvious. If there are any questions about errors we will of course help with the goal of getting the output to pass and ensuring good QA for the submission.

Policy for designation of maintainer
If the maintainer is inactive and 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 authority to commit
This policy implements a priority approach to ascertain who 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-wanted.
 * Regular packages dropped by a developer picked up by user maintainers.
 * Patches submitted via the new Gentoo GitHub mirror system.

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 is taken as an 'understood' and required approach in determining authority. Commits by 'non member' developers without contact with members of the project is discouraged and falls 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.

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 portage. If user maintainer does not do so, the proxy developer is entitled to remove old versions, upon commit, at his / her discretion in order to keep the tree clean.