+1 to re-think the FLIP process a bit. I think more explicit approval is certainly a good idea. Who can vote on FLIPs is a question to be answered, though. I think PMCs only would be a bit too strict.
On Thu, Jun 27, 2019 at 11:38 AM Hequn Cheng <chenghe...@gmail.com> wrote: > Hi all, > > Thanks for raising the nice discussion @Aljoscha. > > +1 to sticking to the "lazy majority" voting process. > It is good to get more people involved in the design discussion and get > enough binding votes. > > As for the scope of the FLIP, previous replies show a lot of good thoughts. > On the other hand, I think we can also define some scope that which should > *not* be a FLIP. > Sometimes it is easier for us to list a blacklist. > > Best, Hequn > > On Thu, Jun 27, 2019 at 5:27 PM Biao Liu <mmyy1...@gmail.com> wrote: > > > Hi community, > > > > Thanks Aljoscha for bringing us this discussion. > > > > As Aljoscha said, "lazy majority" is always the voting rule of FLIP. It > > seems that people just ignored or didn't realized this rule. > > My concern is that what we can do to make sure developers will obey the > > rules. > > I think Kurt has given a good suggestion. Since the community is growing > > bigger and bigger, maybe we need some volunteers to host the progress of > > FLIP. Like start a discussion/voting in ML or update the sheet of FLIP > > document [1]. > > > > 1. > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals > > > > > > > > Dawid Wysakowicz <dwysakow...@apache.org> 于2019年6月27日周四 下午2:56写道： > > > > > Hi all, > > > > > > I do very much agree with the statement from Aljosha's initial message, > > > which is currently also expressed in the description page of a FLIP. > > > > > > 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. > > > > > > > > > Therefore I think we should enforce following the lazy majority > approach. > > > I will probably just repeat what was already said, but I do think this > > > would make the decisions more visible, easier to reference in case of > > > related decisions, and also this would show if the community has > capacity > > > to implement the FLIP. Nowadays, even if a FLIP is "accepted" it might > be > > > just stale because there are no committers that have the capacity to > help > > > with the changes. > > > > > > Another, maybe an orthogonal issue, is that we could maybe use this > > > process for agreeing on a scope of a release. I think it might make > sense > > > to construct a release plan of an accepted FLIPs. This would enforce > > better > > > scoping of FLIPs, as they would have to fit into a single release. In > my > > > opinion FLIPs that spawn multiple releases(thus even over multiple > years) > > > are rarely relevant in the future anymore, as the project evolves and > it > > > usually makes sense to revisit the original proposal anyway. This would > > > have the benefits that: > > > > > > - we have a clear scope for a release rather than just a vague list > of > > > features that we want to have. > > > - the whole community is on the same page what a certain feature > means > > > - the scope does not change drastically during the development > period > > > > > > As for what should and what should not deserve a FLIP, I actually quite > > > like the definition in the FLIPs page[1]. I think it does make sense to > > > have a FLIP, and as a result a voting process, for any *public* or > major > > > change. I agree with Gordon. Even if the change is trivial it might > > affect > > > external systems/users and it is also a commitment from the community. > > > Therefore I think they deserve a vote. > > > > > > Lastly, I think Jark raised a valid point. We should have a clear > > > understanding what binding votes in this case mean. I think it makes > > sense > > > to consider PMC's and committers' votes as binding for FLIPs voting. > > > Otherwise we would lose the aspect of committing to help with getting > the > > > FLIP into the codebase. > > > > > > To sum up I would opt for enforcing the lazy majority. I would suggest > to > > > consider constructing a release plan with a list of accepted FLIPs. > > > > > > Best, > > > > > > Dawid > > > > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals#FlinkImprovementProposals-Whatisconsidereda%22majorchange%22thatneedsaFLIP > > > ? > > > On 27/06/2019 04:15, Jark Wu wrote: > > > > > > +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 > > > > <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> > < > > 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 > > > > > > > > >
