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