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 <yrql...@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 <fo...@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 <a...@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 <fengta...@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 <a...@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 <fengta...@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 <a...@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 >>>>> >>>>> >>> >>
