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