In this document:
- Development Guidelines
- Source Code
- GerritHub Configuration
- Submitting a Patch
- Continuous Integration
- Code Review
- Revising Patches
- Multi-Commit Patch Series
SPDK is primarily licensed using a BSD 3-clause license. Some optional or utility code, such as kernel modules, is licensed using a dual BSD/GPLv2 license. All submitted code must carry the appropriate license.
These general guidelines help ensure that the SPDK development community remains fun, fair, and efficient.
- Developers should strive to be active on GerritHub in order to stay in the loop on upcoming changes.
- Trello is where we maintain our backlog and is a great place for design material for more complex patches. Once code has been merged, however, the documentation in the repository supersedes any materials found on Trello (i.e., collateral found on Trello is not maintained once a feature is merged).
- The maintainers do their best to “star” patches that are likely to have impact on applications or other ongoing work, please keep an eye out for those items.
- Coding and submission guidelines (i.e. being clear and concise in the commit message) should always be respected.
- Developers do not need to add specific reviewers to patches, the maintainers and everyone else in the community should always be on the lookout for incoming patches. If a developer would like to be added to a review, or would like a specific person added to their patch, they should feel free to do so.
- There’s no min or max time for the lifecycle of a patch, depending on a variety of factors a patch may go through in hours or possibly weeks or longer. How efficiently our community operates is a direct result of how well our community developers interact with each other.
Directions for getting the code, building the modules, running tests, etc., are all found in the GitHub.
Everyone is welcome to contribute! Design pre-work and general discussion occurs via one of the communications channels described on the Community page.
Patch submission is done through GerritHub where patches are voted on by everyone in the community. A patch requires a minimum of two +2 votes before it will be merged. +2 votes are reserved for the project maintainers who can also be found on the mailing list or in IRC.
You’ll log in to GerritHub using your GitHub account. Here are a few common settings you might want to setup for SPDK:
Profile: Verify that the information is correct here.
- Set Maximum Page Size to 100 rows per page. Otherwise you’ll be hitting ‘next’ a lot.
- We highly recommend you set your Email Notifications to None. Gerrit can send a lot of emails!
- In the
My Menusection, add the following entry:
Name: SPDK Open Reviews URL: #/dashboard/?Outgoing=projects:spdk+o:self+status:open&Needs%20Review=projects:spdk+r:self+-o:self+status:open&Open=projects:spdk+status:open+-r:self+-o:self
You can probably also delete the other entries in there. This will add a link at the top of the page under “My” that will show you a nice dashboard of all of the SPDK review activity.
Now that you’re configured, you can clone the GerritHub repository locally:
git clone https://review.gerrithub.io/spdk/spdk cd spdk git submodule update --init
Or if you already cloned directly from GitHub, you can change your repository to point at GerritHub by doing:
git remote set-url origin https://review.gerrithub.io/spdk/spdk
This will prompt you for a username and a password. The username is your GitHub name, but the password is the
one generated from the
HTTP Password section on GerritHub. You can use the git credential helper
to store your password for you. You can enable it for the SPDK repository with:
git config credential.helper store
Finally, you’ll need to install the Gerrit commit-msg hook. This inserts a unique change ID each time you commit and is required for Gerrit to work.
curl -Lo .git/hooks/commit-msg https://review.gerrithub.io/tools/hooks/commit-msg chmod +x .git/hooks/commit-msg
Now open .git/config in a text editor and add these lines: (this will make pushing reviews easier)
[remote "review"] url = https://review.gerrithub.io/spdk/spdk push = HEAD:refs/for/master
Now you should be all set!
Submitting a Patch
All commits must be signed off by the developer which indicates that you agree to the Developer Certificate of Origin. This is done using the
--signoffoption when committing your changes.
All commits must conform to the SPDK style guide. The style guide is defined by the script located in
scripts/check_format.sh, which will programmatically fix coding style issues using the tools
pep8. Be sure to run this script prior to submitting a patch.
All new code must include accompanying unit test code.
Commits should be rebased and all unit tests should be passing prior to submission.
Squash commits prior to submitting a review such that each commit has a clear purpose that takes an incremental step toward the goal of the series of commits.
Provide a clear commit message describing the purpose of the commit. Good commit messages provide a very brief summary of what the commit does in the title followed by a short paragraph providing context for the change. For example, what problem is being solved, how was it discovered and how this patch solves the problem.
Development on SPDK is all done based on the
master branch, so start by making sure you have the latest. The below
origin is pointed at GerritHub.
git checkout master git pull
Next, create a branch for your development work.
git checkout -b <my_branch>
Then, make your changes and commit as you go. You’ll build up a branch off of master with a series of commits. Once you are done, pull the latest from master again and rebase your changes on top.
git checkout master git pull git checkout <my_branch> git rebase -i master
Now your branch should be based on the tip of master and you should have the tip of
git push review
SPDK employs continuous integration (CI), which means all patches are run through a series of tests before they are even reviewed.
The SPDK CI system periodically looks at GerritHub, pulls the patches down, and runs them on a pool of multiple machines with
real NVMe SSDs. The tests are all checked in to the main SPDK repository (follow
autorun.sh in the root of the repository).
That means that users can add tests to the CI system by simply submitting a patch. Tests are required to be added in the
same patch as the new code they are testing.
The status of the CI system includes an overview of the queued patches. Note that patches will not automatically be queued up, but instead require a cursory approval from one of the SPDK maintainers before they run. Patches pending approval for a run through the CI system are listed under the ‘Pending Approval’ table on the CI status page.
When the CI system completes, it will post a comment on the Gerrit review with a +/-1 Verified flag, plus a link to the logs of the test run. This is particularly useful if the tests fail. Patches will not be merged without a +1 Verified from the CI system.
If the CI system gives your patch a -1 but you believe it is in error (not related to your patch), please ask a maintainer (via IRC) to have your patch re-run.
Everyone is encouraged to review all patches and mark them with a +1 (thumbs up) or -1 (thumbs down). Code review feedback is highly valued, so even if you are a beginner with SPDK, please jump in and start reviewing patches. For a patch to be merged, two maintainers must give it a +2 vote, only maintainers are allowed to use +2.
SPDK has fairly high standards for patch approval. We try to strike a balance between maintaining a high velocity and not allowing ourselves to become overwhelmed in technical debt. Given this, you should expect all non-trivial patches to go through at least a few rounds of code review.
Fortunately, Gerrit makes it very easy to update an outstanding review. You simply update the commits in your git repository to incorporate the new changes and push again. For instance:
git checkout <my_branch> address code review feedback git commit -a --amend git push review
Multi-Commit Patch Series
Gerrit has excellent support for creating series of patches, where each commit is reviewable separately but is dependent on the previous one for merging. You can push an entire series of patches to Gerrit using the following steps:
git checkout master git pull git checkout <my_series> make some changes git commit -s -a # Change 1 make some changes git commit -s -a # Change 2 make some changes git commit -s -a # Change 3 git push review
Gerrit will create three reviews, each dependent on one another. Inevitably, a reviewer will ask you to make a change during code review on change #2. To address that feedback, you could do the following:
git checkout <sha of change #2> git checkout -b tmp # 'tmp' or any name you want address code review feedback git commit -s -a --amend # The amend modifies change #2 to include your updates git checkout <my_series> # Points at change #3 git rebase -i tmp # Move change #3 on top of the new change #2 git push review git branch -D tmp # Clean up the 'tmp' branch