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