Let me attempt to summarise the discussion. The workflow for an AIP should be:
1. Create a draft AIP 2. Open a [DISCUSS] thread to get feedback on idea/goal/outlines 3. Allow suitable time for input on this 4. Change state of AIP to "in-development" 5. Open a PR, making clear it relates to an AIP and needs discussing on list before merging. 6. Call a 72 hour vote on the PR 7. Merge, mark AIP as accepted. On timings: I think allowing a week for stage 3 gives enough people a chance to see and respond - 72hours can be a bit tight for those of us with too many emails ;) As for what is/isn't in need of an AIP: I think this is always going to be a bit hazy: Dropping support for Python 2 is not a big _code_ change but does have big impact, Drew's OpenAPI3 AIP possibly didn't need an AIP as it's a small impact change, but it doesn't hurt to have one as it's formalising the public API a bit more (and this calling a vote makes more people aware of the change). I'm not sure how to summarise that though. -ash > On 24 Feb 2019, at 22:54, Tao Feng <fengta...@gmail.com> wrote: > > 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 >>>>>>> >>>>>>> >>>>> >>>> >> >>
