airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From siddharth anand <san...@apache.org>
Subject [DISCUSS] Review-then-commit (RTC) vs Commit-then-review (CTR)
Date Wed, 18 May 2016 03:10:32 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message