ProcessingPullRequests

A.K.A. Gatekeeper HOWTO

Since only gatekeepers have write permissions to release branches in the Open MPI repository, developers must submit pull requests to get commits on release branches.

Pull Requests are usually fairly simple to apply -- Github usually can do it in a single click. As such, the GK's job is usually pretty easy (the GK's role was more important back when Open MPI was using Subversion).

However, sometimes the GK needs to do a bit more than a single click.

This wiki page will document what are the best practices for actually performing the gatekeeper duties with respect to CMRs.

Principles and Best Practices

• It is valid for the gatekeeper to reject a PR that does not merge cleanly to the release branch. It is the responsibility of the developer (not the gatekeeper) to submit a PR that can apply cleanly. This is simply due to the larger number of developers vs. one (plus backup) gatekeeper.
• PRs should not be applied until they have been reviewed (i.e., had the "reviewed" label applied).
• PRs should not be applied until they have been approved by the Release Manager.
• Maintain a single clean and up-to-date git clone of the release branch that is used for PR merges.
• Once a PR is merged, compile and trivially test the release branch to ensure that nothing has broken.
• Try not to apply too many PRs in a single day. After applying a bunch of PRs, let an overnight MTT run to ensure that nothing new has broken before applying more PRs.