http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Flink-project-bylaws-tp30409p30502.html
amendments. My gut feeling is that this discussion will quickly become a
> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <
[hidden email]> 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 <
[hidden email]>
>> 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 <
[hidden email]> 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 <
[hidden email]>
>>> 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 <
>>>>>
[hidden email]>
>>>>>> 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 <
[hidden email]>
>>>>> 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
>>>>>>>
>>>>>
>>>