Notice: MediaWiki has been updated. Report any rough edges to marcan@marcan.st

Difference between revisions of "Code Integration"

From OpenKinect
Jump to: navigation, search
(Developer workflow)
(Integration workflow)
Line 23: Line 23:
 
==== Integration workflow ====
 
==== Integration workflow ====
  
- Integrator receives pull request or patch
+
* Integrator receives pull request or patch
- If pull request, integrator makes sure it is rebased.  
+
** 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 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 github issue comments.
+
** If patch, integrate on top. If conflicted, contact developer via github issue comments.
- Integrator merges patch into main branch. Should always come in at head if rebase was successful.
+
* Integrator merges patch into main branch. Should always come in at head if rebase was successful.
- Integrator pushes to main repo
+
* Integrator pushes to main repo
  
 
=== Integrator Instructions ===
 
=== Integrator Instructions ===

Revision as of 20:54, 21 November 2010

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.

Workflows

Developer workflow

  • Developer clones repository
  • Developer makes a new branch to work on feature with. Master branch should be reserved for upstreams unless developer knows what theyare doing with git.
    • git checkout -b [new feature branch name] master
  • Developer makes changes to feature branch, signing off on every commit.
  • Developer submits feature branch via pull request or patch filed as project issue.
  • 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.

Integration workflow

  • 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 github issue comments.
  • Integrator merges patch into main branch. Should always come in at 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