Open Kinect Repo Policy
In an effort to keep up with the additions from the community while keeping a clean and usable source history in git, we've established a policy on merges to the main repository. This integration policy will hopefully make it easy for us to find bug and figure out where new features come in, while also keeping conflicts with new and ongoing development to a minimum.
- Developer clones repository - Developer makes a new branch to work on feature with. Master branch
should be reserved for upstreams unless developer knows what they are doing with git. - git checkout -b [new feature branch name] master
- Developer makes changes to feature branch, signing off on every
- Developer submits feature branch via pull request or patch filed as
- Once patch is merged to main repo, developer updates from remote
repo and merges main repo into their master.
- Developer then makes new branch off master, continues on new feature. - If developer has another feature they have worked on between the
time they have submitted, needed commits can be cherry picked to new branch.
- Integrator receives pull request or patch
- If pull request, integrator makes sure it is rebased. - If not rebased, and developer is in IRC channel, talk to developer there to have them properly rebase. If developer is not in IRC channel, integrator pulls to local repo and rebases. If conflicts arise, notify developer via pull request comment. - If patch, integrate on top. If conflicted, contact developer via git issue comments.
- Integrator merges patch into main branch. Should always come in as
head if rebase was successful.
- Integrator pushes to main repo
=== Integrator Instructions
Whenever an integrator brings in a new commit, it should be rebased to the head of the master branch on the main repo. However, due to the volume of pull requests and patches we're receiving, this may not always be the case for pull requests.
=== Developer Instructions
==== Submitting a request ==== Updating from the remote