airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Homan <jgho...@gmail.com>
Subject Re: [DISCUSS] Review-then-commit (RTC) vs Commit-then-review (CTR)
Date Wed, 18 May 2016 18:14:18 GMT
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 <criccomini@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 <sanand@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
>>

Mime
View raw message