+1 for sticking to the lazy majority voting. A question from my side, the 3+1 votes are binding votes which only active (i.e. non-emeritus) committers and PMC members have?
Best, Jark On Wed, 26 Jun 2019 at 19:07, Tzu-Li (Gordon) Tai <tzuli...@apache.org> wrote: > +1 to enforcing lazy majority voting for future FLIPs, starting from FLIPs > that are still currently under discussion (by the time we've agreed on the > FLIP voting process). > > My two cents concerning "what should and shouldn't be a FLIP": > > I can understand Chesnay's argument about how some FLIPs, while meeting the > criteria defined by the FLIP guidelines, feel to not be sufficiently large > to justify a FLIP. > As a matter of fact, the FLIP guidelines explicitly mention that "Exposed > Monitoring Information" is considered public interface; I guess that was > why this FLIP came around in the first place. > I was also hesitant in whether or not the recent FLIP about keyed state > snapshot binary format unification (FLIP-41) deserves to be a FLIP, since > the complexity of the change is rather small. > > However, with the fact that these changes indeed touch the general public > interface of Flink, the scope (including all potential 3rd party projects) > is strictly speaking hard to define. > Outcomes of such changes, even if the complexity of the change is rather > trivial, can still stick around for quite a while. > In this case, IMO the value of proposing a FLIP for such a change is less > about discussing design or implementation details, and more on the fact > that said change requires an official vote for approval from the community. > > Best, > Gordon > > On Wed, Jun 26, 2019 at 5:50 PM Chesnay Schepler <ches...@apache.org> > wrote: > > > 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 > > > > > > >
