airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Xiaodong <xd.den...@gmail.com>
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.


XD

> On 24 Feb 2019, at 5:30 PM, Kevin Yang <yrqls21@gmail.com> 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
> <https://github.com/apache/airflow/pull/4396> 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 <fokko@driesprong.frl>
> 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 <ash@apache.org>:
>> 
>>> 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 <fengtao04@gmail.com> 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 <ash@apache.org>
>>>> 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 <fengtao04@gmail.com> wrote:
>>>>>> 
>>>>>> Please correct me if I am wrong. I think normally it starts with
a
>>>>>> [DISCUSS] email thread for all the technical details discussion.
If
>>>>>> everyone aligns, we could move to the vote thread. Here are some
>>>>> guidelines
>>>>>> found on the apache website(
>>>>> https://www.apache.org/foundation/voting.html)
>>>>>> . 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 be
>>>> overruled
>>>>>> nor overridden by anyone. Vetos stand until and unless withdrawn
by
>>>> 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 <ash@apache.org>
>>>>> 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 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
wiki
>>>> along
>>>>>>> with a template email to use for AIP votes.
>>>>>>> 
>>>>>>> -ash
>>>>> 
>>>>> 
>>> 
>> 


Mime
View raw message