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