On 19 Jul 2014, at 07:49 , Joan Touzet <[email protected]> wrote: > 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.
+1 Jan --
signature.asc
Description: Message signed with OpenPGP using GPGMail
