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
