I have started a Wiki page (editable by all) for collecting ideas for Bylaws changes, so that we can batch changes together and then vote on them: https://cwiki.apache.org/confluence/display/FLINK/Ideas+for+Bylaw+changes
On Tue, Aug 13, 2019 at 1:41 PM Becket Qin <becket....@gmail.com> wrote: > 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 > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > >
