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 <xd.den...@gmail.com> 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 <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 > >>>>> > >>>>> > >>> > >> > >
