Hi all, This is an interesting problem and sometimes it bothers me too. In general, I agree that it should deserve a voting process. But I also share the same concern with Zili that the FLIP number will be flooded.
So, I think the compromise way is such a small new interface does not need a FLIP, but need a vote in the ML for the JIRA issue. For example, "[VOTE][FLINK-14317] New options for hadoop history server", and a shorter voting period (48h?). Best, Jark On Tue, 15 Oct 2019 at 20: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 > > >
