12.2. GitHub, Git, and related topics
PMIx’s Git repository is hosted at GitHub.
First, you will need a Git client. We recommend getting the latest version available. If you do not have the command
gitin your path, you will likely need to download and install Git.
openpmix is the main PMIx repository where most active development is done. Git clone this repository. Note that the use of the
--recursiveCLI option is necessary because PMIx uses Git submodules:
shell$ git clone --recursive https://github.com/openpmix/openpmix.git
Note that Git is natively capable of using many forms of web proxies. If your network setup requires the user of a web proxy, consult the Git documentation for more details.
12.2.2. Git commits: open source / contributor’s declaration
In order to remain open source, all new commits to the PMIx
repository must include a
Signed-off-by: line, indicating the
submitter’s agreement to the PMIx Contributor’s Declaration.
You can use the
-s option to
git commit to
automatically add the
Signed-off-by: line to your commit
12.2.3. Git branch scheme
Generally, PMIx has two types of branches in its Git repository:
All active development occurs on the
masterbranch (new features, bug fixes, etc.).
Release branches of the form
.xsuffix indicates that this branch is used to create all releases in the PMIx vMAJOR.MINOR series.
Periodically, the PMIx community will make a new release branch, typically from
A Git tag of the form
vMAJOR.MINOR.RELEASEis used to indicate the specific commit on a release branch from where official PMIx release tarball was created (e.g.,
Once a bug is fixed or a new feature is implemented on
master, it is
cherry-picked over to the relevant release branch(es).
It may seem odd to some, but the PMIx community
development model does not PR bug fixes or new
features directly to release branches. Instead,
initial bug-fix / feature PRs are generally first made
This helps us ensure that future releases (with
master as a Git ancestor) will contain the bug fix /
shell$ git checkout master shell$ git pull --rebase shell$ git checkout pr/bug-fix # ... make changes / fix a bug / etc. ... shell$ git add ... shell$ git commit -s ... shell$ git push myfork
At this point, you go create a PR from your fork’s
branch to the PMIx community GitHub repo
master branch. Work
with the community to get the PR completed and merged. Then you can
open a new PR to cherry pick the Git commits from that bug fix to each
of the relevant release branches.
Depending on how far the release branch has diverged from
there may be some porting effort involved in the cherry-pick.
For example, if your bug fix on
master is comprised of a single Git
# Fetch all upstream git activity, including the merge of the "master" PR. shell$ get fetch --all # Check out the target release branch, and advance to the most recent commit. shell$ git checkout v5.0.x shell$ git pull --rebase # Make a branch for your bug fix shell$ git checkout -b pr/v5.0.x/bug-fix # Cherry pick the commit from the "master" branch shell$ git cherry-pick -x 123abc # Push to your fork shell$ git push myfork
The PMIx development community requires adding the following line to the commit message of cherry-picked commits on release branches:
(cherry picked from commit [git_hash_of_original_commit])
Note the use of the
-x option to
This option automatically adds the
(cherry picked from
...) line to your commit message.
Git does not actually store any meta data about Git cherry-picks in the commit. Having a standardized text line containing the source Git commit hash in the commit messages helps the PMIx development community track where commits came from on release branches, and therefore allows us to check whether all relevant commits have been ported to a given release branch.
Once your commits are ready and pushed up to your fork, make a PR to the target release branch.
A GitHub PR CI job checks all commits on release branches
(cherry picked from...) line. It will also
ensure that the Git hash cited in that line actually
exists on the
This check ensures that commits are not made to release
branches before their corresponding
master PR was
All this being said, sometimes there is a need for a non-cherry-picked
commit on a release branch. E.g., sometimes a release branch has
diverged so much that the bug no longer exists on
master. It would
therefore not make sense — or even be impossible — to
commit the bug fix in question to
In such cases, make a regular PR to the target branch (with commits
that do not include
(cherry picked from ...) lines). In the PR
description, add a line with the following token:
This tells the GitHub CI job that this PR contains commits that are
not cherry-picked from
bot:notacherrypick should only be used when
absolutely necessary. It is not a license to avoid
the process of PR’ing to
12.2.4. CI (testing)
The PMIx community generally runs a bunch of tests on each PR (Continuous Integration / CI). These tests are a mixture of GitHub Actions and other CI systems (e.g., Jenkins). Examples include (but are not limited to):
Check each Git commit for bozo email addresses
Check that each Git commit contains a
Check that commits on release branches contain a cherry-pick notice
Build and publish the docs
Build PMIx in a variety of environments and run sanity tests with that installation