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 > >> > >> >
