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
