Skip to content

SubmittingPullRequests

Jeff Squyres edited this page Sep 1, 2015 · 21 revisions

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.

REMEMBER Open MPI developers do not have write access into the ompi-release repo. Therefore, you can only set labels and milestones by inserting bot commands in pull requests.

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.


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, OR indicate that this is solely a release branch bug (i.e., there's no corresponding commit on ompi:master because the bug doesn't/didn't exist on ompi:master). 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:


[[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.

General scheme

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. It is critical that any changes resulting from the discussion be first committed to the ompi repo on Github so they can be tested by the community prior to moving them to the release branch. Once the changes have been pushed to the ompi repo, the Pull Request should be updated and a commit message containing the revision's master hash added. This should be done at the time the changes are pushed to the ompi repo so tracking is maintained.

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.

Clone this wiki locally