Hi Jincheng, Thanks for the comments. I replied on the wiki page. Just a brief summary, the current bylaws do require some of the FLIPs to get PMC approval if their impact is big enough. But it leaves majority of the technical decisions to the committers who are supposed to be responsible for making such decisions.
Re: Robert, I agree we can simply remove the requirement of +1 from a non-author committer and revisit it in a bit. After all, it does not make sense to have a bylaw that we cannot afford. I have just updated the bylaws wiki. Thanks, Jiangjie (Becket) Qin On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <rmetz...@apache.org> wrote: > 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 > > > >>>>>>>>>>> > > > > > > > > >
