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