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 >
