Hi Chesnay, We could do that. This might actually help unblock other things such as META-FLIP discussion quicker. Will you or someone familiar enough with the current state to write it down? If we are going to have an itemized discussion, I think the parts need immediate attention are: 1. Vote types (maybe just the one type for FLIP) 2. Which vote type should be for a FLIP. 3. Who has binding votes for a FLIP.
After these are clarified, we can conclude the FLIP-META discussion to fix the broken FLIP process. The Committer / PMC related discussions may not be that urgent as the current convention, although not clearly defined, seems working fine. Does that make sense? Re Piotr: Thanks for sharing your thoughts. 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... 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. > The vote requires a minimum length of 3 days, but it could last longer in order to collect enough binding votes. In most cases, only the committers with enough expertise / interest would vote on the FLIP. Thanks, Jiangjie (Becket) Qin On Fri, Jul 12, 2019 at 5:07 PM 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 > >>>>>>>> > >>>>>> > >>>> > > > >
