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