Project Talk:Proxy Maintainers

Preamble
Since the inception of the project, history has demonstrated that participation of proxy maintainer will wanes and their packages eventually are abandoned. Alternately, other users are found to contribute to bugs of such packages and in turn substitute for the designated maintainer. This has caused a conflict in honoring the designated maintainer over another new face when there are no contributions by the designated maintainer. A policy is needed to ensure both recognition of active maintainers and an action plan in the case of them becoming inactive, having lost interest in pursuing the package. Attempts need be made to avoid displacing a maintainer whose absence may be transitory. In practice, it is not possible to cover all possibilities of RL.

Policy
In the case of evidence of inactivity of the maintainer in a bug of the package actively drawing input from other users, the contributing users can be offered the option of becoming a co-maintainer without consultation of the actual maintainer.

Note:


 * Substituting the maintainer is to be done on confirmation of notice of withdrawal by the maintainer, or
 * After a timeout period of one month.

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

Preamble
To date, the assumed rule is that any developer can commit to packages of the project since they are assumed to be packages of 'maintainer-wanted'. This requires refinement. The number of maintainers and their activity in various fora have increased combined with maintainers taking on packages beyond the list of orphaned packages. The latest addition is Gentoo's GitHub mirror which takes pull requests, implicitly authorizing a separate set of developers to commit. If the project is to be taken seriously, the authority given to devs to commit on behalf of proxied users need reflect that of regular projects and herds. The policy describes a priority approach to ascertain who may commit a user's contribution.

Policy
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 by its nature the project hosts a full scope of packages, negotiations between developers is taken as an 'understood' approach for authority to be determined. Committing by non member developers with no contact with members of the project is discouraged and is considered to fall short of respecting the state of the project. The case of Gentoo's GitHub mirror has determined it acceptable for any developer attached to it to commit patches. This policy states that those developers need first prompt the project's members, via IRC or the alias, offering the option of committing. If this proves fruitless those developers are free to commit the pull request on behalf of the user.

Preamble
As packages are bumped over time and various proxy developers, old versions of ebuilds build up.

Policy
When preparing to commit changes to a package on behalf of a proxied maintainer, consideration should be made with respect to old ebuild versions and whether they are candidates for removal. The proxied maintainer may elect to stipulate which ebuilds should or should not be removed from the tree, which should be discussed and agreed upon with the proxy developer.

If the proxied maintainer does not identify ebuilds that should be removed from the tree, then the proxy developer may remove old ebuilds upon commit in order to keep the tree clean as well as to allow for regression testing and fallback.

Default policy
Subject to the discretion of the proxy developer, for commits that involve version changes of the package (as opposed to revision bumps), between two and four of the highest-version ebuilds, not including any being committed, should be retained.

If the package has both stable and testing ebuilds, then the two most-recent stable ebuilds, not including any being committed, must be retained and, if there are any testing ebuilds at a higher version that the latest stable version, then at least one testing ebuild should be retained.