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 <wander4...@gmail.com> 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 <chenghe...@gmail.com> 于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 <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
