We organize known future work in GitHub projects. See Tracking SPIRV-Tools work with GitHub projects for more.
To report a new bug or request a new feature, please file a GitHub issue. Please ensure the bug has not already been reported by searching issues and projects. If the bug has not already been reported open a new one here.
When opening a new issue for a bug, make sure you provide the following:
For feature requests, we use issues as well. Please create a new issue, as with bugs. In the issue provide
Before we can use your code, you must sign the Khronos Open Source Contributor License Agreement (CLA), which you can do online. The CLA is necessary mainly because you own the copyright to your changes, even after your contribution becomes part of our codebase, so we need your permission to use and distribute your code. We also need to be sure of various other things -- for instance that you‘ll tell us if you know that your code infringes on other people’s patents. You don‘t have to sign the CLA until after you’ve submitted your code for review and a member has approved it, but you must do it before we can put your code into our codebase.
See README.md for instruction on how to get, build, and test the source. Once you have made your changes:
clang-format -style=file -i [modified-files]can help.
Fixes https://github.com/KhronosGroup/SPIRV-Tools/issues/1234When you do this, the issue will be closed automatically when the commit goes into master. Also, this helps us update the CHANGES file.
The reviewer can either approve your PR or request changes. If changes are requested:
After the PR has been reviewed it is the job of the reviewer to merge the PR. Instructions for this are given below.
The formal code reviews are done on GitHub. Reviewers are to look for all of the usual things:
When looking for functional problems, there are some common problems reviewers should pay particular attention to:
We intend to maintain a linear history on the GitHub master branch, and the build and its tests should pass at each commit in that history. A linear always-working history is easier to understand and to bisect in case we want to find which commit introduced a bug.
The following steps should be done exactly once (when you are about to merge a PR for the first time):
Find out the local name for the main github repo in your git configuration. For example, in this configuration, it is labeled
git remote -v [ ... ] upstream https://github.com/KhronosGroup/SPIRV-Tools.git (fetch) upstream https://github.com/KhronosGroup/SPIRV-Tools.git (push)
Make sure that the
upstream remote is set to fetch from the
git config --get-all remote.upstream.fetch +refs/heads/*:refs/remotes/upstream/* +refs/pull/*/head:refs/remotes/upstream/pr/*
If the line
+refs/pull/*/head:refs/remotes/upstream/pr/* is not present in your configuration, you can add it with the command:
git config --local --add remote.upstream.fetch '+refs/pull/*/head:refs/remotes/upstream/pr/*'
The following steps should be done for every PR that you intend to merge:
Make sure your local copy of the master branch is up to date:
git checkout master git pull
Fetch all pull requests refs:
git fetch upstream
Checkout the particular pull request you are going to review:
git checkout pr/1048
Rebase the PR on top of the master branch. If there are conflicts, send it back to the author and ask them to rebase. During the interactive rebase be sure to squash all of the commits down to a single commit.
git rebase -i master
Build and test the PR.
If all of the tests pass, push the commit
git push upstream HEAD:master
Close the PR and add a comment saying it was push using the commit that you just pushed. See https://github.com/KhronosGroup/SPIRV-Tools/pull/935 as an example.