[DISCUSS] Flink project bylaws

[Fabian Hueske-2]

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 <[hidden email]
>:

> 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 <[hidden email]> wrote:
>
> > Big +1 on this.
> >
> >
> > best
> >
> > forward
> >
> > Hequn Cheng <[hidden email]> 于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 <[hidden email]>
> > 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 <[hidden email]
> >
> > > > 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 <
> > [hidden email]
> > > >
> > > > > 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 <[hidden email]> 于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 <
> > [hidden email]
> > > >
> > > > > > 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 <
> > [hidden email]
> > > >
> > > > > > 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 <
> > > [hidden email]>
> > > > > > > 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 <
> > > > > [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
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> [phone]
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> 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
> > > > > > > >>>>>>>>>>>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Becket Qin]

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 <[hidden email]> 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 <
> [hidden email]
> >:
>
> > 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 <[hidden email]>
> wrote:
> >
> > > Big +1 on this.
> > >
> > >
> > > best
> > >
> > > forward
> > >
> > > Hequn Cheng <[hidden email]> 于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 <[hidden email]>
> > > 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 <
> [hidden email]
> > >
> > > > > 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 <
> > > [hidden email]
> > > > >
> > > > > > 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 <[hidden email]> 于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 <
> > > [hidden email]
> > > > >
> > > > > > > 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 <
> > > [hidden email]
> > > > >
> > > > > > > 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 <
> > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > [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
> > > > > > > > >>>>>>>>>>>
> > > > > > > > >>>>>>>>>>> [phone]
> > > > > > > > >>>>>>>>>>>
> > > > > > > > >>>>>>>>>>>
> > > > > > > > >>>>>>>>>>> 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
> > > > > > > > >>>>>>>>>>>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Becket Qin]

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 [hidden email].
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 <[hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]
>> >:
>>
>> > 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 <[hidden email]>
>> wrote:
>> >
>> > > Big +1 on this.
>> > >
>> > >
>> > > best
>> > >
>> > > forward
>> > >
>> > > Hequn Cheng <[hidden email]> 于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 <[hidden email]>
>> > > 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 <
>> [hidden email]
>> > >
>> > > > > 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 <
>> > > [hidden email]
>> > > > >
>> > > > > > 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 <[hidden email]> 于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 <
>> > > [hidden email]
>> > > > >
>> > > > > > > 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 <
>> > > [hidden email]
>> > > > >
>> > > > > > > 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 <
>> > > > [hidden email]>
>> > > > > > > > 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 <
>> > > > > > [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
>> > > > > > > > >>>>>>>>>>>
>> > > > > > > > >>>>>>>>>>> [phone]
>> > > > > > > > >>>>>>>>>>>
>> > > > > > > > >>>>>>>>>>>
>> > > > > > > > >>>>>>>>>>> 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
>> > > > > > > > >>>>>>>>>>>
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

[Yu Li]

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 <[hidden email]> 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 [hidden email].
> 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 <[hidden email]> 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 <[hidden email]>
> 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 <
> >> [hidden email]
> >> >:
> >>
> >> > 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 <[hidden email]>
> >> wrote:
> >> >
> >> > > Big +1 on this.
> >> > >
> >> > >
> >> > > best
> >> > >
> >> > > forward
> >> > >
> >> > > Hequn Cheng <[hidden email]> 于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 <[hidden email]
> >
> >> > > 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 <
> >> [hidden email]
> >> > >
> >> > > > > 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 <
> >> > > [hidden email]
> >> > > > >
> >> > > > > > 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 <[hidden email]> 于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 <
> >> > > [hidden email]
> >> > > > >
> >> > > > > > > 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 <
> >> > > [hidden email]
> >> > > > >
> >> > > > > > > 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 <
> >> > > > [hidden email]>
> >> > > > > > > > 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 <
> >> > > > > > [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
> >> > > > > > > > >>>>>>>>>>>
> >> > > > > > > > >>>>>>>>>>> [phone]
> >> > > > > > > > >>>>>>>>>>>
> >> > > > > > > > >>>>>>>>>>>
> >> > > > > > > > >>>>>>>>>>> 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
> >> > > > > > > > >>>>>>>>>>>
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

[Becket Qin]

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
> > 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <
> > >> [hidden email]
> > >> >:
> > >>
> > >> > 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 <[hidden email]>
> > >> wrote:
> > >> >
> > >> > > Big +1 on this.
> > >> > >
> > >> > >
> > >> > > best
> > >> > >
> > >> > > forward
> > >> > >
> > >> > > Hequn Cheng <[hidden email]> 于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 <
> [hidden email]
> > >
> > >> > > 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 <
> > >> [hidden email]
> > >> > >
> > >> > > > > 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 <
> > >> > > [hidden email]
> > >> > > > >
> > >> > > > > > 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 <[hidden email]> 于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 <
> > >> > > [hidden email]
> > >> > > > >
> > >> > > > > > > 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 <
> > >> > > [hidden email]
> > >> > > > >
> > >> > > > > > > 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 <
> > >> > > > [hidden email]>
> > >> > > > > > > > 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 <
> > >> > > > > > [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
> > >> > > > > > > > >>>>>>>>>>>
> > >> > > > > > > > >>>>>>>>>>> [phone]
> > >> > > > > > > > >>>>>>>>>>>
> > >> > > > > > > > >>>>>>>>>>>
> > >> > > > > > > > >>>>>>>>>>> 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
> > >> > > > > > > > >>>>>>>>>>>
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

[Fabian Hueske-2]

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 <[hidden email]
>:

> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
> > > 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 <[hidden email]>
> > 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 <[hidden email]>
> > > 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 <
> > > >> [hidden email]
> > > >> >:
> > > >>
> > > >> > 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 <
> [hidden email]>
> > > >> wrote:
> > > >> >
> > > >> > > Big +1 on this.
> > > >> > >
> > > >> > >
> > > >> > > best
> > > >> > >
> > > >> > > forward
> > > >> > >
> > > >> > > Hequn Cheng <[hidden email]> 于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 <
> > [hidden email]
> > > >
> > > >> > > 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 <
> > > >> [hidden email]
> > > >> > >
> > > >> > > > > 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 <
> > > >> > > [hidden email]
> > > >> > > > >
> > > >> > > > > > 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 <[hidden email]> 于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 <
> > > >> > > [hidden email]
> > > >> > > > >
> > > >> > > > > > > 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 <
> > > >> > > [hidden email]
> > > >> > > > >
> > > >> > > > > > > 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 <
> > > >> > > > [hidden email]>
> > > >> > > > > > > > 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 <
> > > >> > > > > > [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
> > > >> > > > > > > > >>>>>>>>>>>
> > > >> > > > > > > > >>>>>>>>>>> [phone]
> > > >> > > > > > > > >>>>>>>>>>>
> > > >> > > > > > > > >>>>>>>>>>>
> > > >> > > > > > > > >>>>>>>>>>> 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
> > > >> > > > > > > > >>>>>>>>>>>
> > > >> > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>

[Stephan Ewen]

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 <[hidden email]> 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 <
> [hidden email]
> >:
>
> > 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
> > > > 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 <[hidden email]>
> > > 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 <[hidden email]>
> > > > 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 <
> > > > >> [hidden email]
> > > > >> >:
> > > > >>
> > > > >> > 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 <
> > [hidden email]>
> > > > >> wrote:
> > > > >> >
> > > > >> > > Big +1 on this.
> > > > >> > >
> > > > >> > >
> > > > >> > > best
> > > > >> > >
> > > > >> > > forward
> > > > >> > >
> > > > >> > > Hequn Cheng <[hidden email]> 于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 <
> > > [hidden email]
> > > > >
> > > > >> > > 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 <
> > > > >> [hidden email]
> > > > >> > >
> > > > >> > > > > 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 <
> > > > >> > > [hidden email]
> > > > >> > > > >
> > > > >> > > > > > 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 <[hidden email]>
> 于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 <
> > > > >> > > [hidden email]
> > > > >> > > > >
> > > > >> > > > > > > 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 <
> > > > >> > > [hidden email]
> > > > >> > > > >
> > > > >> > > > > > > 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 <
> > > > >> > > > [hidden email]>
> > > > >> > > > > > > > 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 <
> > > > >> > > > > > [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
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> [phone]
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> 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
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

[Becket Qin]

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 <[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]
> > >:
> >
> > > 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 <[hidden email]> 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 <[hidden email]>
> 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 [hidden email].
> > > > > 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 <[hidden email]>
> > > > 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 <
> [hidden email]>
> > > > > 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 <
> > > > > >> [hidden email]
> > > > > >> >:
> > > > > >>
> > > > > >> > 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 <
> > > [hidden email]>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > > Big +1 on this.
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > best
> > > > > >> > >
> > > > > >> > > forward
> > > > > >> > >
> > > > > >> > > Hequn Cheng <[hidden email]> 于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 <
> > > > [hidden email]
> > > > > >
> > > > > >> > > 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 <
> > > > > >> [hidden email]
> > > > > >> > >
> > > > > >> > > > > 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 <
> > > > > >> > > [hidden email]
> > > > > >> > > > >
> > > > > >> > > > > > 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 <[hidden email]>
> > 于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 <
> > > > > >> > > [hidden email]
> > > > > >> > > > >
> > > > > >> > > > > > > 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 <
> > > > > >> > > [hidden email]
> > > > > >> > > > >
> > > > > >> > > > > > > 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 <
> > > > > >> > > > [hidden email]>
> > > > > >> > > > > > > > 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
> <
> > > > > >> > > > > > [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
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> [phone]
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> 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
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > >
> > > > > >> > > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Fabian Hueske-2]

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 <[hidden email]>:

> 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 <[hidden email]> 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 <[hidden email]> 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 <
> > > [hidden email]
> > > >:
> > >
> > > > 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 <[hidden email]> 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 <[hidden email]>
> > 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 [hidden email].
> > > > > > 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 <
> [hidden email]>
> > > > > 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 <
> > [hidden email]>
> > > > > > 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 <
> > > > > > >> [hidden email]
> > > > > > >> >:
> > > > > > >>
> > > > > > >> > 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 <
> > > > [hidden email]>
> > > > > > >> wrote:
> > > > > > >> >
> > > > > > >> > > Big +1 on this.
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > best
> > > > > > >> > >
> > > > > > >> > > forward
> > > > > > >> > >
> > > > > > >> > > Hequn Cheng <[hidden email]> 于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 <
> > > > > [hidden email]
> > > > > > >
> > > > > > >> > > 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 <
> > > > > > >> [hidden email]
> > > > > > >> > >
> > > > > > >> > > > > 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 <
> > > > > > >> > > [hidden email]
> > > > > > >> > > > >
> > > > > > >> > > > > > 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 <[hidden email]>
> > > 于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 <
> > > > > > >> > > [hidden email]
> > > > > > >> > > > >
> > > > > > >> > > > > > > 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 <
> > > > > > >> > > [hidden email]
> > > > > > >> > > > >
> > > > > > >> > > > > > > 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
> <
> > > > > > >> > > > [hidden email]>
> > > > > > >> > > > > > > > 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
> > <
> > > > > > >> > > > > > [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
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> [phone]
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> 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
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Becket Qin]

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 <[hidden email]> 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 <[hidden email]
> >:
>
> > 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 <[hidden email]> 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 <[hidden email]>
> 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 <
> > > > [hidden email]
> > > > >:
> > > >
> > > > > 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 <[hidden email]> 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 <[hidden email]>
> > > 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 [hidden email].
> > > > > > > 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 <
> > [hidden email]>
> > > > > > 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 <
> > > [hidden email]>
> > > > > > > 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 <
> > > > > > > >> [hidden email]
> > > > > > > >> >:
> > > > > > > >>
> > > > > > > >> > 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 <
> > > > > [hidden email]>
> > > > > > > >> wrote:
> > > > > > > >> >
> > > > > > > >> > > Big +1 on this.
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > best
> > > > > > > >> > >
> > > > > > > >> > > forward
> > > > > > > >> > >
> > > > > > > >> > > Hequn Cheng <[hidden email]> 于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 <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > >> > > 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 <
> > > > > > > >> [hidden email]
> > > > > > > >> > >
> > > > > > > >> > > > > 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 <
> > > > > > > >> > > [hidden email]
> > > > > > > >> > > > >
> > > > > > > >> > > > > > 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 <[hidden email]>
> > > > 于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
> <
> > > > > > > >> > > [hidden email]
> > > > > > > >> > > > >
> > > > > > > >> > > > > > > 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
> <
> > > > > > > >> > > [hidden email]
> > > > > > > >> > > > >
> > > > > > > >> > > > > > > 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
> > <
> > > > > > > >> > > > [hidden email]>
> > > > > > > >> > > > > > > > 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
> > > <
> > > > > > > >> > > > > > [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
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> [phone]
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> 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
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[mxm]

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 <[hidden email]> 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 <[hidden email]
>>> :
>>
>>> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <
>>>>> [hidden email]
>>>>>> :
>>>>>
>>>>>> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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 [hidden email].
>>>>>>>> 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 <
>>> [hidden email]>
>>>>>>> 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 <
>>>> [hidden email]>
>>>>>>>> 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 <
>>>>>>>>>> [hidden email]
>>>>>>>>>>> :
>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>> [hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Big +1 on this.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> best
>>>>>>>>>>>>
>>>>>>>>>>>> forward
>>>>>>>>>>>>
>>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
>>>>>>> [hidden email]
>>>>>>>>>
>>>>>>>>>>>> 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 <
>>>>>>>>>> [hidden email]
>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 <[hidden email]>
>>>>> 于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
>> <
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>> <
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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
>>> <
>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>> 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
>>>> <
>>>>>>>>>>>>>>> [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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[Becket Qin]

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 <[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]
> >>> :
> >>
> >>> 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 <[hidden email]> 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 <[hidden email]>
> >> 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 <
> >>>>> [hidden email]
> >>>>>> :
> >>>>>
> >>>>>> 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 <[hidden email]> 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 <[hidden email]>
> >>>> 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 [hidden email].
> >>>>>>>> 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 <
> >>> [hidden email]>
> >>>>>>> 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 <
> >>>> [hidden email]>
> >>>>>>>> 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 <
> >>>>>>>>>> [hidden email]
> >>>>>>>>>>> :
> >>>>>>>>>>
> >>>>>>>>>>> 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 <
> >>>>>> [hidden email]>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Big +1 on this.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> best
> >>>>>>>>>>>>
> >>>>>>>>>>>> forward
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
> >>>>>>> [hidden email]
> >>>>>>>>>
> >>>>>>>>>>>> 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 <
> >>>>>>>>>> [hidden email]
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> 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 <
> >>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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 <[hidden email]>
> >>>>> 于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
> >> <
> >>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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
> >> <
> >>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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
> >>> <
> >>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>>> 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
> >>>> <
> >>>>>>>>>>>>>>> [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
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>

[Becket Qin]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]
>> >>> :
>> >>
>> >>> 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 <[hidden email]> 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 <[hidden email]>
>> >> 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 <
>> >>>>> [hidden email]
>> >>>>>> :
>> >>>>>
>> >>>>>> 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 <[hidden email]> 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 <[hidden email]>
>> >>>> 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 [hidden email].
>> >>>>>>>> 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 <
>> >>> [hidden email]>
>> >>>>>>> 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 <
>> >>>> [hidden email]>
>> >>>>>>>> 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 <
>> >>>>>>>>>> [hidden email]
>> >>>>>>>>>>> :
>> >>>>>>>>>>
>> >>>>>>>>>>> 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 <
>> >>>>>> [hidden email]>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Big +1 on this.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> best
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> forward
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
>> >>>>>>> [hidden email]
>> >>>>>>>>>
>> >>>>>>>>>>>> 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 <
>> >>>>>>>>>> [hidden email]
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>> 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 <
>> >>>>>>>>>>>> [hidden email]
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> 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 <[hidden email]>
>> >>>>> 于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
>> >> <
>> >>>>>>>>>>>> [hidden email]
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> 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
>> >> <
>> >>>>>>>>>>>> [hidden email]
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> 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
>> >>> <
>> >>>>>>>>>>>>> [hidden email]>
>> >>>>>>>>>>>>>>>>> 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
>> >>>> <
>> >>>>>>>>>>>>>>> [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
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>

[mxm]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>> [hidden email]
>>>>>> :
>>>>>
>>>>>> 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 <[hidden email]> 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 <[hidden email]>
>>>>> 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 <
>>>>>>>> [hidden email]
>>>>>>>>> :
>>>>>>>>
>>>>>>>>> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>> 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 [hidden email].
>>>>>>>>>>> 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 <
>>>>>> [hidden email]>
>>>>>>>>>> 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 <
>>>>>>> [hidden email]>
>>>>>>>>>>> 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 <
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>>>> [hidden email]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Big +1 on this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
>>>>>>>>>> [hidden email]
>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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 <[hidden email]>
>>>>>>>> 于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
>>>>> <
>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 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
>>>>> <
>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 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
>>>>>> <
>>>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>> <
>>>>>>>>>>>>>>>>>> [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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[Robert Metzger]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <
> >>> [hidden email]
> >>>>>> :
> >>>>>
> >>>>>> 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 <[hidden email]>
> 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 <[hidden email]>
> >>>>> 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 <
> >>>>>>>> [hidden email]
> >>>>>>>>> :
> >>>>>>>>
> >>>>>>>>> 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 <[hidden email]> 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 <[hidden email]>
> >>>>>>> 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 [hidden email].
> >>>>>>>>>>> 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 <
> >>>>>> [hidden email]>
> >>>>>>>>>> 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 <
> >>>>>>> [hidden email]>
> >>>>>>>>>>> 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 <
> >>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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 <
> >>>>>>>>> [hidden email]>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Big +1 on this.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> best
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> forward
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
> >>>>>>>>>> [hidden email]
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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 <
> >>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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 <
> >>>>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 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 <[hidden email]>
> >>>>>>>> 于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
> >>>>> <
> >>>>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 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
> >>>>> <
> >>>>>>>>>>>>>>> [hidden email]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 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
> >>>>>> <
> >>>>>>>>>>>>>>>> [hidden email]>
> >>>>>>>>>>>>>>>>>>>> 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
> >>>>>>> <
> >>>>>>>>>>>>>>>>>> [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
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>

[Becket Qin]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>
> > 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 <[hidden email]>
> > 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 <
> > >>> [hidden email]
> > >>>>>> :
> > >>>>>
> > >>>>>> 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 <[hidden email]>
> > 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 <[hidden email]
> >
> > >>>>> 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 <
> > >>>>>>>> [hidden email]
> > >>>>>>>>> :
> > >>>>>>>>
> > >>>>>>>>> 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 <[hidden email]>
> 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 <
> [hidden email]>
> > >>>>>>> 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 [hidden email].
> > >>>>>>>>>>> 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 <
> > >>>>>> [hidden email]>
> > >>>>>>>>>> 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 <
> > >>>>>>> [hidden email]>
> > >>>>>>>>>>> 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 <
> > >>>>>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 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 <
> > >>>>>>>>> [hidden email]>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Big +1 on this.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> best
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> forward
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
> > >>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 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 <
> > >>>>>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> 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 <
> > >>>>>>>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 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 <[hidden email]>
> > >>>>>>>> 于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
> > >>>>> <
> > >>>>>>>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> 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
> > >>>>> <
> > >>>>>>>>>>>>>>> [hidden email]
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> 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
> > >>>>>> <
> > >>>>>>>>>>>>>>>> [hidden email]>
> > >>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>> <
> > >>>>>>>>>>>>>>>>>> [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
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>

[Robert Metzger]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > 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 <[hidden email]>
> > > 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 <[hidden email]>
> > > 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 <
> > > >>> [hidden email]
> > > >>>>>> :
> > > >>>>>
> > > >>>>>> 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 <[hidden email]>
> > > 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 <
> [hidden email]
> > >
> > > >>>>> 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 <
> > > >>>>>>>> [hidden email]
> > > >>>>>>>>> :
> > > >>>>>>>>
> > > >>>>>>>>> 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 <[hidden email]>
> > 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 <
> > [hidden email]>
> > > >>>>>>> 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 [hidden email].
> > > >>>>>>>>>>> 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 <
> > > >>>>>> [hidden email]>
> > > >>>>>>>>>> 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 <
> > > >>>>>>> [hidden email]>
> > > >>>>>>>>>>> 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 <
> > > >>>>>>>>>>>>> [hidden email]
> > > >>>>>>>>>>>>>> :
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 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 <
> > > >>>>>>>>> [hidden email]>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Big +1 on this.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> best
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> forward
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
> > > >>>>>>>>>> [hidden email]
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 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 <
> > > >>>>>>>>>>>>> [hidden email]
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 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 <
> > > >>>>>>>>>>>>>>> [hidden email]
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 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 <[hidden email]>
> > > >>>>>>>> 于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
> > > >>>>> <
> > > >>>>>>>>>>>>>>> [hidden email]
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> 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
> > > >>>>> <
> > > >>>>>>>>>>>>>>> [hidden email]
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> 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
> > > >>>>>> <
> > > >>>>>>>>>>>>>>>> [hidden email]>
> > > >>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>> <
> > > >>>>>>>>>>>>>>>>>> [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
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
> >
>

[Becket Qin]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > 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 <[hidden email]>
> > > > 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 <
> [hidden email]>
> > > > 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 <[hidden email]
> >
> > > > 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 <
> > > > >>> [hidden email]
> > > > >>>>>> :
> > > > >>>>>
> > > > >>>>>> 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 <[hidden email]
> >
> > > > 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 <
> > [hidden email]
> > > >
> > > > >>>>> 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 <
> > > > >>>>>>>> [hidden email]
> > > > >>>>>>>>> :
> > > > >>>>>>>>
> > > > >>>>>>>>> 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 <[hidden email]>
> > > 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 <
> > > [hidden email]>
> > > > >>>>>>> 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 [hidden email].
> > > > >>>>>>>>>>> 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 <
> > > > >>>>>> [hidden email]>
> > > > >>>>>>>>>> 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 <
> > > > >>>>>>> [hidden email]>
> > > > >>>>>>>>>>> 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 <
> > > > >>>>>>>>>>>>> [hidden email]
> > > > >>>>>>>>>>>>>> :
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> 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 <
> > > > >>>>>>>>> [hidden email]>
> > > > >>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Big +1 on this.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> best
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> forward
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
> > > > >>>>>>>>>> [hidden email]
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> 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 <
> > > > >>>>>>>>>>>>> [hidden email]
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> 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 <
> > > > >>>>>>>>>>>>>>> [hidden email]
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> 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 <[hidden email]>
> > > > >>>>>>>> 于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
> > > > >>>>> <
> > > > >>>>>>>>>>>>>>> [hidden email]
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> 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
> > > > >>>>> <
> > > > >>>>>>>>>>>>>>> [hidden email]
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> 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
> > > > >>>>>> <
> > > > >>>>>>>>>>>>>>>> [hidden email]>
> > > > >>>>>>>>>>>>>>>>>>>> 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
> > > > >>>>>>> <
> > > > >>>>>>>>>>>>>>>>>> [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
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> >
>

[Robert Metzger]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]>
> > > > 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 <
> [hidden email]>
> > > > > 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 <
> > [hidden email]>
> > > > > 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 <
> [hidden email]
> > >
> > > > > 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 <
> > > > > >>> [hidden email]
> > > > > >>>>>> :
> > > > > >>>>>
> > > > > >>>>>> 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 <
> [hidden email]
> > >
> > > > > 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 <
> > > [hidden email]
> > > > >
> > > > > >>>>> 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 <
> > > > > >>>>>>>> [hidden email]
> > > > > >>>>>>>>> :
> > > > > >>>>>>>>
> > > > > >>>>>>>>> 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 <[hidden email]>
> > > > 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 <
> > > > [hidden email]>
> > > > > >>>>>>> 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 [hidden email].
> > > > > >>>>>>>>>>> 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 <
> > > > > >>>>>> [hidden email]>
> > > > > >>>>>>>>>> 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 <
> > > > > >>>>>>> [hidden email]>
> > > > > >>>>>>>>>>> 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 <
> > > > > >>>>>>>>>>>>> [hidden email]
> > > > > >>>>>>>>>>>>>> :
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> 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 <
> > > > > >>>>>>>>> [hidden email]>
> > > > > >>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Big +1 on this.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> best
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> forward
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
> > > > > >>>>>>>>>> [hidden email]
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> 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 <
> > > > > >>>>>>>>>>>>> [hidden email]
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> 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 <
> > > > > >>>>>>>>>>>>>>> [hidden email]
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> 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 <[hidden email]>
> > > > > >>>>>>>> 于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
> > > > > >>>>> <
> > > > > >>>>>>>>>>>>>>> [hidden email]
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> 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
> > > > > >>>>> <
> > > > > >>>>>>>>>>>>>>> [hidden email]
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> 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
> > > > > >>>>>> <
> > > > > >>>>>>>>>>>>>>>> [hidden email]>
> > > > > >>>>>>>>>>>>>>>>>>>> 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
> > > > > >>>>>>> <
> > > > > >>>>>>>>>>>>>>>>>> [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
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Chesnay Schepler-3]

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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>>> 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 <
>> [hidden email]>
>>>>>> 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 <
>>> [hidden email]>
>>>>>> 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 <
>> [hidden email]
>>>>>> 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 <
>>>>>>>>> [hidden email]
>>>>>>>>>>>> :
>>>>>>>>>>>> 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 <
>> [hidden email]
>>>>>> 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 <
>>>> [hidden email]
>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>> 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 <[hidden email]>
>>>>> 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 <
>>>>> [hidden email]>
>>>>>>>>>>>>> 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 [hidden email].
>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> Big +1 on this.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hequn Cheng <[hidden email]> 于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 <
>>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>>>>>>>> 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 <[hidden email]>
>>>>>>>>>>>>>> 于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
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>> [hidden email]>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>> [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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [phone]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>