Project:GitHub/Pull requests

GitHub labels explained
Since GitHub does not provide for detailed descriptions for labels, here's a quick run-down.

Assignment status
assigned -- at least one assignee (package maintainer) for each altered package was found on GitHub and mentioned in the assignment comment. GitHub team does not need to look into assigning the pull request.

need assignment -- the pull request could not be fully assigned automatically (inverse of the above). Someone needs to look into pinging the appropriate maintainer.

Additional assignment information
maintainer-needed -- the pull request alters at least one package that does not have a maintainer. Any developer can look into merging that part. It is a good idea to ask the user about proxy-maintaining it.

new package -- the pull request adds a new package. Either the user should proxy-maintain it, or another developer needs to take it.

self-maintained -- the pull request author is one of the maintainers of each of the packages altered in the pull request. Any proxy-maint member may review it without having to obtain permission from other developers.

Pull request status (progress)
do not merge -- the pull request is not supposed to be merged (or reviewed, unless specifically asked to). This is intended for early RFCs and CI runs. The automated assignment for this pull request is disabled.

help needed -- the author has requested help from other developers in fixing the pull request. If you have a minute, please look into it.

test request -- the pull request is waiting for testing, usually by the submitter. If otherwise approved, the pull request can be merged as soon as the issues are confirmed to be fixed.

work in progress -- the work on the pull request is still ongoing. It will be assigned, and the maintainer are free to provide early review. However, it should be merged until the label is removed.

Merging notes
fix on merge -- the pull request is mostly good, except for a few minor issues. If the submitter did not fix them yet, the developer can merge the pull request provided that he fixes them himself while doing it.

revbump on merge -- the pull request is mostly good, except that the package(s) need(s) to be revbumped. If the submitter did not do that yet, the developer can merge the pull request provided that he introduces the necessary revbump (+ ~arch keywording, potentially keeping the old version if it is stable).

Pull request assignment
The new pull requests are automatically assigned using a cronjob run every 4 minutes. The assignment script leaves a comment @-mentioning appropriate developers/teams and setting labels appropriately.

The assignment is performed based on the list of changed files. The script reads the current maintainers from the metadata.xml files, and maps them to GitHub developers/teams. It should be noted that the files from the current ::gentoo version are used rather than ones from the pull request.

The following additional rules apply:
 * New and unmaintained packages are assigned to Project:Proxy Maintainers as candidates for proxy maintenance.
 * Eclass and profile changes are not assigned automatically, and instead assumed to be handled by other assignees of the pull request (if any).
 * Pull requests involving packages with more than 5 unique sets of maintainers are not assigned automatically (to prevent spam).
 * Packages whose maintainers have no GitHub account (as in, none of the maintainers do have one) are marked as non-assignable.

If the script was able to find at least one assignee for each of the modified packages, the pull request is marked assigned. Otherwise it is marked can't assign.

In order to prevent automatic assignment, please set the assigned label or add at least one explicit assignee. In order to have the pull request re-assigned, remove all assignees (if any) and the appropriate label. The script will automatically remove the previous assignment comment.

Pull request CI
All pull requests are subject to CI runs that run pkgcheck on the whole repository. The CI script is run every 20 minutes, and processes a single pull request (and leaves ETAs on all remaining pull requests).

The CI run consists of pregenerating caches and running pkgcheck on the whole repository. This makes it possible to catch indirect dependency breakages resulting from the changes. If any issues are found, the result is compared to the repository state on which the PR was last rebased. The report indicates appropriately which issues are new to the pull request, and which are persisting (i.e. could be fixed by rebasing).

In order to rerun the CI, force push new commits over the pull requests. The script will detect changed commit identifier, and rerun the checks. it is currently not possible to disable CI on a pull request.

Developers are encouraged to file pull requests in order to CI-test their package removals.

Who is eligible to review?
Everyone can review pull requests. However, please make sure that your comments are correct and on topic. It is a bad experience for our users if they are confused by incorrect suggestions, and then asked to revert them.

It should be noted that pull request reviews are therefore non-binding. They are supposed to improve the pull request and make it more likely to be accepted as-is by the assignee. However, the assignee may choose not to accept a pull request having a positive review, and appropriately he/she may choose to accept it even though there is a negative review.

How to review?
A different levels of review are appropriate to the different kinds of commits. In particular:


 * if a pull requests affects a small part of ebuild (adding a patch, fixing a small bug), don't request the author to fix irrelevant bugs (unless he explicitly wants to).
 * If a pull request does a version bump, don't ask the author to fix minor bugs that are unchanged since the previous version (unless he explicitly wants to).
 * If a pull request does an EAPI bump, it might be reasonable to request changes semi-relevant to the EAPI bump.
 * If a pull request submits a new ebuild, it is highly desirable to bring it to top-quality before being committed.
 * If a pull request requests proxied maintenance of an existing ebuild, it is desirable to ask the new maintainer to fix some bugs, however not necessarily all of them at once.

Be clear in your comments. Avoid unnecessary nitpicking, and even more importantly — avoid wars between developers over ebuild style. If something is purely your preference or recommendation, state that clearly and explain why. If you're not sure, say that, suggest how to check. Feel free to @-mention other developers or teams (QA for technical issues, licenses for license doubts, python for Python doubts, etc.) to get help.

For simple additional changes (revbump, typo fix), don't request the submitter to update the pull request. Instead, leave a comment stating what is wrong and that it will be fixed by the person merging it, so that the submitters knows how to avoid the problem in the future. Add a 'revbump on merge' or 'fix on merge' label appropriately, so that people won't merge it accidentally.

How to submit reviews?
Preferably, use the GitHub review feature to submit reviews. This makes it possible to combine all comments into a single mail rather than sending one mail for each comment.

You can either review the final result of the pull request (Files changed tab) or single commits separately. In order to add a comment, click a line to be commented on, write the comment and use Start a review. This will cause this and your further review comments to be marked pending — which also allows you to modify or remove them before sending.

Please note that GitHub stores your pending, so you can freely navigate through multiple commits and tabs, or even leave the pull request without losing your input. Once ready to submit, navigate to the Files changed tab and use the Review changes button on top.

You can write the general comments here (e.g. applying to the whole pull request, if necessary) and additionally decide if you approve or request changes to the pull request. Neither is obligatory — you can also use the review feature to leave a few neutral comments in a single mail.

Pull request approval
Please remember that pull requests follow the same rules as other commits to the Gentoo repository. Therefore, you can only merge a pull request if you would be permitted to commit the changes to the Gentoo repository. Furthermore, you take responsibility for the changes you are merging.

In particular, changes affecting packages maintained by other developers/projects may require their permission to be merged. If the maintainers do not use GitHub, you may need to use other media to contact them and obtain approval for the merge.

Adding the git remote
Most of the methods listed here require you to fetch pull requests from GitHub. In order to do that most conveniently, create a new remote for GitHub and enable fetching of pull request refs:

Afterwards, each call to:

will fetch new pull requests and expose them as github/pull/NNNN refs.

Closing pull requests
There are three ways of closing a pull request:
 * 1) via a merge commit,
 * 2) via a Closes tag,
 * 3) manually.

If you do a merge commit involving unmodified upstream commits, GitHub will detect commit id match and close the pull request automatically.

Alternatively, you could add a Closes tag to your commit message to make GitHub close the pull request:

Finally, if you did neither of that you need to close the pull request manually.

Using git cherry-pick
In order to cherry-pick all new commits from the pull request, do:

Afterwards, edit the commits as necessary, rebase and sign them and push.

Using git am
It is also possible to use GitHub generated patches to avoid adding the GitHub repository locally. It should be noted, however, that git am is weaker than git cherry-pick at conflict resolution.

Doing a true merge
In order to create a true merge commit for a pull request, do:

Please do not use the default merge commit message. Instead, modify it to adhere to the Gentoo commit message rules, indicating the most important changes included in the merged branch and include the pull request URL in it.

Remember that you need to explicitly make git preserve merge commits when rebasing, e.g.: