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 >>>>>>>>>>>
signature.asc
Description: OpenPGP digital signature
