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