airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Xiaodong <>
Subject Re: Voting on AIPs - what's our process?
Date Sun, 24 Feb 2019 10:00:15 GMT
Great discussions!

Two minor points from me:
- For the workflow Ash summarised: may I remind that we may want to decide how long the vote
on an AIP should be open as well (3, 5,or 7 days?). This can be decided later when the workflow
is formalised.

- For the process description Fokko proposed: how shall we decide if a change is “fundamental”
or not? Like Fokko mentioned, one of Kafka’s criteria is whether the change proposal is
changing a public method. But this should be a very minor concern as the committers can decide
if AIP is required in a flexible way later.


> On 24 Feb 2019, at 5:30 PM, Kevin Yang <> wrote:
> +1 for having AIPs backed by PRs.
> About having multiple PR for an AIP. I feels like it might cause overturn
> on an accepted AIP. Say idea in AIP and phase 1 PR all look good but in
> phase 2 we encountered blockers and have to employ creative solutions that
> is against the AIP. I think if an AIP is large enough so PRs must be
> splitted into phases, we might want to just split the AIP? Again use the
> example of AIP-12. We have a fairly large PR
> <> but it is far way from
> covering what's being proposed in the AIP. It would be surprising for me if
> AIP-12 is accepted because the idea is good and the PR claims to back it is
> good.
> My 2 cents.
> Cheers,
> Kevin Y
> On Sun, Feb 24, 2019 at 1:14 AM Driesprong, Fokko <>
> wrote:
>> An AIP should be a couple of PR's. I think splitting up major code changes
>> into multiple PR's is a good thing to maintain progress and you don't need
>> to resolve the conflicts all the time.
>> We could also look at different Apache projects. For example, for Kafka you
>> need to open a KIP if you're changing a public method. I think this is
>> easier (to automate) for JVM based languages. I think we need to open a
>> Wiki to describe the process (or maybe on the Github template itself),
>> which states:
>> - Only (python)docs changes, no ticket is required.
>> - Simple code changes, create a Jira ticket.
>> - Fundamental changes, open an AIP.
>> I like to have a PR with the AIP because conceptually everything always
>> looks nice, but when you enter the trenches and start coding, you will
>> always hit some edge cases which needs a creative solution. It would be
>> nice to also discuss the edge cases before merging the actual code. If the
>> PR is really big, the AIP could also have a couple of phases which each end
>> up in a different PR.
>> Cheers, Fokko
>> Op zo 24 feb. 2019 om 09:41 schreef Ash Berlin-Taylor <>:
>>> My thinking on AIPs that have a PR is that a vote on the AIP is "is this
>>> feature/design goal a good idea" but discussion about the code or merging
>>> the pr can happen on GitHub as usual.
>>> For example AIP-12 is an excellent Idea but there are a few questions to
>>> answer about the design. (The author of the proposal also has an open
>> PR).
>>> A bit of a thin distinction perhaps, but in the general case I was
>>> thinking not a discussion on the PR.
>>> Having written all that down I can see a workflow something like this:
>>> - start AIP
>>> - get loose consensus on list
>>> - open PR
>>> - call vote on AIP + that specific PR.
>>> (That falls down if we want to open multiple PRs to complete an AIP)
>>> -ash
>>> On 22 February 2019 19:28:15 GMT, Tao Feng <> wrote:
>>>> I think AIP is a proposal which is back by a PR. Hence it should
>>>> consider a
>>>> major code change(normal code change shouldn't need a AIP).
>>>> On Fri, Feb 22, 2019 at 2:54 AM Ash Berlin-Taylor <>
>>>> wrote:
>>>>> There was a post about this AIP on 1 Febuary (but no replies other
>>>> than
>>>>> me), and AIPs are not code changes so the point about veto doesn't
>>>> apply
>>>>> here I don't think?.
>>>>> But yes, I think the rough idea of there should be apparent consensus
>>>>> before a vote is called makes sense. I  was using "Lazy consensus" in
>>>>> calling my vote as no one else spoke up on the discussion thread ;)
>>>>> -ash
>>>>>> On 21 Feb 2019, at 20:22, Tao Feng <> wrote:
>>>>>> Please correct me if I am wrong. I think normally it starts with
>>>>>> [DISCUSS] email thread for all the technical details discussion.
>>>>>> everyone aligns, we could move to the vote thread. Here are some
>>>>> guidelines
>>>>>> found on the apache website(
>>>>>> . A few points captured:
>>>>>> ```
>>>>>> A code-modification proposal may be stopped dead in its tracks by
>>>> -1
>>>>> vote
>>>>>> by a qualified voter. This constitutes a veto, and it cannot be
>>>> overruled
>>>>>> nor overridden by anyone. Vetos stand until and unless withdrawn
>>>> their
>>>>>> casters.
>>>>>> ```
>>>>>> I think we should make sure everyone is aligned in the discuss
>>>> thread
>>>>>> before we move to vote thread. WDYT.
>>>>>> On Thu, Feb 21, 2019 at 9:26 AM Ash Berlin-Taylor <>
>>>>> wrote:
>>>>>>> I'm about to send a vote email for the first AIP that I (hope)
>>>> going
>>>>> to
>>>>>>> be a simple and straight forward one to accept.
>>>>>>> Since we haven't defined the process of how/when we vote on AIPs
>>>> I'm
>>>>>>> making it up as we go along :)
>>>>>>> Some points:
>>>>>>> - A failed vote on an AIP is not the same as rejecting the AIP,
>>>> could
>>>>>>> just need more refinement.
>>>>>>> - a proposal requires three positive votes and no negative ones
>>>> order
>>>>>>> to pass
>>>>>>> - I've picked a some-what random time of 1 week for AIP votes
>>>> (compared
>>>>> to
>>>>>>> the 3 days for release votes)
>>>>>>> - members of the community are encouraged to cast votes.
>>>>>>> If no one objects to these "rules" I'll write them up in the
>>>> along
>>>>>>> with a template email to use for AIP votes.
>>>>>>> -ash

View raw message