-
Notifications
You must be signed in to change notification settings - Fork 928
SubmittingPullRequests
In the Open MPI project, we track three main things:
-
Bugs and enhancement requests: These tracked in the Github Issues tracker in the
ompirepository. -
Requests to get code into the release branches: These are tracked in the Pull Requests in the
ompi-releaserepository. -
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
ompirepository.
You must have a Github account to submit bugs or pull requests.
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:
- Developer writes/commits code in the
masterbranch of their localompiclone. - Developer pushes this code up to the
ompirepo on Github. - Developer creates a topic branch in their local repo from the desired release branch in their local repo.
- Developer cherry-picks the changes from
masterto their local topic branch. - Developer pushes their topic branch to their personal Github repo (NOT the main
ompirepo!). - Developer files a Pull Request to bring the code to the relevant branch in the
ompi-releaserepo.
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.