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