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