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

Reply via email to