Hey- The consensus approval link is referring to votes (e.g. releases, new committers, new PMCers, etc) rather than code changes. A single +1 is standard for code changes, as Chris describes. However, projects are welcome to provide more fine-grained requirements as well. For example, Hadoop is RTC (Review-then-commit) but also features to be developed in branches that run on CTR (Commit-then-review). Such a branch can only be merged back to master with three binding +1s, as a counterweight to the possibility of un-reviewed changes appearing.
Historically, ASF operated on a CTR model. However, Hadoop and the myriad projects that flowed from it, adopted RTC. I'm not aware of any big-data/Hadoop/Kafka projects that currently use CTR. (This comment's not an endorsement of either approach, just an observation) Additionally, the community can chose any time to change its approach (via a vote). -Jakob On 18 May 2016 at 10:55, Chris Riccomini <criccom...@apache.org> wrote: > Hey Sid, > >> In the RTC case, we need 3 +1 binding (a.k.a. committer) votes > > This sounds very high. Usually one +1 (other than the person sending the) > is normal in an RTC scenario. > >> In the CTR case, we may want a separate develop branch against which to > run integration tests and merge to master only after those tests pass > > I would prefer not to have a separate branch, so if we feel like that's a > requirement for CTR, then I'd prefer RTC. If we're comfortable committing > to master, though, then I'm fine either way. We have quite a few active > committers, so waiting 24h for a review seems fine. > > Basically, I don't have a strong preference either way, except that I > strongly prefer not to have a separate development branch. If you force me > to pick, I'd pick RTC. I find that RTC encourages a shared understanding of > the code, which is useful. > > Cheers, > Chris > > On Tue, May 17, 2016 at 8:10 PM, siddharth anand <san...@apache.org> wrote: > >> Folks, >> It's a good time for us to discuss whether we will adopt a RTC or CTR >> policy towards software changes. >> >> In the RTC case, we need 3 +1 binding (a.k.a. committer) votes and 0 >> binding vetos for any change as RTC requires consensus approval: >> >> - http://www.apache.org/foundation/glossary.html#ReviewThenCommit >> - http://www.apache.org/foundation/glossary.html#ConsensusApproval >> >> In the CTR case, we operate by lazy consensus, which many of the committers >> have already exercised for the recent Committer/PPMC vote. In the CTR case, >> we may want a separate develop branch against which to run integration >> tests and merge to master only after those tests pass. I'm curious about >> this approach and would like to understand how well this is supported via >> infra tools, automation, and documentation. >> >> - http://www.apache.org/foundation/glossary.html#CommitThenReview >> - http://www.apache.org/foundation/glossary.html#LazyConsensus >> >> I'm also curious if we need to strictly adopt one of these or whether we >> can roll our own - e.g. a +1 binding for RTC for example. >> >> Mentors, >> Any guidance here? >> >> -s >>
