airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Homan <>
Subject Re: [DISCUSS] Review-then-commit (RTC) vs Commit-then-review (CTR)
Date Fri, 20 May 2016 17:27:13 GMT
It's up to each community to decide what it's comfortable with, and
then make sure the process is applied equally to everyone.  In my
experience, 'non-minor, trivial' is pretty nebulous.  Does a
3,000-line IDE-driven refactor count as non-minor?  What about a one
line change in the heart of the scheduler that inadvertently changes a
!= to a ==?

It's generally agreed that immediate fixes for broken builds (e.g.,
missing seimicolons that break the compiler, or the Python
equivalent), can be checked in without reviews (they're usually
attached to the original ticket).


On 20 May 2016 at 09:23, siddharth anand <> wrote:
> Can we suggest a +1 vote for non-minor/non-trivial commits, or do all
> commits require a +1? Or is the "non-minor, non-trivial" wording too
> nebulous. t feels like this would work better the more committers we have
> given our different daily work schedules.
> -s
> On Thu, May 19, 2016 at 5:56 PM, Jakob Homan <> wrote:
>> On 18 May 2016 at 16:06, siddharth anand <> wrote:
>> > Is there an automation we can use to ensure/enforce that PRs
>> > and JIRAs receive the +1 binding (from committers) votes needed before a
>> > merge can proceed
>> Not that I know of.  Since we're using github PRs, there might be some
>> kind of workflow system that plugs into that, but I'm not aware of it.
>> Honor code works well, and reverting commits work when it doesn't...

View raw message