Hi Robert, Thanks for help apply the changes. I agree we should freeze the change to the bylaws page starting from now. For this particular addition of clarification, I'll send a notice in the voting thread to let who have already voted to know.
Thanks, Jiangjie (Becket) Qin On Tue, Aug 13, 2019 at 1:29 PM Robert Metzger <rmetz...@apache.org> wrote: > 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 > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > > >
