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 >
