Jan says: ----- Original Message ----- On CTR (commit-then-review): it’s a leftover from the cvs/svn days, in our git world, what was equivalent to commit in the old model is merge to master (and release branches) in ours. And for that we do distinctly follow review-then-commit (http://wiki.apache.org/couchdb/Merge_Procedure) to ensure to the highest degree that master and release branches are always in a shippable/stable state. Git, branches and our merge procedure make all this not much of a problem that it was in the old cvs/svn days. I wonder then, if we should reword the CTR section to reflect our situation? (Even if committing to, say, a feature branch, that then is reviewed before it is merged into master or a release branch could be seen as CTR, it is not quite capturing the same intent). --
I generally agree here, but I'm going to leave this thread open for 24h before changing the text. The proposal would be to explicitly state that we follow a review-then-commit model using git branches and pull requests, generally following the GitHub Flow pattern (http://scottchacon.com/2011/08/31/github-flow.html), and that detail on the process is outside the scope of the Bylaws. -Joan
