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