airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ash Berlin-Taylor <>
Subject Re: Voting on AIPs - what's our process?
Date Mon, 25 Feb 2019 10:40:50 GMT
Let me attempt to summarise the discussion. The workflow for an AIP should be:

1. Create a draft AIP
2. Open a [DISCUSS] thread to get feedback on idea/goal/outlines
3. Allow  suitable time for input on this
4. Change state of AIP to "in-development"
5. Open a PR, making clear it relates to an AIP and needs discussing on list before merging.
6. Call a 72 hour vote on the PR
7. Merge, mark AIP as accepted.

On timings: I think allowing a week for stage 3 gives enough people a chance to see and respond
- 72hours can be a bit tight for those of us with too many emails ;)

As for what is/isn't in need of an AIP: I think this is always going to be a bit hazy: Dropping
support for Python 2 is not a big _code_ change but does have big impact, Drew's OpenAPI3
AIP possibly didn't need an AIP as it's a small impact change, but it doesn't hurt to have
one as it's formalising the public API a bit more (and this calling a vote makes more people
aware of the change). I'm not sure how to summarise that though.


> On 24 Feb 2019, at 22:54, Tao Feng <> wrote:
> Based on my observation of Kafka KIP,   KIP usually could be very
> comprehensive which is almost like a tech spec including: 1. motivation; 2.
> what new public interface it tries to propose; 3. what are the rejected
> alternatives with what reason; 4. what could be the failure scenarios etc.
> And it seems most of the KIP is back with a single pr to help better
> understanding for the discussion.  As Kevin mentioned, current AIP(or the
> one I read) only include a high level idea of what the author tries to
> propose. It lacks of edge case discussion which will only get caught in the
> pr discussion. Hence I am +1 on AIP with a pr.
> In terms of how long of the process, I think there is a 72 hour lazy
> consensus rule in Apache world(?). My understanding is that the author
> could initiate the vote thread if there are no concerns within 72 hours of
> the discuss thread.  In terms of how to decide the fundamental or not, I
> think the change needs an AIP if the change could not be included in a
> minor release. But this is open for discussion.
> Best,
> -Tao
> On Sun, Feb 24, 2019 at 2:00 AM Deng Xiaodong <> wrote:
>> 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.
>> XD
>>> 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
>>>>>> 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"
>>>>>>> calling my vote as no one else spoke up on the discussion thread
>>>>>>> -ash
>>>>>>>> On 21 Feb 2019, at 20:22, Tao Feng <>
>>>>>>>> Please correct me if I am wrong. I think normally it starts
with a
>>>>>>>> [DISCUSS] email thread for all the technical details discussion.
>>>>>>>> everyone aligns, we could move to the vote thread. Here are
>>>>>>> guidelines
>>>>>>>> found on the apache website(
>>>>>>>> . A few points captured:
>>>>>>>> ```
>>>>>>>> A code-modification proposal may be stopped dead in its tracks
by a
>>>>>> -1
>>>>>>> vote
>>>>>>>> by a qualified voter. This constitutes a veto, and it cannot
>>>>>> 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) is
>>>>>> 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, it
>>>>>> could
>>>>>>>>> just need more refinement.
>>>>>>>>> - a proposal requires three positive votes and no negative
ones in
>>>>>> order
>>>>>>>>> to pass
>>>>>>>>> - I've picked a some-what random time of 1 week for AIP
>>>>>> (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 wiki
>>>>>> along
>>>>>>>>> with a template email to use for AIP votes.
>>>>>>>>> -ash

View raw message