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