Hi all, It seems that this discussion is idle, but I want to resume it because I think this will make our community run faster and keep us in the safe side.
I would like to summarize the discussions so far (please correct me if I'm wrong): 1. we all agree to have a VOTE in mailing list for such small API changes 2. the voting period can be shorter (48h?) -- Dawid, Jark, Timo 3. requires a formal FLIP process is too heavy -- Zili Chen, Jark, Dawid, Xingtong - FLIP number will explode - difficult to track major design changes - we can loosen some formal requirements for such changes 4. introduce a new kind of process -- Hequn, Jark, Xingtong ------------------------------------------------------------------ My proposal is introducing a new process similar to Xingtong pointed. 1. For small API changes, we don't need a formal FLIP process. 2. The discussion can happen in JIRA issue, a [DISCUSS] thread is not mandatory. 3. The JIRA issue should describe API changes clearly in the description. 4. Once the proposal is finalized call a [VOTE] to have the proposal adopted. The vote requires 3 binding votes (Committers), and at least 2 days. This is a new kind of voting actions which should be added to Flink Bylaws. ----------------------------------------------------------------- Further discussion: 1. We need to define **what is small API changes**. 2. Do we need a place (wiki?) to track all such proposals/JIRA issues and how? Best, Jark On Wed, 16 Oct 2019 at 17:56, Timo Walther <twal...@apache.org> wrote: > Hi all, > > I agree with Jark. Having a voting with at least 3 binding votes makes > sense for API changes. It also forces people to question the > introduction of another config option that might make the configuration > of Flink more complicated. A FLIP is usually a bigger effort with long > term impacts on the general usability. A shorter voting period of 48 > hours for just a little config option sounds reasonable to me. > > Regards, > Timo > > On 16.10.19 10:36, Xintong Song wrote: > > Hi all, > > > > I think config option changes deserves a voting process, but not > > necessarily a FLIP. > > > > My concern for always having FLIPs on config option changes is that, we > > might result in too many FLIPs, which makes it difficult for people who > > wants to track the major design changes other than pure config option > > changes. > > > > > > My two cents, > > > > - For config option changes introduced by FLIPs, they need to be > explicitly > > described in the FLIP document and voted. We do have a section 'Public > > Interface' for that in the FLIP template. > > > > - For config option changes introduced by other JIRA tickets / PRs, they > > need to be voted in the ML. We can add a statement 'whether the PR > > introduce any config option changes' in the PR template, and if the > answer > > is yes, a link to the ML vote thread is required to be attached before > > getting the PR merged. > > > > > > What do you think? > > > > > > Thank you~ > > > > Xintong Song > > > > > > > > On Wed, Oct 16, 2019 at 2:50 PM Zili Chen <wander4...@gmail.com> wrote: > > > >> Hi Jark & Hequn, > >> > >> Do you stick to introduce a looser FLIP? We possibly introduce a > redundant > >> extra type > >> of community consensus if we are able to just reuse the process of > current > >> FLIP. Given > >> the activity of our community I don't think it costs too much for a > config > >> option keys > >> change with 3 days at least voting required >3 committer votes. > >> > >> Best, > >> tison. > >> > >> > >> Hequn Cheng <chenghe...@gmail.com> 于2019年10月16日周三 下午2:29写道： > >> > >>> Hi all, > >>> > >>> +1 to have a looser FLIP policy for these API changes. > >>> > >>> I think the concerns raised above are all valid. Besides the feedbacks > >> from > >>> @Jark, if we want to keep track of these changes, maybe we can create a > >> new > >>> kind of FLIP that is dedicated to these minor API changes? For example, > >> we > >>> can add a single wiki page and list all related JIRAs in it. The design > >>> details can be described in the JIRA. > >>> Another option is to simply add a new JIRA label to track these > changes. > >>> > >>> What do you think? > >>> > >>> Best, Hequn > >>> > >>> On Tue, Oct 15, 2019 at 8:43 PM Zili Chen <wander4...@gmail.com> > wrote: > >>> > >>>> The naming concern above can be a separated issue since it looks also > >>>> affect FLIP-54 and isn't limited for config option changes FLIP. > >>>> > >>>> Best, > >>>> tison. > >>>> > >>>> > >>>> Aljoscha Krettek <aljos...@apache.org> 于2019年10月15日周二 下午8:37写道： > >>>> > >>>>> Another PR that introduces new config options: > >>>>> https://github.com/apache/flink/pull/9759 > >>>>> > >>>>>> On 15. Oct 2019, at 14:31, Zili Chen <wander4...@gmail.com> wrote: > >>>>>> > >>>>>> Hi Aljoscha & Dawid & Kostas, > >>>>>> > >>>>>> I agree that changes on config option keys deserve a FLIP and it is > >>>>>> reasonable > >>>>>> we commit the changes with a standard FLIP process so that ensure > >> the > >>>>> change > >>>>>> given proper visibility. > >>>>>> > >>>>>> My concern is about naming. Given FLIP-73 as an example, if FLIPs > >>>>>> associated to > >>>>>> FLIP-73(actually can be regarded as sub-FLIP of it) grows FLIP > >>> numbers > >>>>> and > >>>>>> appears > >>>>>> like FLIP-80 FLIP-85 FLIP-91 and so on, then we possibly run into a > >>>> state > >>>>>> flooded by > >>>>>> quite a few config option only FLIP. Maybe it makes sense to number > >>>> these > >>>>>> FLIP as > >>>>>> FLIP-73.1 FLIP-73.2, which shows the association and doesn't > >> pollute > >>>>> other > >>>>>> FLIPs. > >>>>>> > >>>>>> Remind the general thoughts, IMO changes on config option keys > >>> deserve > >>>> a > >>>>>> standard > >>>>>> FLIP process, e.g. FLIP-61. > >>>>>> > >>>>>> Best, > >>>>>> tison. > >>>>>> > >>>>>> > >>>>>> Kostas Kloudas <kklou...@gmail.com> 于2019年10月15日周二 下午8:20写道： > >>>>>> > >>>>>>> Hi Aljoscha, > >>>>>>> > >>>>>>> Given that config option keys are user-facing and any change there > >>> is > >>>>>>> breaking, I think there should be a discussion about them and a > >>> FLIP, > >>>>>>> where people have to actually vote for it seems to be the right > >>> place. > >>>>>>> I understand that this is tedious (and actually I will also have > >> to > >>>>>>> open some FLIPs as part of FLIP-73), but this contributes to the > >>>>>>> uniformity of our parameters and also giving them some more > >>>>>>> visibility. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Kostas > >>>>>>> > >>>>>>> On Tue, Oct 15, 2019 at 2:05 PM Aljoscha Krettek < > >>> aljos...@apache.org > >>>>>>> wrote: > >>>>>>>> Hi Everyone, > >>>>>>>> > >>>>>>>> The title says it all, do you think we need to cover all config > >>>> options > >>>>>>> that we introduce/change by FLIPs? I was thinking about this > >> because > >>>> of > >>>>> the > >>>>>>> FLIP-73 work, which will introduce some new config options and > >> also > >>>>> because > >>>>>>> I just spotted a PR [1] that introduces some config options. > >>>>>>>> Best, > >>>>>>>> Aljoscha > >>>>>>>> > >>>>>>>> [1] https://github.com/apache/flink/pull/9836 > >>>>> > >
