SubmittingPullRequests

In the Open MPI project, we track three main things:

1. Bugs and enhancement requests: These tracked in the Github Issues tracker in the ompi repository.
2. Requests to get code into the release branches: These are tracked in the Pull Requests in the ompi-release repository.
3. RFCs (i.e., "hey, I've got an idea -- what do people think about this?"): These are typically tracked in the Pull Requests in the ompi repository.

You must have a Github account to submit bugs or pull requests.

Submitting a Pull Request

Pull Requests for the Open MPI release branches are filed via developer's personal Github repositories, and end up in the ompi-release repository Pull Requests listing.

Generally, an Open MPI developer writes new code and pushes it to the master branch on the main ompi repo. To get that code into a release branch, the developer must submit a Pull Request to get it pulled to the appropriate release branch.

[[Recall that Open MPI has ompi and ompi-release Github repositories|GithubRepos]]. Main development work is done on ompi. When code has been vetted, it is moved to an appropriate release branch in the ompi-release repo. Official distribution tarballs are made from the ompi-release repo.

Further recall that developers do not have write access into ompi-release. When they have code they want to get included in a release branch, they must submit a Github Pull Request.

NOTE: Pull requests on ompi-release must include a hash reference in the body/comments corresponding to the commit(s) on ompi:master from which it is derived. Specifically: the intent is that code only goes to the ompi-release repository after it has been committed to the ompi:master development branch. Normally, you can just list a Git hash in a PR body/comment, and Github will auto-link it. But since since ompi:master is a different Github repository than ompi-release, you must prefix hashes with open-mpi/<repo_name> so that Github will know to link it to the other repo. For example:

• A commit in ompi:master: open-mpi/ompi@ce8e33447ff342859c7ffd5216e8aa793d676428
• A commit in ompi-release:v1.8: open-mpi/ompi-release@514ea9f6cc59bcd6426ec3f524ffdfb4279491e0

The general scheme of how this works is:

1. Developer writes/commits code in the master branch of their local ompi clone.
2. Developer pushes this code up to the ompi repo on Github.
3. Developer creates a topic branch in their local repo from the desired release branch in their local repo.
4. Developer cherry-picks the changes from master to their local topic branch.
5. Developer pushes their topic branch to their personal Github repo (NOT the main ompi repo!).
6. Developer files a Pull Request to bring the code to the relevant branch in the ompi-release repo.

Once the Pull Request is filed, there can be discussion on the PR, and the developer may revise their patch (or series of patches) on the topic branch, and re-push to their personal Github repo to allow others to see the changes. Finally, when the PR is merged into the target branch on ompi-release, the PR is closed and the topic branch at Github and in the developer's local repo can be deleted.

An example of this developer process -- and its associated git commands -- is shown on this wiki page.