[DISCUSS] FLIP policy for introducing config option keys

[Aljoscha Krettek-2]

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

[dwysakowicz]

Hi Aljoscha,

I understand this might be troublesome at times, but I see benefit in
having at least 3 +1s from committers on those. In the end config
options are part of user facing API. In the end adapting config options
is a commitment to support those options in the future. I think having a
better exposure than we had so far could improve consistency of option
keys between different modules.

On the other hand I understand that the requirement of having a voting
period of 72 hours might be a substantial overhead in those cases. I was
thinking if we can have a shorter FLIP cadence for such votes. To
summarize my message, personally I prefer having a FLIP for those
changes, but would be up for loosening formal requirements a bit.

Best,

Dawid

On 15/10/2019 14:05, Aljoscha Krettek 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

[Kostas Kloudas-4]

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 <[hidden email]> 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

[tison]

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 <[hidden email]> 于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 <[hidden email]>
> 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
>

[Aljoscha Krettek-2]

Another PR that introduces new config options: https://github.com/apache/flink/pull/9759

> On 15. Oct 2019, at 14:31, Zili Chen <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]>
>> 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
>>

[tison]

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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]>
> >> 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
> >>
>
>

[Jark Wu-2]

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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]>
> > 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
> >
>

[Hequn Cheng]

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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]
> >
> > >> 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
> > >>
> >
> >
>

[tison]

Hi Jark & Hequn,

Do you stick to introduce a looser FLIP? We possibly introduce a redundant
extra type
of community consensus if we are able to just reuse the process of current
FLIP. Given
the activity of our community I don't think it costs too much for a config
option keys
change with 3 days at least voting required >3 committer votes.

Best,
tison.


Hequn Cheng <[hidden email]> 于2019年10月16日周三 下午2:29写道：

> 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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 于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 <
> [hidden email]
> > >
> > > >> 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
> > > >>
> > >
> > >
> >
>

[Xintong Song]

Hi all,

I think config option changes deserves a voting process, but not
necessarily a FLIP.

My concern for always having FLIPs on config option changes is that, we
might result in too many FLIPs, which makes it difficult for people who
wants to track the major design changes other than pure config option
changes.


My two cents,

- For config option changes introduced by FLIPs, they need to be explicitly
described in the FLIP document and voted. We do have a section 'Public
Interface' for that in the FLIP template.

- For config option changes introduced by other JIRA tickets / PRs, they
need to be voted in the ML. We can add a statement 'whether the PR
introduce any config option changes' in the PR template, and if the answer
is yes, a link to the ML vote thread is required to be attached before
getting the PR merged.


What do you think?


Thank you~

Xintong Song



On Wed, Oct 16, 2019 at 2:50 PM Zili Chen <[hidden email]> wrote:

> Hi Jark & Hequn,
>
> Do you stick to introduce a looser FLIP? We possibly introduce a redundant
> extra type
> of community consensus if we are able to just reuse the process of current
> FLIP. Given
> the activity of our community I don't think it costs too much for a config
> option keys
> change with 3 days at least voting required >3 committer votes.
>
> Best,
> tison.
>
>
> Hequn Cheng <[hidden email]> 于2019年10月16日周三 下午2:29写道：
>
> > 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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 于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 <
> > [hidden email]
> > > >
> > > > >> 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
> > > > >>
> > > >
> > > >
> > >
> >
>

[Timo Walther-2]

Hi all,

I agree with Jark. Having a voting with at least 3 binding votes makes
sense for API changes. It also forces people to question the
introduction of another config option that might make the configuration
of Flink more complicated. A FLIP is usually a bigger effort with long
term impacts on the general usability. A shorter voting period of 48
hours for just a little config option sounds reasonable to me.

Regards,
Timo

On 16.10.19 10:36, Xintong Song wrote:

> Hi all,
>
> I think config option changes deserves a voting process, but not
> necessarily a FLIP.
>
> My concern for always having FLIPs on config option changes is that, we
> might result in too many FLIPs, which makes it difficult for people who
> wants to track the major design changes other than pure config option
> changes.
>
>
> My two cents,
>
> - For config option changes introduced by FLIPs, they need to be explicitly
> described in the FLIP document and voted. We do have a section 'Public
> Interface' for that in the FLIP template.
>
> - For config option changes introduced by other JIRA tickets / PRs, they
> need to be voted in the ML. We can add a statement 'whether the PR
> introduce any config option changes' in the PR template, and if the answer
> is yes, a link to the ML vote thread is required to be attached before
> getting the PR merged.
>
>
> What do you think?
>
>
> Thank you~
>
> Xintong Song
>
>
>
> On Wed, Oct 16, 2019 at 2:50 PM Zili Chen <[hidden email]> wrote:
>
>> Hi Jark & Hequn,
>>
>> Do you stick to introduce a looser FLIP? We possibly introduce a redundant
>> extra type
>> of community consensus if we are able to just reuse the process of current
>> FLIP. Given
>> the activity of our community I don't think it costs too much for a config
>> option keys
>> change with 3 days at least voting required >3 committer votes.
>>
>> Best,
>> tison.
>>
>>
>> Hequn Cheng <[hidden email]> 于2019年10月16日周三 下午2:29写道：
>>
>>> 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 <[hidden email]> 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 于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 <
>>> [hidden email]
>>>>>>> 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
>>>>>

[Jark Wu-2]

Hi all,

It seems that this discussion is idle, but I want to resume it because
I think this will make our community run faster and keep us in the safe
side.

I would like to summarize the discussions so far (please correct me if I'm
wrong):

1. we all agree to have a VOTE in mailing list for such small API changes
2. the voting period can be shorter (48h?)   -- Dawid, Jark, Timo
3. requires a formal FLIP process is too heavy -- Zili Chen, Jark, Dawid,
Xingtong
 - FLIP number will explode
 - difficult to track major design changes
 - we can loosen some formal requirements for such changes
4. introduce a new kind of process -- Hequn, Jark, Xingtong

------------------------------------------------------------------

My proposal is introducing a new process similar to Xingtong pointed.

1. For small API changes, we don't need a formal FLIP process.
2. The discussion can happen in JIRA issue, a [DISCUSS] thread is not
mandatory.
3. The JIRA issue should describe API changes clearly in the description.
4. Once the proposal is finalized call a [VOTE] to have the proposal
adopted.
   The vote requires 3 binding votes (Committers), and at least 2 days.
This is a
   new kind of voting actions which should be added to Flink Bylaws.

-----------------------------------------------------------------

Further discussion:

1. We need to define **what is small API changes**.
2. Do we need a place (wiki?) to track all such proposals/JIRA issues and
how?


Best,
Jark

On Wed, 16 Oct 2019 at 17:56, Timo Walther <[hidden email]> wrote:

> Hi all,
>
> I agree with Jark. Having a voting with at least 3 binding votes makes
> sense for API changes. It also forces people to question the
> introduction of another config option that might make the configuration
> of Flink more complicated. A FLIP is usually a bigger effort with long
> term impacts on the general usability. A shorter voting period of 48
> hours for just a little config option sounds reasonable to me.
>
> Regards,
> Timo
>
> On 16.10.19 10:36, Xintong Song wrote:
> > Hi all,
> >
> > I think config option changes deserves a voting process, but not
> > necessarily a FLIP.
> >
> > My concern for always having FLIPs on config option changes is that, we
> > might result in too many FLIPs, which makes it difficult for people who
> > wants to track the major design changes other than pure config option
> > changes.
> >
> >
> > My two cents,
> >
> > - For config option changes introduced by FLIPs, they need to be
> explicitly
> > described in the FLIP document and voted. We do have a section 'Public
> > Interface' for that in the FLIP template.
> >
> > - For config option changes introduced by other JIRA tickets / PRs, they
> > need to be voted in the ML. We can add a statement 'whether the PR
> > introduce any config option changes' in the PR template, and if the
> answer
> > is yes, a link to the ML vote thread is required to be attached before
> > getting the PR merged.
> >
> >
> > What do you think?
> >
> >
> > Thank you~
> >
> > Xintong Song
> >
> >
> >
> > On Wed, Oct 16, 2019 at 2:50 PM Zili Chen <[hidden email]> wrote:
> >
> >> Hi Jark & Hequn,
> >>
> >> Do you stick to introduce a looser FLIP? We possibly introduce a
> redundant
> >> extra type
> >> of community consensus if we are able to just reuse the process of
> current
> >> FLIP. Given
> >> the activity of our community I don't think it costs too much for a
> config
> >> option keys
> >> change with 3 days at least voting required >3 committer votes.
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> Hequn Cheng <[hidden email]> 于2019年10月16日周三 下午2:29写道：
> >>
> >>> 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 <[hidden email]>
> 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 <[hidden email]> 于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 <[hidden email]> 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 <[hidden email]> 于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 <
> >>> [hidden email]
> >>>>>>> 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
> >>>>>
>
>