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