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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
