The idea of CTR is that the repo that the commit is made to is not in the direct path to a release. Thus, one can commit to the repo/branch as a sort of shared sandbox.
When a commit is proposed to enter into the release path, that path is RTC, which means that the patch must be proposed as a backport, and that before that backport commit can happen (eg, via svn merge), that the patch must be reviewed and voted on in that path (and on the mailing list specific to that path, if one exist). Key in the below is how "dislike" is defined. If, for example, I don't like using a while() loop instead of a for() loop, I can either patch the code myself (since we are CTR) or offer suggestions on why the change should be made, etc... I cannot, however, veto the entire patch/commit for personal, non-technical reasons. Now all this works only when developers are actively working *together* as a group, and that consensus building is a main factor in that development. That is why the *behavior* around git (not git itself) is somewhat circumspect @ Apache, since it really reinforces the idea that instead of it being a group of people working on the same codebase, each person is individually working on their own fork of the codebase and, eventually, some stuff gets shared. In that mindset, each patch/commit is seen as "personal" and not "communal", if you get my drift. On Jul 8, 2014, at 3:24 PM, Eric Schultz <eschu...@prplfoundation.org> wrote: > All, > > I'm trying to understand to the Apache Foundation model of voting in the > commit-then-review system. If a project is running on a CTR system and > someone says they dislike a piece of a previous commit, what happens? Does > it require consensus to remove the code or is the code removed if consensus > isn't reached to keep it in? > > Thanks, > > Eric > > -- > Eric Schultz, Community Manager, prpl Foundation > http://www.prplfoundation.org > eschu...@prplfoundation.org > cell: 920-539-0404 > skype: ericschultzwi > @EricPrpl
