The FLIP guidelines disagree with your first point.
The guidelines are a bit contradictory as at some places we say that
FLIPs are for major features, and in other places say they are for any
changes to the public API.
This very point came up in the recent FLIP about standardizing metrics.
Metrics are somewhat part of the public API, and thus you can interpret
the guidelines to say that you need a FLIP. But in terms of scope, I
believed it to not be sufficiently large to justify a FLIP.
Overall I'm very much in favor of sticking to the lazy majority voting
scheme and enforcing it,
but I do think we have to reevaluate what changes require a FLIP and
which don't.
On 26/06/2019 11:37, Aljoscha Krettek wrote:
Hi All,
When we originally introduced the FLIP process (which is based on the KIP process
from Kafka and refers to the Kafka bylaws for how votes work) voting was set to be
“lazy majority”. This means that a FLIP vote "requires 3 binding +1 votes and
more binding +1 votes than -1 votes” [1][2]. Currently, we treat FLIP votes more
like “lazy Approval”, i.e. if there are no -1 votes FLIP are often accepted, if
there is a VOTE thread at all.
I propose that we stick to the original process or update our FLIP document to
a voting scheme that we agree on. I’m in favour of sticking with “lazy
majority”, for these reasons:
1. FLIPs should typically be used for deeper changes of Flink. These will stick
around for quite a while after they’re implemented and the PMC (and the
committers) has the burden of maintaining them. I think that therefore FLIP
votes are even move important than release votes, because they steer the long
time direction of Flink.
2. Requiring at least 3 +1 votes means that there is more work needed for
getting a FLIP accepted. I think this is a good thing because it will require
people to be more involved in the direction of the project. And if there are
not enough +1 votes on a FLIP, this is a signal that there is not enough
interest in the feature or that there is not enough bandwidth for working on a
feature.
3. This is more an “optics” thing, but I think having clear rules and sticking
to them makes it easier for an international community (like the Apache Flink
community) to work together and collaborate. If there is preferential treatment
for certain parts of the community that makes it hard for other parts to
participate and get into the community and understand the workings of it.
As a side note, I like the FLIP process because they are a place where we can
keep track of important decisions and they are a place that we can point to
when there is uncertainty about a certain feature in the future. For example
FLIP-28 [3] (which is now discarded) would be a place where we record the
decision that we want Flink to be Scala free in the long term. We could then
point to this in the future. There are some decisions in Flink that are
somewhat hidden in ML discussions or Jira issues, and therefore hard to find,
for example the decision to eventually phase out the DataSet API, or the
decision to drop the older Python APIs, or the semantics of savepoints and
checkpoints. Some FLIPs might not be about implementing a certain feature but
just a general direction that we want to take. I think we should have more of
these.
What do you think?
Best,
Aljoscha
[1]
https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals
[2] https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Approvals
[3]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-28%3A+Long-term+goal+of+making+flink-table+Scala-free
