-
Notifications
You must be signed in to change notification settings - Fork 9
OFI Cray libfabric recommended workflow and policies
This wiki page documents the recommended workflow and policies we will be using in the libfabric-cray repository.
The first thing to note is that we have renamed the repository after forking ofiwg/libfabric to be libfabric-cray. We did this primarily to aid developers with keeping their repositories straight, since only GNI-specific work will be merged to this fork. The other reason is that the subject line for the github notification emails are prefixed with the repository name only, which makes things confusing if you get notifications from ofiwg/libfabric also. There is currently no way to configure the subject line (though the nice people at github have put in a feature request).
As mentioned above, for the most part only changes in the prov/gni directory should be merged to master. Notable exceptions are the changes needed to build the GNI provider, which need to be made in the top level makefile template and a couple of provider-independent source files. All other work should should go directly to ofiwg/libfabric.
All merges will be done via github reviewed pull requests. More on that below.
This section documents the suggested workflow. There are probably a few different ways to do the same thing, but this should give you an idea.
See https://help.github.com/articles/fork-a-repo/ for more detailed directions on how to fork, clone and set up a remote.
If you have not already forked ofiwg/libfabric, use the github interface to fork the repository under your account (Fork link near the top left of the repository pages). You can fork either ofiwg/libfabric or ofi-cray/libfabric-cray (you cannot fork both). You will need to manage your remotes when changing between the two.
Next, make a local clone of the repository. You can either do this from github from the side bar of your forked repository or via the command line.
Finally, set up your remotes, i.e.,the remote repositories you'll be interacting with. You can set up any number of distinct upstream remotes, for example ofiwg and ofi-cray.
% git remote add ofi-cray https://github.com/ofi-cray/libfabric-cray
% git remote add ofiwg https://github.com/ofiwg/libfabric
If you don't think you'll contribute to or merge from ofiwg, you can skip that one.
There is a lot of info out there on fetching, merging, committing, etc. so no need to repeat it here. One thing worth mentioning is that git pull is a nice basic shortcut for fetching and merging changes from an upstream remote. If you have uncommitted changes to your repository, git pull will fail and recommend you commit or stash, so you should be safe.
Also, in general you should do work in branches off of your fork. Again, there's already a lot out there about working with branches.
Pull requests are a github-specific feature to share your changes with others for discussion. As policy, we will require a pull request for every merge, reviewed by at least one other person.
These articles on pull request cover most of what you need to know:
- https://help.github.com/articles/using-pull-requests/
- https://help.github.com/articles/creating-a-pull-request/
The only slightly tricky part is the destination repository. Make sure it's pointing at the correct master (ofiwg/libfabric or ofi-cray/libfabric-cray) depending on where you want to merge your commits.
Use an @mention in the pull request text to ask for a review from a particular person (setting the Assignee doesn't send a notification to that person).
We still need to discuss squashing commits and rebasing.