Hi Becket, I've applied the proposed change to the document: https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026&selectedPageVersions=20&selectedPageVersions=19
I would propose to stop accepting changes to the document now, as it might start a discussion about the validity of the vote and the bylaws itself. Changes to the document require a 2/3 majority. On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels <m...@apache.org> wrote: > Hi Becket, > > Thanks for clarifying and updating the draft. The changes look good to me. > > I don't feel strong about a 2/3 majority in case of committer/PMC > removal. Like you pointed out, both provide a significant hurdle due to > possible vetos or a 2/3 majority. > > Thanks, > Max > > On 13.08.19 10:36, Becket Qin wrote: > > Piotr just reminded me that there was a previous suggestion to clarify a > > committer's responsibility when commit his/her own patch. So I'd like to > > incorporate that in the bylaws. The additional clarification is following > > in bold and italic font. > > > > one +1 from a committer followed by a Lazy approval (not counting the > vote > >> of the contributor), moving to lazy majority if a -1 is received. > >> > > > > > > Note that this implies that committers can +1 their own commits and merge > >> right away. *However, the committe**rs should use their best judgement > to > >> respect the components expertise and ongoing development plan.* > > > > > > This does not really change any of the existing bylaws, just about > > clarification. > > > > If there is no objection to this additional clarification, after the > bylaws > > wiki is updated, I'll send an update notice to the voting thread to > inform > > those who already voted about this addition. > > > > Thanks, > > > > Jiangjie (Becket) Qin > > > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin <becket....@gmail.com> > wrote: > > > >> Hi Maximillian, > >> > >> Thanks for the feedback. Please see the reply below: > >> > >> Step 2 should include a personal email to the PMC members in question. > >> > >> I'm afraid reminders inside the vote thread could be overlooked easily. > >> > >> > >> This is exactly what I meant to say by "reach out" :) I just made it > more > >> explicit. > >> > >> The way the terms are described in the draft, the consensus is "lazy", > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy > >>> Consensus". This is in line with the other definitions such as "Lazy > >>> Majority". > >> > >> It was initially called "lazy consensus", but Robert pointed out that > >> "lazy consensus" actually means something different in ASF term [1]. > >> Here "lazy" pretty much means "assume everyone is +1 unless someone says > >> otherwise". This means any vote that requires a minimum number of +1 is > not > >> really a "lazy" vote. > >> > >> Removing a committer / PMC member only requires 3 binding votes. I'd > >>> expect an important action like this to require a 2/3 majority. > >> > >> Personally I think consensus is good enough here. PMC members can cast a > >> veto if they disagree about the removal. In some sense, it is more > >> difficult than with 2/3 majority to remove a committer / PMC member. > Also, > >> it might be a hard decision for some PMC members if they have never > worked > >> with the person in question. That said, I am OK to change it to 2/3 > >> majority as this will happen very rarely. > >> > >> Thanks, > >> > >> Jiangjie (Becket) Qin > >> > >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus > >> > >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <m...@apache.org> > wrote: > >> > >>> I'm a bit late to the discussion here. Three suggestions: > >>> > >>> 1) Procedure for "insufficient active binding voters to reach 2/3 > majority > >>> > >>>> 1. Wait until the minimum length of the voting passes. > >>>> 2. Publicly reach out to the remaining binding voters in the > voting > >>> mail thread for at least 2 attempts with at least 7 days between two > >>> attempts. > >>>> 3. If the binding voter being contacted still failed to respond > >>> after all the attempts, the binding voter will be considered as > inactive > >>> for the purpose of this particular voting. > >>> > >>> Step 2 should include a personal email to the PMC members in question. > >>> I'm afraid reminders inside the vote thread could be overlooked easily. > >>> > >>> 2) "Consensus" => "Lazy Consensus" > >>> > >>> The way the terms are described in the draft, the consensus is "lazy", > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy > >>> Consensus". This is in line with the other definitions such as "Lazy > >>> Majority". > >>> > >>> 3) Committer / PMC Removal > >>> > >>> Removing a committer / PMC member only requires 3 binding votes. I'd > >>> expect an important action like this to require a 2/3 majority. > >>> > >>> > >>> Do you think we could incorporate those suggestions? > >>> > >>> Thanks, > >>> Max > >>> > >>> On 11.08.19 10:14, Becket Qin wrote: > >>>> Hi folks, > >>>> > >>>> Thanks for all the discussion and support. I have started the voting > >>> thread. > >>>> > >>>> > >>> > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html > >>>> > >>>> Thanks, > >>>> > >>>> Jiangjie (Becket) Qin > >>>> > >>>> On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <fhue...@gmail.com> > wrote: > >>>> > >>>>> Thanks for the update and driving the discussion Becket! > >>>>> +1 for starting a vote. > >>>>> > >>>>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin < > >>> becket....@gmail.com > >>>>>> : > >>>>> > >>>>>> Thanks Stephan. > >>>>>> > >>>>>> I think we have resolved all the comments on the wiki page. There > are > >>> two > >>>>>> minor changes made to the bylaws since last week. > >>>>>> 1. For 2/3 majority, the required attempts to reach out to binding > >>> voters > >>>>>> is reduced from 3 to 2. This helps shorten the voting process a > little > >>>>> bit. > >>>>>> 2. Clarified what is considered as the adoption of new codebase. > >>>>>> > >>>>>> I think we almost reached consensus. I'll start a voting thread in > two > >>>>> days > >>>>>> if there is no new concerns. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Jiangjie (Becket) Qin > >>>>>> > >>>>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org> > wrote: > >>>>>> > >>>>>>> I added a clarification to the table, clarifying that the current > >>>>>> phrasing > >>>>>>> means that committers do not need another +1 for their commits. > >>>>>>> > >>>>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fhue...@gmail.com> > >>>>> wrote: > >>>>>>> > >>>>>>>> Hi Becket, > >>>>>>>> > >>>>>>>> Thanks a lot for pushing this forward and addressing the feedback. > >>>>>>>> I'm very happy with the current state of the bylaws. > >>>>>>>> +1 to wait until Friday before starting a vote. > >>>>>>>> > >>>>>>>> Best, Fabian > >>>>>>>> > >>>>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin < > >>>>>>>> becket....@gmail.com > >>>>>>>>> : > >>>>>>>> > >>>>>>>>> Hi Everyone, > >>>>>>>>> > >>>>>>>>> Thanks for all the discussion and feedback. > >>>>>>>>> > >>>>>>>>> It seems that we have almost reached consensus. I'll leave the > >>>>>>> discussion > >>>>>>>>> thread open until this Friday. If there is no more concerns > raised, > >>>>>>> I'll > >>>>>>>>> start a voting thread after that. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> Jiangjie (Becket) Qin > >>>>>>>>> > >>>>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <car...@gmail.com> wrote: > >>>>>>>>> > >>>>>>>>>> Hi Becket, > >>>>>>>>>> > >>>>>>>>>> Thanks for noticing and resolving my comment around PMC removal > >>>>> and > >>>>>>> ASF > >>>>>>>>>> rules of PMC membership change process, which you seem to > neglect > >>>>>> in > >>>>>>>> the > >>>>>>>>>> summary of updates (smile). > >>>>>>>>>> > >>>>>>>>>> Best Regards, > >>>>>>>>>> Yu > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <becket....@gmail.com> > >>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi folks, > >>>>>>>>>>> > >>>>>>>>>>> Thanks for all the feedback. > >>>>>>>>>>> > >>>>>>>>>>> It seems that there are a few concerns over the emeritus status > >>>>>>>> after 6 > >>>>>>>>>>> months of inactivity. Given that the main purpose is just to > >>>>> make > >>>>>>>> sure > >>>>>>>>>> 2/3 > >>>>>>>>>>> majority can pass and we sort of have a solution for that, I > >>>>> just > >>>>>>>>> updated > >>>>>>>>>>> the draft with the following changes: > >>>>>>>>>>> > >>>>>>>>>>> 1. Removed the inactivity term for emeritus committers / PMCs. > >>>>> A > >>>>>>>>>> committer > >>>>>>>>>>> / PMC will only be considered emeritus by their own claim. > >>>>>>>>>>> 2. Removed the approval process for reinstatement of the > >>>>> emeritus > >>>>>>>>>>> committers / PMCs. An emeritus committer / PMC will be > >>>>> reinstated > >>>>>>>> when > >>>>>>>>>> they > >>>>>>>>>>> send an email to the priv...@flink.apache.org. > >>>>>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still doable > >>>>>> when > >>>>>>>>> there > >>>>>>>>>>> are non-emeritus committers / PMCs who do not cast the vote. > >>>>>>>>>>> > >>>>>>>>>>> Please let me know if you have any further thoughts. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> > >>>>>>>>>>> Jiangjie (Becket) Qin > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin < > >>>>>> becket....@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi Fabian, > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks for the feedback. > >>>>>>>>>>>> > >>>>>>>>>>>> I agree that if we don't like emeritus committers / PMCs, we > >>>>>>> don't > >>>>>>>>> have > >>>>>>>>>>> to > >>>>>>>>>>>> do it. That said, emeritus status simply means whether an > >>>>>>>> individual > >>>>>>>>> is > >>>>>>>>>>>> active / inactive in the community. It does not make the > >>>>> merits > >>>>>>>>> earned > >>>>>>>>>> to > >>>>>>>>>>>> go away. For our purpose, emeritus status is mostly just a > >>>>> way > >>>>>> to > >>>>>>>>> make > >>>>>>>>>>> 2/3 > >>>>>>>>>>>> majority possible. As you noticed, since reaching out to > >>>>>> binding > >>>>>>>>> voters > >>>>>>>>>>> who > >>>>>>>>>>>> have not voted can achieve the same goal, the emeritus status > >>>>>> is > >>>>>>>> more > >>>>>>>>>> of > >>>>>>>>>>> an > >>>>>>>>>>>> optimization so we don't have to ping the inactive binding > >>>>>> voters > >>>>>>>>> every > >>>>>>>>>>>> time and wait for long. However, given that 2/3 majority > >>>>>> votings > >>>>>>>> are > >>>>>>>>>>> rare, > >>>>>>>>>>>> such communication cost is probably OK. So I think we can > >>>>>> remove > >>>>>>>> that > >>>>>>>>>>>> emeritus part from the bylaws. > >>>>>>>>>>>> > >>>>>>>>>>>> 1) We should add to the requirements of the PMC that they > >>>>> need > >>>>>> to > >>>>>>>>> make > >>>>>>>>>>>>> sure the project complies with brand issues and reports > >>>>> misuse > >>>>>>> of > >>>>>>>>> ASF > >>>>>>>>>>>>> brands. > >>>>>>>>>>>> > >>>>>>>>>>>> Good point. Added. > >>>>>>>>>>>> > >>>>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e., > >>>>> a > >>>>>> 3 > >>>>>>>> day > >>>>>>>>>> vote > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am? > >>>>>>>>>>>> > >>>>>>>>>>>> This might be a little tricky because people are from > >>>>> countries > >>>>>>> in > >>>>>>>>>>>> different time zones and with different holidays, and so on. > >>>>> If > >>>>>>> we > >>>>>>>>> are > >>>>>>>>>>>> worrying about 3 days minimum length is not enough for those > >>>>>> who > >>>>>>>> want > >>>>>>>>>> to > >>>>>>>>>>>> give feedback, we can make it 5 days. > >>>>>>>>>>>> > >>>>>>>>>>>> 3) Do we need a process do decide about removal of features > >>>>>> (like > >>>>>>>> the > >>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream > >>>>>> Python > >>>>>>>>>> APIs)? > >>>>>>>>>>>> > >>>>>>>>>>>> I assume such action should be covered by FLIP as it is a > >>>>>> change > >>>>>>> to > >>>>>>>>> the > >>>>>>>>>>>> API and probably needs a migration plan. It would be useful > >>>>> to > >>>>>>>> have a > >>>>>>>>>>>> formal deprecation procedure. But that might be better to be > >>>>>> put > >>>>>>>> into > >>>>>>>>>>>> somewhere else because the bylaws are primarily focusing on > >>>>> the > >>>>>>>>>>>> non-technical rules, whereas the deprecation seems more on > >>>>> the > >>>>>>>>>> technical > >>>>>>>>>>>> side. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> > >>>>>>>>>>>> Jiangjie (Becket) Qin > >>>>>>>>>>>> > >>>>>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske < > >>>>>>> fhue...@gmail.com> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>> > >>>>>>>>>>>>> First of all thank you very much Becket for starting this > >>>>>>>>> discussion! > >>>>>>>>>>>>> I think it is a very good idea and overdue to formally > >>>>> define > >>>>>>> some > >>>>>>>>> of > >>>>>>>>>>> our > >>>>>>>>>>>>> community processes. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Similar to Chesnay, I have concerns about the distinction > >>>>>>> between > >>>>>>>>>> active > >>>>>>>>>>>>> and non-active / emeritus committers and PMC members. > >>>>>>>>>>>>> My foremost concern is that this is not in the spirit of the > >>>>>>>> Apache > >>>>>>>>>> Way > >>>>>>>>>>>>> [1] > >>>>>>>>>>>>> which is (among other things) based on the idea of merit > >>>>> which > >>>>>>>> once > >>>>>>>>>>>>> earned, > >>>>>>>>>>>>> does not go away over time. > >>>>>>>>>>>>> I know other projects like Hadoop and Kafka have similar > >>>>>> clauses > >>>>>>>> in > >>>>>>>>>> the > >>>>>>>>>>>>> bylaws but IMO we don't need to adopt them if we don't like > >>>>>>> them. > >>>>>>>>>>>>> For example, I don't like the idea that committers or PMC > >>>>>>> members > >>>>>>>>> who > >>>>>>>>>>> are > >>>>>>>>>>>>> temporarily away from the project (for whatever reason: > >>>>>> parental > >>>>>>>>>> leave, > >>>>>>>>>>>>> sabbatical, health issues, etc.) need the PMC approval to be > >>>>>>>>> "active" > >>>>>>>>>>>>> again. > >>>>>>>>>>>>> As far as I am aware, we have not seen any issues with > >>>>>> inactive > >>>>>>>>>> members > >>>>>>>>>>> in > >>>>>>>>>>>>> the past. > >>>>>>>>>>>>> Moreover, it would be hard to track whether somebody became > >>>>>>>> inactive > >>>>>>>>>> at > >>>>>>>>>>>>> some point in time (which we would need to do, if I > >>>>> understand > >>>>>>> the > >>>>>>>>>>>>> proposal > >>>>>>>>>>>>> correctly). > >>>>>>>>>>>>> With the approach that Becket suggested in his last email > >>>>>>>> (reaching > >>>>>>>>>> out > >>>>>>>>>>> to > >>>>>>>>>>>>> binding voters who haven't voted yet), we could drop the > >>>>>>>> distinction > >>>>>>>>>>>>> between active and non-active committers and PMC members. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I also have a few minor comments: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 1) We should add to the requirements of the PMC [2] that > >>>>> they > >>>>>>> need > >>>>>>>>> to > >>>>>>>>>>> make > >>>>>>>>>>>>> sure the project complies with brand issues and reports > >>>>> misuse > >>>>>>> of > >>>>>>>>> ASF > >>>>>>>>>>>>> brands. > >>>>>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e., > >>>>>> a 3 > >>>>>>>> day > >>>>>>>>>>> vote > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am? > >>>>>>>>>>>>> 3) Do we need a process do decide about removal of features > >>>>>>> (like > >>>>>>>>> the > >>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream > >>>>>> Python > >>>>>>>>>> APIs)? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thank you, > >>>>>>>>>>>>> Fabian > >>>>>>>>>>>>> > >>>>>>>>>>>>> [1] https://www.apache.org/theapacheway/ > >>>>>>>>>>>>> [2] https://www.apache.org/dev/pmc.html > >>>>>>>>>>>>> > >>>>>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin < > >>>>>>>>>>>>> becket....@gmail.com > >>>>>>>>>>>>>> : > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Hequn, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see the reply > >>>>>> below: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one PMC > >>>>> in > >>>>>>>> the 3 > >>>>>>>>>>>>> binding > >>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers > >>>>> and 1 > >>>>>>>> PMC. > >>>>>>>>>>>>>>> I think this makes sense considering a FLIP could > >>>>> somehow > >>>>>>> be a > >>>>>>>>> big > >>>>>>>>>>>>>> feature > >>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no > >>>>> loss > >>>>>>> of > >>>>>>>>>>>>> flexibility > >>>>>>>>>>>>>>> as committers also have a chance to vote and participate > >>>>>> in > >>>>>>>> it. > >>>>>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs are > >>>>> the > >>>>>>>>>> following: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 1. Generally speaking, the PMC's primary responsibility is > >>>>>>>>> operating > >>>>>>>>>>> the > >>>>>>>>>>>>>> project and deciding what software to release on behalf of > >>>>>>> ASF. > >>>>>>>>>>>>> Committers, > >>>>>>>>>>>>>> on the other hand, are responsible for the technical part > >>>>> of > >>>>>>> the > >>>>>>>>>>>>> project. > >>>>>>>>>>>>>> So for FLIPs, a PMC's vote probably should not outweigh a > >>>>>>>>>> committer's > >>>>>>>>>>>>> vote. > >>>>>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is really > >>>>>>>>> convincing > >>>>>>>>>>>>> enough > >>>>>>>>>>>>>> to decide whether the FLIP is good to go or not. Also, if > >>>>>> some > >>>>>>>>>>>>> committers > >>>>>>>>>>>>>> have concern over a FLIP, they could just veto it. To me > >>>>> it > >>>>>> is > >>>>>>>>>>> actually > >>>>>>>>>>>>> a > >>>>>>>>>>>>>> more strict requirement to pass a FLIP than asking a PMC > >>>>> to > >>>>>>>> vote. > >>>>>>>>> In > >>>>>>>>>>>>>> practice, people will usually also address the concerns > >>>>> even > >>>>>>> if > >>>>>>>>> they > >>>>>>>>>>> are > >>>>>>>>>>>>>> not from a PMC/committer before they start the voting > >>>>>> process. > >>>>>>>> So > >>>>>>>>> I > >>>>>>>>>>>>> don't > >>>>>>>>>>>>>> see much benefit of requiring a PMC's vote in this case. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the votes > >>>>> no > >>>>>>>> longer > >>>>>>>>>>>>>> independent. Ideally, a vote is either binding or > >>>>>> non-binding > >>>>>>> by > >>>>>>>>>>>>> itself. If > >>>>>>>>>>>>>> we have the at-least-one-PMC-vote requirement here, > >>>>> imagine > >>>>>>>> there > >>>>>>>>>> have > >>>>>>>>>>>>> been > >>>>>>>>>>>>>> 3 committers who voted +1. But the FLIP still has not > >>>>>> passed, > >>>>>>> so > >>>>>>>>>> those > >>>>>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a +1, > >>>>>> those > >>>>>>>>> votes > >>>>>>>>>>>>>> suddenly become binding, which is a little awkward. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable to me. > >>>>>> Some > >>>>>>>>>>> thoughts > >>>>>>>>>>>>> on > >>>>>>>>>>>>>> this: > >>>>>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is probably > >>>>>>> because > >>>>>>>>>> there > >>>>>>>>>>>>> are > >>>>>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3 majority > >>>>>>>>>>> prohibitively > >>>>>>>>>>>>>> expensive. In our case, there are only 22 PMCs for > >>>>> Flink[2] > >>>>>>> and > >>>>>>>> a > >>>>>>>>>>> quick > >>>>>>>>>>>>>> search shows at most 6 of them have not sent email in the > >>>>>>>> recent 6 > >>>>>>>>>>>>> months > >>>>>>>>>>>>>> or so. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare. It is > >>>>>>>> designed > >>>>>>>>>> in > >>>>>>>>>>>>>> particular for the cases that broad opinions are > >>>>> important, > >>>>>>> more > >>>>>>>>>>>>>> specifically new codebase adoption or modification to the > >>>>>>>> bylaws. > >>>>>>>>>>>>> Therefore > >>>>>>>>>>>>>> such vote by its nature favors consensus over convenience. > >>>>>>> That > >>>>>>>>>> means > >>>>>>>>>>>>> any > >>>>>>>>>>>>>> alternative voting type reducing the coverage worth a > >>>>>> careful > >>>>>>>>>>> thinking. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3. I do agree that it does not make sense to have 2/3 > >>>>>> majority > >>>>>>>> if > >>>>>>>>>> such > >>>>>>>>>>>>>> requirement is no-longer doable over time. But I am a > >>>>> little > >>>>>>>>>> hesitant > >>>>>>>>>>> to > >>>>>>>>>>>>>> lower the threshold to lazy 2/3 majority in our case. What > >>>>>> do > >>>>>>>> you > >>>>>>>>>>> think > >>>>>>>>>>>>>> about doing the following: > >>>>>>>>>>>>>> - After the voting started, there will be at least 6 > >>>>>> days > >>>>>>>> for > >>>>>>>>>>>>> people to > >>>>>>>>>>>>>> cast their votes. > >>>>>>>>>>>>>> - After 6 days, if the result of the vote is still not > >>>>>>>>>> determined, > >>>>>>>>>>>>> the > >>>>>>>>>>>>>> person who started the vote should reach out to the > >>>>> binding > >>>>>>>> voters > >>>>>>>>>> who > >>>>>>>>>>>>> have > >>>>>>>>>>>>>> not voted yet for at least 3 times and at least 7 days > >>>>>> between > >>>>>>>>> each > >>>>>>>>>>>>> time. > >>>>>>>>>>>>>> If a binding voter still did not respond, the vote from > >>>>> that > >>>>>>>> voter > >>>>>>>>>>> will > >>>>>>>>>>>>> be > >>>>>>>>>>>>>> excluded from the 2/3 majority counting. > >>>>>>>>>>>>>> This would ensure the coverage at our best effort while > >>>>>> still > >>>>>>>> let > >>>>>>>>>> the > >>>>>>>>>>>>> 2/3 > >>>>>>>>>>>>>> majority vote make progress. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Jiangjie (Becket) Qin > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> [1] https://projects.apache.org/committee.html?hadoop > >>>>>>>>>>>>>> [2] https://projects.apache.org/committee.html?flink > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward < > >>>>>>>>> forwardxu...@gmail.com> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Big +1 on this. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> best > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> forward > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hequn Cheng <chenghe...@gmail.com> 于2019年7月21日周日 > >>>>>> 下午1:30写道： > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi Becket, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Big +1 on this. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least > >>>>>>> includes a > >>>>>>>>> PMC > >>>>>>>>>>>>> vote. > >>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one > >>>>> PMC > >>>>>> in > >>>>>>>>> the 3 > >>>>>>>>>>>>>> binding > >>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers > >>>>>> and 1 > >>>>>>>>> PMC. > >>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could > >>>>>> somehow > >>>>>>>> be a > >>>>>>>>>> big > >>>>>>>>>>>>>>> feature > >>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no > >>>>>> loss > >>>>>>>> of > >>>>>>>>>>>>>> flexibility > >>>>>>>>>>>>>>>> as committers also have a chance to vote and > >>>>> participate > >>>>>>> in > >>>>>>>>> it. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> ========Seperator======== > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> For the nice bylaws, I agree with the general idea and > >>>>>>> most > >>>>>>>> of > >>>>>>>>>> the > >>>>>>>>>>>>>>> content. > >>>>>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority". The > >>>>>>> main > >>>>>>>>>>> concern > >>>>>>>>>>>>> is > >>>>>>>>>>>>>> I > >>>>>>>>>>>>>>> am > >>>>>>>>>>>>>>>> not sure if it is doable in practice. The reasons are: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a > >>>>>> committer > >>>>>>>> or a > >>>>>>>>>> PMC > >>>>>>>>>>>>>> member > >>>>>>>>>>>>>>>> is active if he or she sends one email to the mailing > >>>>>> list > >>>>>>>>>> every 6 > >>>>>>>>>>>>>>> months. > >>>>>>>>>>>>>>>> While the minimum length of the vote is only 6 days. > >>>>>> There > >>>>>>>> are > >>>>>>>>>>>>> chances > >>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>> during the vote, some of the active members are still > >>>>>>>> offline > >>>>>>>>> of > >>>>>>>>>>> the > >>>>>>>>>>>>>>>> community. > >>>>>>>>>>>>>>>> 2. The code of Flink is changing fast and not everyone > >>>>>>> fully > >>>>>>>>>>>>>> understands > >>>>>>>>>>>>>>>> every part. We don't need to force people to vote if > >>>>>> they > >>>>>>>> are > >>>>>>>>>> not > >>>>>>>>>>>>> sure > >>>>>>>>>>>>>>>> about it. It may also make the final result less > >>>>>> credible. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Given the above reasons, perhaps we can change the 2/3 > >>>>>>>>> Majority > >>>>>>>>>> to > >>>>>>>>>>>>> lazy > >>>>>>>>>>>>>>> 2/3 > >>>>>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a > >>>>>> higher > >>>>>>>>>>> threshold, > >>>>>>>>>>>>>>>> however, more practical. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> What do you think? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin < > >>>>>>>>>> becket....@gmail.com > >>>>>>>>>>>> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi Jincheng, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki page. > >>>>>>> Just > >>>>>>>> a > >>>>>>>>>>> brief > >>>>>>>>>>>>>>>> summary, > >>>>>>>>>>>>>>>>> the current bylaws do require some of the FLIPs to > >>>>> get > >>>>>>> PMC > >>>>>>>>>>>>> approval > >>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>> their impact is big enough. But it leaves majority > >>>>> of > >>>>>>> the > >>>>>>>>>>>>> technical > >>>>>>>>>>>>>>>>> decisions to the committers who are supposed to be > >>>>>>>>> responsible > >>>>>>>>>>> for > >>>>>>>>>>>>>>> making > >>>>>>>>>>>>>>>>> such decisions. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Re: Robert, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I agree we can simply remove the requirement of +1 > >>>>>> from > >>>>>>> a > >>>>>>>>>>>>> non-author > >>>>>>>>>>>>>>>>> committer and revisit it in a bit. After all, it > >>>>> does > >>>>>>> not > >>>>>>>>> make > >>>>>>>>>>>>> sense > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just > >>>>>> updated > >>>>>>>> the > >>>>>>>>>>> bylaws > >>>>>>>>>>>>>>> wiki. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger < > >>>>>>>>>>>>> rmetz...@apache.org > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the > >>>>>>> current > >>>>>>>>>>> status > >>>>>>>>>>>>> in > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> bylaws, and then implementing changes one by one > >>>>> is > >>>>>> a > >>>>>>>> very > >>>>>>>>>>>>> involved > >>>>>>>>>>>>>>>> task. > >>>>>>>>>>>>>>>>>> Unless there's somebody who's really eager to > >>>>> drive > >>>>>>>> this, > >>>>>>>>> I > >>>>>>>>>>>>> would > >>>>>>>>>>>>>>> stick > >>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for > >>>>>> Flink, > >>>>>>>> even > >>>>>>>>>> if > >>>>>>>>>>>>> this > >>>>>>>>>>>>>>>> means > >>>>>>>>>>>>>>>>>> some changes. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> The cross-review requirement is the last big open > >>>>>>> point > >>>>>>>> in > >>>>>>>>>>> this > >>>>>>>>>>>>>>>>> discussion. > >>>>>>>>>>>>>>>>>> It seems that a there is a slight tendency in the > >>>>>>>>> discussion > >>>>>>>>>>>>> that > >>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>> not feasible given the current pull request review > >>>>>>>>>> situation. > >>>>>>>>>>>>>>>>>> For the sake of bringing this discussion to a > >>>>>>>> conclusion, > >>>>>>>>>> I'm > >>>>>>>>>>>>> fine > >>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>>> leaving this requirement out. As we are currently > >>>>>>> adding > >>>>>>>>>> more > >>>>>>>>>>>>>>>> committers > >>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> the project, we might be able to revisit this > >>>>>>> discussion > >>>>>>>>> in > >>>>>>>>>> 3 > >>>>>>>>>>> - > >>>>>>>>>>>>> 6 > >>>>>>>>>>>>>>>> months. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun < > >>>>>>>>>>>>>>> sunjincheng...@gmail.com > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Hi Becket, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks for the proposal. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least > >>>>>>>>> includes a > >>>>>>>>>>> PMC > >>>>>>>>>>>>>>> vote. > >>>>>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects > >>>>>> the > >>>>>>>>> user's > >>>>>>>>>>>>>>> interface > >>>>>>>>>>>>>>>>>>> changes. What do you think? (I leave the comment > >>>>>> in > >>>>>>>> the > >>>>>>>>>>> wiki.) > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>>>>> Jincheng > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Dawid Wysakowicz <dwysakow...@apache.org> > >>>>>>>> 于2019年7月17日周三 > >>>>>>>>>>>>>> 下午9:12写道： > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say > >>>>>> that > >>>>>>> I > >>>>>>>>>> really > >>>>>>>>>>>>> like > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> proposed bylaws! > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> One comment, I also have the same concerns as > >>>>>>>>> expressed > >>>>>>>>>> by > >>>>>>>>>>>>> few > >>>>>>>>>>>>>>>> people > >>>>>>>>>>>>>>>>>>>> before that the "committer +1" on code change > >>>>>>> might > >>>>>>>> be > >>>>>>>>>>> hard > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>> achieve > >>>>>>>>>>>>>>>>>>>> currently. On the other hand I would say this > >>>>>>> would > >>>>>>>> be > >>>>>>>>>>>>>> beneficial > >>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and > >>>>>>> knowledge > >>>>>>>>>>>>> sharing. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I was just wondering what should be the next > >>>>>> step > >>>>>>>> for > >>>>>>>>>>> this? > >>>>>>>>>>>>> I > >>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>> it > >>>>>>>>>>>>>>>>>>>> would make sense to already use those bylaws > >>>>> and > >>>>>>> put > >>>>>>>>>> them > >>>>>>>>>>> to > >>>>>>>>>>>>>> PMC > >>>>>>>>>>>>>>>>> vote. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Dawid > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote: > >>>>>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I > >>>>> think. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly. > >>>>>> If > >>>>>>> we > >>>>>>>>> are > >>>>>>>>>>>>>> stating > >>>>>>>>>>>>>>>>> that a > >>>>>>>>>>>>>>>>>>>> single > >>>>>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code > >>>>>> review, > >>>>>>>>> with 0 > >>>>>>>>>>>>> hours > >>>>>>>>>>>>>>>> delay > >>>>>>>>>>>>>>>>>> (de > >>>>>>>>>>>>>>>>>>>> facto > >>>>>>>>>>>>>>>>>>>>>>> the current state), we should also write > >>>>>> down > >>>>>>>> that > >>>>>>>>>>> this > >>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>> subject > >>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect > >>>>>> the > >>>>>>>>>>>>> components > >>>>>>>>>>>>>>>>> expertise > >>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de > >>>>> facto > >>>>>>>>> current > >>>>>>>>>>>>>> state). > >>>>>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the > >>>>>>>>>> intention, > >>>>>>>>>>>>> but > >>>>>>>>>>>>>> it > >>>>>>>>>>>>>>>> may > >>>>>>>>>>>>>>>>>> be a > >>>>>>>>>>>>>>>>>>>>>> little difficult to enforce and follow.. > >>>>>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague > >>>>>>> rule > >>>>>>>>>>> anyway, > >>>>>>>>>>>>>>>> intended > >>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like > >>>>>> to > >>>>>>>> just > >>>>>>>>>>>>> avoid a > >>>>>>>>>>>>>>>>>> situation > >>>>>>>>>>>>>>>>>>>> when someone violates current uncodified state > >>>>>> and > >>>>>>>>>> refers > >>>>>>>>>>> to > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> bylaws > >>>>>>>>>>>>>>>>>>>> which are saying merging with any committer +1 > >>>>>> is > >>>>>>>>> always > >>>>>>>>>>>>> fine > >>>>>>>>>>>>>>> (like > >>>>>>>>>>>>>>>>>> mine > >>>>>>>>>>>>>>>>>>> +1 > >>>>>>>>>>>>>>>>>>>> for flink-python or flink-ml). > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Piotrek > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek > >>>>> < > >>>>>>>>>>>>>>> aljos...@apache.org > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the > >>>>>> FLIP. > >>>>>>>>> This > >>>>>>>>>> is > >>>>>>>>>>>>> just > >>>>>>>>>>>>>>>> about > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> voting, before that there needs to be the > >>>>>>> discussion > >>>>>>>>>>>>> thread. If > >>>>>>>>>>>>>>>> three > >>>>>>>>>>>>>>>>>>> days > >>>>>>>>>>>>>>>>>>>> have passed on a vote and there is consensus > >>>>>>> (i.e. 3 > >>>>>>>>>>>>>>>> committers/PMCs > >>>>>>>>>>>>>>>>>> have > >>>>>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me. > >>>>>> So > >>>>>>>> far, > >>>>>>>>>> we > >>>>>>>>>>>>> have > >>>>>>>>>>>>>>>> rarely > >>>>>>>>>>>>>>>>>> see > >>>>>>>>>>>>>>>>>>>> any FLIPs pass that formal bar. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread, > >>>>> we > >>>>>>> want > >>>>>>>>> to > >>>>>>>>>>> use > >>>>>>>>>>>>>> "lazy > >>>>>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think > >>>>>>> that > >>>>>>>>>> should > >>>>>>>>>>>>> be > >>>>>>>>>>>>>>>> changed > >>>>>>>>>>>>>>>>>>> from > >>>>>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a > >>>>>>> current > >>>>>>>>>> state > >>>>>>>>>>>>> that > >>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>> all > >>>>>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to > >>>>>>> come > >>>>>>>> up > >>>>>>>>>>> with > >>>>>>>>>>>>>>>> something > >>>>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>> reflects the common state, according to > >>>>>>>>> PMCs/commiters, > >>>>>>>>>>> that > >>>>>>>>>>>>>>> might > >>>>>>>>>>>>>>>>>> take a > >>>>>>>>>>>>>>>>>>>> very long time. In that case I think it’s > >>>>> better > >>>>>>> to > >>>>>>>>>> adopt > >>>>>>>>>>>>>>> something > >>>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>> all like, rather than trying to capture how we > >>>>>> do > >>>>>>> it > >>>>>>>>>> now. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Aljoscha > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski > >>>>> < > >>>>>>>>>>>>>>> pi...@ververica.com > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally > >>>>> speaking > >>>>>> +1 > >>>>>>>>> from > >>>>>>>>>> my > >>>>>>>>>>>>> side > >>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> general idea and most of the content. I also > >>>>> see > >>>>>>>> merit > >>>>>>>>>> to > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> Chesney's > >>>>>>>>>>>>>>>>>>>> proposal to start from the current state. I > >>>>>> think > >>>>>>>>> either > >>>>>>>>>>>>> would > >>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>> fine > >>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>> me. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Couple of comments: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> 1. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from > >>>>> another > >>>>>>>>>> committer > >>>>>>>>>>>>> would > >>>>>>>>>>>>>>>> slow > >>>>>>>>>>>>>>>>>> down > >>>>>>>>>>>>>>>>>>>> and put even more strain on the current > >>>>>> reviewing > >>>>>>>>>>> bottleneck > >>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>>>> having. Even if the change clear and simple, > >>>>>>> context > >>>>>>>>>>> switch > >>>>>>>>>>>>>> cost > >>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>> quite > >>>>>>>>>>>>>>>>>>>> high, and that’s just one less PR that the > >>>>>> second > >>>>>>>>>> “cross” > >>>>>>>>>>>>>>> committer > >>>>>>>>>>>>>>>>>> could > >>>>>>>>>>>>>>>>>>>> have reviewed somewhere else in that time. > >>>>>>> Besides, > >>>>>>>>>>> current > >>>>>>>>>>>>>> setup > >>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>> have (with no cross +1 from another committer > >>>>>>>>> required) > >>>>>>>>>>>>> works > >>>>>>>>>>>>>>> quite > >>>>>>>>>>>>>>>>>> well > >>>>>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On > >>>>>> the > >>>>>>>>> other > >>>>>>>>>>> hand > >>>>>>>>>>>>>>>>> reviewing > >>>>>>>>>>>>>>>>>>>> bottleneck is. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> 2. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I think a committer should know when to > >>>>> ask > >>>>>>>>> another > >>>>>>>>>>>>>>> committer > >>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>> feedback or not. > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly. > >>>>>> If > >>>>>>> we > >>>>>>>>> are > >>>>>>>>>>>>>> stating > >>>>>>>>>>>>>>>>> that a > >>>>>>>>>>>>>>>>>>>> single committers +1 is good enough for code > >>>>>>> review, > >>>>>>>>>> with > >>>>>>>>>>> 0 > >>>>>>>>>>>>>> hours > >>>>>>>>>>>>>>>>> delay > >>>>>>>>>>>>>>>>>>> (de > >>>>>>>>>>>>>>>>>>>> facto the current state), we should also write > >>>>>>> down > >>>>>>>>> that > >>>>>>>>>>>>> this > >>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>> subject > >>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> the best judgement of the committer to respect > >>>>>> the > >>>>>>>>>>>>> components > >>>>>>>>>>>>>>>>> expertise > >>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de facto > >>>>>>> current > >>>>>>>>>>> state). > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> 3. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think > >>>>>>>>> currently > >>>>>>>>>>>>> might > >>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems > >>>>>> if > >>>>>>>>>>> respected > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> letter. > >>>>>>>>>>>>>>>>>>>> Again I think it depends highly on whether the > >>>>>>>>>> committers > >>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>> highest > >>>>>>>>>>>>>>>>>>>> expertise in the affected components managed > >>>>> to > >>>>>>>>> respond > >>>>>>>>>> or > >>>>>>>>>>>>> not. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Piotrek > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay > >>>>> Schepler > >>>>>> < > >>>>>>>>>>>>>>>> ches...@apache.org> > >>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first > >>>>>>> write > >>>>>>>>> down > >>>>>>>>>>>>> Bylaws > >>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>> reflect the current state, and then have > >>>>>> separate > >>>>>>>>>>>>> discussions > >>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that > >>>>>> this > >>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>> will > >>>>>>>>>>>>>>>>>>> quickly > >>>>>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being > >>>>>>>>> discussed > >>>>>>>>>>> at > >>>>>>>>>>>>>> once. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote: > >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket > >>>>>> Qin > >>>>>>> < > >>>>>>>>>>>>>>>>>> becket....@gmail.com> > >>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments > >>>>> and > >>>>>>>>>> feedback. > >>>>>>>>>>>>>> Please > >>>>>>>>>>>>>>>> see > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> replies > >>>>>>>>>>>>>>>>>>>>>>>>>> below: > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------- > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code > >>>>> Change" > >>>>>> we > >>>>>>>>> could > >>>>>>>>>>>>> also > >>>>>>>>>>>>>>> add a > >>>>>>>>>>>>>>>>> row > >>>>>>>>>>>>>>>>>>>> for "Code > >>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a > >>>>>> reference > >>>>>>> to > >>>>>>>>> the > >>>>>>>>>>>>> FLIP > >>>>>>>>>>>>>>>> process > >>>>>>>>>>>>>>>>>>>> page. A > >>>>>>>>>>>>>>>>>>>>>>>>>> FLIP > >>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules > >>>>> for > >>>>>>>>>> approvals, > >>>>>>>>>>>>> etc. > >>>>>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------- > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft > >>>>> currently > >>>>>>>>> requires > >>>>>>>>>>>>> "one > >>>>>>>>>>>>>> +1 > >>>>>>>>>>>>>>>>> from a > >>>>>>>>>>>>>>>>>>>> committer > >>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch > >>>>> followed > >>>>>>> by a > >>>>>>>>>> Lazy > >>>>>>>>>>>>>>> approval > >>>>>>>>>>>>>>>>> (not > >>>>>>>>>>>>>>>>>>>> counting > >>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving > >>>>> to > >>>>>>> lazy > >>>>>>>>>>>>> majority > >>>>>>>>>>>>>> if > >>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>> -1 > >>>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>> received". > >>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a > >>>>>>>>> committer > >>>>>>>>>>>>> always > >>>>>>>>>>>>>>>>> needs a > >>>>>>>>>>>>>>>>>>>> review > >>>>>>>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I > >>>>>>> know > >>>>>>>>> this > >>>>>>>>>>> is > >>>>>>>>>>>>>>>> currently > >>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>> always > >>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors, > >>>>>>>> contributor > >>>>>>>>>>>>> reviews > >>>>>>>>>>>>>> & > >>>>>>>>>>>>>>>>> +1s). > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how > >>>>> we > >>>>>>> can > >>>>>>>>>> make > >>>>>>>>>>> it > >>>>>>>>>>>>>> easy > >>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> follow the > >>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more > >>>>>> Flink-specific > >>>>>>>> Jira > >>>>>>>>>>>>>> workflows > >>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>> ticket > >>>>>>>>>>>>>>>>>>>>>>>>>> types + > >>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this > >>>>> is > >>>>>>>>>> certainly > >>>>>>>>>>>>>> "Step > >>>>>>>>>>>>>>>> 2", > >>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>> believe, > >>>>>>>>>>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy & > >>>>>>> transparent > >>>>>>>>> as > >>>>>>>>>>>>>> possible, > >>>>>>>>>>>>>>>>>>>> otherwise they > >>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken. > >>>>>>>>>>>>>>>>>>>>>>>>>> & Re: Till > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the > >>>>>>> author > >>>>>>>>> and > >>>>>>>>>>>>>> getting > >>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>> +1 > >>>>>>>>>>>>>>>>>>> from > >>>>>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer > >>>>>> should > >>>>>>>> know > >>>>>>>>>>> when > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>> ask > >>>>>>>>>>>>>>>>>>> another > >>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence, > >>>>> I > >>>>>>>> would > >>>>>>>>>> not > >>>>>>>>>>>>>> enforce > >>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>>>>>>>> strictly > >>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the > >>>>> author > >>>>>>> is > >>>>>>>> a > >>>>>>>>>>>>> committer > >>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>> course > >>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist. > >>>>>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern > >>>>> here. > >>>>>>>> TBH, > >>>>>>>>> in > >>>>>>>>>>>>> Kafka > >>>>>>>>>>>>>>>>>>> occasionally > >>>>>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are > >>>>> still > >>>>>>>>> merged > >>>>>>>>>>>>> without > >>>>>>>>>>>>>>>>>> following > >>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is > >>>>> rare. > >>>>>>>> That > >>>>>>>>>>> said, > >>>>>>>>>>>>> I > >>>>>>>>>>>>>>> still > >>>>>>>>>>>>>>>>>> think > >>>>>>>>>>>>>>>>>>>> an > >>>>>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes > >>>>> sense > >>>>>>> due > >>>>>>>>> to > >>>>>>>>>>> the > >>>>>>>>>>>>>>>> following > >>>>>>>>>>>>>>>>>>>> reasons: > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need > >>>>>> to > >>>>>>>> make > >>>>>>>>>>> sure > >>>>>>>>>>>>>> every > >>>>>>>>>>>>>>>>> patch > >>>>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a > >>>>>>>> little > >>>>>>>>>>>>> difficult > >>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> guarantee if > >>>>>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for > >>>>>>> many > >>>>>>>>>>>>> reasons. In > >>>>>>>>>>>>>>>> some > >>>>>>>>>>>>>>>>>>>> cases, a > >>>>>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough > >>>>> knowledge > >>>>>>>> about > >>>>>>>>>> the > >>>>>>>>>>>>>>> project > >>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>> make > >>>>>>>>>>>>>>>>>>>> a good > >>>>>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the > >>>>>> contributors > >>>>>>>> are > >>>>>>>>>> more > >>>>>>>>>>>>>>> eagerly > >>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>> get a > >>>>>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are > >>>>>> willing > >>>>>>>> to > >>>>>>>>>>> lower > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> review > >>>>>>>>>>>>>>>>>>> bar. > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review > >>>>>> among > >>>>>>>>>>>>> committers, > >>>>>>>>>>>>>>>> which > >>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>> personally > >>>>>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually > >>>>>>> form > >>>>>>>>>>>>> consistent > >>>>>>>>>>>>>>>> design > >>>>>>>>>>>>>>>>>>>> principles > >>>>>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the > >>>>>>>> committers > >>>>>>>>>> will > >>>>>>>>>>>>> know > >>>>>>>>>>>>>>> how > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> other > >>>>>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn > >>>>>> from > >>>>>>>> each > >>>>>>>>>>>>> other. > >>>>>>>>>>>>>> So > >>>>>>>>>>>>>>>> they > >>>>>>>>>>>>>>>>>>> tend > >>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how > >>>>>>> things > >>>>>>>>>> should > >>>>>>>>>>>>> be > >>>>>>>>>>>>>>> done > >>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>> general. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to > >>>>>>>> consider > >>>>>>>>>> the > >>>>>>>>>>>>>>> following > >>>>>>>>>>>>>>>>> two > >>>>>>>>>>>>>>>>>>>> scenarios: > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes > >>>>> a > >>>>>>> lot > >>>>>>>> of > >>>>>>>>>>>>>>> iterations. > >>>>>>>>>>>>>>>>> Then > >>>>>>>>>>>>>>>>>>>> the patch > >>>>>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes > >>>>>> time > >>>>>>>>>> because > >>>>>>>>>>>>> there > >>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>>> things > >>>>>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified / > >>>>> changed. > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is > >>>>> very > >>>>>>>> smooth > >>>>>>>>>> and > >>>>>>>>>>>>>> quick, > >>>>>>>>>>>>>>>> so > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> patch is > >>>>>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a > >>>>> patch > >>>>>>> does > >>>>>>>>> not > >>>>>>>>>>>>> take > >>>>>>>>>>>>>>> much > >>>>>>>>>>>>>>>>>> time. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the > >>>>>> patch > >>>>>>>>> from a > >>>>>>>>>>>>>>> committer > >>>>>>>>>>>>>>>>>> falls > >>>>>>>>>>>>>>>>>>>> either in > >>>>>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here > >>>>> is > >>>>>>> to > >>>>>>>>>> review > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> patch > >>>>>>>>>>>>>>>>>>>> because > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually > >>>>> needs > >>>>>>> to > >>>>>>>> be > >>>>>>>>>>>>>> reviewed. > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not > >>>>>> take > >>>>>>>>> much > >>>>>>>>>>> time > >>>>>>>>>>>>>>>> anyways. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter > >>>>>>> case > >>>>>>>> 1 > >>>>>>>>> if > >>>>>>>>>>> we > >>>>>>>>>>>>>> skip > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> cross-review. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------ > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Robert > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki > >>>>>> and > >>>>>>>> made > >>>>>>>>>> the > >>>>>>>>>>>>>>>> following > >>>>>>>>>>>>>>>>>>>> modifications > >>>>>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments: > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role > >>>>> section. > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus" > >>>>>> to > >>>>>>>>>>>>> "consensus" > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>> align > >>>>>>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary > >>>>> and > >>>>>>>> other > >>>>>>>>>>>>>> projects. > >>>>>>>>>>>>>>>>>>>>>>>>>> 3. review board -> pull request > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------- > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like > >>>>> unnecessary > >>>>>>>>> noise. > >>>>>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure > >>>>>> 2/3 > >>>>>>>>>>> majority > >>>>>>>>>>>>> is > >>>>>>>>>>>>>>>> still > >>>>>>>>>>>>>>>>>>>> feasible in > >>>>>>>>>>>>>>>>>>>>>>>>>> practice. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in > >>>>> the > >>>>>>>> draft > >>>>>>>>>>>>> compared > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>> existing > >>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to > >>>>>>>>> highlight > >>>>>>>>>>>>> these > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>> discuss > >>>>>>>>>>>>>>>>>>>> them > >>>>>>>>>>>>>>>>>>>>>>>>>>> one by one. > >>>>>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not > >>>>>>> familiar > >>>>>>>>>> enough > >>>>>>>>>>>>> with > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>> current Flink > >>>>>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I > >>>>> saw > >>>>>>> you > >>>>>>>>>>>>> commented > >>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>> some > >>>>>>>>>>>>>>>>>>> part > >>>>>>>>>>>>>>>>>>>> in the > >>>>>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete? > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------- > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka > >>>>>>> bylaws? > >>>>>>>>> I’m > >>>>>>>>>>>>> asking > >>>>>>>>>>>>>>>>> because > >>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>> quite > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind > >>>>> essentially > >>>>>>>>> adopting > >>>>>>>>>>> the > >>>>>>>>>>>>>>> Kafka > >>>>>>>>>>>>>>>>>>> bylaws. > >>>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>>>> mean, > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to > >>>>>> try > >>>>>>>> to > >>>>>>>>>>>>> re-invent > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> wheel > >>>>>>>>>>>>>>>>>>>> here. > >>>>>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first > >>>>> version > >>>>>>> of > >>>>>>>>> the > >>>>>>>>>>>>> draft > >>>>>>>>>>>>>> was > >>>>>>>>>>>>>>>>>> almost > >>>>>>>>>>>>>>>>>>>> identical > >>>>>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already > >>>>> caught a > >>>>>>> few > >>>>>>>>>>>>>> inconsistent > >>>>>>>>>>>>>>>>>> places. > >>>>>>>>>>>>>>>>>>>> So it > >>>>>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to > >>>>>> make > >>>>>>>> sure > >>>>>>>>>> we > >>>>>>>>>>>>> truly > >>>>>>>>>>>>>>>> agree > >>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>> them. > >>>>>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them > >>>>>>>> shortly > >>>>>>>>>>> after > >>>>>>>>>>>>>>>> adoption. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the > >>>>> valuable > >>>>>>>>>> feedback. > >>>>>>>>>>>>> These > >>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>> great > >>>>>>>>>>>>>>>>>>>>>>>>>> discussion. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM > >>>>> Aljoscha > >>>>>>>>> Krettek > >>>>>>>>>> < > >>>>>>>>>>>>>>>>>>>> aljos...@apache.org> > >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Big +1 > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka > >>>>>>> bylaws? > >>>>>>>>> I’m > >>>>>>>>>>>>> asking > >>>>>>>>>>>>>>>>>> because I > >>>>>>>>>>>>>>>>>>>> quite > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind > >>>>> essentially > >>>>>>>>> adopting > >>>>>>>>>>> the > >>>>>>>>>>>>>>> Kafka > >>>>>>>>>>>>>>>>>>> bylaws. > >>>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>>>> mean, > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to > >>>>>> try > >>>>>>>> to > >>>>>>>>>>>>> re-invent > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> wheel > >>>>>>>>>>>>>>>>>>>> here. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the > >>>>>>>>>> “committer > >>>>>>>>>>>>> +1” > >>>>>>>>>>>>>>>>>>> requirement. > >>>>>>>>>>>>>>>>>>>> We > >>>>>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I > >>>>> would > >>>>>>>>> actually > >>>>>>>>>>> be > >>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> favour > >>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>>>> requiring > >>>>>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more > >>>>>>>>>> complicated. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till > >>>>>> Rohrmann > >>>>>>> < > >>>>>>>>>>>>>>>>>> trohrm...@apache.org> > >>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft > >>>>>>>> Becket. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of > >>>>> emeritus > >>>>>>> (or > >>>>>>>>>> active > >>>>>>>>>>>>> vs. > >>>>>>>>>>>>>>>>>> inactive), > >>>>>>>>>>>>>>>>>>>> it > >>>>>>>>>>>>>>>>>>>>>>>>>> won't > >>>>>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority > >>>>> vote > >>>>>>>>> because > >>>>>>>>>>> we > >>>>>>>>>>>>>>> already > >>>>>>>>>>>>>>>>>> have > >>>>>>>>>>>>>>>>>>>> too > >>>>>>>>>>>>>>>>>>>>>>>>>> many > >>>>>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the > >>>>>>>> author > >>>>>>>>>> and > >>>>>>>>>>>>>>> getting a > >>>>>>>>>>>>>>>>> +1 > >>>>>>>>>>>>>>>>>>>> from a > >>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer > >>>>>> should > >>>>>>>>> know > >>>>>>>>>>>>> when to > >>>>>>>>>>>>>>> ask > >>>>>>>>>>>>>>>>>>> another > >>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. > >>>>> Hence, I > >>>>>>>> would > >>>>>>>>>> not > >>>>>>>>>>>>>>> enforce > >>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>>>>>>>>> strictly > >>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the > >>>>>> author > >>>>>>>> is a > >>>>>>>>>>>>>> committer > >>>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>> course > >>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers, > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Till > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM > >>>>> Chesnay > >>>>>>>>>> Schepler > >>>>>>>>>>> < > >>>>>>>>>>>>>>>>>>>> ches...@apache.org> > >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like > >>>>>>> unnecessary > >>>>>>>>>> noise. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in > >>>>>> the > >>>>>>>>> draft > >>>>>>>>>>>>>> compared > >>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> existing > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way > >>>>> to > >>>>>>>>>> highlight > >>>>>>>>>>>>>> these > >>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> discuss > >>>>>>>>>>>>>>>>>>>>>>>>>> them > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger > >>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off > >>>>> this > >>>>>>>>>>> discussion > >>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> creating > >>>>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>>> draft > >>>>>>>>>>>>>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, > >>>>> that > >>>>>> a > >>>>>>>>>>> committer > >>>>>>>>>>>>>>> always > >>>>>>>>>>>>>>>>>> needs > >>>>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>>>>>>>>> review > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far > >>>>>> as I > >>>>>>>>> know > >>>>>>>>>>>>> this is > >>>>>>>>>>>>>>>>>> currently > >>>>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>>>>>> always > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors, > >>>>>>>>>> contributor > >>>>>>>>>>>>>>> reviews > >>>>>>>>>>>>>>>> & > >>>>>>>>>>>>>>>>>>> +1s). > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw, > >>>>> if > >>>>>>> we > >>>>>>>>> had > >>>>>>>>>>>>> cases > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> past > >>>>>>>>>>>>>>>>>>>> where > >>>>>>>>>>>>>>>>>>>>>>>>>>> code > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND > >>>>> we > >>>>>>>>> believe > >>>>>>>>>>>>> that we > >>>>>>>>>>>>>>>> have > >>>>>>>>>>>>>>>>>>> enough > >>>>>>>>>>>>>>>>>>>>>>>>>>> capacity > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's > >>>>>>>> approval. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM > >>>>>>>> Konstantin > >>>>>>>>>>> Knauf > >>>>>>>>>>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> konstan...@ververica.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this, > >>>>>>> Becket. I > >>>>>>>>>> have > >>>>>>>>>>>>> two > >>>>>>>>>>>>>>>> remarks > >>>>>>>>>>>>>>>>>>>> regarding > >>>>>>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code > >>>>>>> Change" > >>>>>>>> we > >>>>>>>>>>> could > >>>>>>>>>>>>>> also > >>>>>>>>>>>>>>>>> add a > >>>>>>>>>>>>>>>>>>>> row for > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Code > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a > >>>>>>>> reference > >>>>>>>>> to > >>>>>>>>>>> the > >>>>>>>>>>>>>> FLIP > >>>>>>>>>>>>>>>>>> process > >>>>>>>>>>>>>>>>>>>> page. > >>>>>>>>>>>>>>>>>>>>>>>>>> A > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different > >>>>> rules > >>>>>>> for > >>>>>>>>>>>>> approvals, > >>>>>>>>>>>>>>> etc. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft > >>>>>>> currently > >>>>>>>>>>> requires > >>>>>>>>>>>>>> "one > >>>>>>>>>>>>>>>> +1 > >>>>>>>>>>>>>>>>>>> from a > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch > >>>>>>> followed > >>>>>>>>> by a > >>>>>>>>>>>>> Lazy > >>>>>>>>>>>>>>>>> approval > >>>>>>>>>>>>>>>>>>> (not > >>>>>>>>>>>>>>>>>>>>>>>>>>> counting > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), > >>>>> moving > >>>>>>> to > >>>>>>>>> lazy > >>>>>>>>>>>>>> majority > >>>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>> -1 > >>>>>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> received". > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, > >>>>>> that a > >>>>>>>>>>> committer > >>>>>>>>>>>>>>> always > >>>>>>>>>>>>>>>>>>> needs a > >>>>>>>>>>>>>>>>>>>>>>>>>> review > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far > >>>>>> as I > >>>>>>>>> know > >>>>>>>>>>>>> this is > >>>>>>>>>>>>>>>>>> currently > >>>>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>>>>>> always > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors, > >>>>>>>>>> contributor > >>>>>>>>>>>>>>> reviews > >>>>>>>>>>>>>>>> & > >>>>>>>>>>>>>>>>>>> +1s). > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about > >>>>>> how > >>>>>>>> we > >>>>>>>>>> can > >>>>>>>>>>>>> make > >>>>>>>>>>>>>> it > >>>>>>>>>>>>>>>>> easy > >>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> follow > >>>>>>>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more > >>>>>>>> Flink-specific > >>>>>>>>>> Jira > >>>>>>>>>>>>>>>> workflows > >>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> ticket > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> types + > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While > >>>>>> this > >>>>>>> is > >>>>>>>>>>>>> certainly > >>>>>>>>>>>>>>>> "Step > >>>>>>>>>>>>>>>>>> 2", > >>>>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>>>>>>>> believe, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy & > >>>>>>>>> transparent > >>>>>>>>>>> as > >>>>>>>>>>>>>>>> possible, > >>>>>>>>>>>>>>>>>>>> otherwise > >>>>>>>>>>>>>>>>>>>>>>>>>>> they > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM > >>>>>> Becket > >>>>>>>>> Qin < > >>>>>>>>>>>>>>>>>>>> becket....@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP > >>>>>> process > >>>>>>>>>>> discussion > >>>>>>>>>>>>>>> thread > >>>>>>>>>>>>>>>>>> [1], > >>>>>>>>>>>>>>>>>>>>>>>>>> currently > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to > >>>>>>> govern > >>>>>>>>> the > >>>>>>>>>>>>>>> operation > >>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>> project. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Such > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the > >>>>>> community > >>>>>>>> to > >>>>>>>>>>>>>> coordinate > >>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>> contribute > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of > >>>>>>> other > >>>>>>>>>>>>> processes > >>>>>>>>>>>>>>> such > >>>>>>>>>>>>>>>>> as > >>>>>>>>>>>>>>>>>>>> FLIP. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws > >>>>> page > >>>>>>> and > >>>>>>>>>> would > >>>>>>>>>>>>> like > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> start a > >>>>>>>>>>>>>>>>>>>>>>>>>>> discussion > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone > >>>>> in > >>>>>>> the > >>>>>>>>>>>>> community. > >>>>>>>>>>>>>>>> It'll > >>>>>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>> great to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> hear > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1] > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>> > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions > >>>>>> Architect > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 - > >>>>>>>> 31.08.2019, > >>>>>>>>>>>>> 05.09. - > >>>>>>>>>>>>>>>>>>> 06.09.2010 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse > >>>>>> 115, > >>>>>>>>> 10115 > >>>>>>>>>>>>>> Berlin, > >>>>>>>>>>>>>>>>>> Germany > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht > >>>>>>>> Charlottenburg: > >>>>>>>>>> HRB > >>>>>>>>>>>>>> 158244 > >>>>>>>>>>>>>>> B > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas > >>>>>>> Tzoumas, > >>>>>>>>> Dr. > >>>>>>>>>>>>> Stephan > >>>>>>>>>>>>>>>> Ewen > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >
