Yes, I'd also link it in the wiki.
On 28/08/2019 15:27, Robert Metzger wrote:
Thanks a lot for running the vote Becket!
I have removed the "(draft)" from the wiki page :)
Should we link the bylaws also from the Flink website?
On Thu, Aug 22, 2019 at 6:23 PM Becket Qin <becket....@gmail.com> wrote:
Thanks for collecting the ideas of Bylaws changes. It is a good idea!
Jiangjie (Becket) Qin
On Thu, Aug 22, 2019 at 12:11 PM Robert Metzger <rmetz...@apache.org>
wrote:
I have started a Wiki page (editable by all) for collecting ideas for
Bylaws changes, so that we can batch changes together and then vote on
them:
https://cwiki.apache.org/confluence/display/FLINK/Ideas+for+Bylaw+changes
On Tue, Aug 13, 2019 at 1:41 PM Becket Qin <becket....@gmail.com> wrote:
Hi Robert,
Thanks for help apply the changes. I agree we should freeze the change
to
the bylaws page starting from now. For this particular addition of
clarification, I'll send a notice in the voting thread to let who have
already voted to know.
Thanks,
Jiangjie (Becket) Qin
On Tue, Aug 13, 2019 at 1:29 PM Robert Metzger <rmetz...@apache.org>
wrote:
Hi Becket,
I've applied the proposed change to the document:
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026&selectedPageVersions=20&selectedPageVersions=19
I would propose to stop accepting changes to the document now, as it
might
start a discussion about the validity of the vote and the bylaws
itself.
Changes to the document require a 2/3 majority.
On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels <m...@apache.org>
wrote:
Hi Becket,
Thanks for clarifying and updating the draft. The changes look good
to
me.
I don't feel strong about a 2/3 majority in case of committer/PMC
removal. Like you pointed out, both provide a significant hurdle
due
to
possible vetos or a 2/3 majority.
Thanks,
Max
On 13.08.19 10:36, Becket Qin wrote:
Piotr just reminded me that there was a previous suggestion to
clarify
a
committer's responsibility when commit his/her own patch. So I'd
like
to
incorporate that in the bylaws. The additional clarification is
following
in bold and italic font.
one +1 from a committer followed by a Lazy approval (not counting
the
vote
of the contributor), moving to lazy majority if a -1 is
received.
Note that this implies that committers can +1 their own commits
and
merge
right away. *However, the committe**rs should use their best
judgement
to
respect the components expertise and ongoing development plan.*
This does not really change any of the existing bylaws, just
about
clarification.
If there is no objection to this additional clarification, after
the
bylaws
wiki is updated, I'll send an update notice to the voting thread
to
inform
those who already voted about this addition.
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 12, 2019 at 11:19 AM Becket Qin <
becket....@gmail.com>
wrote:
Hi Maximillian,
Thanks for the feedback. Please see the reply below:
Step 2 should include a personal email to the PMC members in
question.
I'm afraid reminders inside the vote thread could be overlooked
easily.
This is exactly what I meant to say by "reach out" :) I just
made
it
more
explicit.
The way the terms are described in the draft, the consensus is
"lazy",
i.e. requires only 3 binding votes. I'd suggest renaming it to
"Lazy
Consensus". This is in line with the other definitions such as
"Lazy
Majority".
It was initially called "lazy consensus", but Robert pointed out
that
"lazy consensus" actually means something different in ASF term
[1].
Here "lazy" pretty much means "assume everyone is +1 unless
someone
says
otherwise". This means any vote that requires a minimum number
of
+1
is
not
really a "lazy" vote.
Removing a committer / PMC member only requires 3 binding votes.
I'd
expect an important action like this to require a 2/3 majority.
Personally I think consensus is good enough here. PMC members
can
cast a
veto if they disagree about the removal. In some sense, it is
more
difficult than with 2/3 majority to remove a committer / PMC
member.
Also,
it might be a hard decision for some PMC members if they have
never
worked
with the person in question. That said, I am OK to change it to
2/3
majority as this will happen very rarely.
Thanks,
Jiangjie (Becket) Qin
[1] https://www.apache.org/foundation/voting.html#LazyConsensus
On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <
m...@apache.org>
wrote:
I'm a bit late to the discussion here. Three suggestions:
1) Procedure for "insufficient active binding voters to reach
2/3
majority
1. Wait until the minimum length of the voting passes.
2. Publicly reach out to the remaining binding voters in
the
voting
mail thread for at least 2 attempts with at least 7 days
between
two
attempts.
3. If the binding voter being contacted still failed to
respond
after all the attempts, the binding voter will be considered as
inactive
for the purpose of this particular voting.
Step 2 should include a personal email to the PMC members in
question.
I'm afraid reminders inside the vote thread could be overlooked
easily.
2) "Consensus" => "Lazy Consensus"
The way the terms are described in the draft, the consensus is
"lazy",
i.e. requires only 3 binding votes. I'd suggest renaming it to
"Lazy
Consensus". This is in line with the other definitions such as
"Lazy
Majority".
3) Committer / PMC Removal
Removing a committer / PMC member only requires 3 binding
votes.
I'd
expect an important action like this to require a 2/3 majority.
Do you think we could incorporate those suggestions?
Thanks,
Max
On 11.08.19 10:14, Becket Qin wrote:
Hi folks,
Thanks for all the discussion and support. I have started the
voting
thread.
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
Thanks,
Jiangjie (Becket) Qin
On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <
fhue...@gmail.com
wrote:
Thanks for the update and driving the discussion Becket!
+1 for starting a vote.
Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
becket....@gmail.com
:
Thanks Stephan.
I think we have resolved all the comments on the wiki page.
There
are
two
minor changes made to the bylaws since last week.
1. For 2/3 majority, the required attempts to reach out to
binding
voters
is reduced from 3 to 2. This helps shorten the voting
process
a
little
bit.
2. Clarified what is considered as the adoption of new
codebase.
I think we almost reached consensus. I'll start a voting
thread
in
two
days
if there is no new concerns.
Thanks,
Jiangjie (Becket) Qin
On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <
se...@apache.org
wrote:
I added a clarification to the table, clarifying that the
current
phrasing
means that committers do not need another +1 for their
commits.
On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <
fhue...@gmail.com
wrote:
Hi Becket,
Thanks a lot for pushing this forward and addressing the
feedback.
I'm very happy with the current state of the bylaws.
+1 to wait until Friday before starting a vote.
Best, Fabian
Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
becket....@gmail.com
:
Hi Everyone,
Thanks for all the discussion and feedback.
It seems that we have almost reached consensus. I'll
leave
the
discussion
thread open until this Friday. If there is no more
concerns
raised,
I'll
start a voting thread after that.
Thanks,
Jiangjie (Becket) Qin
On Fri, Jul 26, 2019 at 6:49 PM Yu Li <car...@gmail.com>
wrote:
Hi Becket,
Thanks for noticing and resolving my comment around PMC
removal
and
ASF
rules of PMC membership change process, which you seem
to
neglect
in
the
summary of updates (smile).
Best Regards,
Yu
On Wed, 24 Jul 2019 at 04:32, Becket Qin <
becket....@gmail.com>
wrote:
Hi folks,
Thanks for all the feedback.
It seems that there are a few concerns over the
emeritus
status
after 6
months of inactivity. Given that the main purpose is
just
to
make
sure
2/3
majority can pass and we sort of have a solution for
that,
I
just
updated
the draft with the following changes:
1. Removed the inactivity term for emeritus committers
/
PMCs.
A
committer
/ PMC will only be considered emeritus by their own
claim.
2. Removed the approval process for reinstatement of
the
emeritus
committers / PMCs. An emeritus committer / PMC will be
reinstated
when
they
send an email to the priv...@flink.apache.org.
3. Adde the term to ensure 2/3 majority voting is still
doable
when
there
are non-emeritus committers / PMCs who do not cast the
vote.
Please let me know if you have any further thoughts.
Thanks,
Jiangjie (Becket) Qin
On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
becket....@gmail.com>
wrote:
Hi Fabian,
Thanks for the feedback.
I agree that if we don't like emeritus committers /
PMCs,
we
don't
have
to
do it. That said, emeritus status simply means whether
an
individual
is
active / inactive in the community. It does not make
the
merits
earned
to
go away. For our purpose, emeritus status is mostly
just a
way
to
make
2/3
majority possible. As you noticed, since reaching out
to
binding
voters
who
have not voted can achieve the same goal, the emeritus
status
is
more
of
an
optimization so we don't have to ping the inactive
binding
voters
every
time and wait for long. However, given that 2/3
majority
votings
are
rare,
such communication cost is probably OK. So I think we
can
remove
that
emeritus part from the bylaws.
1) We should add to the requirements of the PMC that
they
need
to
make
sure the project complies with brand issues and
reports
misuse
of
ASF
brands.
Good point. Added.
2) Do we want to restrict voting days to working days,
i.e.,
a
3
day
vote
that starts on Friday 11:00am ends on Wednesday
11:00am?
This might be a little tricky because people are from
countries
in
different time zones and with different holidays, and
so
on.
If
we
are
worrying about 3 days minimum length is not enough for
those
who
want
to
give feedback, we can make it 5 days.
3) Do we need a process do decide about removal of
features
(like
the
DataSet API for instance or the legacy
DataSet/DataStream
Python
APIs)?
I assume such action should be covered by FLIP as it
is
a
change
to
the
API and probably needs a migration plan. It would be
useful
to
have a
formal deprecation procedure. But that might be better
to
be
put
into
somewhere else because the bylaws are primarily
focusing
on
the
non-technical rules, whereas the deprecation seems
more
on
the
technical
side.
Thanks,
Jiangjie (Becket) Qin
On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
fhue...@gmail.com>
wrote:
Hi all,
First of all thank you very much Becket for starting
this
discussion!
I think it is a very good idea and overdue to
formally
define
some
of
our
community processes.
Similar to Chesnay, I have concerns about the
distinction
between
active
and non-active / emeritus committers and PMC members.
My foremost concern is that this is not in the spirit
of
the
Apache
Way
[1]
which is (among other things) based on the idea of
merit
which
once
earned,
does not go away over time.
I know other projects like Hadoop and Kafka have
similar
clauses
in
the
bylaws but IMO we don't need to adopt them if we
don't
like
them.
For example, I don't like the idea that committers or
PMC
members
who
are
temporarily away from the project (for whatever
reason:
parental
leave,
sabbatical, health issues, etc.) need the PMC
approval
to
be
"active"
again.
As far as I am aware, we have not seen any issues
with
inactive
members
in
the past.
Moreover, it would be hard to track whether somebody
became
inactive
at
some point in time (which we would need to do, if I
understand
the
proposal
correctly).
With the approach that Becket suggested in his last
email
(reaching
out
to
binding voters who haven't voted yet), we could drop
the
distinction
between active and non-active committers and PMC
members.
I also have a few minor comments:
1) We should add to the requirements of the PMC [2]
that
they
need
to
make
sure the project complies with brand issues and
reports
misuse
of
ASF
brands.
2) Do we want to restrict voting days to working
days,
i.e.,
a 3
day
vote
that starts on Friday 11:00am ends on Wednesday
11:00am?
3) Do we need a process do decide about removal of
features
(like
the
DataSet API for instance or the legacy
DataSet/DataStream
Python
APIs)?
Thank you,
Fabian
[1] https://www.apache.org/theapacheway/
[2] https://www.apache.org/dev/pmc.html
Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket
Qin <
becket....@gmail.com
:
Hi Hequn,
Thanks for sharing your thoughts. Please see the
reply
below:
Perhaps what Jincheng means is to hold at least one
PMC
in
the 3
binding
votes? i.e, the vote could have 2 binding
committers
and 1
PMC.
I think this makes sense considering a FLIP could
somehow
be a
big
feature
which may impacts Flink a lot. Meanwhile, there is
no
loss
of
flexibility
as committers also have a chance to vote and
participate
in
it.
A few concerns of requiring a PMC vote in all FLIPs
are
the
following:
1. Generally speaking, the PMC's primary
responsibility
is
operating
the
project and deciding what software to release on
behalf
of
ASF.
Committers,
on the other hand, are responsible for the technical
part
of
the
project.
So for FLIPs, a PMC's vote probably should not
outweigh
a
committer's
vote.
Besides, I am not sure whether a single PMCs +1 is
really
convincing
enough
to decide whether the FLIP is good to go or not.
Also,
if
some
committers
have concern over a FLIP, they could just veto it.
To
me
it
is
actually
a
more strict requirement to pass a FLIP than asking a
PMC
to
vote.
In
practice, people will usually also address the
concerns
even
if
they
are
not from a PMC/committer before they start the
voting
process.
So
I
don't
see much benefit of requiring a PMC's vote in this
case.
2. The at-least-one-PMC-vote requirement makes the
votes
no
longer
independent. Ideally, a vote is either binding or
non-binding
by
itself. If
we have the at-least-one-PMC-vote requirement here,
imagine
there
have
been
3 committers who voted +1. But the FLIP still has
not
passed,
so
those
votes are effectively non-binding. Now a PMC votes a
+1,
those
votes
suddenly become binding, which is a little awkward.
The lazy 2/3 majority suggestion sounds reasonable
to
me.
Some
thoughts
on
this:
1. One reason Hadoop uses lazy 2/3 majority is
probably
because
there
are
104 PMC members[1] for Hadoop which makes the 2/3
majority
prohibitively
expensive. In our case, there are only 22 PMCs for
Flink[2]
and
a
quick
search shows at most 6 of them have not sent email
in
the
recent 6
months
or so.
2. 2/3 majority votes are supposed to be very rare.
It
is
designed
in
particular for the cases that broad opinions are
important,
more
specifically new codebase adoption or modification
to
the
bylaws.
Therefore
such vote by its nature favors consensus over
convenience.
That
means
any
alternative voting type reducing the coverage worth
a
careful
thinking.
3. I do agree that it does not make sense to have
2/3
majority
if
such
requirement is no-longer doable over time. But I am
a
little
hesitant
to
lower the threshold to lazy 2/3 majority in our
case.
What
do
you
think
about doing the following:
- After the voting started, there will be at
least 6
days
for
people to
cast their votes.
- After 6 days, if the result of the vote is
still
not
determined,
the
person who started the vote should reach out to the
binding
voters
who
have
not voted yet for at least 3 times and at least 7
days
between
each
time.
If a binding voter still did not respond, the vote
from
that
voter
will
be
excluded from the 2/3 majority counting.
This would ensure the coverage at our best effort
while
still
let
the
2/3
majority vote make progress.
Thanks,
Jiangjie (Becket) Qin
[1]
https://projects.apache.org/committee.html?hadoop
[2]
https://projects.apache.org/committee.html?flink
On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
forwardxu...@gmail.com>
wrote:
Big +1 on this.
best
forward
Hequn Cheng <chenghe...@gmail.com> 于2019年7月21日周日
下午1:30写道：
Hi Becket,
Big +1 on this.
Regarding the vote of FLIP, preferably at least
includes a
PMC
vote.
Perhaps what Jincheng means is to hold at least
one
PMC
in
the 3
binding
votes? i.e, the vote could have 2 binding
committers
and 1
PMC.
I think this makes sense considering a FLIP could
somehow
be a
big
feature
which may impacts Flink a lot. Meanwhile, there is
no
loss
of
flexibility
as committers also have a chance to vote and
participate
in
it.
========Seperator========
For the nice bylaws, I agree with the general idea
and
most
of
the
content.
Only share some thoughts about the "2/3 Majority".
The
main
concern
is
I
am
not sure if it is doable in practice. The reasons
are:
1. If we follow the bylaws strictly, it means a
committer
or a
PMC
member
is active if he or she sends one email to the
mailing
list
every 6
months.
While the minimum length of the vote is only 6
days.
There
are
chances
that
during the vote, some of the active members are
still
offline
of
the
community.
2. The code of Flink is changing fast and not
everyone
fully
understands
every part. We don't need to force people to vote
if
they
are
not
sure
about it. It may also make the final result less
credible.
Given the above reasons, perhaps we can change the
2/3
Majority
to
lazy
2/3
Majority, just as the Hadoop bylaws[1]. It makes a
higher
threshold,
however, more practical.
What do you think?
[1] https://hadoop.apache.org/bylaws.html
On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
becket....@gmail.com
wrote:
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
