Re: [DISCUSS] Flink project bylaws

[Stephan Ewen <se...@apache.org>]

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 <fh...@gmail.com> wrote:

> Hi Becket,
>
> Thanks a lot for pushing this forward and addressing the feedback.
> I'm very happy with the current state of the bylaws.
> +1 to wait until Friday before starting a vote.
>
> Best, Fabian
>
> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> becket.qin@gmail.com
> >:
>
> > Hi Everyone,
> >
> > Thanks for all the discussion and feedback.
> >
> > It seems that we have almost reached consensus. I'll leave the discussion
> > thread open until this Friday. If there is no more concerns raised, I'll
> > start a voting thread after that.
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com> wrote:
> >
> > > Hi Becket,
> > >
> > > Thanks for noticing and resolving my comment around PMC removal and ASF
> > > rules of PMC membership change process, which you seem to neglect in
> the
> > > summary of updates (smile).
> > >
> > > Best Regards,
> > > Yu
> > >
> > >
> > > On Wed, 24 Jul 2019 at 04:32, Becket Qin <be...@gmail.com> wrote:
> > >
> > > > Hi folks,
> > > >
> > > > Thanks for all the feedback.
> > > >
> > > > It seems that there are a few concerns over the emeritus status
> after 6
> > > > months of inactivity. Given that the main purpose is just to make
> sure
> > > 2/3
> > > > majority can pass and we sort of have a solution for that, I just
> > updated
> > > > the draft with the following changes:
> > > >
> > > > 1. Removed the inactivity term for emeritus committers / PMCs. A
> > > committer
> > > > / PMC will only be considered emeritus by their own claim.
> > > > 2. Removed the approval process for reinstatement of the emeritus
> > > > committers / PMCs. An emeritus committer / PMC will be reinstated
> when
> > > they
> > > > send an email to the private@flink.apache.org.
> > > > 3. Adde the term to ensure 2/3 majority voting is still doable when
> > there
> > > > are non-emeritus committers / PMCs who do not cast the vote.
> > > >
> > > > Please let me know if you have any further thoughts.
> > > >
> > > > Thanks,
> > > >
> > > > Jiangjie (Becket) Qin
> > > >
> > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <be...@gmail.com>
> > > wrote:
> > > >
> > > > > Hi Fabian,
> > > > >
> > > > > Thanks for the feedback.
> > > > >
> > > > > I agree that if we don't like emeritus committers / PMCs, we don't
> > have
> > > > to
> > > > > do it. That said, emeritus status simply means whether an
> individual
> > is
> > > > > active / inactive in the community. It does not make the merits
> > earned
> > > to
> > > > > go away. For our purpose, emeritus status is mostly just a way to
> > make
> > > > 2/3
> > > > > majority possible. As you noticed, since reaching out to binding
> > voters
> > > > who
> > > > > have not voted can achieve the same goal, the emeritus status is
> more
> > > of
> > > > an
> > > > > optimization so we don't have to ping the inactive binding voters
> > every
> > > > > time and wait for long. However, given that 2/3 majority votings
> are
> > > > rare,
> > > > > such communication cost is probably OK. So I think we can remove
> that
> > > > > emeritus part from the bylaws.
> > > > >
> > > > > 1) We should add to the requirements of the PMC that they need to
> > make
> > > > >> sure the project complies with brand issues and reports misuse of
> > ASF
> > > > >> brands.
> > > > >
> > > > > Good point. Added.
> > > > >
> > > > > 2) Do we want to restrict voting days to working days, i.e., a 3
> day
> > > vote
> > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > > >
> > > > > This might be a little tricky because people are from countries in
> > > > > different time zones and with different holidays, and so on. If we
> > are
> > > > > worrying about 3 days minimum length is not enough for those who
> want
> > > to
> > > > > give feedback, we can make it 5 days.
> > > > >
> > > > > 3) Do we need a process do decide about removal of features (like
> the
> > > > >> DataSet API for instance or the legacy DataSet/DataStream Python
> > > APIs)?
> > > > >
> > > > > I assume such action should be covered by FLIP as it is a change to
> > the
> > > > > API and probably needs a migration plan. It would be useful to
> have a
> > > > > formal deprecation procedure. But that might be better to be put
> into
> > > > > somewhere else because the bylaws are primarily focusing on the
> > > > > non-technical rules, whereas the deprecation seems more on the
> > > technical
> > > > > side.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jiangjie (Becket) Qin
> > > > >
> > > > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <fh...@gmail.com>
> > > > wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >> First of all thank you very much Becket for starting this
> > discussion!
> > > > >> I think it is a very good idea and overdue to formally define some
> > of
> > > > our
> > > > >> community processes.
> > > > >>
> > > > >> Similar to Chesnay, I have concerns about the distinction between
> > > active
> > > > >> and non-active / emeritus committers and PMC members.
> > > > >> My foremost concern is that this is not in the spirit of the
> Apache
> > > Way
> > > > >> [1]
> > > > >> which is (among other things) based on the idea of merit which
> once
> > > > >> earned,
> > > > >> does not go away over time.
> > > > >> I know other projects like Hadoop and Kafka have similar clauses
> in
> > > the
> > > > >> bylaws but IMO we don't need to adopt them if we don't like them.
> > > > >> For example, I don't like the idea that committers or PMC members
> > who
> > > > are
> > > > >> temporarily away from the project (for whatever reason: parental
> > > leave,
> > > > >> sabbatical, health issues, etc.) need the PMC approval to be
> > "active"
> > > > >> again.
> > > > >> As far as I am aware, we have not seen any issues with inactive
> > > members
> > > > in
> > > > >> the past.
> > > > >> Moreover, it would be hard to track whether somebody became
> inactive
> > > at
> > > > >> some point in time (which we would need to do, if I understand the
> > > > >> proposal
> > > > >> correctly).
> > > > >> With the approach that Becket suggested in his last email
> (reaching
> > > out
> > > > to
> > > > >> binding voters who haven't voted yet), we could drop the
> distinction
> > > > >> between active and non-active committers and PMC members.
> > > > >>
> > > > >> I also have a few minor comments:
> > > > >>
> > > > >> 1) We should add to the requirements of the PMC [2] that they need
> > to
> > > > make
> > > > >> sure the project complies with brand issues and reports misuse of
> > ASF
> > > > >> brands.
> > > > >> 2) Do we want to restrict voting days to working days, i.e., a 3
> day
> > > > vote
> > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > > >> 3) Do we need a process do decide about removal of features (like
> > the
> > > > >> DataSet API for instance or the legacy DataSet/DataStream Python
> > > APIs)?
> > > > >>
> > > > >> Thank you,
> > > > >> Fabian
> > > > >>
> > > > >> [1] https://www.apache.org/theapacheway/
> > > > >> [2] https://www.apache.org/dev/pmc.html
> > > > >>
> > > > >> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> > > > >> becket.qin@gmail.com
> > > > >> >:
> > > > >>
> > > > >> > Hi Hequn,
> > > > >> >
> > > > >> > Thanks for sharing your thoughts. Please see the reply below:
> > > > >> >
> > > > >> > > Perhaps what Jincheng means is to hold at least one PMC in
> the 3
> > > > >> binding
> > > > >> > > votes? i.e, the vote could have 2 binding committers and 1
> PMC.
> > > > >> > > I think this makes sense considering a FLIP could somehow be a
> > big
> > > > >> > feature
> > > > >> > > which may impacts Flink a lot. Meanwhile, there is no loss of
> > > > >> flexibility
> > > > >> > > as committers also have a chance to vote and participate in
> it.
> > > > >> > A few concerns of requiring a PMC vote in all FLIPs are the
> > > following:
> > > > >> >
> > > > >> > 1. Generally speaking, the PMC's primary responsibility is
> > operating
> > > > the
> > > > >> > project and deciding what software to release on behalf of ASF.
> > > > >> Committers,
> > > > >> > on the other hand, are responsible for the technical part of the
> > > > >> project.
> > > > >> > So for FLIPs, a PMC's vote probably should not outweigh a
> > > committer's
> > > > >> vote.
> > > > >> > Besides, I am not sure whether a single PMCs +1 is really
> > convincing
> > > > >> enough
> > > > >> > to decide whether the FLIP is good to go or not. Also, if some
> > > > >> committers
> > > > >> > have concern over a FLIP, they could just veto it. To me it is
> > > > actually
> > > > >> a
> > > > >> > more strict requirement to pass a FLIP than asking a PMC to
> vote.
> > In
> > > > >> > practice, people will usually also address the concerns even if
> > they
> > > > are
> > > > >> > not from a PMC/committer before they start the voting process.
> So
> > I
> > > > >> don't
> > > > >> > see much benefit of requiring a PMC's vote in this case.
> > > > >> >
> > > > >> > 2. The at-least-one-PMC-vote requirement makes the votes no
> longer
> > > > >> > independent. Ideally, a vote is either binding or non-binding by
> > > > >> itself. If
> > > > >> > we have the at-least-one-PMC-vote requirement here, imagine
> there
> > > have
> > > > >> been
> > > > >> > 3 committers who voted +1. But the FLIP still has not passed, so
> > > those
> > > > >> > votes are effectively non-binding. Now a PMC votes a +1, those
> > votes
> > > > >> > suddenly become binding, which is a little awkward.
> > > > >> >
> > > > >> >
> > > > >> > The lazy 2/3 majority suggestion sounds reasonable to me. Some
> > > > thoughts
> > > > >> on
> > > > >> > this:
> > > > >> > 1. One reason Hadoop uses lazy 2/3 majority is probably because
> > > there
> > > > >> are
> > > > >> > 104 PMC members[1] for Hadoop which makes the 2/3 majority
> > > > prohibitively
> > > > >> > expensive. In our case, there are only 22 PMCs for Flink[2] and
> a
> > > > quick
> > > > >> > search shows at most 6 of them have not sent email in the
> recent 6
> > > > >> months
> > > > >> > or so.
> > > > >> >
> > > > >> > 2. 2/3 majority votes are supposed to be very rare. It is
> designed
> > > in
> > > > >> > particular for the cases that broad opinions are important, more
> > > > >> > specifically new codebase adoption or modification to the
> bylaws.
> > > > >> Therefore
> > > > >> > such vote by its nature favors consensus over convenience. That
> > > means
> > > > >> any
> > > > >> > alternative voting type reducing the coverage worth a careful
> > > > thinking.
> > > > >> >
> > > > >> > 3. I do agree that it does not make sense to have 2/3 majority
> if
> > > such
> > > > >> > requirement is no-longer doable over time. But I am a little
> > > hesitant
> > > > to
> > > > >> > lower the threshold to lazy 2/3 majority in our case. What do
> you
> > > > think
> > > > >> > about doing the following:
> > > > >> >     - After the voting started, there will be at least 6 days
> for
> > > > >> people to
> > > > >> > cast their votes.
> > > > >> >     - After 6 days, if the result of the vote is still not
> > > determined,
> > > > >> the
> > > > >> > person who started the vote should reach out to the binding
> voters
> > > who
> > > > >> have
> > > > >> > not voted yet for at least 3 times and at least 7 days between
> > each
> > > > >> time.
> > > > >> > If a binding voter still did not respond, the vote from that
> voter
> > > > will
> > > > >> be
> > > > >> > excluded from the 2/3 majority counting.
> > > > >> > This would ensure the coverage at our best effort while still
> let
> > > the
> > > > >> 2/3
> > > > >> > majority vote make progress.
> > > > >> >
> > > > >> > Thanks,
> > > > >> >
> > > > >> > Jiangjie (Becket) Qin
> > > > >> >
> > > > >> >
> > > > >> > [1] https://projects.apache.org/committee.html?hadoop
> > > > >> > [2] https://projects.apache.org/committee.html?flink
> > > > >> >
> > > > >> > On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> > forwardxu315@gmail.com>
> > > > >> wrote:
> > > > >> >
> > > > >> > > Big +1 on this.
> > > > >> > >
> > > > >> > >
> > > > >> > > best
> > > > >> > >
> > > > >> > > forward
> > > > >> > >
> > > > >> > > Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日 下午1:30写道：
> > > > >> > >
> > > > >> > > > Hi Becket,
> > > > >> > > >
> > > > >> > > > Big +1 on this.
> > > > >> > > >
> > > > >> > > > > Regarding the vote of FLIP, preferably at least includes a
> > PMC
> > > > >> vote.
> > > > >> > > > Perhaps what Jincheng means is to hold at least one PMC in
> > the 3
> > > > >> > binding
> > > > >> > > > votes? i.e, the vote could have 2 binding committers and 1
> > PMC.
> > > > >> > > > I think this makes sense considering a FLIP could somehow
> be a
> > > big
> > > > >> > > feature
> > > > >> > > > which may impacts Flink a lot. Meanwhile, there is no loss
> of
> > > > >> > flexibility
> > > > >> > > > as committers also have a chance to vote and participate in
> > it.
> > > > >> > > >
> > > > >> > > > ========Seperator========
> > > > >> > > >
> > > > >> > > > For the nice bylaws, I agree with the general idea and most
> of
> > > the
> > > > >> > > content.
> > > > >> > > > Only share some thoughts about the "2/3 Majority". The main
> > > > concern
> > > > >> is
> > > > >> > I
> > > > >> > > am
> > > > >> > > > not sure if it is doable in practice. The reasons are:
> > > > >> > > >
> > > > >> > > > 1. If we follow the bylaws strictly, it means a committer
> or a
> > > PMC
> > > > >> > member
> > > > >> > > > is active if he or she sends one email to the mailing list
> > > every 6
> > > > >> > > months.
> > > > >> > > > While the minimum length of the vote is only 6 days. There
> are
> > > > >> chances
> > > > >> > > that
> > > > >> > > > during the vote, some of the active members are still
> offline
> > of
> > > > the
> > > > >> > > > community.
> > > > >> > > > 2. The code of Flink is changing fast and not everyone fully
> > > > >> > understands
> > > > >> > > > every part. We don't need to force people to vote if they
> are
> > > not
> > > > >> sure
> > > > >> > > > about it. It may also make the final result less credible.
> > > > >> > > >
> > > > >> > > > Given the above reasons, perhaps we can change the 2/3
> > Majority
> > > to
> > > > >> lazy
> > > > >> > > 2/3
> > > > >> > > > Majority, just as the Hadoop bylaws[1]. It makes a higher
> > > > threshold,
> > > > >> > > > however, more practical.
> > > > >> > > >
> > > > >> > > > What do you think?
> > > > >> > > >
> > > > >> > > > [1] https://hadoop.apache.org/bylaws.html
> > > > >> > > >
> > > > >> > > > On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> > > becket.qin@gmail.com
> > > > >
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > > > Hi Jincheng,
> > > > >> > > > >
> > > > >> > > > > Thanks for the comments. I replied on the wiki page. Just
> a
> > > > brief
> > > > >> > > > summary,
> > > > >> > > > > the current bylaws do require some of the FLIPs to get PMC
> > > > >> approval
> > > > >> > if
> > > > >> > > > > their impact is big enough. But it leaves majority of the
> > > > >> technical
> > > > >> > > > > decisions to the committers who are supposed to be
> > responsible
> > > > for
> > > > >> > > making
> > > > >> > > > > such decisions.
> > > > >> > > > >
> > > > >> > > > > Re: Robert,
> > > > >> > > > >
> > > > >> > > > > I agree we can simply remove the requirement of +1 from a
> > > > >> non-author
> > > > >> > > > > committer and revisit it in a bit. After all, it does not
> > make
> > > > >> sense
> > > > >> > to
> > > > >> > > > > have a bylaw that we cannot afford. I have just updated
> the
> > > > bylaws
> > > > >> > > wiki.
> > > > >> > > > >
> > > > >> > > > > Thanks,
> > > > >> > > > >
> > > > >> > > > > Jiangjie (Becket) Qin
> > > > >> > > > >
> > > > >> > > > > On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> > > > >> rmetzger@apache.org
> > > > >> > >
> > > > >> > > > > wrote:
> > > > >> > > > >
> > > > >> > > > > > Hi all,
> > > > >> > > > > > I agree with Aljoscha that trying to reflect the current
> > > > status
> > > > >> in
> > > > >> > > the
> > > > >> > > > > > bylaws, and then implementing changes one by one is a
> very
> > > > >> involved
> > > > >> > > > task.
> > > > >> > > > > > Unless there's somebody who's really eager to drive
> this,
> > I
> > > > >> would
> > > > >> > > stick
> > > > >> > > > > to
> > > > >> > > > > > Becket's initiative to come up with Bylaws for Flink,
> even
> > > if
> > > > >> this
> > > > >> > > > means
> > > > >> > > > > > some changes.
> > > > >> > > > > >
> > > > >> > > > > > The cross-review requirement is the last big open point
> in
> > > > this
> > > > >> > > > > discussion.
> > > > >> > > > > > It seems that a there is a slight tendency in the
> > discussion
> > > > >> that
> > > > >> > > this
> > > > >> > > > is
> > > > >> > > > > > not feasible given the current pull request review
> > > situation.
> > > > >> > > > > > For the sake of bringing this discussion to a
> conclusion,
> > > I'm
> > > > >> fine
> > > > >> > > with
> > > > >> > > > > > leaving this requirement out. As we are currently adding
> > > more
> > > > >> > > > committers
> > > > >> > > > > to
> > > > >> > > > > > the project, we might be able to revisit this discussion
> > in
> > > 3
> > > > -
> > > > >> 6
> > > > >> > > > months.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> > > > >> > > sunjincheng121@gmail.com
> > > > >> > > > >
> > > > >> > > > > > wrote:
> > > > >> > > > > >
> > > > >> > > > > > > Hi Becket,
> > > > >> > > > > > >
> > > > >> > > > > > > Thanks for the proposal.
> > > > >> > > > > > >
> > > > >> > > > > > > Regarding the vote of FLIP, preferably at least
> > includes a
> > > > PMC
> > > > >> > > vote.
> > > > >> > > > > > > Because FLIP is usually a big change or affects the
> > user's
> > > > >> > > interface
> > > > >> > > > > > > changes. What do you think? (I leave the comment in
> the
> > > > wiki.)
> > > > >> > > > > > >
> > > > >> > > > > > > Best,
> > > > >> > > > > > > Jincheng
> > > > >> > > > > > >
> > > > >> > > > > > > Dawid Wysakowicz <dw...@apache.org>
> 于2019年7月17日周三
> > > > >> > 下午9:12写道：
> > > > >> > > > > > >
> > > > >> > > > > > > > Hi all,
> > > > >> > > > > > > >
> > > > >> > > > > > > > Sorry for joining late. I just wanted to say that I
> > > really
> > > > >> like
> > > > >> > > the
> > > > >> > > > > > > > proposed bylaws!
> > > > >> > > > > > > >
> > > > >> > > > > > > > One comment, I also have the same concerns as
> > expressed
> > > by
> > > > >> few
> > > > >> > > > people
> > > > >> > > > > > > > before that the "committer +1" on code change might
> be
> > > > hard
> > > > >> to
> > > > >> > > > > achieve
> > > > >> > > > > > > > currently. On the other hand I would say this would
> be
> > > > >> > beneficial
> > > > >> > > > for
> > > > >> > > > > > > > the quality/uniformity of our codebase and knowledge
> > > > >> sharing.
> > > > >> > > > > > > >
> > > > >> > > > > > > > I was just wondering what should be the next step
> for
> > > > this?
> > > > >> I
> > > > >> > > think
> > > > >> > > > > it
> > > > >> > > > > > > > would make sense to already use those bylaws and put
> > > them
> > > > to
> > > > >> > PMC
> > > > >> > > > > vote.
> > > > >> > > > > > > >
> > > > >> > > > > > > > Best,
> > > > >> > > > > > > >
> > > > >> > > > > > > > Dawid
> > > > >> > > > > > > >
> > > > >> > > > > > > > On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > >> > > > > > > > > Hi Aljoscha and Becket
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Right, 3 days for FLIP voting is fine I think.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >>> I’m missing this stated somewhere clearly. If we
> > are
> > > > >> > stating
> > > > >> > > > > that a
> > > > >> > > > > > > > single
> > > > >> > > > > > > > >>> committers +1 is good enough for code review,
> > with 0
> > > > >> hours
> > > > >> > > > delay
> > > > >> > > > > > (de
> > > > >> > > > > > > > facto
> > > > >> > > > > > > > >>> the current state), we should also write down
> that
> > > > this
> > > > >> is
> > > > >> > > > > subject
> > > > >> > > > > > to
> > > > >> > > > > > > > the
> > > > >> > > > > > > > >>> best judgement of the committer to respect the
> > > > >> components
> > > > >> > > > > expertise
> > > > >> > > > > > > and
> > > > >> > > > > > > > >>> ongoing development plans (also the de facto
> > current
> > > > >> > state).
> > > > >> > > > > > > > >> Adding the statement would help clarify the
> > > intention,
> > > > >> but
> > > > >> > it
> > > > >> > > > may
> > > > >> > > > > > be a
> > > > >> > > > > > > > >> little difficult to enforce and follow..
> > > > >> > > > > > > > > I would be fine with that, it’s a soft/vague rule
> > > > anyway,
> > > > >> > > > intended
> > > > >> > > > > to
> > > > >> > > > > > > be
> > > > >> > > > > > > > used with your “best judgemenet". I would like to
> just
> > > > >> avoid a
> > > > >> > > > > > situation
> > > > >> > > > > > > > when someone violates current uncodified state and
> > > refers
> > > > to
> > > > >> > the
> > > > >> > > > > bylaws
> > > > >> > > > > > > > which are saying merging with any committer +1 is
> > always
> > > > >> fine
> > > > >> > > (like
> > > > >> > > > > > mine
> > > > >> > > > > > > +1
> > > > >> > > > > > > > for flink-python or flink-ml).
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Piotrek
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <
> > > > >> > > aljoscha@apache.org
> > > > >> > > > >
> > > > >> > > > > > > wrote:
> > > > >> > > > > > > > >>
> > > > >> > > > > > > > >> @Piotr regarding the 3 days voting on the FLIP.
> > This
> > > is
> > > > >> just
> > > > >> > > > about
> > > > >> > > > > > the
> > > > >> > > > > > > > voting, before that there needs to be the discussion
> > > > >> thread. If
> > > > >> > > > three
> > > > >> > > > > > > days
> > > > >> > > > > > > > have passed on a vote and there is consensus (i.e. 3
> > > > >> > > > committers/PMCs
> > > > >> > > > > > have
> > > > >> > > > > > > > voted +1) that seems a high enough bar for me. So
> far,
> > > we
> > > > >> have
> > > > >> > > > rarely
> > > > >> > > > > > see
> > > > >> > > > > > > > any FLIPs pass that formal bar.
> > > > >> > > > > > > > >>
> > > > >> > > > > > > > >> According to the recent META-FLIP thread, we want
> > to
> > > > use
> > > > >> > "lazy
> > > > >> > > > > > > > majority" for the FLIP voting process. I think that
> > > should
> > > > >> be
> > > > >> > > > changed
> > > > >> > > > > > > from
> > > > >> > > > > > > > “consensus” in the proposed bylaws.
> > > > >> > > > > > > > >>
> > > > >> > > > > > > > >> Regarding the current state: do we have a current
> > > state
> > > > >> that
> > > > >> > > we
> > > > >> > > > > all
> > > > >> > > > > > > > agree on? I have the feeling that if we try to come
> up
> > > > with
> > > > >> > > > something
> > > > >> > > > > > > that
> > > > >> > > > > > > > reflects the common state, according to
> > PMCs/commiters,
> > > > that
> > > > >> > > might
> > > > >> > > > > > take a
> > > > >> > > > > > > > very long time. In that case I think it’s better to
> > > adopt
> > > > >> > > something
> > > > >> > > > > > that
> > > > >> > > > > > > we
> > > > >> > > > > > > > all like, rather than trying to capture how we do it
> > > now.
> > > > >> > > > > > > > >>
> > > > >> > > > > > > > >> Aljoscha
> > > > >> > > > > > > > >>
> > > > >> > > > > > > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <
> > > > >> > > piotr@ververica.com
> > > > >> > > > >
> > > > >> > > > > > > wrote:
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>> Hi,
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>> Thanks for the proposal. Generally speaking +1
> > from
> > > my
> > > > >> side
> > > > >> > > to
> > > > >> > > > > the
> > > > >> > > > > > > > general idea and most of the content. I also see
> merit
> > > to
> > > > >> the
> > > > >> > > > > Chesney's
> > > > >> > > > > > > > proposal to start from the current state. I think
> > either
> > > > >> would
> > > > >> > be
> > > > >> > > > > fine
> > > > >> > > > > > > for
> > > > >> > > > > > > > me.
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>> Couple of comments:
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>> 1.
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>> I also think that requiring +1 from another
> > > committer
> > > > >> would
> > > > >> > > > slow
> > > > >> > > > > > down
> > > > >> > > > > > > > and put even more strain on the current reviewing
> > > > bottleneck
> > > > >> > that
> > > > >> > > > we
> > > > >> > > > > > are
> > > > >> > > > > > > > having. Even if the change clear and simple, context
> > > > switch
> > > > >> > cost
> > > > >> > > is
> > > > >> > > > > > quite
> > > > >> > > > > > > > high, and that’s just one less PR that the second
> > > “cross”
> > > > >> > > committer
> > > > >> > > > > > could
> > > > >> > > > > > > > have reviewed somewhere else in that time. Besides,
> > > > current
> > > > >> > setup
> > > > >> > > > > that
> > > > >> > > > > > we
> > > > >> > > > > > > > have (with no cross +1 from another committer
> > required)
> > > > >> works
> > > > >> > > quite
> > > > >> > > > > > well
> > > > >> > > > > > > > and I do not feel that’s causing troubles. On the
> > other
> > > > hand
> > > > >> > > > > reviewing
> > > > >> > > > > > > > bottleneck is.
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>> 2.
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>>> I think a committer should know when to ask
> > another
> > > > >> > > committer
> > > > >> > > > > for
> > > > >> > > > > > > > feedback or not.
> > > > >> > > > > > > > >>> I’m missing this stated somewhere clearly. If we
> > are
> > > > >> > stating
> > > > >> > > > > that a
> > > > >> > > > > > > > single committers +1 is good enough for code review,
> > > with
> > > > 0
> > > > >> > hours
> > > > >> > > > > delay
> > > > >> > > > > > > (de
> > > > >> > > > > > > > facto the current state), we should also write down
> > that
> > > > >> this
> > > > >> > is
> > > > >> > > > > > subject
> > > > >> > > > > > > to
> > > > >> > > > > > > > the best judgement of the committer to respect the
> > > > >> components
> > > > >> > > > > expertise
> > > > >> > > > > > > and
> > > > >> > > > > > > > ongoing development plans (also the de facto current
> > > > state).
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>> 3.
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>> Minimum length of 3 days for FLIP I think
> > currently
> > > > >> might
> > > > >> > be
> > > > >> > > > > > > > problematic/too quick and can lead to problems if
> > > > respected
> > > > >> to
> > > > >> > > the
> > > > >> > > > > > > letter.
> > > > >> > > > > > > > Again I think it depends highly on whether the
> > > committers
> > > > >> with
> > > > >> > > > > highest
> > > > >> > > > > > > > expertise in the affected components managed to
> > respond
> > > or
> > > > >> not.
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>> Piotrek
> > > > >> > > > > > > > >>>
> > > > >> > > > > > > > >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <
> > > > >> > > > chesnay@apache.org>
> > > > >> > > > > > > > wrote:
> > > > >> > > > > > > > >>>>
> > > > >> > > > > > > > >>>> I'm wondering whether we shouldn't first write
> > down
> > > > >> Bylaws
> > > > >> > > > that
> > > > >> > > > > > > > reflect the current state, and then have separate
> > > > >> discussions
> > > > >> > for
> > > > >> > > > > > > > individual amendments. My gut feeling is that this
> > > > >> discussion
> > > > >> > > will
> > > > >> > > > > > > quickly
> > > > >> > > > > > > > become a chaotic mess with plenty points being
> > discussed
> > > > at
> > > > >> > once.
> > > > >> > > > > > > > >>>>
> > > > >> > > > > > > > >>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > > >> > > > > > > > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <
> > > > >> > > > > > becket.qin@gmail.com>
> > > > >> > > > > > > > wrote:
> > > > >> > > > > > > > >>>>>
> > > > >> > > > > > > > >>>>>> Thanks everyone for all the comments and
> > > feedback.
> > > > >> > Please
> > > > >> > > > see
> > > > >> > > > > > the
> > > > >> > > > > > > > replies
> > > > >> > > > > > > > >>>>>> below:
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> --------------------------------
> > > > >> > > > > > > > >>>>>> Re: Konstantin
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>>> * In addition to a simple "Code Change" we
> > could
> > > > >> also
> > > > >> > > add a
> > > > >> > > > > row
> > > > >> > > > > > > > for "Code
> > > > >> > > > > > > > >>>>>>> Change requiring a FLIP" with a reference to
> > the
> > > > >> FLIP
> > > > >> > > > process
> > > > >> > > > > > > > page. A
> > > > >> > > > > > > > >>>>>> FLIP
> > > > >> > > > > > > > >>>>>>> will have/does have different rules for
> > > approvals,
> > > > >> etc.
> > > > >> > > > > > > > >>>>>> Good point. Just added the entry.
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> -------------------------------
> > > > >> > > > > > > > >>>>>> Re: Konstantin
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>>> * For "Code Change" the draft currently
> > requires
> > > > >> "one
> > > > >> > +1
> > > > >> > > > > from a
> > > > >> > > > > > > > committer
> > > > >> > > > > > > > >>>>>>> who has not authored the patch followed by a
> > > Lazy
> > > > >> > > approval
> > > > >> > > > > (not
> > > > >> > > > > > > > counting
> > > > >> > > > > > > > >>>>>>> the vote of the contributor), moving to lazy
> > > > >> majority
> > > > >> > if
> > > > >> > > a
> > > > >> > > > -1
> > > > >> > > > > > is
> > > > >> > > > > > > > >>>>>> received".
> > > > >> > > > > > > > >>>>>>> In my understanding this means, that a
> > committer
> > > > >> always
> > > > >> > > > > needs a
> > > > >> > > > > > > > review
> > > > >> > > > > > > > >>>>>> and
> > > > >> > > > > > > > >>>>>>> +1 from another committer. As far as I know
> > this
> > > > is
> > > > >> > > > currently
> > > > >> > > > > > not
> > > > >> > > > > > > > always
> > > > >> > > > > > > > >>>>>>> the case (often committer authors,
> contributor
> > > > >> reviews
> > > > >> > &
> > > > >> > > > > +1s).
> > > > >> > > > > > > > >>>>>>>
> > > > >> > > > > > > > >>>>>> I think it is worth thinking about how we can
> > > make
> > > > it
> > > > >> > easy
> > > > >> > > > to
> > > > >> > > > > > > > follow the
> > > > >> > > > > > > > >>>>>>> bylaws e.g. by having more Flink-specific
> Jira
> > > > >> > workflows
> > > > >> > > > and
> > > > >> > > > > > > ticket
> > > > >> > > > > > > > >>>>>> types +
> > > > >> > > > > > > > >>>>>>> corresponding permissions. While this is
> > > certainly
> > > > >> > "Step
> > > > >> > > > 2",
> > > > >> > > > > I
> > > > >> > > > > > > > believe,
> > > > >> > > > > > > > >>>>>> we
> > > > >> > > > > > > > >>>>>>> really need to make it as easy & transparent
> > as
> > > > >> > possible,
> > > > >> > > > > > > > otherwise they
> > > > >> > > > > > > > >>>>>>> will be unintentionally broken.
> > > > >> > > > > > > > >>>>>> & Re: Till
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>>> For the case of a committer being the author
> > and
> > > > >> > getting
> > > > >> > > a
> > > > >> > > > +1
> > > > >> > > > > > > from
> > > > >> > > > > > > > a
> > > > >> > > > > > > > >>>>>>> non-committer: I think a committer should
> know
> > > > when
> > > > >> to
> > > > >> > > ask
> > > > >> > > > > > > another
> > > > >> > > > > > > > >>>>>>> committer for feedback or not. Hence, I
> would
> > > not
> > > > >> > enforce
> > > > >> > > > > that
> > > > >> > > > > > we
> > > > >> > > > > > > > >>>>>> strictly
> > > > >> > > > > > > > >>>>>>> need a +1 from a committer if the author is
> a
> > > > >> committer
> > > > >> > > but
> > > > >> > > > > of
> > > > >> > > > > > > > course
> > > > >> > > > > > > > >>>>>>> encourage it if capacities exist.
> > > > >> > > > > > > > >>>>>> I am with Robert and Aljoscha on this.
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> I completely understand the concern here.
> TBH,
> > in
> > > > >> Kafka
> > > > >> > > > > > > occasionally
> > > > >> > > > > > > > >>>>>> trivial patches from committers are still
> > merged
> > > > >> without
> > > > >> > > > > > following
> > > > >> > > > > > > > the
> > > > >> > > > > > > > >>>>>> cross-review requirement, but it is rare.
> That
> > > > said,
> > > > >> I
> > > > >> > > still
> > > > >> > > > > > think
> > > > >> > > > > > > > an
> > > > >> > > > > > > > >>>>>> additional committer's review makes sense due
> > to
> > > > the
> > > > >> > > > following
> > > > >> > > > > > > > reasons:
> > > > >> > > > > > > > >>>>>> 1. The bottom line here is that we need to
> make
> > > > sure
> > > > >> > every
> > > > >> > > > > patch
> > > > >> > > > > > > is
> > > > >> > > > > > > > >>>>>> reviewed with a high quality. This is a
> little
> > > > >> difficult
> > > > >> > > to
> > > > >> > > > > > > > guarantee if
> > > > >> > > > > > > > >>>>>> the review comes from a contributor for many
> > > > >> reasons. In
> > > > >> > > > some
> > > > >> > > > > > > > cases, a
> > > > >> > > > > > > > >>>>>> contributor may not have enough knowledge
> about
> > > the
> > > > >> > > project
> > > > >> > > > to
> > > > >> > > > > > > make
> > > > >> > > > > > > > a good
> > > > >> > > > > > > > >>>>>> judgement. Also sometimes the contributors
> are
> > > more
> > > > >> > > eagerly
> > > > >> > > > to
> > > > >> > > > > > > get a
> > > > >> > > > > > > > >>>>>> particular issue fixed, so they are willing
> to
> > > > lower
> > > > >> the
> > > > >> > > > > review
> > > > >> > > > > > > bar.
> > > > >> > > > > > > > >>>>>> 2. One byproduct of such cross review among
> > > > >> committers,
> > > > >> > > > which
> > > > >> > > > > I
> > > > >> > > > > > > > personally
> > > > >> > > > > > > > >>>>>> feel useful, is that it helps gradually form
> > > > >> consistent
> > > > >> > > > design
> > > > >> > > > > > > > principles
> > > > >> > > > > > > > >>>>>> and code style. This is because the
> committers
> > > will
> > > > >> know
> > > > >> > > how
> > > > >> > > > > the
> > > > >> > > > > > > > other
> > > > >> > > > > > > > >>>>>> committers are writing code and learn from
> each
> > > > >> other.
> > > > >> > So
> > > > >> > > > they
> > > > >> > > > > > > tend
> > > > >> > > > > > > > to
> > > > >> > > > > > > > >>>>>> reach some tacit understanding on how things
> > > should
> > > > >> be
> > > > >> > > done
> > > > >> > > > in
> > > > >> > > > > > > > general.
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> Another way to think about this is to
> consider
> > > the
> > > > >> > > following
> > > > >> > > > > two
> > > > >> > > > > > > > scenarios:
> > > > >> > > > > > > > >>>>>> 1. Reviewing a committer's patch takes a lot
> of
> > > > >> > > iterations.
> > > > >> > > > > Then
> > > > >> > > > > > > > the patch
> > > > >> > > > > > > > >>>>>> needs to be reviewed even if it takes time
> > > because
> > > > >> there
> > > > >> > > are
> > > > >> > > > > > > things
> > > > >> > > > > > > > >>>>>> actually needs to be clarified / changed.
> > > > >> > > > > > > > >>>>>> 2. Reviewing a committer's patch is very
> smooth
> > > and
> > > > >> > quick,
> > > > >> > > > so
> > > > >> > > > > > the
> > > > >> > > > > > > > patch is
> > > > >> > > > > > > > >>>>>> merged soon. Then reviewing such a patch does
> > not
> > > > >> take
> > > > >> > > much
> > > > >> > > > > > time.
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> Letting another committer review the patch
> > from a
> > > > >> > > committer
> > > > >> > > > > > falls
> > > > >> > > > > > > > either in
> > > > >> > > > > > > > >>>>>> case 1 or case 2. The best option here is to
> > > review
> > > > >> the
> > > > >> > > > patch
> > > > >> > > > > > > > because
> > > > >> > > > > > > > >>>>>> If it is case 1, the patch actually needs to
> be
> > > > >> > reviewed.
> > > > >> > > > > > > > >>>>>> If it is case 2, the review should not take
> > much
> > > > time
> > > > >> > > > anyways.
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> In the contrast, we will risk encounter case
> 1
> > if
> > > > we
> > > > >> > skip
> > > > >> > > > the
> > > > >> > > > > > > > cross-review.
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> ------------------------
> > > > >> > > > > > > > >>>>>> Re: Robert
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> I replied to your comments in the wiki and
> made
> > > the
> > > > >> > > > following
> > > > >> > > > > > > > modifications
> > > > >> > > > > > > > >>>>>> to resolve some of your comments:
> > > > >> > > > > > > > >>>>>> 1. Added a release manager role section.
> > > > >> > > > > > > > >>>>>> 2. changed the name of "lazy consensus" to
> > > > >> "consensus"
> > > > >> > to
> > > > >> > > > > align
> > > > >> > > > > > > with
> > > > >> > > > > > > > >>>>>> general definition of Apache glossary and
> other
> > > > >> > projects.
> > > > >> > > > > > > > >>>>>> 3. review board  -> pull request
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> -------------------------
> > > > >> > > > > > > > >>>>>> Re: Chesnay
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> The emeritus stuff seems like unnecessary
> > noise.
> > > > >> > > > > > > > >>>>>> As Till mentioned, this is to make sure 2/3
> > > > majority
> > > > >> is
> > > > >> > > > still
> > > > >> > > > > > > > feasible in
> > > > >> > > > > > > > >>>>>> practice.
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> There's a bunch of subtle changes in the
> draft
> > > > >> compared
> > > > >> > to
> > > > >> > > > > > > existing
> > > > >> > > > > > > > >>>>>>> "conventions"; we should find a way to
> > highlight
> > > > >> these
> > > > >> > > and
> > > > >> > > > > > > discuss
> > > > >> > > > > > > > them
> > > > >> > > > > > > > >>>>>>> one by one.
> > > > >> > > > > > > > >>>>>> That is a good suggestion. I am not familiar
> > > enough
> > > > >> with
> > > > >> > > the
> > > > >> > > > > > > > current Flink
> > > > >> > > > > > > > >>>>>> convention. Will you help on this? I saw you
> > > > >> commented
> > > > >> > on
> > > > >> > > > some
> > > > >> > > > > > > part
> > > > >> > > > > > > > in the
> > > > >> > > > > > > > >>>>>> wiki. Are those complete?
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> --------------------------
> > > > >> > > > > > > > >>>>>> Re: Aljoscha
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> How different is this from the Kafka bylaws?
> > I’m
> > > > >> asking
> > > > >> > > > > because
> > > > >> > > > > > I
> > > > >> > > > > > > > quite
> > > > >> > > > > > > > >>>>>>> like them and wouldn’t mind essentially
> > adopting
> > > > the
> > > > >> > > Kafka
> > > > >> > > > > > > bylaws.
> > > > >> > > > > > > > I
> > > > >> > > > > > > > >>>>>> mean,
> > > > >> > > > > > > > >>>>>>> it’s open source, and we don’t have to try
> to
> > > > >> re-invent
> > > > >> > > the
> > > > >> > > > > > wheel
> > > > >> > > > > > > > here.
> > > > >> > > > > > > > >>>>>> Ha, you got me on this. The first version of
> > the
> > > > >> draft
> > > > >> > was
> > > > >> > > > > > almost
> > > > >> > > > > > > > identical
> > > > >> > > > > > > > >>>>>> to Kafka. But Robert has already caught a few
> > > > >> > inconsistent
> > > > >> > > > > > places.
> > > > >> > > > > > > > So it
> > > > >> > > > > > > > >>>>>> might still worth going through it to make
> sure
> > > we
> > > > >> truly
> > > > >> > > > agree
> > > > >> > > > > > on
> > > > >> > > > > > > > them.
> > > > >> > > > > > > > >>>>>> Otherwise we may end up modifying them
> shortly
> > > > after
> > > > >> > > > adoption.
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> Thanks again folks, for all the valuable
> > > feedback.
> > > > >> These
> > > > >> > > are
> > > > >> > > > > > great
> > > > >> > > > > > > > >>>>>> discussion.
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> Jiangjie (Becket) Qin
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha
> > Krettek
> > > <
> > > > >> > > > > > > > aljoscha@apache.org>
> > > > >> > > > > > > > >>>>>> wrote:
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > > >>>>>>> Big +1
> > > > >> > > > > > > > >>>>>>>
> > > > >> > > > > > > > >>>>>>> How different is this from the Kafka bylaws?
> > I’m
> > > > >> asking
> > > > >> > > > > > because I
> > > > >> > > > > > > > quite
> > > > >> > > > > > > > >>>>>>> like them and wouldn’t mind essentially
> > adopting
> > > > the
> > > > >> > > Kafka
> > > > >> > > > > > > bylaws.
> > > > >> > > > > > > > I
> > > > >> > > > > > > > >>>>>> mean,
> > > > >> > > > > > > > >>>>>>> it’s open source, and we don’t have to try
> to
> > > > >> re-invent
> > > > >> > > the
> > > > >> > > > > > wheel
> > > > >> > > > > > > > here.
> > > > >> > > > > > > > >>>>>>>
> > > > >> > > > > > > > >>>>>>> I think it’s worthwhile to discuss the
> > > “committer
> > > > >> +1”
> > > > >> > > > > > > requirement.
> > > > >> > > > > > > > We
> > > > >> > > > > > > > >>>>>>> don’t usually have that now but I would
> > actually
> > > > be
> > > > >> in
> > > > >> > > > favour
> > > > >> > > > > > of
> > > > >> > > > > > > > >>>>>> requiring
> > > > >> > > > > > > > >>>>>>> it, although it might make stuff more
> > > complicated.
> > > > >> > > > > > > > >>>>>>>
> > > > >> > > > > > > > >>>>>>> Aljoscha
> > > > >> > > > > > > > >>>>>>>
> > > > >> > > > > > > > >>>>>>>> On 11. Jul 2019, at 15:31, Till Rohrmann <
> > > > >> > > > > > trohrmann@apache.org>
> > > > >> > > > > > > > wrote:
> > > > >> > > > > > > > >>>>>>>>
> > > > >> > > > > > > > >>>>>>>> Thanks a lot for creating this draft
> Becket.
> > > > >> > > > > > > > >>>>>>>>
> > > > >> > > > > > > > >>>>>>>> I think without the notion of emeritus (or
> > > active
> > > > >> vs.
> > > > >> > > > > > inactive),
> > > > >> > > > > > > > it
> > > > >> > > > > > > > >>>>>> won't
> > > > >> > > > > > > > >>>>>>>> be possible to have a 2/3 majority vote
> > because
> > > > we
> > > > >> > > already
> > > > >> > > > > > have
> > > > >> > > > > > > > too
> > > > >> > > > > > > > >>>>>> many
> > > > >> > > > > > > > >>>>>>>> inactive PMCs/committers.
> > > > >> > > > > > > > >>>>>>>>
> > > > >> > > > > > > > >>>>>>>> For the case of a committer being the
> author
> > > and
> > > > >> > > getting a
> > > > >> > > > > +1
> > > > >> > > > > > > > from a
> > > > >> > > > > > > > >>>>>>>> non-committer: I think a committer should
> > know
> > > > >> when to
> > > > >> > > ask
> > > > >> > > > > > > another
> > > > >> > > > > > > > >>>>>>>> committer for feedback or not. Hence, I
> would
> > > not
> > > > >> > > enforce
> > > > >> > > > > that
> > > > >> > > > > > > we
> > > > >> > > > > > > > >>>>>>> strictly
> > > > >> > > > > > > > >>>>>>>> need a +1 from a committer if the author
> is a
> > > > >> > committer
> > > > >> > > > but
> > > > >> > > > > of
> > > > >> > > > > > > > course
> > > > >> > > > > > > > >>>>>>>> encourage it if capacities exist.
> > > > >> > > > > > > > >>>>>>>>
> > > > >> > > > > > > > >>>>>>>> Cheers,
> > > > >> > > > > > > > >>>>>>>> Till
> > > > >> > > > > > > > >>>>>>>>
> > > > >> > > > > > > > >>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM Chesnay
> > > Schepler
> > > > <
> > > > >> > > > > > > > chesnay@apache.org>
> > > > >> > > > > > > > >>>>>>> wrote:
> > > > >> > > > > > > > >>>>>>>>> The emeritus stuff seems like unnecessary
> > > noise.
> > > > >> > > > > > > > >>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>> There's a bunch of subtle changes in the
> > draft
> > > > >> > compared
> > > > >> > > > to
> > > > >> > > > > > > > existing
> > > > >> > > > > > > > >>>>>>>>> "conventions"; we should find a way to
> > > highlight
> > > > >> > these
> > > > >> > > > and
> > > > >> > > > > > > > discuss
> > > > >> > > > > > > > >>>>>> them
> > > > >> > > > > > > > >>>>>>>>> one by one.
> > > > >> > > > > > > > >>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>> On 11/07/2019 14:29, Robert Metzger wrote:
> > > > >> > > > > > > > >>>>>>>>>> Thank you Becket for kicking off this
> > > > discussion
> > > > >> and
> > > > >> > > > > > creating
> > > > >> > > > > > > a
> > > > >> > > > > > > > draft
> > > > >> > > > > > > > >>>>>>> in
> > > > >> > > > > > > > >>>>>>>>>> the Wiki.
> > > > >> > > > > > > > >>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>> I left some comments in the wiki.
> > > > >> > > > > > > > >>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>> In my understanding this means, that a
> > > > committer
> > > > >> > > always
> > > > >> > > > > > needs
> > > > >> > > > > > > a
> > > > >> > > > > > > > >>>>>> review
> > > > >> > > > > > > > >>>>>>>>> and
> > > > >> > > > > > > > >>>>>>>>>>> +1 from another committer. As far as I
> > know
> > > > >> this is
> > > > >> > > > > > currently
> > > > >> > > > > > > > not
> > > > >> > > > > > > > >>>>>>> always
> > > > >> > > > > > > > >>>>>>>>>>> the case (often committer authors,
> > > contributor
> > > > >> > > reviews
> > > > >> > > > &
> > > > >> > > > > > > +1s).
> > > > >> > > > > > > > >>>>>>>>>> I would agree to add such a bylaw, if we
> > had
> > > > >> cases
> > > > >> > in
> > > > >> > > > the
> > > > >> > > > > > past
> > > > >> > > > > > > > where
> > > > >> > > > > > > > >>>>>>> code
> > > > >> > > > > > > > >>>>>>>>>> was not sufficiently reviewed AND we
> > believe
> > > > >> that we
> > > > >> > > > have
> > > > >> > > > > > > enough
> > > > >> > > > > > > > >>>>>>> capacity
> > > > >> > > > > > > > >>>>>>>>>> to ensure a separate committer's
> approval.
> > > > >> > > > > > > > >>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> Konstantin
> > > > Knauf
> > > > >> <
> > > > >> > > > > > > > >>>>>>>>> konstantin@ververica.com>
> > > > >> > > > > > > > >>>>>>>>>> wrote:
> > > > >> > > > > > > > >>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> Hi all,
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> thanks a lot for driving this, Becket. I
> > > have
> > > > >> two
> > > > >> > > > remarks
> > > > >> > > > > > > > regarding
> > > > >> > > > > > > > >>>>>>> the
> > > > >> > > > > > > > >>>>>>>>>>> "Actions" section:
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> * In addition to a simple "Code Change"
> we
> > > > could
> > > > >> > also
> > > > >> > > > > add a
> > > > >> > > > > > > > row for
> > > > >> > > > > > > > >>>>>>>>> "Code
> > > > >> > > > > > > > >>>>>>>>>>> Change requiring a FLIP" with a
> reference
> > to
> > > > the
> > > > >> > FLIP
> > > > >> > > > > > process
> > > > >> > > > > > > > page.
> > > > >> > > > > > > > >>>>>> A
> > > > >> > > > > > > > >>>>>>>>> FLIP
> > > > >> > > > > > > > >>>>>>>>>>> will have/does have different rules for
> > > > >> approvals,
> > > > >> > > etc.
> > > > >> > > > > > > > >>>>>>>>>>> * For "Code Change" the draft currently
> > > > requires
> > > > >> > "one
> > > > >> > > > +1
> > > > >> > > > > > > from a
> > > > >> > > > > > > > >>>>>>>>> committer
> > > > >> > > > > > > > >>>>>>>>>>> who has not authored the patch followed
> > by a
> > > > >> Lazy
> > > > >> > > > > approval
> > > > >> > > > > > > (not
> > > > >> > > > > > > > >>>>>>> counting
> > > > >> > > > > > > > >>>>>>>>>>> the vote of the contributor), moving to
> > lazy
> > > > >> > majority
> > > > >> > > > if
> > > > >> > > > > a
> > > > >> > > > > > -1
> > > > >> > > > > > > > is
> > > > >> > > > > > > > >>>>>>>>> received".
> > > > >> > > > > > > > >>>>>>>>>>> In my understanding this means, that a
> > > > committer
> > > > >> > > always
> > > > >> > > > > > > needs a
> > > > >> > > > > > > > >>>>>> review
> > > > >> > > > > > > > >>>>>>>>> and
> > > > >> > > > > > > > >>>>>>>>>>> +1 from another committer. As far as I
> > know
> > > > >> this is
> > > > >> > > > > > currently
> > > > >> > > > > > > > not
> > > > >> > > > > > > > >>>>>>> always
> > > > >> > > > > > > > >>>>>>>>>>> the case (often committer authors,
> > > contributor
> > > > >> > > reviews
> > > > >> > > > &
> > > > >> > > > > > > +1s).
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> I think it is worth thinking about how
> we
> > > can
> > > > >> make
> > > > >> > it
> > > > >> > > > > easy
> > > > >> > > > > > to
> > > > >> > > > > > > > follow
> > > > >> > > > > > > > >>>>>>> the
> > > > >> > > > > > > > >>>>>>>>>>> bylaws e.g. by having more
> Flink-specific
> > > Jira
> > > > >> > > > workflows
> > > > >> > > > > > and
> > > > >> > > > > > > > ticket
> > > > >> > > > > > > > >>>>>>>>> types +
> > > > >> > > > > > > > >>>>>>>>>>> corresponding permissions. While this is
> > > > >> certainly
> > > > >> > > > "Step
> > > > >> > > > > > 2",
> > > > >> > > > > > > I
> > > > >> > > > > > > > >>>>>>> believe,
> > > > >> > > > > > > > >>>>>>>>> we
> > > > >> > > > > > > > >>>>>>>>>>> really need to make it as easy &
> > transparent
> > > > as
> > > > >> > > > possible,
> > > > >> > > > > > > > otherwise
> > > > >> > > > > > > > >>>>>>> they
> > > > >> > > > > > > > >>>>>>>>>>> will be unintentionally broken.
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> Cheers and thanks,
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> Konstantin
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM Becket
> > Qin <
> > > > >> > > > > > > > becket.qin@gmail.com>
> > > > >> > > > > > > > >>>>>>>>> wrote:
> > > > >> > > > > > > > >>>>>>>>>>>> Hi all,
> > > > >> > > > > > > > >>>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>> As it was raised in the FLIP process
> > > > discussion
> > > > >> > > thread
> > > > >> > > > > > [1],
> > > > >> > > > > > > > >>>>>> currently
> > > > >> > > > > > > > >>>>>>>>>>> Flink
> > > > >> > > > > > > > >>>>>>>>>>>> does not have official bylaws to govern
> > the
> > > > >> > > operation
> > > > >> > > > of
> > > > >> > > > > > the
> > > > >> > > > > > > > >>>>>> project.
> > > > >> > > > > > > > >>>>>>>>>>> Such
> > > > >> > > > > > > > >>>>>>>>>>>> bylaws are critical for the community
> to
> > > > >> > coordinate
> > > > >> > > > and
> > > > >> > > > > > > > contribute
> > > > >> > > > > > > > >>>>>>>>>>>> together. It is also the basis of other
> > > > >> processes
> > > > >> > > such
> > > > >> > > > > as
> > > > >> > > > > > > > FLIP.
> > > > >> > > > > > > > >>>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>> I have drafted a Flink bylaws page and
> > > would
> > > > >> like
> > > > >> > to
> > > > >> > > > > > start a
> > > > >> > > > > > > > >>>>>>> discussion
> > > > >> > > > > > > > >>>>>>>>>>>> thread on this.
> > > > >> > > > > > > > >>>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > > >> > > > > > > > >>>>>>>>>>>> The bylaws will affect everyone in the
> > > > >> community.
> > > > >> > > > It'll
> > > > >> > > > > be
> > > > >> > > > > > > > great to
> > > > >> > > > > > > > >>>>>>>>> hear
> > > > >> > > > > > > > >>>>>>>>>>>> your thoughts.
> > > > >> > > > > > > > >>>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>> Thanks,
> > > > >> > > > > > > > >>>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > >> > > > > > > > >>>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>> [1]
> > > > >> > > > > > > > >>>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> > > > >> > > > > > > > >>>>>>>>>>> --
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> Konstantin Knauf | Solutions Architect
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> +49 160 91394525
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> Planned Absences: 10.08.2019 -
> 31.08.2019,
> > > > >> 05.09. -
> > > > >> > > > > > > 06.09.2010
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> --
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> Ververica GmbH | Invalidenstrasse 115,
> > 10115
> > > > >> > Berlin,
> > > > >> > > > > > Germany
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> --
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > > >>>>>>>>>>> Ververica GmbH
> > > > >> > > > > > > > >>>>>>>>>>> Registered at Amtsgericht
> Charlottenburg:
> > > HRB
> > > > >> > 158244
> > > > >> > > B
> > > > >> > > > > > > > >>>>>>>>>>> Managing Directors: Dr. Kostas Tzoumas,
> > Dr.
> > > > >> Stephan
> > > > >> > > > Ewen
> > > > >> > > > > > > > >>>>>>>>>>>
> > > > >> > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Flink project bylaws

[Chesnay Schepler <ch...@apache.org>]

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 <be...@gmail.com> wrote:
>
>> Thanks for collecting the ideas of Bylaws changes. It is a good idea!
>>
>> Jiangjie (Becket) Qin
>>
>> On Thu, Aug 22, 2019 at 12:11 PM Robert Metzger <rm...@apache.org>
>> wrote:
>>
>>> I have started a Wiki page (editable by all) for collecting ideas for
>>> Bylaws changes, so that we can batch changes together and then vote on
>>> them:
>>>
>> https://cwiki.apache.org/confluence/display/FLINK/Ideas+for+Bylaw+changes
>>> On Tue, Aug 13, 2019 at 1:41 PM Becket Qin <be...@gmail.com> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> Thanks for help apply the changes. I agree we should freeze the change
>> to
>>>> the bylaws page starting from now. For this particular addition of
>>>> clarification, I'll send a notice in the voting thread to let who have
>>>> already voted to know.
>>>>
>>>> Thanks,
>>>>
>>>> Jiangjie (Becket) Qin
>>>>
>>>> On Tue, Aug 13, 2019 at 1:29 PM Robert Metzger <rm...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Becket,
>>>>> I've applied the proposed change to the document:
>>>>>
>>>>>
>> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026&selectedPageVersions=20&selectedPageVersions=19
>>>>> I would propose to stop accepting changes to the document now, as it
>>>> might
>>>>> start a discussion about the validity of the vote and the bylaws
>>> itself.
>>>>> Changes to the document require a 2/3 majority.
>>>>>
>>>>>
>>>>> On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels <mx...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi Becket,
>>>>>>
>>>>>> Thanks for clarifying and updating the draft. The changes look good
>>> to
>>>>> me.
>>>>>> I don't feel strong about a 2/3 majority in case of committer/PMC
>>>>>> removal. Like you pointed out, both provide a significant hurdle
>> due
>>> to
>>>>>> possible vetos or a 2/3 majority.
>>>>>>
>>>>>> Thanks,
>>>>>> Max
>>>>>>
>>>>>> On 13.08.19 10:36, Becket Qin wrote:
>>>>>>> Piotr just reminded me that there was a previous suggestion to
>>>> clarify
>>>>> a
>>>>>>> committer's responsibility when commit his/her own patch. So I'd
>>> like
>>>>> to
>>>>>>> incorporate that in the bylaws. The additional clarification is
>>>>> following
>>>>>>> in bold and italic font.
>>>>>>>
>>>>>>> one +1 from a committer followed by a Lazy approval (not counting
>>> the
>>>>>> vote
>>>>>>>> of the contributor), moving to lazy majority if a -1 is
>> received.
>>>>>>>
>>>>>>> Note that this implies that committers can +1 their own commits
>> and
>>>>> merge
>>>>>>>> right away. *However, the committe**rs should use their best
>>>> judgement
>>>>>> to
>>>>>>>> respect the components expertise and ongoing development plan.*
>>>>>>>
>>>>>>> This does not really change any of the existing bylaws, just
>> about
>>>>>>> clarification.
>>>>>>>
>>>>>>> If there is no objection to this additional clarification, after
>>> the
>>>>>> bylaws
>>>>>>> wiki is updated, I'll send an update notice to the voting thread
>> to
>>>>>> inform
>>>>>>> those who already voted about this addition.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jiangjie (Becket) Qin
>>>>>>>
>>>>>>> On Mon, Aug 12, 2019 at 11:19 AM Becket Qin <
>> becket.qin@gmail.com>
>>>>>> wrote:
>>>>>>>> Hi Maximillian,
>>>>>>>>
>>>>>>>> Thanks for the feedback. Please see the reply below:
>>>>>>>>
>>>>>>>> Step 2 should include a personal email to the PMC members in
>>>> question.
>>>>>>>> I'm afraid reminders inside the vote thread could be overlooked
>>>>> easily.
>>>>>>>>
>>>>>>>> This is exactly what I meant to say by "reach out" :) I just
>> made
>>> it
>>>>>> more
>>>>>>>> explicit.
>>>>>>>>
>>>>>>>> The way the terms are described in the draft, the consensus is
>>>> "lazy",
>>>>>>>>> i.e. requires only 3 binding votes. I'd suggest renaming it to
>>>> "Lazy
>>>>>>>>> Consensus". This is in line with the other definitions such as
>>>> "Lazy
>>>>>>>>> Majority".
>>>>>>>> It was initially called "lazy consensus", but Robert pointed out
>>>> that
>>>>>>>> "lazy consensus" actually means something different in ASF term
>>> [1].
>>>>>>>> Here "lazy" pretty much means "assume everyone is +1 unless
>>> someone
>>>>> says
>>>>>>>> otherwise". This means any vote that requires a minimum number
>> of
>>> +1
>>>>> is
>>>>>> not
>>>>>>>> really a "lazy" vote.
>>>>>>>>
>>>>>>>> Removing a committer / PMC member only requires 3 binding votes.
>>> I'd
>>>>>>>>> expect an important action like this to require a 2/3 majority.
>>>>>>>> Personally I think consensus is good enough here. PMC members
>> can
>>>>> cast a
>>>>>>>> veto if they disagree about the removal. In some sense, it is
>> more
>>>>>>>> difficult than with 2/3 majority to remove a committer / PMC
>>> member.
>>>>>> Also,
>>>>>>>> it might be a hard decision for some PMC members if they have
>>> never
>>>>>> worked
>>>>>>>> with the person in question. That said, I am OK to change it to
>>> 2/3
>>>>>>>> majority as this will happen very rarely.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>
>>>>>>>> [1] https://www.apache.org/foundation/voting.html#LazyConsensus
>>>>>>>>
>>>>>>>> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <
>>> mxm@apache.org>
>>>>>> wrote:
>>>>>>>>> I'm a bit late to the discussion here. Three suggestions:
>>>>>>>>>
>>>>>>>>> 1) Procedure for "insufficient active binding voters to reach
>> 2/3
>>>>>> majority
>>>>>>>>>>      1. Wait until the minimum length of the voting passes.
>>>>>>>>>>      2. Publicly reach out to the remaining binding voters in
>> the
>>>>>> voting
>>>>>>>>> mail thread for at least 2 attempts with at least 7 days
>> between
>>>> two
>>>>>>>>> attempts.
>>>>>>>>>>      3. If the binding voter being contacted still failed to
>>>> respond
>>>>>>>>> after all the attempts, the binding voter will be considered as
>>>>>> inactive
>>>>>>>>> for the purpose of this particular voting.
>>>>>>>>>
>>>>>>>>> Step 2 should include a personal email to the PMC members in
>>>>> question.
>>>>>>>>> I'm afraid reminders inside the vote thread could be overlooked
>>>>> easily.
>>>>>>>>> 2) "Consensus" => "Lazy Consensus"
>>>>>>>>>
>>>>>>>>> The way the terms are described in the draft, the consensus is
>>>>> "lazy",
>>>>>>>>> i.e. requires only 3 binding votes. I'd suggest renaming it to
>>>> "Lazy
>>>>>>>>> Consensus". This is in line with the other definitions such as
>>>> "Lazy
>>>>>>>>> Majority".
>>>>>>>>>
>>>>>>>>> 3) Committer / PMC Removal
>>>>>>>>>
>>>>>>>>> Removing a committer / PMC member only requires 3 binding
>> votes.
>>>> I'd
>>>>>>>>> expect an important action like this to require a 2/3 majority.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Do you think we could incorporate those suggestions?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Max
>>>>>>>>>
>>>>>>>>> On 11.08.19 10:14, Becket Qin wrote:
>>>>>>>>>> Hi folks,
>>>>>>>>>>
>>>>>>>>>> Thanks for all the discussion and support. I have started the
>>>> voting
>>>>>>>>> thread.
>>>>>>>>>>
>> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>
>>>>>>>>>> On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <
>> fhueske@gmail.com
>>>>>> wrote:
>>>>>>>>>>> Thanks for the update and driving the discussion Becket!
>>>>>>>>>>> +1 for starting a vote.
>>>>>>>>>>>
>>>>>>>>>>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
>>>>>>>>> becket.qin@gmail.com
>>>>>>>>>>>> :
>>>>>>>>>>>> Thanks Stephan.
>>>>>>>>>>>>
>>>>>>>>>>>> I think we have resolved all the comments on the wiki page.
>>>> There
>>>>>> are
>>>>>>>>> two
>>>>>>>>>>>> minor changes made to the bylaws since last week.
>>>>>>>>>>>> 1. For 2/3 majority, the required attempts to reach out to
>>>> binding
>>>>>>>>> voters
>>>>>>>>>>>> is reduced from 3 to 2. This helps shorten the voting
>> process
>>> a
>>>>>> little
>>>>>>>>>>> bit.
>>>>>>>>>>>> 2. Clarified what is considered as the adoption of new
>>> codebase.
>>>>>>>>>>>> I think we almost reached consensus. I'll start a voting
>>> thread
>>>> in
>>>>>> two
>>>>>>>>>>> days
>>>>>>>>>>>> if there is no new concerns.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <
>> sewen@apache.org
>>>>>> wrote:
>>>>>>>>>>>>> I added a clarification to the table, clarifying that the
>>>> current
>>>>>>>>>>>> phrasing
>>>>>>>>>>>>> means that committers do not need another +1 for their
>>> commits.
>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <
>>>> fhueske@gmail.com
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Hi Becket,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks a lot for pushing this forward and addressing the
>>>>> feedback.
>>>>>>>>>>>>>> I'm very happy with the current state of the bylaws.
>>>>>>>>>>>>>> +1 to wait until Friday before starting a vote.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best, Fabian
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
>>>>>>>>>>>>>> becket.qin@gmail.com
>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for all the discussion and feedback.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It seems that we have almost reached consensus. I'll
>> leave
>>>> the
>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>> thread open until this Friday. If there is no more
>> concerns
>>>>>> raised,
>>>>>>>>>>>>> I'll
>>>>>>>>>>>>>>> start a voting thread after that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>>>>>> Hi Becket,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for noticing and resolving my comment around PMC
>>>>> removal
>>>>>>>>>>> and
>>>>>>>>>>>>> ASF
>>>>>>>>>>>>>>>> rules of PMC membership change process, which you seem
>> to
>>>>>> neglect
>>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> summary of updates (smile).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>> Yu
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <
>>>>> becket.qin@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Hi folks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for all the feedback.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It seems that there are a few concerns over the
>> emeritus
>>>>> status
>>>>>>>>>>>>>> after 6
>>>>>>>>>>>>>>>>> months of inactivity. Given that the main purpose is
>> just
>>>> to
>>>>>>>>>>> make
>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>> 2/3
>>>>>>>>>>>>>>>>> majority can pass and we sort of have a solution for
>>> that,
>>>> I
>>>>>>>>>>> just
>>>>>>>>>>>>>>> updated
>>>>>>>>>>>>>>>>> the draft with the following changes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1. Removed the inactivity term for emeritus committers
>> /
>>>>> PMCs.
>>>>>>>>>>> A
>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>> / PMC will only be considered emeritus by their own
>>> claim.
>>>>>>>>>>>>>>>>> 2. Removed the approval process for reinstatement of
>> the
>>>>>>>>>>> emeritus
>>>>>>>>>>>>>>>>> committers / PMCs. An emeritus committer / PMC will be
>>>>>>>>>>> reinstated
>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> send an email to the private@flink.apache.org.
>>>>>>>>>>>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still
>>>>> doable
>>>>>>>>>>>> when
>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> are non-emeritus committers / PMCs who do not cast the
>>>> vote.
>>>>>>>>>>>>>>>>> Please let me know if you have any further thoughts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
>>>>>>>>>>>> becket.qin@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Hi Fabian,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks for the feedback.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I agree that if we don't like emeritus committers /
>>> PMCs,
>>>> we
>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> do it. That said, emeritus status simply means whether
>>> an
>>>>>>>>>>>>>> individual
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> active / inactive in the community. It does not make
>> the
>>>>>>>>>>> merits
>>>>>>>>>>>>>>> earned
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> go away. For our purpose, emeritus status is mostly
>>> just a
>>>>>>>>>>> way
>>>>>>>>>>>> to
>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>> 2/3
>>>>>>>>>>>>>>>>>> majority possible. As you noticed, since reaching out
>> to
>>>>>>>>>>>> binding
>>>>>>>>>>>>>>> voters
>>>>>>>>>>>>>>>>> who
>>>>>>>>>>>>>>>>>> have not voted can achieve the same goal, the emeritus
>>>>> status
>>>>>>>>>>>> is
>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>> optimization so we don't have to ping the inactive
>>> binding
>>>>>>>>>>>> voters
>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>>>> time and wait for long. However, given that 2/3
>> majority
>>>>>>>>>>>> votings
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> rare,
>>>>>>>>>>>>>>>>>> such communication cost is probably OK. So I think we
>>> can
>>>>>>>>>>>> remove
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> emeritus part from the bylaws.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1) We should add to the requirements of the PMC that
>>> they
>>>>>>>>>>> need
>>>>>>>>>>>> to
>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> sure the project complies with brand issues and
>> reports
>>>>>>>>>>> misuse
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> ASF
>>>>>>>>>>>>>>>>>>> brands.
>>>>>>>>>>>>>>>>>> Good point. Added.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2) Do we want to restrict voting days to working days,
>>>> i.e.,
>>>>>>>>>>> a
>>>>>>>>>>>> 3
>>>>>>>>>>>>>> day
>>>>>>>>>>>>>>>> vote
>>>>>>>>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday
>>> 11:00am?
>>>>>>>>>>>>>>>>>> This might be a little tricky because people are from
>>>>>>>>>>> countries
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> different time zones and with different holidays, and
>> so
>>>> on.
>>>>>>>>>>> If
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> worrying about 3 days minimum length is not enough for
>>>> those
>>>>>>>>>>>> who
>>>>>>>>>>>>>> want
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> give feedback, we can make it 5 days.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 3) Do we need a process do decide about removal of
>>>> features
>>>>>>>>>>>> (like
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> DataSet API for instance or the legacy
>>> DataSet/DataStream
>>>>>>>>>>>> Python
>>>>>>>>>>>>>>>> APIs)?
>>>>>>>>>>>>>>>>>> I assume such action should be covered by FLIP as it
>> is
>>> a
>>>>>>>>>>>> change
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> API and probably needs a migration plan. It would be
>>>> useful
>>>>>>>>>>> to
>>>>>>>>>>>>>> have a
>>>>>>>>>>>>>>>>>> formal deprecation procedure. But that might be better
>>> to
>>>> be
>>>>>>>>>>>> put
>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>>> somewhere else because the bylaws are primarily
>> focusing
>>>> on
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> non-technical rules, whereas the deprecation seems
>> more
>>> on
>>>>>>>>>>> the
>>>>>>>>>>>>>>>> technical
>>>>>>>>>>>>>>>>>> side.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
>>>>>>>>>>>>> fhueske@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> First of all thank you very much Becket for starting
>>> this
>>>>>>>>>>>>>>> discussion!
>>>>>>>>>>>>>>>>>>> I think it is a very good idea and overdue to
>> formally
>>>>>>>>>>> define
>>>>>>>>>>>>> some
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>>>>> community processes.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Similar to Chesnay, I have concerns about the
>>> distinction
>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>> active
>>>>>>>>>>>>>>>>>>> and non-active / emeritus committers and PMC members.
>>>>>>>>>>>>>>>>>>> My foremost concern is that this is not in the spirit
>>> of
>>>>> the
>>>>>>>>>>>>>> Apache
>>>>>>>>>>>>>>>> Way
>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>> which is (among other things) based on the idea of
>>> merit
>>>>>>>>>>> which
>>>>>>>>>>>>>> once
>>>>>>>>>>>>>>>>>>> earned,
>>>>>>>>>>>>>>>>>>> does not go away over time.
>>>>>>>>>>>>>>>>>>> I know other projects like Hadoop and Kafka have
>>> similar
>>>>>>>>>>>> clauses
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> bylaws but IMO we don't need to adopt them if we
>> don't
>>>> like
>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>> For example, I don't like the idea that committers or
>>> PMC
>>>>>>>>>>>>> members
>>>>>>>>>>>>>>> who
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> temporarily away from the project (for whatever
>> reason:
>>>>>>>>>>>> parental
>>>>>>>>>>>>>>>> leave,
>>>>>>>>>>>>>>>>>>> sabbatical, health issues, etc.) need the PMC
>> approval
>>> to
>>>>> be
>>>>>>>>>>>>>>> "active"
>>>>>>>>>>>>>>>>>>> again.
>>>>>>>>>>>>>>>>>>> As far as I am aware, we have not seen any issues
>> with
>>>>>>>>>>>> inactive
>>>>>>>>>>>>>>>> members
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> the past.
>>>>>>>>>>>>>>>>>>> Moreover, it would be hard to track whether somebody
>>>> became
>>>>>>>>>>>>>> inactive
>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>> some point in time (which we would need to do, if I
>>>>>>>>>>> understand
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> proposal
>>>>>>>>>>>>>>>>>>> correctly).
>>>>>>>>>>>>>>>>>>> With the approach that Becket suggested in his last
>>> email
>>>>>>>>>>>>>> (reaching
>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> binding voters who haven't voted yet), we could drop
>>> the
>>>>>>>>>>>>>> distinction
>>>>>>>>>>>>>>>>>>> between active and non-active committers and PMC
>>> members.
>>>>>>>>>>>>>>>>>>> I also have a few minor comments:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1) We should add to the requirements of the PMC [2]
>>> that
>>>>>>>>>>> they
>>>>>>>>>>>>> need
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> sure the project complies with brand issues and
>> reports
>>>>>>>>>>> misuse
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> ASF
>>>>>>>>>>>>>>>>>>> brands.
>>>>>>>>>>>>>>>>>>> 2) Do we want to restrict voting days to working
>> days,
>>>>> i.e.,
>>>>>>>>>>>> a 3
>>>>>>>>>>>>>> day
>>>>>>>>>>>>>>>>> vote
>>>>>>>>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday
>>> 11:00am?
>>>>>>>>>>>>>>>>>>> 3) Do we need a process do decide about removal of
>>>> features
>>>>>>>>>>>>> (like
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> DataSet API for instance or the legacy
>>> DataSet/DataStream
>>>>>>>>>>>> Python
>>>>>>>>>>>>>>>> APIs)?
>>>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>>>> Fabian
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [1] https://www.apache.org/theapacheway/
>>>>>>>>>>>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket
>> Qin <
>>>>>>>>>>>>>>>>>>> becket.qin@gmail.com
>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>> Hi Hequn,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see the
>> reply
>>>>>>>>>>>> below:
>>>>>>>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
>>> PMC
>>>>>>>>>>> in
>>>>>>>>>>>>>> the 3
>>>>>>>>>>>>>>>>>>> binding
>>>>>>>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding
>> committers
>>>>>>>>>>> and 1
>>>>>>>>>>>>>> PMC.
>>>>>>>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
>>>>>>>>>>> somehow
>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>> big
>>>>>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is
>> no
>>>>>>>>>>> loss
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> flexibility
>>>>>>>>>>>>>>>>>>>>> as committers also have a chance to vote and
>>>> participate
>>>>>>>>>>>> in
>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs
>>> are
>>>>>>>>>>> the
>>>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>>>>>>>> 1. Generally speaking, the PMC's primary
>>> responsibility
>>>> is
>>>>>>>>>>>>>>> operating
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> project and deciding what software to release on
>>> behalf
>>>> of
>>>>>>>>>>>>> ASF.
>>>>>>>>>>>>>>>>>>> Committers,
>>>>>>>>>>>>>>>>>>>> on the other hand, are responsible for the technical
>>>> part
>>>>>>>>>>> of
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> project.
>>>>>>>>>>>>>>>>>>>> So for FLIPs, a PMC's vote probably should not
>>> outweigh
>>>> a
>>>>>>>>>>>>>>>> committer's
>>>>>>>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is
>>>> really
>>>>>>>>>>>>>>> convincing
>>>>>>>>>>>>>>>>>>> enough
>>>>>>>>>>>>>>>>>>>> to decide whether the FLIP is good to go or not.
>> Also,
>>>> if
>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> committers
>>>>>>>>>>>>>>>>>>>> have concern over a FLIP, they could just veto it.
>> To
>>> me
>>>>>>>>>>> it
>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> more strict requirement to pass a FLIP than asking a
>>> PMC
>>>>>>>>>>> to
>>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>> In
>>>>>>>>>>>>>>>>>>>> practice, people will usually also address the
>>> concerns
>>>>>>>>>>> even
>>>>>>>>>>>>> if
>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> not from a PMC/committer before they start the
>> voting
>>>>>>>>>>>> process.
>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>> see much benefit of requiring a PMC's vote in this
>>> case.
>>>>>>>>>>>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the
>>> votes
>>>>>>>>>>> no
>>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>>>>>>> independent. Ideally, a vote is either binding or
>>>>>>>>>>>> non-binding
>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>> itself. If
>>>>>>>>>>>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
>>>>>>>>>>> imagine
>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>> 3 committers who voted +1. But the FLIP still has
>> not
>>>>>>>>>>>> passed,
>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a
>>> +1,
>>>>>>>>>>>> those
>>>>>>>>>>>>>>> votes
>>>>>>>>>>>>>>>>>>>> suddenly become binding, which is a little awkward.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable
>> to
>>>> me.
>>>>>>>>>>>> Some
>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is
>>> probably
>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3
>>>> majority
>>>>>>>>>>>>>>>>> prohibitively
>>>>>>>>>>>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
>>>>>>>>>>> Flink[2]
>>>>>>>>>>>>> and
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> quick
>>>>>>>>>>>>>>>>>>>> search shows at most 6 of them have not sent email
>> in
>>>> the
>>>>>>>>>>>>>> recent 6
>>>>>>>>>>>>>>>>>>> months
>>>>>>>>>>>>>>>>>>>> or so.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare.
>> It
>>>> is
>>>>>>>>>>>>>> designed
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> particular for the cases that broad opinions are
>>>>>>>>>>> important,
>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>> specifically new codebase adoption or modification
>> to
>>>> the
>>>>>>>>>>>>>> bylaws.
>>>>>>>>>>>>>>>>>>> Therefore
>>>>>>>>>>>>>>>>>>>> such vote by its nature favors consensus over
>>>> convenience.
>>>>>>>>>>>>> That
>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>>>> alternative voting type reducing the coverage worth
>> a
>>>>>>>>>>>> careful
>>>>>>>>>>>>>>>>> thinking.
>>>>>>>>>>>>>>>>>>>> 3. I do agree that it does not make sense to have
>> 2/3
>>>>>>>>>>>> majority
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>> such
>>>>>>>>>>>>>>>>>>>> requirement is no-longer doable over time. But I am
>> a
>>>>>>>>>>> little
>>>>>>>>>>>>>>>> hesitant
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> lower the threshold to lazy 2/3 majority in our
>> case.
>>>> What
>>>>>>>>>>>> do
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>> about doing the following:
>>>>>>>>>>>>>>>>>>>>      - After the voting started, there will be at
>>> least 6
>>>>>>>>>>>> days
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> people to
>>>>>>>>>>>>>>>>>>>> cast their votes.
>>>>>>>>>>>>>>>>>>>>      - After 6 days, if the result of the vote is
>> still
>>>> not
>>>>>>>>>>>>>>>> determined,
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> person who started the vote should reach out to the
>>>>>>>>>>> binding
>>>>>>>>>>>>>> voters
>>>>>>>>>>>>>>>> who
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>> not voted yet for at least 3 times and at least 7
>> days
>>>>>>>>>>>> between
>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>> time.
>>>>>>>>>>>>>>>>>>>> If a binding voter still did not respond, the vote
>>> from
>>>>>>>>>>> that
>>>>>>>>>>>>>> voter
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> excluded from the 2/3 majority counting.
>>>>>>>>>>>>>>>>>>>> This would ensure the coverage at our best effort
>>> while
>>>>>>>>>>>> still
>>>>>>>>>>>>>> let
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> 2/3
>>>>>>>>>>>>>>>>>>>> majority vote make progress.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [1]
>> https://projects.apache.org/committee.html?hadoop
>>>>>>>>>>>>>>>>>>>> [2]
>> https://projects.apache.org/committee.html?flink
>>>>>>>>>>>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
>>>>>>>>>>>>>>> forwardxu315@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> Big +1 on this.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
>>>>>>>>>>>> 下午1:30写道：
>>>>>>>>>>>>>>>>>>>>>> Hi Becket,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Big +1 on this.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
>>>>>>>>>>>>> includes a
>>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least
>> one
>>>>>>>>>>> PMC
>>>>>>>>>>>> in
>>>>>>>>>>>>>>> the 3
>>>>>>>>>>>>>>>>>>>> binding
>>>>>>>>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding
>> committers
>>>>>>>>>>>> and 1
>>>>>>>>>>>>>>> PMC.
>>>>>>>>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
>>>>>>>>>>>> somehow
>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>> big
>>>>>>>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is
>>> no
>>>>>>>>>>>> loss
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> flexibility
>>>>>>>>>>>>>>>>>>>>>> as committers also have a chance to vote and
>>>>>>>>>>> participate
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>>>>>>> ========Seperator========
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> For the nice bylaws, I agree with the general idea
>>> and
>>>>>>>>>>>>> most
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> content.
>>>>>>>>>>>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority".
>>> The
>>>>>>>>>>>>> main
>>>>>>>>>>>>>>>>> concern
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>> am
>>>>>>>>>>>>>>>>>>>>>> not sure if it is doable in practice. The reasons
>>> are:
>>>>>>>>>>>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
>>>>>>>>>>>> committer
>>>>>>>>>>>>>> or a
>>>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>>>>>>> member
>>>>>>>>>>>>>>>>>>>>>> is active if he or she sends one email to the
>>> mailing
>>>>>>>>>>>> list
>>>>>>>>>>>>>>>> every 6
>>>>>>>>>>>>>>>>>>>>> months.
>>>>>>>>>>>>>>>>>>>>>> While the minimum length of the vote is only 6
>> days.
>>>>>>>>>>>> There
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> chances
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> during the vote, some of the active members are
>>> still
>>>>>>>>>>>>>> offline
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> community.
>>>>>>>>>>>>>>>>>>>>>> 2. The code of Flink is changing fast and not
>>> everyone
>>>>>>>>>>>>> fully
>>>>>>>>>>>>>>>>>>>> understands
>>>>>>>>>>>>>>>>>>>>>> every part. We don't need to force people to vote
>> if
>>>>>>>>>>>> they
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>>> about it. It may also make the final result less
>>>>>>>>>>>> credible.
>>>>>>>>>>>>>>>>>>>>>> Given the above reasons, perhaps we can change the
>>> 2/3
>>>>>>>>>>>>>>> Majority
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>>>> 2/3
>>>>>>>>>>>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
>>>>>>>>>>>> higher
>>>>>>>>>>>>>>>>> threshold,
>>>>>>>>>>>>>>>>>>>>>> however, more practical.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
>>>>>>>>>>>>>>>> becket.qin@gmail.com
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi Jincheng,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki
>>> page.
>>>>>>>>>>>>> Just
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> brief
>>>>>>>>>>>>>>>>>>>>>> summary,
>>>>>>>>>>>>>>>>>>>>>>> the current bylaws do require some of the FLIPs
>> to
>>>>>>>>>>> get
>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>>>>>> approval
>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>> their impact is big enough. But it leaves
>> majority
>>>>>>>>>>> of
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> technical
>>>>>>>>>>>>>>>>>>>>>>> decisions to the committers who are supposed to
>> be
>>>>>>>>>>>>>>> responsible
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> making
>>>>>>>>>>>>>>>>>>>>>>> such decisions.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Re: Robert,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I agree we can simply remove the requirement of
>> +1
>>>>>>>>>>>> from
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> non-author
>>>>>>>>>>>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
>>>>>>>>>>> does
>>>>>>>>>>>>> not
>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> sense
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
>>>>>>>>>>>> updated
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> bylaws
>>>>>>>>>>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
>>>>>>>>>>>>>>>>>>> rmetzger@apache.org
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>> status
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
>>>>>>>>>>> is
>>>>>>>>>>>> a
>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>> involved
>>>>>>>>>>>>>>>>>>>>>> task.
>>>>>>>>>>>>>>>>>>>>>>>> Unless there's somebody who's really eager to
>>>>>>>>>>> drive
>>>>>>>>>>>>>> this,
>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>> stick
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
>>>>>>>>>>>> Flink,
>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>>>>>>>>> some changes.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The cross-review requirement is the last big
>> open
>>>>>>>>>>>>> point
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>> discussion.
>>>>>>>>>>>>>>>>>>>>>>>> It seems that a there is a slight tendency in
>> the
>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>> not feasible given the current pull request
>> review
>>>>>>>>>>>>>>>> situation.
>>>>>>>>>>>>>>>>>>>>>>>> For the sake of bringing this discussion to a
>>>>>>>>>>>>>> conclusion,
>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>> fine
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>> leaving this requirement out. As we are
>> currently
>>>>>>>>>>>>> adding
>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>>> committers
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> the project, we might be able to revisit this
>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> 3
>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>>>>>> months.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
>>>>>>>>>>>>>>>>>>>>> sunjincheng121@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Becket,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
>>>>>>>>>>>>>>> includes a
>>>>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> user's
>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>>>>> changes. What do you think? (I leave the
>> comment
>>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> wiki.)
>>>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>>>> Jincheng
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
>>>>>>>>>>>>>> 于2019年7月17日周三
>>>>>>>>>>>>>>>>>>>> 下午9:12写道：
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
>>>>>>>>>>>> that
>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> proposed bylaws!
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
>>>>>>>>>>>>>>> expressed
>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>>>>>>>> people
>>>>>>>>>>>>>>>>>>>>>>>>>> before that the "committer +1" on code change
>>>>>>>>>>>>> might
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> hard
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> achieve
>>>>>>>>>>>>>>>>>>>>>>>>>> currently. On the other hand I would say this
>>>>>>>>>>>>> would
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> beneficial
>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
>>>>>>>>>>>>> knowledge
>>>>>>>>>>>>>>>>>>> sharing.
>>>>>>>>>>>>>>>>>>>>>>>>>> I was just wondering what should be the next
>>>>>>>>>>>> step
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>>> would make sense to already use those bylaws
>>>>>>>>>>> and
>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Dawid
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
>>>>>>>>>>> think.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
>>>>>>>>>>>> If
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> stating
>>>>>>>>>>>>>>>>>>>>>>> that a
>>>>>>>>>>>>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
>>>>>>>>>>>> review,
>>>>>>>>>>>>>>> with 0
>>>>>>>>>>>>>>>>>>> hours
>>>>>>>>>>>>>>>>>>>>>> delay
>>>>>>>>>>>>>>>>>>>>>>>> (de
>>>>>>>>>>>>>>>>>>>>>>>>>> facto
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the current state), we should also write
>>>>>>>>>>>> down
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>> subject
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>> expertise
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
>>>>>>>>>>> facto
>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>> state).
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
>>>>>>>>>>>>>>>> intention,
>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
>>>>>>>>>>>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
>>>>>>>>>>>>> rule
>>>>>>>>>>>>>>>>> anyway,
>>>>>>>>>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
>>>>>>>>>>>> to
>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>> avoid a
>>>>>>>>>>>>>>>>>>>>>>>> situation
>>>>>>>>>>>>>>>>>>>>>>>>>> when someone violates current uncodified state
>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> refers
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> bylaws
>>>>>>>>>>>>>>>>>>>>>>>>>> which are saying merging with any committer +1
>>>>>>>>>>>> is
>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>> fine
>>>>>>>>>>>>>>>>>>>>> (like
>>>>>>>>>>>>>>>>>>>>>>>> mine
>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>>>>> for flink-python or flink-ml).
>>>>>>>>>>>>>>>>>>>>>>>>>>> Piotrek
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>> aljoscha@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
>>>>>>>>>>>> FLIP.
>>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> voting, before that there needs to be the
>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>> thread. If
>>>>>>>>>>>>>>>>>>>>>> three
>>>>>>>>>>>>>>>>>>>>>>>>> days
>>>>>>>>>>>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
>>>>>>>>>>>>> (i.e. 3
>>>>>>>>>>>>>>>>>>>>>> committers/PMCs
>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
>>>>>>>>>>>> So
>>>>>>>>>>>>>> far,
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>> rarely
>>>>>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
>>>>>>>>>>> we
>>>>>>>>>>>>> want
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>> "lazy
>>>>>>>>>>>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>> changed
>>>>>>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
>>>>>>>>>>>>> come
>>>>>>>>>>>>>> up
>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>> reflects the common state, according to
>>>>>>>>>>>>>>> PMCs/commiters,
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> might
>>>>>>>>>>>>>>>>>>>>>>>> take a
>>>>>>>>>>>>>>>>>>>>>>>>>> very long time. In that case I think it’s
>>>>>>>>>>> better
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> adopt
>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
>>>>>>>>>>>> do
>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>> piotr@ververica.com
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
>>>>>>>>>>> speaking
>>>>>>>>>>>> +1
>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>> side
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> general idea and most of the content. I also
>>>>>>>>>>> see
>>>>>>>>>>>>>> merit
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> Chesney's
>>>>>>>>>>>>>>>>>>>>>>>>>> proposal to start from the current state. I
>>>>>>>>>>>> think
>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>> fine
>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>> me.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Couple of comments:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
>>>>>>>>>>> another
>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>> slow
>>>>>>>>>>>>>>>>>>>>>>>> down
>>>>>>>>>>>>>>>>>>>>>>>>>> and put even more strain on the current
>>>>>>>>>>>> reviewing
>>>>>>>>>>>>>>>>> bottleneck
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
>>>>>>>>>>>>> context
>>>>>>>>>>>>>>>>> switch
>>>>>>>>>>>>>>>>>>>> cost
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
>>>>>>>>>>>> second
>>>>>>>>>>>>>>>> “cross”
>>>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
>>>>>>>>>>>>> Besides,
>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>> setup
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
>>>>>>>>>>>>>>> required)
>>>>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>>>>> well
>>>>>>>>>>>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>> hand
>>>>>>>>>>>>>>>>>>>>>>> reviewing
>>>>>>>>>>>>>>>>>>>>>>>>>> bottleneck is.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
>>>>>>>>>>> ask
>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>> feedback or not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
>>>>>>>>>>>> If
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> stating
>>>>>>>>>>>>>>>>>>>>>>> that a
>>>>>>>>>>>>>>>>>>>>>>>>>> single committers +1 is good enough for code
>>>>>>>>>>>>> review,
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> 0
>>>>>>>>>>>>>>>>>>>> hours
>>>>>>>>>>>>>>>>>>>>>>> delay
>>>>>>>>>>>>>>>>>>>>>>>>> (de
>>>>>>>>>>>>>>>>>>>>>>>>>> facto the current state), we should also write
>>>>>>>>>>>>> down
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>> subject
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> the best judgement of the committer to respect
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>> expertise
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>> state).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>> might
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>> respected
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> letter.
>>>>>>>>>>>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
>>>>>>>>>>>>>>>> committers
>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>> highest
>>>>>>>>>>>>>>>>>>>>>>>>>> expertise in the affected components managed
>>>>>>>>>>> to
>>>>>>>>>>>>>>> respond
>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Piotrek
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
>>>>>>>>>>> Schepler
>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>> chesnay@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
>>>>>>>>>>>>> write
>>>>>>>>>>>>>>> down
>>>>>>>>>>>>>>>>>>> Bylaws
>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>> reflect the current state, and then have
>>>>>>>>>>>> separate
>>>>>>>>>>>>>>>>>>> discussions
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>>> quickly
>>>>>>>>>>>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
>>>>>>>>>>>>>>> discussed
>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>> once.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
>>>>>>>>>>>> Qin
>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
>>>>>>>>>>> and
>>>>>>>>>>>>>>>> feedback.
>>>>>>>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> replies
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> below:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
>>>>>>>>>>> Change"
>>>>>>>>>>>> we
>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>>>>>>>>>>> row
>>>>>>>>>>>>>>>>>>>>>>>>>> for "Code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
>>>>>>>>>>>> reference
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>>>>>>> page. A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
>>>>>>>>>>> for
>>>>>>>>>>>>>>>> approvals,
>>>>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
>>>>>>>>>>> currently
>>>>>>>>>>>>>>> requires
>>>>>>>>>>>>>>>>>>> "one
>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
>>>>>>>>>>> followed
>>>>>>>>>>>>> by a
>>>>>>>>>>>>>>>> Lazy
>>>>>>>>>>>>>>>>>>>>> approval
>>>>>>>>>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>>>>>>>>>>>> counting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
>>>>>>>>>>> to
>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>> majority
>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>> -1
>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> received".
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>> needs a
>>>>>>>>>>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
>>>>>>>>>>>>> know
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>>>>>>>>>>>>>> contributor
>>>>>>>>>>>>>>>>>>> reviews
>>>>>>>>>>>>>>>>>>>> &
>>>>>>>>>>>>>>>>>>>>>>> +1s).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
>>>>>>>>>>> we
>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> follow the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
>>>>>>>>>>>> Flink-specific
>>>>>>>>>>>>>> Jira
>>>>>>>>>>>>>>>>>>>> workflows
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> types +
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
>>>>>>>>>>> is
>>>>>>>>>>>>>>>> certainly
>>>>>>>>>>>>>>>>>>>> "Step
>>>>>>>>>>>>>>>>>>>>>> 2",
>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>> believe,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
>>>>>>>>>>>>> transparent
>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>> possible,
>>>>>>>>>>>>>>>>>>>>>>>>>> otherwise they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> & Re: Till
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
>>>>>>>>>>>>> author
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
>>>>>>>>>>>> should
>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> ask
>>>>>>>>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
>>>>>>>>>>> I
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>> enforce
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
>>>>>>>>>>> author
>>>>>>>>>>>>> is
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>> course
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
>>>>>>>>>>> here.
>>>>>>>>>>>>>> TBH,
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>>>>>>>>>>> occasionally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
>>>>>>>>>>> still
>>>>>>>>>>>>>>> merged
>>>>>>>>>>>>>>>>>>> without
>>>>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
>>>>>>>>>>> rare.
>>>>>>>>>>>>>> That
>>>>>>>>>>>>>>>>> said,
>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
>>>>>>>>>>> sense
>>>>>>>>>>>>> due
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>>>>>>> reasons:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
>>>>>>>>>>>> to
>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
>>>>>>>>>>>>>> little
>>>>>>>>>>>>>>>>>>> difficult
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> guarantee if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
>>>>>>>>>>>>> many
>>>>>>>>>>>>>>>>>>> reasons. In
>>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>>>>> cases, a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
>>>>>>>>>>> knowledge
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> project
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>>>>>> a good
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
>>>>>>>>>>>> contributors
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>> eagerly
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> get a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
>>>>>>>>>>>> willing
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> lower
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>>>> bar.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
>>>>>>>>>>>> among
>>>>>>>>>>>>>>>>>>> committers,
>>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>> personally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
>>>>>>>>>>>>> form
>>>>>>>>>>>>>>>>>>> consistent
>>>>>>>>>>>>>>>>>>>>>> design
>>>>>>>>>>>>>>>>>>>>>>>>>> principles
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
>>>>>>>>>>>>>> committers
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
>>>>>>>>>>>> from
>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>>>>>> other.
>>>>>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>>>>> tend
>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
>>>>>>>>>>>>> things
>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>> general.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
>>>>>>>>>>>>>> consider
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>>>>>>>>>>>> scenarios:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
>>>>>>>>>>> a
>>>>>>>>>>>>> lot
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> iterations.
>>>>>>>>>>>>>>>>>>>>>>> Then
>>>>>>>>>>>>>>>>>>>>>>>>>> the patch
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
>>>>>>>>>>>> time
>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>>>> things
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
>>>>>>>>>>> changed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
>>>>>>>>>>> very
>>>>>>>>>>>>>> smooth
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> quick,
>>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> patch is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
>>>>>>>>>>> patch
>>>>>>>>>>>>> does
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> take
>>>>>>>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>>>>>>>> time.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
>>>>>>>>>>>> patch
>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>>>> falls
>>>>>>>>>>>>>>>>>>>>>>>>>> either in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
>>>>>>>>>>> is
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
>>>>>>>>>>> needs
>>>>>>>>>>>>> to
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> reviewed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
>>>>>>>>>>>> take
>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>>>>>>>> anyways.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
>>>>>>>>>>>>> case
>>>>>>>>>>>>>> 1
>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>> skip
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> cross-review.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Robert
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
>>>>>>>>>>>> and
>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>>>>>>> modifications
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
>>>>>>>>>>> section.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> "consensus"
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> align
>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
>>>>>>>>>>> and
>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>> projects.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>> noise.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
>>>>>>>>>>>> 2/3
>>>>>>>>>>>>>>>>> majority
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>>>>>>>> feasible in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> practice.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
>>>>>>>>>>> the
>>>>>>>>>>>>>> draft
>>>>>>>>>>>>>>>>>>> compared
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
>>>>>>>>>>>>>>> highlight
>>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
>>>>>>>>>>>>> familiar
>>>>>>>>>>>>>>>> enough
>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> current Flink
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
>>>>>>>>>>> saw
>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>> commented
>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
>>>>>>>>>>>>> bylaws?
>>>>>>>>>>>>>>> I’m
>>>>>>>>>>>>>>>>>>> asking
>>>>>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
>>>>>>>>>>> essentially
>>>>>>>>>>>>>>> adopting
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>>>>>>>>>>> bylaws.
>>>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
>>>>>>>>>>>> try
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> re-invent
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> wheel
>>>>>>>>>>>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
>>>>>>>>>>> version
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> draft
>>>>>>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>>>>>>>> almost
>>>>>>>>>>>>>>>>>>>>>>>>>> identical
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
>>>>>>>>>>> caught a
>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>>>>>> inconsistent
>>>>>>>>>>>>>>>>>>>>>>>> places.
>>>>>>>>>>>>>>>>>>>>>>>>>> So it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
>>>>>>>>>>>> make
>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>> truly
>>>>>>>>>>>>>>>>>>>>>> agree
>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
>>>>>>>>>>>>>> shortly
>>>>>>>>>>>>>>>>> after
>>>>>>>>>>>>>>>>>>>>>> adoption.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
>>>>>>>>>>> valuable
>>>>>>>>>>>>>>>> feedback.
>>>>>>>>>>>>>>>>>>> These
>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>>> great
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> discussion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>>>> Krettek
>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>> aljoscha@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Big +1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
>>>>>>>>>>>>> bylaws?
>>>>>>>>>>>>>>> I’m
>>>>>>>>>>>>>>>>>>> asking
>>>>>>>>>>>>>>>>>>>>>>>> because I
>>>>>>>>>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
>>>>>>>>>>> essentially
>>>>>>>>>>>>>>> adopting
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>>>>>>>>>>> bylaws.
>>>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mean,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
>>>>>>>>>>>> try
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> re-invent
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> wheel
>>>>>>>>>>>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
>>>>>>>>>>>>>>>> “committer
>>>>>>>>>>>>>>>>>>> +1”
>>>>>>>>>>>>>>>>>>>>>>>>> requirement.
>>>>>>>>>>>>>>>>>>>>>>>>>> We
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
>>>>>>>>>>> would
>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>> favour
>>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requiring
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
>>>>>>>>>>>>>>>> complicated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
>>>>>>>>>>>> Rohrmann
>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>> trohrmann@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
>>>>>>>>>>>>>> Becket.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
>>>>>>>>>>> emeritus
>>>>>>>>>>>>> (or
>>>>>>>>>>>>>>>> active
>>>>>>>>>>>>>>>>>>> vs.
>>>>>>>>>>>>>>>>>>>>>>>> inactive),
>>>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> won't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
>>>>>>>>>>> vote
>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> many
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
>>>>>>>>>>>>>> author
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> getting a
>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
>>>>>>>>>>>> should
>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>> when to
>>>>>>>>>>>>>>>>>>>>> ask
>>>>>>>>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
>>>>>>>>>>> Hence, I
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>> enforce
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
>>>>>>>>>>>> author
>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>> course
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Till
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
>>>>>>>>>>> Chesnay
>>>>>>>>>>>>>>>> Schepler
>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>> chesnay@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>>> noise.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> draft
>>>>>>>>>>>>>>>>>>>> compared
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
>>>>>>>>>>> to
>>>>>>>>>>>>>>>> highlight
>>>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>> draft
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
>>>>>>>>>>> that
>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
>>>>>>>>>>>> as I
>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>>>>>>>>>>>>>>>> contributor
>>>>>>>>>>>>>>>>>>>>> reviews
>>>>>>>>>>>>>>>>>>>>>> &
>>>>>>>>>>>>>>>>>>>>>>>>> +1s).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
>>>>>>>>>>> if
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> had
>>>>>>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> past
>>>>>>>>>>>>>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
>>>>>>>>>>> we
>>>>>>>>>>>>>>> believe
>>>>>>>>>>>>>>>>>>> that we
>>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>> enough
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> capacity
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
>>>>>>>>>>>>>> approval.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>> Knauf
>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
>>>>>>>>>>>>> Becket. I
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>>>>>>>> remarks
>>>>>>>>>>>>>>>>>>>>>>>>>> regarding
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
>>>>>>>>>>>>> Change"
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>>>>>>>>>>>>>> row for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>>>>>>> page.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
>>>>>>>>>>> rules
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> approvals,
>>>>>>>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>> requires
>>>>>>>>>>>>>>>>>>>> "one
>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
>>>>>>>>>>>>> followed
>>>>>>>>>>>>>>> by a
>>>>>>>>>>>>>>>>>>> Lazy
>>>>>>>>>>>>>>>>>>>>>>> approval
>>>>>>>>>>>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> counting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
>>>>>>>>>>> moving
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>>>>>>> majority
>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>> -1
>>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> received".
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
>>>>>>>>>>>> that a
>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>> needs a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
>>>>>>>>>>>> as I
>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>>>>>>>>>>>>>>>> contributor
>>>>>>>>>>>>>>>>>>>>> reviews
>>>>>>>>>>>>>>>>>>>>>> &
>>>>>>>>>>>>>>>>>>>>>>>>> +1s).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
>>>>>>>>>>>> how
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
>>>>>>>>>>>>>> Flink-specific
>>>>>>>>>>>>>>>> Jira
>>>>>>>>>>>>>>>>>>>>>> workflows
>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> types +
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
>>>>>>>>>>>> this
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> certainly
>>>>>>>>>>>>>>>>>>>>>> "Step
>>>>>>>>>>>>>>>>>>>>>>>> 2",
>>>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> believe,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
>>>>>>>>>>>>>>> transparent
>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>>> possible,
>>>>>>>>>>>>>>>>>>>>>>>>>> otherwise
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
>>>>>>>>>>>> Becket
>>>>>>>>>>>>>>> Qin <
>>>>>>>>>>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>>>>>>>>>>> [1],
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
>>>>>>>>>>>>> govern
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> operation
>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> project.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
>>>>>>>>>>>> community
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> coordinate
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> contribute
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>> processes
>>>>>>>>>>>>>>>>>>>>> such
>>>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
>>>>>>>>>>> page
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> start a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
>>>>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> community.
>>>>>>>>>>>>>>>>>>>>>> It'll
>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>> great to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hear
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
>>>>>>>>>>>> Architect
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
>>>>>>>>>>>>>> 31.08.2019,
>>>>>>>>>>>>>>>>>>> 05.09. -
>>>>>>>>>>>>>>>>>>>>>>>>> 06.09.2010
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
>>>>>>>>>>>> 115,
>>>>>>>>>>>>>>> 10115
>>>>>>>>>>>>>>>>>>>> Berlin,
>>>>>>>>>>>>>>>>>>>>>>>> Germany
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
>>>>>>>>>>>>>> Charlottenburg:
>>>>>>>>>>>>>>>> HRB
>>>>>>>>>>>>>>>>>>>> 158244
>>>>>>>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
>>>>>>>>>>>>> Tzoumas,
>>>>>>>>>>>>>>> Dr.
>>>>>>>>>>>>>>>>>>> Stephan
>>>>>>>>>>>>>>>>>>>>>> Ewen
>>>>>>>>>>>>>>>>>>>>>>>>>>

Re: [DISCUSS] Flink project bylaws

[Robert Metzger <rm...@apache.org>]

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 <be...@gmail.com> wrote:

> Thanks for collecting the ideas of Bylaws changes. It is a good idea!
>
> Jiangjie (Becket) Qin
>
> On Thu, Aug 22, 2019 at 12:11 PM Robert Metzger <rm...@apache.org>
> wrote:
>
> > I have started a Wiki page (editable by all) for collecting ideas for
> > Bylaws changes, so that we can batch changes together and then vote on
> > them:
> >
> https://cwiki.apache.org/confluence/display/FLINK/Ideas+for+Bylaw+changes
> >
> > On Tue, Aug 13, 2019 at 1:41 PM Becket Qin <be...@gmail.com> wrote:
> >
> > > Hi Robert,
> > >
> > > Thanks for help apply the changes. I agree we should freeze the change
> to
> > > the bylaws page starting from now. For this particular addition of
> > > clarification, I'll send a notice in the voting thread to let who have
> > > already voted to know.
> > >
> > > Thanks,
> > >
> > > Jiangjie (Becket) Qin
> > >
> > > On Tue, Aug 13, 2019 at 1:29 PM Robert Metzger <rm...@apache.org>
> > > wrote:
> > >
> > > > Hi Becket,
> > > > I've applied the proposed change to the document:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026&selectedPageVersions=20&selectedPageVersions=19
> > > >
> > > > I would propose to stop accepting changes to the document now, as it
> > > might
> > > > start a discussion about the validity of the vote and the bylaws
> > itself.
> > > > Changes to the document require a 2/3 majority.
> > > >
> > > >
> > > > On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels <mx...@apache.org>
> > > > wrote:
> > > >
> > > > > Hi Becket,
> > > > >
> > > > > Thanks for clarifying and updating the draft. The changes look good
> > to
> > > > me.
> > > > >
> > > > > I don't feel strong about a 2/3 majority in case of committer/PMC
> > > > > removal. Like you pointed out, both provide a significant hurdle
> due
> > to
> > > > > possible vetos or a 2/3 majority.
> > > > >
> > > > > Thanks,
> > > > > Max
> > > > >
> > > > > On 13.08.19 10:36, Becket Qin wrote:
> > > > > > Piotr just reminded me that there was a previous suggestion to
> > > clarify
> > > > a
> > > > > > committer's responsibility when commit his/her own patch. So I'd
> > like
> > > > to
> > > > > > incorporate that in the bylaws. The additional clarification is
> > > > following
> > > > > > in bold and italic font.
> > > > > >
> > > > > > one +1 from a committer followed by a Lazy approval (not counting
> > the
> > > > > vote
> > > > > >> of the contributor), moving to lazy majority if a -1 is
> received.
> > > > > >>
> > > > > >
> > > > > >
> > > > > > Note that this implies that committers can +1 their own commits
> and
> > > > merge
> > > > > >> right away. *However, the committe**rs should use their best
> > > judgement
> > > > > to
> > > > > >> respect the components expertise and ongoing development plan.*
> > > > > >
> > > > > >
> > > > > > This does not really change any of the existing bylaws, just
> about
> > > > > > clarification.
> > > > > >
> > > > > > If there is no objection to this additional clarification, after
> > the
> > > > > bylaws
> > > > > > wiki is updated, I'll send an update notice to the voting thread
> to
> > > > > inform
> > > > > > those who already voted about this addition.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Jiangjie (Becket) Qin
> > > > > >
> > > > > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin <
> becket.qin@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> Hi Maximillian,
> > > > > >>
> > > > > >> Thanks for the feedback. Please see the reply below:
> > > > > >>
> > > > > >> Step 2 should include a personal email to the PMC members in
> > > question.
> > > > > >>
> > > > > >> I'm afraid reminders inside the vote thread could be overlooked
> > > > easily.
> > > > > >>
> > > > > >>
> > > > > >> This is exactly what I meant to say by "reach out" :) I just
> made
> > it
> > > > > more
> > > > > >> explicit.
> > > > > >>
> > > > > >> The way the terms are described in the draft, the consensus is
> > > "lazy",
> > > > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to
> > > "Lazy
> > > > > >>> Consensus". This is in line with the other definitions such as
> > > "Lazy
> > > > > >>> Majority".
> > > > > >>
> > > > > >> It was initially called "lazy consensus", but Robert pointed out
> > > that
> > > > > >> "lazy consensus" actually means something different in ASF term
> > [1].
> > > > > >> Here "lazy" pretty much means "assume everyone is +1 unless
> > someone
> > > > says
> > > > > >> otherwise". This means any vote that requires a minimum number
> of
> > +1
> > > > is
> > > > > not
> > > > > >> really a "lazy" vote.
> > > > > >>
> > > > > >> Removing a committer / PMC member only requires 3 binding votes.
> > I'd
> > > > > >>> expect an important action like this to require a 2/3 majority.
> > > > > >>
> > > > > >> Personally I think consensus is good enough here. PMC members
> can
> > > > cast a
> > > > > >> veto if they disagree about the removal. In some sense, it is
> more
> > > > > >> difficult than with 2/3 majority to remove a committer / PMC
> > member.
> > > > > Also,
> > > > > >> it might be a hard decision for some PMC members if they have
> > never
> > > > > worked
> > > > > >> with the person in question. That said, I am OK to change it to
> > 2/3
> > > > > >> majority as this will happen very rarely.
> > > > > >>
> > > > > >> Thanks,
> > > > > >>
> > > > > >> Jiangjie (Becket) Qin
> > > > > >>
> > > > > >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus
> > > > > >>
> > > > > >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <
> > mxm@apache.org>
> > > > > wrote:
> > > > > >>
> > > > > >>> I'm a bit late to the discussion here. Three suggestions:
> > > > > >>>
> > > > > >>> 1) Procedure for "insufficient active binding voters to reach
> 2/3
> > > > > majority
> > > > > >>>
> > > > > >>>>     1. Wait until the minimum length of the voting passes.
> > > > > >>>>     2. Publicly reach out to the remaining binding voters in
> the
> > > > > voting
> > > > > >>> mail thread for at least 2 attempts with at least 7 days
> between
> > > two
> > > > > >>> attempts.
> > > > > >>>>     3. If the binding voter being contacted still failed to
> > > respond
> > > > > >>> after all the attempts, the binding voter will be considered as
> > > > > inactive
> > > > > >>> for the purpose of this particular voting.
> > > > > >>>
> > > > > >>> Step 2 should include a personal email to the PMC members in
> > > > question.
> > > > > >>> I'm afraid reminders inside the vote thread could be overlooked
> > > > easily.
> > > > > >>>
> > > > > >>> 2) "Consensus" => "Lazy Consensus"
> > > > > >>>
> > > > > >>> The way the terms are described in the draft, the consensus is
> > > > "lazy",
> > > > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to
> > > "Lazy
> > > > > >>> Consensus". This is in line with the other definitions such as
> > > "Lazy
> > > > > >>> Majority".
> > > > > >>>
> > > > > >>> 3) Committer / PMC Removal
> > > > > >>>
> > > > > >>> Removing a committer / PMC member only requires 3 binding
> votes.
> > > I'd
> > > > > >>> expect an important action like this to require a 2/3 majority.
> > > > > >>>
> > > > > >>>
> > > > > >>> Do you think we could incorporate those suggestions?
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>> Max
> > > > > >>>
> > > > > >>> On 11.08.19 10:14, Becket Qin wrote:
> > > > > >>>> Hi folks,
> > > > > >>>>
> > > > > >>>> Thanks for all the discussion and support. I have started the
> > > voting
> > > > > >>> thread.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>
> > > > >
> > > >
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
> > > > > >>>>
> > > > > >>>> Thanks,
> > > > > >>>>
> > > > > >>>> Jiangjie (Becket) Qin
> > > > > >>>>
> > > > > >>>> On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <
> fhueske@gmail.com
> > >
> > > > > wrote:
> > > > > >>>>
> > > > > >>>>> Thanks for the update and driving the discussion Becket!
> > > > > >>>>> +1 for starting a vote.
> > > > > >>>>>
> > > > > >>>>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
> > > > > >>> becket.qin@gmail.com
> > > > > >>>>>> :
> > > > > >>>>>
> > > > > >>>>>> Thanks Stephan.
> > > > > >>>>>>
> > > > > >>>>>> I think we have resolved all the comments on the wiki page.
> > > There
> > > > > are
> > > > > >>> two
> > > > > >>>>>> minor changes made to the bylaws since last week.
> > > > > >>>>>> 1. For 2/3 majority, the required attempts to reach out to
> > > binding
> > > > > >>> voters
> > > > > >>>>>> is reduced from 3 to 2. This helps shorten the voting
> process
> > a
> > > > > little
> > > > > >>>>> bit.
> > > > > >>>>>> 2. Clarified what is considered as the adoption of new
> > codebase.
> > > > > >>>>>>
> > > > > >>>>>> I think we almost reached consensus. I'll start a voting
> > thread
> > > in
> > > > > two
> > > > > >>>>> days
> > > > > >>>>>> if there is no new concerns.
> > > > > >>>>>>
> > > > > >>>>>> Thanks,
> > > > > >>>>>>
> > > > > >>>>>> Jiangjie (Becket) Qin
> > > > > >>>>>>
> > > > > >>>>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <
> sewen@apache.org
> > >
> > > > > wrote:
> > > > > >>>>>>
> > > > > >>>>>>> I added a clarification to the table, clarifying that the
> > > current
> > > > > >>>>>> phrasing
> > > > > >>>>>>> means that committers do not need another +1 for their
> > commits.
> > > > > >>>>>>>
> > > > > >>>>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <
> > > fhueske@gmail.com
> > > > >
> > > > > >>>>> wrote:
> > > > > >>>>>>>
> > > > > >>>>>>>> Hi Becket,
> > > > > >>>>>>>>
> > > > > >>>>>>>> Thanks a lot for pushing this forward and addressing the
> > > > feedback.
> > > > > >>>>>>>> I'm very happy with the current state of the bylaws.
> > > > > >>>>>>>> +1 to wait until Friday before starting a vote.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Best, Fabian
> > > > > >>>>>>>>
> > > > > >>>>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> > > > > >>>>>>>> becket.qin@gmail.com
> > > > > >>>>>>>>> :
> > > > > >>>>>>>>
> > > > > >>>>>>>>> Hi Everyone,
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Thanks for all the discussion and feedback.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> It seems that we have almost reached consensus. I'll
> leave
> > > the
> > > > > >>>>>>> discussion
> > > > > >>>>>>>>> thread open until this Friday. If there is no more
> concerns
> > > > > raised,
> > > > > >>>>>>> I'll
> > > > > >>>>>>>>> start a voting thread after that.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Thanks,
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Jiangjie (Becket) Qin
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com>
> > > > wrote:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> Hi Becket,
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Thanks for noticing and resolving my comment around PMC
> > > > removal
> > > > > >>>>> and
> > > > > >>>>>>> ASF
> > > > > >>>>>>>>>> rules of PMC membership change process, which you seem
> to
> > > > > neglect
> > > > > >>>>>> in
> > > > > >>>>>>>> the
> > > > > >>>>>>>>>> summary of updates (smile).
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Best Regards,
> > > > > >>>>>>>>>> Yu
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <
> > > > becket.qin@gmail.com>
> > > > > >>>>>>> wrote:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> Hi folks,
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Thanks for all the feedback.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> It seems that there are a few concerns over the
> emeritus
> > > > status
> > > > > >>>>>>>> after 6
> > > > > >>>>>>>>>>> months of inactivity. Given that the main purpose is
> just
> > > to
> > > > > >>>>> make
> > > > > >>>>>>>> sure
> > > > > >>>>>>>>>> 2/3
> > > > > >>>>>>>>>>> majority can pass and we sort of have a solution for
> > that,
> > > I
> > > > > >>>>> just
> > > > > >>>>>>>>> updated
> > > > > >>>>>>>>>>> the draft with the following changes:
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> 1. Removed the inactivity term for emeritus committers
> /
> > > > PMCs.
> > > > > >>>>> A
> > > > > >>>>>>>>>> committer
> > > > > >>>>>>>>>>> / PMC will only be considered emeritus by their own
> > claim.
> > > > > >>>>>>>>>>> 2. Removed the approval process for reinstatement of
> the
> > > > > >>>>> emeritus
> > > > > >>>>>>>>>>> committers / PMCs. An emeritus committer / PMC will be
> > > > > >>>>> reinstated
> > > > > >>>>>>>> when
> > > > > >>>>>>>>>> they
> > > > > >>>>>>>>>>> send an email to the private@flink.apache.org.
> > > > > >>>>>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still
> > > > doable
> > > > > >>>>>> when
> > > > > >>>>>>>>> there
> > > > > >>>>>>>>>>> are non-emeritus committers / PMCs who do not cast the
> > > vote.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Please let me know if you have any further thoughts.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Thanks,
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Jiangjie (Becket) Qin
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
> > > > > >>>>>> becket.qin@gmail.com>
> > > > > >>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> Hi Fabian,
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Thanks for the feedback.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> I agree that if we don't like emeritus committers /
> > PMCs,
> > > we
> > > > > >>>>>>> don't
> > > > > >>>>>>>>> have
> > > > > >>>>>>>>>>> to
> > > > > >>>>>>>>>>>> do it. That said, emeritus status simply means whether
> > an
> > > > > >>>>>>>> individual
> > > > > >>>>>>>>> is
> > > > > >>>>>>>>>>>> active / inactive in the community. It does not make
> the
> > > > > >>>>> merits
> > > > > >>>>>>>>> earned
> > > > > >>>>>>>>>> to
> > > > > >>>>>>>>>>>> go away. For our purpose, emeritus status is mostly
> > just a
> > > > > >>>>> way
> > > > > >>>>>> to
> > > > > >>>>>>>>> make
> > > > > >>>>>>>>>>> 2/3
> > > > > >>>>>>>>>>>> majority possible. As you noticed, since reaching out
> to
> > > > > >>>>>> binding
> > > > > >>>>>>>>> voters
> > > > > >>>>>>>>>>> who
> > > > > >>>>>>>>>>>> have not voted can achieve the same goal, the emeritus
> > > > status
> > > > > >>>>>> is
> > > > > >>>>>>>> more
> > > > > >>>>>>>>>> of
> > > > > >>>>>>>>>>> an
> > > > > >>>>>>>>>>>> optimization so we don't have to ping the inactive
> > binding
> > > > > >>>>>> voters
> > > > > >>>>>>>>> every
> > > > > >>>>>>>>>>>> time and wait for long. However, given that 2/3
> majority
> > > > > >>>>>> votings
> > > > > >>>>>>>> are
> > > > > >>>>>>>>>>> rare,
> > > > > >>>>>>>>>>>> such communication cost is probably OK. So I think we
> > can
> > > > > >>>>>> remove
> > > > > >>>>>>>> that
> > > > > >>>>>>>>>>>> emeritus part from the bylaws.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> 1) We should add to the requirements of the PMC that
> > they
> > > > > >>>>> need
> > > > > >>>>>> to
> > > > > >>>>>>>>> make
> > > > > >>>>>>>>>>>>> sure the project complies with brand issues and
> reports
> > > > > >>>>> misuse
> > > > > >>>>>>> of
> > > > > >>>>>>>>> ASF
> > > > > >>>>>>>>>>>>> brands.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Good point. Added.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> 2) Do we want to restrict voting days to working days,
> > > i.e.,
> > > > > >>>>> a
> > > > > >>>>>> 3
> > > > > >>>>>>>> day
> > > > > >>>>>>>>>> vote
> > > > > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday
> > 11:00am?
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> This might be a little tricky because people are from
> > > > > >>>>> countries
> > > > > >>>>>>> in
> > > > > >>>>>>>>>>>> different time zones and with different holidays, and
> so
> > > on.
> > > > > >>>>> If
> > > > > >>>>>>> we
> > > > > >>>>>>>>> are
> > > > > >>>>>>>>>>>> worrying about 3 days minimum length is not enough for
> > > those
> > > > > >>>>>> who
> > > > > >>>>>>>> want
> > > > > >>>>>>>>>> to
> > > > > >>>>>>>>>>>> give feedback, we can make it 5 days.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> 3) Do we need a process do decide about removal of
> > > features
> > > > > >>>>>> (like
> > > > > >>>>>>>> the
> > > > > >>>>>>>>>>>>> DataSet API for instance or the legacy
> > DataSet/DataStream
> > > > > >>>>>> Python
> > > > > >>>>>>>>>> APIs)?
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> I assume such action should be covered by FLIP as it
> is
> > a
> > > > > >>>>>> change
> > > > > >>>>>>> to
> > > > > >>>>>>>>> the
> > > > > >>>>>>>>>>>> API and probably needs a migration plan. It would be
> > > useful
> > > > > >>>>> to
> > > > > >>>>>>>> have a
> > > > > >>>>>>>>>>>> formal deprecation procedure. But that might be better
> > to
> > > be
> > > > > >>>>>> put
> > > > > >>>>>>>> into
> > > > > >>>>>>>>>>>> somewhere else because the bylaws are primarily
> focusing
> > > on
> > > > > >>>>> the
> > > > > >>>>>>>>>>>> non-technical rules, whereas the deprecation seems
> more
> > on
> > > > > >>>>> the
> > > > > >>>>>>>>>> technical
> > > > > >>>>>>>>>>>> side.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Thanks,
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
> > > > > >>>>>>> fhueske@gmail.com>
> > > > > >>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Hi all,
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> First of all thank you very much Becket for starting
> > this
> > > > > >>>>>>>>> discussion!
> > > > > >>>>>>>>>>>>> I think it is a very good idea and overdue to
> formally
> > > > > >>>>> define
> > > > > >>>>>>> some
> > > > > >>>>>>>>> of
> > > > > >>>>>>>>>>> our
> > > > > >>>>>>>>>>>>> community processes.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Similar to Chesnay, I have concerns about the
> > distinction
> > > > > >>>>>>> between
> > > > > >>>>>>>>>> active
> > > > > >>>>>>>>>>>>> and non-active / emeritus committers and PMC members.
> > > > > >>>>>>>>>>>>> My foremost concern is that this is not in the spirit
> > of
> > > > the
> > > > > >>>>>>>> Apache
> > > > > >>>>>>>>>> Way
> > > > > >>>>>>>>>>>>> [1]
> > > > > >>>>>>>>>>>>> which is (among other things) based on the idea of
> > merit
> > > > > >>>>> which
> > > > > >>>>>>>> once
> > > > > >>>>>>>>>>>>> earned,
> > > > > >>>>>>>>>>>>> does not go away over time.
> > > > > >>>>>>>>>>>>> I know other projects like Hadoop and Kafka have
> > similar
> > > > > >>>>>> clauses
> > > > > >>>>>>>> in
> > > > > >>>>>>>>>> the
> > > > > >>>>>>>>>>>>> bylaws but IMO we don't need to adopt them if we
> don't
> > > like
> > > > > >>>>>>> them.
> > > > > >>>>>>>>>>>>> For example, I don't like the idea that committers or
> > PMC
> > > > > >>>>>>> members
> > > > > >>>>>>>>> who
> > > > > >>>>>>>>>>> are
> > > > > >>>>>>>>>>>>> temporarily away from the project (for whatever
> reason:
> > > > > >>>>>> parental
> > > > > >>>>>>>>>> leave,
> > > > > >>>>>>>>>>>>> sabbatical, health issues, etc.) need the PMC
> approval
> > to
> > > > be
> > > > > >>>>>>>>> "active"
> > > > > >>>>>>>>>>>>> again.
> > > > > >>>>>>>>>>>>> As far as I am aware, we have not seen any issues
> with
> > > > > >>>>>> inactive
> > > > > >>>>>>>>>> members
> > > > > >>>>>>>>>>> in
> > > > > >>>>>>>>>>>>> the past.
> > > > > >>>>>>>>>>>>> Moreover, it would be hard to track whether somebody
> > > became
> > > > > >>>>>>>> inactive
> > > > > >>>>>>>>>> at
> > > > > >>>>>>>>>>>>> some point in time (which we would need to do, if I
> > > > > >>>>> understand
> > > > > >>>>>>> the
> > > > > >>>>>>>>>>>>> proposal
> > > > > >>>>>>>>>>>>> correctly).
> > > > > >>>>>>>>>>>>> With the approach that Becket suggested in his last
> > email
> > > > > >>>>>>>> (reaching
> > > > > >>>>>>>>>> out
> > > > > >>>>>>>>>>> to
> > > > > >>>>>>>>>>>>> binding voters who haven't voted yet), we could drop
> > the
> > > > > >>>>>>>> distinction
> > > > > >>>>>>>>>>>>> between active and non-active committers and PMC
> > members.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> I also have a few minor comments:
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> 1) We should add to the requirements of the PMC [2]
> > that
> > > > > >>>>> they
> > > > > >>>>>>> need
> > > > > >>>>>>>>> to
> > > > > >>>>>>>>>>> make
> > > > > >>>>>>>>>>>>> sure the project complies with brand issues and
> reports
> > > > > >>>>> misuse
> > > > > >>>>>>> of
> > > > > >>>>>>>>> ASF
> > > > > >>>>>>>>>>>>> brands.
> > > > > >>>>>>>>>>>>> 2) Do we want to restrict voting days to working
> days,
> > > > i.e.,
> > > > > >>>>>> a 3
> > > > > >>>>>>>> day
> > > > > >>>>>>>>>>> vote
> > > > > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday
> > 11:00am?
> > > > > >>>>>>>>>>>>> 3) Do we need a process do decide about removal of
> > > features
> > > > > >>>>>>> (like
> > > > > >>>>>>>>> the
> > > > > >>>>>>>>>>>>> DataSet API for instance or the legacy
> > DataSet/DataStream
> > > > > >>>>>> Python
> > > > > >>>>>>>>>> APIs)?
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Thank you,
> > > > > >>>>>>>>>>>>> Fabian
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> [1] https://www.apache.org/theapacheway/
> > > > > >>>>>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket
> Qin <
> > > > > >>>>>>>>>>>>> becket.qin@gmail.com
> > > > > >>>>>>>>>>>>>> :
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Hi Hequn,
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see the
> reply
> > > > > >>>>>> below:
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
> > PMC
> > > > > >>>>> in
> > > > > >>>>>>>> the 3
> > > > > >>>>>>>>>>>>> binding
> > > > > >>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding
> committers
> > > > > >>>>> and 1
> > > > > >>>>>>>> PMC.
> > > > > >>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> > > > > >>>>> somehow
> > > > > >>>>>>> be a
> > > > > >>>>>>>>> big
> > > > > >>>>>>>>>>>>>> feature
> > > > > >>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is
> no
> > > > > >>>>> loss
> > > > > >>>>>>> of
> > > > > >>>>>>>>>>>>> flexibility
> > > > > >>>>>>>>>>>>>>> as committers also have a chance to vote and
> > > participate
> > > > > >>>>>> in
> > > > > >>>>>>>> it.
> > > > > >>>>>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs
> > are
> > > > > >>>>> the
> > > > > >>>>>>>>>> following:
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> 1. Generally speaking, the PMC's primary
> > responsibility
> > > is
> > > > > >>>>>>>>> operating
> > > > > >>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>> project and deciding what software to release on
> > behalf
> > > of
> > > > > >>>>>>> ASF.
> > > > > >>>>>>>>>>>>> Committers,
> > > > > >>>>>>>>>>>>>> on the other hand, are responsible for the technical
> > > part
> > > > > >>>>> of
> > > > > >>>>>>> the
> > > > > >>>>>>>>>>>>> project.
> > > > > >>>>>>>>>>>>>> So for FLIPs, a PMC's vote probably should not
> > outweigh
> > > a
> > > > > >>>>>>>>>> committer's
> > > > > >>>>>>>>>>>>> vote.
> > > > > >>>>>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is
> > > really
> > > > > >>>>>>>>> convincing
> > > > > >>>>>>>>>>>>> enough
> > > > > >>>>>>>>>>>>>> to decide whether the FLIP is good to go or not.
> Also,
> > > if
> > > > > >>>>>> some
> > > > > >>>>>>>>>>>>> committers
> > > > > >>>>>>>>>>>>>> have concern over a FLIP, they could just veto it.
> To
> > me
> > > > > >>>>> it
> > > > > >>>>>> is
> > > > > >>>>>>>>>>> actually
> > > > > >>>>>>>>>>>>> a
> > > > > >>>>>>>>>>>>>> more strict requirement to pass a FLIP than asking a
> > PMC
> > > > > >>>>> to
> > > > > >>>>>>>> vote.
> > > > > >>>>>>>>> In
> > > > > >>>>>>>>>>>>>> practice, people will usually also address the
> > concerns
> > > > > >>>>> even
> > > > > >>>>>>> if
> > > > > >>>>>>>>> they
> > > > > >>>>>>>>>>> are
> > > > > >>>>>>>>>>>>>> not from a PMC/committer before they start the
> voting
> > > > > >>>>>> process.
> > > > > >>>>>>>> So
> > > > > >>>>>>>>> I
> > > > > >>>>>>>>>>>>> don't
> > > > > >>>>>>>>>>>>>> see much benefit of requiring a PMC's vote in this
> > case.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the
> > votes
> > > > > >>>>> no
> > > > > >>>>>>>> longer
> > > > > >>>>>>>>>>>>>> independent. Ideally, a vote is either binding or
> > > > > >>>>>> non-binding
> > > > > >>>>>>> by
> > > > > >>>>>>>>>>>>> itself. If
> > > > > >>>>>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
> > > > > >>>>> imagine
> > > > > >>>>>>>> there
> > > > > >>>>>>>>>> have
> > > > > >>>>>>>>>>>>> been
> > > > > >>>>>>>>>>>>>> 3 committers who voted +1. But the FLIP still has
> not
> > > > > >>>>>> passed,
> > > > > >>>>>>> so
> > > > > >>>>>>>>>> those
> > > > > >>>>>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a
> > +1,
> > > > > >>>>>> those
> > > > > >>>>>>>>> votes
> > > > > >>>>>>>>>>>>>> suddenly become binding, which is a little awkward.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable
> to
> > > me.
> > > > > >>>>>> Some
> > > > > >>>>>>>>>>> thoughts
> > > > > >>>>>>>>>>>>> on
> > > > > >>>>>>>>>>>>>> this:
> > > > > >>>>>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is
> > probably
> > > > > >>>>>>> because
> > > > > >>>>>>>>>> there
> > > > > >>>>>>>>>>>>> are
> > > > > >>>>>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3
> > > majority
> > > > > >>>>>>>>>>> prohibitively
> > > > > >>>>>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
> > > > > >>>>> Flink[2]
> > > > > >>>>>>> and
> > > > > >>>>>>>> a
> > > > > >>>>>>>>>>> quick
> > > > > >>>>>>>>>>>>>> search shows at most 6 of them have not sent email
> in
> > > the
> > > > > >>>>>>>> recent 6
> > > > > >>>>>>>>>>>>> months
> > > > > >>>>>>>>>>>>>> or so.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare.
> It
> > > is
> > > > > >>>>>>>> designed
> > > > > >>>>>>>>>> in
> > > > > >>>>>>>>>>>>>> particular for the cases that broad opinions are
> > > > > >>>>> important,
> > > > > >>>>>>> more
> > > > > >>>>>>>>>>>>>> specifically new codebase adoption or modification
> to
> > > the
> > > > > >>>>>>>> bylaws.
> > > > > >>>>>>>>>>>>> Therefore
> > > > > >>>>>>>>>>>>>> such vote by its nature favors consensus over
> > > convenience.
> > > > > >>>>>>> That
> > > > > >>>>>>>>>> means
> > > > > >>>>>>>>>>>>> any
> > > > > >>>>>>>>>>>>>> alternative voting type reducing the coverage worth
> a
> > > > > >>>>>> careful
> > > > > >>>>>>>>>>> thinking.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> 3. I do agree that it does not make sense to have
> 2/3
> > > > > >>>>>> majority
> > > > > >>>>>>>> if
> > > > > >>>>>>>>>> such
> > > > > >>>>>>>>>>>>>> requirement is no-longer doable over time. But I am
> a
> > > > > >>>>> little
> > > > > >>>>>>>>>> hesitant
> > > > > >>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>> lower the threshold to lazy 2/3 majority in our
> case.
> > > What
> > > > > >>>>>> do
> > > > > >>>>>>>> you
> > > > > >>>>>>>>>>> think
> > > > > >>>>>>>>>>>>>> about doing the following:
> > > > > >>>>>>>>>>>>>>     - After the voting started, there will be at
> > least 6
> > > > > >>>>>> days
> > > > > >>>>>>>> for
> > > > > >>>>>>>>>>>>> people to
> > > > > >>>>>>>>>>>>>> cast their votes.
> > > > > >>>>>>>>>>>>>>     - After 6 days, if the result of the vote is
> still
> > > not
> > > > > >>>>>>>>>> determined,
> > > > > >>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>> person who started the vote should reach out to the
> > > > > >>>>> binding
> > > > > >>>>>>>> voters
> > > > > >>>>>>>>>> who
> > > > > >>>>>>>>>>>>> have
> > > > > >>>>>>>>>>>>>> not voted yet for at least 3 times and at least 7
> days
> > > > > >>>>>> between
> > > > > >>>>>>>>> each
> > > > > >>>>>>>>>>>>> time.
> > > > > >>>>>>>>>>>>>> If a binding voter still did not respond, the vote
> > from
> > > > > >>>>> that
> > > > > >>>>>>>> voter
> > > > > >>>>>>>>>>> will
> > > > > >>>>>>>>>>>>> be
> > > > > >>>>>>>>>>>>>> excluded from the 2/3 majority counting.
> > > > > >>>>>>>>>>>>>> This would ensure the coverage at our best effort
> > while
> > > > > >>>>>> still
> > > > > >>>>>>>> let
> > > > > >>>>>>>>>> the
> > > > > >>>>>>>>>>>>> 2/3
> > > > > >>>>>>>>>>>>>> majority vote make progress.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Thanks,
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> [1]
> https://projects.apache.org/committee.html?hadoop
> > > > > >>>>>>>>>>>>>> [2]
> https://projects.apache.org/committee.html?flink
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> > > > > >>>>>>>>> forwardxu315@gmail.com>
> > > > > >>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Big +1 on this.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> best
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> forward
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
> > > > > >>>>>> 下午1:30写道：
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> Hi Becket,
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> Big +1 on this.
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> > > > > >>>>>>> includes a
> > > > > >>>>>>>>> PMC
> > > > > >>>>>>>>>>>>> vote.
> > > > > >>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least
> one
> > > > > >>>>> PMC
> > > > > >>>>>> in
> > > > > >>>>>>>>> the 3
> > > > > >>>>>>>>>>>>>> binding
> > > > > >>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding
> committers
> > > > > >>>>>> and 1
> > > > > >>>>>>>>> PMC.
> > > > > >>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> > > > > >>>>>> somehow
> > > > > >>>>>>>> be a
> > > > > >>>>>>>>>> big
> > > > > >>>>>>>>>>>>>>> feature
> > > > > >>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is
> > no
> > > > > >>>>>> loss
> > > > > >>>>>>>> of
> > > > > >>>>>>>>>>>>>> flexibility
> > > > > >>>>>>>>>>>>>>>> as committers also have a chance to vote and
> > > > > >>>>> participate
> > > > > >>>>>>> in
> > > > > >>>>>>>>> it.
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> ========Seperator========
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> For the nice bylaws, I agree with the general idea
> > and
> > > > > >>>>>>> most
> > > > > >>>>>>>> of
> > > > > >>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>> content.
> > > > > >>>>>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority".
> > The
> > > > > >>>>>>> main
> > > > > >>>>>>>>>>> concern
> > > > > >>>>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>> I
> > > > > >>>>>>>>>>>>>>> am
> > > > > >>>>>>>>>>>>>>>> not sure if it is doable in practice. The reasons
> > are:
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
> > > > > >>>>>> committer
> > > > > >>>>>>>> or a
> > > > > >>>>>>>>>> PMC
> > > > > >>>>>>>>>>>>>> member
> > > > > >>>>>>>>>>>>>>>> is active if he or she sends one email to the
> > mailing
> > > > > >>>>>> list
> > > > > >>>>>>>>>> every 6
> > > > > >>>>>>>>>>>>>>> months.
> > > > > >>>>>>>>>>>>>>>> While the minimum length of the vote is only 6
> days.
> > > > > >>>>>> There
> > > > > >>>>>>>> are
> > > > > >>>>>>>>>>>>> chances
> > > > > >>>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>>> during the vote, some of the active members are
> > still
> > > > > >>>>>>>> offline
> > > > > >>>>>>>>> of
> > > > > >>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>> community.
> > > > > >>>>>>>>>>>>>>>> 2. The code of Flink is changing fast and not
> > everyone
> > > > > >>>>>>> fully
> > > > > >>>>>>>>>>>>>> understands
> > > > > >>>>>>>>>>>>>>>> every part. We don't need to force people to vote
> if
> > > > > >>>>>> they
> > > > > >>>>>>>> are
> > > > > >>>>>>>>>> not
> > > > > >>>>>>>>>>>>> sure
> > > > > >>>>>>>>>>>>>>>> about it. It may also make the final result less
> > > > > >>>>>> credible.
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> Given the above reasons, perhaps we can change the
> > 2/3
> > > > > >>>>>>>>> Majority
> > > > > >>>>>>>>>> to
> > > > > >>>>>>>>>>>>> lazy
> > > > > >>>>>>>>>>>>>>> 2/3
> > > > > >>>>>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
> > > > > >>>>>> higher
> > > > > >>>>>>>>>>> threshold,
> > > > > >>>>>>>>>>>>>>>> however, more practical.
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> What do you think?
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> > > > > >>>>>>>>>> becket.qin@gmail.com
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> Hi Jincheng,
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki
> > page.
> > > > > >>>>>>> Just
> > > > > >>>>>>>> a
> > > > > >>>>>>>>>>> brief
> > > > > >>>>>>>>>>>>>>>> summary,
> > > > > >>>>>>>>>>>>>>>>> the current bylaws do require some of the FLIPs
> to
> > > > > >>>>> get
> > > > > >>>>>>> PMC
> > > > > >>>>>>>>>>>>> approval
> > > > > >>>>>>>>>>>>>> if
> > > > > >>>>>>>>>>>>>>>>> their impact is big enough. But it leaves
> majority
> > > > > >>>>> of
> > > > > >>>>>>> the
> > > > > >>>>>>>>>>>>> technical
> > > > > >>>>>>>>>>>>>>>>> decisions to the committers who are supposed to
> be
> > > > > >>>>>>>>> responsible
> > > > > >>>>>>>>>>> for
> > > > > >>>>>>>>>>>>>>> making
> > > > > >>>>>>>>>>>>>>>>> such decisions.
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> Re: Robert,
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> I agree we can simply remove the requirement of
> +1
> > > > > >>>>>> from
> > > > > >>>>>>> a
> > > > > >>>>>>>>>>>>> non-author
> > > > > >>>>>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
> > > > > >>>>> does
> > > > > >>>>>>> not
> > > > > >>>>>>>>> make
> > > > > >>>>>>>>>>>>> sense
> > > > > >>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
> > > > > >>>>>> updated
> > > > > >>>>>>>> the
> > > > > >>>>>>>>>>> bylaws
> > > > > >>>>>>>>>>>>>>> wiki.
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> Thanks,
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> > > > > >>>>>>>>>>>>> rmetzger@apache.org
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> Hi all,
> > > > > >>>>>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
> > > > > >>>>>>> current
> > > > > >>>>>>>>>>> status
> > > > > >>>>>>>>>>>>> in
> > > > > >>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
> > > > > >>>>> is
> > > > > >>>>>> a
> > > > > >>>>>>>> very
> > > > > >>>>>>>>>>>>> involved
> > > > > >>>>>>>>>>>>>>>> task.
> > > > > >>>>>>>>>>>>>>>>>> Unless there's somebody who's really eager to
> > > > > >>>>> drive
> > > > > >>>>>>>> this,
> > > > > >>>>>>>>> I
> > > > > >>>>>>>>>>>>> would
> > > > > >>>>>>>>>>>>>>> stick
> > > > > >>>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
> > > > > >>>>>> Flink,
> > > > > >>>>>>>> even
> > > > > >>>>>>>>>> if
> > > > > >>>>>>>>>>>>> this
> > > > > >>>>>>>>>>>>>>>> means
> > > > > >>>>>>>>>>>>>>>>>> some changes.
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> The cross-review requirement is the last big
> open
> > > > > >>>>>>> point
> > > > > >>>>>>>> in
> > > > > >>>>>>>>>>> this
> > > > > >>>>>>>>>>>>>>>>> discussion.
> > > > > >>>>>>>>>>>>>>>>>> It seems that a there is a slight tendency in
> the
> > > > > >>>>>>>>> discussion
> > > > > >>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>> this
> > > > > >>>>>>>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>>>>>> not feasible given the current pull request
> review
> > > > > >>>>>>>>>> situation.
> > > > > >>>>>>>>>>>>>>>>>> For the sake of bringing this discussion to a
> > > > > >>>>>>>> conclusion,
> > > > > >>>>>>>>>> I'm
> > > > > >>>>>>>>>>>>> fine
> > > > > >>>>>>>>>>>>>>> with
> > > > > >>>>>>>>>>>>>>>>>> leaving this requirement out. As we are
> currently
> > > > > >>>>>>> adding
> > > > > >>>>>>>>>> more
> > > > > >>>>>>>>>>>>>>>> committers
> > > > > >>>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>> the project, we might be able to revisit this
> > > > > >>>>>>> discussion
> > > > > >>>>>>>>> in
> > > > > >>>>>>>>>> 3
> > > > > >>>>>>>>>>> -
> > > > > >>>>>>>>>>>>> 6
> > > > > >>>>>>>>>>>>>>>> months.
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> > > > > >>>>>>>>>>>>>>> sunjincheng121@gmail.com
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> Hi Becket,
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> Thanks for the proposal.
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> > > > > >>>>>>>>> includes a
> > > > > >>>>>>>>>>> PMC
> > > > > >>>>>>>>>>>>>>> vote.
> > > > > >>>>>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
> > > > > >>>>>> the
> > > > > >>>>>>>>> user's
> > > > > >>>>>>>>>>>>>>> interface
> > > > > >>>>>>>>>>>>>>>>>>> changes. What do you think? (I leave the
> comment
> > > > > >>>>>> in
> > > > > >>>>>>>> the
> > > > > >>>>>>>>>>> wiki.)
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> Best,
> > > > > >>>>>>>>>>>>>>>>>>> Jincheng
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
> > > > > >>>>>>>> 于2019年7月17日周三
> > > > > >>>>>>>>>>>>>> 下午9:12写道：
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>> Hi all,
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
> > > > > >>>>>> that
> > > > > >>>>>>> I
> > > > > >>>>>>>>>> really
> > > > > >>>>>>>>>>>>> like
> > > > > >>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>> proposed bylaws!
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
> > > > > >>>>>>>>> expressed
> > > > > >>>>>>>>>> by
> > > > > >>>>>>>>>>>>> few
> > > > > >>>>>>>>>>>>>>>> people
> > > > > >>>>>>>>>>>>>>>>>>>> before that the "committer +1" on code change
> > > > > >>>>>>> might
> > > > > >>>>>>>> be
> > > > > >>>>>>>>>>> hard
> > > > > >>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>> achieve
> > > > > >>>>>>>>>>>>>>>>>>>> currently. On the other hand I would say this
> > > > > >>>>>>> would
> > > > > >>>>>>>> be
> > > > > >>>>>>>>>>>>>> beneficial
> > > > > >>>>>>>>>>>>>>>> for
> > > > > >>>>>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
> > > > > >>>>>>> knowledge
> > > > > >>>>>>>>>>>>> sharing.
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>> I was just wondering what should be the next
> > > > > >>>>>> step
> > > > > >>>>>>>> for
> > > > > >>>>>>>>>>> this?
> > > > > >>>>>>>>>>>>> I
> > > > > >>>>>>>>>>>>>>> think
> > > > > >>>>>>>>>>>>>>>>> it
> > > > > >>>>>>>>>>>>>>>>>>>> would make sense to already use those bylaws
> > > > > >>>>> and
> > > > > >>>>>>> put
> > > > > >>>>>>>>>> them
> > > > > >>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>> PMC
> > > > > >>>>>>>>>>>>>>>>> vote.
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>> Best,
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>> Dawid
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
> > > > > >>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
> > > > > >>>>> think.
> > > > > >>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> > > > > >>>>>> If
> > > > > >>>>>>> we
> > > > > >>>>>>>>> are
> > > > > >>>>>>>>>>>>>> stating
> > > > > >>>>>>>>>>>>>>>>> that a
> > > > > >>>>>>>>>>>>>>>>>>>> single
> > > > > >>>>>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
> > > > > >>>>>> review,
> > > > > >>>>>>>>> with 0
> > > > > >>>>>>>>>>>>> hours
> > > > > >>>>>>>>>>>>>>>> delay
> > > > > >>>>>>>>>>>>>>>>>> (de
> > > > > >>>>>>>>>>>>>>>>>>>> facto
> > > > > >>>>>>>>>>>>>>>>>>>>>>> the current state), we should also write
> > > > > >>>>>> down
> > > > > >>>>>>>> that
> > > > > >>>>>>>>>>> this
> > > > > >>>>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>>>>> subject
> > > > > >>>>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
> > > > > >>>>>> the
> > > > > >>>>>>>>>>>>> components
> > > > > >>>>>>>>>>>>>>>>> expertise
> > > > > >>>>>>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
> > > > > >>>>> facto
> > > > > >>>>>>>>> current
> > > > > >>>>>>>>>>>>>> state).
> > > > > >>>>>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
> > > > > >>>>>>>>>> intention,
> > > > > >>>>>>>>>>>>> but
> > > > > >>>>>>>>>>>>>> it
> > > > > >>>>>>>>>>>>>>>> may
> > > > > >>>>>>>>>>>>>>>>>> be a
> > > > > >>>>>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
> > > > > >>>>>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
> > > > > >>>>>>> rule
> > > > > >>>>>>>>>>> anyway,
> > > > > >>>>>>>>>>>>>>>> intended
> > > > > >>>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>> be
> > > > > >>>>>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
> > > > > >>>>>> to
> > > > > >>>>>>>> just
> > > > > >>>>>>>>>>>>> avoid a
> > > > > >>>>>>>>>>>>>>>>>> situation
> > > > > >>>>>>>>>>>>>>>>>>>> when someone violates current uncodified state
> > > > > >>>>>> and
> > > > > >>>>>>>>>> refers
> > > > > >>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>> bylaws
> > > > > >>>>>>>>>>>>>>>>>>>> which are saying merging with any committer +1
> > > > > >>>>>> is
> > > > > >>>>>>>>> always
> > > > > >>>>>>>>>>>>> fine
> > > > > >>>>>>>>>>>>>>> (like
> > > > > >>>>>>>>>>>>>>>>>> mine
> > > > > >>>>>>>>>>>>>>>>>>> +1
> > > > > >>>>>>>>>>>>>>>>>>>> for flink-python or flink-ml).
> > > > > >>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>> Piotrek
> > > > > >>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
> > > > > >>>>> <
> > > > > >>>>>>>>>>>>>>> aljoscha@apache.org
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
> > > > > >>>>>> FLIP.
> > > > > >>>>>>>>> This
> > > > > >>>>>>>>>> is
> > > > > >>>>>>>>>>>>> just
> > > > > >>>>>>>>>>>>>>>> about
> > > > > >>>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>> voting, before that there needs to be the
> > > > > >>>>>>> discussion
> > > > > >>>>>>>>>>>>> thread. If
> > > > > >>>>>>>>>>>>>>>> three
> > > > > >>>>>>>>>>>>>>>>>>> days
> > > > > >>>>>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
> > > > > >>>>>>> (i.e. 3
> > > > > >>>>>>>>>>>>>>>> committers/PMCs
> > > > > >>>>>>>>>>>>>>>>>> have
> > > > > >>>>>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
> > > > > >>>>>> So
> > > > > >>>>>>>> far,
> > > > > >>>>>>>>>> we
> > > > > >>>>>>>>>>>>> have
> > > > > >>>>>>>>>>>>>>>> rarely
> > > > > >>>>>>>>>>>>>>>>>> see
> > > > > >>>>>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
> > > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
> > > > > >>>>> we
> > > > > >>>>>>> want
> > > > > >>>>>>>>> to
> > > > > >>>>>>>>>>> use
> > > > > >>>>>>>>>>>>>> "lazy
> > > > > >>>>>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
> > > > > >>>>>>> that
> > > > > >>>>>>>>>> should
> > > > > >>>>>>>>>>>>> be
> > > > > >>>>>>>>>>>>>>>> changed
> > > > > >>>>>>>>>>>>>>>>>>> from
> > > > > >>>>>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
> > > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
> > > > > >>>>>>> current
> > > > > >>>>>>>>>> state
> > > > > >>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>>>>> all
> > > > > >>>>>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
> > > > > >>>>>>> come
> > > > > >>>>>>>> up
> > > > > >>>>>>>>>>> with
> > > > > >>>>>>>>>>>>>>>> something
> > > > > >>>>>>>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>>>>>>> reflects the common state, according to
> > > > > >>>>>>>>> PMCs/commiters,
> > > > > >>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>> might
> > > > > >>>>>>>>>>>>>>>>>> take a
> > > > > >>>>>>>>>>>>>>>>>>>> very long time. In that case I think it’s
> > > > > >>>>> better
> > > > > >>>>>>> to
> > > > > >>>>>>>>>> adopt
> > > > > >>>>>>>>>>>>>>> something
> > > > > >>>>>>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
> > > > > >>>>>> do
> > > > > >>>>>>> it
> > > > > >>>>>>>>>> now.
> > > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>> Aljoscha
> > > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
> > > > > >>>>> <
> > > > > >>>>>>>>>>>>>>> piotr@ververica.com
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> Hi,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
> > > > > >>>>> speaking
> > > > > >>>>>> +1
> > > > > >>>>>>>>> from
> > > > > >>>>>>>>>> my
> > > > > >>>>>>>>>>>>> side
> > > > > >>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>> general idea and most of the content. I also
> > > > > >>>>> see
> > > > > >>>>>>>> merit
> > > > > >>>>>>>>>> to
> > > > > >>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>> Chesney's
> > > > > >>>>>>>>>>>>>>>>>>>> proposal to start from the current state. I
> > > > > >>>>>> think
> > > > > >>>>>>>>> either
> > > > > >>>>>>>>>>>>> would
> > > > > >>>>>>>>>>>>>> be
> > > > > >>>>>>>>>>>>>>>>> fine
> > > > > >>>>>>>>>>>>>>>>>>> for
> > > > > >>>>>>>>>>>>>>>>>>>> me.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> Couple of comments:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> 1.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
> > > > > >>>>> another
> > > > > >>>>>>>>>> committer
> > > > > >>>>>>>>>>>>> would
> > > > > >>>>>>>>>>>>>>>> slow
> > > > > >>>>>>>>>>>>>>>>>> down
> > > > > >>>>>>>>>>>>>>>>>>>> and put even more strain on the current
> > > > > >>>>>> reviewing
> > > > > >>>>>>>>>>> bottleneck
> > > > > >>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>>>>>> are
> > > > > >>>>>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
> > > > > >>>>>>> context
> > > > > >>>>>>>>>>> switch
> > > > > >>>>>>>>>>>>>> cost
> > > > > >>>>>>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>>>>>> quite
> > > > > >>>>>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
> > > > > >>>>>> second
> > > > > >>>>>>>>>> “cross”
> > > > > >>>>>>>>>>>>>>> committer
> > > > > >>>>>>>>>>>>>>>>>> could
> > > > > >>>>>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
> > > > > >>>>>>> Besides,
> > > > > >>>>>>>>>>> current
> > > > > >>>>>>>>>>>>>> setup
> > > > > >>>>>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
> > > > > >>>>>>>>> required)
> > > > > >>>>>>>>>>>>> works
> > > > > >>>>>>>>>>>>>>> quite
> > > > > >>>>>>>>>>>>>>>>>> well
> > > > > >>>>>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
> > > > > >>>>>> the
> > > > > >>>>>>>>> other
> > > > > >>>>>>>>>>> hand
> > > > > >>>>>>>>>>>>>>>>> reviewing
> > > > > >>>>>>>>>>>>>>>>>>>> bottleneck is.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> 2.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
> > > > > >>>>> ask
> > > > > >>>>>>>>> another
> > > > > >>>>>>>>>>>>>>> committer
> > > > > >>>>>>>>>>>>>>>>> for
> > > > > >>>>>>>>>>>>>>>>>>>> feedback or not.
> > > > > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> > > > > >>>>>> If
> > > > > >>>>>>> we
> > > > > >>>>>>>>> are
> > > > > >>>>>>>>>>>>>> stating
> > > > > >>>>>>>>>>>>>>>>> that a
> > > > > >>>>>>>>>>>>>>>>>>>> single committers +1 is good enough for code
> > > > > >>>>>>> review,
> > > > > >>>>>>>>>> with
> > > > > >>>>>>>>>>> 0
> > > > > >>>>>>>>>>>>>> hours
> > > > > >>>>>>>>>>>>>>>>> delay
> > > > > >>>>>>>>>>>>>>>>>>> (de
> > > > > >>>>>>>>>>>>>>>>>>>> facto the current state), we should also write
> > > > > >>>>>>> down
> > > > > >>>>>>>>> that
> > > > > >>>>>>>>>>>>> this
> > > > > >>>>>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>>>>>> subject
> > > > > >>>>>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>>> the best judgement of the committer to respect
> > > > > >>>>>> the
> > > > > >>>>>>>>>>>>> components
> > > > > >>>>>>>>>>>>>>>>> expertise
> > > > > >>>>>>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
> > > > > >>>>>>> current
> > > > > >>>>>>>>>>> state).
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> 3.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
> > > > > >>>>>>>>> currently
> > > > > >>>>>>>>>>>>> might
> > > > > >>>>>>>>>>>>>> be
> > > > > >>>>>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
> > > > > >>>>>> if
> > > > > >>>>>>>>>>> respected
> > > > > >>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>> letter.
> > > > > >>>>>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
> > > > > >>>>>>>>>> committers
> > > > > >>>>>>>>>>>>> with
> > > > > >>>>>>>>>>>>>>>>> highest
> > > > > >>>>>>>>>>>>>>>>>>>> expertise in the affected components managed
> > > > > >>>>> to
> > > > > >>>>>>>>> respond
> > > > > >>>>>>>>>> or
> > > > > >>>>>>>>>>>>> not.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>> Piotrek
> > > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
> > > > > >>>>> Schepler
> > > > > >>>>>> <
> > > > > >>>>>>>>>>>>>>>> chesnay@apache.org>
> > > > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
> > > > > >>>>>>> write
> > > > > >>>>>>>>> down
> > > > > >>>>>>>>>>>>> Bylaws
> > > > > >>>>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>>>>>>> reflect the current state, and then have
> > > > > >>>>>> separate
> > > > > >>>>>>>>>>>>> discussions
> > > > > >>>>>>>>>>>>>> for
> > > > > >>>>>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
> > > > > >>>>>> this
> > > > > >>>>>>>>>>>>> discussion
> > > > > >>>>>>>>>>>>>>> will
> > > > > >>>>>>>>>>>>>>>>>>> quickly
> > > > > >>>>>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
> > > > > >>>>>>>>> discussed
> > > > > >>>>>>>>>>> at
> > > > > >>>>>>>>>>>>>> once.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
> > > > > >>>>>> Qin
> > > > > >>>>>>> <
> > > > > >>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> > > > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
> > > > > >>>>> and
> > > > > >>>>>>>>>> feedback.
> > > > > >>>>>>>>>>>>>> Please
> > > > > >>>>>>>>>>>>>>>> see
> > > > > >>>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>> replies
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> below:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> > > > > >>>>> Change"
> > > > > >>>>>> we
> > > > > >>>>>>>>> could
> > > > > >>>>>>>>>>>>> also
> > > > > >>>>>>>>>>>>>>> add a
> > > > > >>>>>>>>>>>>>>>>> row
> > > > > >>>>>>>>>>>>>>>>>>>> for "Code
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> > > > > >>>>>> reference
> > > > > >>>>>>> to
> > > > > >>>>>>>>> the
> > > > > >>>>>>>>>>>>> FLIP
> > > > > >>>>>>>>>>>>>>>> process
> > > > > >>>>>>>>>>>>>>>>>>>> page. A
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
> > > > > >>>>> for
> > > > > >>>>>>>>>> approvals,
> > > > > >>>>>>>>>>>>> etc.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> > > > > >>>>> currently
> > > > > >>>>>>>>> requires
> > > > > >>>>>>>>>>>>> "one
> > > > > >>>>>>>>>>>>>> +1
> > > > > >>>>>>>>>>>>>>>>> from a
> > > > > >>>>>>>>>>>>>>>>>>>> committer
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> > > > > >>>>> followed
> > > > > >>>>>>> by a
> > > > > >>>>>>>>>> Lazy
> > > > > >>>>>>>>>>>>>>> approval
> > > > > >>>>>>>>>>>>>>>>> (not
> > > > > >>>>>>>>>>>>>>>>>>>> counting
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
> > > > > >>>>> to
> > > > > >>>>>>> lazy
> > > > > >>>>>>>>>>>>> majority
> > > > > >>>>>>>>>>>>>> if
> > > > > >>>>>>>>>>>>>>> a
> > > > > >>>>>>>>>>>>>>>> -1
> > > > > >>>>>>>>>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> received".
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
> > > > > >>>>>>>>> committer
> > > > > >>>>>>>>>>>>> always
> > > > > >>>>>>>>>>>>>>>>> needs a
> > > > > >>>>>>>>>>>>>>>>>>>> review
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
> > > > > >>>>>>> know
> > > > > >>>>>>>>> this
> > > > > >>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>>>> currently
> > > > > >>>>>>>>>>>>>>>>>> not
> > > > > >>>>>>>>>>>>>>>>>>>> always
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > > > > >>>>>>>> contributor
> > > > > >>>>>>>>>>>>> reviews
> > > > > >>>>>>>>>>>>>> &
> > > > > >>>>>>>>>>>>>>>>> +1s).
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
> > > > > >>>>> we
> > > > > >>>>>>> can
> > > > > >>>>>>>>>> make
> > > > > >>>>>>>>>>> it
> > > > > >>>>>>>>>>>>>> easy
> > > > > >>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>>> follow the
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> > > > > >>>>>> Flink-specific
> > > > > >>>>>>>> Jira
> > > > > >>>>>>>>>>>>>> workflows
> > > > > >>>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>> ticket
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> types +
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
> > > > > >>>>> is
> > > > > >>>>>>>>>> certainly
> > > > > >>>>>>>>>>>>>> "Step
> > > > > >>>>>>>>>>>>>>>> 2",
> > > > > >>>>>>>>>>>>>>>>> I
> > > > > >>>>>>>>>>>>>>>>>>>> believe,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> > > > > >>>>>>> transparent
> > > > > >>>>>>>>> as
> > > > > >>>>>>>>>>>>>> possible,
> > > > > >>>>>>>>>>>>>>>>>>>> otherwise they
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> & Re: Till
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> > > > > >>>>>>> author
> > > > > >>>>>>>>> and
> > > > > >>>>>>>>>>>>>> getting
> > > > > >>>>>>>>>>>>>>> a
> > > > > >>>>>>>>>>>>>>>> +1
> > > > > >>>>>>>>>>>>>>>>>>> from
> > > > > >>>>>>>>>>>>>>>>>>>> a
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> > > > > >>>>>> should
> > > > > >>>>>>>> know
> > > > > >>>>>>>>>>> when
> > > > > >>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>> ask
> > > > > >>>>>>>>>>>>>>>>>>> another
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
> > > > > >>>>> I
> > > > > >>>>>>>> would
> > > > > >>>>>>>>>> not
> > > > > >>>>>>>>>>>>>> enforce
> > > > > >>>>>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> > > > > >>>>> author
> > > > > >>>>>>> is
> > > > > >>>>>>>> a
> > > > > >>>>>>>>>>>>> committer
> > > > > >>>>>>>>>>>>>>> but
> > > > > >>>>>>>>>>>>>>>>> of
> > > > > >>>>>>>>>>>>>>>>>>>> course
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
> > > > > >>>>> here.
> > > > > >>>>>>>> TBH,
> > > > > >>>>>>>>> in
> > > > > >>>>>>>>>>>>> Kafka
> > > > > >>>>>>>>>>>>>>>>>>> occasionally
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
> > > > > >>>>> still
> > > > > >>>>>>>>> merged
> > > > > >>>>>>>>>>>>> without
> > > > > >>>>>>>>>>>>>>>>>> following
> > > > > >>>>>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
> > > > > >>>>> rare.
> > > > > >>>>>>>> That
> > > > > >>>>>>>>>>> said,
> > > > > >>>>>>>>>>>>> I
> > > > > >>>>>>>>>>>>>>> still
> > > > > >>>>>>>>>>>>>>>>>> think
> > > > > >>>>>>>>>>>>>>>>>>>> an
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
> > > > > >>>>> sense
> > > > > >>>>>>> due
> > > > > >>>>>>>>> to
> > > > > >>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>> following
> > > > > >>>>>>>>>>>>>>>>>>>> reasons:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
> > > > > >>>>>> to
> > > > > >>>>>>>> make
> > > > > >>>>>>>>>>> sure
> > > > > >>>>>>>>>>>>>> every
> > > > > >>>>>>>>>>>>>>>>> patch
> > > > > >>>>>>>>>>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
> > > > > >>>>>>>> little
> > > > > >>>>>>>>>>>>> difficult
> > > > > >>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>>> guarantee if
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
> > > > > >>>>>>> many
> > > > > >>>>>>>>>>>>> reasons. In
> > > > > >>>>>>>>>>>>>>>> some
> > > > > >>>>>>>>>>>>>>>>>>>> cases, a
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
> > > > > >>>>> knowledge
> > > > > >>>>>>>> about
> > > > > >>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>> project
> > > > > >>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>> make
> > > > > >>>>>>>>>>>>>>>>>>>> a good
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
> > > > > >>>>>> contributors
> > > > > >>>>>>>> are
> > > > > >>>>>>>>>> more
> > > > > >>>>>>>>>>>>>>> eagerly
> > > > > >>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>> get a
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
> > > > > >>>>>> willing
> > > > > >>>>>>>> to
> > > > > >>>>>>>>>>> lower
> > > > > >>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>> review
> > > > > >>>>>>>>>>>>>>>>>>> bar.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
> > > > > >>>>>> among
> > > > > >>>>>>>>>>>>> committers,
> > > > > >>>>>>>>>>>>>>>> which
> > > > > >>>>>>>>>>>>>>>>> I
> > > > > >>>>>>>>>>>>>>>>>>>> personally
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
> > > > > >>>>>>> form
> > > > > >>>>>>>>>>>>> consistent
> > > > > >>>>>>>>>>>>>>>> design
> > > > > >>>>>>>>>>>>>>>>>>>> principles
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
> > > > > >>>>>>>> committers
> > > > > >>>>>>>>>> will
> > > > > >>>>>>>>>>>>> know
> > > > > >>>>>>>>>>>>>>> how
> > > > > >>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>> other
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
> > > > > >>>>>> from
> > > > > >>>>>>>> each
> > > > > >>>>>>>>>>>>> other.
> > > > > >>>>>>>>>>>>>> So
> > > > > >>>>>>>>>>>>>>>> they
> > > > > >>>>>>>>>>>>>>>>>>> tend
> > > > > >>>>>>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
> > > > > >>>>>>> things
> > > > > >>>>>>>>>> should
> > > > > >>>>>>>>>>>>> be
> > > > > >>>>>>>>>>>>>>> done
> > > > > >>>>>>>>>>>>>>>> in
> > > > > >>>>>>>>>>>>>>>>>>>> general.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
> > > > > >>>>>>>> consider
> > > > > >>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>> following
> > > > > >>>>>>>>>>>>>>>>> two
> > > > > >>>>>>>>>>>>>>>>>>>> scenarios:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
> > > > > >>>>> a
> > > > > >>>>>>> lot
> > > > > >>>>>>>> of
> > > > > >>>>>>>>>>>>>>> iterations.
> > > > > >>>>>>>>>>>>>>>>> Then
> > > > > >>>>>>>>>>>>>>>>>>>> the patch
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
> > > > > >>>>>> time
> > > > > >>>>>>>>>> because
> > > > > >>>>>>>>>>>>> there
> > > > > >>>>>>>>>>>>>>> are
> > > > > >>>>>>>>>>>>>>>>>>> things
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
> > > > > >>>>> changed.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
> > > > > >>>>> very
> > > > > >>>>>>>> smooth
> > > > > >>>>>>>>>> and
> > > > > >>>>>>>>>>>>>> quick,
> > > > > >>>>>>>>>>>>>>>> so
> > > > > >>>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>> patch is
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
> > > > > >>>>> patch
> > > > > >>>>>>> does
> > > > > >>>>>>>>> not
> > > > > >>>>>>>>>>>>> take
> > > > > >>>>>>>>>>>>>>> much
> > > > > >>>>>>>>>>>>>>>>>> time.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
> > > > > >>>>>> patch
> > > > > >>>>>>>>> from a
> > > > > >>>>>>>>>>>>>>> committer
> > > > > >>>>>>>>>>>>>>>>>> falls
> > > > > >>>>>>>>>>>>>>>>>>>> either in
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
> > > > > >>>>> is
> > > > > >>>>>>> to
> > > > > >>>>>>>>>> review
> > > > > >>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>> patch
> > > > > >>>>>>>>>>>>>>>>>>>> because
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
> > > > > >>>>> needs
> > > > > >>>>>>> to
> > > > > >>>>>>>> be
> > > > > >>>>>>>>>>>>>> reviewed.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
> > > > > >>>>>> take
> > > > > >>>>>>>>> much
> > > > > >>>>>>>>>>> time
> > > > > >>>>>>>>>>>>>>>> anyways.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
> > > > > >>>>>>> case
> > > > > >>>>>>>> 1
> > > > > >>>>>>>>> if
> > > > > >>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>> skip
> > > > > >>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>> cross-review.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Robert
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
> > > > > >>>>>> and
> > > > > >>>>>>>> made
> > > > > >>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>> following
> > > > > >>>>>>>>>>>>>>>>>>>> modifications
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
> > > > > >>>>> section.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
> > > > > >>>>>> to
> > > > > >>>>>>>>>>>>> "consensus"
> > > > > >>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>> align
> > > > > >>>>>>>>>>>>>>>>>>> with
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
> > > > > >>>>> and
> > > > > >>>>>>>> other
> > > > > >>>>>>>>>>>>>> projects.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> > > > > >>>>> unnecessary
> > > > > >>>>>>>>> noise.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
> > > > > >>>>>> 2/3
> > > > > >>>>>>>>>>> majority
> > > > > >>>>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>>>> still
> > > > > >>>>>>>>>>>>>>>>>>>> feasible in
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> practice.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> > > > > >>>>> the
> > > > > >>>>>>>> draft
> > > > > >>>>>>>>>>>>> compared
> > > > > >>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>> existing
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
> > > > > >>>>>>>>> highlight
> > > > > >>>>>>>>>>>>> these
> > > > > >>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>> discuss
> > > > > >>>>>>>>>>>>>>>>>>>> them
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
> > > > > >>>>>>> familiar
> > > > > >>>>>>>>>> enough
> > > > > >>>>>>>>>>>>> with
> > > > > >>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>> current Flink
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
> > > > > >>>>> saw
> > > > > >>>>>>> you
> > > > > >>>>>>>>>>>>> commented
> > > > > >>>>>>>>>>>>>> on
> > > > > >>>>>>>>>>>>>>>> some
> > > > > >>>>>>>>>>>>>>>>>>> part
> > > > > >>>>>>>>>>>>>>>>>>>> in the
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> > > > > >>>>>>> bylaws?
> > > > > >>>>>>>>> I’m
> > > > > >>>>>>>>>>>>> asking
> > > > > >>>>>>>>>>>>>>>>> because
> > > > > >>>>>>>>>>>>>>>>>> I
> > > > > >>>>>>>>>>>>>>>>>>>> quite
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> > > > > >>>>> essentially
> > > > > >>>>>>>>> adopting
> > > > > >>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>> Kafka
> > > > > >>>>>>>>>>>>>>>>>>> bylaws.
> > > > > >>>>>>>>>>>>>>>>>>>> I
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> > > > > >>>>>> try
> > > > > >>>>>>>> to
> > > > > >>>>>>>>>>>>> re-invent
> > > > > >>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>> wheel
> > > > > >>>>>>>>>>>>>>>>>>>> here.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
> > > > > >>>>> version
> > > > > >>>>>>> of
> > > > > >>>>>>>>> the
> > > > > >>>>>>>>>>>>> draft
> > > > > >>>>>>>>>>>>>> was
> > > > > >>>>>>>>>>>>>>>>>> almost
> > > > > >>>>>>>>>>>>>>>>>>>> identical
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
> > > > > >>>>> caught a
> > > > > >>>>>>> few
> > > > > >>>>>>>>>>>>>> inconsistent
> > > > > >>>>>>>>>>>>>>>>>> places.
> > > > > >>>>>>>>>>>>>>>>>>>> So it
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
> > > > > >>>>>> make
> > > > > >>>>>>>> sure
> > > > > >>>>>>>>>> we
> > > > > >>>>>>>>>>>>> truly
> > > > > >>>>>>>>>>>>>>>> agree
> > > > > >>>>>>>>>>>>>>>>>> on
> > > > > >>>>>>>>>>>>>>>>>>>> them.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
> > > > > >>>>>>>> shortly
> > > > > >>>>>>>>>>> after
> > > > > >>>>>>>>>>>>>>>> adoption.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
> > > > > >>>>> valuable
> > > > > >>>>>>>>>> feedback.
> > > > > >>>>>>>>>>>>> These
> > > > > >>>>>>>>>>>>>>> are
> > > > > >>>>>>>>>>>>>>>>>> great
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> discussion.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
> > > > > >>>>> Aljoscha
> > > > > >>>>>>>>> Krettek
> > > > > >>>>>>>>>> <
> > > > > >>>>>>>>>>>>>>>>>>>> aljoscha@apache.org>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Big +1
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> > > > > >>>>>>> bylaws?
> > > > > >>>>>>>>> I’m
> > > > > >>>>>>>>>>>>> asking
> > > > > >>>>>>>>>>>>>>>>>> because I
> > > > > >>>>>>>>>>>>>>>>>>>> quite
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> > > > > >>>>> essentially
> > > > > >>>>>>>>> adopting
> > > > > >>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>> Kafka
> > > > > >>>>>>>>>>>>>>>>>>> bylaws.
> > > > > >>>>>>>>>>>>>>>>>>>> I
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> > > > > >>>>>> try
> > > > > >>>>>>>> to
> > > > > >>>>>>>>>>>>> re-invent
> > > > > >>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>> wheel
> > > > > >>>>>>>>>>>>>>>>>>>> here.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
> > > > > >>>>>>>>>> “committer
> > > > > >>>>>>>>>>>>> +1”
> > > > > >>>>>>>>>>>>>>>>>>> requirement.
> > > > > >>>>>>>>>>>>>>>>>>>> We
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
> > > > > >>>>> would
> > > > > >>>>>>>>> actually
> > > > > >>>>>>>>>>> be
> > > > > >>>>>>>>>>>>> in
> > > > > >>>>>>>>>>>>>>>> favour
> > > > > >>>>>>>>>>>>>>>>>> of
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> requiring
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
> > > > > >>>>>>>>>> complicated.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
> > > > > >>>>>> Rohrmann
> > > > > >>>>>>> <
> > > > > >>>>>>>>>>>>>>>>>> trohrmann@apache.org>
> > > > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
> > > > > >>>>>>>> Becket.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
> > > > > >>>>> emeritus
> > > > > >>>>>>> (or
> > > > > >>>>>>>>>> active
> > > > > >>>>>>>>>>>>> vs.
> > > > > >>>>>>>>>>>>>>>>>> inactive),
> > > > > >>>>>>>>>>>>>>>>>>>> it
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> won't
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
> > > > > >>>>> vote
> > > > > >>>>>>>>> because
> > > > > >>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>>> already
> > > > > >>>>>>>>>>>>>>>>>> have
> > > > > >>>>>>>>>>>>>>>>>>>> too
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> many
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> > > > > >>>>>>>> author
> > > > > >>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>> getting a
> > > > > >>>>>>>>>>>>>>>>> +1
> > > > > >>>>>>>>>>>>>>>>>>>> from a
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> > > > > >>>>>> should
> > > > > >>>>>>>>> know
> > > > > >>>>>>>>>>>>> when to
> > > > > >>>>>>>>>>>>>>> ask
> > > > > >>>>>>>>>>>>>>>>>>> another
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
> > > > > >>>>> Hence, I
> > > > > >>>>>>>> would
> > > > > >>>>>>>>>> not
> > > > > >>>>>>>>>>>>>>> enforce
> > > > > >>>>>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> > > > > >>>>>> author
> > > > > >>>>>>>> is a
> > > > > >>>>>>>>>>>>>> committer
> > > > > >>>>>>>>>>>>>>>> but
> > > > > >>>>>>>>>>>>>>>>> of
> > > > > >>>>>>>>>>>>>>>>>>>> course
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Till
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
> > > > > >>>>> Chesnay
> > > > > >>>>>>>>>> Schepler
> > > > > >>>>>>>>>>> <
> > > > > >>>>>>>>>>>>>>>>>>>> chesnay@apache.org>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> > > > > >>>>>>> unnecessary
> > > > > >>>>>>>>>> noise.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> > > > > >>>>>> the
> > > > > >>>>>>>>> draft
> > > > > >>>>>>>>>>>>>> compared
> > > > > >>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>>> existing
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
> > > > > >>>>> to
> > > > > >>>>>>>>>> highlight
> > > > > >>>>>>>>>>>>>> these
> > > > > >>>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>>> discuss
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> them
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
> > > > > >>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
> > > > > >>>>> this
> > > > > >>>>>>>>>>> discussion
> > > > > >>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>> creating
> > > > > >>>>>>>>>>>>>>>>>>> a
> > > > > >>>>>>>>>>>>>>>>>>>> draft
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> in
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> > > > > >>>>> that
> > > > > >>>>>> a
> > > > > >>>>>>>>>>> committer
> > > > > >>>>>>>>>>>>>>> always
> > > > > >>>>>>>>>>>>>>>>>> needs
> > > > > >>>>>>>>>>>>>>>>>>> a
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> review
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> > > > > >>>>>> as I
> > > > > >>>>>>>>> know
> > > > > >>>>>>>>>>>>> this is
> > > > > >>>>>>>>>>>>>>>>>> currently
> > > > > >>>>>>>>>>>>>>>>>>>> not
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > > > > >>>>>>>>>> contributor
> > > > > >>>>>>>>>>>>>>> reviews
> > > > > >>>>>>>>>>>>>>>> &
> > > > > >>>>>>>>>>>>>>>>>>> +1s).
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
> > > > > >>>>> if
> > > > > >>>>>>> we
> > > > > >>>>>>>>> had
> > > > > >>>>>>>>>>>>> cases
> > > > > >>>>>>>>>>>>>> in
> > > > > >>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>> past
> > > > > >>>>>>>>>>>>>>>>>>>> where
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> code
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
> > > > > >>>>> we
> > > > > >>>>>>>>> believe
> > > > > >>>>>>>>>>>>> that we
> > > > > >>>>>>>>>>>>>>>> have
> > > > > >>>>>>>>>>>>>>>>>>> enough
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> capacity
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
> > > > > >>>>>>>> approval.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> > > > > >>>>>>>> Konstantin
> > > > > >>>>>>>>>>> Knauf
> > > > > >>>>>>>>>>>>> <
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
> > > > > >>>>>>> Becket. I
> > > > > >>>>>>>>>> have
> > > > > >>>>>>>>>>>>> two
> > > > > >>>>>>>>>>>>>>>> remarks
> > > > > >>>>>>>>>>>>>>>>>>>> regarding
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> > > > > >>>>>>> Change"
> > > > > >>>>>>>> we
> > > > > >>>>>>>>>>> could
> > > > > >>>>>>>>>>>>>> also
> > > > > >>>>>>>>>>>>>>>>> add a
> > > > > >>>>>>>>>>>>>>>>>>>> row for
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Code
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> > > > > >>>>>>>> reference
> > > > > >>>>>>>>> to
> > > > > >>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>> FLIP
> > > > > >>>>>>>>>>>>>>>>>> process
> > > > > >>>>>>>>>>>>>>>>>>>> page.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> A
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
> > > > > >>>>> rules
> > > > > >>>>>>> for
> > > > > >>>>>>>>>>>>> approvals,
> > > > > >>>>>>>>>>>>>>> etc.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> > > > > >>>>>>> currently
> > > > > >>>>>>>>>>> requires
> > > > > >>>>>>>>>>>>>> "one
> > > > > >>>>>>>>>>>>>>>> +1
> > > > > >>>>>>>>>>>>>>>>>>> from a
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> > > > > >>>>>>> followed
> > > > > >>>>>>>>> by a
> > > > > >>>>>>>>>>>>> Lazy
> > > > > >>>>>>>>>>>>>>>>> approval
> > > > > >>>>>>>>>>>>>>>>>>> (not
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> counting
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
> > > > > >>>>> moving
> > > > > >>>>>>> to
> > > > > >>>>>>>>> lazy
> > > > > >>>>>>>>>>>>>> majority
> > > > > >>>>>>>>>>>>>>>> if
> > > > > >>>>>>>>>>>>>>>>> a
> > > > > >>>>>>>>>>>>>>>>>> -1
> > > > > >>>>>>>>>>>>>>>>>>>> is
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> received".
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> > > > > >>>>>> that a
> > > > > >>>>>>>>>>> committer
> > > > > >>>>>>>>>>>>>>> always
> > > > > >>>>>>>>>>>>>>>>>>> needs a
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> review
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> > > > > >>>>>> as I
> > > > > >>>>>>>>> know
> > > > > >>>>>>>>>>>>> this is
> > > > > >>>>>>>>>>>>>>>>>> currently
> > > > > >>>>>>>>>>>>>>>>>>>> not
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > > > > >>>>>>>>>> contributor
> > > > > >>>>>>>>>>>>>>> reviews
> > > > > >>>>>>>>>>>>>>>> &
> > > > > >>>>>>>>>>>>>>>>>>> +1s).
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
> > > > > >>>>>> how
> > > > > >>>>>>>> we
> > > > > >>>>>>>>>> can
> > > > > >>>>>>>>>>>>> make
> > > > > >>>>>>>>>>>>>> it
> > > > > >>>>>>>>>>>>>>>>> easy
> > > > > >>>>>>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>>>> follow
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> > > > > >>>>>>>> Flink-specific
> > > > > >>>>>>>>>> Jira
> > > > > >>>>>>>>>>>>>>>> workflows
> > > > > >>>>>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>>> ticket
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> types +
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
> > > > > >>>>>> this
> > > > > >>>>>>> is
> > > > > >>>>>>>>>>>>> certainly
> > > > > >>>>>>>>>>>>>>>> "Step
> > > > > >>>>>>>>>>>>>>>>>> 2",
> > > > > >>>>>>>>>>>>>>>>>>> I
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> believe,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> > > > > >>>>>>>>> transparent
> > > > > >>>>>>>>>>> as
> > > > > >>>>>>>>>>>>>>>> possible,
> > > > > >>>>>>>>>>>>>>>>>>>> otherwise
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> they
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
> > > > > >>>>>> Becket
> > > > > >>>>>>>>> Qin <
> > > > > >>>>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
> > > > > >>>>>> process
> > > > > >>>>>>>>>>> discussion
> > > > > >>>>>>>>>>>>>>> thread
> > > > > >>>>>>>>>>>>>>>>>> [1],
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> currently
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
> > > > > >>>>>>> govern
> > > > > >>>>>>>>> the
> > > > > >>>>>>>>>>>>>>> operation
> > > > > >>>>>>>>>>>>>>>> of
> > > > > >>>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>> project.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
> > > > > >>>>>> community
> > > > > >>>>>>>> to
> > > > > >>>>>>>>>>>>>> coordinate
> > > > > >>>>>>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>>>>>> contribute
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
> > > > > >>>>>>> other
> > > > > >>>>>>>>>>>>> processes
> > > > > >>>>>>>>>>>>>>> such
> > > > > >>>>>>>>>>>>>>>>> as
> > > > > >>>>>>>>>>>>>>>>>>>> FLIP.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
> > > > > >>>>> page
> > > > > >>>>>>> and
> > > > > >>>>>>>>>> would
> > > > > >>>>>>>>>>>>> like
> > > > > >>>>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>>> start a
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> discussion
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
> > > > > >>>>> in
> > > > > >>>>>>> the
> > > > > >>>>>>>>>>>>> community.
> > > > > >>>>>>>>>>>>>>>> It'll
> > > > > >>>>>>>>>>>>>>>>> be
> > > > > >>>>>>>>>>>>>>>>>>>> great to
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> hear
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>
> > > > >
> > > >
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
> > > > > >>>>>> Architect
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
> > > > > >>>>>>>> 31.08.2019,
> > > > > >>>>>>>>>>>>> 05.09. -
> > > > > >>>>>>>>>>>>>>>>>>> 06.09.2010
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
> > > > > >>>>>> 115,
> > > > > >>>>>>>>> 10115
> > > > > >>>>>>>>>>>>>> Berlin,
> > > > > >>>>>>>>>>>>>>>>>> Germany
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
> > > > > >>>>>>>> Charlottenburg:
> > > > > >>>>>>>>>> HRB
> > > > > >>>>>>>>>>>>>> 158244
> > > > > >>>>>>>>>>>>>>> B
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
> > > > > >>>>>>> Tzoumas,
> > > > > >>>>>>>>> Dr.
> > > > > >>>>>>>>>>>>> Stephan
> > > > > >>>>>>>>>>>>>>>> Ewen
> > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Flink project bylaws

[Becket Qin <be...@gmail.com>]

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 <rm...@apache.org> wrote:

> I have started a Wiki page (editable by all) for collecting ideas for
> Bylaws changes, so that we can batch changes together and then vote on
> them:
> https://cwiki.apache.org/confluence/display/FLINK/Ideas+for+Bylaw+changes
>
> On Tue, Aug 13, 2019 at 1:41 PM Becket Qin <be...@gmail.com> wrote:
>
> > Hi Robert,
> >
> > Thanks for help apply the changes. I agree we should freeze the change to
> > the bylaws page starting from now. For this particular addition of
> > clarification, I'll send a notice in the voting thread to let who have
> > already voted to know.
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Tue, Aug 13, 2019 at 1:29 PM Robert Metzger <rm...@apache.org>
> > wrote:
> >
> > > Hi Becket,
> > > I've applied the proposed change to the document:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026&selectedPageVersions=20&selectedPageVersions=19
> > >
> > > I would propose to stop accepting changes to the document now, as it
> > might
> > > start a discussion about the validity of the vote and the bylaws
> itself.
> > > Changes to the document require a 2/3 majority.
> > >
> > >
> > > On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels <mx...@apache.org>
> > > wrote:
> > >
> > > > Hi Becket,
> > > >
> > > > Thanks for clarifying and updating the draft. The changes look good
> to
> > > me.
> > > >
> > > > I don't feel strong about a 2/3 majority in case of committer/PMC
> > > > removal. Like you pointed out, both provide a significant hurdle due
> to
> > > > possible vetos or a 2/3 majority.
> > > >
> > > > Thanks,
> > > > Max
> > > >
> > > > On 13.08.19 10:36, Becket Qin wrote:
> > > > > Piotr just reminded me that there was a previous suggestion to
> > clarify
> > > a
> > > > > committer's responsibility when commit his/her own patch. So I'd
> like
> > > to
> > > > > incorporate that in the bylaws. The additional clarification is
> > > following
> > > > > in bold and italic font.
> > > > >
> > > > > one +1 from a committer followed by a Lazy approval (not counting
> the
> > > > vote
> > > > >> of the contributor), moving to lazy majority if a -1 is received.
> > > > >>
> > > > >
> > > > >
> > > > > Note that this implies that committers can +1 their own commits and
> > > merge
> > > > >> right away. *However, the committe**rs should use their best
> > judgement
> > > > to
> > > > >> respect the components expertise and ongoing development plan.*
> > > > >
> > > > >
> > > > > This does not really change any of the existing bylaws, just about
> > > > > clarification.
> > > > >
> > > > > If there is no objection to this additional clarification, after
> the
> > > > bylaws
> > > > > wiki is updated, I'll send an update notice to the voting thread to
> > > > inform
> > > > > those who already voted about this addition.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jiangjie (Becket) Qin
> > > > >
> > > > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin <be...@gmail.com>
> > > > wrote:
> > > > >
> > > > >> Hi Maximillian,
> > > > >>
> > > > >> Thanks for the feedback. Please see the reply below:
> > > > >>
> > > > >> Step 2 should include a personal email to the PMC members in
> > question.
> > > > >>
> > > > >> I'm afraid reminders inside the vote thread could be overlooked
> > > easily.
> > > > >>
> > > > >>
> > > > >> This is exactly what I meant to say by "reach out" :) I just made
> it
> > > > more
> > > > >> explicit.
> > > > >>
> > > > >> The way the terms are described in the draft, the consensus is
> > "lazy",
> > > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to
> > "Lazy
> > > > >>> Consensus". This is in line with the other definitions such as
> > "Lazy
> > > > >>> Majority".
> > > > >>
> > > > >> It was initially called "lazy consensus", but Robert pointed out
> > that
> > > > >> "lazy consensus" actually means something different in ASF term
> [1].
> > > > >> Here "lazy" pretty much means "assume everyone is +1 unless
> someone
> > > says
> > > > >> otherwise". This means any vote that requires a minimum number of
> +1
> > > is
> > > > not
> > > > >> really a "lazy" vote.
> > > > >>
> > > > >> Removing a committer / PMC member only requires 3 binding votes.
> I'd
> > > > >>> expect an important action like this to require a 2/3 majority.
> > > > >>
> > > > >> Personally I think consensus is good enough here. PMC members can
> > > cast a
> > > > >> veto if they disagree about the removal. In some sense, it is more
> > > > >> difficult than with 2/3 majority to remove a committer / PMC
> member.
> > > > Also,
> > > > >> it might be a hard decision for some PMC members if they have
> never
> > > > worked
> > > > >> with the person in question. That said, I am OK to change it to
> 2/3
> > > > >> majority as this will happen very rarely.
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> Jiangjie (Becket) Qin
> > > > >>
> > > > >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus
> > > > >>
> > > > >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <
> mxm@apache.org>
> > > > wrote:
> > > > >>
> > > > >>> I'm a bit late to the discussion here. Three suggestions:
> > > > >>>
> > > > >>> 1) Procedure for "insufficient active binding voters to reach 2/3
> > > > majority
> > > > >>>
> > > > >>>>     1. Wait until the minimum length of the voting passes.
> > > > >>>>     2. Publicly reach out to the remaining binding voters in the
> > > > voting
> > > > >>> mail thread for at least 2 attempts with at least 7 days between
> > two
> > > > >>> attempts.
> > > > >>>>     3. If the binding voter being contacted still failed to
> > respond
> > > > >>> after all the attempts, the binding voter will be considered as
> > > > inactive
> > > > >>> for the purpose of this particular voting.
> > > > >>>
> > > > >>> Step 2 should include a personal email to the PMC members in
> > > question.
> > > > >>> I'm afraid reminders inside the vote thread could be overlooked
> > > easily.
> > > > >>>
> > > > >>> 2) "Consensus" => "Lazy Consensus"
> > > > >>>
> > > > >>> The way the terms are described in the draft, the consensus is
> > > "lazy",
> > > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to
> > "Lazy
> > > > >>> Consensus". This is in line with the other definitions such as
> > "Lazy
> > > > >>> Majority".
> > > > >>>
> > > > >>> 3) Committer / PMC Removal
> > > > >>>
> > > > >>> Removing a committer / PMC member only requires 3 binding votes.
> > I'd
> > > > >>> expect an important action like this to require a 2/3 majority.
> > > > >>>
> > > > >>>
> > > > >>> Do you think we could incorporate those suggestions?
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Max
> > > > >>>
> > > > >>> On 11.08.19 10:14, Becket Qin wrote:
> > > > >>>> Hi folks,
> > > > >>>>
> > > > >>>> Thanks for all the discussion and support. I have started the
> > voting
> > > > >>> thread.
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > >
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>>
> > > > >>>> Jiangjie (Becket) Qin
> > > > >>>>
> > > > >>>> On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <fhueske@gmail.com
> >
> > > > wrote:
> > > > >>>>
> > > > >>>>> Thanks for the update and driving the discussion Becket!
> > > > >>>>> +1 for starting a vote.
> > > > >>>>>
> > > > >>>>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
> > > > >>> becket.qin@gmail.com
> > > > >>>>>> :
> > > > >>>>>
> > > > >>>>>> Thanks Stephan.
> > > > >>>>>>
> > > > >>>>>> I think we have resolved all the comments on the wiki page.
> > There
> > > > are
> > > > >>> two
> > > > >>>>>> minor changes made to the bylaws since last week.
> > > > >>>>>> 1. For 2/3 majority, the required attempts to reach out to
> > binding
> > > > >>> voters
> > > > >>>>>> is reduced from 3 to 2. This helps shorten the voting process
> a
> > > > little
> > > > >>>>> bit.
> > > > >>>>>> 2. Clarified what is considered as the adoption of new
> codebase.
> > > > >>>>>>
> > > > >>>>>> I think we almost reached consensus. I'll start a voting
> thread
> > in
> > > > two
> > > > >>>>> days
> > > > >>>>>> if there is no new concerns.
> > > > >>>>>>
> > > > >>>>>> Thanks,
> > > > >>>>>>
> > > > >>>>>> Jiangjie (Becket) Qin
> > > > >>>>>>
> > > > >>>>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <sewen@apache.org
> >
> > > > wrote:
> > > > >>>>>>
> > > > >>>>>>> I added a clarification to the table, clarifying that the
> > current
> > > > >>>>>> phrasing
> > > > >>>>>>> means that committers do not need another +1 for their
> commits.
> > > > >>>>>>>
> > > > >>>>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <
> > fhueske@gmail.com
> > > >
> > > > >>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> Hi Becket,
> > > > >>>>>>>>
> > > > >>>>>>>> Thanks a lot for pushing this forward and addressing the
> > > feedback.
> > > > >>>>>>>> I'm very happy with the current state of the bylaws.
> > > > >>>>>>>> +1 to wait until Friday before starting a vote.
> > > > >>>>>>>>
> > > > >>>>>>>> Best, Fabian
> > > > >>>>>>>>
> > > > >>>>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> > > > >>>>>>>> becket.qin@gmail.com
> > > > >>>>>>>>> :
> > > > >>>>>>>>
> > > > >>>>>>>>> Hi Everyone,
> > > > >>>>>>>>>
> > > > >>>>>>>>> Thanks for all the discussion and feedback.
> > > > >>>>>>>>>
> > > > >>>>>>>>> It seems that we have almost reached consensus. I'll leave
> > the
> > > > >>>>>>> discussion
> > > > >>>>>>>>> thread open until this Friday. If there is no more concerns
> > > > raised,
> > > > >>>>>>> I'll
> > > > >>>>>>>>> start a voting thread after that.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Thanks,
> > > > >>>>>>>>>
> > > > >>>>>>>>> Jiangjie (Becket) Qin
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com>
> > > wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Hi Becket,
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Thanks for noticing and resolving my comment around PMC
> > > removal
> > > > >>>>> and
> > > > >>>>>>> ASF
> > > > >>>>>>>>>> rules of PMC membership change process, which you seem to
> > > > neglect
> > > > >>>>>> in
> > > > >>>>>>>> the
> > > > >>>>>>>>>> summary of updates (smile).
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Best Regards,
> > > > >>>>>>>>>> Yu
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <
> > > becket.qin@gmail.com>
> > > > >>>>>>> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> Hi folks,
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Thanks for all the feedback.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> It seems that there are a few concerns over the emeritus
> > > status
> > > > >>>>>>>> after 6
> > > > >>>>>>>>>>> months of inactivity. Given that the main purpose is just
> > to
> > > > >>>>> make
> > > > >>>>>>>> sure
> > > > >>>>>>>>>> 2/3
> > > > >>>>>>>>>>> majority can pass and we sort of have a solution for
> that,
> > I
> > > > >>>>> just
> > > > >>>>>>>>> updated
> > > > >>>>>>>>>>> the draft with the following changes:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> 1. Removed the inactivity term for emeritus committers /
> > > PMCs.
> > > > >>>>> A
> > > > >>>>>>>>>> committer
> > > > >>>>>>>>>>> / PMC will only be considered emeritus by their own
> claim.
> > > > >>>>>>>>>>> 2. Removed the approval process for reinstatement of the
> > > > >>>>> emeritus
> > > > >>>>>>>>>>> committers / PMCs. An emeritus committer / PMC will be
> > > > >>>>> reinstated
> > > > >>>>>>>> when
> > > > >>>>>>>>>> they
> > > > >>>>>>>>>>> send an email to the private@flink.apache.org.
> > > > >>>>>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still
> > > doable
> > > > >>>>>> when
> > > > >>>>>>>>> there
> > > > >>>>>>>>>>> are non-emeritus committers / PMCs who do not cast the
> > vote.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Please let me know if you have any further thoughts.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Jiangjie (Becket) Qin
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
> > > > >>>>>> becket.qin@gmail.com>
> > > > >>>>>>>>>> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> Hi Fabian,
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Thanks for the feedback.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> I agree that if we don't like emeritus committers /
> PMCs,
> > we
> > > > >>>>>>> don't
> > > > >>>>>>>>> have
> > > > >>>>>>>>>>> to
> > > > >>>>>>>>>>>> do it. That said, emeritus status simply means whether
> an
> > > > >>>>>>>> individual
> > > > >>>>>>>>> is
> > > > >>>>>>>>>>>> active / inactive in the community. It does not make the
> > > > >>>>> merits
> > > > >>>>>>>>> earned
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>>>> go away. For our purpose, emeritus status is mostly
> just a
> > > > >>>>> way
> > > > >>>>>> to
> > > > >>>>>>>>> make
> > > > >>>>>>>>>>> 2/3
> > > > >>>>>>>>>>>> majority possible. As you noticed, since reaching out to
> > > > >>>>>> binding
> > > > >>>>>>>>> voters
> > > > >>>>>>>>>>> who
> > > > >>>>>>>>>>>> have not voted can achieve the same goal, the emeritus
> > > status
> > > > >>>>>> is
> > > > >>>>>>>> more
> > > > >>>>>>>>>> of
> > > > >>>>>>>>>>> an
> > > > >>>>>>>>>>>> optimization so we don't have to ping the inactive
> binding
> > > > >>>>>> voters
> > > > >>>>>>>>> every
> > > > >>>>>>>>>>>> time and wait for long. However, given that 2/3 majority
> > > > >>>>>> votings
> > > > >>>>>>>> are
> > > > >>>>>>>>>>> rare,
> > > > >>>>>>>>>>>> such communication cost is probably OK. So I think we
> can
> > > > >>>>>> remove
> > > > >>>>>>>> that
> > > > >>>>>>>>>>>> emeritus part from the bylaws.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> 1) We should add to the requirements of the PMC that
> they
> > > > >>>>> need
> > > > >>>>>> to
> > > > >>>>>>>>> make
> > > > >>>>>>>>>>>>> sure the project complies with brand issues and reports
> > > > >>>>> misuse
> > > > >>>>>>> of
> > > > >>>>>>>>> ASF
> > > > >>>>>>>>>>>>> brands.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Good point. Added.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> 2) Do we want to restrict voting days to working days,
> > i.e.,
> > > > >>>>> a
> > > > >>>>>> 3
> > > > >>>>>>>> day
> > > > >>>>>>>>>> vote
> > > > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday
> 11:00am?
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> This might be a little tricky because people are from
> > > > >>>>> countries
> > > > >>>>>>> in
> > > > >>>>>>>>>>>> different time zones and with different holidays, and so
> > on.
> > > > >>>>> If
> > > > >>>>>>> we
> > > > >>>>>>>>> are
> > > > >>>>>>>>>>>> worrying about 3 days minimum length is not enough for
> > those
> > > > >>>>>> who
> > > > >>>>>>>> want
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>>>> give feedback, we can make it 5 days.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> 3) Do we need a process do decide about removal of
> > features
> > > > >>>>>> (like
> > > > >>>>>>>> the
> > > > >>>>>>>>>>>>> DataSet API for instance or the legacy
> DataSet/DataStream
> > > > >>>>>> Python
> > > > >>>>>>>>>> APIs)?
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> I assume such action should be covered by FLIP as it is
> a
> > > > >>>>>> change
> > > > >>>>>>> to
> > > > >>>>>>>>> the
> > > > >>>>>>>>>>>> API and probably needs a migration plan. It would be
> > useful
> > > > >>>>> to
> > > > >>>>>>>> have a
> > > > >>>>>>>>>>>> formal deprecation procedure. But that might be better
> to
> > be
> > > > >>>>>> put
> > > > >>>>>>>> into
> > > > >>>>>>>>>>>> somewhere else because the bylaws are primarily focusing
> > on
> > > > >>>>> the
> > > > >>>>>>>>>>>> non-technical rules, whereas the deprecation seems more
> on
> > > > >>>>> the
> > > > >>>>>>>>>> technical
> > > > >>>>>>>>>>>> side.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
> > > > >>>>>>> fhueske@gmail.com>
> > > > >>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Hi all,
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> First of all thank you very much Becket for starting
> this
> > > > >>>>>>>>> discussion!
> > > > >>>>>>>>>>>>> I think it is a very good idea and overdue to formally
> > > > >>>>> define
> > > > >>>>>>> some
> > > > >>>>>>>>> of
> > > > >>>>>>>>>>> our
> > > > >>>>>>>>>>>>> community processes.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Similar to Chesnay, I have concerns about the
> distinction
> > > > >>>>>>> between
> > > > >>>>>>>>>> active
> > > > >>>>>>>>>>>>> and non-active / emeritus committers and PMC members.
> > > > >>>>>>>>>>>>> My foremost concern is that this is not in the spirit
> of
> > > the
> > > > >>>>>>>> Apache
> > > > >>>>>>>>>> Way
> > > > >>>>>>>>>>>>> [1]
> > > > >>>>>>>>>>>>> which is (among other things) based on the idea of
> merit
> > > > >>>>> which
> > > > >>>>>>>> once
> > > > >>>>>>>>>>>>> earned,
> > > > >>>>>>>>>>>>> does not go away over time.
> > > > >>>>>>>>>>>>> I know other projects like Hadoop and Kafka have
> similar
> > > > >>>>>> clauses
> > > > >>>>>>>> in
> > > > >>>>>>>>>> the
> > > > >>>>>>>>>>>>> bylaws but IMO we don't need to adopt them if we don't
> > like
> > > > >>>>>>> them.
> > > > >>>>>>>>>>>>> For example, I don't like the idea that committers or
> PMC
> > > > >>>>>>> members
> > > > >>>>>>>>> who
> > > > >>>>>>>>>>> are
> > > > >>>>>>>>>>>>> temporarily away from the project (for whatever reason:
> > > > >>>>>> parental
> > > > >>>>>>>>>> leave,
> > > > >>>>>>>>>>>>> sabbatical, health issues, etc.) need the PMC approval
> to
> > > be
> > > > >>>>>>>>> "active"
> > > > >>>>>>>>>>>>> again.
> > > > >>>>>>>>>>>>> As far as I am aware, we have not seen any issues with
> > > > >>>>>> inactive
> > > > >>>>>>>>>> members
> > > > >>>>>>>>>>> in
> > > > >>>>>>>>>>>>> the past.
> > > > >>>>>>>>>>>>> Moreover, it would be hard to track whether somebody
> > became
> > > > >>>>>>>> inactive
> > > > >>>>>>>>>> at
> > > > >>>>>>>>>>>>> some point in time (which we would need to do, if I
> > > > >>>>> understand
> > > > >>>>>>> the
> > > > >>>>>>>>>>>>> proposal
> > > > >>>>>>>>>>>>> correctly).
> > > > >>>>>>>>>>>>> With the approach that Becket suggested in his last
> email
> > > > >>>>>>>> (reaching
> > > > >>>>>>>>>> out
> > > > >>>>>>>>>>> to
> > > > >>>>>>>>>>>>> binding voters who haven't voted yet), we could drop
> the
> > > > >>>>>>>> distinction
> > > > >>>>>>>>>>>>> between active and non-active committers and PMC
> members.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> I also have a few minor comments:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> 1) We should add to the requirements of the PMC [2]
> that
> > > > >>>>> they
> > > > >>>>>>> need
> > > > >>>>>>>>> to
> > > > >>>>>>>>>>> make
> > > > >>>>>>>>>>>>> sure the project complies with brand issues and reports
> > > > >>>>> misuse
> > > > >>>>>>> of
> > > > >>>>>>>>> ASF
> > > > >>>>>>>>>>>>> brands.
> > > > >>>>>>>>>>>>> 2) Do we want to restrict voting days to working days,
> > > i.e.,
> > > > >>>>>> a 3
> > > > >>>>>>>> day
> > > > >>>>>>>>>>> vote
> > > > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday
> 11:00am?
> > > > >>>>>>>>>>>>> 3) Do we need a process do decide about removal of
> > features
> > > > >>>>>>> (like
> > > > >>>>>>>>> the
> > > > >>>>>>>>>>>>> DataSet API for instance or the legacy
> DataSet/DataStream
> > > > >>>>>> Python
> > > > >>>>>>>>>> APIs)?
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Thank you,
> > > > >>>>>>>>>>>>> Fabian
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> [1] https://www.apache.org/theapacheway/
> > > > >>>>>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> > > > >>>>>>>>>>>>> becket.qin@gmail.com
> > > > >>>>>>>>>>>>>> :
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Hi Hequn,
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see the reply
> > > > >>>>>> below:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
> PMC
> > > > >>>>> in
> > > > >>>>>>>> the 3
> > > > >>>>>>>>>>>>> binding
> > > > >>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> > > > >>>>> and 1
> > > > >>>>>>>> PMC.
> > > > >>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> > > > >>>>> somehow
> > > > >>>>>>> be a
> > > > >>>>>>>>> big
> > > > >>>>>>>>>>>>>> feature
> > > > >>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
> > > > >>>>> loss
> > > > >>>>>>> of
> > > > >>>>>>>>>>>>> flexibility
> > > > >>>>>>>>>>>>>>> as committers also have a chance to vote and
> > participate
> > > > >>>>>> in
> > > > >>>>>>>> it.
> > > > >>>>>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs
> are
> > > > >>>>> the
> > > > >>>>>>>>>> following:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> 1. Generally speaking, the PMC's primary
> responsibility
> > is
> > > > >>>>>>>>> operating
> > > > >>>>>>>>>>> the
> > > > >>>>>>>>>>>>>> project and deciding what software to release on
> behalf
> > of
> > > > >>>>>>> ASF.
> > > > >>>>>>>>>>>>> Committers,
> > > > >>>>>>>>>>>>>> on the other hand, are responsible for the technical
> > part
> > > > >>>>> of
> > > > >>>>>>> the
> > > > >>>>>>>>>>>>> project.
> > > > >>>>>>>>>>>>>> So for FLIPs, a PMC's vote probably should not
> outweigh
> > a
> > > > >>>>>>>>>> committer's
> > > > >>>>>>>>>>>>> vote.
> > > > >>>>>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is
> > really
> > > > >>>>>>>>> convincing
> > > > >>>>>>>>>>>>> enough
> > > > >>>>>>>>>>>>>> to decide whether the FLIP is good to go or not. Also,
> > if
> > > > >>>>>> some
> > > > >>>>>>>>>>>>> committers
> > > > >>>>>>>>>>>>>> have concern over a FLIP, they could just veto it. To
> me
> > > > >>>>> it
> > > > >>>>>> is
> > > > >>>>>>>>>>> actually
> > > > >>>>>>>>>>>>> a
> > > > >>>>>>>>>>>>>> more strict requirement to pass a FLIP than asking a
> PMC
> > > > >>>>> to
> > > > >>>>>>>> vote.
> > > > >>>>>>>>> In
> > > > >>>>>>>>>>>>>> practice, people will usually also address the
> concerns
> > > > >>>>> even
> > > > >>>>>>> if
> > > > >>>>>>>>> they
> > > > >>>>>>>>>>> are
> > > > >>>>>>>>>>>>>> not from a PMC/committer before they start the voting
> > > > >>>>>> process.
> > > > >>>>>>>> So
> > > > >>>>>>>>> I
> > > > >>>>>>>>>>>>> don't
> > > > >>>>>>>>>>>>>> see much benefit of requiring a PMC's vote in this
> case.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the
> votes
> > > > >>>>> no
> > > > >>>>>>>> longer
> > > > >>>>>>>>>>>>>> independent. Ideally, a vote is either binding or
> > > > >>>>>> non-binding
> > > > >>>>>>> by
> > > > >>>>>>>>>>>>> itself. If
> > > > >>>>>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
> > > > >>>>> imagine
> > > > >>>>>>>> there
> > > > >>>>>>>>>> have
> > > > >>>>>>>>>>>>> been
> > > > >>>>>>>>>>>>>> 3 committers who voted +1. But the FLIP still has not
> > > > >>>>>> passed,
> > > > >>>>>>> so
> > > > >>>>>>>>>> those
> > > > >>>>>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a
> +1,
> > > > >>>>>> those
> > > > >>>>>>>>> votes
> > > > >>>>>>>>>>>>>> suddenly become binding, which is a little awkward.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable to
> > me.
> > > > >>>>>> Some
> > > > >>>>>>>>>>> thoughts
> > > > >>>>>>>>>>>>> on
> > > > >>>>>>>>>>>>>> this:
> > > > >>>>>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is
> probably
> > > > >>>>>>> because
> > > > >>>>>>>>>> there
> > > > >>>>>>>>>>>>> are
> > > > >>>>>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3
> > majority
> > > > >>>>>>>>>>> prohibitively
> > > > >>>>>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
> > > > >>>>> Flink[2]
> > > > >>>>>>> and
> > > > >>>>>>>> a
> > > > >>>>>>>>>>> quick
> > > > >>>>>>>>>>>>>> search shows at most 6 of them have not sent email in
> > the
> > > > >>>>>>>> recent 6
> > > > >>>>>>>>>>>>> months
> > > > >>>>>>>>>>>>>> or so.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare. It
> > is
> > > > >>>>>>>> designed
> > > > >>>>>>>>>> in
> > > > >>>>>>>>>>>>>> particular for the cases that broad opinions are
> > > > >>>>> important,
> > > > >>>>>>> more
> > > > >>>>>>>>>>>>>> specifically new codebase adoption or modification to
> > the
> > > > >>>>>>>> bylaws.
> > > > >>>>>>>>>>>>> Therefore
> > > > >>>>>>>>>>>>>> such vote by its nature favors consensus over
> > convenience.
> > > > >>>>>>> That
> > > > >>>>>>>>>> means
> > > > >>>>>>>>>>>>> any
> > > > >>>>>>>>>>>>>> alternative voting type reducing the coverage worth a
> > > > >>>>>> careful
> > > > >>>>>>>>>>> thinking.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> 3. I do agree that it does not make sense to have 2/3
> > > > >>>>>> majority
> > > > >>>>>>>> if
> > > > >>>>>>>>>> such
> > > > >>>>>>>>>>>>>> requirement is no-longer doable over time. But I am a
> > > > >>>>> little
> > > > >>>>>>>>>> hesitant
> > > > >>>>>>>>>>> to
> > > > >>>>>>>>>>>>>> lower the threshold to lazy 2/3 majority in our case.
> > What
> > > > >>>>>> do
> > > > >>>>>>>> you
> > > > >>>>>>>>>>> think
> > > > >>>>>>>>>>>>>> about doing the following:
> > > > >>>>>>>>>>>>>>     - After the voting started, there will be at
> least 6
> > > > >>>>>> days
> > > > >>>>>>>> for
> > > > >>>>>>>>>>>>> people to
> > > > >>>>>>>>>>>>>> cast their votes.
> > > > >>>>>>>>>>>>>>     - After 6 days, if the result of the vote is still
> > not
> > > > >>>>>>>>>> determined,
> > > > >>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>> person who started the vote should reach out to the
> > > > >>>>> binding
> > > > >>>>>>>> voters
> > > > >>>>>>>>>> who
> > > > >>>>>>>>>>>>> have
> > > > >>>>>>>>>>>>>> not voted yet for at least 3 times and at least 7 days
> > > > >>>>>> between
> > > > >>>>>>>>> each
> > > > >>>>>>>>>>>>> time.
> > > > >>>>>>>>>>>>>> If a binding voter still did not respond, the vote
> from
> > > > >>>>> that
> > > > >>>>>>>> voter
> > > > >>>>>>>>>>> will
> > > > >>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>> excluded from the 2/3 majority counting.
> > > > >>>>>>>>>>>>>> This would ensure the coverage at our best effort
> while
> > > > >>>>>> still
> > > > >>>>>>>> let
> > > > >>>>>>>>>> the
> > > > >>>>>>>>>>>>> 2/3
> > > > >>>>>>>>>>>>>> majority vote make progress.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> [1] https://projects.apache.org/committee.html?hadoop
> > > > >>>>>>>>>>>>>> [2] https://projects.apache.org/committee.html?flink
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> > > > >>>>>>>>> forwardxu315@gmail.com>
> > > > >>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Big +1 on this.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> best
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> forward
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
> > > > >>>>>> 下午1:30写道：
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Hi Becket,
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Big +1 on this.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> > > > >>>>>>> includes a
> > > > >>>>>>>>> PMC
> > > > >>>>>>>>>>>>> vote.
> > > > >>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
> > > > >>>>> PMC
> > > > >>>>>> in
> > > > >>>>>>>>> the 3
> > > > >>>>>>>>>>>>>> binding
> > > > >>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> > > > >>>>>> and 1
> > > > >>>>>>>>> PMC.
> > > > >>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> > > > >>>>>> somehow
> > > > >>>>>>>> be a
> > > > >>>>>>>>>> big
> > > > >>>>>>>>>>>>>>> feature
> > > > >>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is
> no
> > > > >>>>>> loss
> > > > >>>>>>>> of
> > > > >>>>>>>>>>>>>> flexibility
> > > > >>>>>>>>>>>>>>>> as committers also have a chance to vote and
> > > > >>>>> participate
> > > > >>>>>>> in
> > > > >>>>>>>>> it.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> ========Seperator========
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> For the nice bylaws, I agree with the general idea
> and
> > > > >>>>>>> most
> > > > >>>>>>>> of
> > > > >>>>>>>>>> the
> > > > >>>>>>>>>>>>>>> content.
> > > > >>>>>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority".
> The
> > > > >>>>>>> main
> > > > >>>>>>>>>>> concern
> > > > >>>>>>>>>>>>> is
> > > > >>>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>> am
> > > > >>>>>>>>>>>>>>>> not sure if it is doable in practice. The reasons
> are:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
> > > > >>>>>> committer
> > > > >>>>>>>> or a
> > > > >>>>>>>>>> PMC
> > > > >>>>>>>>>>>>>> member
> > > > >>>>>>>>>>>>>>>> is active if he or she sends one email to the
> mailing
> > > > >>>>>> list
> > > > >>>>>>>>>> every 6
> > > > >>>>>>>>>>>>>>> months.
> > > > >>>>>>>>>>>>>>>> While the minimum length of the vote is only 6 days.
> > > > >>>>>> There
> > > > >>>>>>>> are
> > > > >>>>>>>>>>>>> chances
> > > > >>>>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>>> during the vote, some of the active members are
> still
> > > > >>>>>>>> offline
> > > > >>>>>>>>> of
> > > > >>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>> community.
> > > > >>>>>>>>>>>>>>>> 2. The code of Flink is changing fast and not
> everyone
> > > > >>>>>>> fully
> > > > >>>>>>>>>>>>>> understands
> > > > >>>>>>>>>>>>>>>> every part. We don't need to force people to vote if
> > > > >>>>>> they
> > > > >>>>>>>> are
> > > > >>>>>>>>>> not
> > > > >>>>>>>>>>>>> sure
> > > > >>>>>>>>>>>>>>>> about it. It may also make the final result less
> > > > >>>>>> credible.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Given the above reasons, perhaps we can change the
> 2/3
> > > > >>>>>>>>> Majority
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>>>>> lazy
> > > > >>>>>>>>>>>>>>> 2/3
> > > > >>>>>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
> > > > >>>>>> higher
> > > > >>>>>>>>>>> threshold,
> > > > >>>>>>>>>>>>>>>> however, more practical.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> What do you think?
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> > > > >>>>>>>>>> becket.qin@gmail.com
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Hi Jincheng,
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki
> page.
> > > > >>>>>>> Just
> > > > >>>>>>>> a
> > > > >>>>>>>>>>> brief
> > > > >>>>>>>>>>>>>>>> summary,
> > > > >>>>>>>>>>>>>>>>> the current bylaws do require some of the FLIPs to
> > > > >>>>> get
> > > > >>>>>>> PMC
> > > > >>>>>>>>>>>>> approval
> > > > >>>>>>>>>>>>>> if
> > > > >>>>>>>>>>>>>>>>> their impact is big enough. But it leaves majority
> > > > >>>>> of
> > > > >>>>>>> the
> > > > >>>>>>>>>>>>> technical
> > > > >>>>>>>>>>>>>>>>> decisions to the committers who are supposed to be
> > > > >>>>>>>>> responsible
> > > > >>>>>>>>>>> for
> > > > >>>>>>>>>>>>>>> making
> > > > >>>>>>>>>>>>>>>>> such decisions.
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Re: Robert,
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> I agree we can simply remove the requirement of +1
> > > > >>>>>> from
> > > > >>>>>>> a
> > > > >>>>>>>>>>>>> non-author
> > > > >>>>>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
> > > > >>>>> does
> > > > >>>>>>> not
> > > > >>>>>>>>> make
> > > > >>>>>>>>>>>>> sense
> > > > >>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
> > > > >>>>>> updated
> > > > >>>>>>>> the
> > > > >>>>>>>>>>> bylaws
> > > > >>>>>>>>>>>>>>> wiki.
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> > > > >>>>>>>>>>>>> rmetzger@apache.org
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Hi all,
> > > > >>>>>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
> > > > >>>>>>> current
> > > > >>>>>>>>>>> status
> > > > >>>>>>>>>>>>> in
> > > > >>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
> > > > >>>>> is
> > > > >>>>>> a
> > > > >>>>>>>> very
> > > > >>>>>>>>>>>>> involved
> > > > >>>>>>>>>>>>>>>> task.
> > > > >>>>>>>>>>>>>>>>>> Unless there's somebody who's really eager to
> > > > >>>>> drive
> > > > >>>>>>>> this,
> > > > >>>>>>>>> I
> > > > >>>>>>>>>>>>> would
> > > > >>>>>>>>>>>>>>> stick
> > > > >>>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
> > > > >>>>>> Flink,
> > > > >>>>>>>> even
> > > > >>>>>>>>>> if
> > > > >>>>>>>>>>>>> this
> > > > >>>>>>>>>>>>>>>> means
> > > > >>>>>>>>>>>>>>>>>> some changes.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> The cross-review requirement is the last big open
> > > > >>>>>>> point
> > > > >>>>>>>> in
> > > > >>>>>>>>>>> this
> > > > >>>>>>>>>>>>>>>>> discussion.
> > > > >>>>>>>>>>>>>>>>>> It seems that a there is a slight tendency in the
> > > > >>>>>>>>> discussion
> > > > >>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>> this
> > > > >>>>>>>>>>>>>>>> is
> > > > >>>>>>>>>>>>>>>>>> not feasible given the current pull request review
> > > > >>>>>>>>>> situation.
> > > > >>>>>>>>>>>>>>>>>> For the sake of bringing this discussion to a
> > > > >>>>>>>> conclusion,
> > > > >>>>>>>>>> I'm
> > > > >>>>>>>>>>>>> fine
> > > > >>>>>>>>>>>>>>> with
> > > > >>>>>>>>>>>>>>>>>> leaving this requirement out. As we are currently
> > > > >>>>>>> adding
> > > > >>>>>>>>>> more
> > > > >>>>>>>>>>>>>>>> committers
> > > > >>>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>> the project, we might be able to revisit this
> > > > >>>>>>> discussion
> > > > >>>>>>>>> in
> > > > >>>>>>>>>> 3
> > > > >>>>>>>>>>> -
> > > > >>>>>>>>>>>>> 6
> > > > >>>>>>>>>>>>>>>> months.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> > > > >>>>>>>>>>>>>>> sunjincheng121@gmail.com
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> Hi Becket,
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> Thanks for the proposal.
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> > > > >>>>>>>>> includes a
> > > > >>>>>>>>>>> PMC
> > > > >>>>>>>>>>>>>>> vote.
> > > > >>>>>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
> > > > >>>>>> the
> > > > >>>>>>>>> user's
> > > > >>>>>>>>>>>>>>> interface
> > > > >>>>>>>>>>>>>>>>>>> changes. What do you think? (I leave the comment
> > > > >>>>>> in
> > > > >>>>>>>> the
> > > > >>>>>>>>>>> wiki.)
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> Best,
> > > > >>>>>>>>>>>>>>>>>>> Jincheng
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
> > > > >>>>>>>> 于2019年7月17日周三
> > > > >>>>>>>>>>>>>> 下午9:12写道：
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> Hi all,
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
> > > > >>>>>> that
> > > > >>>>>>> I
> > > > >>>>>>>>>> really
> > > > >>>>>>>>>>>>> like
> > > > >>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> proposed bylaws!
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
> > > > >>>>>>>>> expressed
> > > > >>>>>>>>>> by
> > > > >>>>>>>>>>>>> few
> > > > >>>>>>>>>>>>>>>> people
> > > > >>>>>>>>>>>>>>>>>>>> before that the "committer +1" on code change
> > > > >>>>>>> might
> > > > >>>>>>>> be
> > > > >>>>>>>>>>> hard
> > > > >>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>> achieve
> > > > >>>>>>>>>>>>>>>>>>>> currently. On the other hand I would say this
> > > > >>>>>>> would
> > > > >>>>>>>> be
> > > > >>>>>>>>>>>>>> beneficial
> > > > >>>>>>>>>>>>>>>> for
> > > > >>>>>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
> > > > >>>>>>> knowledge
> > > > >>>>>>>>>>>>> sharing.
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> I was just wondering what should be the next
> > > > >>>>>> step
> > > > >>>>>>>> for
> > > > >>>>>>>>>>> this?
> > > > >>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>> think
> > > > >>>>>>>>>>>>>>>>> it
> > > > >>>>>>>>>>>>>>>>>>>> would make sense to already use those bylaws
> > > > >>>>> and
> > > > >>>>>>> put
> > > > >>>>>>>>>> them
> > > > >>>>>>>>>>> to
> > > > >>>>>>>>>>>>>> PMC
> > > > >>>>>>>>>>>>>>>>> vote.
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> Best,
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> Dawid
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > >>>>>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
> > > > >>>>> think.
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> > > > >>>>>> If
> > > > >>>>>>> we
> > > > >>>>>>>>> are
> > > > >>>>>>>>>>>>>> stating
> > > > >>>>>>>>>>>>>>>>> that a
> > > > >>>>>>>>>>>>>>>>>>>> single
> > > > >>>>>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
> > > > >>>>>> review,
> > > > >>>>>>>>> with 0
> > > > >>>>>>>>>>>>> hours
> > > > >>>>>>>>>>>>>>>> delay
> > > > >>>>>>>>>>>>>>>>>> (de
> > > > >>>>>>>>>>>>>>>>>>>> facto
> > > > >>>>>>>>>>>>>>>>>>>>>>> the current state), we should also write
> > > > >>>>>> down
> > > > >>>>>>>> that
> > > > >>>>>>>>>>> this
> > > > >>>>>>>>>>>>> is
> > > > >>>>>>>>>>>>>>>>> subject
> > > > >>>>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
> > > > >>>>>> the
> > > > >>>>>>>>>>>>> components
> > > > >>>>>>>>>>>>>>>>> expertise
> > > > >>>>>>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
> > > > >>>>> facto
> > > > >>>>>>>>> current
> > > > >>>>>>>>>>>>>> state).
> > > > >>>>>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
> > > > >>>>>>>>>> intention,
> > > > >>>>>>>>>>>>> but
> > > > >>>>>>>>>>>>>> it
> > > > >>>>>>>>>>>>>>>> may
> > > > >>>>>>>>>>>>>>>>>> be a
> > > > >>>>>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
> > > > >>>>>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
> > > > >>>>>>> rule
> > > > >>>>>>>>>>> anyway,
> > > > >>>>>>>>>>>>>>>> intended
> > > > >>>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
> > > > >>>>>> to
> > > > >>>>>>>> just
> > > > >>>>>>>>>>>>> avoid a
> > > > >>>>>>>>>>>>>>>>>> situation
> > > > >>>>>>>>>>>>>>>>>>>> when someone violates current uncodified state
> > > > >>>>>> and
> > > > >>>>>>>>>> refers
> > > > >>>>>>>>>>> to
> > > > >>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>> bylaws
> > > > >>>>>>>>>>>>>>>>>>>> which are saying merging with any committer +1
> > > > >>>>>> is
> > > > >>>>>>>>> always
> > > > >>>>>>>>>>>>> fine
> > > > >>>>>>>>>>>>>>> (like
> > > > >>>>>>>>>>>>>>>>>> mine
> > > > >>>>>>>>>>>>>>>>>>> +1
> > > > >>>>>>>>>>>>>>>>>>>> for flink-python or flink-ml).
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>> Piotrek
> > > > >>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
> > > > >>>>> <
> > > > >>>>>>>>>>>>>>> aljoscha@apache.org
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
> > > > >>>>>> FLIP.
> > > > >>>>>>>>> This
> > > > >>>>>>>>>> is
> > > > >>>>>>>>>>>>> just
> > > > >>>>>>>>>>>>>>>> about
> > > > >>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> voting, before that there needs to be the
> > > > >>>>>>> discussion
> > > > >>>>>>>>>>>>> thread. If
> > > > >>>>>>>>>>>>>>>> three
> > > > >>>>>>>>>>>>>>>>>>> days
> > > > >>>>>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
> > > > >>>>>>> (i.e. 3
> > > > >>>>>>>>>>>>>>>> committers/PMCs
> > > > >>>>>>>>>>>>>>>>>> have
> > > > >>>>>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
> > > > >>>>>> So
> > > > >>>>>>>> far,
> > > > >>>>>>>>>> we
> > > > >>>>>>>>>>>>> have
> > > > >>>>>>>>>>>>>>>> rarely
> > > > >>>>>>>>>>>>>>>>>> see
> > > > >>>>>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
> > > > >>>>> we
> > > > >>>>>>> want
> > > > >>>>>>>>> to
> > > > >>>>>>>>>>> use
> > > > >>>>>>>>>>>>>> "lazy
> > > > >>>>>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
> > > > >>>>>>> that
> > > > >>>>>>>>>> should
> > > > >>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>>> changed
> > > > >>>>>>>>>>>>>>>>>>> from
> > > > >>>>>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
> > > > >>>>>>> current
> > > > >>>>>>>>>> state
> > > > >>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>> we
> > > > >>>>>>>>>>>>>>>>> all
> > > > >>>>>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
> > > > >>>>>>> come
> > > > >>>>>>>> up
> > > > >>>>>>>>>>> with
> > > > >>>>>>>>>>>>>>>> something
> > > > >>>>>>>>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>>>>>>> reflects the common state, according to
> > > > >>>>>>>>> PMCs/commiters,
> > > > >>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>> might
> > > > >>>>>>>>>>>>>>>>>> take a
> > > > >>>>>>>>>>>>>>>>>>>> very long time. In that case I think it’s
> > > > >>>>> better
> > > > >>>>>>> to
> > > > >>>>>>>>>> adopt
> > > > >>>>>>>>>>>>>>> something
> > > > >>>>>>>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>>>>>> we
> > > > >>>>>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
> > > > >>>>>> do
> > > > >>>>>>> it
> > > > >>>>>>>>>> now.
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>> Aljoscha
> > > > >>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
> > > > >>>>> <
> > > > >>>>>>>>>>>>>>> piotr@ververica.com
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> Hi,
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
> > > > >>>>> speaking
> > > > >>>>>> +1
> > > > >>>>>>>>> from
> > > > >>>>>>>>>> my
> > > > >>>>>>>>>>>>> side
> > > > >>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> general idea and most of the content. I also
> > > > >>>>> see
> > > > >>>>>>>> merit
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>> Chesney's
> > > > >>>>>>>>>>>>>>>>>>>> proposal to start from the current state. I
> > > > >>>>>> think
> > > > >>>>>>>>> either
> > > > >>>>>>>>>>>>> would
> > > > >>>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>>>> fine
> > > > >>>>>>>>>>>>>>>>>>> for
> > > > >>>>>>>>>>>>>>>>>>>> me.
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> Couple of comments:
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> 1.
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
> > > > >>>>> another
> > > > >>>>>>>>>> committer
> > > > >>>>>>>>>>>>> would
> > > > >>>>>>>>>>>>>>>> slow
> > > > >>>>>>>>>>>>>>>>>> down
> > > > >>>>>>>>>>>>>>>>>>>> and put even more strain on the current
> > > > >>>>>> reviewing
> > > > >>>>>>>>>>> bottleneck
> > > > >>>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>>> we
> > > > >>>>>>>>>>>>>>>>>> are
> > > > >>>>>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
> > > > >>>>>>> context
> > > > >>>>>>>>>>> switch
> > > > >>>>>>>>>>>>>> cost
> > > > >>>>>>>>>>>>>>> is
> > > > >>>>>>>>>>>>>>>>>> quite
> > > > >>>>>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
> > > > >>>>>> second
> > > > >>>>>>>>>> “cross”
> > > > >>>>>>>>>>>>>>> committer
> > > > >>>>>>>>>>>>>>>>>> could
> > > > >>>>>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
> > > > >>>>>>> Besides,
> > > > >>>>>>>>>>> current
> > > > >>>>>>>>>>>>>> setup
> > > > >>>>>>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>>>>> we
> > > > >>>>>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
> > > > >>>>>>>>> required)
> > > > >>>>>>>>>>>>> works
> > > > >>>>>>>>>>>>>>> quite
> > > > >>>>>>>>>>>>>>>>>> well
> > > > >>>>>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
> > > > >>>>>> the
> > > > >>>>>>>>> other
> > > > >>>>>>>>>>> hand
> > > > >>>>>>>>>>>>>>>>> reviewing
> > > > >>>>>>>>>>>>>>>>>>>> bottleneck is.
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> 2.
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
> > > > >>>>> ask
> > > > >>>>>>>>> another
> > > > >>>>>>>>>>>>>>> committer
> > > > >>>>>>>>>>>>>>>>> for
> > > > >>>>>>>>>>>>>>>>>>>> feedback or not.
> > > > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> > > > >>>>>> If
> > > > >>>>>>> we
> > > > >>>>>>>>> are
> > > > >>>>>>>>>>>>>> stating
> > > > >>>>>>>>>>>>>>>>> that a
> > > > >>>>>>>>>>>>>>>>>>>> single committers +1 is good enough for code
> > > > >>>>>>> review,
> > > > >>>>>>>>>> with
> > > > >>>>>>>>>>> 0
> > > > >>>>>>>>>>>>>> hours
> > > > >>>>>>>>>>>>>>>>> delay
> > > > >>>>>>>>>>>>>>>>>>> (de
> > > > >>>>>>>>>>>>>>>>>>>> facto the current state), we should also write
> > > > >>>>>>> down
> > > > >>>>>>>>> that
> > > > >>>>>>>>>>>>> this
> > > > >>>>>>>>>>>>>> is
> > > > >>>>>>>>>>>>>>>>>> subject
> > > > >>>>>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>>> the best judgement of the committer to respect
> > > > >>>>>> the
> > > > >>>>>>>>>>>>> components
> > > > >>>>>>>>>>>>>>>>> expertise
> > > > >>>>>>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
> > > > >>>>>>> current
> > > > >>>>>>>>>>> state).
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> 3.
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
> > > > >>>>>>>>> currently
> > > > >>>>>>>>>>>>> might
> > > > >>>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
> > > > >>>>>> if
> > > > >>>>>>>>>>> respected
> > > > >>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>> letter.
> > > > >>>>>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
> > > > >>>>>>>>>> committers
> > > > >>>>>>>>>>>>> with
> > > > >>>>>>>>>>>>>>>>> highest
> > > > >>>>>>>>>>>>>>>>>>>> expertise in the affected components managed
> > > > >>>>> to
> > > > >>>>>>>>> respond
> > > > >>>>>>>>>> or
> > > > >>>>>>>>>>>>> not.
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>> Piotrek
> > > > >>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
> > > > >>>>> Schepler
> > > > >>>>>> <
> > > > >>>>>>>>>>>>>>>> chesnay@apache.org>
> > > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
> > > > >>>>>>> write
> > > > >>>>>>>>> down
> > > > >>>>>>>>>>>>> Bylaws
> > > > >>>>>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>>>>>>> reflect the current state, and then have
> > > > >>>>>> separate
> > > > >>>>>>>>>>>>> discussions
> > > > >>>>>>>>>>>>>> for
> > > > >>>>>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
> > > > >>>>>> this
> > > > >>>>>>>>>>>>> discussion
> > > > >>>>>>>>>>>>>>> will
> > > > >>>>>>>>>>>>>>>>>>> quickly
> > > > >>>>>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
> > > > >>>>>>>>> discussed
> > > > >>>>>>>>>>> at
> > > > >>>>>>>>>>>>>> once.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
> > > > >>>>>> Qin
> > > > >>>>>>> <
> > > > >>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> > > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
> > > > >>>>> and
> > > > >>>>>>>>>> feedback.
> > > > >>>>>>>>>>>>>> Please
> > > > >>>>>>>>>>>>>>>> see
> > > > >>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> replies
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> below:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> > > > >>>>> Change"
> > > > >>>>>> we
> > > > >>>>>>>>> could
> > > > >>>>>>>>>>>>> also
> > > > >>>>>>>>>>>>>>> add a
> > > > >>>>>>>>>>>>>>>>> row
> > > > >>>>>>>>>>>>>>>>>>>> for "Code
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> > > > >>>>>> reference
> > > > >>>>>>> to
> > > > >>>>>>>>> the
> > > > >>>>>>>>>>>>> FLIP
> > > > >>>>>>>>>>>>>>>> process
> > > > >>>>>>>>>>>>>>>>>>>> page. A
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
> > > > >>>>> for
> > > > >>>>>>>>>> approvals,
> > > > >>>>>>>>>>>>> etc.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> > > > >>>>> currently
> > > > >>>>>>>>> requires
> > > > >>>>>>>>>>>>> "one
> > > > >>>>>>>>>>>>>> +1
> > > > >>>>>>>>>>>>>>>>> from a
> > > > >>>>>>>>>>>>>>>>>>>> committer
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> > > > >>>>> followed
> > > > >>>>>>> by a
> > > > >>>>>>>>>> Lazy
> > > > >>>>>>>>>>>>>>> approval
> > > > >>>>>>>>>>>>>>>>> (not
> > > > >>>>>>>>>>>>>>>>>>>> counting
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
> > > > >>>>> to
> > > > >>>>>>> lazy
> > > > >>>>>>>>>>>>> majority
> > > > >>>>>>>>>>>>>> if
> > > > >>>>>>>>>>>>>>> a
> > > > >>>>>>>>>>>>>>>> -1
> > > > >>>>>>>>>>>>>>>>>> is
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> received".
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
> > > > >>>>>>>>> committer
> > > > >>>>>>>>>>>>> always
> > > > >>>>>>>>>>>>>>>>> needs a
> > > > >>>>>>>>>>>>>>>>>>>> review
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
> > > > >>>>>>> know
> > > > >>>>>>>>> this
> > > > >>>>>>>>>>> is
> > > > >>>>>>>>>>>>>>>> currently
> > > > >>>>>>>>>>>>>>>>>> not
> > > > >>>>>>>>>>>>>>>>>>>> always
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > > > >>>>>>>> contributor
> > > > >>>>>>>>>>>>> reviews
> > > > >>>>>>>>>>>>>> &
> > > > >>>>>>>>>>>>>>>>> +1s).
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
> > > > >>>>> we
> > > > >>>>>>> can
> > > > >>>>>>>>>> make
> > > > >>>>>>>>>>> it
> > > > >>>>>>>>>>>>>> easy
> > > > >>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>>> follow the
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> > > > >>>>>> Flink-specific
> > > > >>>>>>>> Jira
> > > > >>>>>>>>>>>>>> workflows
> > > > >>>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>> ticket
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> types +
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
> > > > >>>>> is
> > > > >>>>>>>>>> certainly
> > > > >>>>>>>>>>>>>> "Step
> > > > >>>>>>>>>>>>>>>> 2",
> > > > >>>>>>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>>>>>>> believe,
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> we
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> > > > >>>>>>> transparent
> > > > >>>>>>>>> as
> > > > >>>>>>>>>>>>>> possible,
> > > > >>>>>>>>>>>>>>>>>>>> otherwise they
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> & Re: Till
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> > > > >>>>>>> author
> > > > >>>>>>>>> and
> > > > >>>>>>>>>>>>>> getting
> > > > >>>>>>>>>>>>>>> a
> > > > >>>>>>>>>>>>>>>> +1
> > > > >>>>>>>>>>>>>>>>>>> from
> > > > >>>>>>>>>>>>>>>>>>>> a
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> > > > >>>>>> should
> > > > >>>>>>>> know
> > > > >>>>>>>>>>> when
> > > > >>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>> ask
> > > > >>>>>>>>>>>>>>>>>>> another
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
> > > > >>>>> I
> > > > >>>>>>>> would
> > > > >>>>>>>>>> not
> > > > >>>>>>>>>>>>>> enforce
> > > > >>>>>>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>>>>> we
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> > > > >>>>> author
> > > > >>>>>>> is
> > > > >>>>>>>> a
> > > > >>>>>>>>>>>>> committer
> > > > >>>>>>>>>>>>>>> but
> > > > >>>>>>>>>>>>>>>>> of
> > > > >>>>>>>>>>>>>>>>>>>> course
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
> > > > >>>>> here.
> > > > >>>>>>>> TBH,
> > > > >>>>>>>>> in
> > > > >>>>>>>>>>>>> Kafka
> > > > >>>>>>>>>>>>>>>>>>> occasionally
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
> > > > >>>>> still
> > > > >>>>>>>>> merged
> > > > >>>>>>>>>>>>> without
> > > > >>>>>>>>>>>>>>>>>> following
> > > > >>>>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
> > > > >>>>> rare.
> > > > >>>>>>>> That
> > > > >>>>>>>>>>> said,
> > > > >>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>> still
> > > > >>>>>>>>>>>>>>>>>> think
> > > > >>>>>>>>>>>>>>>>>>>> an
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
> > > > >>>>> sense
> > > > >>>>>>> due
> > > > >>>>>>>>> to
> > > > >>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>> following
> > > > >>>>>>>>>>>>>>>>>>>> reasons:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
> > > > >>>>>> to
> > > > >>>>>>>> make
> > > > >>>>>>>>>>> sure
> > > > >>>>>>>>>>>>>> every
> > > > >>>>>>>>>>>>>>>>> patch
> > > > >>>>>>>>>>>>>>>>>>> is
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
> > > > >>>>>>>> little
> > > > >>>>>>>>>>>>> difficult
> > > > >>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>>> guarantee if
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
> > > > >>>>>>> many
> > > > >>>>>>>>>>>>> reasons. In
> > > > >>>>>>>>>>>>>>>> some
> > > > >>>>>>>>>>>>>>>>>>>> cases, a
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
> > > > >>>>> knowledge
> > > > >>>>>>>> about
> > > > >>>>>>>>>> the
> > > > >>>>>>>>>>>>>>> project
> > > > >>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>> make
> > > > >>>>>>>>>>>>>>>>>>>> a good
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
> > > > >>>>>> contributors
> > > > >>>>>>>> are
> > > > >>>>>>>>>> more
> > > > >>>>>>>>>>>>>>> eagerly
> > > > >>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>> get a
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
> > > > >>>>>> willing
> > > > >>>>>>>> to
> > > > >>>>>>>>>>> lower
> > > > >>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>> review
> > > > >>>>>>>>>>>>>>>>>>> bar.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
> > > > >>>>>> among
> > > > >>>>>>>>>>>>> committers,
> > > > >>>>>>>>>>>>>>>> which
> > > > >>>>>>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>>>>>>> personally
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
> > > > >>>>>>> form
> > > > >>>>>>>>>>>>> consistent
> > > > >>>>>>>>>>>>>>>> design
> > > > >>>>>>>>>>>>>>>>>>>> principles
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
> > > > >>>>>>>> committers
> > > > >>>>>>>>>> will
> > > > >>>>>>>>>>>>> know
> > > > >>>>>>>>>>>>>>> how
> > > > >>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> other
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
> > > > >>>>>> from
> > > > >>>>>>>> each
> > > > >>>>>>>>>>>>> other.
> > > > >>>>>>>>>>>>>> So
> > > > >>>>>>>>>>>>>>>> they
> > > > >>>>>>>>>>>>>>>>>>> tend
> > > > >>>>>>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
> > > > >>>>>>> things
> > > > >>>>>>>>>> should
> > > > >>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>> done
> > > > >>>>>>>>>>>>>>>> in
> > > > >>>>>>>>>>>>>>>>>>>> general.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
> > > > >>>>>>>> consider
> > > > >>>>>>>>>> the
> > > > >>>>>>>>>>>>>>> following
> > > > >>>>>>>>>>>>>>>>> two
> > > > >>>>>>>>>>>>>>>>>>>> scenarios:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
> > > > >>>>> a
> > > > >>>>>>> lot
> > > > >>>>>>>> of
> > > > >>>>>>>>>>>>>>> iterations.
> > > > >>>>>>>>>>>>>>>>> Then
> > > > >>>>>>>>>>>>>>>>>>>> the patch
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
> > > > >>>>>> time
> > > > >>>>>>>>>> because
> > > > >>>>>>>>>>>>> there
> > > > >>>>>>>>>>>>>>> are
> > > > >>>>>>>>>>>>>>>>>>> things
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
> > > > >>>>> changed.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
> > > > >>>>> very
> > > > >>>>>>>> smooth
> > > > >>>>>>>>>> and
> > > > >>>>>>>>>>>>>> quick,
> > > > >>>>>>>>>>>>>>>> so
> > > > >>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> patch is
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
> > > > >>>>> patch
> > > > >>>>>>> does
> > > > >>>>>>>>> not
> > > > >>>>>>>>>>>>> take
> > > > >>>>>>>>>>>>>>> much
> > > > >>>>>>>>>>>>>>>>>> time.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
> > > > >>>>>> patch
> > > > >>>>>>>>> from a
> > > > >>>>>>>>>>>>>>> committer
> > > > >>>>>>>>>>>>>>>>>> falls
> > > > >>>>>>>>>>>>>>>>>>>> either in
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
> > > > >>>>> is
> > > > >>>>>>> to
> > > > >>>>>>>>>> review
> > > > >>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>> patch
> > > > >>>>>>>>>>>>>>>>>>>> because
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
> > > > >>>>> needs
> > > > >>>>>>> to
> > > > >>>>>>>> be
> > > > >>>>>>>>>>>>>> reviewed.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
> > > > >>>>>> take
> > > > >>>>>>>>> much
> > > > >>>>>>>>>>> time
> > > > >>>>>>>>>>>>>>>> anyways.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
> > > > >>>>>>> case
> > > > >>>>>>>> 1
> > > > >>>>>>>>> if
> > > > >>>>>>>>>>> we
> > > > >>>>>>>>>>>>>> skip
> > > > >>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> cross-review.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Robert
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
> > > > >>>>>> and
> > > > >>>>>>>> made
> > > > >>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>> following
> > > > >>>>>>>>>>>>>>>>>>>> modifications
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
> > > > >>>>> section.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
> > > > >>>>>> to
> > > > >>>>>>>>>>>>> "consensus"
> > > > >>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>> align
> > > > >>>>>>>>>>>>>>>>>>> with
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
> > > > >>>>> and
> > > > >>>>>>>> other
> > > > >>>>>>>>>>>>>> projects.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> > > > >>>>> unnecessary
> > > > >>>>>>>>> noise.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
> > > > >>>>>> 2/3
> > > > >>>>>>>>>>> majority
> > > > >>>>>>>>>>>>> is
> > > > >>>>>>>>>>>>>>>> still
> > > > >>>>>>>>>>>>>>>>>>>> feasible in
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> practice.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> > > > >>>>> the
> > > > >>>>>>>> draft
> > > > >>>>>>>>>>>>> compared
> > > > >>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>> existing
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
> > > > >>>>>>>>> highlight
> > > > >>>>>>>>>>>>> these
> > > > >>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>> discuss
> > > > >>>>>>>>>>>>>>>>>>>> them
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
> > > > >>>>>>> familiar
> > > > >>>>>>>>>> enough
> > > > >>>>>>>>>>>>> with
> > > > >>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>> current Flink
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
> > > > >>>>> saw
> > > > >>>>>>> you
> > > > >>>>>>>>>>>>> commented
> > > > >>>>>>>>>>>>>> on
> > > > >>>>>>>>>>>>>>>> some
> > > > >>>>>>>>>>>>>>>>>>> part
> > > > >>>>>>>>>>>>>>>>>>>> in the
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> > > > >>>>>>> bylaws?
> > > > >>>>>>>>> I’m
> > > > >>>>>>>>>>>>> asking
> > > > >>>>>>>>>>>>>>>>> because
> > > > >>>>>>>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>>>>>>> quite
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> > > > >>>>> essentially
> > > > >>>>>>>>> adopting
> > > > >>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>> Kafka
> > > > >>>>>>>>>>>>>>>>>>> bylaws.
> > > > >>>>>>>>>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> > > > >>>>>> try
> > > > >>>>>>>> to
> > > > >>>>>>>>>>>>> re-invent
> > > > >>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>> wheel
> > > > >>>>>>>>>>>>>>>>>>>> here.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
> > > > >>>>> version
> > > > >>>>>>> of
> > > > >>>>>>>>> the
> > > > >>>>>>>>>>>>> draft
> > > > >>>>>>>>>>>>>> was
> > > > >>>>>>>>>>>>>>>>>> almost
> > > > >>>>>>>>>>>>>>>>>>>> identical
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
> > > > >>>>> caught a
> > > > >>>>>>> few
> > > > >>>>>>>>>>>>>> inconsistent
> > > > >>>>>>>>>>>>>>>>>> places.
> > > > >>>>>>>>>>>>>>>>>>>> So it
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
> > > > >>>>>> make
> > > > >>>>>>>> sure
> > > > >>>>>>>>>> we
> > > > >>>>>>>>>>>>> truly
> > > > >>>>>>>>>>>>>>>> agree
> > > > >>>>>>>>>>>>>>>>>> on
> > > > >>>>>>>>>>>>>>>>>>>> them.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
> > > > >>>>>>>> shortly
> > > > >>>>>>>>>>> after
> > > > >>>>>>>>>>>>>>>> adoption.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
> > > > >>>>> valuable
> > > > >>>>>>>>>> feedback.
> > > > >>>>>>>>>>>>> These
> > > > >>>>>>>>>>>>>>> are
> > > > >>>>>>>>>>>>>>>>>> great
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> discussion.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
> > > > >>>>> Aljoscha
> > > > >>>>>>>>> Krettek
> > > > >>>>>>>>>> <
> > > > >>>>>>>>>>>>>>>>>>>> aljoscha@apache.org>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Big +1
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> > > > >>>>>>> bylaws?
> > > > >>>>>>>>> I’m
> > > > >>>>>>>>>>>>> asking
> > > > >>>>>>>>>>>>>>>>>> because I
> > > > >>>>>>>>>>>>>>>>>>>> quite
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> > > > >>>>> essentially
> > > > >>>>>>>>> adopting
> > > > >>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>> Kafka
> > > > >>>>>>>>>>>>>>>>>>> bylaws.
> > > > >>>>>>>>>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> > > > >>>>>> try
> > > > >>>>>>>> to
> > > > >>>>>>>>>>>>> re-invent
> > > > >>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>> wheel
> > > > >>>>>>>>>>>>>>>>>>>> here.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
> > > > >>>>>>>>>> “committer
> > > > >>>>>>>>>>>>> +1”
> > > > >>>>>>>>>>>>>>>>>>> requirement.
> > > > >>>>>>>>>>>>>>>>>>>> We
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
> > > > >>>>> would
> > > > >>>>>>>>> actually
> > > > >>>>>>>>>>> be
> > > > >>>>>>>>>>>>> in
> > > > >>>>>>>>>>>>>>>> favour
> > > > >>>>>>>>>>>>>>>>>> of
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> requiring
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
> > > > >>>>>>>>>> complicated.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
> > > > >>>>>> Rohrmann
> > > > >>>>>>> <
> > > > >>>>>>>>>>>>>>>>>> trohrmann@apache.org>
> > > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
> > > > >>>>>>>> Becket.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
> > > > >>>>> emeritus
> > > > >>>>>>> (or
> > > > >>>>>>>>>> active
> > > > >>>>>>>>>>>>> vs.
> > > > >>>>>>>>>>>>>>>>>> inactive),
> > > > >>>>>>>>>>>>>>>>>>>> it
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> won't
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
> > > > >>>>> vote
> > > > >>>>>>>>> because
> > > > >>>>>>>>>>> we
> > > > >>>>>>>>>>>>>>> already
> > > > >>>>>>>>>>>>>>>>>> have
> > > > >>>>>>>>>>>>>>>>>>>> too
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> many
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> > > > >>>>>>>> author
> > > > >>>>>>>>>> and
> > > > >>>>>>>>>>>>>>> getting a
> > > > >>>>>>>>>>>>>>>>> +1
> > > > >>>>>>>>>>>>>>>>>>>> from a
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> > > > >>>>>> should
> > > > >>>>>>>>> know
> > > > >>>>>>>>>>>>> when to
> > > > >>>>>>>>>>>>>>> ask
> > > > >>>>>>>>>>>>>>>>>>> another
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
> > > > >>>>> Hence, I
> > > > >>>>>>>> would
> > > > >>>>>>>>>> not
> > > > >>>>>>>>>>>>>>> enforce
> > > > >>>>>>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>>>>>>> we
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> > > > >>>>>> author
> > > > >>>>>>>> is a
> > > > >>>>>>>>>>>>>> committer
> > > > >>>>>>>>>>>>>>>> but
> > > > >>>>>>>>>>>>>>>>> of
> > > > >>>>>>>>>>>>>>>>>>>> course
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Till
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
> > > > >>>>> Chesnay
> > > > >>>>>>>>>> Schepler
> > > > >>>>>>>>>>> <
> > > > >>>>>>>>>>>>>>>>>>>> chesnay@apache.org>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> > > > >>>>>>> unnecessary
> > > > >>>>>>>>>> noise.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> > > > >>>>>> the
> > > > >>>>>>>>> draft
> > > > >>>>>>>>>>>>>> compared
> > > > >>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>>> existing
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
> > > > >>>>> to
> > > > >>>>>>>>>> highlight
> > > > >>>>>>>>>>>>>> these
> > > > >>>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>>> discuss
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> them
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
> > > > >>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
> > > > >>>>> this
> > > > >>>>>>>>>>> discussion
> > > > >>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>> creating
> > > > >>>>>>>>>>>>>>>>>>> a
> > > > >>>>>>>>>>>>>>>>>>>> draft
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> in
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> > > > >>>>> that
> > > > >>>>>> a
> > > > >>>>>>>>>>> committer
> > > > >>>>>>>>>>>>>>> always
> > > > >>>>>>>>>>>>>>>>>> needs
> > > > >>>>>>>>>>>>>>>>>>> a
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> review
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> > > > >>>>>> as I
> > > > >>>>>>>>> know
> > > > >>>>>>>>>>>>> this is
> > > > >>>>>>>>>>>>>>>>>> currently
> > > > >>>>>>>>>>>>>>>>>>>> not
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > > > >>>>>>>>>> contributor
> > > > >>>>>>>>>>>>>>> reviews
> > > > >>>>>>>>>>>>>>>> &
> > > > >>>>>>>>>>>>>>>>>>> +1s).
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
> > > > >>>>> if
> > > > >>>>>>> we
> > > > >>>>>>>>> had
> > > > >>>>>>>>>>>>> cases
> > > > >>>>>>>>>>>>>> in
> > > > >>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>> past
> > > > >>>>>>>>>>>>>>>>>>>> where
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> code
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
> > > > >>>>> we
> > > > >>>>>>>>> believe
> > > > >>>>>>>>>>>>> that we
> > > > >>>>>>>>>>>>>>>> have
> > > > >>>>>>>>>>>>>>>>>>> enough
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> capacity
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
> > > > >>>>>>>> approval.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> > > > >>>>>>>> Konstantin
> > > > >>>>>>>>>>> Knauf
> > > > >>>>>>>>>>>>> <
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
> > > > >>>>>>> Becket. I
> > > > >>>>>>>>>> have
> > > > >>>>>>>>>>>>> two
> > > > >>>>>>>>>>>>>>>> remarks
> > > > >>>>>>>>>>>>>>>>>>>> regarding
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> > > > >>>>>>> Change"
> > > > >>>>>>>> we
> > > > >>>>>>>>>>> could
> > > > >>>>>>>>>>>>>> also
> > > > >>>>>>>>>>>>>>>>> add a
> > > > >>>>>>>>>>>>>>>>>>>> row for
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Code
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> > > > >>>>>>>> reference
> > > > >>>>>>>>> to
> > > > >>>>>>>>>>> the
> > > > >>>>>>>>>>>>>> FLIP
> > > > >>>>>>>>>>>>>>>>>> process
> > > > >>>>>>>>>>>>>>>>>>>> page.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> A
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
> > > > >>>>> rules
> > > > >>>>>>> for
> > > > >>>>>>>>>>>>> approvals,
> > > > >>>>>>>>>>>>>>> etc.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> > > > >>>>>>> currently
> > > > >>>>>>>>>>> requires
> > > > >>>>>>>>>>>>>> "one
> > > > >>>>>>>>>>>>>>>> +1
> > > > >>>>>>>>>>>>>>>>>>> from a
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> > > > >>>>>>> followed
> > > > >>>>>>>>> by a
> > > > >>>>>>>>>>>>> Lazy
> > > > >>>>>>>>>>>>>>>>> approval
> > > > >>>>>>>>>>>>>>>>>>> (not
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> counting
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
> > > > >>>>> moving
> > > > >>>>>>> to
> > > > >>>>>>>>> lazy
> > > > >>>>>>>>>>>>>> majority
> > > > >>>>>>>>>>>>>>>> if
> > > > >>>>>>>>>>>>>>>>> a
> > > > >>>>>>>>>>>>>>>>>> -1
> > > > >>>>>>>>>>>>>>>>>>>> is
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> received".
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> > > > >>>>>> that a
> > > > >>>>>>>>>>> committer
> > > > >>>>>>>>>>>>>>> always
> > > > >>>>>>>>>>>>>>>>>>> needs a
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> review
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> > > > >>>>>> as I
> > > > >>>>>>>>> know
> > > > >>>>>>>>>>>>> this is
> > > > >>>>>>>>>>>>>>>>>> currently
> > > > >>>>>>>>>>>>>>>>>>>> not
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > > > >>>>>>>>>> contributor
> > > > >>>>>>>>>>>>>>> reviews
> > > > >>>>>>>>>>>>>>>> &
> > > > >>>>>>>>>>>>>>>>>>> +1s).
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
> > > > >>>>>> how
> > > > >>>>>>>> we
> > > > >>>>>>>>>> can
> > > > >>>>>>>>>>>>> make
> > > > >>>>>>>>>>>>>> it
> > > > >>>>>>>>>>>>>>>>> easy
> > > > >>>>>>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>>>> follow
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> > > > >>>>>>>> Flink-specific
> > > > >>>>>>>>>> Jira
> > > > >>>>>>>>>>>>>>>> workflows
> > > > >>>>>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>>> ticket
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> types +
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
> > > > >>>>>> this
> > > > >>>>>>> is
> > > > >>>>>>>>>>>>> certainly
> > > > >>>>>>>>>>>>>>>> "Step
> > > > >>>>>>>>>>>>>>>>>> 2",
> > > > >>>>>>>>>>>>>>>>>>> I
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> believe,
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> > > > >>>>>>>>> transparent
> > > > >>>>>>>>>>> as
> > > > >>>>>>>>>>>>>>>> possible,
> > > > >>>>>>>>>>>>>>>>>>>> otherwise
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> they
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
> > > > >>>>>> Becket
> > > > >>>>>>>>> Qin <
> > > > >>>>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
> > > > >>>>>> process
> > > > >>>>>>>>>>> discussion
> > > > >>>>>>>>>>>>>>> thread
> > > > >>>>>>>>>>>>>>>>>> [1],
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> currently
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
> > > > >>>>>>> govern
> > > > >>>>>>>>> the
> > > > >>>>>>>>>>>>>>> operation
> > > > >>>>>>>>>>>>>>>> of
> > > > >>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> project.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
> > > > >>>>>> community
> > > > >>>>>>>> to
> > > > >>>>>>>>>>>>>> coordinate
> > > > >>>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>>>>> contribute
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
> > > > >>>>>>> other
> > > > >>>>>>>>>>>>> processes
> > > > >>>>>>>>>>>>>>> such
> > > > >>>>>>>>>>>>>>>>> as
> > > > >>>>>>>>>>>>>>>>>>>> FLIP.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
> > > > >>>>> page
> > > > >>>>>>> and
> > > > >>>>>>>>>> would
> > > > >>>>>>>>>>>>> like
> > > > >>>>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>>> start a
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> discussion
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
> > > > >>>>> in
> > > > >>>>>>> the
> > > > >>>>>>>>>>>>> community.
> > > > >>>>>>>>>>>>>>>> It'll
> > > > >>>>>>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>>>>>>> great to
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> hear
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>
> > > >
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
> > > > >>>>>> Architect
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
> > > > >>>>>>>> 31.08.2019,
> > > > >>>>>>>>>>>>> 05.09. -
> > > > >>>>>>>>>>>>>>>>>>> 06.09.2010
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
> > > > >>>>>> 115,
> > > > >>>>>>>>> 10115
> > > > >>>>>>>>>>>>>> Berlin,
> > > > >>>>>>>>>>>>>>>>>> Germany
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
> > > > >>>>>>>> Charlottenburg:
> > > > >>>>>>>>>> HRB
> > > > >>>>>>>>>>>>>> 158244
> > > > >>>>>>>>>>>>>>> B
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
> > > > >>>>>>> Tzoumas,
> > > > >>>>>>>>> Dr.
> > > > >>>>>>>>>>>>> Stephan
> > > > >>>>>>>>>>>>>>>> Ewen
> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Flink project bylaws

[Robert Metzger <rm...@apache.org>]

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 <be...@gmail.com> wrote:

> Hi Robert,
>
> Thanks for help apply the changes. I agree we should freeze the change to
> the bylaws page starting from now. For this particular addition of
> clarification, I'll send a notice in the voting thread to let who have
> already voted to know.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> On Tue, Aug 13, 2019 at 1:29 PM Robert Metzger <rm...@apache.org>
> wrote:
>
> > Hi Becket,
> > I've applied the proposed change to the document:
> >
> >
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026&selectedPageVersions=20&selectedPageVersions=19
> >
> > I would propose to stop accepting changes to the document now, as it
> might
> > start a discussion about the validity of the vote and the bylaws itself.
> > Changes to the document require a 2/3 majority.
> >
> >
> > On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels <mx...@apache.org>
> > wrote:
> >
> > > Hi Becket,
> > >
> > > Thanks for clarifying and updating the draft. The changes look good to
> > me.
> > >
> > > I don't feel strong about a 2/3 majority in case of committer/PMC
> > > removal. Like you pointed out, both provide a significant hurdle due to
> > > possible vetos or a 2/3 majority.
> > >
> > > Thanks,
> > > Max
> > >
> > > On 13.08.19 10:36, Becket Qin wrote:
> > > > Piotr just reminded me that there was a previous suggestion to
> clarify
> > a
> > > > committer's responsibility when commit his/her own patch. So I'd like
> > to
> > > > incorporate that in the bylaws. The additional clarification is
> > following
> > > > in bold and italic font.
> > > >
> > > > one +1 from a committer followed by a Lazy approval (not counting the
> > > vote
> > > >> of the contributor), moving to lazy majority if a -1 is received.
> > > >>
> > > >
> > > >
> > > > Note that this implies that committers can +1 their own commits and
> > merge
> > > >> right away. *However, the committe**rs should use their best
> judgement
> > > to
> > > >> respect the components expertise and ongoing development plan.*
> > > >
> > > >
> > > > This does not really change any of the existing bylaws, just about
> > > > clarification.
> > > >
> > > > If there is no objection to this additional clarification, after the
> > > bylaws
> > > > wiki is updated, I'll send an update notice to the voting thread to
> > > inform
> > > > those who already voted about this addition.
> > > >
> > > > Thanks,
> > > >
> > > > Jiangjie (Becket) Qin
> > > >
> > > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin <be...@gmail.com>
> > > wrote:
> > > >
> > > >> Hi Maximillian,
> > > >>
> > > >> Thanks for the feedback. Please see the reply below:
> > > >>
> > > >> Step 2 should include a personal email to the PMC members in
> question.
> > > >>
> > > >> I'm afraid reminders inside the vote thread could be overlooked
> > easily.
> > > >>
> > > >>
> > > >> This is exactly what I meant to say by "reach out" :) I just made it
> > > more
> > > >> explicit.
> > > >>
> > > >> The way the terms are described in the draft, the consensus is
> "lazy",
> > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to
> "Lazy
> > > >>> Consensus". This is in line with the other definitions such as
> "Lazy
> > > >>> Majority".
> > > >>
> > > >> It was initially called "lazy consensus", but Robert pointed out
> that
> > > >> "lazy consensus" actually means something different in ASF term [1].
> > > >> Here "lazy" pretty much means "assume everyone is +1 unless someone
> > says
> > > >> otherwise". This means any vote that requires a minimum number of +1
> > is
> > > not
> > > >> really a "lazy" vote.
> > > >>
> > > >> Removing a committer / PMC member only requires 3 binding votes. I'd
> > > >>> expect an important action like this to require a 2/3 majority.
> > > >>
> > > >> Personally I think consensus is good enough here. PMC members can
> > cast a
> > > >> veto if they disagree about the removal. In some sense, it is more
> > > >> difficult than with 2/3 majority to remove a committer / PMC member.
> > > Also,
> > > >> it might be a hard decision for some PMC members if they have never
> > > worked
> > > >> with the person in question. That said, I am OK to change it to 2/3
> > > >> majority as this will happen very rarely.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Jiangjie (Becket) Qin
> > > >>
> > > >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus
> > > >>
> > > >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <mx...@apache.org>
> > > wrote:
> > > >>
> > > >>> I'm a bit late to the discussion here. Three suggestions:
> > > >>>
> > > >>> 1) Procedure for "insufficient active binding voters to reach 2/3
> > > majority
> > > >>>
> > > >>>>     1. Wait until the minimum length of the voting passes.
> > > >>>>     2. Publicly reach out to the remaining binding voters in the
> > > voting
> > > >>> mail thread for at least 2 attempts with at least 7 days between
> two
> > > >>> attempts.
> > > >>>>     3. If the binding voter being contacted still failed to
> respond
> > > >>> after all the attempts, the binding voter will be considered as
> > > inactive
> > > >>> for the purpose of this particular voting.
> > > >>>
> > > >>> Step 2 should include a personal email to the PMC members in
> > question.
> > > >>> I'm afraid reminders inside the vote thread could be overlooked
> > easily.
> > > >>>
> > > >>> 2) "Consensus" => "Lazy Consensus"
> > > >>>
> > > >>> The way the terms are described in the draft, the consensus is
> > "lazy",
> > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to
> "Lazy
> > > >>> Consensus". This is in line with the other definitions such as
> "Lazy
> > > >>> Majority".
> > > >>>
> > > >>> 3) Committer / PMC Removal
> > > >>>
> > > >>> Removing a committer / PMC member only requires 3 binding votes.
> I'd
> > > >>> expect an important action like this to require a 2/3 majority.
> > > >>>
> > > >>>
> > > >>> Do you think we could incorporate those suggestions?
> > > >>>
> > > >>> Thanks,
> > > >>> Max
> > > >>>
> > > >>> On 11.08.19 10:14, Becket Qin wrote:
> > > >>>> Hi folks,
> > > >>>>
> > > >>>> Thanks for all the discussion and support. I have started the
> voting
> > > >>> thread.
> > > >>>>
> > > >>>>
> > > >>>
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
> > > >>>>
> > > >>>> Thanks,
> > > >>>>
> > > >>>> Jiangjie (Becket) Qin
> > > >>>>
> > > >>>> On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <fh...@gmail.com>
> > > wrote:
> > > >>>>
> > > >>>>> Thanks for the update and driving the discussion Becket!
> > > >>>>> +1 for starting a vote.
> > > >>>>>
> > > >>>>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
> > > >>> becket.qin@gmail.com
> > > >>>>>> :
> > > >>>>>
> > > >>>>>> Thanks Stephan.
> > > >>>>>>
> > > >>>>>> I think we have resolved all the comments on the wiki page.
> There
> > > are
> > > >>> two
> > > >>>>>> minor changes made to the bylaws since last week.
> > > >>>>>> 1. For 2/3 majority, the required attempts to reach out to
> binding
> > > >>> voters
> > > >>>>>> is reduced from 3 to 2. This helps shorten the voting process a
> > > little
> > > >>>>> bit.
> > > >>>>>> 2. Clarified what is considered as the adoption of new codebase.
> > > >>>>>>
> > > >>>>>> I think we almost reached consensus. I'll start a voting thread
> in
> > > two
> > > >>>>> days
> > > >>>>>> if there is no new concerns.
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>>
> > > >>>>>> Jiangjie (Becket) Qin
> > > >>>>>>
> > > >>>>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org>
> > > wrote:
> > > >>>>>>
> > > >>>>>>> I added a clarification to the table, clarifying that the
> current
> > > >>>>>> phrasing
> > > >>>>>>> means that committers do not need another +1 for their commits.
> > > >>>>>>>
> > > >>>>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <
> fhueske@gmail.com
> > >
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> Hi Becket,
> > > >>>>>>>>
> > > >>>>>>>> Thanks a lot for pushing this forward and addressing the
> > feedback.
> > > >>>>>>>> I'm very happy with the current state of the bylaws.
> > > >>>>>>>> +1 to wait until Friday before starting a vote.
> > > >>>>>>>>
> > > >>>>>>>> Best, Fabian
> > > >>>>>>>>
> > > >>>>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> > > >>>>>>>> becket.qin@gmail.com
> > > >>>>>>>>> :
> > > >>>>>>>>
> > > >>>>>>>>> Hi Everyone,
> > > >>>>>>>>>
> > > >>>>>>>>> Thanks for all the discussion and feedback.
> > > >>>>>>>>>
> > > >>>>>>>>> It seems that we have almost reached consensus. I'll leave
> the
> > > >>>>>>> discussion
> > > >>>>>>>>> thread open until this Friday. If there is no more concerns
> > > raised,
> > > >>>>>>> I'll
> > > >>>>>>>>> start a voting thread after that.
> > > >>>>>>>>>
> > > >>>>>>>>> Thanks,
> > > >>>>>>>>>
> > > >>>>>>>>> Jiangjie (Becket) Qin
> > > >>>>>>>>>
> > > >>>>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com>
> > wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> Hi Becket,
> > > >>>>>>>>>>
> > > >>>>>>>>>> Thanks for noticing and resolving my comment around PMC
> > removal
> > > >>>>> and
> > > >>>>>>> ASF
> > > >>>>>>>>>> rules of PMC membership change process, which you seem to
> > > neglect
> > > >>>>>> in
> > > >>>>>>>> the
> > > >>>>>>>>>> summary of updates (smile).
> > > >>>>>>>>>>
> > > >>>>>>>>>> Best Regards,
> > > >>>>>>>>>> Yu
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <
> > becket.qin@gmail.com>
> > > >>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Hi folks,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Thanks for all the feedback.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> It seems that there are a few concerns over the emeritus
> > status
> > > >>>>>>>> after 6
> > > >>>>>>>>>>> months of inactivity. Given that the main purpose is just
> to
> > > >>>>> make
> > > >>>>>>>> sure
> > > >>>>>>>>>> 2/3
> > > >>>>>>>>>>> majority can pass and we sort of have a solution for that,
> I
> > > >>>>> just
> > > >>>>>>>>> updated
> > > >>>>>>>>>>> the draft with the following changes:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 1. Removed the inactivity term for emeritus committers /
> > PMCs.
> > > >>>>> A
> > > >>>>>>>>>> committer
> > > >>>>>>>>>>> / PMC will only be considered emeritus by their own claim.
> > > >>>>>>>>>>> 2. Removed the approval process for reinstatement of the
> > > >>>>> emeritus
> > > >>>>>>>>>>> committers / PMCs. An emeritus committer / PMC will be
> > > >>>>> reinstated
> > > >>>>>>>> when
> > > >>>>>>>>>> they
> > > >>>>>>>>>>> send an email to the private@flink.apache.org.
> > > >>>>>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still
> > doable
> > > >>>>>> when
> > > >>>>>>>>> there
> > > >>>>>>>>>>> are non-emeritus committers / PMCs who do not cast the
> vote.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Please let me know if you have any further thoughts.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Jiangjie (Becket) Qin
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
> > > >>>>>> becket.qin@gmail.com>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> Hi Fabian,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Thanks for the feedback.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I agree that if we don't like emeritus committers / PMCs,
> we
> > > >>>>>>> don't
> > > >>>>>>>>> have
> > > >>>>>>>>>>> to
> > > >>>>>>>>>>>> do it. That said, emeritus status simply means whether an
> > > >>>>>>>> individual
> > > >>>>>>>>> is
> > > >>>>>>>>>>>> active / inactive in the community. It does not make the
> > > >>>>> merits
> > > >>>>>>>>> earned
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>> go away. For our purpose, emeritus status is mostly just a
> > > >>>>> way
> > > >>>>>> to
> > > >>>>>>>>> make
> > > >>>>>>>>>>> 2/3
> > > >>>>>>>>>>>> majority possible. As you noticed, since reaching out to
> > > >>>>>> binding
> > > >>>>>>>>> voters
> > > >>>>>>>>>>> who
> > > >>>>>>>>>>>> have not voted can achieve the same goal, the emeritus
> > status
> > > >>>>>> is
> > > >>>>>>>> more
> > > >>>>>>>>>> of
> > > >>>>>>>>>>> an
> > > >>>>>>>>>>>> optimization so we don't have to ping the inactive binding
> > > >>>>>> voters
> > > >>>>>>>>> every
> > > >>>>>>>>>>>> time and wait for long. However, given that 2/3 majority
> > > >>>>>> votings
> > > >>>>>>>> are
> > > >>>>>>>>>>> rare,
> > > >>>>>>>>>>>> such communication cost is probably OK. So I think we can
> > > >>>>>> remove
> > > >>>>>>>> that
> > > >>>>>>>>>>>> emeritus part from the bylaws.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 1) We should add to the requirements of the PMC that they
> > > >>>>> need
> > > >>>>>> to
> > > >>>>>>>>> make
> > > >>>>>>>>>>>>> sure the project complies with brand issues and reports
> > > >>>>> misuse
> > > >>>>>>> of
> > > >>>>>>>>> ASF
> > > >>>>>>>>>>>>> brands.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Good point. Added.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 2) Do we want to restrict voting days to working days,
> i.e.,
> > > >>>>> a
> > > >>>>>> 3
> > > >>>>>>>> day
> > > >>>>>>>>>> vote
> > > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> This might be a little tricky because people are from
> > > >>>>> countries
> > > >>>>>>> in
> > > >>>>>>>>>>>> different time zones and with different holidays, and so
> on.
> > > >>>>> If
> > > >>>>>>> we
> > > >>>>>>>>> are
> > > >>>>>>>>>>>> worrying about 3 days minimum length is not enough for
> those
> > > >>>>>> who
> > > >>>>>>>> want
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>> give feedback, we can make it 5 days.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 3) Do we need a process do decide about removal of
> features
> > > >>>>>> (like
> > > >>>>>>>> the
> > > >>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
> > > >>>>>> Python
> > > >>>>>>>>>> APIs)?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I assume such action should be covered by FLIP as it is a
> > > >>>>>> change
> > > >>>>>>> to
> > > >>>>>>>>> the
> > > >>>>>>>>>>>> API and probably needs a migration plan. It would be
> useful
> > > >>>>> to
> > > >>>>>>>> have a
> > > >>>>>>>>>>>> formal deprecation procedure. But that might be better to
> be
> > > >>>>>> put
> > > >>>>>>>> into
> > > >>>>>>>>>>>> somewhere else because the bylaws are primarily focusing
> on
> > > >>>>> the
> > > >>>>>>>>>>>> non-technical rules, whereas the deprecation seems more on
> > > >>>>> the
> > > >>>>>>>>>> technical
> > > >>>>>>>>>>>> side.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Jiangjie (Becket) Qin
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
> > > >>>>>>> fhueske@gmail.com>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> First of all thank you very much Becket for starting this
> > > >>>>>>>>> discussion!
> > > >>>>>>>>>>>>> I think it is a very good idea and overdue to formally
> > > >>>>> define
> > > >>>>>>> some
> > > >>>>>>>>> of
> > > >>>>>>>>>>> our
> > > >>>>>>>>>>>>> community processes.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Similar to Chesnay, I have concerns about the distinction
> > > >>>>>>> between
> > > >>>>>>>>>> active
> > > >>>>>>>>>>>>> and non-active / emeritus committers and PMC members.
> > > >>>>>>>>>>>>> My foremost concern is that this is not in the spirit of
> > the
> > > >>>>>>>> Apache
> > > >>>>>>>>>> Way
> > > >>>>>>>>>>>>> [1]
> > > >>>>>>>>>>>>> which is (among other things) based on the idea of merit
> > > >>>>> which
> > > >>>>>>>> once
> > > >>>>>>>>>>>>> earned,
> > > >>>>>>>>>>>>> does not go away over time.
> > > >>>>>>>>>>>>> I know other projects like Hadoop and Kafka have similar
> > > >>>>>> clauses
> > > >>>>>>>> in
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>> bylaws but IMO we don't need to adopt them if we don't
> like
> > > >>>>>>> them.
> > > >>>>>>>>>>>>> For example, I don't like the idea that committers or PMC
> > > >>>>>>> members
> > > >>>>>>>>> who
> > > >>>>>>>>>>> are
> > > >>>>>>>>>>>>> temporarily away from the project (for whatever reason:
> > > >>>>>> parental
> > > >>>>>>>>>> leave,
> > > >>>>>>>>>>>>> sabbatical, health issues, etc.) need the PMC approval to
> > be
> > > >>>>>>>>> "active"
> > > >>>>>>>>>>>>> again.
> > > >>>>>>>>>>>>> As far as I am aware, we have not seen any issues with
> > > >>>>>> inactive
> > > >>>>>>>>>> members
> > > >>>>>>>>>>> in
> > > >>>>>>>>>>>>> the past.
> > > >>>>>>>>>>>>> Moreover, it would be hard to track whether somebody
> became
> > > >>>>>>>> inactive
> > > >>>>>>>>>> at
> > > >>>>>>>>>>>>> some point in time (which we would need to do, if I
> > > >>>>> understand
> > > >>>>>>> the
> > > >>>>>>>>>>>>> proposal
> > > >>>>>>>>>>>>> correctly).
> > > >>>>>>>>>>>>> With the approach that Becket suggested in his last email
> > > >>>>>>>> (reaching
> > > >>>>>>>>>> out
> > > >>>>>>>>>>> to
> > > >>>>>>>>>>>>> binding voters who haven't voted yet), we could drop the
> > > >>>>>>>> distinction
> > > >>>>>>>>>>>>> between active and non-active committers and PMC members.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I also have a few minor comments:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 1) We should add to the requirements of the PMC [2] that
> > > >>>>> they
> > > >>>>>>> need
> > > >>>>>>>>> to
> > > >>>>>>>>>>> make
> > > >>>>>>>>>>>>> sure the project complies with brand issues and reports
> > > >>>>> misuse
> > > >>>>>>> of
> > > >>>>>>>>> ASF
> > > >>>>>>>>>>>>> brands.
> > > >>>>>>>>>>>>> 2) Do we want to restrict voting days to working days,
> > i.e.,
> > > >>>>>> a 3
> > > >>>>>>>> day
> > > >>>>>>>>>>> vote
> > > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > >>>>>>>>>>>>> 3) Do we need a process do decide about removal of
> features
> > > >>>>>>> (like
> > > >>>>>>>>> the
> > > >>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
> > > >>>>>> Python
> > > >>>>>>>>>> APIs)?
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thank you,
> > > >>>>>>>>>>>>> Fabian
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> [1] https://www.apache.org/theapacheway/
> > > >>>>>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> > > >>>>>>>>>>>>> becket.qin@gmail.com
> > > >>>>>>>>>>>>>> :
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Hi Hequn,
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see the reply
> > > >>>>>> below:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one PMC
> > > >>>>> in
> > > >>>>>>>> the 3
> > > >>>>>>>>>>>>> binding
> > > >>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> > > >>>>> and 1
> > > >>>>>>>> PMC.
> > > >>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> > > >>>>> somehow
> > > >>>>>>> be a
> > > >>>>>>>>> big
> > > >>>>>>>>>>>>>> feature
> > > >>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
> > > >>>>> loss
> > > >>>>>>> of
> > > >>>>>>>>>>>>> flexibility
> > > >>>>>>>>>>>>>>> as committers also have a chance to vote and
> participate
> > > >>>>>> in
> > > >>>>>>>> it.
> > > >>>>>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs are
> > > >>>>> the
> > > >>>>>>>>>> following:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 1. Generally speaking, the PMC's primary responsibility
> is
> > > >>>>>>>>> operating
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>>>>> project and deciding what software to release on behalf
> of
> > > >>>>>>> ASF.
> > > >>>>>>>>>>>>> Committers,
> > > >>>>>>>>>>>>>> on the other hand, are responsible for the technical
> part
> > > >>>>> of
> > > >>>>>>> the
> > > >>>>>>>>>>>>> project.
> > > >>>>>>>>>>>>>> So for FLIPs, a PMC's vote probably should not outweigh
> a
> > > >>>>>>>>>> committer's
> > > >>>>>>>>>>>>> vote.
> > > >>>>>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is
> really
> > > >>>>>>>>> convincing
> > > >>>>>>>>>>>>> enough
> > > >>>>>>>>>>>>>> to decide whether the FLIP is good to go or not. Also,
> if
> > > >>>>>> some
> > > >>>>>>>>>>>>> committers
> > > >>>>>>>>>>>>>> have concern over a FLIP, they could just veto it. To me
> > > >>>>> it
> > > >>>>>> is
> > > >>>>>>>>>>> actually
> > > >>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>> more strict requirement to pass a FLIP than asking a PMC
> > > >>>>> to
> > > >>>>>>>> vote.
> > > >>>>>>>>> In
> > > >>>>>>>>>>>>>> practice, people will usually also address the concerns
> > > >>>>> even
> > > >>>>>>> if
> > > >>>>>>>>> they
> > > >>>>>>>>>>> are
> > > >>>>>>>>>>>>>> not from a PMC/committer before they start the voting
> > > >>>>>> process.
> > > >>>>>>>> So
> > > >>>>>>>>> I
> > > >>>>>>>>>>>>> don't
> > > >>>>>>>>>>>>>> see much benefit of requiring a PMC's vote in this case.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the votes
> > > >>>>> no
> > > >>>>>>>> longer
> > > >>>>>>>>>>>>>> independent. Ideally, a vote is either binding or
> > > >>>>>> non-binding
> > > >>>>>>> by
> > > >>>>>>>>>>>>> itself. If
> > > >>>>>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
> > > >>>>> imagine
> > > >>>>>>>> there
> > > >>>>>>>>>> have
> > > >>>>>>>>>>>>> been
> > > >>>>>>>>>>>>>> 3 committers who voted +1. But the FLIP still has not
> > > >>>>>> passed,
> > > >>>>>>> so
> > > >>>>>>>>>> those
> > > >>>>>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a +1,
> > > >>>>>> those
> > > >>>>>>>>> votes
> > > >>>>>>>>>>>>>> suddenly become binding, which is a little awkward.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable to
> me.
> > > >>>>>> Some
> > > >>>>>>>>>>> thoughts
> > > >>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>> this:
> > > >>>>>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is probably
> > > >>>>>>> because
> > > >>>>>>>>>> there
> > > >>>>>>>>>>>>> are
> > > >>>>>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3
> majority
> > > >>>>>>>>>>> prohibitively
> > > >>>>>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
> > > >>>>> Flink[2]
> > > >>>>>>> and
> > > >>>>>>>> a
> > > >>>>>>>>>>> quick
> > > >>>>>>>>>>>>>> search shows at most 6 of them have not sent email in
> the
> > > >>>>>>>> recent 6
> > > >>>>>>>>>>>>> months
> > > >>>>>>>>>>>>>> or so.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare. It
> is
> > > >>>>>>>> designed
> > > >>>>>>>>>> in
> > > >>>>>>>>>>>>>> particular for the cases that broad opinions are
> > > >>>>> important,
> > > >>>>>>> more
> > > >>>>>>>>>>>>>> specifically new codebase adoption or modification to
> the
> > > >>>>>>>> bylaws.
> > > >>>>>>>>>>>>> Therefore
> > > >>>>>>>>>>>>>> such vote by its nature favors consensus over
> convenience.
> > > >>>>>>> That
> > > >>>>>>>>>> means
> > > >>>>>>>>>>>>> any
> > > >>>>>>>>>>>>>> alternative voting type reducing the coverage worth a
> > > >>>>>> careful
> > > >>>>>>>>>>> thinking.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 3. I do agree that it does not make sense to have 2/3
> > > >>>>>> majority
> > > >>>>>>>> if
> > > >>>>>>>>>> such
> > > >>>>>>>>>>>>>> requirement is no-longer doable over time. But I am a
> > > >>>>> little
> > > >>>>>>>>>> hesitant
> > > >>>>>>>>>>> to
> > > >>>>>>>>>>>>>> lower the threshold to lazy 2/3 majority in our case.
> What
> > > >>>>>> do
> > > >>>>>>>> you
> > > >>>>>>>>>>> think
> > > >>>>>>>>>>>>>> about doing the following:
> > > >>>>>>>>>>>>>>     - After the voting started, there will be at least 6
> > > >>>>>> days
> > > >>>>>>>> for
> > > >>>>>>>>>>>>> people to
> > > >>>>>>>>>>>>>> cast their votes.
> > > >>>>>>>>>>>>>>     - After 6 days, if the result of the vote is still
> not
> > > >>>>>>>>>> determined,
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>> person who started the vote should reach out to the
> > > >>>>> binding
> > > >>>>>>>> voters
> > > >>>>>>>>>> who
> > > >>>>>>>>>>>>> have
> > > >>>>>>>>>>>>>> not voted yet for at least 3 times and at least 7 days
> > > >>>>>> between
> > > >>>>>>>>> each
> > > >>>>>>>>>>>>> time.
> > > >>>>>>>>>>>>>> If a binding voter still did not respond, the vote from
> > > >>>>> that
> > > >>>>>>>> voter
> > > >>>>>>>>>>> will
> > > >>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>> excluded from the 2/3 majority counting.
> > > >>>>>>>>>>>>>> This would ensure the coverage at our best effort while
> > > >>>>>> still
> > > >>>>>>>> let
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>> 2/3
> > > >>>>>>>>>>>>>> majority vote make progress.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> [1] https://projects.apache.org/committee.html?hadoop
> > > >>>>>>>>>>>>>> [2] https://projects.apache.org/committee.html?flink
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> > > >>>>>>>>> forwardxu315@gmail.com>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Big +1 on this.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> best
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> forward
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
> > > >>>>>> 下午1:30写道：
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Hi Becket,
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Big +1 on this.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> > > >>>>>>> includes a
> > > >>>>>>>>> PMC
> > > >>>>>>>>>>>>> vote.
> > > >>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
> > > >>>>> PMC
> > > >>>>>> in
> > > >>>>>>>>> the 3
> > > >>>>>>>>>>>>>> binding
> > > >>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> > > >>>>>> and 1
> > > >>>>>>>>> PMC.
> > > >>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> > > >>>>>> somehow
> > > >>>>>>>> be a
> > > >>>>>>>>>> big
> > > >>>>>>>>>>>>>>> feature
> > > >>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
> > > >>>>>> loss
> > > >>>>>>>> of
> > > >>>>>>>>>>>>>> flexibility
> > > >>>>>>>>>>>>>>>> as committers also have a chance to vote and
> > > >>>>> participate
> > > >>>>>>> in
> > > >>>>>>>>> it.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> ========Seperator========
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> For the nice bylaws, I agree with the general idea and
> > > >>>>>>> most
> > > >>>>>>>> of
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>>>> content.
> > > >>>>>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority". The
> > > >>>>>>> main
> > > >>>>>>>>>>> concern
> > > >>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>> am
> > > >>>>>>>>>>>>>>>> not sure if it is doable in practice. The reasons are:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
> > > >>>>>> committer
> > > >>>>>>>> or a
> > > >>>>>>>>>> PMC
> > > >>>>>>>>>>>>>> member
> > > >>>>>>>>>>>>>>>> is active if he or she sends one email to the mailing
> > > >>>>>> list
> > > >>>>>>>>>> every 6
> > > >>>>>>>>>>>>>>> months.
> > > >>>>>>>>>>>>>>>> While the minimum length of the vote is only 6 days.
> > > >>>>>> There
> > > >>>>>>>> are
> > > >>>>>>>>>>>>> chances
> > > >>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>> during the vote, some of the active members are still
> > > >>>>>>>> offline
> > > >>>>>>>>> of
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>> community.
> > > >>>>>>>>>>>>>>>> 2. The code of Flink is changing fast and not everyone
> > > >>>>>>> fully
> > > >>>>>>>>>>>>>> understands
> > > >>>>>>>>>>>>>>>> every part. We don't need to force people to vote if
> > > >>>>>> they
> > > >>>>>>>> are
> > > >>>>>>>>>> not
> > > >>>>>>>>>>>>> sure
> > > >>>>>>>>>>>>>>>> about it. It may also make the final result less
> > > >>>>>> credible.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Given the above reasons, perhaps we can change the 2/3
> > > >>>>>>>>> Majority
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>>> lazy
> > > >>>>>>>>>>>>>>> 2/3
> > > >>>>>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
> > > >>>>>> higher
> > > >>>>>>>>>>> threshold,
> > > >>>>>>>>>>>>>>>> however, more practical.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> What do you think?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> > > >>>>>>>>>> becket.qin@gmail.com
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Hi Jincheng,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki page.
> > > >>>>>>> Just
> > > >>>>>>>> a
> > > >>>>>>>>>>> brief
> > > >>>>>>>>>>>>>>>> summary,
> > > >>>>>>>>>>>>>>>>> the current bylaws do require some of the FLIPs to
> > > >>>>> get
> > > >>>>>>> PMC
> > > >>>>>>>>>>>>> approval
> > > >>>>>>>>>>>>>> if
> > > >>>>>>>>>>>>>>>>> their impact is big enough. But it leaves majority
> > > >>>>> of
> > > >>>>>>> the
> > > >>>>>>>>>>>>> technical
> > > >>>>>>>>>>>>>>>>> decisions to the committers who are supposed to be
> > > >>>>>>>>> responsible
> > > >>>>>>>>>>> for
> > > >>>>>>>>>>>>>>> making
> > > >>>>>>>>>>>>>>>>> such decisions.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Re: Robert,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> I agree we can simply remove the requirement of +1
> > > >>>>>> from
> > > >>>>>>> a
> > > >>>>>>>>>>>>> non-author
> > > >>>>>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
> > > >>>>> does
> > > >>>>>>> not
> > > >>>>>>>>> make
> > > >>>>>>>>>>>>> sense
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
> > > >>>>>> updated
> > > >>>>>>>> the
> > > >>>>>>>>>>> bylaws
> > > >>>>>>>>>>>>>>> wiki.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> > > >>>>>>>>>>>>> rmetzger@apache.org
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
> > > >>>>>>> current
> > > >>>>>>>>>>> status
> > > >>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
> > > >>>>> is
> > > >>>>>> a
> > > >>>>>>>> very
> > > >>>>>>>>>>>>> involved
> > > >>>>>>>>>>>>>>>> task.
> > > >>>>>>>>>>>>>>>>>> Unless there's somebody who's really eager to
> > > >>>>> drive
> > > >>>>>>>> this,
> > > >>>>>>>>> I
> > > >>>>>>>>>>>>> would
> > > >>>>>>>>>>>>>>> stick
> > > >>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
> > > >>>>>> Flink,
> > > >>>>>>>> even
> > > >>>>>>>>>> if
> > > >>>>>>>>>>>>> this
> > > >>>>>>>>>>>>>>>> means
> > > >>>>>>>>>>>>>>>>>> some changes.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> The cross-review requirement is the last big open
> > > >>>>>>> point
> > > >>>>>>>> in
> > > >>>>>>>>>>> this
> > > >>>>>>>>>>>>>>>>> discussion.
> > > >>>>>>>>>>>>>>>>>> It seems that a there is a slight tendency in the
> > > >>>>>>>>> discussion
> > > >>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>> this
> > > >>>>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>> not feasible given the current pull request review
> > > >>>>>>>>>> situation.
> > > >>>>>>>>>>>>>>>>>> For the sake of bringing this discussion to a
> > > >>>>>>>> conclusion,
> > > >>>>>>>>>> I'm
> > > >>>>>>>>>>>>> fine
> > > >>>>>>>>>>>>>>> with
> > > >>>>>>>>>>>>>>>>>> leaving this requirement out. As we are currently
> > > >>>>>>> adding
> > > >>>>>>>>>> more
> > > >>>>>>>>>>>>>>>> committers
> > > >>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>> the project, we might be able to revisit this
> > > >>>>>>> discussion
> > > >>>>>>>>> in
> > > >>>>>>>>>> 3
> > > >>>>>>>>>>> -
> > > >>>>>>>>>>>>> 6
> > > >>>>>>>>>>>>>>>> months.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> > > >>>>>>>>>>>>>>> sunjincheng121@gmail.com
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Hi Becket,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Thanks for the proposal.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> > > >>>>>>>>> includes a
> > > >>>>>>>>>>> PMC
> > > >>>>>>>>>>>>>>> vote.
> > > >>>>>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
> > > >>>>>> the
> > > >>>>>>>>> user's
> > > >>>>>>>>>>>>>>> interface
> > > >>>>>>>>>>>>>>>>>>> changes. What do you think? (I leave the comment
> > > >>>>>> in
> > > >>>>>>>> the
> > > >>>>>>>>>>> wiki.)
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Best,
> > > >>>>>>>>>>>>>>>>>>> Jincheng
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
> > > >>>>>>>> 于2019年7月17日周三
> > > >>>>>>>>>>>>>> 下午9:12写道：
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
> > > >>>>>> that
> > > >>>>>>> I
> > > >>>>>>>>>> really
> > > >>>>>>>>>>>>> like
> > > >>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> proposed bylaws!
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
> > > >>>>>>>>> expressed
> > > >>>>>>>>>> by
> > > >>>>>>>>>>>>> few
> > > >>>>>>>>>>>>>>>> people
> > > >>>>>>>>>>>>>>>>>>>> before that the "committer +1" on code change
> > > >>>>>>> might
> > > >>>>>>>> be
> > > >>>>>>>>>>> hard
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>> achieve
> > > >>>>>>>>>>>>>>>>>>>> currently. On the other hand I would say this
> > > >>>>>>> would
> > > >>>>>>>> be
> > > >>>>>>>>>>>>>> beneficial
> > > >>>>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
> > > >>>>>>> knowledge
> > > >>>>>>>>>>>>> sharing.
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> I was just wondering what should be the next
> > > >>>>>> step
> > > >>>>>>>> for
> > > >>>>>>>>>>> this?
> > > >>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>> think
> > > >>>>>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>>>>> would make sense to already use those bylaws
> > > >>>>> and
> > > >>>>>>> put
> > > >>>>>>>>>> them
> > > >>>>>>>>>>> to
> > > >>>>>>>>>>>>>> PMC
> > > >>>>>>>>>>>>>>>>> vote.
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Best,
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Dawid
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > >>>>>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
> > > >>>>> think.
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> > > >>>>>> If
> > > >>>>>>> we
> > > >>>>>>>>> are
> > > >>>>>>>>>>>>>> stating
> > > >>>>>>>>>>>>>>>>> that a
> > > >>>>>>>>>>>>>>>>>>>> single
> > > >>>>>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
> > > >>>>>> review,
> > > >>>>>>>>> with 0
> > > >>>>>>>>>>>>> hours
> > > >>>>>>>>>>>>>>>> delay
> > > >>>>>>>>>>>>>>>>>> (de
> > > >>>>>>>>>>>>>>>>>>>> facto
> > > >>>>>>>>>>>>>>>>>>>>>>> the current state), we should also write
> > > >>>>>> down
> > > >>>>>>>> that
> > > >>>>>>>>>>> this
> > > >>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>> subject
> > > >>>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
> > > >>>>>> the
> > > >>>>>>>>>>>>> components
> > > >>>>>>>>>>>>>>>>> expertise
> > > >>>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
> > > >>>>> facto
> > > >>>>>>>>> current
> > > >>>>>>>>>>>>>> state).
> > > >>>>>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
> > > >>>>>>>>>> intention,
> > > >>>>>>>>>>>>> but
> > > >>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>> may
> > > >>>>>>>>>>>>>>>>>> be a
> > > >>>>>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
> > > >>>>>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
> > > >>>>>>> rule
> > > >>>>>>>>>>> anyway,
> > > >>>>>>>>>>>>>>>> intended
> > > >>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
> > > >>>>>> to
> > > >>>>>>>> just
> > > >>>>>>>>>>>>> avoid a
> > > >>>>>>>>>>>>>>>>>> situation
> > > >>>>>>>>>>>>>>>>>>>> when someone violates current uncodified state
> > > >>>>>> and
> > > >>>>>>>>>> refers
> > > >>>>>>>>>>> to
> > > >>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> bylaws
> > > >>>>>>>>>>>>>>>>>>>> which are saying merging with any committer +1
> > > >>>>>> is
> > > >>>>>>>>> always
> > > >>>>>>>>>>>>> fine
> > > >>>>>>>>>>>>>>> (like
> > > >>>>>>>>>>>>>>>>>> mine
> > > >>>>>>>>>>>>>>>>>>> +1
> > > >>>>>>>>>>>>>>>>>>>> for flink-python or flink-ml).
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> Piotrek
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
> > > >>>>> <
> > > >>>>>>>>>>>>>>> aljoscha@apache.org
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
> > > >>>>>> FLIP.
> > > >>>>>>>>> This
> > > >>>>>>>>>> is
> > > >>>>>>>>>>>>> just
> > > >>>>>>>>>>>>>>>> about
> > > >>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> voting, before that there needs to be the
> > > >>>>>>> discussion
> > > >>>>>>>>>>>>> thread. If
> > > >>>>>>>>>>>>>>>> three
> > > >>>>>>>>>>>>>>>>>>> days
> > > >>>>>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
> > > >>>>>>> (i.e. 3
> > > >>>>>>>>>>>>>>>> committers/PMCs
> > > >>>>>>>>>>>>>>>>>> have
> > > >>>>>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
> > > >>>>>> So
> > > >>>>>>>> far,
> > > >>>>>>>>>> we
> > > >>>>>>>>>>>>> have
> > > >>>>>>>>>>>>>>>> rarely
> > > >>>>>>>>>>>>>>>>>> see
> > > >>>>>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
> > > >>>>> we
> > > >>>>>>> want
> > > >>>>>>>>> to
> > > >>>>>>>>>>> use
> > > >>>>>>>>>>>>>> "lazy
> > > >>>>>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
> > > >>>>>>> that
> > > >>>>>>>>>> should
> > > >>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>> changed
> > > >>>>>>>>>>>>>>>>>>> from
> > > >>>>>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
> > > >>>>>>> current
> > > >>>>>>>>>> state
> > > >>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>> all
> > > >>>>>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
> > > >>>>>>> come
> > > >>>>>>>> up
> > > >>>>>>>>>>> with
> > > >>>>>>>>>>>>>>>> something
> > > >>>>>>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>>>> reflects the common state, according to
> > > >>>>>>>>> PMCs/commiters,
> > > >>>>>>>>>>> that
> > > >>>>>>>>>>>>>>> might
> > > >>>>>>>>>>>>>>>>>> take a
> > > >>>>>>>>>>>>>>>>>>>> very long time. In that case I think it’s
> > > >>>>> better
> > > >>>>>>> to
> > > >>>>>>>>>> adopt
> > > >>>>>>>>>>>>>>> something
> > > >>>>>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
> > > >>>>>> do
> > > >>>>>>> it
> > > >>>>>>>>>> now.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> Aljoscha
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
> > > >>>>> <
> > > >>>>>>>>>>>>>>> piotr@ververica.com
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Hi,
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
> > > >>>>> speaking
> > > >>>>>> +1
> > > >>>>>>>>> from
> > > >>>>>>>>>> my
> > > >>>>>>>>>>>>> side
> > > >>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> general idea and most of the content. I also
> > > >>>>> see
> > > >>>>>>>> merit
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> Chesney's
> > > >>>>>>>>>>>>>>>>>>>> proposal to start from the current state. I
> > > >>>>>> think
> > > >>>>>>>>> either
> > > >>>>>>>>>>>>> would
> > > >>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>> fine
> > > >>>>>>>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>>>> me.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Couple of comments:
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> 1.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
> > > >>>>> another
> > > >>>>>>>>>> committer
> > > >>>>>>>>>>>>> would
> > > >>>>>>>>>>>>>>>> slow
> > > >>>>>>>>>>>>>>>>>> down
> > > >>>>>>>>>>>>>>>>>>>> and put even more strain on the current
> > > >>>>>> reviewing
> > > >>>>>>>>>>> bottleneck
> > > >>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>>> are
> > > >>>>>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
> > > >>>>>>> context
> > > >>>>>>>>>>> switch
> > > >>>>>>>>>>>>>> cost
> > > >>>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>> quite
> > > >>>>>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
> > > >>>>>> second
> > > >>>>>>>>>> “cross”
> > > >>>>>>>>>>>>>>> committer
> > > >>>>>>>>>>>>>>>>>> could
> > > >>>>>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
> > > >>>>>>> Besides,
> > > >>>>>>>>>>> current
> > > >>>>>>>>>>>>>> setup
> > > >>>>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
> > > >>>>>>>>> required)
> > > >>>>>>>>>>>>> works
> > > >>>>>>>>>>>>>>> quite
> > > >>>>>>>>>>>>>>>>>> well
> > > >>>>>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
> > > >>>>>> the
> > > >>>>>>>>> other
> > > >>>>>>>>>>> hand
> > > >>>>>>>>>>>>>>>>> reviewing
> > > >>>>>>>>>>>>>>>>>>>> bottleneck is.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> 2.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
> > > >>>>> ask
> > > >>>>>>>>> another
> > > >>>>>>>>>>>>>>> committer
> > > >>>>>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>>>> feedback or not.
> > > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> > > >>>>>> If
> > > >>>>>>> we
> > > >>>>>>>>> are
> > > >>>>>>>>>>>>>> stating
> > > >>>>>>>>>>>>>>>>> that a
> > > >>>>>>>>>>>>>>>>>>>> single committers +1 is good enough for code
> > > >>>>>>> review,
> > > >>>>>>>>>> with
> > > >>>>>>>>>>> 0
> > > >>>>>>>>>>>>>> hours
> > > >>>>>>>>>>>>>>>>> delay
> > > >>>>>>>>>>>>>>>>>>> (de
> > > >>>>>>>>>>>>>>>>>>>> facto the current state), we should also write
> > > >>>>>>> down
> > > >>>>>>>>> that
> > > >>>>>>>>>>>>> this
> > > >>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>> subject
> > > >>>>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>> the best judgement of the committer to respect
> > > >>>>>> the
> > > >>>>>>>>>>>>> components
> > > >>>>>>>>>>>>>>>>> expertise
> > > >>>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
> > > >>>>>>> current
> > > >>>>>>>>>>> state).
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> 3.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
> > > >>>>>>>>> currently
> > > >>>>>>>>>>>>> might
> > > >>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
> > > >>>>>> if
> > > >>>>>>>>>>> respected
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>> letter.
> > > >>>>>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
> > > >>>>>>>>>> committers
> > > >>>>>>>>>>>>> with
> > > >>>>>>>>>>>>>>>>> highest
> > > >>>>>>>>>>>>>>>>>>>> expertise in the affected components managed
> > > >>>>> to
> > > >>>>>>>>> respond
> > > >>>>>>>>>> or
> > > >>>>>>>>>>>>> not.
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Piotrek
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
> > > >>>>> Schepler
> > > >>>>>> <
> > > >>>>>>>>>>>>>>>> chesnay@apache.org>
> > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
> > > >>>>>>> write
> > > >>>>>>>>> down
> > > >>>>>>>>>>>>> Bylaws
> > > >>>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>>>> reflect the current state, and then have
> > > >>>>>> separate
> > > >>>>>>>>>>>>> discussions
> > > >>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
> > > >>>>>> this
> > > >>>>>>>>>>>>> discussion
> > > >>>>>>>>>>>>>>> will
> > > >>>>>>>>>>>>>>>>>>> quickly
> > > >>>>>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
> > > >>>>>>>>> discussed
> > > >>>>>>>>>>> at
> > > >>>>>>>>>>>>>> once.
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
> > > >>>>>> Qin
> > > >>>>>>> <
> > > >>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
> > > >>>>> and
> > > >>>>>>>>>> feedback.
> > > >>>>>>>>>>>>>> Please
> > > >>>>>>>>>>>>>>>> see
> > > >>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> replies
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> below:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> > > >>>>> Change"
> > > >>>>>> we
> > > >>>>>>>>> could
> > > >>>>>>>>>>>>> also
> > > >>>>>>>>>>>>>>> add a
> > > >>>>>>>>>>>>>>>>> row
> > > >>>>>>>>>>>>>>>>>>>> for "Code
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> > > >>>>>> reference
> > > >>>>>>> to
> > > >>>>>>>>> the
> > > >>>>>>>>>>>>> FLIP
> > > >>>>>>>>>>>>>>>> process
> > > >>>>>>>>>>>>>>>>>>>> page. A
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
> > > >>>>> for
> > > >>>>>>>>>> approvals,
> > > >>>>>>>>>>>>> etc.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> > > >>>>> currently
> > > >>>>>>>>> requires
> > > >>>>>>>>>>>>> "one
> > > >>>>>>>>>>>>>> +1
> > > >>>>>>>>>>>>>>>>> from a
> > > >>>>>>>>>>>>>>>>>>>> committer
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> > > >>>>> followed
> > > >>>>>>> by a
> > > >>>>>>>>>> Lazy
> > > >>>>>>>>>>>>>>> approval
> > > >>>>>>>>>>>>>>>>> (not
> > > >>>>>>>>>>>>>>>>>>>> counting
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
> > > >>>>> to
> > > >>>>>>> lazy
> > > >>>>>>>>>>>>> majority
> > > >>>>>>>>>>>>>> if
> > > >>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>> -1
> > > >>>>>>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> received".
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
> > > >>>>>>>>> committer
> > > >>>>>>>>>>>>> always
> > > >>>>>>>>>>>>>>>>> needs a
> > > >>>>>>>>>>>>>>>>>>>> review
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
> > > >>>>>>> know
> > > >>>>>>>>> this
> > > >>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>> currently
> > > >>>>>>>>>>>>>>>>>> not
> > > >>>>>>>>>>>>>>>>>>>> always
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > > >>>>>>>> contributor
> > > >>>>>>>>>>>>> reviews
> > > >>>>>>>>>>>>>> &
> > > >>>>>>>>>>>>>>>>> +1s).
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
> > > >>>>> we
> > > >>>>>>> can
> > > >>>>>>>>>> make
> > > >>>>>>>>>>> it
> > > >>>>>>>>>>>>>> easy
> > > >>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>> follow the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> > > >>>>>> Flink-specific
> > > >>>>>>>> Jira
> > > >>>>>>>>>>>>>> workflows
> > > >>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>> ticket
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> types +
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
> > > >>>>> is
> > > >>>>>>>>>> certainly
> > > >>>>>>>>>>>>>> "Step
> > > >>>>>>>>>>>>>>>> 2",
> > > >>>>>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>>>>>> believe,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> > > >>>>>>> transparent
> > > >>>>>>>>> as
> > > >>>>>>>>>>>>>> possible,
> > > >>>>>>>>>>>>>>>>>>>> otherwise they
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> & Re: Till
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> > > >>>>>>> author
> > > >>>>>>>>> and
> > > >>>>>>>>>>>>>> getting
> > > >>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>> +1
> > > >>>>>>>>>>>>>>>>>>> from
> > > >>>>>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> > > >>>>>> should
> > > >>>>>>>> know
> > > >>>>>>>>>>> when
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>> ask
> > > >>>>>>>>>>>>>>>>>>> another
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
> > > >>>>> I
> > > >>>>>>>> would
> > > >>>>>>>>>> not
> > > >>>>>>>>>>>>>> enforce
> > > >>>>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> > > >>>>> author
> > > >>>>>>> is
> > > >>>>>>>> a
> > > >>>>>>>>>>>>> committer
> > > >>>>>>>>>>>>>>> but
> > > >>>>>>>>>>>>>>>>> of
> > > >>>>>>>>>>>>>>>>>>>> course
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
> > > >>>>> here.
> > > >>>>>>>> TBH,
> > > >>>>>>>>> in
> > > >>>>>>>>>>>>> Kafka
> > > >>>>>>>>>>>>>>>>>>> occasionally
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
> > > >>>>> still
> > > >>>>>>>>> merged
> > > >>>>>>>>>>>>> without
> > > >>>>>>>>>>>>>>>>>> following
> > > >>>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
> > > >>>>> rare.
> > > >>>>>>>> That
> > > >>>>>>>>>>> said,
> > > >>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>> still
> > > >>>>>>>>>>>>>>>>>> think
> > > >>>>>>>>>>>>>>>>>>>> an
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
> > > >>>>> sense
> > > >>>>>>> due
> > > >>>>>>>>> to
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>> following
> > > >>>>>>>>>>>>>>>>>>>> reasons:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
> > > >>>>>> to
> > > >>>>>>>> make
> > > >>>>>>>>>>> sure
> > > >>>>>>>>>>>>>> every
> > > >>>>>>>>>>>>>>>>> patch
> > > >>>>>>>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
> > > >>>>>>>> little
> > > >>>>>>>>>>>>> difficult
> > > >>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>> guarantee if
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
> > > >>>>>>> many
> > > >>>>>>>>>>>>> reasons. In
> > > >>>>>>>>>>>>>>>> some
> > > >>>>>>>>>>>>>>>>>>>> cases, a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
> > > >>>>> knowledge
> > > >>>>>>>> about
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>>>> project
> > > >>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>> make
> > > >>>>>>>>>>>>>>>>>>>> a good
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
> > > >>>>>> contributors
> > > >>>>>>>> are
> > > >>>>>>>>>> more
> > > >>>>>>>>>>>>>>> eagerly
> > > >>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>> get a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
> > > >>>>>> willing
> > > >>>>>>>> to
> > > >>>>>>>>>>> lower
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> review
> > > >>>>>>>>>>>>>>>>>>> bar.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
> > > >>>>>> among
> > > >>>>>>>>>>>>> committers,
> > > >>>>>>>>>>>>>>>> which
> > > >>>>>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>>>>>> personally
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
> > > >>>>>>> form
> > > >>>>>>>>>>>>> consistent
> > > >>>>>>>>>>>>>>>> design
> > > >>>>>>>>>>>>>>>>>>>> principles
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
> > > >>>>>>>> committers
> > > >>>>>>>>>> will
> > > >>>>>>>>>>>>> know
> > > >>>>>>>>>>>>>>> how
> > > >>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> other
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
> > > >>>>>> from
> > > >>>>>>>> each
> > > >>>>>>>>>>>>> other.
> > > >>>>>>>>>>>>>> So
> > > >>>>>>>>>>>>>>>> they
> > > >>>>>>>>>>>>>>>>>>> tend
> > > >>>>>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
> > > >>>>>>> things
> > > >>>>>>>>>> should
> > > >>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>> done
> > > >>>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>>>>> general.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
> > > >>>>>>>> consider
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>>>> following
> > > >>>>>>>>>>>>>>>>> two
> > > >>>>>>>>>>>>>>>>>>>> scenarios:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
> > > >>>>> a
> > > >>>>>>> lot
> > > >>>>>>>> of
> > > >>>>>>>>>>>>>>> iterations.
> > > >>>>>>>>>>>>>>>>> Then
> > > >>>>>>>>>>>>>>>>>>>> the patch
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
> > > >>>>>> time
> > > >>>>>>>>>> because
> > > >>>>>>>>>>>>> there
> > > >>>>>>>>>>>>>>> are
> > > >>>>>>>>>>>>>>>>>>> things
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
> > > >>>>> changed.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
> > > >>>>> very
> > > >>>>>>>> smooth
> > > >>>>>>>>>> and
> > > >>>>>>>>>>>>>> quick,
> > > >>>>>>>>>>>>>>>> so
> > > >>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> patch is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
> > > >>>>> patch
> > > >>>>>>> does
> > > >>>>>>>>> not
> > > >>>>>>>>>>>>> take
> > > >>>>>>>>>>>>>>> much
> > > >>>>>>>>>>>>>>>>>> time.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
> > > >>>>>> patch
> > > >>>>>>>>> from a
> > > >>>>>>>>>>>>>>> committer
> > > >>>>>>>>>>>>>>>>>> falls
> > > >>>>>>>>>>>>>>>>>>>> either in
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
> > > >>>>> is
> > > >>>>>>> to
> > > >>>>>>>>>> review
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>> patch
> > > >>>>>>>>>>>>>>>>>>>> because
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
> > > >>>>> needs
> > > >>>>>>> to
> > > >>>>>>>> be
> > > >>>>>>>>>>>>>> reviewed.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
> > > >>>>>> take
> > > >>>>>>>>> much
> > > >>>>>>>>>>> time
> > > >>>>>>>>>>>>>>>> anyways.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
> > > >>>>>>> case
> > > >>>>>>>> 1
> > > >>>>>>>>> if
> > > >>>>>>>>>>> we
> > > >>>>>>>>>>>>>> skip
> > > >>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> cross-review.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Robert
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
> > > >>>>>> and
> > > >>>>>>>> made
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>>>>> following
> > > >>>>>>>>>>>>>>>>>>>> modifications
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
> > > >>>>> section.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
> > > >>>>>> to
> > > >>>>>>>>>>>>> "consensus"
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>> align
> > > >>>>>>>>>>>>>>>>>>> with
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
> > > >>>>> and
> > > >>>>>>>> other
> > > >>>>>>>>>>>>>> projects.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> > > >>>>> unnecessary
> > > >>>>>>>>> noise.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
> > > >>>>>> 2/3
> > > >>>>>>>>>>> majority
> > > >>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>> still
> > > >>>>>>>>>>>>>>>>>>>> feasible in
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> practice.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> > > >>>>> the
> > > >>>>>>>> draft
> > > >>>>>>>>>>>>> compared
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>> existing
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
> > > >>>>>>>>> highlight
> > > >>>>>>>>>>>>> these
> > > >>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>> discuss
> > > >>>>>>>>>>>>>>>>>>>> them
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
> > > >>>>>>> familiar
> > > >>>>>>>>>> enough
> > > >>>>>>>>>>>>> with
> > > >>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>> current Flink
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
> > > >>>>> saw
> > > >>>>>>> you
> > > >>>>>>>>>>>>> commented
> > > >>>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>>>> some
> > > >>>>>>>>>>>>>>>>>>> part
> > > >>>>>>>>>>>>>>>>>>>> in the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> > > >>>>>>> bylaws?
> > > >>>>>>>>> I’m
> > > >>>>>>>>>>>>> asking
> > > >>>>>>>>>>>>>>>>> because
> > > >>>>>>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>>>>>> quite
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> > > >>>>> essentially
> > > >>>>>>>>> adopting
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>>>>>> Kafka
> > > >>>>>>>>>>>>>>>>>>> bylaws.
> > > >>>>>>>>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> > > >>>>>> try
> > > >>>>>>>> to
> > > >>>>>>>>>>>>> re-invent
> > > >>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>> wheel
> > > >>>>>>>>>>>>>>>>>>>> here.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
> > > >>>>> version
> > > >>>>>>> of
> > > >>>>>>>>> the
> > > >>>>>>>>>>>>> draft
> > > >>>>>>>>>>>>>> was
> > > >>>>>>>>>>>>>>>>>> almost
> > > >>>>>>>>>>>>>>>>>>>> identical
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
> > > >>>>> caught a
> > > >>>>>>> few
> > > >>>>>>>>>>>>>> inconsistent
> > > >>>>>>>>>>>>>>>>>> places.
> > > >>>>>>>>>>>>>>>>>>>> So it
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
> > > >>>>>> make
> > > >>>>>>>> sure
> > > >>>>>>>>>> we
> > > >>>>>>>>>>>>> truly
> > > >>>>>>>>>>>>>>>> agree
> > > >>>>>>>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>>>>>>>> them.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
> > > >>>>>>>> shortly
> > > >>>>>>>>>>> after
> > > >>>>>>>>>>>>>>>> adoption.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
> > > >>>>> valuable
> > > >>>>>>>>>> feedback.
> > > >>>>>>>>>>>>> These
> > > >>>>>>>>>>>>>>> are
> > > >>>>>>>>>>>>>>>>>> great
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> discussion.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
> > > >>>>> Aljoscha
> > > >>>>>>>>> Krettek
> > > >>>>>>>>>> <
> > > >>>>>>>>>>>>>>>>>>>> aljoscha@apache.org>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Big +1
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> > > >>>>>>> bylaws?
> > > >>>>>>>>> I’m
> > > >>>>>>>>>>>>> asking
> > > >>>>>>>>>>>>>>>>>> because I
> > > >>>>>>>>>>>>>>>>>>>> quite
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> > > >>>>> essentially
> > > >>>>>>>>> adopting
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>>>>>> Kafka
> > > >>>>>>>>>>>>>>>>>>> bylaws.
> > > >>>>>>>>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> > > >>>>>> try
> > > >>>>>>>> to
> > > >>>>>>>>>>>>> re-invent
> > > >>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>> wheel
> > > >>>>>>>>>>>>>>>>>>>> here.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
> > > >>>>>>>>>> “committer
> > > >>>>>>>>>>>>> +1”
> > > >>>>>>>>>>>>>>>>>>> requirement.
> > > >>>>>>>>>>>>>>>>>>>> We
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
> > > >>>>> would
> > > >>>>>>>>> actually
> > > >>>>>>>>>>> be
> > > >>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>> favour
> > > >>>>>>>>>>>>>>>>>> of
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> requiring
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
> > > >>>>>>>>>> complicated.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
> > > >>>>>> Rohrmann
> > > >>>>>>> <
> > > >>>>>>>>>>>>>>>>>> trohrmann@apache.org>
> > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
> > > >>>>>>>> Becket.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
> > > >>>>> emeritus
> > > >>>>>>> (or
> > > >>>>>>>>>> active
> > > >>>>>>>>>>>>> vs.
> > > >>>>>>>>>>>>>>>>>> inactive),
> > > >>>>>>>>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> won't
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
> > > >>>>> vote
> > > >>>>>>>>> because
> > > >>>>>>>>>>> we
> > > >>>>>>>>>>>>>>> already
> > > >>>>>>>>>>>>>>>>>> have
> > > >>>>>>>>>>>>>>>>>>>> too
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> many
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> > > >>>>>>>> author
> > > >>>>>>>>>> and
> > > >>>>>>>>>>>>>>> getting a
> > > >>>>>>>>>>>>>>>>> +1
> > > >>>>>>>>>>>>>>>>>>>> from a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> > > >>>>>> should
> > > >>>>>>>>> know
> > > >>>>>>>>>>>>> when to
> > > >>>>>>>>>>>>>>> ask
> > > >>>>>>>>>>>>>>>>>>> another
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
> > > >>>>> Hence, I
> > > >>>>>>>> would
> > > >>>>>>>>>> not
> > > >>>>>>>>>>>>>>> enforce
> > > >>>>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> > > >>>>>> author
> > > >>>>>>>> is a
> > > >>>>>>>>>>>>>> committer
> > > >>>>>>>>>>>>>>>> but
> > > >>>>>>>>>>>>>>>>> of
> > > >>>>>>>>>>>>>>>>>>>> course
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Till
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
> > > >>>>> Chesnay
> > > >>>>>>>>>> Schepler
> > > >>>>>>>>>>> <
> > > >>>>>>>>>>>>>>>>>>>> chesnay@apache.org>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> > > >>>>>>> unnecessary
> > > >>>>>>>>>> noise.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> > > >>>>>> the
> > > >>>>>>>>> draft
> > > >>>>>>>>>>>>>> compared
> > > >>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>> existing
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
> > > >>>>> to
> > > >>>>>>>>>> highlight
> > > >>>>>>>>>>>>>> these
> > > >>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>> discuss
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> them
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
> > > >>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
> > > >>>>> this
> > > >>>>>>>>>>> discussion
> > > >>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>> creating
> > > >>>>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>>>> draft
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> > > >>>>> that
> > > >>>>>> a
> > > >>>>>>>>>>> committer
> > > >>>>>>>>>>>>>>> always
> > > >>>>>>>>>>>>>>>>>> needs
> > > >>>>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> review
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> > > >>>>>> as I
> > > >>>>>>>>> know
> > > >>>>>>>>>>>>> this is
> > > >>>>>>>>>>>>>>>>>> currently
> > > >>>>>>>>>>>>>>>>>>>> not
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > > >>>>>>>>>> contributor
> > > >>>>>>>>>>>>>>> reviews
> > > >>>>>>>>>>>>>>>> &
> > > >>>>>>>>>>>>>>>>>>> +1s).
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
> > > >>>>> if
> > > >>>>>>> we
> > > >>>>>>>>> had
> > > >>>>>>>>>>>>> cases
> > > >>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>> past
> > > >>>>>>>>>>>>>>>>>>>> where
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> code
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
> > > >>>>> we
> > > >>>>>>>>> believe
> > > >>>>>>>>>>>>> that we
> > > >>>>>>>>>>>>>>>> have
> > > >>>>>>>>>>>>>>>>>>> enough
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> capacity
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
> > > >>>>>>>> approval.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> > > >>>>>>>> Konstantin
> > > >>>>>>>>>>> Knauf
> > > >>>>>>>>>>>>> <
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
> > > >>>>>>> Becket. I
> > > >>>>>>>>>> have
> > > >>>>>>>>>>>>> two
> > > >>>>>>>>>>>>>>>> remarks
> > > >>>>>>>>>>>>>>>>>>>> regarding
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> > > >>>>>>> Change"
> > > >>>>>>>> we
> > > >>>>>>>>>>> could
> > > >>>>>>>>>>>>>> also
> > > >>>>>>>>>>>>>>>>> add a
> > > >>>>>>>>>>>>>>>>>>>> row for
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Code
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> > > >>>>>>>> reference
> > > >>>>>>>>> to
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>>>>> FLIP
> > > >>>>>>>>>>>>>>>>>> process
> > > >>>>>>>>>>>>>>>>>>>> page.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> A
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
> > > >>>>> rules
> > > >>>>>>> for
> > > >>>>>>>>>>>>> approvals,
> > > >>>>>>>>>>>>>>> etc.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> > > >>>>>>> currently
> > > >>>>>>>>>>> requires
> > > >>>>>>>>>>>>>> "one
> > > >>>>>>>>>>>>>>>> +1
> > > >>>>>>>>>>>>>>>>>>> from a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> > > >>>>>>> followed
> > > >>>>>>>>> by a
> > > >>>>>>>>>>>>> Lazy
> > > >>>>>>>>>>>>>>>>> approval
> > > >>>>>>>>>>>>>>>>>>> (not
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> counting
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
> > > >>>>> moving
> > > >>>>>>> to
> > > >>>>>>>>> lazy
> > > >>>>>>>>>>>>>> majority
> > > >>>>>>>>>>>>>>>> if
> > > >>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>> -1
> > > >>>>>>>>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> received".
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> > > >>>>>> that a
> > > >>>>>>>>>>> committer
> > > >>>>>>>>>>>>>>> always
> > > >>>>>>>>>>>>>>>>>>> needs a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> review
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> > > >>>>>> as I
> > > >>>>>>>>> know
> > > >>>>>>>>>>>>> this is
> > > >>>>>>>>>>>>>>>>>> currently
> > > >>>>>>>>>>>>>>>>>>>> not
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > > >>>>>>>>>> contributor
> > > >>>>>>>>>>>>>>> reviews
> > > >>>>>>>>>>>>>>>> &
> > > >>>>>>>>>>>>>>>>>>> +1s).
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
> > > >>>>>> how
> > > >>>>>>>> we
> > > >>>>>>>>>> can
> > > >>>>>>>>>>>>> make
> > > >>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>> easy
> > > >>>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>> follow
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> > > >>>>>>>> Flink-specific
> > > >>>>>>>>>> Jira
> > > >>>>>>>>>>>>>>>> workflows
> > > >>>>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>> ticket
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> types +
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
> > > >>>>>> this
> > > >>>>>>> is
> > > >>>>>>>>>>>>> certainly
> > > >>>>>>>>>>>>>>>> "Step
> > > >>>>>>>>>>>>>>>>>> 2",
> > > >>>>>>>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> believe,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> > > >>>>>>>>> transparent
> > > >>>>>>>>>>> as
> > > >>>>>>>>>>>>>>>> possible,
> > > >>>>>>>>>>>>>>>>>>>> otherwise
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> they
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
> > > >>>>>> Becket
> > > >>>>>>>>> Qin <
> > > >>>>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
> > > >>>>>> process
> > > >>>>>>>>>>> discussion
> > > >>>>>>>>>>>>>>> thread
> > > >>>>>>>>>>>>>>>>>> [1],
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> currently
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
> > > >>>>>>> govern
> > > >>>>>>>>> the
> > > >>>>>>>>>>>>>>> operation
> > > >>>>>>>>>>>>>>>> of
> > > >>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> project.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
> > > >>>>>> community
> > > >>>>>>>> to
> > > >>>>>>>>>>>>>> coordinate
> > > >>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>> contribute
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
> > > >>>>>>> other
> > > >>>>>>>>>>>>> processes
> > > >>>>>>>>>>>>>>> such
> > > >>>>>>>>>>>>>>>>> as
> > > >>>>>>>>>>>>>>>>>>>> FLIP.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
> > > >>>>> page
> > > >>>>>>> and
> > > >>>>>>>>>> would
> > > >>>>>>>>>>>>> like
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>> start a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> discussion
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
> > > >>>>> in
> > > >>>>>>> the
> > > >>>>>>>>>>>>> community.
> > > >>>>>>>>>>>>>>>> It'll
> > > >>>>>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>>>> great to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> hear
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
> > > >>>>>> Architect
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
> > > >>>>>>>> 31.08.2019,
> > > >>>>>>>>>>>>> 05.09. -
> > > >>>>>>>>>>>>>>>>>>> 06.09.2010
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
> > > >>>>>> 115,
> > > >>>>>>>>> 10115
> > > >>>>>>>>>>>>>> Berlin,
> > > >>>>>>>>>>>>>>>>>> Germany
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
> > > >>>>>>>> Charlottenburg:
> > > >>>>>>>>>> HRB
> > > >>>>>>>>>>>>>> 158244
> > > >>>>>>>>>>>>>>> B
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
> > > >>>>>>> Tzoumas,
> > > >>>>>>>>> Dr.
> > > >>>>>>>>>>>>> Stephan
> > > >>>>>>>>>>>>>>>> Ewen
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
> >
>

Re: [DISCUSS] Flink project bylaws

[Becket Qin <be...@gmail.com>]

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 <rm...@apache.org> wrote:

> Hi Becket,
> I've applied the proposed change to the document:
>
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026&selectedPageVersions=20&selectedPageVersions=19
>
> I would propose to stop accepting changes to the document now, as it might
> start a discussion about the validity of the vote and the bylaws itself.
> Changes to the document require a 2/3 majority.
>
>
> On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels <mx...@apache.org>
> wrote:
>
> > Hi Becket,
> >
> > Thanks for clarifying and updating the draft. The changes look good to
> me.
> >
> > I don't feel strong about a 2/3 majority in case of committer/PMC
> > removal. Like you pointed out, both provide a significant hurdle due to
> > possible vetos or a 2/3 majority.
> >
> > Thanks,
> > Max
> >
> > On 13.08.19 10:36, Becket Qin wrote:
> > > Piotr just reminded me that there was a previous suggestion to clarify
> a
> > > committer's responsibility when commit his/her own patch. So I'd like
> to
> > > incorporate that in the bylaws. The additional clarification is
> following
> > > in bold and italic font.
> > >
> > > one +1 from a committer followed by a Lazy approval (not counting the
> > vote
> > >> of the contributor), moving to lazy majority if a -1 is received.
> > >>
> > >
> > >
> > > Note that this implies that committers can +1 their own commits and
> merge
> > >> right away. *However, the committe**rs should use their best judgement
> > to
> > >> respect the components expertise and ongoing development plan.*
> > >
> > >
> > > This does not really change any of the existing bylaws, just about
> > > clarification.
> > >
> > > If there is no objection to this additional clarification, after the
> > bylaws
> > > wiki is updated, I'll send an update notice to the voting thread to
> > inform
> > > those who already voted about this addition.
> > >
> > > Thanks,
> > >
> > > Jiangjie (Becket) Qin
> > >
> > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin <be...@gmail.com>
> > wrote:
> > >
> > >> Hi Maximillian,
> > >>
> > >> Thanks for the feedback. Please see the reply below:
> > >>
> > >> Step 2 should include a personal email to the PMC members in question.
> > >>
> > >> I'm afraid reminders inside the vote thread could be overlooked
> easily.
> > >>
> > >>
> > >> This is exactly what I meant to say by "reach out" :) I just made it
> > more
> > >> explicit.
> > >>
> > >> The way the terms are described in the draft, the consensus is "lazy",
> > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy
> > >>> Consensus". This is in line with the other definitions such as "Lazy
> > >>> Majority".
> > >>
> > >> It was initially called "lazy consensus", but Robert pointed out that
> > >> "lazy consensus" actually means something different in ASF term [1].
> > >> Here "lazy" pretty much means "assume everyone is +1 unless someone
> says
> > >> otherwise". This means any vote that requires a minimum number of +1
> is
> > not
> > >> really a "lazy" vote.
> > >>
> > >> Removing a committer / PMC member only requires 3 binding votes. I'd
> > >>> expect an important action like this to require a 2/3 majority.
> > >>
> > >> Personally I think consensus is good enough here. PMC members can
> cast a
> > >> veto if they disagree about the removal. In some sense, it is more
> > >> difficult than with 2/3 majority to remove a committer / PMC member.
> > Also,
> > >> it might be a hard decision for some PMC members if they have never
> > worked
> > >> with the person in question. That said, I am OK to change it to 2/3
> > >> majority as this will happen very rarely.
> > >>
> > >> Thanks,
> > >>
> > >> Jiangjie (Becket) Qin
> > >>
> > >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus
> > >>
> > >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <mx...@apache.org>
> > wrote:
> > >>
> > >>> I'm a bit late to the discussion here. Three suggestions:
> > >>>
> > >>> 1) Procedure for "insufficient active binding voters to reach 2/3
> > majority
> > >>>
> > >>>>     1. Wait until the minimum length of the voting passes.
> > >>>>     2. Publicly reach out to the remaining binding voters in the
> > voting
> > >>> mail thread for at least 2 attempts with at least 7 days between two
> > >>> attempts.
> > >>>>     3. If the binding voter being contacted still failed to respond
> > >>> after all the attempts, the binding voter will be considered as
> > inactive
> > >>> for the purpose of this particular voting.
> > >>>
> > >>> Step 2 should include a personal email to the PMC members in
> question.
> > >>> I'm afraid reminders inside the vote thread could be overlooked
> easily.
> > >>>
> > >>> 2) "Consensus" => "Lazy Consensus"
> > >>>
> > >>> The way the terms are described in the draft, the consensus is
> "lazy",
> > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy
> > >>> Consensus". This is in line with the other definitions such as "Lazy
> > >>> Majority".
> > >>>
> > >>> 3) Committer / PMC Removal
> > >>>
> > >>> Removing a committer / PMC member only requires 3 binding votes. I'd
> > >>> expect an important action like this to require a 2/3 majority.
> > >>>
> > >>>
> > >>> Do you think we could incorporate those suggestions?
> > >>>
> > >>> Thanks,
> > >>> Max
> > >>>
> > >>> On 11.08.19 10:14, Becket Qin wrote:
> > >>>> Hi folks,
> > >>>>
> > >>>> Thanks for all the discussion and support. I have started the voting
> > >>> thread.
> > >>>>
> > >>>>
> > >>>
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Jiangjie (Becket) Qin
> > >>>>
> > >>>> On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <fh...@gmail.com>
> > wrote:
> > >>>>
> > >>>>> Thanks for the update and driving the discussion Becket!
> > >>>>> +1 for starting a vote.
> > >>>>>
> > >>>>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
> > >>> becket.qin@gmail.com
> > >>>>>> :
> > >>>>>
> > >>>>>> Thanks Stephan.
> > >>>>>>
> > >>>>>> I think we have resolved all the comments on the wiki page. There
> > are
> > >>> two
> > >>>>>> minor changes made to the bylaws since last week.
> > >>>>>> 1. For 2/3 majority, the required attempts to reach out to binding
> > >>> voters
> > >>>>>> is reduced from 3 to 2. This helps shorten the voting process a
> > little
> > >>>>> bit.
> > >>>>>> 2. Clarified what is considered as the adoption of new codebase.
> > >>>>>>
> > >>>>>> I think we almost reached consensus. I'll start a voting thread in
> > two
> > >>>>> days
> > >>>>>> if there is no new concerns.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>>
> > >>>>>> Jiangjie (Becket) Qin
> > >>>>>>
> > >>>>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org>
> > wrote:
> > >>>>>>
> > >>>>>>> I added a clarification to the table, clarifying that the current
> > >>>>>> phrasing
> > >>>>>>> means that committers do not need another +1 for their commits.
> > >>>>>>>
> > >>>>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fhueske@gmail.com
> >
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Hi Becket,
> > >>>>>>>>
> > >>>>>>>> Thanks a lot for pushing this forward and addressing the
> feedback.
> > >>>>>>>> I'm very happy with the current state of the bylaws.
> > >>>>>>>> +1 to wait until Friday before starting a vote.
> > >>>>>>>>
> > >>>>>>>> Best, Fabian
> > >>>>>>>>
> > >>>>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> > >>>>>>>> becket.qin@gmail.com
> > >>>>>>>>> :
> > >>>>>>>>
> > >>>>>>>>> Hi Everyone,
> > >>>>>>>>>
> > >>>>>>>>> Thanks for all the discussion and feedback.
> > >>>>>>>>>
> > >>>>>>>>> It seems that we have almost reached consensus. I'll leave the
> > >>>>>>> discussion
> > >>>>>>>>> thread open until this Friday. If there is no more concerns
> > raised,
> > >>>>>>> I'll
> > >>>>>>>>> start a voting thread after that.
> > >>>>>>>>>
> > >>>>>>>>> Thanks,
> > >>>>>>>>>
> > >>>>>>>>> Jiangjie (Becket) Qin
> > >>>>>>>>>
> > >>>>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com>
> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Hi Becket,
> > >>>>>>>>>>
> > >>>>>>>>>> Thanks for noticing and resolving my comment around PMC
> removal
> > >>>>> and
> > >>>>>>> ASF
> > >>>>>>>>>> rules of PMC membership change process, which you seem to
> > neglect
> > >>>>>> in
> > >>>>>>>> the
> > >>>>>>>>>> summary of updates (smile).
> > >>>>>>>>>>
> > >>>>>>>>>> Best Regards,
> > >>>>>>>>>> Yu
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <
> becket.qin@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Hi folks,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks for all the feedback.
> > >>>>>>>>>>>
> > >>>>>>>>>>> It seems that there are a few concerns over the emeritus
> status
> > >>>>>>>> after 6
> > >>>>>>>>>>> months of inactivity. Given that the main purpose is just to
> > >>>>> make
> > >>>>>>>> sure
> > >>>>>>>>>> 2/3
> > >>>>>>>>>>> majority can pass and we sort of have a solution for that, I
> > >>>>> just
> > >>>>>>>>> updated
> > >>>>>>>>>>> the draft with the following changes:
> > >>>>>>>>>>>
> > >>>>>>>>>>> 1. Removed the inactivity term for emeritus committers /
> PMCs.
> > >>>>> A
> > >>>>>>>>>> committer
> > >>>>>>>>>>> / PMC will only be considered emeritus by their own claim.
> > >>>>>>>>>>> 2. Removed the approval process for reinstatement of the
> > >>>>> emeritus
> > >>>>>>>>>>> committers / PMCs. An emeritus committer / PMC will be
> > >>>>> reinstated
> > >>>>>>>> when
> > >>>>>>>>>> they
> > >>>>>>>>>>> send an email to the private@flink.apache.org.
> > >>>>>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still
> doable
> > >>>>>> when
> > >>>>>>>>> there
> > >>>>>>>>>>> are non-emeritus committers / PMCs who do not cast the vote.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Please let me know if you have any further thoughts.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Jiangjie (Becket) Qin
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
> > >>>>>> becket.qin@gmail.com>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi Fabian,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Thanks for the feedback.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I agree that if we don't like emeritus committers / PMCs, we
> > >>>>>>> don't
> > >>>>>>>>> have
> > >>>>>>>>>>> to
> > >>>>>>>>>>>> do it. That said, emeritus status simply means whether an
> > >>>>>>>> individual
> > >>>>>>>>> is
> > >>>>>>>>>>>> active / inactive in the community. It does not make the
> > >>>>> merits
> > >>>>>>>>> earned
> > >>>>>>>>>> to
> > >>>>>>>>>>>> go away. For our purpose, emeritus status is mostly just a
> > >>>>> way
> > >>>>>> to
> > >>>>>>>>> make
> > >>>>>>>>>>> 2/3
> > >>>>>>>>>>>> majority possible. As you noticed, since reaching out to
> > >>>>>> binding
> > >>>>>>>>> voters
> > >>>>>>>>>>> who
> > >>>>>>>>>>>> have not voted can achieve the same goal, the emeritus
> status
> > >>>>>> is
> > >>>>>>>> more
> > >>>>>>>>>> of
> > >>>>>>>>>>> an
> > >>>>>>>>>>>> optimization so we don't have to ping the inactive binding
> > >>>>>> voters
> > >>>>>>>>> every
> > >>>>>>>>>>>> time and wait for long. However, given that 2/3 majority
> > >>>>>> votings
> > >>>>>>>> are
> > >>>>>>>>>>> rare,
> > >>>>>>>>>>>> such communication cost is probably OK. So I think we can
> > >>>>>> remove
> > >>>>>>>> that
> > >>>>>>>>>>>> emeritus part from the bylaws.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 1) We should add to the requirements of the PMC that they
> > >>>>> need
> > >>>>>> to
> > >>>>>>>>> make
> > >>>>>>>>>>>>> sure the project complies with brand issues and reports
> > >>>>> misuse
> > >>>>>>> of
> > >>>>>>>>> ASF
> > >>>>>>>>>>>>> brands.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Good point. Added.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
> > >>>>> a
> > >>>>>> 3
> > >>>>>>>> day
> > >>>>>>>>>> vote
> > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> This might be a little tricky because people are from
> > >>>>> countries
> > >>>>>>> in
> > >>>>>>>>>>>> different time zones and with different holidays, and so on.
> > >>>>> If
> > >>>>>>> we
> > >>>>>>>>> are
> > >>>>>>>>>>>> worrying about 3 days minimum length is not enough for those
> > >>>>>> who
> > >>>>>>>> want
> > >>>>>>>>>> to
> > >>>>>>>>>>>> give feedback, we can make it 5 days.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 3) Do we need a process do decide about removal of features
> > >>>>>> (like
> > >>>>>>>> the
> > >>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
> > >>>>>> Python
> > >>>>>>>>>> APIs)?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I assume such action should be covered by FLIP as it is a
> > >>>>>> change
> > >>>>>>> to
> > >>>>>>>>> the
> > >>>>>>>>>>>> API and probably needs a migration plan. It would be useful
> > >>>>> to
> > >>>>>>>> have a
> > >>>>>>>>>>>> formal deprecation procedure. But that might be better to be
> > >>>>>> put
> > >>>>>>>> into
> > >>>>>>>>>>>> somewhere else because the bylaws are primarily focusing on
> > >>>>> the
> > >>>>>>>>>>>> non-technical rules, whereas the deprecation seems more on
> > >>>>> the
> > >>>>>>>>>> technical
> > >>>>>>>>>>>> side.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Jiangjie (Becket) Qin
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
> > >>>>>>> fhueske@gmail.com>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> First of all thank you very much Becket for starting this
> > >>>>>>>>> discussion!
> > >>>>>>>>>>>>> I think it is a very good idea and overdue to formally
> > >>>>> define
> > >>>>>>> some
> > >>>>>>>>> of
> > >>>>>>>>>>> our
> > >>>>>>>>>>>>> community processes.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Similar to Chesnay, I have concerns about the distinction
> > >>>>>>> between
> > >>>>>>>>>> active
> > >>>>>>>>>>>>> and non-active / emeritus committers and PMC members.
> > >>>>>>>>>>>>> My foremost concern is that this is not in the spirit of
> the
> > >>>>>>>> Apache
> > >>>>>>>>>> Way
> > >>>>>>>>>>>>> [1]
> > >>>>>>>>>>>>> which is (among other things) based on the idea of merit
> > >>>>> which
> > >>>>>>>> once
> > >>>>>>>>>>>>> earned,
> > >>>>>>>>>>>>> does not go away over time.
> > >>>>>>>>>>>>> I know other projects like Hadoop and Kafka have similar
> > >>>>>> clauses
> > >>>>>>>> in
> > >>>>>>>>>> the
> > >>>>>>>>>>>>> bylaws but IMO we don't need to adopt them if we don't like
> > >>>>>>> them.
> > >>>>>>>>>>>>> For example, I don't like the idea that committers or PMC
> > >>>>>>> members
> > >>>>>>>>> who
> > >>>>>>>>>>> are
> > >>>>>>>>>>>>> temporarily away from the project (for whatever reason:
> > >>>>>> parental
> > >>>>>>>>>> leave,
> > >>>>>>>>>>>>> sabbatical, health issues, etc.) need the PMC approval to
> be
> > >>>>>>>>> "active"
> > >>>>>>>>>>>>> again.
> > >>>>>>>>>>>>> As far as I am aware, we have not seen any issues with
> > >>>>>> inactive
> > >>>>>>>>>> members
> > >>>>>>>>>>> in
> > >>>>>>>>>>>>> the past.
> > >>>>>>>>>>>>> Moreover, it would be hard to track whether somebody became
> > >>>>>>>> inactive
> > >>>>>>>>>> at
> > >>>>>>>>>>>>> some point in time (which we would need to do, if I
> > >>>>> understand
> > >>>>>>> the
> > >>>>>>>>>>>>> proposal
> > >>>>>>>>>>>>> correctly).
> > >>>>>>>>>>>>> With the approach that Becket suggested in his last email
> > >>>>>>>> (reaching
> > >>>>>>>>>> out
> > >>>>>>>>>>> to
> > >>>>>>>>>>>>> binding voters who haven't voted yet), we could drop the
> > >>>>>>>> distinction
> > >>>>>>>>>>>>> between active and non-active committers and PMC members.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I also have a few minor comments:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 1) We should add to the requirements of the PMC [2] that
> > >>>>> they
> > >>>>>>> need
> > >>>>>>>>> to
> > >>>>>>>>>>> make
> > >>>>>>>>>>>>> sure the project complies with brand issues and reports
> > >>>>> misuse
> > >>>>>>> of
> > >>>>>>>>> ASF
> > >>>>>>>>>>>>> brands.
> > >>>>>>>>>>>>> 2) Do we want to restrict voting days to working days,
> i.e.,
> > >>>>>> a 3
> > >>>>>>>> day
> > >>>>>>>>>>> vote
> > >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > >>>>>>>>>>>>> 3) Do we need a process do decide about removal of features
> > >>>>>>> (like
> > >>>>>>>>> the
> > >>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
> > >>>>>> Python
> > >>>>>>>>>> APIs)?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thank you,
> > >>>>>>>>>>>>> Fabian
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> [1] https://www.apache.org/theapacheway/
> > >>>>>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> > >>>>>>>>>>>>> becket.qin@gmail.com
> > >>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Hi Hequn,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see the reply
> > >>>>>> below:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one PMC
> > >>>>> in
> > >>>>>>>> the 3
> > >>>>>>>>>>>>> binding
> > >>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> > >>>>> and 1
> > >>>>>>>> PMC.
> > >>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> > >>>>> somehow
> > >>>>>>> be a
> > >>>>>>>>> big
> > >>>>>>>>>>>>>> feature
> > >>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
> > >>>>> loss
> > >>>>>>> of
> > >>>>>>>>>>>>> flexibility
> > >>>>>>>>>>>>>>> as committers also have a chance to vote and participate
> > >>>>>> in
> > >>>>>>>> it.
> > >>>>>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs are
> > >>>>> the
> > >>>>>>>>>> following:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 1. Generally speaking, the PMC's primary responsibility is
> > >>>>>>>>> operating
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>>> project and deciding what software to release on behalf of
> > >>>>>>> ASF.
> > >>>>>>>>>>>>> Committers,
> > >>>>>>>>>>>>>> on the other hand, are responsible for the technical part
> > >>>>> of
> > >>>>>>> the
> > >>>>>>>>>>>>> project.
> > >>>>>>>>>>>>>> So for FLIPs, a PMC's vote probably should not outweigh a
> > >>>>>>>>>> committer's
> > >>>>>>>>>>>>> vote.
> > >>>>>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is really
> > >>>>>>>>> convincing
> > >>>>>>>>>>>>> enough
> > >>>>>>>>>>>>>> to decide whether the FLIP is good to go or not. Also, if
> > >>>>>> some
> > >>>>>>>>>>>>> committers
> > >>>>>>>>>>>>>> have concern over a FLIP, they could just veto it. To me
> > >>>>> it
> > >>>>>> is
> > >>>>>>>>>>> actually
> > >>>>>>>>>>>>> a
> > >>>>>>>>>>>>>> more strict requirement to pass a FLIP than asking a PMC
> > >>>>> to
> > >>>>>>>> vote.
> > >>>>>>>>> In
> > >>>>>>>>>>>>>> practice, people will usually also address the concerns
> > >>>>> even
> > >>>>>>> if
> > >>>>>>>>> they
> > >>>>>>>>>>> are
> > >>>>>>>>>>>>>> not from a PMC/committer before they start the voting
> > >>>>>> process.
> > >>>>>>>> So
> > >>>>>>>>> I
> > >>>>>>>>>>>>> don't
> > >>>>>>>>>>>>>> see much benefit of requiring a PMC's vote in this case.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the votes
> > >>>>> no
> > >>>>>>>> longer
> > >>>>>>>>>>>>>> independent. Ideally, a vote is either binding or
> > >>>>>> non-binding
> > >>>>>>> by
> > >>>>>>>>>>>>> itself. If
> > >>>>>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
> > >>>>> imagine
> > >>>>>>>> there
> > >>>>>>>>>> have
> > >>>>>>>>>>>>> been
> > >>>>>>>>>>>>>> 3 committers who voted +1. But the FLIP still has not
> > >>>>>> passed,
> > >>>>>>> so
> > >>>>>>>>>> those
> > >>>>>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a +1,
> > >>>>>> those
> > >>>>>>>>> votes
> > >>>>>>>>>>>>>> suddenly become binding, which is a little awkward.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable to me.
> > >>>>>> Some
> > >>>>>>>>>>> thoughts
> > >>>>>>>>>>>>> on
> > >>>>>>>>>>>>>> this:
> > >>>>>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is probably
> > >>>>>>> because
> > >>>>>>>>>> there
> > >>>>>>>>>>>>> are
> > >>>>>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3 majority
> > >>>>>>>>>>> prohibitively
> > >>>>>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
> > >>>>> Flink[2]
> > >>>>>>> and
> > >>>>>>>> a
> > >>>>>>>>>>> quick
> > >>>>>>>>>>>>>> search shows at most 6 of them have not sent email in the
> > >>>>>>>> recent 6
> > >>>>>>>>>>>>> months
> > >>>>>>>>>>>>>> or so.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare. It is
> > >>>>>>>> designed
> > >>>>>>>>>> in
> > >>>>>>>>>>>>>> particular for the cases that broad opinions are
> > >>>>> important,
> > >>>>>>> more
> > >>>>>>>>>>>>>> specifically new codebase adoption or modification to the
> > >>>>>>>> bylaws.
> > >>>>>>>>>>>>> Therefore
> > >>>>>>>>>>>>>> such vote by its nature favors consensus over convenience.
> > >>>>>>> That
> > >>>>>>>>>> means
> > >>>>>>>>>>>>> any
> > >>>>>>>>>>>>>> alternative voting type reducing the coverage worth a
> > >>>>>> careful
> > >>>>>>>>>>> thinking.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 3. I do agree that it does not make sense to have 2/3
> > >>>>>> majority
> > >>>>>>>> if
> > >>>>>>>>>> such
> > >>>>>>>>>>>>>> requirement is no-longer doable over time. But I am a
> > >>>>> little
> > >>>>>>>>>> hesitant
> > >>>>>>>>>>> to
> > >>>>>>>>>>>>>> lower the threshold to lazy 2/3 majority in our case. What
> > >>>>>> do
> > >>>>>>>> you
> > >>>>>>>>>>> think
> > >>>>>>>>>>>>>> about doing the following:
> > >>>>>>>>>>>>>>     - After the voting started, there will be at least 6
> > >>>>>> days
> > >>>>>>>> for
> > >>>>>>>>>>>>> people to
> > >>>>>>>>>>>>>> cast their votes.
> > >>>>>>>>>>>>>>     - After 6 days, if the result of the vote is still not
> > >>>>>>>>>> determined,
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>> person who started the vote should reach out to the
> > >>>>> binding
> > >>>>>>>> voters
> > >>>>>>>>>> who
> > >>>>>>>>>>>>> have
> > >>>>>>>>>>>>>> not voted yet for at least 3 times and at least 7 days
> > >>>>>> between
> > >>>>>>>>> each
> > >>>>>>>>>>>>> time.
> > >>>>>>>>>>>>>> If a binding voter still did not respond, the vote from
> > >>>>> that
> > >>>>>>>> voter
> > >>>>>>>>>>> will
> > >>>>>>>>>>>>> be
> > >>>>>>>>>>>>>> excluded from the 2/3 majority counting.
> > >>>>>>>>>>>>>> This would ensure the coverage at our best effort while
> > >>>>>> still
> > >>>>>>>> let
> > >>>>>>>>>> the
> > >>>>>>>>>>>>> 2/3
> > >>>>>>>>>>>>>> majority vote make progress.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> [1] https://projects.apache.org/committee.html?hadoop
> > >>>>>>>>>>>>>> [2] https://projects.apache.org/committee.html?flink
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> > >>>>>>>>> forwardxu315@gmail.com>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Big +1 on this.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> best
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> forward
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
> > >>>>>> 下午1:30写道：
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Hi Becket,
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Big +1 on this.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> > >>>>>>> includes a
> > >>>>>>>>> PMC
> > >>>>>>>>>>>>> vote.
> > >>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
> > >>>>> PMC
> > >>>>>> in
> > >>>>>>>>> the 3
> > >>>>>>>>>>>>>> binding
> > >>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> > >>>>>> and 1
> > >>>>>>>>> PMC.
> > >>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> > >>>>>> somehow
> > >>>>>>>> be a
> > >>>>>>>>>> big
> > >>>>>>>>>>>>>>> feature
> > >>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
> > >>>>>> loss
> > >>>>>>>> of
> > >>>>>>>>>>>>>> flexibility
> > >>>>>>>>>>>>>>>> as committers also have a chance to vote and
> > >>>>> participate
> > >>>>>>> in
> > >>>>>>>>> it.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> ========Seperator========
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> For the nice bylaws, I agree with the general idea and
> > >>>>>>> most
> > >>>>>>>> of
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>>> content.
> > >>>>>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority". The
> > >>>>>>> main
> > >>>>>>>>>>> concern
> > >>>>>>>>>>>>> is
> > >>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>> am
> > >>>>>>>>>>>>>>>> not sure if it is doable in practice. The reasons are:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
> > >>>>>> committer
> > >>>>>>>> or a
> > >>>>>>>>>> PMC
> > >>>>>>>>>>>>>> member
> > >>>>>>>>>>>>>>>> is active if he or she sends one email to the mailing
> > >>>>>> list
> > >>>>>>>>>> every 6
> > >>>>>>>>>>>>>>> months.
> > >>>>>>>>>>>>>>>> While the minimum length of the vote is only 6 days.
> > >>>>>> There
> > >>>>>>>> are
> > >>>>>>>>>>>>> chances
> > >>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>> during the vote, some of the active members are still
> > >>>>>>>> offline
> > >>>>>>>>> of
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>>>>> community.
> > >>>>>>>>>>>>>>>> 2. The code of Flink is changing fast and not everyone
> > >>>>>>> fully
> > >>>>>>>>>>>>>> understands
> > >>>>>>>>>>>>>>>> every part. We don't need to force people to vote if
> > >>>>>> they
> > >>>>>>>> are
> > >>>>>>>>>> not
> > >>>>>>>>>>>>> sure
> > >>>>>>>>>>>>>>>> about it. It may also make the final result less
> > >>>>>> credible.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Given the above reasons, perhaps we can change the 2/3
> > >>>>>>>>> Majority
> > >>>>>>>>>> to
> > >>>>>>>>>>>>> lazy
> > >>>>>>>>>>>>>>> 2/3
> > >>>>>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
> > >>>>>> higher
> > >>>>>>>>>>> threshold,
> > >>>>>>>>>>>>>>>> however, more practical.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> What do you think?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> > >>>>>>>>>> becket.qin@gmail.com
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Hi Jincheng,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki page.
> > >>>>>>> Just
> > >>>>>>>> a
> > >>>>>>>>>>> brief
> > >>>>>>>>>>>>>>>> summary,
> > >>>>>>>>>>>>>>>>> the current bylaws do require some of the FLIPs to
> > >>>>> get
> > >>>>>>> PMC
> > >>>>>>>>>>>>> approval
> > >>>>>>>>>>>>>> if
> > >>>>>>>>>>>>>>>>> their impact is big enough. But it leaves majority
> > >>>>> of
> > >>>>>>> the
> > >>>>>>>>>>>>> technical
> > >>>>>>>>>>>>>>>>> decisions to the committers who are supposed to be
> > >>>>>>>>> responsible
> > >>>>>>>>>>> for
> > >>>>>>>>>>>>>>> making
> > >>>>>>>>>>>>>>>>> such decisions.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Re: Robert,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I agree we can simply remove the requirement of +1
> > >>>>>> from
> > >>>>>>> a
> > >>>>>>>>>>>>> non-author
> > >>>>>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
> > >>>>> does
> > >>>>>>> not
> > >>>>>>>>> make
> > >>>>>>>>>>>>> sense
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
> > >>>>>> updated
> > >>>>>>>> the
> > >>>>>>>>>>> bylaws
> > >>>>>>>>>>>>>>> wiki.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> > >>>>>>>>>>>>> rmetzger@apache.org
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
> > >>>>>>> current
> > >>>>>>>>>>> status
> > >>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
> > >>>>> is
> > >>>>>> a
> > >>>>>>>> very
> > >>>>>>>>>>>>> involved
> > >>>>>>>>>>>>>>>> task.
> > >>>>>>>>>>>>>>>>>> Unless there's somebody who's really eager to
> > >>>>> drive
> > >>>>>>>> this,
> > >>>>>>>>> I
> > >>>>>>>>>>>>> would
> > >>>>>>>>>>>>>>> stick
> > >>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
> > >>>>>> Flink,
> > >>>>>>>> even
> > >>>>>>>>>> if
> > >>>>>>>>>>>>> this
> > >>>>>>>>>>>>>>>> means
> > >>>>>>>>>>>>>>>>>> some changes.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> The cross-review requirement is the last big open
> > >>>>>>> point
> > >>>>>>>> in
> > >>>>>>>>>>> this
> > >>>>>>>>>>>>>>>>> discussion.
> > >>>>>>>>>>>>>>>>>> It seems that a there is a slight tendency in the
> > >>>>>>>>> discussion
> > >>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>> this
> > >>>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>> not feasible given the current pull request review
> > >>>>>>>>>> situation.
> > >>>>>>>>>>>>>>>>>> For the sake of bringing this discussion to a
> > >>>>>>>> conclusion,
> > >>>>>>>>>> I'm
> > >>>>>>>>>>>>> fine
> > >>>>>>>>>>>>>>> with
> > >>>>>>>>>>>>>>>>>> leaving this requirement out. As we are currently
> > >>>>>>> adding
> > >>>>>>>>>> more
> > >>>>>>>>>>>>>>>> committers
> > >>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>> the project, we might be able to revisit this
> > >>>>>>> discussion
> > >>>>>>>>> in
> > >>>>>>>>>> 3
> > >>>>>>>>>>> -
> > >>>>>>>>>>>>> 6
> > >>>>>>>>>>>>>>>> months.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> > >>>>>>>>>>>>>>> sunjincheng121@gmail.com
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Hi Becket,
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Thanks for the proposal.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> > >>>>>>>>> includes a
> > >>>>>>>>>>> PMC
> > >>>>>>>>>>>>>>> vote.
> > >>>>>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
> > >>>>>> the
> > >>>>>>>>> user's
> > >>>>>>>>>>>>>>> interface
> > >>>>>>>>>>>>>>>>>>> changes. What do you think? (I leave the comment
> > >>>>>> in
> > >>>>>>>> the
> > >>>>>>>>>>> wiki.)
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>>>>>>> Jincheng
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
> > >>>>>>>> 于2019年7月17日周三
> > >>>>>>>>>>>>>> 下午9:12写道：
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
> > >>>>>> that
> > >>>>>>> I
> > >>>>>>>>>> really
> > >>>>>>>>>>>>> like
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> proposed bylaws!
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
> > >>>>>>>>> expressed
> > >>>>>>>>>> by
> > >>>>>>>>>>>>> few
> > >>>>>>>>>>>>>>>> people
> > >>>>>>>>>>>>>>>>>>>> before that the "committer +1" on code change
> > >>>>>>> might
> > >>>>>>>> be
> > >>>>>>>>>>> hard
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> achieve
> > >>>>>>>>>>>>>>>>>>>> currently. On the other hand I would say this
> > >>>>>>> would
> > >>>>>>>> be
> > >>>>>>>>>>>>>> beneficial
> > >>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
> > >>>>>>> knowledge
> > >>>>>>>>>>>>> sharing.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> I was just wondering what should be the next
> > >>>>>> step
> > >>>>>>>> for
> > >>>>>>>>>>> this?
> > >>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>> think
> > >>>>>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>>> would make sense to already use those bylaws
> > >>>>> and
> > >>>>>>> put
> > >>>>>>>>>> them
> > >>>>>>>>>>> to
> > >>>>>>>>>>>>>> PMC
> > >>>>>>>>>>>>>>>>> vote.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Dawid
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
> > >>>>>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
> > >>>>> think.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> > >>>>>> If
> > >>>>>>> we
> > >>>>>>>>> are
> > >>>>>>>>>>>>>> stating
> > >>>>>>>>>>>>>>>>> that a
> > >>>>>>>>>>>>>>>>>>>> single
> > >>>>>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
> > >>>>>> review,
> > >>>>>>>>> with 0
> > >>>>>>>>>>>>> hours
> > >>>>>>>>>>>>>>>> delay
> > >>>>>>>>>>>>>>>>>> (de
> > >>>>>>>>>>>>>>>>>>>> facto
> > >>>>>>>>>>>>>>>>>>>>>>> the current state), we should also write
> > >>>>>> down
> > >>>>>>>> that
> > >>>>>>>>>>> this
> > >>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>> subject
> > >>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
> > >>>>>> the
> > >>>>>>>>>>>>> components
> > >>>>>>>>>>>>>>>>> expertise
> > >>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
> > >>>>> facto
> > >>>>>>>>> current
> > >>>>>>>>>>>>>> state).
> > >>>>>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
> > >>>>>>>>>> intention,
> > >>>>>>>>>>>>> but
> > >>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>> may
> > >>>>>>>>>>>>>>>>>> be a
> > >>>>>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
> > >>>>>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
> > >>>>>>> rule
> > >>>>>>>>>>> anyway,
> > >>>>>>>>>>>>>>>> intended
> > >>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
> > >>>>>> to
> > >>>>>>>> just
> > >>>>>>>>>>>>> avoid a
> > >>>>>>>>>>>>>>>>>> situation
> > >>>>>>>>>>>>>>>>>>>> when someone violates current uncodified state
> > >>>>>> and
> > >>>>>>>>>> refers
> > >>>>>>>>>>> to
> > >>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> bylaws
> > >>>>>>>>>>>>>>>>>>>> which are saying merging with any committer +1
> > >>>>>> is
> > >>>>>>>>> always
> > >>>>>>>>>>>>> fine
> > >>>>>>>>>>>>>>> (like
> > >>>>>>>>>>>>>>>>>> mine
> > >>>>>>>>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>>>>>>>> for flink-python or flink-ml).
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Piotrek
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
> > >>>>> <
> > >>>>>>>>>>>>>>> aljoscha@apache.org
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
> > >>>>>> FLIP.
> > >>>>>>>>> This
> > >>>>>>>>>> is
> > >>>>>>>>>>>>> just
> > >>>>>>>>>>>>>>>> about
> > >>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> voting, before that there needs to be the
> > >>>>>>> discussion
> > >>>>>>>>>>>>> thread. If
> > >>>>>>>>>>>>>>>> three
> > >>>>>>>>>>>>>>>>>>> days
> > >>>>>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
> > >>>>>>> (i.e. 3
> > >>>>>>>>>>>>>>>> committers/PMCs
> > >>>>>>>>>>>>>>>>>> have
> > >>>>>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
> > >>>>>> So
> > >>>>>>>> far,
> > >>>>>>>>>> we
> > >>>>>>>>>>>>> have
> > >>>>>>>>>>>>>>>> rarely
> > >>>>>>>>>>>>>>>>>> see
> > >>>>>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
> > >>>>> we
> > >>>>>>> want
> > >>>>>>>>> to
> > >>>>>>>>>>> use
> > >>>>>>>>>>>>>> "lazy
> > >>>>>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
> > >>>>>>> that
> > >>>>>>>>>> should
> > >>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>> changed
> > >>>>>>>>>>>>>>>>>>> from
> > >>>>>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
> > >>>>>>> current
> > >>>>>>>>>> state
> > >>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>> all
> > >>>>>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
> > >>>>>>> come
> > >>>>>>>> up
> > >>>>>>>>>>> with
> > >>>>>>>>>>>>>>>> something
> > >>>>>>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>>> reflects the common state, according to
> > >>>>>>>>> PMCs/commiters,
> > >>>>>>>>>>> that
> > >>>>>>>>>>>>>>> might
> > >>>>>>>>>>>>>>>>>> take a
> > >>>>>>>>>>>>>>>>>>>> very long time. In that case I think it’s
> > >>>>> better
> > >>>>>>> to
> > >>>>>>>>>> adopt
> > >>>>>>>>>>>>>>> something
> > >>>>>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
> > >>>>>> do
> > >>>>>>> it
> > >>>>>>>>>> now.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Aljoscha
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
> > >>>>> <
> > >>>>>>>>>>>>>>> piotr@ververica.com
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
> > >>>>> speaking
> > >>>>>> +1
> > >>>>>>>>> from
> > >>>>>>>>>> my
> > >>>>>>>>>>>>> side
> > >>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> general idea and most of the content. I also
> > >>>>> see
> > >>>>>>>> merit
> > >>>>>>>>>> to
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> Chesney's
> > >>>>>>>>>>>>>>>>>>>> proposal to start from the current state. I
> > >>>>>> think
> > >>>>>>>>> either
> > >>>>>>>>>>>>> would
> > >>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>> fine
> > >>>>>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>> me.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Couple of comments:
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 1.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
> > >>>>> another
> > >>>>>>>>>> committer
> > >>>>>>>>>>>>> would
> > >>>>>>>>>>>>>>>> slow
> > >>>>>>>>>>>>>>>>>> down
> > >>>>>>>>>>>>>>>>>>>> and put even more strain on the current
> > >>>>>> reviewing
> > >>>>>>>>>>> bottleneck
> > >>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
> > >>>>>>> context
> > >>>>>>>>>>> switch
> > >>>>>>>>>>>>>> cost
> > >>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>> quite
> > >>>>>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
> > >>>>>> second
> > >>>>>>>>>> “cross”
> > >>>>>>>>>>>>>>> committer
> > >>>>>>>>>>>>>>>>>> could
> > >>>>>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
> > >>>>>>> Besides,
> > >>>>>>>>>>> current
> > >>>>>>>>>>>>>> setup
> > >>>>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
> > >>>>>>>>> required)
> > >>>>>>>>>>>>> works
> > >>>>>>>>>>>>>>> quite
> > >>>>>>>>>>>>>>>>>> well
> > >>>>>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
> > >>>>>> the
> > >>>>>>>>> other
> > >>>>>>>>>>> hand
> > >>>>>>>>>>>>>>>>> reviewing
> > >>>>>>>>>>>>>>>>>>>> bottleneck is.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 2.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
> > >>>>> ask
> > >>>>>>>>> another
> > >>>>>>>>>>>>>>> committer
> > >>>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>> feedback or not.
> > >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> > >>>>>> If
> > >>>>>>> we
> > >>>>>>>>> are
> > >>>>>>>>>>>>>> stating
> > >>>>>>>>>>>>>>>>> that a
> > >>>>>>>>>>>>>>>>>>>> single committers +1 is good enough for code
> > >>>>>>> review,
> > >>>>>>>>>> with
> > >>>>>>>>>>> 0
> > >>>>>>>>>>>>>> hours
> > >>>>>>>>>>>>>>>>> delay
> > >>>>>>>>>>>>>>>>>>> (de
> > >>>>>>>>>>>>>>>>>>>> facto the current state), we should also write
> > >>>>>>> down
> > >>>>>>>>> that
> > >>>>>>>>>>>>> this
> > >>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>> subject
> > >>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>> the best judgement of the committer to respect
> > >>>>>> the
> > >>>>>>>>>>>>> components
> > >>>>>>>>>>>>>>>>> expertise
> > >>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
> > >>>>>>> current
> > >>>>>>>>>>> state).
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 3.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
> > >>>>>>>>> currently
> > >>>>>>>>>>>>> might
> > >>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
> > >>>>>> if
> > >>>>>>>>>>> respected
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>> letter.
> > >>>>>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
> > >>>>>>>>>> committers
> > >>>>>>>>>>>>> with
> > >>>>>>>>>>>>>>>>> highest
> > >>>>>>>>>>>>>>>>>>>> expertise in the affected components managed
> > >>>>> to
> > >>>>>>>>> respond
> > >>>>>>>>>> or
> > >>>>>>>>>>>>> not.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Piotrek
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
> > >>>>> Schepler
> > >>>>>> <
> > >>>>>>>>>>>>>>>> chesnay@apache.org>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
> > >>>>>>> write
> > >>>>>>>>> down
> > >>>>>>>>>>>>> Bylaws
> > >>>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>>> reflect the current state, and then have
> > >>>>>> separate
> > >>>>>>>>>>>>> discussions
> > >>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
> > >>>>>> this
> > >>>>>>>>>>>>> discussion
> > >>>>>>>>>>>>>>> will
> > >>>>>>>>>>>>>>>>>>> quickly
> > >>>>>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
> > >>>>>>>>> discussed
> > >>>>>>>>>>> at
> > >>>>>>>>>>>>>> once.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
> > >>>>>> Qin
> > >>>>>>> <
> > >>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
> > >>>>> and
> > >>>>>>>>>> feedback.
> > >>>>>>>>>>>>>> Please
> > >>>>>>>>>>>>>>>> see
> > >>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> replies
> > >>>>>>>>>>>>>>>>>>>>>>>>>> below:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> > >>>>> Change"
> > >>>>>> we
> > >>>>>>>>> could
> > >>>>>>>>>>>>> also
> > >>>>>>>>>>>>>>> add a
> > >>>>>>>>>>>>>>>>> row
> > >>>>>>>>>>>>>>>>>>>> for "Code
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> > >>>>>> reference
> > >>>>>>> to
> > >>>>>>>>> the
> > >>>>>>>>>>>>> FLIP
> > >>>>>>>>>>>>>>>> process
> > >>>>>>>>>>>>>>>>>>>> page. A
> > >>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
> > >>>>> for
> > >>>>>>>>>> approvals,
> > >>>>>>>>>>>>> etc.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> > >>>>> currently
> > >>>>>>>>> requires
> > >>>>>>>>>>>>> "one
> > >>>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>>>>> from a
> > >>>>>>>>>>>>>>>>>>>> committer
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> > >>>>> followed
> > >>>>>>> by a
> > >>>>>>>>>> Lazy
> > >>>>>>>>>>>>>>> approval
> > >>>>>>>>>>>>>>>>> (not
> > >>>>>>>>>>>>>>>>>>>> counting
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
> > >>>>> to
> > >>>>>>> lazy
> > >>>>>>>>>>>>> majority
> > >>>>>>>>>>>>>> if
> > >>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>> -1
> > >>>>>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>>>>>>>>>> received".
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
> > >>>>>>>>> committer
> > >>>>>>>>>>>>> always
> > >>>>>>>>>>>>>>>>> needs a
> > >>>>>>>>>>>>>>>>>>>> review
> > >>>>>>>>>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
> > >>>>>>> know
> > >>>>>>>>> this
> > >>>>>>>>>>> is
> > >>>>>>>>>>>>>>>> currently
> > >>>>>>>>>>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>>>> always
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > >>>>>>>> contributor
> > >>>>>>>>>>>>> reviews
> > >>>>>>>>>>>>>> &
> > >>>>>>>>>>>>>>>>> +1s).
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
> > >>>>> we
> > >>>>>>> can
> > >>>>>>>>>> make
> > >>>>>>>>>>> it
> > >>>>>>>>>>>>>> easy
> > >>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>> follow the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> > >>>>>> Flink-specific
> > >>>>>>>> Jira
> > >>>>>>>>>>>>>> workflows
> > >>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>> ticket
> > >>>>>>>>>>>>>>>>>>>>>>>>>> types +
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
> > >>>>> is
> > >>>>>>>>>> certainly
> > >>>>>>>>>>>>>> "Step
> > >>>>>>>>>>>>>>>> 2",
> > >>>>>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>>>>> believe,
> > >>>>>>>>>>>>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> > >>>>>>> transparent
> > >>>>>>>>> as
> > >>>>>>>>>>>>>> possible,
> > >>>>>>>>>>>>>>>>>>>> otherwise they
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> & Re: Till
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> > >>>>>>> author
> > >>>>>>>>> and
> > >>>>>>>>>>>>>> getting
> > >>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>>>>>>> from
> > >>>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> > >>>>>> should
> > >>>>>>>> know
> > >>>>>>>>>>> when
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>> ask
> > >>>>>>>>>>>>>>>>>>> another
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
> > >>>>> I
> > >>>>>>>> would
> > >>>>>>>>>> not
> > >>>>>>>>>>>>>> enforce
> > >>>>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> > >>>>> author
> > >>>>>>> is
> > >>>>>>>> a
> > >>>>>>>>>>>>> committer
> > >>>>>>>>>>>>>>> but
> > >>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>> course
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
> > >>>>> here.
> > >>>>>>>> TBH,
> > >>>>>>>>> in
> > >>>>>>>>>>>>> Kafka
> > >>>>>>>>>>>>>>>>>>> occasionally
> > >>>>>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
> > >>>>> still
> > >>>>>>>>> merged
> > >>>>>>>>>>>>> without
> > >>>>>>>>>>>>>>>>>> following
> > >>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
> > >>>>> rare.
> > >>>>>>>> That
> > >>>>>>>>>>> said,
> > >>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>> still
> > >>>>>>>>>>>>>>>>>> think
> > >>>>>>>>>>>>>>>>>>>> an
> > >>>>>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
> > >>>>> sense
> > >>>>>>> due
> > >>>>>>>>> to
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>>>>> following
> > >>>>>>>>>>>>>>>>>>>> reasons:
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
> > >>>>>> to
> > >>>>>>>> make
> > >>>>>>>>>>> sure
> > >>>>>>>>>>>>>> every
> > >>>>>>>>>>>>>>>>> patch
> > >>>>>>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
> > >>>>>>>> little
> > >>>>>>>>>>>>> difficult
> > >>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>> guarantee if
> > >>>>>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
> > >>>>>>> many
> > >>>>>>>>>>>>> reasons. In
> > >>>>>>>>>>>>>>>> some
> > >>>>>>>>>>>>>>>>>>>> cases, a
> > >>>>>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
> > >>>>> knowledge
> > >>>>>>>> about
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>>> project
> > >>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>> make
> > >>>>>>>>>>>>>>>>>>>> a good
> > >>>>>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
> > >>>>>> contributors
> > >>>>>>>> are
> > >>>>>>>>>> more
> > >>>>>>>>>>>>>>> eagerly
> > >>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>> get a
> > >>>>>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
> > >>>>>> willing
> > >>>>>>>> to
> > >>>>>>>>>>> lower
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> review
> > >>>>>>>>>>>>>>>>>>> bar.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
> > >>>>>> among
> > >>>>>>>>>>>>> committers,
> > >>>>>>>>>>>>>>>> which
> > >>>>>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>>>>> personally
> > >>>>>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
> > >>>>>>> form
> > >>>>>>>>>>>>> consistent
> > >>>>>>>>>>>>>>>> design
> > >>>>>>>>>>>>>>>>>>>> principles
> > >>>>>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
> > >>>>>>>> committers
> > >>>>>>>>>> will
> > >>>>>>>>>>>>> know
> > >>>>>>>>>>>>>>> how
> > >>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> other
> > >>>>>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
> > >>>>>> from
> > >>>>>>>> each
> > >>>>>>>>>>>>> other.
> > >>>>>>>>>>>>>> So
> > >>>>>>>>>>>>>>>> they
> > >>>>>>>>>>>>>>>>>>> tend
> > >>>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
> > >>>>>>> things
> > >>>>>>>>>> should
> > >>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>> done
> > >>>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>>> general.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
> > >>>>>>>> consider
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>>> following
> > >>>>>>>>>>>>>>>>> two
> > >>>>>>>>>>>>>>>>>>>> scenarios:
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
> > >>>>> a
> > >>>>>>> lot
> > >>>>>>>> of
> > >>>>>>>>>>>>>>> iterations.
> > >>>>>>>>>>>>>>>>> Then
> > >>>>>>>>>>>>>>>>>>>> the patch
> > >>>>>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
> > >>>>>> time
> > >>>>>>>>>> because
> > >>>>>>>>>>>>> there
> > >>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>>> things
> > >>>>>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
> > >>>>> changed.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
> > >>>>> very
> > >>>>>>>> smooth
> > >>>>>>>>>> and
> > >>>>>>>>>>>>>> quick,
> > >>>>>>>>>>>>>>>> so
> > >>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> patch is
> > >>>>>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
> > >>>>> patch
> > >>>>>>> does
> > >>>>>>>>> not
> > >>>>>>>>>>>>> take
> > >>>>>>>>>>>>>>> much
> > >>>>>>>>>>>>>>>>>> time.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
> > >>>>>> patch
> > >>>>>>>>> from a
> > >>>>>>>>>>>>>>> committer
> > >>>>>>>>>>>>>>>>>> falls
> > >>>>>>>>>>>>>>>>>>>> either in
> > >>>>>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
> > >>>>> is
> > >>>>>>> to
> > >>>>>>>>>> review
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>> patch
> > >>>>>>>>>>>>>>>>>>>> because
> > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
> > >>>>> needs
> > >>>>>>> to
> > >>>>>>>> be
> > >>>>>>>>>>>>>> reviewed.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
> > >>>>>> take
> > >>>>>>>>> much
> > >>>>>>>>>>> time
> > >>>>>>>>>>>>>>>> anyways.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
> > >>>>>>> case
> > >>>>>>>> 1
> > >>>>>>>>> if
> > >>>>>>>>>>> we
> > >>>>>>>>>>>>>> skip
> > >>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> cross-review.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Robert
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
> > >>>>>> and
> > >>>>>>>> made
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>>>> following
> > >>>>>>>>>>>>>>>>>>>> modifications
> > >>>>>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
> > >>>>> section.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
> > >>>>>> to
> > >>>>>>>>>>>>> "consensus"
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> align
> > >>>>>>>>>>>>>>>>>>> with
> > >>>>>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
> > >>>>> and
> > >>>>>>>> other
> > >>>>>>>>>>>>>> projects.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> > >>>>> unnecessary
> > >>>>>>>>> noise.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
> > >>>>>> 2/3
> > >>>>>>>>>>> majority
> > >>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>> still
> > >>>>>>>>>>>>>>>>>>>> feasible in
> > >>>>>>>>>>>>>>>>>>>>>>>>>> practice.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> > >>>>> the
> > >>>>>>>> draft
> > >>>>>>>>>>>>> compared
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>> existing
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
> > >>>>>>>>> highlight
> > >>>>>>>>>>>>> these
> > >>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>> discuss
> > >>>>>>>>>>>>>>>>>>>> them
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
> > >>>>>>> familiar
> > >>>>>>>>>> enough
> > >>>>>>>>>>>>> with
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> current Flink
> > >>>>>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
> > >>>>> saw
> > >>>>>>> you
> > >>>>>>>>>>>>> commented
> > >>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>> some
> > >>>>>>>>>>>>>>>>>>> part
> > >>>>>>>>>>>>>>>>>>>> in the
> > >>>>>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> > >>>>>>> bylaws?
> > >>>>>>>>> I’m
> > >>>>>>>>>>>>> asking
> > >>>>>>>>>>>>>>>>> because
> > >>>>>>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>>>>> quite
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> > >>>>> essentially
> > >>>>>>>>> adopting
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>>>> Kafka
> > >>>>>>>>>>>>>>>>>>> bylaws.
> > >>>>>>>>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> > >>>>>> try
> > >>>>>>>> to
> > >>>>>>>>>>>>> re-invent
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>> wheel
> > >>>>>>>>>>>>>>>>>>>> here.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
> > >>>>> version
> > >>>>>>> of
> > >>>>>>>>> the
> > >>>>>>>>>>>>> draft
> > >>>>>>>>>>>>>> was
> > >>>>>>>>>>>>>>>>>> almost
> > >>>>>>>>>>>>>>>>>>>> identical
> > >>>>>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
> > >>>>> caught a
> > >>>>>>> few
> > >>>>>>>>>>>>>> inconsistent
> > >>>>>>>>>>>>>>>>>> places.
> > >>>>>>>>>>>>>>>>>>>> So it
> > >>>>>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
> > >>>>>> make
> > >>>>>>>> sure
> > >>>>>>>>>> we
> > >>>>>>>>>>>>> truly
> > >>>>>>>>>>>>>>>> agree
> > >>>>>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>>>> them.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
> > >>>>>>>> shortly
> > >>>>>>>>>>> after
> > >>>>>>>>>>>>>>>> adoption.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
> > >>>>> valuable
> > >>>>>>>>>> feedback.
> > >>>>>>>>>>>>> These
> > >>>>>>>>>>>>>>> are
> > >>>>>>>>>>>>>>>>>> great
> > >>>>>>>>>>>>>>>>>>>>>>>>>> discussion.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
> > >>>>> Aljoscha
> > >>>>>>>>> Krettek
> > >>>>>>>>>> <
> > >>>>>>>>>>>>>>>>>>>> aljoscha@apache.org>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Big +1
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> > >>>>>>> bylaws?
> > >>>>>>>>> I’m
> > >>>>>>>>>>>>> asking
> > >>>>>>>>>>>>>>>>>> because I
> > >>>>>>>>>>>>>>>>>>>> quite
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> > >>>>> essentially
> > >>>>>>>>> adopting
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>>>> Kafka
> > >>>>>>>>>>>>>>>>>>> bylaws.
> > >>>>>>>>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> > >>>>>> try
> > >>>>>>>> to
> > >>>>>>>>>>>>> re-invent
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>> wheel
> > >>>>>>>>>>>>>>>>>>>> here.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
> > >>>>>>>>>> “committer
> > >>>>>>>>>>>>> +1”
> > >>>>>>>>>>>>>>>>>>> requirement.
> > >>>>>>>>>>>>>>>>>>>> We
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
> > >>>>> would
> > >>>>>>>>> actually
> > >>>>>>>>>>> be
> > >>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>> favour
> > >>>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>>>>>>> requiring
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
> > >>>>>>>>>> complicated.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
> > >>>>>> Rohrmann
> > >>>>>>> <
> > >>>>>>>>>>>>>>>>>> trohrmann@apache.org>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
> > >>>>>>>> Becket.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
> > >>>>> emeritus
> > >>>>>>> (or
> > >>>>>>>>>> active
> > >>>>>>>>>>>>> vs.
> > >>>>>>>>>>>>>>>>>> inactive),
> > >>>>>>>>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>>>>>>>>> won't
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
> > >>>>> vote
> > >>>>>>>>> because
> > >>>>>>>>>>> we
> > >>>>>>>>>>>>>>> already
> > >>>>>>>>>>>>>>>>>> have
> > >>>>>>>>>>>>>>>>>>>> too
> > >>>>>>>>>>>>>>>>>>>>>>>>>> many
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> > >>>>>>>> author
> > >>>>>>>>>> and
> > >>>>>>>>>>>>>>> getting a
> > >>>>>>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>>>>>>>> from a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> > >>>>>> should
> > >>>>>>>>> know
> > >>>>>>>>>>>>> when to
> > >>>>>>>>>>>>>>> ask
> > >>>>>>>>>>>>>>>>>>> another
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
> > >>>>> Hence, I
> > >>>>>>>> would
> > >>>>>>>>>> not
> > >>>>>>>>>>>>>>> enforce
> > >>>>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> > >>>>>> author
> > >>>>>>>> is a
> > >>>>>>>>>>>>>> committer
> > >>>>>>>>>>>>>>>> but
> > >>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>> course
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Till
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
> > >>>>> Chesnay
> > >>>>>>>>>> Schepler
> > >>>>>>>>>>> <
> > >>>>>>>>>>>>>>>>>>>> chesnay@apache.org>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> > >>>>>>> unnecessary
> > >>>>>>>>>> noise.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> > >>>>>> the
> > >>>>>>>>> draft
> > >>>>>>>>>>>>>> compared
> > >>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>> existing
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
> > >>>>> to
> > >>>>>>>>>> highlight
> > >>>>>>>>>>>>>> these
> > >>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>> discuss
> > >>>>>>>>>>>>>>>>>>>>>>>>>> them
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
> > >>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
> > >>>>> this
> > >>>>>>>>>>> discussion
> > >>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>> creating
> > >>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>> draft
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> > >>>>> that
> > >>>>>> a
> > >>>>>>>>>>> committer
> > >>>>>>>>>>>>>>> always
> > >>>>>>>>>>>>>>>>>> needs
> > >>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>>>>>>>> review
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> > >>>>>> as I
> > >>>>>>>>> know
> > >>>>>>>>>>>>> this is
> > >>>>>>>>>>>>>>>>>> currently
> > >>>>>>>>>>>>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > >>>>>>>>>> contributor
> > >>>>>>>>>>>>>>> reviews
> > >>>>>>>>>>>>>>>> &
> > >>>>>>>>>>>>>>>>>>> +1s).
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
> > >>>>> if
> > >>>>>>> we
> > >>>>>>>>> had
> > >>>>>>>>>>>>> cases
> > >>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>> past
> > >>>>>>>>>>>>>>>>>>>> where
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> code
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
> > >>>>> we
> > >>>>>>>>> believe
> > >>>>>>>>>>>>> that we
> > >>>>>>>>>>>>>>>> have
> > >>>>>>>>>>>>>>>>>>> enough
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> capacity
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
> > >>>>>>>> approval.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> > >>>>>>>> Konstantin
> > >>>>>>>>>>> Knauf
> > >>>>>>>>>>>>> <
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
> > >>>>>>> Becket. I
> > >>>>>>>>>> have
> > >>>>>>>>>>>>> two
> > >>>>>>>>>>>>>>>> remarks
> > >>>>>>>>>>>>>>>>>>>> regarding
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> > >>>>>>> Change"
> > >>>>>>>> we
> > >>>>>>>>>>> could
> > >>>>>>>>>>>>>> also
> > >>>>>>>>>>>>>>>>> add a
> > >>>>>>>>>>>>>>>>>>>> row for
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Code
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> > >>>>>>>> reference
> > >>>>>>>>> to
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>>> FLIP
> > >>>>>>>>>>>>>>>>>> process
> > >>>>>>>>>>>>>>>>>>>> page.
> > >>>>>>>>>>>>>>>>>>>>>>>>>> A
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
> > >>>>> rules
> > >>>>>>> for
> > >>>>>>>>>>>>> approvals,
> > >>>>>>>>>>>>>>> etc.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> > >>>>>>> currently
> > >>>>>>>>>>> requires
> > >>>>>>>>>>>>>> "one
> > >>>>>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>>>>>>> from a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> > >>>>>>> followed
> > >>>>>>>>> by a
> > >>>>>>>>>>>>> Lazy
> > >>>>>>>>>>>>>>>>> approval
> > >>>>>>>>>>>>>>>>>>> (not
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> counting
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
> > >>>>> moving
> > >>>>>>> to
> > >>>>>>>>> lazy
> > >>>>>>>>>>>>>> majority
> > >>>>>>>>>>>>>>>> if
> > >>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>> -1
> > >>>>>>>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> received".
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> > >>>>>> that a
> > >>>>>>>>>>> committer
> > >>>>>>>>>>>>>>> always
> > >>>>>>>>>>>>>>>>>>> needs a
> > >>>>>>>>>>>>>>>>>>>>>>>>>> review
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> > >>>>>> as I
> > >>>>>>>>> know
> > >>>>>>>>>>>>> this is
> > >>>>>>>>>>>>>>>>>> currently
> > >>>>>>>>>>>>>>>>>>>> not
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> > >>>>>>>>>> contributor
> > >>>>>>>>>>>>>>> reviews
> > >>>>>>>>>>>>>>>> &
> > >>>>>>>>>>>>>>>>>>> +1s).
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
> > >>>>>> how
> > >>>>>>>> we
> > >>>>>>>>>> can
> > >>>>>>>>>>>>> make
> > >>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>> easy
> > >>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>> follow
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> > >>>>>>>> Flink-specific
> > >>>>>>>>>> Jira
> > >>>>>>>>>>>>>>>> workflows
> > >>>>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>> ticket
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> types +
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
> > >>>>>> this
> > >>>>>>> is
> > >>>>>>>>>>>>> certainly
> > >>>>>>>>>>>>>>>> "Step
> > >>>>>>>>>>>>>>>>>> 2",
> > >>>>>>>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> believe,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> > >>>>>>>>> transparent
> > >>>>>>>>>>> as
> > >>>>>>>>>>>>>>>> possible,
> > >>>>>>>>>>>>>>>>>>>> otherwise
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> they
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
> > >>>>>> Becket
> > >>>>>>>>> Qin <
> > >>>>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
> > >>>>>> process
> > >>>>>>>>>>> discussion
> > >>>>>>>>>>>>>>> thread
> > >>>>>>>>>>>>>>>>>> [1],
> > >>>>>>>>>>>>>>>>>>>>>>>>>> currently
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
> > >>>>>>> govern
> > >>>>>>>>> the
> > >>>>>>>>>>>>>>> operation
> > >>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>> project.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
> > >>>>>> community
> > >>>>>>>> to
> > >>>>>>>>>>>>>> coordinate
> > >>>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>>>>>> contribute
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
> > >>>>>>> other
> > >>>>>>>>>>>>> processes
> > >>>>>>>>>>>>>>> such
> > >>>>>>>>>>>>>>>>> as
> > >>>>>>>>>>>>>>>>>>>> FLIP.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
> > >>>>> page
> > >>>>>>> and
> > >>>>>>>>>> would
> > >>>>>>>>>>>>> like
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>> start a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> discussion
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
> > >>>>> in
> > >>>>>>> the
> > >>>>>>>>>>>>> community.
> > >>>>>>>>>>>>>>>> It'll
> > >>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>>> great to
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> hear
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
> > >>>>>> Architect
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
> > >>>>>>>> 31.08.2019,
> > >>>>>>>>>>>>> 05.09. -
> > >>>>>>>>>>>>>>>>>>> 06.09.2010
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
> > >>>>>> 115,
> > >>>>>>>>> 10115
> > >>>>>>>>>>>>>> Berlin,
> > >>>>>>>>>>>>>>>>>> Germany
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
> > >>>>>>>> Charlottenburg:
> > >>>>>>>>>> HRB
> > >>>>>>>>>>>>>> 158244
> > >>>>>>>>>>>>>>> B
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
> > >>>>>>> Tzoumas,
> > >>>>>>>>> Dr.
> > >>>>>>>>>>>>> Stephan
> > >>>>>>>>>>>>>>>> Ewen
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>

Re: [DISCUSS] Flink project bylaws

[Robert Metzger <rm...@apache.org>]

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 <mx...@apache.org> wrote:

> Hi Becket,
>
> Thanks for clarifying and updating the draft. The changes look good to me.
>
> I don't feel strong about a 2/3 majority in case of committer/PMC
> removal. Like you pointed out, both provide a significant hurdle due to
> possible vetos or a 2/3 majority.
>
> Thanks,
> Max
>
> On 13.08.19 10:36, Becket Qin wrote:
> > Piotr just reminded me that there was a previous suggestion to clarify a
> > committer's responsibility when commit his/her own patch. So I'd like to
> > incorporate that in the bylaws. The additional clarification is following
> > in bold and italic font.
> >
> > one +1 from a committer followed by a Lazy approval (not counting the
> vote
> >> of the contributor), moving to lazy majority if a -1 is received.
> >>
> >
> >
> > Note that this implies that committers can +1 their own commits and merge
> >> right away. *However, the committe**rs should use their best judgement
> to
> >> respect the components expertise and ongoing development plan.*
> >
> >
> > This does not really change any of the existing bylaws, just about
> > clarification.
> >
> > If there is no objection to this additional clarification, after the
> bylaws
> > wiki is updated, I'll send an update notice to the voting thread to
> inform
> > those who already voted about this addition.
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin <be...@gmail.com>
> wrote:
> >
> >> Hi Maximillian,
> >>
> >> Thanks for the feedback. Please see the reply below:
> >>
> >> Step 2 should include a personal email to the PMC members in question.
> >>
> >> I'm afraid reminders inside the vote thread could be overlooked easily.
> >>
> >>
> >> This is exactly what I meant to say by "reach out" :) I just made it
> more
> >> explicit.
> >>
> >> The way the terms are described in the draft, the consensus is "lazy",
> >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy
> >>> Consensus". This is in line with the other definitions such as "Lazy
> >>> Majority".
> >>
> >> It was initially called "lazy consensus", but Robert pointed out that
> >> "lazy consensus" actually means something different in ASF term [1].
> >> Here "lazy" pretty much means "assume everyone is +1 unless someone says
> >> otherwise". This means any vote that requires a minimum number of +1 is
> not
> >> really a "lazy" vote.
> >>
> >> Removing a committer / PMC member only requires 3 binding votes. I'd
> >>> expect an important action like this to require a 2/3 majority.
> >>
> >> Personally I think consensus is good enough here. PMC members can cast a
> >> veto if they disagree about the removal. In some sense, it is more
> >> difficult than with 2/3 majority to remove a committer / PMC member.
> Also,
> >> it might be a hard decision for some PMC members if they have never
> worked
> >> with the person in question. That said, I am OK to change it to 2/3
> >> majority as this will happen very rarely.
> >>
> >> Thanks,
> >>
> >> Jiangjie (Becket) Qin
> >>
> >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus
> >>
> >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <mx...@apache.org>
> wrote:
> >>
> >>> I'm a bit late to the discussion here. Three suggestions:
> >>>
> >>> 1) Procedure for "insufficient active binding voters to reach 2/3
> majority
> >>>
> >>>>     1. Wait until the minimum length of the voting passes.
> >>>>     2. Publicly reach out to the remaining binding voters in the
> voting
> >>> mail thread for at least 2 attempts with at least 7 days between two
> >>> attempts.
> >>>>     3. If the binding voter being contacted still failed to respond
> >>> after all the attempts, the binding voter will be considered as
> inactive
> >>> for the purpose of this particular voting.
> >>>
> >>> Step 2 should include a personal email to the PMC members in question.
> >>> I'm afraid reminders inside the vote thread could be overlooked easily.
> >>>
> >>> 2) "Consensus" => "Lazy Consensus"
> >>>
> >>> The way the terms are described in the draft, the consensus is "lazy",
> >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy
> >>> Consensus". This is in line with the other definitions such as "Lazy
> >>> Majority".
> >>>
> >>> 3) Committer / PMC Removal
> >>>
> >>> Removing a committer / PMC member only requires 3 binding votes. I'd
> >>> expect an important action like this to require a 2/3 majority.
> >>>
> >>>
> >>> Do you think we could incorporate those suggestions?
> >>>
> >>> Thanks,
> >>> Max
> >>>
> >>> On 11.08.19 10:14, Becket Qin wrote:
> >>>> Hi folks,
> >>>>
> >>>> Thanks for all the discussion and support. I have started the voting
> >>> thread.
> >>>>
> >>>>
> >>>
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jiangjie (Becket) Qin
> >>>>
> >>>> On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <fh...@gmail.com>
> wrote:
> >>>>
> >>>>> Thanks for the update and driving the discussion Becket!
> >>>>> +1 for starting a vote.
> >>>>>
> >>>>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
> >>> becket.qin@gmail.com
> >>>>>> :
> >>>>>
> >>>>>> Thanks Stephan.
> >>>>>>
> >>>>>> I think we have resolved all the comments on the wiki page. There
> are
> >>> two
> >>>>>> minor changes made to the bylaws since last week.
> >>>>>> 1. For 2/3 majority, the required attempts to reach out to binding
> >>> voters
> >>>>>> is reduced from 3 to 2. This helps shorten the voting process a
> little
> >>>>> bit.
> >>>>>> 2. Clarified what is considered as the adoption of new codebase.
> >>>>>>
> >>>>>> I think we almost reached consensus. I'll start a voting thread in
> two
> >>>>> days
> >>>>>> if there is no new concerns.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Jiangjie (Becket) Qin
> >>>>>>
> >>>>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org>
> wrote:
> >>>>>>
> >>>>>>> I added a clarification to the table, clarifying that the current
> >>>>>> phrasing
> >>>>>>> means that committers do not need another +1 for their commits.
> >>>>>>>
> >>>>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fh...@gmail.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi Becket,
> >>>>>>>>
> >>>>>>>> Thanks a lot for pushing this forward and addressing the feedback.
> >>>>>>>> I'm very happy with the current state of the bylaws.
> >>>>>>>> +1 to wait until Friday before starting a vote.
> >>>>>>>>
> >>>>>>>> Best, Fabian
> >>>>>>>>
> >>>>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> >>>>>>>> becket.qin@gmail.com
> >>>>>>>>> :
> >>>>>>>>
> >>>>>>>>> Hi Everyone,
> >>>>>>>>>
> >>>>>>>>> Thanks for all the discussion and feedback.
> >>>>>>>>>
> >>>>>>>>> It seems that we have almost reached consensus. I'll leave the
> >>>>>>> discussion
> >>>>>>>>> thread open until this Friday. If there is no more concerns
> raised,
> >>>>>>> I'll
> >>>>>>>>> start a voting thread after that.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>
> >>>>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi Becket,
> >>>>>>>>>>
> >>>>>>>>>> Thanks for noticing and resolving my comment around PMC removal
> >>>>> and
> >>>>>>> ASF
> >>>>>>>>>> rules of PMC membership change process, which you seem to
> neglect
> >>>>>> in
> >>>>>>>> the
> >>>>>>>>>> summary of updates (smile).
> >>>>>>>>>>
> >>>>>>>>>> Best Regards,
> >>>>>>>>>> Yu
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <be...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi folks,
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for all the feedback.
> >>>>>>>>>>>
> >>>>>>>>>>> It seems that there are a few concerns over the emeritus status
> >>>>>>>> after 6
> >>>>>>>>>>> months of inactivity. Given that the main purpose is just to
> >>>>> make
> >>>>>>>> sure
> >>>>>>>>>> 2/3
> >>>>>>>>>>> majority can pass and we sort of have a solution for that, I
> >>>>> just
> >>>>>>>>> updated
> >>>>>>>>>>> the draft with the following changes:
> >>>>>>>>>>>
> >>>>>>>>>>> 1. Removed the inactivity term for emeritus committers / PMCs.
> >>>>> A
> >>>>>>>>>> committer
> >>>>>>>>>>> / PMC will only be considered emeritus by their own claim.
> >>>>>>>>>>> 2. Removed the approval process for reinstatement of the
> >>>>> emeritus
> >>>>>>>>>>> committers / PMCs. An emeritus committer / PMC will be
> >>>>> reinstated
> >>>>>>>> when
> >>>>>>>>>> they
> >>>>>>>>>>> send an email to the private@flink.apache.org.
> >>>>>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still doable
> >>>>>> when
> >>>>>>>>> there
> >>>>>>>>>>> are non-emeritus committers / PMCs who do not cast the vote.
> >>>>>>>>>>>
> >>>>>>>>>>> Please let me know if you have any further thoughts.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
> >>>>>> becket.qin@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Fabian,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks for the feedback.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I agree that if we don't like emeritus committers / PMCs, we
> >>>>>>> don't
> >>>>>>>>> have
> >>>>>>>>>>> to
> >>>>>>>>>>>> do it. That said, emeritus status simply means whether an
> >>>>>>>> individual
> >>>>>>>>> is
> >>>>>>>>>>>> active / inactive in the community. It does not make the
> >>>>> merits
> >>>>>>>>> earned
> >>>>>>>>>> to
> >>>>>>>>>>>> go away. For our purpose, emeritus status is mostly just a
> >>>>> way
> >>>>>> to
> >>>>>>>>> make
> >>>>>>>>>>> 2/3
> >>>>>>>>>>>> majority possible. As you noticed, since reaching out to
> >>>>>> binding
> >>>>>>>>> voters
> >>>>>>>>>>> who
> >>>>>>>>>>>> have not voted can achieve the same goal, the emeritus status
> >>>>>> is
> >>>>>>>> more
> >>>>>>>>>> of
> >>>>>>>>>>> an
> >>>>>>>>>>>> optimization so we don't have to ping the inactive binding
> >>>>>> voters
> >>>>>>>>> every
> >>>>>>>>>>>> time and wait for long. However, given that 2/3 majority
> >>>>>> votings
> >>>>>>>> are
> >>>>>>>>>>> rare,
> >>>>>>>>>>>> such communication cost is probably OK. So I think we can
> >>>>>> remove
> >>>>>>>> that
> >>>>>>>>>>>> emeritus part from the bylaws.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1) We should add to the requirements of the PMC that they
> >>>>> need
> >>>>>> to
> >>>>>>>>> make
> >>>>>>>>>>>>> sure the project complies with brand issues and reports
> >>>>> misuse
> >>>>>>> of
> >>>>>>>>> ASF
> >>>>>>>>>>>>> brands.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Good point. Added.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
> >>>>> a
> >>>>>> 3
> >>>>>>>> day
> >>>>>>>>>> vote
> >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
> >>>>>>>>>>>>
> >>>>>>>>>>>> This might be a little tricky because people are from
> >>>>> countries
> >>>>>>> in
> >>>>>>>>>>>> different time zones and with different holidays, and so on.
> >>>>> If
> >>>>>>> we
> >>>>>>>>> are
> >>>>>>>>>>>> worrying about 3 days minimum length is not enough for those
> >>>>>> who
> >>>>>>>> want
> >>>>>>>>>> to
> >>>>>>>>>>>> give feedback, we can make it 5 days.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 3) Do we need a process do decide about removal of features
> >>>>>> (like
> >>>>>>>> the
> >>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
> >>>>>> Python
> >>>>>>>>>> APIs)?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I assume such action should be covered by FLIP as it is a
> >>>>>> change
> >>>>>>> to
> >>>>>>>>> the
> >>>>>>>>>>>> API and probably needs a migration plan. It would be useful
> >>>>> to
> >>>>>>>> have a
> >>>>>>>>>>>> formal deprecation procedure. But that might be better to be
> >>>>>> put
> >>>>>>>> into
> >>>>>>>>>>>> somewhere else because the bylaws are primarily focusing on
> >>>>> the
> >>>>>>>>>>>> non-technical rules, whereas the deprecation seems more on
> >>>>> the
> >>>>>>>>>> technical
> >>>>>>>>>>>> side.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
> >>>>>>> fhueske@gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> First of all thank you very much Becket for starting this
> >>>>>>>>> discussion!
> >>>>>>>>>>>>> I think it is a very good idea and overdue to formally
> >>>>> define
> >>>>>>> some
> >>>>>>>>> of
> >>>>>>>>>>> our
> >>>>>>>>>>>>> community processes.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Similar to Chesnay, I have concerns about the distinction
> >>>>>>> between
> >>>>>>>>>> active
> >>>>>>>>>>>>> and non-active / emeritus committers and PMC members.
> >>>>>>>>>>>>> My foremost concern is that this is not in the spirit of the
> >>>>>>>> Apache
> >>>>>>>>>> Way
> >>>>>>>>>>>>> [1]
> >>>>>>>>>>>>> which is (among other things) based on the idea of merit
> >>>>> which
> >>>>>>>> once
> >>>>>>>>>>>>> earned,
> >>>>>>>>>>>>> does not go away over time.
> >>>>>>>>>>>>> I know other projects like Hadoop and Kafka have similar
> >>>>>> clauses
> >>>>>>>> in
> >>>>>>>>>> the
> >>>>>>>>>>>>> bylaws but IMO we don't need to adopt them if we don't like
> >>>>>>> them.
> >>>>>>>>>>>>> For example, I don't like the idea that committers or PMC
> >>>>>>> members
> >>>>>>>>> who
> >>>>>>>>>>> are
> >>>>>>>>>>>>> temporarily away from the project (for whatever reason:
> >>>>>> parental
> >>>>>>>>>> leave,
> >>>>>>>>>>>>> sabbatical, health issues, etc.) need the PMC approval to be
> >>>>>>>>> "active"
> >>>>>>>>>>>>> again.
> >>>>>>>>>>>>> As far as I am aware, we have not seen any issues with
> >>>>>> inactive
> >>>>>>>>>> members
> >>>>>>>>>>> in
> >>>>>>>>>>>>> the past.
> >>>>>>>>>>>>> Moreover, it would be hard to track whether somebody became
> >>>>>>>> inactive
> >>>>>>>>>> at
> >>>>>>>>>>>>> some point in time (which we would need to do, if I
> >>>>> understand
> >>>>>>> the
> >>>>>>>>>>>>> proposal
> >>>>>>>>>>>>> correctly).
> >>>>>>>>>>>>> With the approach that Becket suggested in his last email
> >>>>>>>> (reaching
> >>>>>>>>>> out
> >>>>>>>>>>> to
> >>>>>>>>>>>>> binding voters who haven't voted yet), we could drop the
> >>>>>>>> distinction
> >>>>>>>>>>>>> between active and non-active committers and PMC members.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I also have a few minor comments:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1) We should add to the requirements of the PMC [2] that
> >>>>> they
> >>>>>>> need
> >>>>>>>>> to
> >>>>>>>>>>> make
> >>>>>>>>>>>>> sure the project complies with brand issues and reports
> >>>>> misuse
> >>>>>>> of
> >>>>>>>>> ASF
> >>>>>>>>>>>>> brands.
> >>>>>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
> >>>>>> a 3
> >>>>>>>> day
> >>>>>>>>>>> vote
> >>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
> >>>>>>>>>>>>> 3) Do we need a process do decide about removal of features
> >>>>>>> (like
> >>>>>>>>> the
> >>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
> >>>>>> Python
> >>>>>>>>>> APIs)?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thank you,
> >>>>>>>>>>>>> Fabian
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] https://www.apache.org/theapacheway/
> >>>>>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> >>>>>>>>>>>>> becket.qin@gmail.com
> >>>>>>>>>>>>>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Hequn,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see the reply
> >>>>>> below:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one PMC
> >>>>> in
> >>>>>>>> the 3
> >>>>>>>>>>>>> binding
> >>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> >>>>> and 1
> >>>>>>>> PMC.
> >>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> >>>>> somehow
> >>>>>>> be a
> >>>>>>>>> big
> >>>>>>>>>>>>>> feature
> >>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
> >>>>> loss
> >>>>>>> of
> >>>>>>>>>>>>> flexibility
> >>>>>>>>>>>>>>> as committers also have a chance to vote and participate
> >>>>>> in
> >>>>>>>> it.
> >>>>>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs are
> >>>>> the
> >>>>>>>>>> following:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 1. Generally speaking, the PMC's primary responsibility is
> >>>>>>>>> operating
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> project and deciding what software to release on behalf of
> >>>>>>> ASF.
> >>>>>>>>>>>>> Committers,
> >>>>>>>>>>>>>> on the other hand, are responsible for the technical part
> >>>>> of
> >>>>>>> the
> >>>>>>>>>>>>> project.
> >>>>>>>>>>>>>> So for FLIPs, a PMC's vote probably should not outweigh a
> >>>>>>>>>> committer's
> >>>>>>>>>>>>> vote.
> >>>>>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is really
> >>>>>>>>> convincing
> >>>>>>>>>>>>> enough
> >>>>>>>>>>>>>> to decide whether the FLIP is good to go or not. Also, if
> >>>>>> some
> >>>>>>>>>>>>> committers
> >>>>>>>>>>>>>> have concern over a FLIP, they could just veto it. To me
> >>>>> it
> >>>>>> is
> >>>>>>>>>>> actually
> >>>>>>>>>>>>> a
> >>>>>>>>>>>>>> more strict requirement to pass a FLIP than asking a PMC
> >>>>> to
> >>>>>>>> vote.
> >>>>>>>>> In
> >>>>>>>>>>>>>> practice, people will usually also address the concerns
> >>>>> even
> >>>>>>> if
> >>>>>>>>> they
> >>>>>>>>>>> are
> >>>>>>>>>>>>>> not from a PMC/committer before they start the voting
> >>>>>> process.
> >>>>>>>> So
> >>>>>>>>> I
> >>>>>>>>>>>>> don't
> >>>>>>>>>>>>>> see much benefit of requiring a PMC's vote in this case.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the votes
> >>>>> no
> >>>>>>>> longer
> >>>>>>>>>>>>>> independent. Ideally, a vote is either binding or
> >>>>>> non-binding
> >>>>>>> by
> >>>>>>>>>>>>> itself. If
> >>>>>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
> >>>>> imagine
> >>>>>>>> there
> >>>>>>>>>> have
> >>>>>>>>>>>>> been
> >>>>>>>>>>>>>> 3 committers who voted +1. But the FLIP still has not
> >>>>>> passed,
> >>>>>>> so
> >>>>>>>>>> those
> >>>>>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a +1,
> >>>>>> those
> >>>>>>>>> votes
> >>>>>>>>>>>>>> suddenly become binding, which is a little awkward.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable to me.
> >>>>>> Some
> >>>>>>>>>>> thoughts
> >>>>>>>>>>>>> on
> >>>>>>>>>>>>>> this:
> >>>>>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is probably
> >>>>>>> because
> >>>>>>>>>> there
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3 majority
> >>>>>>>>>>> prohibitively
> >>>>>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
> >>>>> Flink[2]
> >>>>>>> and
> >>>>>>>> a
> >>>>>>>>>>> quick
> >>>>>>>>>>>>>> search shows at most 6 of them have not sent email in the
> >>>>>>>> recent 6
> >>>>>>>>>>>>> months
> >>>>>>>>>>>>>> or so.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare. It is
> >>>>>>>> designed
> >>>>>>>>>> in
> >>>>>>>>>>>>>> particular for the cases that broad opinions are
> >>>>> important,
> >>>>>>> more
> >>>>>>>>>>>>>> specifically new codebase adoption or modification to the
> >>>>>>>> bylaws.
> >>>>>>>>>>>>> Therefore
> >>>>>>>>>>>>>> such vote by its nature favors consensus over convenience.
> >>>>>>> That
> >>>>>>>>>> means
> >>>>>>>>>>>>> any
> >>>>>>>>>>>>>> alternative voting type reducing the coverage worth a
> >>>>>> careful
> >>>>>>>>>>> thinking.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 3. I do agree that it does not make sense to have 2/3
> >>>>>> majority
> >>>>>>>> if
> >>>>>>>>>> such
> >>>>>>>>>>>>>> requirement is no-longer doable over time. But I am a
> >>>>> little
> >>>>>>>>>> hesitant
> >>>>>>>>>>> to
> >>>>>>>>>>>>>> lower the threshold to lazy 2/3 majority in our case. What
> >>>>>> do
> >>>>>>>> you
> >>>>>>>>>>> think
> >>>>>>>>>>>>>> about doing the following:
> >>>>>>>>>>>>>>     - After the voting started, there will be at least 6
> >>>>>> days
> >>>>>>>> for
> >>>>>>>>>>>>> people to
> >>>>>>>>>>>>>> cast their votes.
> >>>>>>>>>>>>>>     - After 6 days, if the result of the vote is still not
> >>>>>>>>>> determined,
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>> person who started the vote should reach out to the
> >>>>> binding
> >>>>>>>> voters
> >>>>>>>>>> who
> >>>>>>>>>>>>> have
> >>>>>>>>>>>>>> not voted yet for at least 3 times and at least 7 days
> >>>>>> between
> >>>>>>>>> each
> >>>>>>>>>>>>> time.
> >>>>>>>>>>>>>> If a binding voter still did not respond, the vote from
> >>>>> that
> >>>>>>>> voter
> >>>>>>>>>>> will
> >>>>>>>>>>>>> be
> >>>>>>>>>>>>>> excluded from the 2/3 majority counting.
> >>>>>>>>>>>>>> This would ensure the coverage at our best effort while
> >>>>>> still
> >>>>>>>> let
> >>>>>>>>>> the
> >>>>>>>>>>>>> 2/3
> >>>>>>>>>>>>>> majority vote make progress.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> [1] https://projects.apache.org/committee.html?hadoop
> >>>>>>>>>>>>>> [2] https://projects.apache.org/committee.html?flink
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> >>>>>>>>> forwardxu315@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Big +1 on this.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> best
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> forward
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
> >>>>>> 下午1:30写道：
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi Becket,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Big +1 on this.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> >>>>>>> includes a
> >>>>>>>>> PMC
> >>>>>>>>>>>>> vote.
> >>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
> >>>>> PMC
> >>>>>> in
> >>>>>>>>> the 3
> >>>>>>>>>>>>>> binding
> >>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> >>>>>> and 1
> >>>>>>>>> PMC.
> >>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
> >>>>>> somehow
> >>>>>>>> be a
> >>>>>>>>>> big
> >>>>>>>>>>>>>>> feature
> >>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
> >>>>>> loss
> >>>>>>>> of
> >>>>>>>>>>>>>> flexibility
> >>>>>>>>>>>>>>>> as committers also have a chance to vote and
> >>>>> participate
> >>>>>>> in
> >>>>>>>>> it.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ========Seperator========
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> For the nice bylaws, I agree with the general idea and
> >>>>>>> most
> >>>>>>>> of
> >>>>>>>>>> the
> >>>>>>>>>>>>>>> content.
> >>>>>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority". The
> >>>>>>> main
> >>>>>>>>>>> concern
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>> am
> >>>>>>>>>>>>>>>> not sure if it is doable in practice. The reasons are:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
> >>>>>> committer
> >>>>>>>> or a
> >>>>>>>>>> PMC
> >>>>>>>>>>>>>> member
> >>>>>>>>>>>>>>>> is active if he or she sends one email to the mailing
> >>>>>> list
> >>>>>>>>>> every 6
> >>>>>>>>>>>>>>> months.
> >>>>>>>>>>>>>>>> While the minimum length of the vote is only 6 days.
> >>>>>> There
> >>>>>>>> are
> >>>>>>>>>>>>> chances
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> during the vote, some of the active members are still
> >>>>>>>> offline
> >>>>>>>>> of
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>>> community.
> >>>>>>>>>>>>>>>> 2. The code of Flink is changing fast and not everyone
> >>>>>>> fully
> >>>>>>>>>>>>>> understands
> >>>>>>>>>>>>>>>> every part. We don't need to force people to vote if
> >>>>>> they
> >>>>>>>> are
> >>>>>>>>>> not
> >>>>>>>>>>>>> sure
> >>>>>>>>>>>>>>>> about it. It may also make the final result less
> >>>>>> credible.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Given the above reasons, perhaps we can change the 2/3
> >>>>>>>>> Majority
> >>>>>>>>>> to
> >>>>>>>>>>>>> lazy
> >>>>>>>>>>>>>>> 2/3
> >>>>>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
> >>>>>> higher
> >>>>>>>>>>> threshold,
> >>>>>>>>>>>>>>>> however, more practical.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> What do you think?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> >>>>>>>>>> becket.qin@gmail.com
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hi Jincheng,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki page.
> >>>>>>> Just
> >>>>>>>> a
> >>>>>>>>>>> brief
> >>>>>>>>>>>>>>>> summary,
> >>>>>>>>>>>>>>>>> the current bylaws do require some of the FLIPs to
> >>>>> get
> >>>>>>> PMC
> >>>>>>>>>>>>> approval
> >>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>> their impact is big enough. But it leaves majority
> >>>>> of
> >>>>>>> the
> >>>>>>>>>>>>> technical
> >>>>>>>>>>>>>>>>> decisions to the committers who are supposed to be
> >>>>>>>>> responsible
> >>>>>>>>>>> for
> >>>>>>>>>>>>>>> making
> >>>>>>>>>>>>>>>>> such decisions.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Re: Robert,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I agree we can simply remove the requirement of +1
> >>>>>> from
> >>>>>>> a
> >>>>>>>>>>>>> non-author
> >>>>>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
> >>>>> does
> >>>>>>> not
> >>>>>>>>> make
> >>>>>>>>>>>>> sense
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
> >>>>>> updated
> >>>>>>>> the
> >>>>>>>>>>> bylaws
> >>>>>>>>>>>>>>> wiki.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> >>>>>>>>>>>>> rmetzger@apache.org
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
> >>>>>>> current
> >>>>>>>>>>> status
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
> >>>>> is
> >>>>>> a
> >>>>>>>> very
> >>>>>>>>>>>>> involved
> >>>>>>>>>>>>>>>> task.
> >>>>>>>>>>>>>>>>>> Unless there's somebody who's really eager to
> >>>>> drive
> >>>>>>>> this,
> >>>>>>>>> I
> >>>>>>>>>>>>> would
> >>>>>>>>>>>>>>> stick
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
> >>>>>> Flink,
> >>>>>>>> even
> >>>>>>>>>> if
> >>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>> means
> >>>>>>>>>>>>>>>>>> some changes.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The cross-review requirement is the last big open
> >>>>>>> point
> >>>>>>>> in
> >>>>>>>>>>> this
> >>>>>>>>>>>>>>>>> discussion.
> >>>>>>>>>>>>>>>>>> It seems that a there is a slight tendency in the
> >>>>>>>>> discussion
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>> not feasible given the current pull request review
> >>>>>>>>>> situation.
> >>>>>>>>>>>>>>>>>> For the sake of bringing this discussion to a
> >>>>>>>> conclusion,
> >>>>>>>>>> I'm
> >>>>>>>>>>>>> fine
> >>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>> leaving this requirement out. As we are currently
> >>>>>>> adding
> >>>>>>>>>> more
> >>>>>>>>>>>>>>>> committers
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> the project, we might be able to revisit this
> >>>>>>> discussion
> >>>>>>>>> in
> >>>>>>>>>> 3
> >>>>>>>>>>> -
> >>>>>>>>>>>>> 6
> >>>>>>>>>>>>>>>> months.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> >>>>>>>>>>>>>>> sunjincheng121@gmail.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Hi Becket,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Thanks for the proposal.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> >>>>>>>>> includes a
> >>>>>>>>>>> PMC
> >>>>>>>>>>>>>>> vote.
> >>>>>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
> >>>>>> the
> >>>>>>>>> user's
> >>>>>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>>>>> changes. What do you think? (I leave the comment
> >>>>>> in
> >>>>>>>> the
> >>>>>>>>>>> wiki.)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>>>> Jincheng
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
> >>>>>>>> 于2019年7月17日周三
> >>>>>>>>>>>>>> 下午9:12写道：
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
> >>>>>> that
> >>>>>>> I
> >>>>>>>>>> really
> >>>>>>>>>>>>> like
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> proposed bylaws!
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
> >>>>>>>>> expressed
> >>>>>>>>>> by
> >>>>>>>>>>>>> few
> >>>>>>>>>>>>>>>> people
> >>>>>>>>>>>>>>>>>>>> before that the "committer +1" on code change
> >>>>>>> might
> >>>>>>>> be
> >>>>>>>>>>> hard
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> achieve
> >>>>>>>>>>>>>>>>>>>> currently. On the other hand I would say this
> >>>>>>> would
> >>>>>>>> be
> >>>>>>>>>>>>>> beneficial
> >>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
> >>>>>>> knowledge
> >>>>>>>>>>>>> sharing.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I was just wondering what should be the next
> >>>>>> step
> >>>>>>>> for
> >>>>>>>>>>> this?
> >>>>>>>>>>>>> I
> >>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>> would make sense to already use those bylaws
> >>>>> and
> >>>>>>> put
> >>>>>>>>>> them
> >>>>>>>>>>> to
> >>>>>>>>>>>>>> PMC
> >>>>>>>>>>>>>>>>> vote.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Dawid
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
> >>>>>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
> >>>>> think.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> >>>>>> If
> >>>>>>> we
> >>>>>>>>> are
> >>>>>>>>>>>>>> stating
> >>>>>>>>>>>>>>>>> that a
> >>>>>>>>>>>>>>>>>>>> single
> >>>>>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
> >>>>>> review,
> >>>>>>>>> with 0
> >>>>>>>>>>>>> hours
> >>>>>>>>>>>>>>>> delay
> >>>>>>>>>>>>>>>>>> (de
> >>>>>>>>>>>>>>>>>>>> facto
> >>>>>>>>>>>>>>>>>>>>>>> the current state), we should also write
> >>>>>> down
> >>>>>>>> that
> >>>>>>>>>>> this
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>> subject
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
> >>>>>> the
> >>>>>>>>>>>>> components
> >>>>>>>>>>>>>>>>> expertise
> >>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
> >>>>> facto
> >>>>>>>>> current
> >>>>>>>>>>>>>> state).
> >>>>>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
> >>>>>>>>>> intention,
> >>>>>>>>>>>>> but
> >>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>> may
> >>>>>>>>>>>>>>>>>> be a
> >>>>>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
> >>>>>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
> >>>>>>> rule
> >>>>>>>>>>> anyway,
> >>>>>>>>>>>>>>>> intended
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
> >>>>>> to
> >>>>>>>> just
> >>>>>>>>>>>>> avoid a
> >>>>>>>>>>>>>>>>>> situation
> >>>>>>>>>>>>>>>>>>>> when someone violates current uncodified state
> >>>>>> and
> >>>>>>>>>> refers
> >>>>>>>>>>> to
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> bylaws
> >>>>>>>>>>>>>>>>>>>> which are saying merging with any committer +1
> >>>>>> is
> >>>>>>>>> always
> >>>>>>>>>>>>> fine
> >>>>>>>>>>>>>>> (like
> >>>>>>>>>>>>>>>>>> mine
> >>>>>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>>>>> for flink-python or flink-ml).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Piotrek
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
> >>>>> <
> >>>>>>>>>>>>>>> aljoscha@apache.org
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
> >>>>>> FLIP.
> >>>>>>>>> This
> >>>>>>>>>> is
> >>>>>>>>>>>>> just
> >>>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> voting, before that there needs to be the
> >>>>>>> discussion
> >>>>>>>>>>>>> thread. If
> >>>>>>>>>>>>>>>> three
> >>>>>>>>>>>>>>>>>>> days
> >>>>>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
> >>>>>>> (i.e. 3
> >>>>>>>>>>>>>>>> committers/PMCs
> >>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
> >>>>>> So
> >>>>>>>> far,
> >>>>>>>>>> we
> >>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>> rarely
> >>>>>>>>>>>>>>>>>> see
> >>>>>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
> >>>>> we
> >>>>>>> want
> >>>>>>>>> to
> >>>>>>>>>>> use
> >>>>>>>>>>>>>> "lazy
> >>>>>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
> >>>>>>> that
> >>>>>>>>>> should
> >>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>> changed
> >>>>>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
> >>>>>>> current
> >>>>>>>>>> state
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>> all
> >>>>>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
> >>>>>>> come
> >>>>>>>> up
> >>>>>>>>>>> with
> >>>>>>>>>>>>>>>> something
> >>>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>> reflects the common state, according to
> >>>>>>>>> PMCs/commiters,
> >>>>>>>>>>> that
> >>>>>>>>>>>>>>> might
> >>>>>>>>>>>>>>>>>> take a
> >>>>>>>>>>>>>>>>>>>> very long time. In that case I think it’s
> >>>>> better
> >>>>>>> to
> >>>>>>>>>> adopt
> >>>>>>>>>>>>>>> something
> >>>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
> >>>>>> do
> >>>>>>> it
> >>>>>>>>>> now.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Aljoscha
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
> >>>>> <
> >>>>>>>>>>>>>>> piotr@ververica.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
> >>>>> speaking
> >>>>>> +1
> >>>>>>>>> from
> >>>>>>>>>> my
> >>>>>>>>>>>>> side
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> general idea and most of the content. I also
> >>>>> see
> >>>>>>>> merit
> >>>>>>>>>> to
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> Chesney's
> >>>>>>>>>>>>>>>>>>>> proposal to start from the current state. I
> >>>>>> think
> >>>>>>>>> either
> >>>>>>>>>>>>> would
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>> fine
> >>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>> me.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Couple of comments:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 1.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
> >>>>> another
> >>>>>>>>>> committer
> >>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>> slow
> >>>>>>>>>>>>>>>>>> down
> >>>>>>>>>>>>>>>>>>>> and put even more strain on the current
> >>>>>> reviewing
> >>>>>>>>>>> bottleneck
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
> >>>>>>> context
> >>>>>>>>>>> switch
> >>>>>>>>>>>>>> cost
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
> >>>>>> second
> >>>>>>>>>> “cross”
> >>>>>>>>>>>>>>> committer
> >>>>>>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
> >>>>>>> Besides,
> >>>>>>>>>>> current
> >>>>>>>>>>>>>> setup
> >>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
> >>>>>>>>> required)
> >>>>>>>>>>>>> works
> >>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>>> well
> >>>>>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
> >>>>>> the
> >>>>>>>>> other
> >>>>>>>>>>> hand
> >>>>>>>>>>>>>>>>> reviewing
> >>>>>>>>>>>>>>>>>>>> bottleneck is.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 2.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
> >>>>> ask
> >>>>>>>>> another
> >>>>>>>>>>>>>>> committer
> >>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>> feedback or not.
> >>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> >>>>>> If
> >>>>>>> we
> >>>>>>>>> are
> >>>>>>>>>>>>>> stating
> >>>>>>>>>>>>>>>>> that a
> >>>>>>>>>>>>>>>>>>>> single committers +1 is good enough for code
> >>>>>>> review,
> >>>>>>>>>> with
> >>>>>>>>>>> 0
> >>>>>>>>>>>>>> hours
> >>>>>>>>>>>>>>>>> delay
> >>>>>>>>>>>>>>>>>>> (de
> >>>>>>>>>>>>>>>>>>>> facto the current state), we should also write
> >>>>>>> down
> >>>>>>>>> that
> >>>>>>>>>>>>> this
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>> subject
> >>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> the best judgement of the committer to respect
> >>>>>> the
> >>>>>>>>>>>>> components
> >>>>>>>>>>>>>>>>> expertise
> >>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
> >>>>>>> current
> >>>>>>>>>>> state).
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 3.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
> >>>>>>>>> currently
> >>>>>>>>>>>>> might
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
> >>>>>> if
> >>>>>>>>>>> respected
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> letter.
> >>>>>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
> >>>>>>>>>> committers
> >>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>> highest
> >>>>>>>>>>>>>>>>>>>> expertise in the affected components managed
> >>>>> to
> >>>>>>>>> respond
> >>>>>>>>>> or
> >>>>>>>>>>>>> not.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Piotrek
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
> >>>>> Schepler
> >>>>>> <
> >>>>>>>>>>>>>>>> chesnay@apache.org>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
> >>>>>>> write
> >>>>>>>>> down
> >>>>>>>>>>>>> Bylaws
> >>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>>> reflect the current state, and then have
> >>>>>> separate
> >>>>>>>>>>>>> discussions
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
> >>>>>> this
> >>>>>>>>>>>>> discussion
> >>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>> quickly
> >>>>>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
> >>>>>>>>> discussed
> >>>>>>>>>>> at
> >>>>>>>>>>>>>> once.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
> >>>>>> Qin
> >>>>>>> <
> >>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
> >>>>> and
> >>>>>>>>>> feedback.
> >>>>>>>>>>>>>> Please
> >>>>>>>>>>>>>>>> see
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> replies
> >>>>>>>>>>>>>>>>>>>>>>>>>> below:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
> >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> >>>>> Change"
> >>>>>> we
> >>>>>>>>> could
> >>>>>>>>>>>>> also
> >>>>>>>>>>>>>>> add a
> >>>>>>>>>>>>>>>>> row
> >>>>>>>>>>>>>>>>>>>> for "Code
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> >>>>>> reference
> >>>>>>> to
> >>>>>>>>> the
> >>>>>>>>>>>>> FLIP
> >>>>>>>>>>>>>>>> process
> >>>>>>>>>>>>>>>>>>>> page. A
> >>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> >>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
> >>>>> for
> >>>>>>>>>> approvals,
> >>>>>>>>>>>>> etc.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------
> >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> >>>>> currently
> >>>>>>>>> requires
> >>>>>>>>>>>>> "one
> >>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>> from a
> >>>>>>>>>>>>>>>>>>>> committer
> >>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> >>>>> followed
> >>>>>>> by a
> >>>>>>>>>> Lazy
> >>>>>>>>>>>>>>> approval
> >>>>>>>>>>>>>>>>> (not
> >>>>>>>>>>>>>>>>>>>> counting
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
> >>>>> to
> >>>>>>> lazy
> >>>>>>>>>>>>> majority
> >>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> -1
> >>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>> received".
> >>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
> >>>>>>>>> committer
> >>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>> needs a
> >>>>>>>>>>>>>>>>>>>> review
> >>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
> >>>>>>> know
> >>>>>>>>> this
> >>>>>>>>>>> is
> >>>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> >>>>>>>> contributor
> >>>>>>>>>>>>> reviews
> >>>>>>>>>>>>>> &
> >>>>>>>>>>>>>>>>> +1s).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
> >>>>> we
> >>>>>>> can
> >>>>>>>>>> make
> >>>>>>>>>>> it
> >>>>>>>>>>>>>> easy
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> follow the
> >>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> >>>>>> Flink-specific
> >>>>>>>> Jira
> >>>>>>>>>>>>>> workflows
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> ticket
> >>>>>>>>>>>>>>>>>>>>>>>>>> types +
> >>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
> >>>>> is
> >>>>>>>>>> certainly
> >>>>>>>>>>>>>> "Step
> >>>>>>>>>>>>>>>> 2",
> >>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>> believe,
> >>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> >>>>>>> transparent
> >>>>>>>>> as
> >>>>>>>>>>>>>> possible,
> >>>>>>>>>>>>>>>>>>>> otherwise they
> >>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> >>>>>>>>>>>>>>>>>>>>>>>>>> & Re: Till
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> >>>>>>> author
> >>>>>>>>> and
> >>>>>>>>>>>>>> getting
> >>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> >>>>>> should
> >>>>>>>> know
> >>>>>>>>>>> when
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> ask
> >>>>>>>>>>>>>>>>>>> another
> >>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
> >>>>> I
> >>>>>>>> would
> >>>>>>>>>> not
> >>>>>>>>>>>>>> enforce
> >>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> >>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> >>>>> author
> >>>>>>> is
> >>>>>>>> a
> >>>>>>>>>>>>> committer
> >>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>> course
> >>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> >>>>>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
> >>>>> here.
> >>>>>>>> TBH,
> >>>>>>>>> in
> >>>>>>>>>>>>> Kafka
> >>>>>>>>>>>>>>>>>>> occasionally
> >>>>>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
> >>>>> still
> >>>>>>>>> merged
> >>>>>>>>>>>>> without
> >>>>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
> >>>>> rare.
> >>>>>>>> That
> >>>>>>>>>>> said,
> >>>>>>>>>>>>> I
> >>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
> >>>>> sense
> >>>>>>> due
> >>>>>>>>> to
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>>>>> reasons:
> >>>>>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
> >>>>>> to
> >>>>>>>> make
> >>>>>>>>>>> sure
> >>>>>>>>>>>>>> every
> >>>>>>>>>>>>>>>>> patch
> >>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
> >>>>>>>> little
> >>>>>>>>>>>>> difficult
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> guarantee if
> >>>>>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
> >>>>>>> many
> >>>>>>>>>>>>> reasons. In
> >>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>> cases, a
> >>>>>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
> >>>>> knowledge
> >>>>>>>> about
> >>>>>>>>>> the
> >>>>>>>>>>>>>>> project
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> make
> >>>>>>>>>>>>>>>>>>>> a good
> >>>>>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
> >>>>>> contributors
> >>>>>>>> are
> >>>>>>>>>> more
> >>>>>>>>>>>>>>> eagerly
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> get a
> >>>>>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
> >>>>>> willing
> >>>>>>>> to
> >>>>>>>>>>> lower
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> review
> >>>>>>>>>>>>>>>>>>> bar.
> >>>>>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
> >>>>>> among
> >>>>>>>>>>>>> committers,
> >>>>>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>> personally
> >>>>>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
> >>>>>>> form
> >>>>>>>>>>>>> consistent
> >>>>>>>>>>>>>>>> design
> >>>>>>>>>>>>>>>>>>>> principles
> >>>>>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
> >>>>>>>> committers
> >>>>>>>>>> will
> >>>>>>>>>>>>> know
> >>>>>>>>>>>>>>> how
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
> >>>>>> from
> >>>>>>>> each
> >>>>>>>>>>>>> other.
> >>>>>>>>>>>>>> So
> >>>>>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>>>> tend
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
> >>>>>>> things
> >>>>>>>>>> should
> >>>>>>>>>>>>> be
> >>>>>>>>>>>>>>> done
> >>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>> general.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
> >>>>>>>> consider
> >>>>>>>>>> the
> >>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>> two
> >>>>>>>>>>>>>>>>>>>> scenarios:
> >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
> >>>>> a
> >>>>>>> lot
> >>>>>>>> of
> >>>>>>>>>>>>>>> iterations.
> >>>>>>>>>>>>>>>>> Then
> >>>>>>>>>>>>>>>>>>>> the patch
> >>>>>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
> >>>>>> time
> >>>>>>>>>> because
> >>>>>>>>>>>>> there
> >>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>>> things
> >>>>>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
> >>>>> changed.
> >>>>>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
> >>>>> very
> >>>>>>>> smooth
> >>>>>>>>>> and
> >>>>>>>>>>>>>> quick,
> >>>>>>>>>>>>>>>> so
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> patch is
> >>>>>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
> >>>>> patch
> >>>>>>> does
> >>>>>>>>> not
> >>>>>>>>>>>>> take
> >>>>>>>>>>>>>>> much
> >>>>>>>>>>>>>>>>>> time.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
> >>>>>> patch
> >>>>>>>>> from a
> >>>>>>>>>>>>>>> committer
> >>>>>>>>>>>>>>>>>> falls
> >>>>>>>>>>>>>>>>>>>> either in
> >>>>>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
> >>>>> is
> >>>>>>> to
> >>>>>>>>>> review
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> patch
> >>>>>>>>>>>>>>>>>>>> because
> >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
> >>>>> needs
> >>>>>>> to
> >>>>>>>> be
> >>>>>>>>>>>>>> reviewed.
> >>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
> >>>>>> take
> >>>>>>>>> much
> >>>>>>>>>>> time
> >>>>>>>>>>>>>>>> anyways.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
> >>>>>>> case
> >>>>>>>> 1
> >>>>>>>>> if
> >>>>>>>>>>> we
> >>>>>>>>>>>>>> skip
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> cross-review.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------
> >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Robert
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
> >>>>>> and
> >>>>>>>> made
> >>>>>>>>>> the
> >>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>>>>> modifications
> >>>>>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
> >>>>>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
> >>>>> section.
> >>>>>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
> >>>>>> to
> >>>>>>>>>>>>> "consensus"
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> align
> >>>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
> >>>>> and
> >>>>>>>> other
> >>>>>>>>>>>>>> projects.
> >>>>>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------
> >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> >>>>> unnecessary
> >>>>>>>>> noise.
> >>>>>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
> >>>>>> 2/3
> >>>>>>>>>>> majority
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>>>>> feasible in
> >>>>>>>>>>>>>>>>>>>>>>>>>> practice.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> >>>>> the
> >>>>>>>> draft
> >>>>>>>>>>>>> compared
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> existing
> >>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
> >>>>>>>>> highlight
> >>>>>>>>>>>>> these
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> >>>>>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
> >>>>>>> familiar
> >>>>>>>>>> enough
> >>>>>>>>>>>>> with
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> current Flink
> >>>>>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
> >>>>> saw
> >>>>>>> you
> >>>>>>>>>>>>> commented
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>> part
> >>>>>>>>>>>>>>>>>>>> in the
> >>>>>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------
> >>>>>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> >>>>>>> bylaws?
> >>>>>>>>> I’m
> >>>>>>>>>>>>> asking
> >>>>>>>>>>>>>>>>> because
> >>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> >>>>> essentially
> >>>>>>>>> adopting
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>> Kafka
> >>>>>>>>>>>>>>>>>>> bylaws.
> >>>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> >>>>>> try
> >>>>>>>> to
> >>>>>>>>>>>>> re-invent
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> wheel
> >>>>>>>>>>>>>>>>>>>> here.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
> >>>>> version
> >>>>>>> of
> >>>>>>>>> the
> >>>>>>>>>>>>> draft
> >>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>>>>> almost
> >>>>>>>>>>>>>>>>>>>> identical
> >>>>>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
> >>>>> caught a
> >>>>>>> few
> >>>>>>>>>>>>>> inconsistent
> >>>>>>>>>>>>>>>>>> places.
> >>>>>>>>>>>>>>>>>>>> So it
> >>>>>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
> >>>>>> make
> >>>>>>>> sure
> >>>>>>>>>> we
> >>>>>>>>>>>>> truly
> >>>>>>>>>>>>>>>> agree
> >>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
> >>>>>>>> shortly
> >>>>>>>>>>> after
> >>>>>>>>>>>>>>>> adoption.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
> >>>>> valuable
> >>>>>>>>>> feedback.
> >>>>>>>>>>>>> These
> >>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>> great
> >>>>>>>>>>>>>>>>>>>>>>>>>> discussion.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
> >>>>> Aljoscha
> >>>>>>>>> Krettek
> >>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>> aljoscha@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Big +1
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> >>>>>>> bylaws?
> >>>>>>>>> I’m
> >>>>>>>>>>>>> asking
> >>>>>>>>>>>>>>>>>> because I
> >>>>>>>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> >>>>> essentially
> >>>>>>>>> adopting
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>> Kafka
> >>>>>>>>>>>>>>>>>>> bylaws.
> >>>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>>>> mean,
> >>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> >>>>>> try
> >>>>>>>> to
> >>>>>>>>>>>>> re-invent
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> wheel
> >>>>>>>>>>>>>>>>>>>> here.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
> >>>>>>>>>> “committer
> >>>>>>>>>>>>> +1”
> >>>>>>>>>>>>>>>>>>> requirement.
> >>>>>>>>>>>>>>>>>>>> We
> >>>>>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
> >>>>> would
> >>>>>>>>> actually
> >>>>>>>>>>> be
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> favour
> >>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>>>>> requiring
> >>>>>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
> >>>>>>>>>> complicated.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
> >>>>>> Rohrmann
> >>>>>>> <
> >>>>>>>>>>>>>>>>>> trohrmann@apache.org>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
> >>>>>>>> Becket.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
> >>>>> emeritus
> >>>>>>> (or
> >>>>>>>>>> active
> >>>>>>>>>>>>> vs.
> >>>>>>>>>>>>>>>>>> inactive),
> >>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>> won't
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
> >>>>> vote
> >>>>>>>>> because
> >>>>>>>>>>> we
> >>>>>>>>>>>>>>> already
> >>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>> too
> >>>>>>>>>>>>>>>>>>>>>>>>>> many
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> >>>>>>>> author
> >>>>>>>>>> and
> >>>>>>>>>>>>>>> getting a
> >>>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>>>>> from a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> >>>>>> should
> >>>>>>>>> know
> >>>>>>>>>>>>> when to
> >>>>>>>>>>>>>>> ask
> >>>>>>>>>>>>>>>>>>> another
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
> >>>>> Hence, I
> >>>>>>>> would
> >>>>>>>>>> not
> >>>>>>>>>>>>>>> enforce
> >>>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> >>>>>> author
> >>>>>>>> is a
> >>>>>>>>>>>>>> committer
> >>>>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>> course
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Till
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
> >>>>> Chesnay
> >>>>>>>>>> Schepler
> >>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>> chesnay@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> >>>>>>> unnecessary
> >>>>>>>>>> noise.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> >>>>>> the
> >>>>>>>>> draft
> >>>>>>>>>>>>>> compared
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> existing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
> >>>>> to
> >>>>>>>>>> highlight
> >>>>>>>>>>>>>> these
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
> >>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
> >>>>> this
> >>>>>>>>>>> discussion
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>> creating
> >>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>> draft
> >>>>>>>>>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> >>>>> that
> >>>>>> a
> >>>>>>>>>>> committer
> >>>>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>>> needs
> >>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>> review
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> >>>>>> as I
> >>>>>>>>> know
> >>>>>>>>>>>>> this is
> >>>>>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> >>>>>>>>>> contributor
> >>>>>>>>>>>>>>> reviews
> >>>>>>>>>>>>>>>> &
> >>>>>>>>>>>>>>>>>>> +1s).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
> >>>>> if
> >>>>>>> we
> >>>>>>>>> had
> >>>>>>>>>>>>> cases
> >>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> past
> >>>>>>>>>>>>>>>>>>>> where
> >>>>>>>>>>>>>>>>>>>>>>>>>>> code
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
> >>>>> we
> >>>>>>>>> believe
> >>>>>>>>>>>>> that we
> >>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>> enough
> >>>>>>>>>>>>>>>>>>>>>>>>>>> capacity
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
> >>>>>>>> approval.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> >>>>>>>> Konstantin
> >>>>>>>>>>> Knauf
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
> >>>>>>> Becket. I
> >>>>>>>>>> have
> >>>>>>>>>>>>> two
> >>>>>>>>>>>>>>>> remarks
> >>>>>>>>>>>>>>>>>>>> regarding
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> >>>>>>> Change"
> >>>>>>>> we
> >>>>>>>>>>> could
> >>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>>> add a
> >>>>>>>>>>>>>>>>>>>> row for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Code
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> >>>>>>>> reference
> >>>>>>>>> to
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> FLIP
> >>>>>>>>>>>>>>>>>> process
> >>>>>>>>>>>>>>>>>>>> page.
> >>>>>>>>>>>>>>>>>>>>>>>>>> A
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
> >>>>> rules
> >>>>>>> for
> >>>>>>>>>>>>> approvals,
> >>>>>>>>>>>>>>> etc.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> >>>>>>> currently
> >>>>>>>>>>> requires
> >>>>>>>>>>>>>> "one
> >>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>>>> from a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> >>>>>>> followed
> >>>>>>>>> by a
> >>>>>>>>>>>>> Lazy
> >>>>>>>>>>>>>>>>> approval
> >>>>>>>>>>>>>>>>>>> (not
> >>>>>>>>>>>>>>>>>>>>>>>>>>> counting
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
> >>>>> moving
> >>>>>>> to
> >>>>>>>>> lazy
> >>>>>>>>>>>>>> majority
> >>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> -1
> >>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> received".
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> >>>>>> that a
> >>>>>>>>>>> committer
> >>>>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>>>> needs a
> >>>>>>>>>>>>>>>>>>>>>>>>>> review
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> >>>>>> as I
> >>>>>>>>> know
> >>>>>>>>>>>>> this is
> >>>>>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> >>>>>>>>>> contributor
> >>>>>>>>>>>>>>> reviews
> >>>>>>>>>>>>>>>> &
> >>>>>>>>>>>>>>>>>>> +1s).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
> >>>>>> how
> >>>>>>>> we
> >>>>>>>>>> can
> >>>>>>>>>>>>> make
> >>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>> easy
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> follow
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> >>>>>>>> Flink-specific
> >>>>>>>>>> Jira
> >>>>>>>>>>>>>>>> workflows
> >>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> ticket
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> types +
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
> >>>>>> this
> >>>>>>> is
> >>>>>>>>>>>>> certainly
> >>>>>>>>>>>>>>>> "Step
> >>>>>>>>>>>>>>>>>> 2",
> >>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>>>>> believe,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> >>>>>>>>> transparent
> >>>>>>>>>>> as
> >>>>>>>>>>>>>>>> possible,
> >>>>>>>>>>>>>>>>>>>> otherwise
> >>>>>>>>>>>>>>>>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
> >>>>>> Becket
> >>>>>>>>> Qin <
> >>>>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
> >>>>>> process
> >>>>>>>>>>> discussion
> >>>>>>>>>>>>>>> thread
> >>>>>>>>>>>>>>>>>> [1],
> >>>>>>>>>>>>>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
> >>>>>>> govern
> >>>>>>>>> the
> >>>>>>>>>>>>>>> operation
> >>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> project.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
> >>>>>> community
> >>>>>>>> to
> >>>>>>>>>>>>>> coordinate
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> contribute
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
> >>>>>>> other
> >>>>>>>>>>>>> processes
> >>>>>>>>>>>>>>> such
> >>>>>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>>>>> FLIP.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
> >>>>> page
> >>>>>>> and
> >>>>>>>>>> would
> >>>>>>>>>>>>> like
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> start a
> >>>>>>>>>>>>>>>>>>>>>>>>>>> discussion
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
> >>>>> in
> >>>>>>> the
> >>>>>>>>>>>>> community.
> >>>>>>>>>>>>>>>> It'll
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>> great to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> hear
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
> >>>>>> Architect
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
> >>>>>>>> 31.08.2019,
> >>>>>>>>>>>>> 05.09. -
> >>>>>>>>>>>>>>>>>>> 06.09.2010
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
> >>>>>> 115,
> >>>>>>>>> 10115
> >>>>>>>>>>>>>> Berlin,
> >>>>>>>>>>>>>>>>>> Germany
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
> >>>>>>>> Charlottenburg:
> >>>>>>>>>> HRB
> >>>>>>>>>>>>>> 158244
> >>>>>>>>>>>>>>> B
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
> >>>>>>> Tzoumas,
> >>>>>>>>> Dr.
> >>>>>>>>>>>>> Stephan
> >>>>>>>>>>>>>>>> Ewen
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>

Re: [DISCUSS] Flink project bylaws

[Maximilian Michels <mx...@apache.org>]

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 <be...@gmail.com> wrote:
> 
>> Hi Maximillian,
>>
>> Thanks for the feedback. Please see the reply below:
>>
>> Step 2 should include a personal email to the PMC members in question.
>>
>> I'm afraid reminders inside the vote thread could be overlooked easily.
>>
>>
>> This is exactly what I meant to say by "reach out" :) I just made it more
>> explicit.
>>
>> The way the terms are described in the draft, the consensus is "lazy",
>>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy
>>> Consensus". This is in line with the other definitions such as "Lazy
>>> Majority".
>>
>> It was initially called "lazy consensus", but Robert pointed out that
>> "lazy consensus" actually means something different in ASF term [1].
>> Here "lazy" pretty much means "assume everyone is +1 unless someone says
>> otherwise". This means any vote that requires a minimum number of +1 is not
>> really a "lazy" vote.
>>
>> Removing a committer / PMC member only requires 3 binding votes. I'd
>>> expect an important action like this to require a 2/3 majority.
>>
>> Personally I think consensus is good enough here. PMC members can cast a
>> veto if they disagree about the removal. In some sense, it is more
>> difficult than with 2/3 majority to remove a committer / PMC member. Also,
>> it might be a hard decision for some PMC members if they have never worked
>> with the person in question. That said, I am OK to change it to 2/3
>> majority as this will happen very rarely.
>>
>> Thanks,
>>
>> Jiangjie (Becket) Qin
>>
>> [1] https://www.apache.org/foundation/voting.html#LazyConsensus
>>
>> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <mx...@apache.org> wrote:
>>
>>> I'm a bit late to the discussion here. Three suggestions:
>>>
>>> 1) Procedure for "insufficient active binding voters to reach 2/3 majority
>>>
>>>>     1. Wait until the minimum length of the voting passes.
>>>>     2. Publicly reach out to the remaining binding voters in the voting
>>> mail thread for at least 2 attempts with at least 7 days between two
>>> attempts.
>>>>     3. If the binding voter being contacted still failed to respond
>>> after all the attempts, the binding voter will be considered as inactive
>>> for the purpose of this particular voting.
>>>
>>> Step 2 should include a personal email to the PMC members in question.
>>> I'm afraid reminders inside the vote thread could be overlooked easily.
>>>
>>> 2) "Consensus" => "Lazy Consensus"
>>>
>>> The way the terms are described in the draft, the consensus is "lazy",
>>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy
>>> Consensus". This is in line with the other definitions such as "Lazy
>>> Majority".
>>>
>>> 3) Committer / PMC Removal
>>>
>>> Removing a committer / PMC member only requires 3 binding votes. I'd
>>> expect an important action like this to require a 2/3 majority.
>>>
>>>
>>> Do you think we could incorporate those suggestions?
>>>
>>> Thanks,
>>> Max
>>>
>>> On 11.08.19 10:14, Becket Qin wrote:
>>>> Hi folks,
>>>>
>>>> Thanks for all the discussion and support. I have started the voting
>>> thread.
>>>>
>>>>
>>> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
>>>>
>>>> Thanks,
>>>>
>>>> Jiangjie (Becket) Qin
>>>>
>>>> On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <fh...@gmail.com> wrote:
>>>>
>>>>> Thanks for the update and driving the discussion Becket!
>>>>> +1 for starting a vote.
>>>>>
>>>>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
>>> becket.qin@gmail.com
>>>>>> :
>>>>>
>>>>>> Thanks Stephan.
>>>>>>
>>>>>> I think we have resolved all the comments on the wiki page. There are
>>> two
>>>>>> minor changes made to the bylaws since last week.
>>>>>> 1. For 2/3 majority, the required attempts to reach out to binding
>>> voters
>>>>>> is reduced from 3 to 2. This helps shorten the voting process a little
>>>>> bit.
>>>>>> 2. Clarified what is considered as the adoption of new codebase.
>>>>>>
>>>>>> I think we almost reached consensus. I'll start a voting thread in two
>>>>> days
>>>>>> if there is no new concerns.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jiangjie (Becket) Qin
>>>>>>
>>>>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org> wrote:
>>>>>>
>>>>>>> I added a clarification to the table, clarifying that the current
>>>>>> phrasing
>>>>>>> means that committers do not need another +1 for their commits.
>>>>>>>
>>>>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fh...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Becket,
>>>>>>>>
>>>>>>>> Thanks a lot for pushing this forward and addressing the feedback.
>>>>>>>> I'm very happy with the current state of the bylaws.
>>>>>>>> +1 to wait until Friday before starting a vote.
>>>>>>>>
>>>>>>>> Best, Fabian
>>>>>>>>
>>>>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
>>>>>>>> becket.qin@gmail.com
>>>>>>>>> :
>>>>>>>>
>>>>>>>>> Hi Everyone,
>>>>>>>>>
>>>>>>>>> Thanks for all the discussion and feedback.
>>>>>>>>>
>>>>>>>>> It seems that we have almost reached consensus. I'll leave the
>>>>>>> discussion
>>>>>>>>> thread open until this Friday. If there is no more concerns raised,
>>>>>>> I'll
>>>>>>>>> start a voting thread after that.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>
>>>>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Becket,
>>>>>>>>>>
>>>>>>>>>> Thanks for noticing and resolving my comment around PMC removal
>>>>> and
>>>>>>> ASF
>>>>>>>>>> rules of PMC membership change process, which you seem to neglect
>>>>>> in
>>>>>>>> the
>>>>>>>>>> summary of updates (smile).
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Yu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <be...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi folks,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for all the feedback.
>>>>>>>>>>>
>>>>>>>>>>> It seems that there are a few concerns over the emeritus status
>>>>>>>> after 6
>>>>>>>>>>> months of inactivity. Given that the main purpose is just to
>>>>> make
>>>>>>>> sure
>>>>>>>>>> 2/3
>>>>>>>>>>> majority can pass and we sort of have a solution for that, I
>>>>> just
>>>>>>>>> updated
>>>>>>>>>>> the draft with the following changes:
>>>>>>>>>>>
>>>>>>>>>>> 1. Removed the inactivity term for emeritus committers / PMCs.
>>>>> A
>>>>>>>>>> committer
>>>>>>>>>>> / PMC will only be considered emeritus by their own claim.
>>>>>>>>>>> 2. Removed the approval process for reinstatement of the
>>>>> emeritus
>>>>>>>>>>> committers / PMCs. An emeritus committer / PMC will be
>>>>> reinstated
>>>>>>>> when
>>>>>>>>>> they
>>>>>>>>>>> send an email to the private@flink.apache.org.
>>>>>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still doable
>>>>>> when
>>>>>>>>> there
>>>>>>>>>>> are non-emeritus committers / PMCs who do not cast the vote.
>>>>>>>>>>>
>>>>>>>>>>> Please let me know if you have any further thoughts.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
>>>>>> becket.qin@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Fabian,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the feedback.
>>>>>>>>>>>>
>>>>>>>>>>>> I agree that if we don't like emeritus committers / PMCs, we
>>>>>>> don't
>>>>>>>>> have
>>>>>>>>>>> to
>>>>>>>>>>>> do it. That said, emeritus status simply means whether an
>>>>>>>> individual
>>>>>>>>> is
>>>>>>>>>>>> active / inactive in the community. It does not make the
>>>>> merits
>>>>>>>>> earned
>>>>>>>>>> to
>>>>>>>>>>>> go away. For our purpose, emeritus status is mostly just a
>>>>> way
>>>>>> to
>>>>>>>>> make
>>>>>>>>>>> 2/3
>>>>>>>>>>>> majority possible. As you noticed, since reaching out to
>>>>>> binding
>>>>>>>>> voters
>>>>>>>>>>> who
>>>>>>>>>>>> have not voted can achieve the same goal, the emeritus status
>>>>>> is
>>>>>>>> more
>>>>>>>>>> of
>>>>>>>>>>> an
>>>>>>>>>>>> optimization so we don't have to ping the inactive binding
>>>>>> voters
>>>>>>>>> every
>>>>>>>>>>>> time and wait for long. However, given that 2/3 majority
>>>>>> votings
>>>>>>>> are
>>>>>>>>>>> rare,
>>>>>>>>>>>> such communication cost is probably OK. So I think we can
>>>>>> remove
>>>>>>>> that
>>>>>>>>>>>> emeritus part from the bylaws.
>>>>>>>>>>>>
>>>>>>>>>>>> 1) We should add to the requirements of the PMC that they
>>>>> need
>>>>>> to
>>>>>>>>> make
>>>>>>>>>>>>> sure the project complies with brand issues and reports
>>>>> misuse
>>>>>>> of
>>>>>>>>> ASF
>>>>>>>>>>>>> brands.
>>>>>>>>>>>>
>>>>>>>>>>>> Good point. Added.
>>>>>>>>>>>>
>>>>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
>>>>> a
>>>>>> 3
>>>>>>>> day
>>>>>>>>>> vote
>>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
>>>>>>>>>>>>
>>>>>>>>>>>> This might be a little tricky because people are from
>>>>> countries
>>>>>>> in
>>>>>>>>>>>> different time zones and with different holidays, and so on.
>>>>> If
>>>>>>> we
>>>>>>>>> are
>>>>>>>>>>>> worrying about 3 days minimum length is not enough for those
>>>>>> who
>>>>>>>> want
>>>>>>>>>> to
>>>>>>>>>>>> give feedback, we can make it 5 days.
>>>>>>>>>>>>
>>>>>>>>>>>> 3) Do we need a process do decide about removal of features
>>>>>> (like
>>>>>>>> the
>>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
>>>>>> Python
>>>>>>>>>> APIs)?
>>>>>>>>>>>>
>>>>>>>>>>>> I assume such action should be covered by FLIP as it is a
>>>>>> change
>>>>>>> to
>>>>>>>>> the
>>>>>>>>>>>> API and probably needs a migration plan. It would be useful
>>>>> to
>>>>>>>> have a
>>>>>>>>>>>> formal deprecation procedure. But that might be better to be
>>>>>> put
>>>>>>>> into
>>>>>>>>>>>> somewhere else because the bylaws are primarily focusing on
>>>>> the
>>>>>>>>>>>> non-technical rules, whereas the deprecation seems more on
>>>>> the
>>>>>>>>>> technical
>>>>>>>>>>>> side.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
>>>>>>> fhueske@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> First of all thank you very much Becket for starting this
>>>>>>>>> discussion!
>>>>>>>>>>>>> I think it is a very good idea and overdue to formally
>>>>> define
>>>>>>> some
>>>>>>>>> of
>>>>>>>>>>> our
>>>>>>>>>>>>> community processes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Similar to Chesnay, I have concerns about the distinction
>>>>>>> between
>>>>>>>>>> active
>>>>>>>>>>>>> and non-active / emeritus committers and PMC members.
>>>>>>>>>>>>> My foremost concern is that this is not in the spirit of the
>>>>>>>> Apache
>>>>>>>>>> Way
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> which is (among other things) based on the idea of merit
>>>>> which
>>>>>>>> once
>>>>>>>>>>>>> earned,
>>>>>>>>>>>>> does not go away over time.
>>>>>>>>>>>>> I know other projects like Hadoop and Kafka have similar
>>>>>> clauses
>>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>>>>> bylaws but IMO we don't need to adopt them if we don't like
>>>>>>> them.
>>>>>>>>>>>>> For example, I don't like the idea that committers or PMC
>>>>>>> members
>>>>>>>>> who
>>>>>>>>>>> are
>>>>>>>>>>>>> temporarily away from the project (for whatever reason:
>>>>>> parental
>>>>>>>>>> leave,
>>>>>>>>>>>>> sabbatical, health issues, etc.) need the PMC approval to be
>>>>>>>>> "active"
>>>>>>>>>>>>> again.
>>>>>>>>>>>>> As far as I am aware, we have not seen any issues with
>>>>>> inactive
>>>>>>>>>> members
>>>>>>>>>>> in
>>>>>>>>>>>>> the past.
>>>>>>>>>>>>> Moreover, it would be hard to track whether somebody became
>>>>>>>> inactive
>>>>>>>>>> at
>>>>>>>>>>>>> some point in time (which we would need to do, if I
>>>>> understand
>>>>>>> the
>>>>>>>>>>>>> proposal
>>>>>>>>>>>>> correctly).
>>>>>>>>>>>>> With the approach that Becket suggested in his last email
>>>>>>>> (reaching
>>>>>>>>>> out
>>>>>>>>>>> to
>>>>>>>>>>>>> binding voters who haven't voted yet), we could drop the
>>>>>>>> distinction
>>>>>>>>>>>>> between active and non-active committers and PMC members.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I also have a few minor comments:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) We should add to the requirements of the PMC [2] that
>>>>> they
>>>>>>> need
>>>>>>>>> to
>>>>>>>>>>> make
>>>>>>>>>>>>> sure the project complies with brand issues and reports
>>>>> misuse
>>>>>>> of
>>>>>>>>> ASF
>>>>>>>>>>>>> brands.
>>>>>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
>>>>>> a 3
>>>>>>>> day
>>>>>>>>>>> vote
>>>>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
>>>>>>>>>>>>> 3) Do we need a process do decide about removal of features
>>>>>>> (like
>>>>>>>>> the
>>>>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
>>>>>> Python
>>>>>>>>>> APIs)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>> Fabian
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://www.apache.org/theapacheway/
>>>>>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
>>>>>>>>>>>>> becket.qin@gmail.com
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Hequn,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see the reply
>>>>>> below:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one PMC
>>>>> in
>>>>>>>> the 3
>>>>>>>>>>>>> binding
>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
>>>>> and 1
>>>>>>>> PMC.
>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
>>>>> somehow
>>>>>>> be a
>>>>>>>>> big
>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
>>>>> loss
>>>>>>> of
>>>>>>>>>>>>> flexibility
>>>>>>>>>>>>>>> as committers also have a chance to vote and participate
>>>>>> in
>>>>>>>> it.
>>>>>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs are
>>>>> the
>>>>>>>>>> following:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Generally speaking, the PMC's primary responsibility is
>>>>>>>>> operating
>>>>>>>>>>> the
>>>>>>>>>>>>>> project and deciding what software to release on behalf of
>>>>>>> ASF.
>>>>>>>>>>>>> Committers,
>>>>>>>>>>>>>> on the other hand, are responsible for the technical part
>>>>> of
>>>>>>> the
>>>>>>>>>>>>> project.
>>>>>>>>>>>>>> So for FLIPs, a PMC's vote probably should not outweigh a
>>>>>>>>>> committer's
>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is really
>>>>>>>>> convincing
>>>>>>>>>>>>> enough
>>>>>>>>>>>>>> to decide whether the FLIP is good to go or not. Also, if
>>>>>> some
>>>>>>>>>>>>> committers
>>>>>>>>>>>>>> have concern over a FLIP, they could just veto it. To me
>>>>> it
>>>>>> is
>>>>>>>>>>> actually
>>>>>>>>>>>>> a
>>>>>>>>>>>>>> more strict requirement to pass a FLIP than asking a PMC
>>>>> to
>>>>>>>> vote.
>>>>>>>>> In
>>>>>>>>>>>>>> practice, people will usually also address the concerns
>>>>> even
>>>>>>> if
>>>>>>>>> they
>>>>>>>>>>> are
>>>>>>>>>>>>>> not from a PMC/committer before they start the voting
>>>>>> process.
>>>>>>>> So
>>>>>>>>> I
>>>>>>>>>>>>> don't
>>>>>>>>>>>>>> see much benefit of requiring a PMC's vote in this case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the votes
>>>>> no
>>>>>>>> longer
>>>>>>>>>>>>>> independent. Ideally, a vote is either binding or
>>>>>> non-binding
>>>>>>> by
>>>>>>>>>>>>> itself. If
>>>>>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
>>>>> imagine
>>>>>>>> there
>>>>>>>>>> have
>>>>>>>>>>>>> been
>>>>>>>>>>>>>> 3 committers who voted +1. But the FLIP still has not
>>>>>> passed,
>>>>>>> so
>>>>>>>>>> those
>>>>>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a +1,
>>>>>> those
>>>>>>>>> votes
>>>>>>>>>>>>>> suddenly become binding, which is a little awkward.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable to me.
>>>>>> Some
>>>>>>>>>>> thoughts
>>>>>>>>>>>>> on
>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is probably
>>>>>>> because
>>>>>>>>>> there
>>>>>>>>>>>>> are
>>>>>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3 majority
>>>>>>>>>>> prohibitively
>>>>>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
>>>>> Flink[2]
>>>>>>> and
>>>>>>>> a
>>>>>>>>>>> quick
>>>>>>>>>>>>>> search shows at most 6 of them have not sent email in the
>>>>>>>> recent 6
>>>>>>>>>>>>> months
>>>>>>>>>>>>>> or so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare. It is
>>>>>>>> designed
>>>>>>>>>> in
>>>>>>>>>>>>>> particular for the cases that broad opinions are
>>>>> important,
>>>>>>> more
>>>>>>>>>>>>>> specifically new codebase adoption or modification to the
>>>>>>>> bylaws.
>>>>>>>>>>>>> Therefore
>>>>>>>>>>>>>> such vote by its nature favors consensus over convenience.
>>>>>>> That
>>>>>>>>>> means
>>>>>>>>>>>>> any
>>>>>>>>>>>>>> alternative voting type reducing the coverage worth a
>>>>>> careful
>>>>>>>>>>> thinking.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. I do agree that it does not make sense to have 2/3
>>>>>> majority
>>>>>>>> if
>>>>>>>>>> such
>>>>>>>>>>>>>> requirement is no-longer doable over time. But I am a
>>>>> little
>>>>>>>>>> hesitant
>>>>>>>>>>> to
>>>>>>>>>>>>>> lower the threshold to lazy 2/3 majority in our case. What
>>>>>> do
>>>>>>>> you
>>>>>>>>>>> think
>>>>>>>>>>>>>> about doing the following:
>>>>>>>>>>>>>>     - After the voting started, there will be at least 6
>>>>>> days
>>>>>>>> for
>>>>>>>>>>>>> people to
>>>>>>>>>>>>>> cast their votes.
>>>>>>>>>>>>>>     - After 6 days, if the result of the vote is still not
>>>>>>>>>> determined,
>>>>>>>>>>>>> the
>>>>>>>>>>>>>> person who started the vote should reach out to the
>>>>> binding
>>>>>>>> voters
>>>>>>>>>> who
>>>>>>>>>>>>> have
>>>>>>>>>>>>>> not voted yet for at least 3 times and at least 7 days
>>>>>> between
>>>>>>>>> each
>>>>>>>>>>>>> time.
>>>>>>>>>>>>>> If a binding voter still did not respond, the vote from
>>>>> that
>>>>>>>> voter
>>>>>>>>>>> will
>>>>>>>>>>>>> be
>>>>>>>>>>>>>> excluded from the 2/3 majority counting.
>>>>>>>>>>>>>> This would ensure the coverage at our best effort while
>>>>>> still
>>>>>>>> let
>>>>>>>>>> the
>>>>>>>>>>>>> 2/3
>>>>>>>>>>>>>> majority vote make progress.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] https://projects.apache.org/committee.html?hadoop
>>>>>>>>>>>>>> [2] https://projects.apache.org/committee.html?flink
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
>>>>>>>>> forwardxu315@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Big +1 on this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> forward
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
>>>>>> 下午1:30写道：
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Becket,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Big +1 on this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
>>>>>>> includes a
>>>>>>>>> PMC
>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
>>>>> PMC
>>>>>> in
>>>>>>>>> the 3
>>>>>>>>>>>>>> binding
>>>>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
>>>>>> and 1
>>>>>>>>> PMC.
>>>>>>>>>>>>>>>> I think this makes sense considering a FLIP could
>>>>>> somehow
>>>>>>>> be a
>>>>>>>>>> big
>>>>>>>>>>>>>>> feature
>>>>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
>>>>>> loss
>>>>>>>> of
>>>>>>>>>>>>>> flexibility
>>>>>>>>>>>>>>>> as committers also have a chance to vote and
>>>>> participate
>>>>>>> in
>>>>>>>>> it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ========Seperator========
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For the nice bylaws, I agree with the general idea and
>>>>>>> most
>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>>>>>>> content.
>>>>>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority". The
>>>>>>> main
>>>>>>>>>>> concern
>>>>>>>>>>>>> is
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> am
>>>>>>>>>>>>>>>> not sure if it is doable in practice. The reasons are:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
>>>>>> committer
>>>>>>>> or a
>>>>>>>>>> PMC
>>>>>>>>>>>>>> member
>>>>>>>>>>>>>>>> is active if he or she sends one email to the mailing
>>>>>> list
>>>>>>>>>> every 6
>>>>>>>>>>>>>>> months.
>>>>>>>>>>>>>>>> While the minimum length of the vote is only 6 days.
>>>>>> There
>>>>>>>> are
>>>>>>>>>>>>> chances
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> during the vote, some of the active members are still
>>>>>>>> offline
>>>>>>>>> of
>>>>>>>>>>> the
>>>>>>>>>>>>>>>> community.
>>>>>>>>>>>>>>>> 2. The code of Flink is changing fast and not everyone
>>>>>>> fully
>>>>>>>>>>>>>> understands
>>>>>>>>>>>>>>>> every part. We don't need to force people to vote if
>>>>>> they
>>>>>>>> are
>>>>>>>>>> not
>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>> about it. It may also make the final result less
>>>>>> credible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Given the above reasons, perhaps we can change the 2/3
>>>>>>>>> Majority
>>>>>>>>>> to
>>>>>>>>>>>>> lazy
>>>>>>>>>>>>>>> 2/3
>>>>>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
>>>>>> higher
>>>>>>>>>>> threshold,
>>>>>>>>>>>>>>>> however, more practical.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
>>>>>>>>>> becket.qin@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Jincheng,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki page.
>>>>>>> Just
>>>>>>>> a
>>>>>>>>>>> brief
>>>>>>>>>>>>>>>> summary,
>>>>>>>>>>>>>>>>> the current bylaws do require some of the FLIPs to
>>>>> get
>>>>>>> PMC
>>>>>>>>>>>>> approval
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>> their impact is big enough. But it leaves majority
>>>>> of
>>>>>>> the
>>>>>>>>>>>>> technical
>>>>>>>>>>>>>>>>> decisions to the committers who are supposed to be
>>>>>>>>> responsible
>>>>>>>>>>> for
>>>>>>>>>>>>>>> making
>>>>>>>>>>>>>>>>> such decisions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Re: Robert,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I agree we can simply remove the requirement of +1
>>>>>> from
>>>>>>> a
>>>>>>>>>>>>> non-author
>>>>>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
>>>>> does
>>>>>>> not
>>>>>>>>> make
>>>>>>>>>>>>> sense
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
>>>>>> updated
>>>>>>>> the
>>>>>>>>>>> bylaws
>>>>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
>>>>>>>>>>>>> rmetzger@apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
>>>>>>> current
>>>>>>>>>>> status
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
>>>>> is
>>>>>> a
>>>>>>>> very
>>>>>>>>>>>>> involved
>>>>>>>>>>>>>>>> task.
>>>>>>>>>>>>>>>>>> Unless there's somebody who's really eager to
>>>>> drive
>>>>>>>> this,
>>>>>>>>> I
>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> stick
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
>>>>>> Flink,
>>>>>>>> even
>>>>>>>>>> if
>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>>> some changes.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The cross-review requirement is the last big open
>>>>>>> point
>>>>>>>> in
>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> discussion.
>>>>>>>>>>>>>>>>>> It seems that a there is a slight tendency in the
>>>>>>>>> discussion
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> not feasible given the current pull request review
>>>>>>>>>> situation.
>>>>>>>>>>>>>>>>>> For the sake of bringing this discussion to a
>>>>>>>> conclusion,
>>>>>>>>>> I'm
>>>>>>>>>>>>> fine
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>> leaving this requirement out. As we are currently
>>>>>>> adding
>>>>>>>>>> more
>>>>>>>>>>>>>>>> committers
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> the project, we might be able to revisit this
>>>>>>> discussion
>>>>>>>>> in
>>>>>>>>>> 3
>>>>>>>>>>> -
>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> months.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
>>>>>>>>>>>>>>> sunjincheng121@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Becket,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks for the proposal.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
>>>>>>>>> includes a
>>>>>>>>>>> PMC
>>>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
>>>>>> the
>>>>>>>>> user's
>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>> changes. What do you think? (I leave the comment
>>>>>> in
>>>>>>>> the
>>>>>>>>>>> wiki.)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>> Jincheng
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
>>>>>>>> 于2019年7月17日周三
>>>>>>>>>>>>>> 下午9:12写道：
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
>>>>>> that
>>>>>>> I
>>>>>>>>>> really
>>>>>>>>>>>>> like
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> proposed bylaws!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
>>>>>>>>> expressed
>>>>>>>>>> by
>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>> people
>>>>>>>>>>>>>>>>>>>> before that the "committer +1" on code change
>>>>>>> might
>>>>>>>> be
>>>>>>>>>>> hard
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> achieve
>>>>>>>>>>>>>>>>>>>> currently. On the other hand I would say this
>>>>>>> would
>>>>>>>> be
>>>>>>>>>>>>>> beneficial
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
>>>>>>> knowledge
>>>>>>>>>>>>> sharing.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I was just wondering what should be the next
>>>>>> step
>>>>>>>> for
>>>>>>>>>>> this?
>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> would make sense to already use those bylaws
>>>>> and
>>>>>>> put
>>>>>>>>>> them
>>>>>>>>>>> to
>>>>>>>>>>>>>> PMC
>>>>>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Dawid
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
>>>>>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
>>>>> think.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
>>>>>> If
>>>>>>> we
>>>>>>>>> are
>>>>>>>>>>>>>> stating
>>>>>>>>>>>>>>>>> that a
>>>>>>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
>>>>>> review,
>>>>>>>>> with 0
>>>>>>>>>>>>> hours
>>>>>>>>>>>>>>>> delay
>>>>>>>>>>>>>>>>>> (de
>>>>>>>>>>>>>>>>>>>> facto
>>>>>>>>>>>>>>>>>>>>>>> the current state), we should also write
>>>>>> down
>>>>>>>> that
>>>>>>>>>>> this
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> subject
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
>>>>>> the
>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>> expertise
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
>>>>> facto
>>>>>>>>> current
>>>>>>>>>>>>>> state).
>>>>>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
>>>>>>>>>> intention,
>>>>>>>>>>>>> but
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
>>>>>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
>>>>>>> rule
>>>>>>>>>>> anyway,
>>>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
>>>>>> to
>>>>>>>> just
>>>>>>>>>>>>> avoid a
>>>>>>>>>>>>>>>>>> situation
>>>>>>>>>>>>>>>>>>>> when someone violates current uncodified state
>>>>>> and
>>>>>>>>>> refers
>>>>>>>>>>> to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> bylaws
>>>>>>>>>>>>>>>>>>>> which are saying merging with any committer +1
>>>>>> is
>>>>>>>>> always
>>>>>>>>>>>>> fine
>>>>>>>>>>>>>>> (like
>>>>>>>>>>>>>>>>>> mine
>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>> for flink-python or flink-ml).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Piotrek
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
>>>>> <
>>>>>>>>>>>>>>> aljoscha@apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
>>>>>> FLIP.
>>>>>>>>> This
>>>>>>>>>> is
>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> voting, before that there needs to be the
>>>>>>> discussion
>>>>>>>>>>>>> thread. If
>>>>>>>>>>>>>>>> three
>>>>>>>>>>>>>>>>>>> days
>>>>>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
>>>>>>> (i.e. 3
>>>>>>>>>>>>>>>> committers/PMCs
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
>>>>>> So
>>>>>>>> far,
>>>>>>>>>> we
>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> rarely
>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
>>>>> we
>>>>>>> want
>>>>>>>>> to
>>>>>>>>>>> use
>>>>>>>>>>>>>> "lazy
>>>>>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
>>>>>>> that
>>>>>>>>>> should
>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> changed
>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
>>>>>>> current
>>>>>>>>>> state
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
>>>>>>> come
>>>>>>>> up
>>>>>>>>>>> with
>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> reflects the common state, according to
>>>>>>>>> PMCs/commiters,
>>>>>>>>>>> that
>>>>>>>>>>>>>>> might
>>>>>>>>>>>>>>>>>> take a
>>>>>>>>>>>>>>>>>>>> very long time. In that case I think it’s
>>>>> better
>>>>>>> to
>>>>>>>>>> adopt
>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
>>>>>> do
>>>>>>> it
>>>>>>>>>> now.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
>>>>> <
>>>>>>>>>>>>>>> piotr@ververica.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
>>>>> speaking
>>>>>> +1
>>>>>>>>> from
>>>>>>>>>> my
>>>>>>>>>>>>> side
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> general idea and most of the content. I also
>>>>> see
>>>>>>>> merit
>>>>>>>>>> to
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> Chesney's
>>>>>>>>>>>>>>>>>>>> proposal to start from the current state. I
>>>>>> think
>>>>>>>>> either
>>>>>>>>>>>>> would
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> fine
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> me.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Couple of comments:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 1.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
>>>>> another
>>>>>>>>>> committer
>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> slow
>>>>>>>>>>>>>>>>>> down
>>>>>>>>>>>>>>>>>>>> and put even more strain on the current
>>>>>> reviewing
>>>>>>>>>>> bottleneck
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
>>>>>>> context
>>>>>>>>>>> switch
>>>>>>>>>>>>>> cost
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
>>>>>> second
>>>>>>>>>> “cross”
>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
>>>>>>> Besides,
>>>>>>>>>>> current
>>>>>>>>>>>>>> setup
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
>>>>>>>>> required)
>>>>>>>>>>>>> works
>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>> well
>>>>>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
>>>>>> the
>>>>>>>>> other
>>>>>>>>>>> hand
>>>>>>>>>>>>>>>>> reviewing
>>>>>>>>>>>>>>>>>>>> bottleneck is.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
>>>>> ask
>>>>>>>>> another
>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> feedback or not.
>>>>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
>>>>>> If
>>>>>>> we
>>>>>>>>> are
>>>>>>>>>>>>>> stating
>>>>>>>>>>>>>>>>> that a
>>>>>>>>>>>>>>>>>>>> single committers +1 is good enough for code
>>>>>>> review,
>>>>>>>>>> with
>>>>>>>>>>> 0
>>>>>>>>>>>>>> hours
>>>>>>>>>>>>>>>>> delay
>>>>>>>>>>>>>>>>>>> (de
>>>>>>>>>>>>>>>>>>>> facto the current state), we should also write
>>>>>>> down
>>>>>>>>> that
>>>>>>>>>>>>> this
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> subject
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> the best judgement of the committer to respect
>>>>>> the
>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>> expertise
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
>>>>>>> current
>>>>>>>>>>> state).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 3.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
>>>>>>>>> currently
>>>>>>>>>>>>> might
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
>>>>>> if
>>>>>>>>>>> respected
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> letter.
>>>>>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
>>>>>>>>>> committers
>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>> highest
>>>>>>>>>>>>>>>>>>>> expertise in the affected components managed
>>>>> to
>>>>>>>>> respond
>>>>>>>>>> or
>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Piotrek
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
>>>>> Schepler
>>>>>> <
>>>>>>>>>>>>>>>> chesnay@apache.org>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
>>>>>>> write
>>>>>>>>> down
>>>>>>>>>>>>> Bylaws
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> reflect the current state, and then have
>>>>>> separate
>>>>>>>>>>>>> discussions
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
>>>>>> this
>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> quickly
>>>>>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
>>>>>>>>> discussed
>>>>>>>>>>> at
>>>>>>>>>>>>>> once.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
>>>>>> Qin
>>>>>>> <
>>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
>>>>> and
>>>>>>>>>> feedback.
>>>>>>>>>>>>>> Please
>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> replies
>>>>>>>>>>>>>>>>>>>>>>>>>> below:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
>>>>> Change"
>>>>>> we
>>>>>>>>> could
>>>>>>>>>>>>> also
>>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>>>>> row
>>>>>>>>>>>>>>>>>>>> for "Code
>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
>>>>>> reference
>>>>>>> to
>>>>>>>>> the
>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>> page. A
>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
>>>>> for
>>>>>>>>>> approvals,
>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
>>>>> currently
>>>>>>>>> requires
>>>>>>>>>>>>> "one
>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
>>>>> followed
>>>>>>> by a
>>>>>>>>>> Lazy
>>>>>>>>>>>>>>> approval
>>>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>>>>>> counting
>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
>>>>> to
>>>>>>> lazy
>>>>>>>>>>>>> majority
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> -1
>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>> received".
>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
>>>>>>>>> committer
>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>> needs a
>>>>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
>>>>>>> know
>>>>>>>>> this
>>>>>>>>>>> is
>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>>>>>>>> contributor
>>>>>>>>>>>>> reviews
>>>>>>>>>>>>>> &
>>>>>>>>>>>>>>>>> +1s).
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
>>>>> we
>>>>>>> can
>>>>>>>>>> make
>>>>>>>>>>> it
>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> follow the
>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
>>>>>> Flink-specific
>>>>>>>> Jira
>>>>>>>>>>>>>> workflows
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>>>>>>>> types +
>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
>>>>> is
>>>>>>>>>> certainly
>>>>>>>>>>>>>> "Step
>>>>>>>>>>>>>>>> 2",
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>> believe,
>>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
>>>>>>> transparent
>>>>>>>>> as
>>>>>>>>>>>>>> possible,
>>>>>>>>>>>>>>>>>>>> otherwise they
>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
>>>>>>>>>>>>>>>>>>>>>>>>>> & Re: Till
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
>>>>>>> author
>>>>>>>>> and
>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
>>>>>> should
>>>>>>>> know
>>>>>>>>>>> when
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> ask
>>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
>>>>> I
>>>>>>>> would
>>>>>>>>>> not
>>>>>>>>>>>>>> enforce
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
>>>>> author
>>>>>>> is
>>>>>>>> a
>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> course
>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
>>>>>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
>>>>> here.
>>>>>>>> TBH,
>>>>>>>>> in
>>>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>>>>> occasionally
>>>>>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
>>>>> still
>>>>>>>>> merged
>>>>>>>>>>>>> without
>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
>>>>> rare.
>>>>>>>> That
>>>>>>>>>>> said,
>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
>>>>> sense
>>>>>>> due
>>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>> reasons:
>>>>>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
>>>>>> to
>>>>>>>> make
>>>>>>>>>>> sure
>>>>>>>>>>>>>> every
>>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
>>>>>>>> little
>>>>>>>>>>>>> difficult
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> guarantee if
>>>>>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
>>>>>>> many
>>>>>>>>>>>>> reasons. In
>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>> cases, a
>>>>>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
>>>>> knowledge
>>>>>>>> about
>>>>>>>>>> the
>>>>>>>>>>>>>>> project
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>> a good
>>>>>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
>>>>>> contributors
>>>>>>>> are
>>>>>>>>>> more
>>>>>>>>>>>>>>> eagerly
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> get a
>>>>>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
>>>>>> willing
>>>>>>>> to
>>>>>>>>>>> lower
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>> bar.
>>>>>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
>>>>>> among
>>>>>>>>>>>>> committers,
>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>> personally
>>>>>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
>>>>>>> form
>>>>>>>>>>>>> consistent
>>>>>>>>>>>>>>>> design
>>>>>>>>>>>>>>>>>>>> principles
>>>>>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
>>>>>>>> committers
>>>>>>>>>> will
>>>>>>>>>>>>> know
>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
>>>>>> from
>>>>>>>> each
>>>>>>>>>>>>> other.
>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>> tend
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
>>>>>>> things
>>>>>>>>>> should
>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> general.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
>>>>>>>> consider
>>>>>>>>>> the
>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>>>>>> scenarios:
>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
>>>>> a
>>>>>>> lot
>>>>>>>> of
>>>>>>>>>>>>>>> iterations.
>>>>>>>>>>>>>>>>> Then
>>>>>>>>>>>>>>>>>>>> the patch
>>>>>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
>>>>>> time
>>>>>>>>>> because
>>>>>>>>>>>>> there
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> things
>>>>>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
>>>>> changed.
>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
>>>>> very
>>>>>>>> smooth
>>>>>>>>>> and
>>>>>>>>>>>>>> quick,
>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> patch is
>>>>>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
>>>>> patch
>>>>>>> does
>>>>>>>>> not
>>>>>>>>>>>>> take
>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>> time.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
>>>>>> patch
>>>>>>>>> from a
>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>> falls
>>>>>>>>>>>>>>>>>>>> either in
>>>>>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
>>>>> is
>>>>>>> to
>>>>>>>>>> review
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
>>>>> needs
>>>>>>> to
>>>>>>>> be
>>>>>>>>>>>>>> reviewed.
>>>>>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
>>>>>> take
>>>>>>>>> much
>>>>>>>>>>> time
>>>>>>>>>>>>>>>> anyways.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
>>>>>>> case
>>>>>>>> 1
>>>>>>>>> if
>>>>>>>>>>> we
>>>>>>>>>>>>>> skip
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> cross-review.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Robert
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
>>>>>> and
>>>>>>>> made
>>>>>>>>>> the
>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>> modifications
>>>>>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
>>>>> section.
>>>>>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
>>>>>> to
>>>>>>>>>>>>> "consensus"
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> align
>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
>>>>> and
>>>>>>>> other
>>>>>>>>>>>>>> projects.
>>>>>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
>>>>> unnecessary
>>>>>>>>> noise.
>>>>>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
>>>>>> 2/3
>>>>>>>>>>> majority
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>> feasible in
>>>>>>>>>>>>>>>>>>>>>>>>>> practice.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
>>>>> the
>>>>>>>> draft
>>>>>>>>>>>>> compared
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
>>>>>>>>> highlight
>>>>>>>>>>>>> these
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
>>>>>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
>>>>>>> familiar
>>>>>>>>>> enough
>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> current Flink
>>>>>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
>>>>> saw
>>>>>>> you
>>>>>>>>>>>>> commented
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
>>>>>>> bylaws?
>>>>>>>>> I’m
>>>>>>>>>>>>> asking
>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
>>>>> essentially
>>>>>>>>> adopting
>>>>>>>>>>> the
>>>>>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>>>>> bylaws.
>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>> mean,
>>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
>>>>>> try
>>>>>>>> to
>>>>>>>>>>>>> re-invent
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> wheel
>>>>>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
>>>>> version
>>>>>>> of
>>>>>>>>> the
>>>>>>>>>>>>> draft
>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>>>>> almost
>>>>>>>>>>>>>>>>>>>> identical
>>>>>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
>>>>> caught a
>>>>>>> few
>>>>>>>>>>>>>> inconsistent
>>>>>>>>>>>>>>>>>> places.
>>>>>>>>>>>>>>>>>>>> So it
>>>>>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
>>>>>> make
>>>>>>>> sure
>>>>>>>>>> we
>>>>>>>>>>>>> truly
>>>>>>>>>>>>>>>> agree
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
>>>>>>>> shortly
>>>>>>>>>>> after
>>>>>>>>>>>>>>>> adoption.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
>>>>> valuable
>>>>>>>>>> feedback.
>>>>>>>>>>>>> These
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> great
>>>>>>>>>>>>>>>>>>>>>>>>>> discussion.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
>>>>> Aljoscha
>>>>>>>>> Krettek
>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>> aljoscha@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Big +1
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
>>>>>>> bylaws?
>>>>>>>>> I’m
>>>>>>>>>>>>> asking
>>>>>>>>>>>>>>>>>> because I
>>>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
>>>>> essentially
>>>>>>>>> adopting
>>>>>>>>>>> the
>>>>>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>>>>> bylaws.
>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>> mean,
>>>>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
>>>>>> try
>>>>>>>> to
>>>>>>>>>>>>> re-invent
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> wheel
>>>>>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
>>>>>>>>>> “committer
>>>>>>>>>>>>> +1”
>>>>>>>>>>>>>>>>>>> requirement.
>>>>>>>>>>>>>>>>>>>> We
>>>>>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
>>>>> would
>>>>>>>>> actually
>>>>>>>>>>> be
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> favour
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>> requiring
>>>>>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
>>>>>>>>>> complicated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
>>>>>> Rohrmann
>>>>>>> <
>>>>>>>>>>>>>>>>>> trohrmann@apache.org>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
>>>>>>>> Becket.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
>>>>> emeritus
>>>>>>> (or
>>>>>>>>>> active
>>>>>>>>>>>>> vs.
>>>>>>>>>>>>>>>>>> inactive),
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>>> won't
>>>>>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
>>>>> vote
>>>>>>>>> because
>>>>>>>>>>> we
>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>>>>>>> many
>>>>>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
>>>>>>>> author
>>>>>>>>>> and
>>>>>>>>>>>>>>> getting a
>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
>>>>>> should
>>>>>>>>> know
>>>>>>>>>>>>> when to
>>>>>>>>>>>>>>> ask
>>>>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
>>>>> Hence, I
>>>>>>>> would
>>>>>>>>>> not
>>>>>>>>>>>>>>> enforce
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>> strictly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
>>>>>> author
>>>>>>>> is a
>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> course
>>>>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Till
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
>>>>> Chesnay
>>>>>>>>>> Schepler
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>> chesnay@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
>>>>>>> unnecessary
>>>>>>>>>> noise.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
>>>>>> the
>>>>>>>>> draft
>>>>>>>>>>>>>> compared
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
>>>>> to
>>>>>>>>>> highlight
>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
>>>>> this
>>>>>>>>>>> discussion
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> draft
>>>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
>>>>> that
>>>>>> a
>>>>>>>>>>> committer
>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
>>>>>> as I
>>>>>>>>> know
>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>>>>>>>>>> contributor
>>>>>>>>>>>>>>> reviews
>>>>>>>>>>>>>>>> &
>>>>>>>>>>>>>>>>>>> +1s).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
>>>>> if
>>>>>>> we
>>>>>>>>> had
>>>>>>>>>>>>> cases
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> past
>>>>>>>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
>>>>> we
>>>>>>>>> believe
>>>>>>>>>>>>> that we
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> enough
>>>>>>>>>>>>>>>>>>>>>>>>>>> capacity
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
>>>>>>>> approval.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
>>>>>>>> Konstantin
>>>>>>>>>>> Knauf
>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
>>>>>>> Becket. I
>>>>>>>>>> have
>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>> remarks
>>>>>>>>>>>>>>>>>>>> regarding
>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
>>>>>>> Change"
>>>>>>>> we
>>>>>>>>>>> could
>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>>>>>>>> row for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
>>>>>>>> reference
>>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>> page.
>>>>>>>>>>>>>>>>>>>>>>>>>> A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
>>>>> rules
>>>>>>> for
>>>>>>>>>>>>> approvals,
>>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
>>>>>>> currently
>>>>>>>>>>> requires
>>>>>>>>>>>>>> "one
>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
>>>>>>> followed
>>>>>>>>> by a
>>>>>>>>>>>>> Lazy
>>>>>>>>>>>>>>>>> approval
>>>>>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>>>>>>>>>>>>> counting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
>>>>> moving
>>>>>>> to
>>>>>>>>> lazy
>>>>>>>>>>>>>> majority
>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> -1
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> received".
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
>>>>>> that a
>>>>>>>>>>> committer
>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>> needs a
>>>>>>>>>>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
>>>>>> as I
>>>>>>>>> know
>>>>>>>>>>>>> this is
>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>>>>>>>>>> contributor
>>>>>>>>>>>>>>> reviews
>>>>>>>>>>>>>>>> &
>>>>>>>>>>>>>>>>>>> +1s).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
>>>>>> how
>>>>>>>> we
>>>>>>>>>> can
>>>>>>>>>>>>> make
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
>>>>>>>> Flink-specific
>>>>>>>>>> Jira
>>>>>>>>>>>>>>>> workflows
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> types +
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
>>>>>> this
>>>>>>> is
>>>>>>>>>>>>> certainly
>>>>>>>>>>>>>>>> "Step
>>>>>>>>>>>>>>>>>> 2",
>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>>> believe,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
>>>>>>>>> transparent
>>>>>>>>>>> as
>>>>>>>>>>>>>>>> possible,
>>>>>>>>>>>>>>>>>>>> otherwise
>>>>>>>>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
>>>>>> Becket
>>>>>>>>> Qin <
>>>>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
>>>>>> process
>>>>>>>>>>> discussion
>>>>>>>>>>>>>>> thread
>>>>>>>>>>>>>>>>>> [1],
>>>>>>>>>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
>>>>>>> govern
>>>>>>>>> the
>>>>>>>>>>>>>>> operation
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> project.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
>>>>>> community
>>>>>>>> to
>>>>>>>>>>>>>> coordinate
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> contribute
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
>>>>>>> other
>>>>>>>>>>>>> processes
>>>>>>>>>>>>>>> such
>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>> FLIP.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
>>>>> page
>>>>>>> and
>>>>>>>>>> would
>>>>>>>>>>>>> like
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> start a
>>>>>>>>>>>>>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
>>>>> in
>>>>>>> the
>>>>>>>>>>>>> community.
>>>>>>>>>>>>>>>> It'll
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> great to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hear
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
>>>>>> Architect
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
>>>>>>>> 31.08.2019,
>>>>>>>>>>>>> 05.09. -
>>>>>>>>>>>>>>>>>>> 06.09.2010
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
>>>>>> 115,
>>>>>>>>> 10115
>>>>>>>>>>>>>> Berlin,
>>>>>>>>>>>>>>>>>> Germany
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
>>>>>>>> Charlottenburg:
>>>>>>>>>> HRB
>>>>>>>>>>>>>> 158244
>>>>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
>>>>>>> Tzoumas,
>>>>>>>>> Dr.
>>>>>>>>>>>>> Stephan
>>>>>>>>>>>>>>>> Ewen
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: [DISCUSS] Flink project bylaws

[Becket Qin <be...@gmail.com>]

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 <be...@gmail.com> wrote:

> Hi Maximillian,
>
> Thanks for the feedback. Please see the reply below:
>
> Step 2 should include a personal email to the PMC members in question.
>
> I'm afraid reminders inside the vote thread could be overlooked easily.
>
>
> This is exactly what I meant to say by "reach out" :) I just made it more
> explicit.
>
> The way the terms are described in the draft, the consensus is "lazy",
>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy
>> Consensus". This is in line with the other definitions such as "Lazy
>> Majority".
>
> It was initially called "lazy consensus", but Robert pointed out that
> "lazy consensus" actually means something different in ASF term [1].
> Here "lazy" pretty much means "assume everyone is +1 unless someone says
> otherwise". This means any vote that requires a minimum number of +1 is not
> really a "lazy" vote.
>
> Removing a committer / PMC member only requires 3 binding votes. I'd
>> expect an important action like this to require a 2/3 majority.
>
> Personally I think consensus is good enough here. PMC members can cast a
> veto if they disagree about the removal. In some sense, it is more
> difficult than with 2/3 majority to remove a committer / PMC member. Also,
> it might be a hard decision for some PMC members if they have never worked
> with the person in question. That said, I am OK to change it to 2/3
> majority as this will happen very rarely.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> [1] https://www.apache.org/foundation/voting.html#LazyConsensus
>
> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <mx...@apache.org> wrote:
>
>> I'm a bit late to the discussion here. Three suggestions:
>>
>> 1) Procedure for "insufficient active binding voters to reach 2/3 majority
>>
>> >     1. Wait until the minimum length of the voting passes.
>> >     2. Publicly reach out to the remaining binding voters in the voting
>> mail thread for at least 2 attempts with at least 7 days between two
>> attempts.
>> >     3. If the binding voter being contacted still failed to respond
>> after all the attempts, the binding voter will be considered as inactive
>> for the purpose of this particular voting.
>>
>> Step 2 should include a personal email to the PMC members in question.
>> I'm afraid reminders inside the vote thread could be overlooked easily.
>>
>> 2) "Consensus" => "Lazy Consensus"
>>
>> The way the terms are described in the draft, the consensus is "lazy",
>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy
>> Consensus". This is in line with the other definitions such as "Lazy
>> Majority".
>>
>> 3) Committer / PMC Removal
>>
>> Removing a committer / PMC member only requires 3 binding votes. I'd
>> expect an important action like this to require a 2/3 majority.
>>
>>
>> Do you think we could incorporate those suggestions?
>>
>> Thanks,
>> Max
>>
>> On 11.08.19 10:14, Becket Qin wrote:
>> > Hi folks,
>> >
>> > Thanks for all the discussion and support. I have started the voting
>> thread.
>> >
>> >
>> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
>> >
>> > Thanks,
>> >
>> > Jiangjie (Becket) Qin
>> >
>> > On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <fh...@gmail.com> wrote:
>> >
>> >> Thanks for the update and driving the discussion Becket!
>> >> +1 for starting a vote.
>> >>
>> >> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
>> becket.qin@gmail.com
>> >>> :
>> >>
>> >>> Thanks Stephan.
>> >>>
>> >>> I think we have resolved all the comments on the wiki page. There are
>> two
>> >>> minor changes made to the bylaws since last week.
>> >>> 1. For 2/3 majority, the required attempts to reach out to binding
>> voters
>> >>> is reduced from 3 to 2. This helps shorten the voting process a little
>> >> bit.
>> >>> 2. Clarified what is considered as the adoption of new codebase.
>> >>>
>> >>> I think we almost reached consensus. I'll start a voting thread in two
>> >> days
>> >>> if there is no new concerns.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Jiangjie (Becket) Qin
>> >>>
>> >>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org> wrote:
>> >>>
>> >>>> I added a clarification to the table, clarifying that the current
>> >>> phrasing
>> >>>> means that committers do not need another +1 for their commits.
>> >>>>
>> >>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fh...@gmail.com>
>> >> wrote:
>> >>>>
>> >>>>> Hi Becket,
>> >>>>>
>> >>>>> Thanks a lot for pushing this forward and addressing the feedback.
>> >>>>> I'm very happy with the current state of the bylaws.
>> >>>>> +1 to wait until Friday before starting a vote.
>> >>>>>
>> >>>>> Best, Fabian
>> >>>>>
>> >>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
>> >>>>> becket.qin@gmail.com
>> >>>>>> :
>> >>>>>
>> >>>>>> Hi Everyone,
>> >>>>>>
>> >>>>>> Thanks for all the discussion and feedback.
>> >>>>>>
>> >>>>>> It seems that we have almost reached consensus. I'll leave the
>> >>>> discussion
>> >>>>>> thread open until this Friday. If there is no more concerns raised,
>> >>>> I'll
>> >>>>>> start a voting thread after that.
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>>
>> >>>>>> Jiangjie (Becket) Qin
>> >>>>>>
>> >>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com> wrote:
>> >>>>>>
>> >>>>>>> Hi Becket,
>> >>>>>>>
>> >>>>>>> Thanks for noticing and resolving my comment around PMC removal
>> >> and
>> >>>> ASF
>> >>>>>>> rules of PMC membership change process, which you seem to neglect
>> >>> in
>> >>>>> the
>> >>>>>>> summary of updates (smile).
>> >>>>>>>
>> >>>>>>> Best Regards,
>> >>>>>>> Yu
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <be...@gmail.com>
>> >>>> wrote:
>> >>>>>>>
>> >>>>>>>> Hi folks,
>> >>>>>>>>
>> >>>>>>>> Thanks for all the feedback.
>> >>>>>>>>
>> >>>>>>>> It seems that there are a few concerns over the emeritus status
>> >>>>> after 6
>> >>>>>>>> months of inactivity. Given that the main purpose is just to
>> >> make
>> >>>>> sure
>> >>>>>>> 2/3
>> >>>>>>>> majority can pass and we sort of have a solution for that, I
>> >> just
>> >>>>>> updated
>> >>>>>>>> the draft with the following changes:
>> >>>>>>>>
>> >>>>>>>> 1. Removed the inactivity term for emeritus committers / PMCs.
>> >> A
>> >>>>>>> committer
>> >>>>>>>> / PMC will only be considered emeritus by their own claim.
>> >>>>>>>> 2. Removed the approval process for reinstatement of the
>> >> emeritus
>> >>>>>>>> committers / PMCs. An emeritus committer / PMC will be
>> >> reinstated
>> >>>>> when
>> >>>>>>> they
>> >>>>>>>> send an email to the private@flink.apache.org.
>> >>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still doable
>> >>> when
>> >>>>>> there
>> >>>>>>>> are non-emeritus committers / PMCs who do not cast the vote.
>> >>>>>>>>
>> >>>>>>>> Please let me know if you have any further thoughts.
>> >>>>>>>>
>> >>>>>>>> Thanks,
>> >>>>>>>>
>> >>>>>>>> Jiangjie (Becket) Qin
>> >>>>>>>>
>> >>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
>> >>> becket.qin@gmail.com>
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> Hi Fabian,
>> >>>>>>>>>
>> >>>>>>>>> Thanks for the feedback.
>> >>>>>>>>>
>> >>>>>>>>> I agree that if we don't like emeritus committers / PMCs, we
>> >>>> don't
>> >>>>>> have
>> >>>>>>>> to
>> >>>>>>>>> do it. That said, emeritus status simply means whether an
>> >>>>> individual
>> >>>>>> is
>> >>>>>>>>> active / inactive in the community. It does not make the
>> >> merits
>> >>>>>> earned
>> >>>>>>> to
>> >>>>>>>>> go away. For our purpose, emeritus status is mostly just a
>> >> way
>> >>> to
>> >>>>>> make
>> >>>>>>>> 2/3
>> >>>>>>>>> majority possible. As you noticed, since reaching out to
>> >>> binding
>> >>>>>> voters
>> >>>>>>>> who
>> >>>>>>>>> have not voted can achieve the same goal, the emeritus status
>> >>> is
>> >>>>> more
>> >>>>>>> of
>> >>>>>>>> an
>> >>>>>>>>> optimization so we don't have to ping the inactive binding
>> >>> voters
>> >>>>>> every
>> >>>>>>>>> time and wait for long. However, given that 2/3 majority
>> >>> votings
>> >>>>> are
>> >>>>>>>> rare,
>> >>>>>>>>> such communication cost is probably OK. So I think we can
>> >>> remove
>> >>>>> that
>> >>>>>>>>> emeritus part from the bylaws.
>> >>>>>>>>>
>> >>>>>>>>> 1) We should add to the requirements of the PMC that they
>> >> need
>> >>> to
>> >>>>>> make
>> >>>>>>>>>> sure the project complies with brand issues and reports
>> >> misuse
>> >>>> of
>> >>>>>> ASF
>> >>>>>>>>>> brands.
>> >>>>>>>>>
>> >>>>>>>>> Good point. Added.
>> >>>>>>>>>
>> >>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
>> >> a
>> >>> 3
>> >>>>> day
>> >>>>>>> vote
>> >>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
>> >>>>>>>>>
>> >>>>>>>>> This might be a little tricky because people are from
>> >> countries
>> >>>> in
>> >>>>>>>>> different time zones and with different holidays, and so on.
>> >> If
>> >>>> we
>> >>>>>> are
>> >>>>>>>>> worrying about 3 days minimum length is not enough for those
>> >>> who
>> >>>>> want
>> >>>>>>> to
>> >>>>>>>>> give feedback, we can make it 5 days.
>> >>>>>>>>>
>> >>>>>>>>> 3) Do we need a process do decide about removal of features
>> >>> (like
>> >>>>> the
>> >>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
>> >>> Python
>> >>>>>>> APIs)?
>> >>>>>>>>>
>> >>>>>>>>> I assume such action should be covered by FLIP as it is a
>> >>> change
>> >>>> to
>> >>>>>> the
>> >>>>>>>>> API and probably needs a migration plan. It would be useful
>> >> to
>> >>>>> have a
>> >>>>>>>>> formal deprecation procedure. But that might be better to be
>> >>> put
>> >>>>> into
>> >>>>>>>>> somewhere else because the bylaws are primarily focusing on
>> >> the
>> >>>>>>>>> non-technical rules, whereas the deprecation seems more on
>> >> the
>> >>>>>>> technical
>> >>>>>>>>> side.
>> >>>>>>>>>
>> >>>>>>>>> Thanks,
>> >>>>>>>>>
>> >>>>>>>>> Jiangjie (Becket) Qin
>> >>>>>>>>>
>> >>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
>> >>>> fhueske@gmail.com>
>> >>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Hi all,
>> >>>>>>>>>>
>> >>>>>>>>>> First of all thank you very much Becket for starting this
>> >>>>>> discussion!
>> >>>>>>>>>> I think it is a very good idea and overdue to formally
>> >> define
>> >>>> some
>> >>>>>> of
>> >>>>>>>> our
>> >>>>>>>>>> community processes.
>> >>>>>>>>>>
>> >>>>>>>>>> Similar to Chesnay, I have concerns about the distinction
>> >>>> between
>> >>>>>>> active
>> >>>>>>>>>> and non-active / emeritus committers and PMC members.
>> >>>>>>>>>> My foremost concern is that this is not in the spirit of the
>> >>>>> Apache
>> >>>>>>> Way
>> >>>>>>>>>> [1]
>> >>>>>>>>>> which is (among other things) based on the idea of merit
>> >> which
>> >>>>> once
>> >>>>>>>>>> earned,
>> >>>>>>>>>> does not go away over time.
>> >>>>>>>>>> I know other projects like Hadoop and Kafka have similar
>> >>> clauses
>> >>>>> in
>> >>>>>>> the
>> >>>>>>>>>> bylaws but IMO we don't need to adopt them if we don't like
>> >>>> them.
>> >>>>>>>>>> For example, I don't like the idea that committers or PMC
>> >>>> members
>> >>>>>> who
>> >>>>>>>> are
>> >>>>>>>>>> temporarily away from the project (for whatever reason:
>> >>> parental
>> >>>>>>> leave,
>> >>>>>>>>>> sabbatical, health issues, etc.) need the PMC approval to be
>> >>>>>> "active"
>> >>>>>>>>>> again.
>> >>>>>>>>>> As far as I am aware, we have not seen any issues with
>> >>> inactive
>> >>>>>>> members
>> >>>>>>>> in
>> >>>>>>>>>> the past.
>> >>>>>>>>>> Moreover, it would be hard to track whether somebody became
>> >>>>> inactive
>> >>>>>>> at
>> >>>>>>>>>> some point in time (which we would need to do, if I
>> >> understand
>> >>>> the
>> >>>>>>>>>> proposal
>> >>>>>>>>>> correctly).
>> >>>>>>>>>> With the approach that Becket suggested in his last email
>> >>>>> (reaching
>> >>>>>>> out
>> >>>>>>>> to
>> >>>>>>>>>> binding voters who haven't voted yet), we could drop the
>> >>>>> distinction
>> >>>>>>>>>> between active and non-active committers and PMC members.
>> >>>>>>>>>>
>> >>>>>>>>>> I also have a few minor comments:
>> >>>>>>>>>>
>> >>>>>>>>>> 1) We should add to the requirements of the PMC [2] that
>> >> they
>> >>>> need
>> >>>>>> to
>> >>>>>>>> make
>> >>>>>>>>>> sure the project complies with brand issues and reports
>> >> misuse
>> >>>> of
>> >>>>>> ASF
>> >>>>>>>>>> brands.
>> >>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
>> >>> a 3
>> >>>>> day
>> >>>>>>>> vote
>> >>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
>> >>>>>>>>>> 3) Do we need a process do decide about removal of features
>> >>>> (like
>> >>>>>> the
>> >>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
>> >>> Python
>> >>>>>>> APIs)?
>> >>>>>>>>>>
>> >>>>>>>>>> Thank you,
>> >>>>>>>>>> Fabian
>> >>>>>>>>>>
>> >>>>>>>>>> [1] https://www.apache.org/theapacheway/
>> >>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
>> >>>>>>>>>>
>> >>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
>> >>>>>>>>>> becket.qin@gmail.com
>> >>>>>>>>>>> :
>> >>>>>>>>>>
>> >>>>>>>>>>> Hi Hequn,
>> >>>>>>>>>>>
>> >>>>>>>>>>> Thanks for sharing your thoughts. Please see the reply
>> >>> below:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one PMC
>> >> in
>> >>>>> the 3
>> >>>>>>>>>> binding
>> >>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
>> >> and 1
>> >>>>> PMC.
>> >>>>>>>>>>>> I think this makes sense considering a FLIP could
>> >> somehow
>> >>>> be a
>> >>>>>> big
>> >>>>>>>>>>> feature
>> >>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
>> >> loss
>> >>>> of
>> >>>>>>>>>> flexibility
>> >>>>>>>>>>>> as committers also have a chance to vote and participate
>> >>> in
>> >>>>> it.
>> >>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs are
>> >> the
>> >>>>>>> following:
>> >>>>>>>>>>>
>> >>>>>>>>>>> 1. Generally speaking, the PMC's primary responsibility is
>> >>>>>> operating
>> >>>>>>>> the
>> >>>>>>>>>>> project and deciding what software to release on behalf of
>> >>>> ASF.
>> >>>>>>>>>> Committers,
>> >>>>>>>>>>> on the other hand, are responsible for the technical part
>> >> of
>> >>>> the
>> >>>>>>>>>> project.
>> >>>>>>>>>>> So for FLIPs, a PMC's vote probably should not outweigh a
>> >>>>>>> committer's
>> >>>>>>>>>> vote.
>> >>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is really
>> >>>>>> convincing
>> >>>>>>>>>> enough
>> >>>>>>>>>>> to decide whether the FLIP is good to go or not. Also, if
>> >>> some
>> >>>>>>>>>> committers
>> >>>>>>>>>>> have concern over a FLIP, they could just veto it. To me
>> >> it
>> >>> is
>> >>>>>>>> actually
>> >>>>>>>>>> a
>> >>>>>>>>>>> more strict requirement to pass a FLIP than asking a PMC
>> >> to
>> >>>>> vote.
>> >>>>>> In
>> >>>>>>>>>>> practice, people will usually also address the concerns
>> >> even
>> >>>> if
>> >>>>>> they
>> >>>>>>>> are
>> >>>>>>>>>>> not from a PMC/committer before they start the voting
>> >>> process.
>> >>>>> So
>> >>>>>> I
>> >>>>>>>>>> don't
>> >>>>>>>>>>> see much benefit of requiring a PMC's vote in this case.
>> >>>>>>>>>>>
>> >>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the votes
>> >> no
>> >>>>> longer
>> >>>>>>>>>>> independent. Ideally, a vote is either binding or
>> >>> non-binding
>> >>>> by
>> >>>>>>>>>> itself. If
>> >>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
>> >> imagine
>> >>>>> there
>> >>>>>>> have
>> >>>>>>>>>> been
>> >>>>>>>>>>> 3 committers who voted +1. But the FLIP still has not
>> >>> passed,
>> >>>> so
>> >>>>>>> those
>> >>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a +1,
>> >>> those
>> >>>>>> votes
>> >>>>>>>>>>> suddenly become binding, which is a little awkward.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable to me.
>> >>> Some
>> >>>>>>>> thoughts
>> >>>>>>>>>> on
>> >>>>>>>>>>> this:
>> >>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is probably
>> >>>> because
>> >>>>>>> there
>> >>>>>>>>>> are
>> >>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3 majority
>> >>>>>>>> prohibitively
>> >>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
>> >> Flink[2]
>> >>>> and
>> >>>>> a
>> >>>>>>>> quick
>> >>>>>>>>>>> search shows at most 6 of them have not sent email in the
>> >>>>> recent 6
>> >>>>>>>>>> months
>> >>>>>>>>>>> or so.
>> >>>>>>>>>>>
>> >>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare. It is
>> >>>>> designed
>> >>>>>>> in
>> >>>>>>>>>>> particular for the cases that broad opinions are
>> >> important,
>> >>>> more
>> >>>>>>>>>>> specifically new codebase adoption or modification to the
>> >>>>> bylaws.
>> >>>>>>>>>> Therefore
>> >>>>>>>>>>> such vote by its nature favors consensus over convenience.
>> >>>> That
>> >>>>>>> means
>> >>>>>>>>>> any
>> >>>>>>>>>>> alternative voting type reducing the coverage worth a
>> >>> careful
>> >>>>>>>> thinking.
>> >>>>>>>>>>>
>> >>>>>>>>>>> 3. I do agree that it does not make sense to have 2/3
>> >>> majority
>> >>>>> if
>> >>>>>>> such
>> >>>>>>>>>>> requirement is no-longer doable over time. But I am a
>> >> little
>> >>>>>>> hesitant
>> >>>>>>>> to
>> >>>>>>>>>>> lower the threshold to lazy 2/3 majority in our case. What
>> >>> do
>> >>>>> you
>> >>>>>>>> think
>> >>>>>>>>>>> about doing the following:
>> >>>>>>>>>>>     - After the voting started, there will be at least 6
>> >>> days
>> >>>>> for
>> >>>>>>>>>> people to
>> >>>>>>>>>>> cast their votes.
>> >>>>>>>>>>>     - After 6 days, if the result of the vote is still not
>> >>>>>>> determined,
>> >>>>>>>>>> the
>> >>>>>>>>>>> person who started the vote should reach out to the
>> >> binding
>> >>>>> voters
>> >>>>>>> who
>> >>>>>>>>>> have
>> >>>>>>>>>>> not voted yet for at least 3 times and at least 7 days
>> >>> between
>> >>>>>> each
>> >>>>>>>>>> time.
>> >>>>>>>>>>> If a binding voter still did not respond, the vote from
>> >> that
>> >>>>> voter
>> >>>>>>>> will
>> >>>>>>>>>> be
>> >>>>>>>>>>> excluded from the 2/3 majority counting.
>> >>>>>>>>>>> This would ensure the coverage at our best effort while
>> >>> still
>> >>>>> let
>> >>>>>>> the
>> >>>>>>>>>> 2/3
>> >>>>>>>>>>> majority vote make progress.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Thanks,
>> >>>>>>>>>>>
>> >>>>>>>>>>> Jiangjie (Becket) Qin
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> [1] https://projects.apache.org/committee.html?hadoop
>> >>>>>>>>>>> [2] https://projects.apache.org/committee.html?flink
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
>> >>>>>> forwardxu315@gmail.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Big +1 on this.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> best
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> forward
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
>> >>> 下午1:30写道：
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> Hi Becket,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Big +1 on this.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
>> >>>> includes a
>> >>>>>> PMC
>> >>>>>>>>>> vote.
>> >>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
>> >> PMC
>> >>> in
>> >>>>>> the 3
>> >>>>>>>>>>> binding
>> >>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
>> >>> and 1
>> >>>>>> PMC.
>> >>>>>>>>>>>>> I think this makes sense considering a FLIP could
>> >>> somehow
>> >>>>> be a
>> >>>>>>> big
>> >>>>>>>>>>>> feature
>> >>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
>> >>> loss
>> >>>>> of
>> >>>>>>>>>>> flexibility
>> >>>>>>>>>>>>> as committers also have a chance to vote and
>> >> participate
>> >>>> in
>> >>>>>> it.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> ========Seperator========
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> For the nice bylaws, I agree with the general idea and
>> >>>> most
>> >>>>> of
>> >>>>>>> the
>> >>>>>>>>>>>> content.
>> >>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority". The
>> >>>> main
>> >>>>>>>> concern
>> >>>>>>>>>> is
>> >>>>>>>>>>> I
>> >>>>>>>>>>>> am
>> >>>>>>>>>>>>> not sure if it is doable in practice. The reasons are:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
>> >>> committer
>> >>>>> or a
>> >>>>>>> PMC
>> >>>>>>>>>>> member
>> >>>>>>>>>>>>> is active if he or she sends one email to the mailing
>> >>> list
>> >>>>>>> every 6
>> >>>>>>>>>>>> months.
>> >>>>>>>>>>>>> While the minimum length of the vote is only 6 days.
>> >>> There
>> >>>>> are
>> >>>>>>>>>> chances
>> >>>>>>>>>>>> that
>> >>>>>>>>>>>>> during the vote, some of the active members are still
>> >>>>> offline
>> >>>>>> of
>> >>>>>>>> the
>> >>>>>>>>>>>>> community.
>> >>>>>>>>>>>>> 2. The code of Flink is changing fast and not everyone
>> >>>> fully
>> >>>>>>>>>>> understands
>> >>>>>>>>>>>>> every part. We don't need to force people to vote if
>> >>> they
>> >>>>> are
>> >>>>>>> not
>> >>>>>>>>>> sure
>> >>>>>>>>>>>>> about it. It may also make the final result less
>> >>> credible.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Given the above reasons, perhaps we can change the 2/3
>> >>>>>> Majority
>> >>>>>>> to
>> >>>>>>>>>> lazy
>> >>>>>>>>>>>> 2/3
>> >>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
>> >>> higher
>> >>>>>>>> threshold,
>> >>>>>>>>>>>>> however, more practical.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> What do you think?
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
>> >>>>>>> becket.qin@gmail.com
>> >>>>>>>>>
>> >>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Hi Jincheng,
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki page.
>> >>>> Just
>> >>>>> a
>> >>>>>>>> brief
>> >>>>>>>>>>>>> summary,
>> >>>>>>>>>>>>>> the current bylaws do require some of the FLIPs to
>> >> get
>> >>>> PMC
>> >>>>>>>>>> approval
>> >>>>>>>>>>> if
>> >>>>>>>>>>>>>> their impact is big enough. But it leaves majority
>> >> of
>> >>>> the
>> >>>>>>>>>> technical
>> >>>>>>>>>>>>>> decisions to the committers who are supposed to be
>> >>>>>> responsible
>> >>>>>>>> for
>> >>>>>>>>>>>> making
>> >>>>>>>>>>>>>> such decisions.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Re: Robert,
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> I agree we can simply remove the requirement of +1
>> >>> from
>> >>>> a
>> >>>>>>>>>> non-author
>> >>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
>> >> does
>> >>>> not
>> >>>>>> make
>> >>>>>>>>>> sense
>> >>>>>>>>>>> to
>> >>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
>> >>> updated
>> >>>>> the
>> >>>>>>>> bylaws
>> >>>>>>>>>>>> wiki.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Thanks,
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Jiangjie (Becket) Qin
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
>> >>>>>>>>>> rmetzger@apache.org
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Hi all,
>> >>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
>> >>>> current
>> >>>>>>>> status
>> >>>>>>>>>> in
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
>> >> is
>> >>> a
>> >>>>> very
>> >>>>>>>>>> involved
>> >>>>>>>>>>>>> task.
>> >>>>>>>>>>>>>>> Unless there's somebody who's really eager to
>> >> drive
>> >>>>> this,
>> >>>>>> I
>> >>>>>>>>>> would
>> >>>>>>>>>>>> stick
>> >>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
>> >>> Flink,
>> >>>>> even
>> >>>>>>> if
>> >>>>>>>>>> this
>> >>>>>>>>>>>>> means
>> >>>>>>>>>>>>>>> some changes.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> The cross-review requirement is the last big open
>> >>>> point
>> >>>>> in
>> >>>>>>>> this
>> >>>>>>>>>>>>>> discussion.
>> >>>>>>>>>>>>>>> It seems that a there is a slight tendency in the
>> >>>>>> discussion
>> >>>>>>>>>> that
>> >>>>>>>>>>>> this
>> >>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>> not feasible given the current pull request review
>> >>>>>>> situation.
>> >>>>>>>>>>>>>>> For the sake of bringing this discussion to a
>> >>>>> conclusion,
>> >>>>>>> I'm
>> >>>>>>>>>> fine
>> >>>>>>>>>>>> with
>> >>>>>>>>>>>>>>> leaving this requirement out. As we are currently
>> >>>> adding
>> >>>>>>> more
>> >>>>>>>>>>>>> committers
>> >>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>> the project, we might be able to revisit this
>> >>>> discussion
>> >>>>>> in
>> >>>>>>> 3
>> >>>>>>>> -
>> >>>>>>>>>> 6
>> >>>>>>>>>>>>> months.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
>> >>>>>>>>>>>> sunjincheng121@gmail.com
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Hi Becket,
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Thanks for the proposal.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
>> >>>>>> includes a
>> >>>>>>>> PMC
>> >>>>>>>>>>>> vote.
>> >>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
>> >>> the
>> >>>>>> user's
>> >>>>>>>>>>>> interface
>> >>>>>>>>>>>>>>>> changes. What do you think? (I leave the comment
>> >>> in
>> >>>>> the
>> >>>>>>>> wiki.)
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Best,
>> >>>>>>>>>>>>>>>> Jincheng
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
>> >>>>> 于2019年7月17日周三
>> >>>>>>>>>>> 下午9:12写道：
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Hi all,
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
>> >>> that
>> >>>> I
>> >>>>>>> really
>> >>>>>>>>>> like
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> proposed bylaws!
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
>> >>>>>> expressed
>> >>>>>>> by
>> >>>>>>>>>> few
>> >>>>>>>>>>>>> people
>> >>>>>>>>>>>>>>>>> before that the "committer +1" on code change
>> >>>> might
>> >>>>> be
>> >>>>>>>> hard
>> >>>>>>>>>> to
>> >>>>>>>>>>>>>> achieve
>> >>>>>>>>>>>>>>>>> currently. On the other hand I would say this
>> >>>> would
>> >>>>> be
>> >>>>>>>>>>> beneficial
>> >>>>>>>>>>>>> for
>> >>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
>> >>>> knowledge
>> >>>>>>>>>> sharing.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> I was just wondering what should be the next
>> >>> step
>> >>>>> for
>> >>>>>>>> this?
>> >>>>>>>>>> I
>> >>>>>>>>>>>> think
>> >>>>>>>>>>>>>> it
>> >>>>>>>>>>>>>>>>> would make sense to already use those bylaws
>> >> and
>> >>>> put
>> >>>>>>> them
>> >>>>>>>> to
>> >>>>>>>>>>> PMC
>> >>>>>>>>>>>>>> vote.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Best,
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Dawid
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
>> >>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
>> >> think.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
>> >>> If
>> >>>> we
>> >>>>>> are
>> >>>>>>>>>>> stating
>> >>>>>>>>>>>>>> that a
>> >>>>>>>>>>>>>>>>> single
>> >>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
>> >>> review,
>> >>>>>> with 0
>> >>>>>>>>>> hours
>> >>>>>>>>>>>>> delay
>> >>>>>>>>>>>>>>> (de
>> >>>>>>>>>>>>>>>>> facto
>> >>>>>>>>>>>>>>>>>>>> the current state), we should also write
>> >>> down
>> >>>>> that
>> >>>>>>>> this
>> >>>>>>>>>> is
>> >>>>>>>>>>>>>> subject
>> >>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
>> >>> the
>> >>>>>>>>>> components
>> >>>>>>>>>>>>>> expertise
>> >>>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
>> >> facto
>> >>>>>> current
>> >>>>>>>>>>> state).
>> >>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
>> >>>>>>> intention,
>> >>>>>>>>>> but
>> >>>>>>>>>>> it
>> >>>>>>>>>>>>> may
>> >>>>>>>>>>>>>>> be a
>> >>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
>> >>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
>> >>>> rule
>> >>>>>>>> anyway,
>> >>>>>>>>>>>>> intended
>> >>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
>> >>> to
>> >>>>> just
>> >>>>>>>>>> avoid a
>> >>>>>>>>>>>>>>> situation
>> >>>>>>>>>>>>>>>>> when someone violates current uncodified state
>> >>> and
>> >>>>>>> refers
>> >>>>>>>> to
>> >>>>>>>>>>> the
>> >>>>>>>>>>>>>> bylaws
>> >>>>>>>>>>>>>>>>> which are saying merging with any committer +1
>> >>> is
>> >>>>>> always
>> >>>>>>>>>> fine
>> >>>>>>>>>>>> (like
>> >>>>>>>>>>>>>>> mine
>> >>>>>>>>>>>>>>>> +1
>> >>>>>>>>>>>>>>>>> for flink-python or flink-ml).
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Piotrek
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
>> >> <
>> >>>>>>>>>>>> aljoscha@apache.org
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
>> >>> FLIP.
>> >>>>>> This
>> >>>>>>> is
>> >>>>>>>>>> just
>> >>>>>>>>>>>>> about
>> >>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> voting, before that there needs to be the
>> >>>> discussion
>> >>>>>>>>>> thread. If
>> >>>>>>>>>>>>> three
>> >>>>>>>>>>>>>>>> days
>> >>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
>> >>>> (i.e. 3
>> >>>>>>>>>>>>> committers/PMCs
>> >>>>>>>>>>>>>>> have
>> >>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
>> >>> So
>> >>>>> far,
>> >>>>>>> we
>> >>>>>>>>>> have
>> >>>>>>>>>>>>> rarely
>> >>>>>>>>>>>>>>> see
>> >>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
>> >> we
>> >>>> want
>> >>>>>> to
>> >>>>>>>> use
>> >>>>>>>>>>> "lazy
>> >>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
>> >>>> that
>> >>>>>>> should
>> >>>>>>>>>> be
>> >>>>>>>>>>>>> changed
>> >>>>>>>>>>>>>>>> from
>> >>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
>> >>>> current
>> >>>>>>> state
>> >>>>>>>>>> that
>> >>>>>>>>>>>> we
>> >>>>>>>>>>>>>> all
>> >>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
>> >>>> come
>> >>>>> up
>> >>>>>>>> with
>> >>>>>>>>>>>>> something
>> >>>>>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>>>> reflects the common state, according to
>> >>>>>> PMCs/commiters,
>> >>>>>>>> that
>> >>>>>>>>>>>> might
>> >>>>>>>>>>>>>>> take a
>> >>>>>>>>>>>>>>>>> very long time. In that case I think it’s
>> >> better
>> >>>> to
>> >>>>>>> adopt
>> >>>>>>>>>>>> something
>> >>>>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
>> >>> do
>> >>>> it
>> >>>>>>> now.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> Aljoscha
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
>> >> <
>> >>>>>>>>>>>> piotr@ververica.com
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
>> >> speaking
>> >>> +1
>> >>>>>> from
>> >>>>>>> my
>> >>>>>>>>>> side
>> >>>>>>>>>>>> to
>> >>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> general idea and most of the content. I also
>> >> see
>> >>>>> merit
>> >>>>>>> to
>> >>>>>>>>>> the
>> >>>>>>>>>>>>>> Chesney's
>> >>>>>>>>>>>>>>>>> proposal to start from the current state. I
>> >>> think
>> >>>>>> either
>> >>>>>>>>>> would
>> >>>>>>>>>>> be
>> >>>>>>>>>>>>>> fine
>> >>>>>>>>>>>>>>>> for
>> >>>>>>>>>>>>>>>>> me.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Couple of comments:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> 1.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
>> >> another
>> >>>>>>> committer
>> >>>>>>>>>> would
>> >>>>>>>>>>>>> slow
>> >>>>>>>>>>>>>>> down
>> >>>>>>>>>>>>>>>>> and put even more strain on the current
>> >>> reviewing
>> >>>>>>>> bottleneck
>> >>>>>>>>>>> that
>> >>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>> are
>> >>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
>> >>>> context
>> >>>>>>>> switch
>> >>>>>>>>>>> cost
>> >>>>>>>>>>>> is
>> >>>>>>>>>>>>>>> quite
>> >>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
>> >>> second
>> >>>>>>> “cross”
>> >>>>>>>>>>>> committer
>> >>>>>>>>>>>>>>> could
>> >>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
>> >>>> Besides,
>> >>>>>>>> current
>> >>>>>>>>>>> setup
>> >>>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
>> >>>>>> required)
>> >>>>>>>>>> works
>> >>>>>>>>>>>> quite
>> >>>>>>>>>>>>>>> well
>> >>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
>> >>> the
>> >>>>>> other
>> >>>>>>>> hand
>> >>>>>>>>>>>>>> reviewing
>> >>>>>>>>>>>>>>>>> bottleneck is.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> 2.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
>> >> ask
>> >>>>>> another
>> >>>>>>>>>>>> committer
>> >>>>>>>>>>>>>> for
>> >>>>>>>>>>>>>>>>> feedback or not.
>> >>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
>> >>> If
>> >>>> we
>> >>>>>> are
>> >>>>>>>>>>> stating
>> >>>>>>>>>>>>>> that a
>> >>>>>>>>>>>>>>>>> single committers +1 is good enough for code
>> >>>> review,
>> >>>>>>> with
>> >>>>>>>> 0
>> >>>>>>>>>>> hours
>> >>>>>>>>>>>>>> delay
>> >>>>>>>>>>>>>>>> (de
>> >>>>>>>>>>>>>>>>> facto the current state), we should also write
>> >>>> down
>> >>>>>> that
>> >>>>>>>>>> this
>> >>>>>>>>>>> is
>> >>>>>>>>>>>>>>> subject
>> >>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>> the best judgement of the committer to respect
>> >>> the
>> >>>>>>>>>> components
>> >>>>>>>>>>>>>> expertise
>> >>>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
>> >>>> current
>> >>>>>>>> state).
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> 3.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
>> >>>>>> currently
>> >>>>>>>>>> might
>> >>>>>>>>>>> be
>> >>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
>> >>> if
>> >>>>>>>> respected
>> >>>>>>>>>> to
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>> letter.
>> >>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
>> >>>>>>> committers
>> >>>>>>>>>> with
>> >>>>>>>>>>>>>> highest
>> >>>>>>>>>>>>>>>>> expertise in the affected components managed
>> >> to
>> >>>>>> respond
>> >>>>>>> or
>> >>>>>>>>>> not.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Piotrek
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
>> >> Schepler
>> >>> <
>> >>>>>>>>>>>>> chesnay@apache.org>
>> >>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
>> >>>> write
>> >>>>>> down
>> >>>>>>>>>> Bylaws
>> >>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>>>> reflect the current state, and then have
>> >>> separate
>> >>>>>>>>>> discussions
>> >>>>>>>>>>> for
>> >>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
>> >>> this
>> >>>>>>>>>> discussion
>> >>>>>>>>>>>> will
>> >>>>>>>>>>>>>>>> quickly
>> >>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
>> >>>>>> discussed
>> >>>>>>>> at
>> >>>>>>>>>>> once.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
>> >>> Qin
>> >>>> <
>> >>>>>>>>>>>>>>> becket.qin@gmail.com>
>> >>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
>> >> and
>> >>>>>>> feedback.
>> >>>>>>>>>>> Please
>> >>>>>>>>>>>>> see
>> >>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> replies
>> >>>>>>>>>>>>>>>>>>>>>>> below:
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> --------------------------------
>> >>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
>> >> Change"
>> >>> we
>> >>>>>> could
>> >>>>>>>>>> also
>> >>>>>>>>>>>> add a
>> >>>>>>>>>>>>>> row
>> >>>>>>>>>>>>>>>>> for "Code
>> >>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
>> >>> reference
>> >>>> to
>> >>>>>> the
>> >>>>>>>>>> FLIP
>> >>>>>>>>>>>>> process
>> >>>>>>>>>>>>>>>>> page. A
>> >>>>>>>>>>>>>>>>>>>>>>> FLIP
>> >>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
>> >> for
>> >>>>>>> approvals,
>> >>>>>>>>>> etc.
>> >>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> -------------------------------
>> >>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
>> >> currently
>> >>>>>> requires
>> >>>>>>>>>> "one
>> >>>>>>>>>>> +1
>> >>>>>>>>>>>>>> from a
>> >>>>>>>>>>>>>>>>> committer
>> >>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
>> >> followed
>> >>>> by a
>> >>>>>>> Lazy
>> >>>>>>>>>>>> approval
>> >>>>>>>>>>>>>> (not
>> >>>>>>>>>>>>>>>>> counting
>> >>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
>> >> to
>> >>>> lazy
>> >>>>>>>>>> majority
>> >>>>>>>>>>> if
>> >>>>>>>>>>>> a
>> >>>>>>>>>>>>> -1
>> >>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>>>>> received".
>> >>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
>> >>>>>> committer
>> >>>>>>>>>> always
>> >>>>>>>>>>>>>> needs a
>> >>>>>>>>>>>>>>>>> review
>> >>>>>>>>>>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
>> >>>> know
>> >>>>>> this
>> >>>>>>>> is
>> >>>>>>>>>>>>> currently
>> >>>>>>>>>>>>>>> not
>> >>>>>>>>>>>>>>>>> always
>> >>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>> >>>>> contributor
>> >>>>>>>>>> reviews
>> >>>>>>>>>>> &
>> >>>>>>>>>>>>>> +1s).
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
>> >> we
>> >>>> can
>> >>>>>>> make
>> >>>>>>>> it
>> >>>>>>>>>>> easy
>> >>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>> follow the
>> >>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
>> >>> Flink-specific
>> >>>>> Jira
>> >>>>>>>>>>> workflows
>> >>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>> ticket
>> >>>>>>>>>>>>>>>>>>>>>>> types +
>> >>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
>> >> is
>> >>>>>>> certainly
>> >>>>>>>>>>> "Step
>> >>>>>>>>>>>>> 2",
>> >>>>>>>>>>>>>> I
>> >>>>>>>>>>>>>>>>> believe,
>> >>>>>>>>>>>>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
>> >>>> transparent
>> >>>>>> as
>> >>>>>>>>>>> possible,
>> >>>>>>>>>>>>>>>>> otherwise they
>> >>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
>> >>>>>>>>>>>>>>>>>>>>>>> & Re: Till
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
>> >>>> author
>> >>>>>> and
>> >>>>>>>>>>> getting
>> >>>>>>>>>>>> a
>> >>>>>>>>>>>>> +1
>> >>>>>>>>>>>>>>>> from
>> >>>>>>>>>>>>>>>>> a
>> >>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
>> >>> should
>> >>>>> know
>> >>>>>>>> when
>> >>>>>>>>>> to
>> >>>>>>>>>>>> ask
>> >>>>>>>>>>>>>>>> another
>> >>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
>> >> I
>> >>>>> would
>> >>>>>>> not
>> >>>>>>>>>>> enforce
>> >>>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>>>>>>>>>> strictly
>> >>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
>> >> author
>> >>>> is
>> >>>>> a
>> >>>>>>>>>> committer
>> >>>>>>>>>>>> but
>> >>>>>>>>>>>>>> of
>> >>>>>>>>>>>>>>>>> course
>> >>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
>> >>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
>> >> here.
>> >>>>> TBH,
>> >>>>>> in
>> >>>>>>>>>> Kafka
>> >>>>>>>>>>>>>>>> occasionally
>> >>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
>> >> still
>> >>>>>> merged
>> >>>>>>>>>> without
>> >>>>>>>>>>>>>>> following
>> >>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
>> >> rare.
>> >>>>> That
>> >>>>>>>> said,
>> >>>>>>>>>> I
>> >>>>>>>>>>>> still
>> >>>>>>>>>>>>>>> think
>> >>>>>>>>>>>>>>>>> an
>> >>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
>> >> sense
>> >>>> due
>> >>>>>> to
>> >>>>>>>> the
>> >>>>>>>>>>>>> following
>> >>>>>>>>>>>>>>>>> reasons:
>> >>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
>> >>> to
>> >>>>> make
>> >>>>>>>> sure
>> >>>>>>>>>>> every
>> >>>>>>>>>>>>>> patch
>> >>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
>> >>>>> little
>> >>>>>>>>>> difficult
>> >>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>> guarantee if
>> >>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
>> >>>> many
>> >>>>>>>>>> reasons. In
>> >>>>>>>>>>>>> some
>> >>>>>>>>>>>>>>>>> cases, a
>> >>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
>> >> knowledge
>> >>>>> about
>> >>>>>>> the
>> >>>>>>>>>>>> project
>> >>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>> make
>> >>>>>>>>>>>>>>>>> a good
>> >>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
>> >>> contributors
>> >>>>> are
>> >>>>>>> more
>> >>>>>>>>>>>> eagerly
>> >>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>> get a
>> >>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
>> >>> willing
>> >>>>> to
>> >>>>>>>> lower
>> >>>>>>>>>> the
>> >>>>>>>>>>>>>> review
>> >>>>>>>>>>>>>>>> bar.
>> >>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
>> >>> among
>> >>>>>>>>>> committers,
>> >>>>>>>>>>>>> which
>> >>>>>>>>>>>>>> I
>> >>>>>>>>>>>>>>>>> personally
>> >>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
>> >>>> form
>> >>>>>>>>>> consistent
>> >>>>>>>>>>>>> design
>> >>>>>>>>>>>>>>>>> principles
>> >>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
>> >>>>> committers
>> >>>>>>> will
>> >>>>>>>>>> know
>> >>>>>>>>>>>> how
>> >>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> other
>> >>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
>> >>> from
>> >>>>> each
>> >>>>>>>>>> other.
>> >>>>>>>>>>> So
>> >>>>>>>>>>>>> they
>> >>>>>>>>>>>>>>>> tend
>> >>>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
>> >>>> things
>> >>>>>>> should
>> >>>>>>>>>> be
>> >>>>>>>>>>>> done
>> >>>>>>>>>>>>> in
>> >>>>>>>>>>>>>>>>> general.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
>> >>>>> consider
>> >>>>>>> the
>> >>>>>>>>>>>> following
>> >>>>>>>>>>>>>> two
>> >>>>>>>>>>>>>>>>> scenarios:
>> >>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
>> >> a
>> >>>> lot
>> >>>>> of
>> >>>>>>>>>>>> iterations.
>> >>>>>>>>>>>>>> Then
>> >>>>>>>>>>>>>>>>> the patch
>> >>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
>> >>> time
>> >>>>>>> because
>> >>>>>>>>>> there
>> >>>>>>>>>>>> are
>> >>>>>>>>>>>>>>>> things
>> >>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
>> >> changed.
>> >>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
>> >> very
>> >>>>> smooth
>> >>>>>>> and
>> >>>>>>>>>>> quick,
>> >>>>>>>>>>>>> so
>> >>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> patch is
>> >>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
>> >> patch
>> >>>> does
>> >>>>>> not
>> >>>>>>>>>> take
>> >>>>>>>>>>>> much
>> >>>>>>>>>>>>>>> time.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
>> >>> patch
>> >>>>>> from a
>> >>>>>>>>>>>> committer
>> >>>>>>>>>>>>>>> falls
>> >>>>>>>>>>>>>>>>> either in
>> >>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
>> >> is
>> >>>> to
>> >>>>>>> review
>> >>>>>>>>>> the
>> >>>>>>>>>>>>> patch
>> >>>>>>>>>>>>>>>>> because
>> >>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
>> >> needs
>> >>>> to
>> >>>>> be
>> >>>>>>>>>>> reviewed.
>> >>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
>> >>> take
>> >>>>>> much
>> >>>>>>>> time
>> >>>>>>>>>>>>> anyways.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
>> >>>> case
>> >>>>> 1
>> >>>>>> if
>> >>>>>>>> we
>> >>>>>>>>>>> skip
>> >>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> cross-review.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> ------------------------
>> >>>>>>>>>>>>>>>>>>>>>>> Re: Robert
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
>> >>> and
>> >>>>> made
>> >>>>>>> the
>> >>>>>>>>>>>>> following
>> >>>>>>>>>>>>>>>>> modifications
>> >>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
>> >>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
>> >> section.
>> >>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
>> >>> to
>> >>>>>>>>>> "consensus"
>> >>>>>>>>>>> to
>> >>>>>>>>>>>>>> align
>> >>>>>>>>>>>>>>>> with
>> >>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
>> >> and
>> >>>>> other
>> >>>>>>>>>>> projects.
>> >>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> -------------------------
>> >>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
>> >> unnecessary
>> >>>>>> noise.
>> >>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
>> >>> 2/3
>> >>>>>>>> majority
>> >>>>>>>>>> is
>> >>>>>>>>>>>>> still
>> >>>>>>>>>>>>>>>>> feasible in
>> >>>>>>>>>>>>>>>>>>>>>>> practice.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
>> >> the
>> >>>>> draft
>> >>>>>>>>>> compared
>> >>>>>>>>>>> to
>> >>>>>>>>>>>>>>>> existing
>> >>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
>> >>>>>> highlight
>> >>>>>>>>>> these
>> >>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>> discuss
>> >>>>>>>>>>>>>>>>> them
>> >>>>>>>>>>>>>>>>>>>>>>>> one by one.
>> >>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
>> >>>> familiar
>> >>>>>>> enough
>> >>>>>>>>>> with
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> current Flink
>> >>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
>> >> saw
>> >>>> you
>> >>>>>>>>>> commented
>> >>>>>>>>>>> on
>> >>>>>>>>>>>>> some
>> >>>>>>>>>>>>>>>> part
>> >>>>>>>>>>>>>>>>> in the
>> >>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> --------------------------
>> >>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
>> >>>> bylaws?
>> >>>>>> I’m
>> >>>>>>>>>> asking
>> >>>>>>>>>>>>>> because
>> >>>>>>>>>>>>>>> I
>> >>>>>>>>>>>>>>>>> quite
>> >>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
>> >> essentially
>> >>>>>> adopting
>> >>>>>>>> the
>> >>>>>>>>>>>> Kafka
>> >>>>>>>>>>>>>>>> bylaws.
>> >>>>>>>>>>>>>>>>> I
>> >>>>>>>>>>>>>>>>>>>>>>> mean,
>> >>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
>> >>> try
>> >>>>> to
>> >>>>>>>>>> re-invent
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>>>>> wheel
>> >>>>>>>>>>>>>>>>> here.
>> >>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
>> >> version
>> >>>> of
>> >>>>>> the
>> >>>>>>>>>> draft
>> >>>>>>>>>>> was
>> >>>>>>>>>>>>>>> almost
>> >>>>>>>>>>>>>>>>> identical
>> >>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
>> >> caught a
>> >>>> few
>> >>>>>>>>>>> inconsistent
>> >>>>>>>>>>>>>>> places.
>> >>>>>>>>>>>>>>>>> So it
>> >>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
>> >>> make
>> >>>>> sure
>> >>>>>>> we
>> >>>>>>>>>> truly
>> >>>>>>>>>>>>> agree
>> >>>>>>>>>>>>>>> on
>> >>>>>>>>>>>>>>>>> them.
>> >>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
>> >>>>> shortly
>> >>>>>>>> after
>> >>>>>>>>>>>>> adoption.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
>> >> valuable
>> >>>>>>> feedback.
>> >>>>>>>>>> These
>> >>>>>>>>>>>> are
>> >>>>>>>>>>>>>>> great
>> >>>>>>>>>>>>>>>>>>>>>>> discussion.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
>> >> Aljoscha
>> >>>>>> Krettek
>> >>>>>>> <
>> >>>>>>>>>>>>>>>>> aljoscha@apache.org>
>> >>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> Big +1
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
>> >>>> bylaws?
>> >>>>>> I’m
>> >>>>>>>>>> asking
>> >>>>>>>>>>>>>>> because I
>> >>>>>>>>>>>>>>>>> quite
>> >>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
>> >> essentially
>> >>>>>> adopting
>> >>>>>>>> the
>> >>>>>>>>>>>> Kafka
>> >>>>>>>>>>>>>>>> bylaws.
>> >>>>>>>>>>>>>>>>> I
>> >>>>>>>>>>>>>>>>>>>>>>> mean,
>> >>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
>> >>> try
>> >>>>> to
>> >>>>>>>>>> re-invent
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>>>>> wheel
>> >>>>>>>>>>>>>>>>> here.
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
>> >>>>>>> “committer
>> >>>>>>>>>> +1”
>> >>>>>>>>>>>>>>>> requirement.
>> >>>>>>>>>>>>>>>>> We
>> >>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
>> >> would
>> >>>>>> actually
>> >>>>>>>> be
>> >>>>>>>>>> in
>> >>>>>>>>>>>>> favour
>> >>>>>>>>>>>>>>> of
>> >>>>>>>>>>>>>>>>>>>>>>> requiring
>> >>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
>> >>>>>>> complicated.
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
>> >>> Rohrmann
>> >>>> <
>> >>>>>>>>>>>>>>> trohrmann@apache.org>
>> >>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
>> >>>>> Becket.
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
>> >> emeritus
>> >>>> (or
>> >>>>>>> active
>> >>>>>>>>>> vs.
>> >>>>>>>>>>>>>>> inactive),
>> >>>>>>>>>>>>>>>>> it
>> >>>>>>>>>>>>>>>>>>>>>>> won't
>> >>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
>> >> vote
>> >>>>>> because
>> >>>>>>>> we
>> >>>>>>>>>>>> already
>> >>>>>>>>>>>>>>> have
>> >>>>>>>>>>>>>>>>> too
>> >>>>>>>>>>>>>>>>>>>>>>> many
>> >>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
>> >>>>> author
>> >>>>>>> and
>> >>>>>>>>>>>> getting a
>> >>>>>>>>>>>>>> +1
>> >>>>>>>>>>>>>>>>> from a
>> >>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
>> >>> should
>> >>>>>> know
>> >>>>>>>>>> when to
>> >>>>>>>>>>>> ask
>> >>>>>>>>>>>>>>>> another
>> >>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
>> >> Hence, I
>> >>>>> would
>> >>>>>>> not
>> >>>>>>>>>>>> enforce
>> >>>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>>>>>>>>>>> strictly
>> >>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
>> >>> author
>> >>>>> is a
>> >>>>>>>>>>> committer
>> >>>>>>>>>>>>> but
>> >>>>>>>>>>>>>> of
>> >>>>>>>>>>>>>>>>> course
>> >>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
>> >>>>>>>>>>>>>>>>>>>>>>>>> Till
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
>> >> Chesnay
>> >>>>>>> Schepler
>> >>>>>>>> <
>> >>>>>>>>>>>>>>>>> chesnay@apache.org>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
>> >>>> unnecessary
>> >>>>>>> noise.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
>> >>> the
>> >>>>>> draft
>> >>>>>>>>>>> compared
>> >>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>> existing
>> >>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
>> >> to
>> >>>>>>> highlight
>> >>>>>>>>>>> these
>> >>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>> discuss
>> >>>>>>>>>>>>>>>>>>>>>>> them
>> >>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
>> >>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
>> >> this
>> >>>>>>>> discussion
>> >>>>>>>>>> and
>> >>>>>>>>>>>>>>> creating
>> >>>>>>>>>>>>>>>> a
>> >>>>>>>>>>>>>>>>> draft
>> >>>>>>>>>>>>>>>>>>>>>>>> in
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
>> >> that
>> >>> a
>> >>>>>>>> committer
>> >>>>>>>>>>>> always
>> >>>>>>>>>>>>>>> needs
>> >>>>>>>>>>>>>>>> a
>> >>>>>>>>>>>>>>>>>>>>>>> review
>> >>>>>>>>>>>>>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
>> >>> as I
>> >>>>>> know
>> >>>>>>>>>> this is
>> >>>>>>>>>>>>>>> currently
>> >>>>>>>>>>>>>>>>> not
>> >>>>>>>>>>>>>>>>>>>>>>>> always
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>> >>>>>>> contributor
>> >>>>>>>>>>>> reviews
>> >>>>>>>>>>>>> &
>> >>>>>>>>>>>>>>>> +1s).
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
>> >> if
>> >>>> we
>> >>>>>> had
>> >>>>>>>>>> cases
>> >>>>>>>>>>> in
>> >>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>> past
>> >>>>>>>>>>>>>>>>> where
>> >>>>>>>>>>>>>>>>>>>>>>>> code
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
>> >> we
>> >>>>>> believe
>> >>>>>>>>>> that we
>> >>>>>>>>>>>>> have
>> >>>>>>>>>>>>>>>> enough
>> >>>>>>>>>>>>>>>>>>>>>>>> capacity
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
>> >>>>> approval.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
>> >>>>> Konstantin
>> >>>>>>>> Knauf
>> >>>>>>>>>> <
>> >>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
>> >>>> Becket. I
>> >>>>>>> have
>> >>>>>>>>>> two
>> >>>>>>>>>>>>> remarks
>> >>>>>>>>>>>>>>>>> regarding
>> >>>>>>>>>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
>> >>>> Change"
>> >>>>> we
>> >>>>>>>> could
>> >>>>>>>>>>> also
>> >>>>>>>>>>>>>> add a
>> >>>>>>>>>>>>>>>>> row for
>> >>>>>>>>>>>>>>>>>>>>>>>>>> "Code
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
>> >>>>> reference
>> >>>>>> to
>> >>>>>>>> the
>> >>>>>>>>>>> FLIP
>> >>>>>>>>>>>>>>> process
>> >>>>>>>>>>>>>>>>> page.
>> >>>>>>>>>>>>>>>>>>>>>>> A
>> >>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
>> >> rules
>> >>>> for
>> >>>>>>>>>> approvals,
>> >>>>>>>>>>>> etc.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
>> >>>> currently
>> >>>>>>>> requires
>> >>>>>>>>>>> "one
>> >>>>>>>>>>>>> +1
>> >>>>>>>>>>>>>>>> from a
>> >>>>>>>>>>>>>>>>>>>>>>>>>> committer
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
>> >>>> followed
>> >>>>>> by a
>> >>>>>>>>>> Lazy
>> >>>>>>>>>>>>>> approval
>> >>>>>>>>>>>>>>>> (not
>> >>>>>>>>>>>>>>>>>>>>>>>> counting
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
>> >> moving
>> >>>> to
>> >>>>>> lazy
>> >>>>>>>>>>> majority
>> >>>>>>>>>>>>> if
>> >>>>>>>>>>>>>> a
>> >>>>>>>>>>>>>>> -1
>> >>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>>>>>>>> received".
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
>> >>> that a
>> >>>>>>>> committer
>> >>>>>>>>>>>> always
>> >>>>>>>>>>>>>>>> needs a
>> >>>>>>>>>>>>>>>>>>>>>>> review
>> >>>>>>>>>>>>>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
>> >>> as I
>> >>>>>> know
>> >>>>>>>>>> this is
>> >>>>>>>>>>>>>>> currently
>> >>>>>>>>>>>>>>>>> not
>> >>>>>>>>>>>>>>>>>>>>>>>> always
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>> >>>>>>> contributor
>> >>>>>>>>>>>> reviews
>> >>>>>>>>>>>>> &
>> >>>>>>>>>>>>>>>> +1s).
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
>> >>> how
>> >>>>> we
>> >>>>>>> can
>> >>>>>>>>>> make
>> >>>>>>>>>>> it
>> >>>>>>>>>>>>>> easy
>> >>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>> follow
>> >>>>>>>>>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
>> >>>>> Flink-specific
>> >>>>>>> Jira
>> >>>>>>>>>>>>> workflows
>> >>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>> ticket
>> >>>>>>>>>>>>>>>>>>>>>>>>>> types +
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
>> >>> this
>> >>>> is
>> >>>>>>>>>> certainly
>> >>>>>>>>>>>>> "Step
>> >>>>>>>>>>>>>>> 2",
>> >>>>>>>>>>>>>>>> I
>> >>>>>>>>>>>>>>>>>>>>>>>> believe,
>> >>>>>>>>>>>>>>>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
>> >>>>>> transparent
>> >>>>>>>> as
>> >>>>>>>>>>>>> possible,
>> >>>>>>>>>>>>>>>>> otherwise
>> >>>>>>>>>>>>>>>>>>>>>>>> they
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
>> >>> Becket
>> >>>>>> Qin <
>> >>>>>>>>>>>>>>>>> becket.qin@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
>> >>> process
>> >>>>>>>> discussion
>> >>>>>>>>>>>> thread
>> >>>>>>>>>>>>>>> [1],
>> >>>>>>>>>>>>>>>>>>>>>>> currently
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
>> >>>> govern
>> >>>>>> the
>> >>>>>>>>>>>> operation
>> >>>>>>>>>>>>> of
>> >>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>>>>>> project.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
>> >>> community
>> >>>>> to
>> >>>>>>>>>>> coordinate
>> >>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>> contribute
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
>> >>>> other
>> >>>>>>>>>> processes
>> >>>>>>>>>>>> such
>> >>>>>>>>>>>>>> as
>> >>>>>>>>>>>>>>>>> FLIP.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
>> >> page
>> >>>> and
>> >>>>>>> would
>> >>>>>>>>>> like
>> >>>>>>>>>>> to
>> >>>>>>>>>>>>>>> start a
>> >>>>>>>>>>>>>>>>>>>>>>>> discussion
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
>> >> in
>> >>>> the
>> >>>>>>>>>> community.
>> >>>>>>>>>>>>> It'll
>> >>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>>> great to
>> >>>>>>>>>>>>>>>>>>>>>>>>>> hear
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
>> >>> Architect
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
>> >>>>> 31.08.2019,
>> >>>>>>>>>> 05.09. -
>> >>>>>>>>>>>>>>>> 06.09.2010
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
>> >>> 115,
>> >>>>>> 10115
>> >>>>>>>>>>> Berlin,
>> >>>>>>>>>>>>>>> Germany
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
>> >>>>> Charlottenburg:
>> >>>>>>> HRB
>> >>>>>>>>>>> 158244
>> >>>>>>>>>>>> B
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
>> >>>> Tzoumas,
>> >>>>>> Dr.
>> >>>>>>>>>> Stephan
>> >>>>>>>>>>>>> Ewen
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>

Re: [DISCUSS] Flink project bylaws

[Becket Qin <be...@gmail.com>]

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 <mx...@apache.org> wrote:

> I'm a bit late to the discussion here. Three suggestions:
>
> 1) Procedure for "insufficient active binding voters to reach 2/3 majority
>
> >     1. Wait until the minimum length of the voting passes.
> >     2. Publicly reach out to the remaining binding voters in the voting
> mail thread for at least 2 attempts with at least 7 days between two
> attempts.
> >     3. If the binding voter being contacted still failed to respond
> after all the attempts, the binding voter will be considered as inactive
> for the purpose of this particular voting.
>
> Step 2 should include a personal email to the PMC members in question.
> I'm afraid reminders inside the vote thread could be overlooked easily.
>
> 2) "Consensus" => "Lazy Consensus"
>
> The way the terms are described in the draft, the consensus is "lazy",
> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy
> Consensus". This is in line with the other definitions such as "Lazy
> Majority".
>
> 3) Committer / PMC Removal
>
> Removing a committer / PMC member only requires 3 binding votes. I'd
> expect an important action like this to require a 2/3 majority.
>
>
> Do you think we could incorporate those suggestions?
>
> Thanks,
> Max
>
> On 11.08.19 10:14, Becket Qin wrote:
> > Hi folks,
> >
> > Thanks for all the discussion and support. I have started the voting
> thread.
> >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <fh...@gmail.com> wrote:
> >
> >> Thanks for the update and driving the discussion Becket!
> >> +1 for starting a vote.
> >>
> >> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
> becket.qin@gmail.com
> >>> :
> >>
> >>> Thanks Stephan.
> >>>
> >>> I think we have resolved all the comments on the wiki page. There are
> two
> >>> minor changes made to the bylaws since last week.
> >>> 1. For 2/3 majority, the required attempts to reach out to binding
> voters
> >>> is reduced from 3 to 2. This helps shorten the voting process a little
> >> bit.
> >>> 2. Clarified what is considered as the adoption of new codebase.
> >>>
> >>> I think we almost reached consensus. I'll start a voting thread in two
> >> days
> >>> if there is no new concerns.
> >>>
> >>> Thanks,
> >>>
> >>> Jiangjie (Becket) Qin
> >>>
> >>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org> wrote:
> >>>
> >>>> I added a clarification to the table, clarifying that the current
> >>> phrasing
> >>>> means that committers do not need another +1 for their commits.
> >>>>
> >>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fh...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Hi Becket,
> >>>>>
> >>>>> Thanks a lot for pushing this forward and addressing the feedback.
> >>>>> I'm very happy with the current state of the bylaws.
> >>>>> +1 to wait until Friday before starting a vote.
> >>>>>
> >>>>> Best, Fabian
> >>>>>
> >>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> >>>>> becket.qin@gmail.com
> >>>>>> :
> >>>>>
> >>>>>> Hi Everyone,
> >>>>>>
> >>>>>> Thanks for all the discussion and feedback.
> >>>>>>
> >>>>>> It seems that we have almost reached consensus. I'll leave the
> >>>> discussion
> >>>>>> thread open until this Friday. If there is no more concerns raised,
> >>>> I'll
> >>>>>> start a voting thread after that.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Jiangjie (Becket) Qin
> >>>>>>
> >>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com> wrote:
> >>>>>>
> >>>>>>> Hi Becket,
> >>>>>>>
> >>>>>>> Thanks for noticing and resolving my comment around PMC removal
> >> and
> >>>> ASF
> >>>>>>> rules of PMC membership change process, which you seem to neglect
> >>> in
> >>>>> the
> >>>>>>> summary of updates (smile).
> >>>>>>>
> >>>>>>> Best Regards,
> >>>>>>> Yu
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <be...@gmail.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> Hi folks,
> >>>>>>>>
> >>>>>>>> Thanks for all the feedback.
> >>>>>>>>
> >>>>>>>> It seems that there are a few concerns over the emeritus status
> >>>>> after 6
> >>>>>>>> months of inactivity. Given that the main purpose is just to
> >> make
> >>>>> sure
> >>>>>>> 2/3
> >>>>>>>> majority can pass and we sort of have a solution for that, I
> >> just
> >>>>>> updated
> >>>>>>>> the draft with the following changes:
> >>>>>>>>
> >>>>>>>> 1. Removed the inactivity term for emeritus committers / PMCs.
> >> A
> >>>>>>> committer
> >>>>>>>> / PMC will only be considered emeritus by their own claim.
> >>>>>>>> 2. Removed the approval process for reinstatement of the
> >> emeritus
> >>>>>>>> committers / PMCs. An emeritus committer / PMC will be
> >> reinstated
> >>>>> when
> >>>>>>> they
> >>>>>>>> send an email to the private@flink.apache.org.
> >>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still doable
> >>> when
> >>>>>> there
> >>>>>>>> are non-emeritus committers / PMCs who do not cast the vote.
> >>>>>>>>
> >>>>>>>> Please let me know if you have any further thoughts.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>
> >>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
> >>> becket.qin@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Fabian,
> >>>>>>>>>
> >>>>>>>>> Thanks for the feedback.
> >>>>>>>>>
> >>>>>>>>> I agree that if we don't like emeritus committers / PMCs, we
> >>>> don't
> >>>>>> have
> >>>>>>>> to
> >>>>>>>>> do it. That said, emeritus status simply means whether an
> >>>>> individual
> >>>>>> is
> >>>>>>>>> active / inactive in the community. It does not make the
> >> merits
> >>>>>> earned
> >>>>>>> to
> >>>>>>>>> go away. For our purpose, emeritus status is mostly just a
> >> way
> >>> to
> >>>>>> make
> >>>>>>>> 2/3
> >>>>>>>>> majority possible. As you noticed, since reaching out to
> >>> binding
> >>>>>> voters
> >>>>>>>> who
> >>>>>>>>> have not voted can achieve the same goal, the emeritus status
> >>> is
> >>>>> more
> >>>>>>> of
> >>>>>>>> an
> >>>>>>>>> optimization so we don't have to ping the inactive binding
> >>> voters
> >>>>>> every
> >>>>>>>>> time and wait for long. However, given that 2/3 majority
> >>> votings
> >>>>> are
> >>>>>>>> rare,
> >>>>>>>>> such communication cost is probably OK. So I think we can
> >>> remove
> >>>>> that
> >>>>>>>>> emeritus part from the bylaws.
> >>>>>>>>>
> >>>>>>>>> 1) We should add to the requirements of the PMC that they
> >> need
> >>> to
> >>>>>> make
> >>>>>>>>>> sure the project complies with brand issues and reports
> >> misuse
> >>>> of
> >>>>>> ASF
> >>>>>>>>>> brands.
> >>>>>>>>>
> >>>>>>>>> Good point. Added.
> >>>>>>>>>
> >>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
> >> a
> >>> 3
> >>>>> day
> >>>>>>> vote
> >>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
> >>>>>>>>>
> >>>>>>>>> This might be a little tricky because people are from
> >> countries
> >>>> in
> >>>>>>>>> different time zones and with different holidays, and so on.
> >> If
> >>>> we
> >>>>>> are
> >>>>>>>>> worrying about 3 days minimum length is not enough for those
> >>> who
> >>>>> want
> >>>>>>> to
> >>>>>>>>> give feedback, we can make it 5 days.
> >>>>>>>>>
> >>>>>>>>> 3) Do we need a process do decide about removal of features
> >>> (like
> >>>>> the
> >>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
> >>> Python
> >>>>>>> APIs)?
> >>>>>>>>>
> >>>>>>>>> I assume such action should be covered by FLIP as it is a
> >>> change
> >>>> to
> >>>>>> the
> >>>>>>>>> API and probably needs a migration plan. It would be useful
> >> to
> >>>>> have a
> >>>>>>>>> formal deprecation procedure. But that might be better to be
> >>> put
> >>>>> into
> >>>>>>>>> somewhere else because the bylaws are primarily focusing on
> >> the
> >>>>>>>>> non-technical rules, whereas the deprecation seems more on
> >> the
> >>>>>>> technical
> >>>>>>>>> side.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>
> >>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
> >>>> fhueske@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi all,
> >>>>>>>>>>
> >>>>>>>>>> First of all thank you very much Becket for starting this
> >>>>>> discussion!
> >>>>>>>>>> I think it is a very good idea and overdue to formally
> >> define
> >>>> some
> >>>>>> of
> >>>>>>>> our
> >>>>>>>>>> community processes.
> >>>>>>>>>>
> >>>>>>>>>> Similar to Chesnay, I have concerns about the distinction
> >>>> between
> >>>>>>> active
> >>>>>>>>>> and non-active / emeritus committers and PMC members.
> >>>>>>>>>> My foremost concern is that this is not in the spirit of the
> >>>>> Apache
> >>>>>>> Way
> >>>>>>>>>> [1]
> >>>>>>>>>> which is (among other things) based on the idea of merit
> >> which
> >>>>> once
> >>>>>>>>>> earned,
> >>>>>>>>>> does not go away over time.
> >>>>>>>>>> I know other projects like Hadoop and Kafka have similar
> >>> clauses
> >>>>> in
> >>>>>>> the
> >>>>>>>>>> bylaws but IMO we don't need to adopt them if we don't like
> >>>> them.
> >>>>>>>>>> For example, I don't like the idea that committers or PMC
> >>>> members
> >>>>>> who
> >>>>>>>> are
> >>>>>>>>>> temporarily away from the project (for whatever reason:
> >>> parental
> >>>>>>> leave,
> >>>>>>>>>> sabbatical, health issues, etc.) need the PMC approval to be
> >>>>>> "active"
> >>>>>>>>>> again.
> >>>>>>>>>> As far as I am aware, we have not seen any issues with
> >>> inactive
> >>>>>>> members
> >>>>>>>> in
> >>>>>>>>>> the past.
> >>>>>>>>>> Moreover, it would be hard to track whether somebody became
> >>>>> inactive
> >>>>>>> at
> >>>>>>>>>> some point in time (which we would need to do, if I
> >> understand
> >>>> the
> >>>>>>>>>> proposal
> >>>>>>>>>> correctly).
> >>>>>>>>>> With the approach that Becket suggested in his last email
> >>>>> (reaching
> >>>>>>> out
> >>>>>>>> to
> >>>>>>>>>> binding voters who haven't voted yet), we could drop the
> >>>>> distinction
> >>>>>>>>>> between active and non-active committers and PMC members.
> >>>>>>>>>>
> >>>>>>>>>> I also have a few minor comments:
> >>>>>>>>>>
> >>>>>>>>>> 1) We should add to the requirements of the PMC [2] that
> >> they
> >>>> need
> >>>>>> to
> >>>>>>>> make
> >>>>>>>>>> sure the project complies with brand issues and reports
> >> misuse
> >>>> of
> >>>>>> ASF
> >>>>>>>>>> brands.
> >>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
> >>> a 3
> >>>>> day
> >>>>>>>> vote
> >>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
> >>>>>>>>>> 3) Do we need a process do decide about removal of features
> >>>> (like
> >>>>>> the
> >>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
> >>> Python
> >>>>>>> APIs)?
> >>>>>>>>>>
> >>>>>>>>>> Thank you,
> >>>>>>>>>> Fabian
> >>>>>>>>>>
> >>>>>>>>>> [1] https://www.apache.org/theapacheway/
> >>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
> >>>>>>>>>>
> >>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> >>>>>>>>>> becket.qin@gmail.com
> >>>>>>>>>>> :
> >>>>>>>>>>
> >>>>>>>>>>> Hi Hequn,
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for sharing your thoughts. Please see the reply
> >>> below:
> >>>>>>>>>>>
> >>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one PMC
> >> in
> >>>>> the 3
> >>>>>>>>>> binding
> >>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> >> and 1
> >>>>> PMC.
> >>>>>>>>>>>> I think this makes sense considering a FLIP could
> >> somehow
> >>>> be a
> >>>>>> big
> >>>>>>>>>>> feature
> >>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
> >> loss
> >>>> of
> >>>>>>>>>> flexibility
> >>>>>>>>>>>> as committers also have a chance to vote and participate
> >>> in
> >>>>> it.
> >>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs are
> >> the
> >>>>>>> following:
> >>>>>>>>>>>
> >>>>>>>>>>> 1. Generally speaking, the PMC's primary responsibility is
> >>>>>> operating
> >>>>>>>> the
> >>>>>>>>>>> project and deciding what software to release on behalf of
> >>>> ASF.
> >>>>>>>>>> Committers,
> >>>>>>>>>>> on the other hand, are responsible for the technical part
> >> of
> >>>> the
> >>>>>>>>>> project.
> >>>>>>>>>>> So for FLIPs, a PMC's vote probably should not outweigh a
> >>>>>>> committer's
> >>>>>>>>>> vote.
> >>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is really
> >>>>>> convincing
> >>>>>>>>>> enough
> >>>>>>>>>>> to decide whether the FLIP is good to go or not. Also, if
> >>> some
> >>>>>>>>>> committers
> >>>>>>>>>>> have concern over a FLIP, they could just veto it. To me
> >> it
> >>> is
> >>>>>>>> actually
> >>>>>>>>>> a
> >>>>>>>>>>> more strict requirement to pass a FLIP than asking a PMC
> >> to
> >>>>> vote.
> >>>>>> In
> >>>>>>>>>>> practice, people will usually also address the concerns
> >> even
> >>>> if
> >>>>>> they
> >>>>>>>> are
> >>>>>>>>>>> not from a PMC/committer before they start the voting
> >>> process.
> >>>>> So
> >>>>>> I
> >>>>>>>>>> don't
> >>>>>>>>>>> see much benefit of requiring a PMC's vote in this case.
> >>>>>>>>>>>
> >>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the votes
> >> no
> >>>>> longer
> >>>>>>>>>>> independent. Ideally, a vote is either binding or
> >>> non-binding
> >>>> by
> >>>>>>>>>> itself. If
> >>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
> >> imagine
> >>>>> there
> >>>>>>> have
> >>>>>>>>>> been
> >>>>>>>>>>> 3 committers who voted +1. But the FLIP still has not
> >>> passed,
> >>>> so
> >>>>>>> those
> >>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a +1,
> >>> those
> >>>>>> votes
> >>>>>>>>>>> suddenly become binding, which is a little awkward.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable to me.
> >>> Some
> >>>>>>>> thoughts
> >>>>>>>>>> on
> >>>>>>>>>>> this:
> >>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is probably
> >>>> because
> >>>>>>> there
> >>>>>>>>>> are
> >>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3 majority
> >>>>>>>> prohibitively
> >>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
> >> Flink[2]
> >>>> and
> >>>>> a
> >>>>>>>> quick
> >>>>>>>>>>> search shows at most 6 of them have not sent email in the
> >>>>> recent 6
> >>>>>>>>>> months
> >>>>>>>>>>> or so.
> >>>>>>>>>>>
> >>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare. It is
> >>>>> designed
> >>>>>>> in
> >>>>>>>>>>> particular for the cases that broad opinions are
> >> important,
> >>>> more
> >>>>>>>>>>> specifically new codebase adoption or modification to the
> >>>>> bylaws.
> >>>>>>>>>> Therefore
> >>>>>>>>>>> such vote by its nature favors consensus over convenience.
> >>>> That
> >>>>>>> means
> >>>>>>>>>> any
> >>>>>>>>>>> alternative voting type reducing the coverage worth a
> >>> careful
> >>>>>>>> thinking.
> >>>>>>>>>>>
> >>>>>>>>>>> 3. I do agree that it does not make sense to have 2/3
> >>> majority
> >>>>> if
> >>>>>>> such
> >>>>>>>>>>> requirement is no-longer doable over time. But I am a
> >> little
> >>>>>>> hesitant
> >>>>>>>> to
> >>>>>>>>>>> lower the threshold to lazy 2/3 majority in our case. What
> >>> do
> >>>>> you
> >>>>>>>> think
> >>>>>>>>>>> about doing the following:
> >>>>>>>>>>>     - After the voting started, there will be at least 6
> >>> days
> >>>>> for
> >>>>>>>>>> people to
> >>>>>>>>>>> cast their votes.
> >>>>>>>>>>>     - After 6 days, if the result of the vote is still not
> >>>>>>> determined,
> >>>>>>>>>> the
> >>>>>>>>>>> person who started the vote should reach out to the
> >> binding
> >>>>> voters
> >>>>>>> who
> >>>>>>>>>> have
> >>>>>>>>>>> not voted yet for at least 3 times and at least 7 days
> >>> between
> >>>>>> each
> >>>>>>>>>> time.
> >>>>>>>>>>> If a binding voter still did not respond, the vote from
> >> that
> >>>>> voter
> >>>>>>>> will
> >>>>>>>>>> be
> >>>>>>>>>>> excluded from the 2/3 majority counting.
> >>>>>>>>>>> This would ensure the coverage at our best effort while
> >>> still
> >>>>> let
> >>>>>>> the
> >>>>>>>>>> 2/3
> >>>>>>>>>>> majority vote make progress.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> [1] https://projects.apache.org/committee.html?hadoop
> >>>>>>>>>>> [2] https://projects.apache.org/committee.html?flink
> >>>>>>>>>>>
> >>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> >>>>>> forwardxu315@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Big +1 on this.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> best
> >>>>>>>>>>>>
> >>>>>>>>>>>> forward
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
> >>> 下午1:30写道：
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Becket,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Big +1 on this.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> >>>> includes a
> >>>>>> PMC
> >>>>>>>>>> vote.
> >>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
> >> PMC
> >>> in
> >>>>>> the 3
> >>>>>>>>>>> binding
> >>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
> >>> and 1
> >>>>>> PMC.
> >>>>>>>>>>>>> I think this makes sense considering a FLIP could
> >>> somehow
> >>>>> be a
> >>>>>>> big
> >>>>>>>>>>>> feature
> >>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
> >>> loss
> >>>>> of
> >>>>>>>>>>> flexibility
> >>>>>>>>>>>>> as committers also have a chance to vote and
> >> participate
> >>>> in
> >>>>>> it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ========Seperator========
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For the nice bylaws, I agree with the general idea and
> >>>> most
> >>>>> of
> >>>>>>> the
> >>>>>>>>>>>> content.
> >>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority". The
> >>>> main
> >>>>>>>> concern
> >>>>>>>>>> is
> >>>>>>>>>>> I
> >>>>>>>>>>>> am
> >>>>>>>>>>>>> not sure if it is doable in practice. The reasons are:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
> >>> committer
> >>>>> or a
> >>>>>>> PMC
> >>>>>>>>>>> member
> >>>>>>>>>>>>> is active if he or she sends one email to the mailing
> >>> list
> >>>>>>> every 6
> >>>>>>>>>>>> months.
> >>>>>>>>>>>>> While the minimum length of the vote is only 6 days.
> >>> There
> >>>>> are
> >>>>>>>>>> chances
> >>>>>>>>>>>> that
> >>>>>>>>>>>>> during the vote, some of the active members are still
> >>>>> offline
> >>>>>> of
> >>>>>>>> the
> >>>>>>>>>>>>> community.
> >>>>>>>>>>>>> 2. The code of Flink is changing fast and not everyone
> >>>> fully
> >>>>>>>>>>> understands
> >>>>>>>>>>>>> every part. We don't need to force people to vote if
> >>> they
> >>>>> are
> >>>>>>> not
> >>>>>>>>>> sure
> >>>>>>>>>>>>> about it. It may also make the final result less
> >>> credible.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Given the above reasons, perhaps we can change the 2/3
> >>>>>> Majority
> >>>>>>> to
> >>>>>>>>>> lazy
> >>>>>>>>>>>> 2/3
> >>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
> >>> higher
> >>>>>>>> threshold,
> >>>>>>>>>>>>> however, more practical.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> What do you think?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> >>>>>>> becket.qin@gmail.com
> >>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Jincheng,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki page.
> >>>> Just
> >>>>> a
> >>>>>>>> brief
> >>>>>>>>>>>>> summary,
> >>>>>>>>>>>>>> the current bylaws do require some of the FLIPs to
> >> get
> >>>> PMC
> >>>>>>>>>> approval
> >>>>>>>>>>> if
> >>>>>>>>>>>>>> their impact is big enough. But it leaves majority
> >> of
> >>>> the
> >>>>>>>>>> technical
> >>>>>>>>>>>>>> decisions to the committers who are supposed to be
> >>>>>> responsible
> >>>>>>>> for
> >>>>>>>>>>>> making
> >>>>>>>>>>>>>> such decisions.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Re: Robert,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I agree we can simply remove the requirement of +1
> >>> from
> >>>> a
> >>>>>>>>>> non-author
> >>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
> >> does
> >>>> not
> >>>>>> make
> >>>>>>>>>> sense
> >>>>>>>>>>> to
> >>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
> >>> updated
> >>>>> the
> >>>>>>>> bylaws
> >>>>>>>>>>>> wiki.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> >>>>>>>>>> rmetzger@apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
> >>>> current
> >>>>>>>> status
> >>>>>>>>>> in
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
> >> is
> >>> a
> >>>>> very
> >>>>>>>>>> involved
> >>>>>>>>>>>>> task.
> >>>>>>>>>>>>>>> Unless there's somebody who's really eager to
> >> drive
> >>>>> this,
> >>>>>> I
> >>>>>>>>>> would
> >>>>>>>>>>>> stick
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
> >>> Flink,
> >>>>> even
> >>>>>>> if
> >>>>>>>>>> this
> >>>>>>>>>>>>> means
> >>>>>>>>>>>>>>> some changes.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The cross-review requirement is the last big open
> >>>> point
> >>>>> in
> >>>>>>>> this
> >>>>>>>>>>>>>> discussion.
> >>>>>>>>>>>>>>> It seems that a there is a slight tendency in the
> >>>>>> discussion
> >>>>>>>>>> that
> >>>>>>>>>>>> this
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>>>> not feasible given the current pull request review
> >>>>>>> situation.
> >>>>>>>>>>>>>>> For the sake of bringing this discussion to a
> >>>>> conclusion,
> >>>>>>> I'm
> >>>>>>>>>> fine
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>>> leaving this requirement out. As we are currently
> >>>> adding
> >>>>>>> more
> >>>>>>>>>>>>> committers
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> the project, we might be able to revisit this
> >>>> discussion
> >>>>>> in
> >>>>>>> 3
> >>>>>>>> -
> >>>>>>>>>> 6
> >>>>>>>>>>>>> months.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> >>>>>>>>>>>> sunjincheng121@gmail.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi Becket,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks for the proposal.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
> >>>>>> includes a
> >>>>>>>> PMC
> >>>>>>>>>>>> vote.
> >>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
> >>> the
> >>>>>> user's
> >>>>>>>>>>>> interface
> >>>>>>>>>>>>>>>> changes. What do you think? (I leave the comment
> >>> in
> >>>>> the
> >>>>>>>> wiki.)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>> Jincheng
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
> >>>>> 于2019年7月17日周三
> >>>>>>>>>>> 下午9:12写道：
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
> >>> that
> >>>> I
> >>>>>>> really
> >>>>>>>>>> like
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> proposed bylaws!
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
> >>>>>> expressed
> >>>>>>> by
> >>>>>>>>>> few
> >>>>>>>>>>>>> people
> >>>>>>>>>>>>>>>>> before that the "committer +1" on code change
> >>>> might
> >>>>> be
> >>>>>>>> hard
> >>>>>>>>>> to
> >>>>>>>>>>>>>> achieve
> >>>>>>>>>>>>>>>>> currently. On the other hand I would say this
> >>>> would
> >>>>> be
> >>>>>>>>>>> beneficial
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
> >>>> knowledge
> >>>>>>>>>> sharing.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I was just wondering what should be the next
> >>> step
> >>>>> for
> >>>>>>>> this?
> >>>>>>>>>> I
> >>>>>>>>>>>> think
> >>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>> would make sense to already use those bylaws
> >> and
> >>>> put
> >>>>>>> them
> >>>>>>>> to
> >>>>>>>>>>> PMC
> >>>>>>>>>>>>>> vote.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Dawid
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
> >>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
> >> think.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> >>> If
> >>>> we
> >>>>>> are
> >>>>>>>>>>> stating
> >>>>>>>>>>>>>> that a
> >>>>>>>>>>>>>>>>> single
> >>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
> >>> review,
> >>>>>> with 0
> >>>>>>>>>> hours
> >>>>>>>>>>>>> delay
> >>>>>>>>>>>>>>> (de
> >>>>>>>>>>>>>>>>> facto
> >>>>>>>>>>>>>>>>>>>> the current state), we should also write
> >>> down
> >>>>> that
> >>>>>>>> this
> >>>>>>>>>> is
> >>>>>>>>>>>>>> subject
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
> >>> the
> >>>>>>>>>> components
> >>>>>>>>>>>>>> expertise
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
> >> facto
> >>>>>> current
> >>>>>>>>>>> state).
> >>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
> >>>>>>> intention,
> >>>>>>>>>> but
> >>>>>>>>>>> it
> >>>>>>>>>>>>> may
> >>>>>>>>>>>>>>> be a
> >>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
> >>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
> >>>> rule
> >>>>>>>> anyway,
> >>>>>>>>>>>>> intended
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
> >>> to
> >>>>> just
> >>>>>>>>>> avoid a
> >>>>>>>>>>>>>>> situation
> >>>>>>>>>>>>>>>>> when someone violates current uncodified state
> >>> and
> >>>>>>> refers
> >>>>>>>> to
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> bylaws
> >>>>>>>>>>>>>>>>> which are saying merging with any committer +1
> >>> is
> >>>>>> always
> >>>>>>>>>> fine
> >>>>>>>>>>>> (like
> >>>>>>>>>>>>>>> mine
> >>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>> for flink-python or flink-ml).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Piotrek
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
> >> <
> >>>>>>>>>>>> aljoscha@apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
> >>> FLIP.
> >>>>>> This
> >>>>>>> is
> >>>>>>>>>> just
> >>>>>>>>>>>>> about
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> voting, before that there needs to be the
> >>>> discussion
> >>>>>>>>>> thread. If
> >>>>>>>>>>>>> three
> >>>>>>>>>>>>>>>> days
> >>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
> >>>> (i.e. 3
> >>>>>>>>>>>>> committers/PMCs
> >>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
> >>> So
> >>>>> far,
> >>>>>>> we
> >>>>>>>>>> have
> >>>>>>>>>>>>> rarely
> >>>>>>>>>>>>>>> see
> >>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
> >> we
> >>>> want
> >>>>>> to
> >>>>>>>> use
> >>>>>>>>>>> "lazy
> >>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
> >>>> that
> >>>>>>> should
> >>>>>>>>>> be
> >>>>>>>>>>>>> changed
> >>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
> >>>> current
> >>>>>>> state
> >>>>>>>>>> that
> >>>>>>>>>>>> we
> >>>>>>>>>>>>>> all
> >>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
> >>>> come
> >>>>> up
> >>>>>>>> with
> >>>>>>>>>>>>> something
> >>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>> reflects the common state, according to
> >>>>>> PMCs/commiters,
> >>>>>>>> that
> >>>>>>>>>>>> might
> >>>>>>>>>>>>>>> take a
> >>>>>>>>>>>>>>>>> very long time. In that case I think it’s
> >> better
> >>>> to
> >>>>>>> adopt
> >>>>>>>>>>>> something
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
> >>> do
> >>>> it
> >>>>>>> now.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Aljoscha
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
> >> <
> >>>>>>>>>>>> piotr@ververica.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
> >> speaking
> >>> +1
> >>>>>> from
> >>>>>>> my
> >>>>>>>>>> side
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> general idea and most of the content. I also
> >> see
> >>>>> merit
> >>>>>>> to
> >>>>>>>>>> the
> >>>>>>>>>>>>>> Chesney's
> >>>>>>>>>>>>>>>>> proposal to start from the current state. I
> >>> think
> >>>>>> either
> >>>>>>>>>> would
> >>>>>>>>>>> be
> >>>>>>>>>>>>>> fine
> >>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>> me.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Couple of comments:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
> >> another
> >>>>>>> committer
> >>>>>>>>>> would
> >>>>>>>>>>>>> slow
> >>>>>>>>>>>>>>> down
> >>>>>>>>>>>>>>>>> and put even more strain on the current
> >>> reviewing
> >>>>>>>> bottleneck
> >>>>>>>>>>> that
> >>>>>>>>>>>>> we
> >>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
> >>>> context
> >>>>>>>> switch
> >>>>>>>>>>> cost
> >>>>>>>>>>>> is
> >>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
> >>> second
> >>>>>>> “cross”
> >>>>>>>>>>>> committer
> >>>>>>>>>>>>>>> could
> >>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
> >>>> Besides,
> >>>>>>>> current
> >>>>>>>>>>> setup
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
> >>>>>> required)
> >>>>>>>>>> works
> >>>>>>>>>>>> quite
> >>>>>>>>>>>>>>> well
> >>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
> >>> the
> >>>>>> other
> >>>>>>>> hand
> >>>>>>>>>>>>>> reviewing
> >>>>>>>>>>>>>>>>> bottleneck is.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 2.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
> >> ask
> >>>>>> another
> >>>>>>>>>>>> committer
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>> feedback or not.
> >>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
> >>> If
> >>>> we
> >>>>>> are
> >>>>>>>>>>> stating
> >>>>>>>>>>>>>> that a
> >>>>>>>>>>>>>>>>> single committers +1 is good enough for code
> >>>> review,
> >>>>>>> with
> >>>>>>>> 0
> >>>>>>>>>>> hours
> >>>>>>>>>>>>>> delay
> >>>>>>>>>>>>>>>> (de
> >>>>>>>>>>>>>>>>> facto the current state), we should also write
> >>>> down
> >>>>>> that
> >>>>>>>>>> this
> >>>>>>>>>>> is
> >>>>>>>>>>>>>>> subject
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> the best judgement of the committer to respect
> >>> the
> >>>>>>>>>> components
> >>>>>>>>>>>>>> expertise
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
> >>>> current
> >>>>>>>> state).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 3.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
> >>>>>> currently
> >>>>>>>>>> might
> >>>>>>>>>>> be
> >>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
> >>> if
> >>>>>>>> respected
> >>>>>>>>>> to
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> letter.
> >>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
> >>>>>>> committers
> >>>>>>>>>> with
> >>>>>>>>>>>>>> highest
> >>>>>>>>>>>>>>>>> expertise in the affected components managed
> >> to
> >>>>>> respond
> >>>>>>> or
> >>>>>>>>>> not.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Piotrek
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
> >> Schepler
> >>> <
> >>>>>>>>>>>>> chesnay@apache.org>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
> >>>> write
> >>>>>> down
> >>>>>>>>>> Bylaws
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>> reflect the current state, and then have
> >>> separate
> >>>>>>>>>> discussions
> >>>>>>>>>>> for
> >>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
> >>> this
> >>>>>>>>>> discussion
> >>>>>>>>>>>> will
> >>>>>>>>>>>>>>>> quickly
> >>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
> >>>>>> discussed
> >>>>>>>> at
> >>>>>>>>>>> once.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
> >>> Qin
> >>>> <
> >>>>>>>>>>>>>>> becket.qin@gmail.com>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
> >> and
> >>>>>>> feedback.
> >>>>>>>>>>> Please
> >>>>>>>>>>>>> see
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> replies
> >>>>>>>>>>>>>>>>>>>>>>> below:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> --------------------------------
> >>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> >> Change"
> >>> we
> >>>>>> could
> >>>>>>>>>> also
> >>>>>>>>>>>> add a
> >>>>>>>>>>>>>> row
> >>>>>>>>>>>>>>>>> for "Code
> >>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> >>> reference
> >>>> to
> >>>>>> the
> >>>>>>>>>> FLIP
> >>>>>>>>>>>>> process
> >>>>>>>>>>>>>>>>> page. A
> >>>>>>>>>>>>>>>>>>>>>>> FLIP
> >>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
> >> for
> >>>>>>> approvals,
> >>>>>>>>>> etc.
> >>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> -------------------------------
> >>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> >> currently
> >>>>>> requires
> >>>>>>>>>> "one
> >>>>>>>>>>> +1
> >>>>>>>>>>>>>> from a
> >>>>>>>>>>>>>>>>> committer
> >>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> >> followed
> >>>> by a
> >>>>>>> Lazy
> >>>>>>>>>>>> approval
> >>>>>>>>>>>>>> (not
> >>>>>>>>>>>>>>>>> counting
> >>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
> >> to
> >>>> lazy
> >>>>>>>>>> majority
> >>>>>>>>>>> if
> >>>>>>>>>>>> a
> >>>>>>>>>>>>> -1
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>> received".
> >>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
> >>>>>> committer
> >>>>>>>>>> always
> >>>>>>>>>>>>>> needs a
> >>>>>>>>>>>>>>>>> review
> >>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
> >>>> know
> >>>>>> this
> >>>>>>>> is
> >>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> >>>>> contributor
> >>>>>>>>>> reviews
> >>>>>>>>>>> &
> >>>>>>>>>>>>>> +1s).
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
> >> we
> >>>> can
> >>>>>>> make
> >>>>>>>> it
> >>>>>>>>>>> easy
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> follow the
> >>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> >>> Flink-specific
> >>>>> Jira
> >>>>>>>>>>> workflows
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> ticket
> >>>>>>>>>>>>>>>>>>>>>>> types +
> >>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
> >> is
> >>>>>>> certainly
> >>>>>>>>>>> "Step
> >>>>>>>>>>>>> 2",
> >>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>> believe,
> >>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> >>>> transparent
> >>>>>> as
> >>>>>>>>>>> possible,
> >>>>>>>>>>>>>>>>> otherwise they
> >>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> >>>>>>>>>>>>>>>>>>>>>>> & Re: Till
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> >>>> author
> >>>>>> and
> >>>>>>>>>>> getting
> >>>>>>>>>>>> a
> >>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> >>> should
> >>>>> know
> >>>>>>>> when
> >>>>>>>>>> to
> >>>>>>>>>>>> ask
> >>>>>>>>>>>>>>>> another
> >>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
> >> I
> >>>>> would
> >>>>>>> not
> >>>>>>>>>>> enforce
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>> strictly
> >>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> >> author
> >>>> is
> >>>>> a
> >>>>>>>>>> committer
> >>>>>>>>>>>> but
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> course
> >>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> >>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
> >> here.
> >>>>> TBH,
> >>>>>> in
> >>>>>>>>>> Kafka
> >>>>>>>>>>>>>>>> occasionally
> >>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
> >> still
> >>>>>> merged
> >>>>>>>>>> without
> >>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
> >> rare.
> >>>>> That
> >>>>>>>> said,
> >>>>>>>>>> I
> >>>>>>>>>>>> still
> >>>>>>>>>>>>>>> think
> >>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
> >> sense
> >>>> due
> >>>>>> to
> >>>>>>>> the
> >>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>> reasons:
> >>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
> >>> to
> >>>>> make
> >>>>>>>> sure
> >>>>>>>>>>> every
> >>>>>>>>>>>>>> patch
> >>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
> >>>>> little
> >>>>>>>>>> difficult
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> guarantee if
> >>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
> >>>> many
> >>>>>>>>>> reasons. In
> >>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>> cases, a
> >>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
> >> knowledge
> >>>>> about
> >>>>>>> the
> >>>>>>>>>>>> project
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> make
> >>>>>>>>>>>>>>>>> a good
> >>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
> >>> contributors
> >>>>> are
> >>>>>>> more
> >>>>>>>>>>>> eagerly
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> get a
> >>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
> >>> willing
> >>>>> to
> >>>>>>>> lower
> >>>>>>>>>> the
> >>>>>>>>>>>>>> review
> >>>>>>>>>>>>>>>> bar.
> >>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
> >>> among
> >>>>>>>>>> committers,
> >>>>>>>>>>>>> which
> >>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>> personally
> >>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
> >>>> form
> >>>>>>>>>> consistent
> >>>>>>>>>>>>> design
> >>>>>>>>>>>>>>>>> principles
> >>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
> >>>>> committers
> >>>>>>> will
> >>>>>>>>>> know
> >>>>>>>>>>>> how
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
> >>> from
> >>>>> each
> >>>>>>>>>> other.
> >>>>>>>>>>> So
> >>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>> tend
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
> >>>> things
> >>>>>>> should
> >>>>>>>>>> be
> >>>>>>>>>>>> done
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>> general.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
> >>>>> consider
> >>>>>>> the
> >>>>>>>>>>>> following
> >>>>>>>>>>>>>> two
> >>>>>>>>>>>>>>>>> scenarios:
> >>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
> >> a
> >>>> lot
> >>>>> of
> >>>>>>>>>>>> iterations.
> >>>>>>>>>>>>>> Then
> >>>>>>>>>>>>>>>>> the patch
> >>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
> >>> time
> >>>>>>> because
> >>>>>>>>>> there
> >>>>>>>>>>>> are
> >>>>>>>>>>>>>>>> things
> >>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
> >> changed.
> >>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
> >> very
> >>>>> smooth
> >>>>>>> and
> >>>>>>>>>>> quick,
> >>>>>>>>>>>>> so
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> patch is
> >>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
> >> patch
> >>>> does
> >>>>>> not
> >>>>>>>>>> take
> >>>>>>>>>>>> much
> >>>>>>>>>>>>>>> time.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
> >>> patch
> >>>>>> from a
> >>>>>>>>>>>> committer
> >>>>>>>>>>>>>>> falls
> >>>>>>>>>>>>>>>>> either in
> >>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
> >> is
> >>>> to
> >>>>>>> review
> >>>>>>>>>> the
> >>>>>>>>>>>>> patch
> >>>>>>>>>>>>>>>>> because
> >>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
> >> needs
> >>>> to
> >>>>> be
> >>>>>>>>>>> reviewed.
> >>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
> >>> take
> >>>>>> much
> >>>>>>>> time
> >>>>>>>>>>>>> anyways.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
> >>>> case
> >>>>> 1
> >>>>>> if
> >>>>>>>> we
> >>>>>>>>>>> skip
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> cross-review.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> ------------------------
> >>>>>>>>>>>>>>>>>>>>>>> Re: Robert
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
> >>> and
> >>>>> made
> >>>>>>> the
> >>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>> modifications
> >>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
> >>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
> >> section.
> >>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
> >>> to
> >>>>>>>>>> "consensus"
> >>>>>>>>>>> to
> >>>>>>>>>>>>>> align
> >>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
> >> and
> >>>>> other
> >>>>>>>>>>> projects.
> >>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> -------------------------
> >>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> >> unnecessary
> >>>>>> noise.
> >>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
> >>> 2/3
> >>>>>>>> majority
> >>>>>>>>>> is
> >>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>> feasible in
> >>>>>>>>>>>>>>>>>>>>>>> practice.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> >> the
> >>>>> draft
> >>>>>>>>>> compared
> >>>>>>>>>>> to
> >>>>>>>>>>>>>>>> existing
> >>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
> >>>>>> highlight
> >>>>>>>>>> these
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>>>>>>>>> one by one.
> >>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
> >>>> familiar
> >>>>>>> enough
> >>>>>>>>>> with
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> current Flink
> >>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
> >> saw
> >>>> you
> >>>>>>>>>> commented
> >>>>>>>>>>> on
> >>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>> part
> >>>>>>>>>>>>>>>>> in the
> >>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> --------------------------
> >>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> >>>> bylaws?
> >>>>>> I’m
> >>>>>>>>>> asking
> >>>>>>>>>>>>>> because
> >>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> >> essentially
> >>>>>> adopting
> >>>>>>>> the
> >>>>>>>>>>>> Kafka
> >>>>>>>>>>>>>>>> bylaws.
> >>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>> mean,
> >>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> >>> try
> >>>>> to
> >>>>>>>>>> re-invent
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> wheel
> >>>>>>>>>>>>>>>>> here.
> >>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
> >> version
> >>>> of
> >>>>>> the
> >>>>>>>>>> draft
> >>>>>>>>>>> was
> >>>>>>>>>>>>>>> almost
> >>>>>>>>>>>>>>>>> identical
> >>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
> >> caught a
> >>>> few
> >>>>>>>>>>> inconsistent
> >>>>>>>>>>>>>>> places.
> >>>>>>>>>>>>>>>>> So it
> >>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
> >>> make
> >>>>> sure
> >>>>>>> we
> >>>>>>>>>> truly
> >>>>>>>>>>>>> agree
> >>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
> >>>>> shortly
> >>>>>>>> after
> >>>>>>>>>>>>> adoption.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
> >> valuable
> >>>>>>> feedback.
> >>>>>>>>>> These
> >>>>>>>>>>>> are
> >>>>>>>>>>>>>>> great
> >>>>>>>>>>>>>>>>>>>>>>> discussion.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
> >> Aljoscha
> >>>>>> Krettek
> >>>>>>> <
> >>>>>>>>>>>>>>>>> aljoscha@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Big +1
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
> >>>> bylaws?
> >>>>>> I’m
> >>>>>>>>>> asking
> >>>>>>>>>>>>>>> because I
> >>>>>>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
> >> essentially
> >>>>>> adopting
> >>>>>>>> the
> >>>>>>>>>>>> Kafka
> >>>>>>>>>>>>>>>> bylaws.
> >>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>> mean,
> >>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
> >>> try
> >>>>> to
> >>>>>>>>>> re-invent
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> wheel
> >>>>>>>>>>>>>>>>> here.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
> >>>>>>> “committer
> >>>>>>>>>> +1”
> >>>>>>>>>>>>>>>> requirement.
> >>>>>>>>>>>>>>>>> We
> >>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
> >> would
> >>>>>> actually
> >>>>>>>> be
> >>>>>>>>>> in
> >>>>>>>>>>>>> favour
> >>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>> requiring
> >>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
> >>>>>>> complicated.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
> >>> Rohrmann
> >>>> <
> >>>>>>>>>>>>>>> trohrmann@apache.org>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
> >>>>> Becket.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
> >> emeritus
> >>>> (or
> >>>>>>> active
> >>>>>>>>>> vs.
> >>>>>>>>>>>>>>> inactive),
> >>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>> won't
> >>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
> >> vote
> >>>>>> because
> >>>>>>>> we
> >>>>>>>>>>>> already
> >>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>> too
> >>>>>>>>>>>>>>>>>>>>>>> many
> >>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
> >>>>> author
> >>>>>>> and
> >>>>>>>>>>>> getting a
> >>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>> from a
> >>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
> >>> should
> >>>>>> know
> >>>>>>>>>> when to
> >>>>>>>>>>>> ask
> >>>>>>>>>>>>>>>> another
> >>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
> >> Hence, I
> >>>>> would
> >>>>>>> not
> >>>>>>>>>>>> enforce
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>> strictly
> >>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
> >>> author
> >>>>> is a
> >>>>>>>>>>> committer
> >>>>>>>>>>>>> but
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> course
> >>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>>>>>>>>>>>> Till
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
> >> Chesnay
> >>>>>>> Schepler
> >>>>>>>> <
> >>>>>>>>>>>>>>>>> chesnay@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
> >>>> unnecessary
> >>>>>>> noise.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
> >>> the
> >>>>>> draft
> >>>>>>>>>>> compared
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> existing
> >>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
> >> to
> >>>>>>> highlight
> >>>>>>>>>>> these
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>> discuss
> >>>>>>>>>>>>>>>>>>>>>>> them
> >>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
> >>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
> >> this
> >>>>>>>> discussion
> >>>>>>>>>> and
> >>>>>>>>>>>>>>> creating
> >>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>> draft
> >>>>>>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> >> that
> >>> a
> >>>>>>>> committer
> >>>>>>>>>>>> always
> >>>>>>>>>>>>>>> needs
> >>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>> review
> >>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> >>> as I
> >>>>>> know
> >>>>>>>>>> this is
> >>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> >>>>>>> contributor
> >>>>>>>>>>>> reviews
> >>>>>>>>>>>>> &
> >>>>>>>>>>>>>>>> +1s).
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
> >> if
> >>>> we
> >>>>>> had
> >>>>>>>>>> cases
> >>>>>>>>>>> in
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> past
> >>>>>>>>>>>>>>>>> where
> >>>>>>>>>>>>>>>>>>>>>>>> code
> >>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
> >> we
> >>>>>> believe
> >>>>>>>>>> that we
> >>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>> enough
> >>>>>>>>>>>>>>>>>>>>>>>> capacity
> >>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
> >>>>> approval.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> >>>>> Konstantin
> >>>>>>>> Knauf
> >>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
> >>>> Becket. I
> >>>>>>> have
> >>>>>>>>>> two
> >>>>>>>>>>>>> remarks
> >>>>>>>>>>>>>>>>> regarding
> >>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
> >>>> Change"
> >>>>> we
> >>>>>>>> could
> >>>>>>>>>>> also
> >>>>>>>>>>>>>> add a
> >>>>>>>>>>>>>>>>> row for
> >>>>>>>>>>>>>>>>>>>>>>>>>> "Code
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
> >>>>> reference
> >>>>>> to
> >>>>>>>> the
> >>>>>>>>>>> FLIP
> >>>>>>>>>>>>>>> process
> >>>>>>>>>>>>>>>>> page.
> >>>>>>>>>>>>>>>>>>>>>>> A
> >>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
> >> rules
> >>>> for
> >>>>>>>>>> approvals,
> >>>>>>>>>>>> etc.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
> >>>> currently
> >>>>>>>> requires
> >>>>>>>>>>> "one
> >>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>> from a
> >>>>>>>>>>>>>>>>>>>>>>>>>> committer
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
> >>>> followed
> >>>>>> by a
> >>>>>>>>>> Lazy
> >>>>>>>>>>>>>> approval
> >>>>>>>>>>>>>>>> (not
> >>>>>>>>>>>>>>>>>>>>>>>> counting
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
> >> moving
> >>>> to
> >>>>>> lazy
> >>>>>>>>>>> majority
> >>>>>>>>>>>>> if
> >>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>> -1
> >>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>> received".
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
> >>> that a
> >>>>>>>> committer
> >>>>>>>>>>>> always
> >>>>>>>>>>>>>>>> needs a
> >>>>>>>>>>>>>>>>>>>>>>> review
> >>>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
> >>> as I
> >>>>>> know
> >>>>>>>>>> this is
> >>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>> always
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
> >>>>>>> contributor
> >>>>>>>>>>>> reviews
> >>>>>>>>>>>>> &
> >>>>>>>>>>>>>>>> +1s).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
> >>> how
> >>>>> we
> >>>>>>> can
> >>>>>>>>>> make
> >>>>>>>>>>> it
> >>>>>>>>>>>>>> easy
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> follow
> >>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
> >>>>> Flink-specific
> >>>>>>> Jira
> >>>>>>>>>>>>> workflows
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>> ticket
> >>>>>>>>>>>>>>>>>>>>>>>>>> types +
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
> >>> this
> >>>> is
> >>>>>>>>>> certainly
> >>>>>>>>>>>>> "Step
> >>>>>>>>>>>>>>> 2",
> >>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>>>>>> believe,
> >>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
> >>>>>> transparent
> >>>>>>>> as
> >>>>>>>>>>>>> possible,
> >>>>>>>>>>>>>>>>> otherwise
> >>>>>>>>>>>>>>>>>>>>>>>> they
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
> >>> Becket
> >>>>>> Qin <
> >>>>>>>>>>>>>>>>> becket.qin@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
> >>> process
> >>>>>>>> discussion
> >>>>>>>>>>>> thread
> >>>>>>>>>>>>>>> [1],
> >>>>>>>>>>>>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
> >>>> govern
> >>>>>> the
> >>>>>>>>>>>> operation
> >>>>>>>>>>>>> of
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> project.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
> >>> community
> >>>>> to
> >>>>>>>>>>> coordinate
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>> contribute
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
> >>>> other
> >>>>>>>>>> processes
> >>>>>>>>>>>> such
> >>>>>>>>>>>>>> as
> >>>>>>>>>>>>>>>>> FLIP.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
> >> page
> >>>> and
> >>>>>>> would
> >>>>>>>>>> like
> >>>>>>>>>>> to
> >>>>>>>>>>>>>>> start a
> >>>>>>>>>>>>>>>>>>>>>>>> discussion
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
> >> in
> >>>> the
> >>>>>>>>>> community.
> >>>>>>>>>>>>> It'll
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>> great to
> >>>>>>>>>>>>>>>>>>>>>>>>>> hear
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
> >>> Architect
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
> >>>>> 31.08.2019,
> >>>>>>>>>> 05.09. -
> >>>>>>>>>>>>>>>> 06.09.2010
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
> >>> 115,
> >>>>>> 10115
> >>>>>>>>>>> Berlin,
> >>>>>>>>>>>>>>> Germany
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
> >>>>> Charlottenburg:
> >>>>>>> HRB
> >>>>>>>>>>> 158244
> >>>>>>>>>>>> B
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
> >>>> Tzoumas,
> >>>>>> Dr.
> >>>>>>>>>> Stephan
> >>>>>>>>>>>>> Ewen
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>

Re: [DISCUSS] Flink project bylaws

[Maximilian Michels <mx...@apache.org>]

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 <fh...@gmail.com> wrote:
> 
>> Thanks for the update and driving the discussion Becket!
>> +1 for starting a vote.
>>
>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <becket.qin@gmail.com
>>> :
>>
>>> Thanks Stephan.
>>>
>>> I think we have resolved all the comments on the wiki page. There are two
>>> minor changes made to the bylaws since last week.
>>> 1. For 2/3 majority, the required attempts to reach out to binding voters
>>> is reduced from 3 to 2. This helps shorten the voting process a little
>> bit.
>>> 2. Clarified what is considered as the adoption of new codebase.
>>>
>>> I think we almost reached consensus. I'll start a voting thread in two
>> days
>>> if there is no new concerns.
>>>
>>> Thanks,
>>>
>>> Jiangjie (Becket) Qin
>>>
>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org> wrote:
>>>
>>>> I added a clarification to the table, clarifying that the current
>>> phrasing
>>>> means that committers do not need another +1 for their commits.
>>>>
>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fh...@gmail.com>
>> wrote:
>>>>
>>>>> Hi Becket,
>>>>>
>>>>> Thanks a lot for pushing this forward and addressing the feedback.
>>>>> I'm very happy with the current state of the bylaws.
>>>>> +1 to wait until Friday before starting a vote.
>>>>>
>>>>> Best, Fabian
>>>>>
>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
>>>>> becket.qin@gmail.com
>>>>>> :
>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> Thanks for all the discussion and feedback.
>>>>>>
>>>>>> It seems that we have almost reached consensus. I'll leave the
>>>> discussion
>>>>>> thread open until this Friday. If there is no more concerns raised,
>>>> I'll
>>>>>> start a voting thread after that.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jiangjie (Becket) Qin
>>>>>>
>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Becket,
>>>>>>>
>>>>>>> Thanks for noticing and resolving my comment around PMC removal
>> and
>>>> ASF
>>>>>>> rules of PMC membership change process, which you seem to neglect
>>> in
>>>>> the
>>>>>>> summary of updates (smile).
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Yu
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 24 Jul 2019 at 04:32, Becket Qin <be...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>>> Hi folks,
>>>>>>>>
>>>>>>>> Thanks for all the feedback.
>>>>>>>>
>>>>>>>> It seems that there are a few concerns over the emeritus status
>>>>> after 6
>>>>>>>> months of inactivity. Given that the main purpose is just to
>> make
>>>>> sure
>>>>>>> 2/3
>>>>>>>> majority can pass and we sort of have a solution for that, I
>> just
>>>>>> updated
>>>>>>>> the draft with the following changes:
>>>>>>>>
>>>>>>>> 1. Removed the inactivity term for emeritus committers / PMCs.
>> A
>>>>>>> committer
>>>>>>>> / PMC will only be considered emeritus by their own claim.
>>>>>>>> 2. Removed the approval process for reinstatement of the
>> emeritus
>>>>>>>> committers / PMCs. An emeritus committer / PMC will be
>> reinstated
>>>>> when
>>>>>>> they
>>>>>>>> send an email to the private@flink.apache.org.
>>>>>>>> 3. Adde the term to ensure 2/3 majority voting is still doable
>>> when
>>>>>> there
>>>>>>>> are non-emeritus committers / PMCs who do not cast the vote.
>>>>>>>>
>>>>>>>> Please let me know if you have any further thoughts.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>
>>>>>>>> On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
>>> becket.qin@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Fabian,
>>>>>>>>>
>>>>>>>>> Thanks for the feedback.
>>>>>>>>>
>>>>>>>>> I agree that if we don't like emeritus committers / PMCs, we
>>>> don't
>>>>>> have
>>>>>>>> to
>>>>>>>>> do it. That said, emeritus status simply means whether an
>>>>> individual
>>>>>> is
>>>>>>>>> active / inactive in the community. It does not make the
>> merits
>>>>>> earned
>>>>>>> to
>>>>>>>>> go away. For our purpose, emeritus status is mostly just a
>> way
>>> to
>>>>>> make
>>>>>>>> 2/3
>>>>>>>>> majority possible. As you noticed, since reaching out to
>>> binding
>>>>>> voters
>>>>>>>> who
>>>>>>>>> have not voted can achieve the same goal, the emeritus status
>>> is
>>>>> more
>>>>>>> of
>>>>>>>> an
>>>>>>>>> optimization so we don't have to ping the inactive binding
>>> voters
>>>>>> every
>>>>>>>>> time and wait for long. However, given that 2/3 majority
>>> votings
>>>>> are
>>>>>>>> rare,
>>>>>>>>> such communication cost is probably OK. So I think we can
>>> remove
>>>>> that
>>>>>>>>> emeritus part from the bylaws.
>>>>>>>>>
>>>>>>>>> 1) We should add to the requirements of the PMC that they
>> need
>>> to
>>>>>> make
>>>>>>>>>> sure the project complies with brand issues and reports
>> misuse
>>>> of
>>>>>> ASF
>>>>>>>>>> brands.
>>>>>>>>>
>>>>>>>>> Good point. Added.
>>>>>>>>>
>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
>> a
>>> 3
>>>>> day
>>>>>>> vote
>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
>>>>>>>>>
>>>>>>>>> This might be a little tricky because people are from
>> countries
>>>> in
>>>>>>>>> different time zones and with different holidays, and so on.
>> If
>>>> we
>>>>>> are
>>>>>>>>> worrying about 3 days minimum length is not enough for those
>>> who
>>>>> want
>>>>>>> to
>>>>>>>>> give feedback, we can make it 5 days.
>>>>>>>>>
>>>>>>>>> 3) Do we need a process do decide about removal of features
>>> (like
>>>>> the
>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
>>> Python
>>>>>>> APIs)?
>>>>>>>>>
>>>>>>>>> I assume such action should be covered by FLIP as it is a
>>> change
>>>> to
>>>>>> the
>>>>>>>>> API and probably needs a migration plan. It would be useful
>> to
>>>>> have a
>>>>>>>>> formal deprecation procedure. But that might be better to be
>>> put
>>>>> into
>>>>>>>>> somewhere else because the bylaws are primarily focusing on
>> the
>>>>>>>>> non-technical rules, whereas the deprecation seems more on
>> the
>>>>>>> technical
>>>>>>>>> side.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>
>>>>>>>>> On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
>>>> fhueske@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> First of all thank you very much Becket for starting this
>>>>>> discussion!
>>>>>>>>>> I think it is a very good idea and overdue to formally
>> define
>>>> some
>>>>>> of
>>>>>>>> our
>>>>>>>>>> community processes.
>>>>>>>>>>
>>>>>>>>>> Similar to Chesnay, I have concerns about the distinction
>>>> between
>>>>>>> active
>>>>>>>>>> and non-active / emeritus committers and PMC members.
>>>>>>>>>> My foremost concern is that this is not in the spirit of the
>>>>> Apache
>>>>>>> Way
>>>>>>>>>> [1]
>>>>>>>>>> which is (among other things) based on the idea of merit
>> which
>>>>> once
>>>>>>>>>> earned,
>>>>>>>>>> does not go away over time.
>>>>>>>>>> I know other projects like Hadoop and Kafka have similar
>>> clauses
>>>>> in
>>>>>>> the
>>>>>>>>>> bylaws but IMO we don't need to adopt them if we don't like
>>>> them.
>>>>>>>>>> For example, I don't like the idea that committers or PMC
>>>> members
>>>>>> who
>>>>>>>> are
>>>>>>>>>> temporarily away from the project (for whatever reason:
>>> parental
>>>>>>> leave,
>>>>>>>>>> sabbatical, health issues, etc.) need the PMC approval to be
>>>>>> "active"
>>>>>>>>>> again.
>>>>>>>>>> As far as I am aware, we have not seen any issues with
>>> inactive
>>>>>>> members
>>>>>>>> in
>>>>>>>>>> the past.
>>>>>>>>>> Moreover, it would be hard to track whether somebody became
>>>>> inactive
>>>>>>> at
>>>>>>>>>> some point in time (which we would need to do, if I
>> understand
>>>> the
>>>>>>>>>> proposal
>>>>>>>>>> correctly).
>>>>>>>>>> With the approach that Becket suggested in his last email
>>>>> (reaching
>>>>>>> out
>>>>>>>> to
>>>>>>>>>> binding voters who haven't voted yet), we could drop the
>>>>> distinction
>>>>>>>>>> between active and non-active committers and PMC members.
>>>>>>>>>>
>>>>>>>>>> I also have a few minor comments:
>>>>>>>>>>
>>>>>>>>>> 1) We should add to the requirements of the PMC [2] that
>> they
>>>> need
>>>>>> to
>>>>>>>> make
>>>>>>>>>> sure the project complies with brand issues and reports
>> misuse
>>>> of
>>>>>> ASF
>>>>>>>>>> brands.
>>>>>>>>>> 2) Do we want to restrict voting days to working days, i.e.,
>>> a 3
>>>>> day
>>>>>>>> vote
>>>>>>>>>> that starts on Friday 11:00am ends on Wednesday 11:00am?
>>>>>>>>>> 3) Do we need a process do decide about removal of features
>>>> (like
>>>>>> the
>>>>>>>>>> DataSet API for instance or the legacy DataSet/DataStream
>>> Python
>>>>>>> APIs)?
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Fabian
>>>>>>>>>>
>>>>>>>>>> [1] https://www.apache.org/theapacheway/
>>>>>>>>>> [2] https://www.apache.org/dev/pmc.html
>>>>>>>>>>
>>>>>>>>>> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
>>>>>>>>>> becket.qin@gmail.com
>>>>>>>>>>> :
>>>>>>>>>>
>>>>>>>>>>> Hi Hequn,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for sharing your thoughts. Please see the reply
>>> below:
>>>>>>>>>>>
>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one PMC
>> in
>>>>> the 3
>>>>>>>>>> binding
>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
>> and 1
>>>>> PMC.
>>>>>>>>>>>> I think this makes sense considering a FLIP could
>> somehow
>>>> be a
>>>>>> big
>>>>>>>>>>> feature
>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
>> loss
>>>> of
>>>>>>>>>> flexibility
>>>>>>>>>>>> as committers also have a chance to vote and participate
>>> in
>>>>> it.
>>>>>>>>>>> A few concerns of requiring a PMC vote in all FLIPs are
>> the
>>>>>>> following:
>>>>>>>>>>>
>>>>>>>>>>> 1. Generally speaking, the PMC's primary responsibility is
>>>>>> operating
>>>>>>>> the
>>>>>>>>>>> project and deciding what software to release on behalf of
>>>> ASF.
>>>>>>>>>> Committers,
>>>>>>>>>>> on the other hand, are responsible for the technical part
>> of
>>>> the
>>>>>>>>>> project.
>>>>>>>>>>> So for FLIPs, a PMC's vote probably should not outweigh a
>>>>>>> committer's
>>>>>>>>>> vote.
>>>>>>>>>>> Besides, I am not sure whether a single PMCs +1 is really
>>>>>> convincing
>>>>>>>>>> enough
>>>>>>>>>>> to decide whether the FLIP is good to go or not. Also, if
>>> some
>>>>>>>>>> committers
>>>>>>>>>>> have concern over a FLIP, they could just veto it. To me
>> it
>>> is
>>>>>>>> actually
>>>>>>>>>> a
>>>>>>>>>>> more strict requirement to pass a FLIP than asking a PMC
>> to
>>>>> vote.
>>>>>> In
>>>>>>>>>>> practice, people will usually also address the concerns
>> even
>>>> if
>>>>>> they
>>>>>>>> are
>>>>>>>>>>> not from a PMC/committer before they start the voting
>>> process.
>>>>> So
>>>>>> I
>>>>>>>>>> don't
>>>>>>>>>>> see much benefit of requiring a PMC's vote in this case.
>>>>>>>>>>>
>>>>>>>>>>> 2. The at-least-one-PMC-vote requirement makes the votes
>> no
>>>>> longer
>>>>>>>>>>> independent. Ideally, a vote is either binding or
>>> non-binding
>>>> by
>>>>>>>>>> itself. If
>>>>>>>>>>> we have the at-least-one-PMC-vote requirement here,
>> imagine
>>>>> there
>>>>>>> have
>>>>>>>>>> been
>>>>>>>>>>> 3 committers who voted +1. But the FLIP still has not
>>> passed,
>>>> so
>>>>>>> those
>>>>>>>>>>> votes are effectively non-binding. Now a PMC votes a +1,
>>> those
>>>>>> votes
>>>>>>>>>>> suddenly become binding, which is a little awkward.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The lazy 2/3 majority suggestion sounds reasonable to me.
>>> Some
>>>>>>>> thoughts
>>>>>>>>>> on
>>>>>>>>>>> this:
>>>>>>>>>>> 1. One reason Hadoop uses lazy 2/3 majority is probably
>>>> because
>>>>>>> there
>>>>>>>>>> are
>>>>>>>>>>> 104 PMC members[1] for Hadoop which makes the 2/3 majority
>>>>>>>> prohibitively
>>>>>>>>>>> expensive. In our case, there are only 22 PMCs for
>> Flink[2]
>>>> and
>>>>> a
>>>>>>>> quick
>>>>>>>>>>> search shows at most 6 of them have not sent email in the
>>>>> recent 6
>>>>>>>>>> months
>>>>>>>>>>> or so.
>>>>>>>>>>>
>>>>>>>>>>> 2. 2/3 majority votes are supposed to be very rare. It is
>>>>> designed
>>>>>>> in
>>>>>>>>>>> particular for the cases that broad opinions are
>> important,
>>>> more
>>>>>>>>>>> specifically new codebase adoption or modification to the
>>>>> bylaws.
>>>>>>>>>> Therefore
>>>>>>>>>>> such vote by its nature favors consensus over convenience.
>>>> That
>>>>>>> means
>>>>>>>>>> any
>>>>>>>>>>> alternative voting type reducing the coverage worth a
>>> careful
>>>>>>>> thinking.
>>>>>>>>>>>
>>>>>>>>>>> 3. I do agree that it does not make sense to have 2/3
>>> majority
>>>>> if
>>>>>>> such
>>>>>>>>>>> requirement is no-longer doable over time. But I am a
>> little
>>>>>>> hesitant
>>>>>>>> to
>>>>>>>>>>> lower the threshold to lazy 2/3 majority in our case. What
>>> do
>>>>> you
>>>>>>>> think
>>>>>>>>>>> about doing the following:
>>>>>>>>>>>     - After the voting started, there will be at least 6
>>> days
>>>>> for
>>>>>>>>>> people to
>>>>>>>>>>> cast their votes.
>>>>>>>>>>>     - After 6 days, if the result of the vote is still not
>>>>>>> determined,
>>>>>>>>>> the
>>>>>>>>>>> person who started the vote should reach out to the
>> binding
>>>>> voters
>>>>>>> who
>>>>>>>>>> have
>>>>>>>>>>> not voted yet for at least 3 times and at least 7 days
>>> between
>>>>>> each
>>>>>>>>>> time.
>>>>>>>>>>> If a binding voter still did not respond, the vote from
>> that
>>>>> voter
>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>>> excluded from the 2/3 majority counting.
>>>>>>>>>>> This would ensure the coverage at our best effort while
>>> still
>>>>> let
>>>>>>> the
>>>>>>>>>> 2/3
>>>>>>>>>>> majority vote make progress.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> [1] https://projects.apache.org/committee.html?hadoop
>>>>>>>>>>> [2] https://projects.apache.org/committee.html?flink
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
>>>>>> forwardxu315@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Big +1 on this.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> best
>>>>>>>>>>>>
>>>>>>>>>>>> forward
>>>>>>>>>>>>
>>>>>>>>>>>> Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
>>> 下午1:30写道：
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Becket,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Big +1 on this.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
>>>> includes a
>>>>>> PMC
>>>>>>>>>> vote.
>>>>>>>>>>>>> Perhaps what Jincheng means is to hold at least one
>> PMC
>>> in
>>>>>> the 3
>>>>>>>>>>> binding
>>>>>>>>>>>>> votes? i.e, the vote could have 2 binding committers
>>> and 1
>>>>>> PMC.
>>>>>>>>>>>>> I think this makes sense considering a FLIP could
>>> somehow
>>>>> be a
>>>>>>> big
>>>>>>>>>>>> feature
>>>>>>>>>>>>> which may impacts Flink a lot. Meanwhile, there is no
>>> loss
>>>>> of
>>>>>>>>>>> flexibility
>>>>>>>>>>>>> as committers also have a chance to vote and
>> participate
>>>> in
>>>>>> it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ========Seperator========
>>>>>>>>>>>>>
>>>>>>>>>>>>> For the nice bylaws, I agree with the general idea and
>>>> most
>>>>> of
>>>>>>> the
>>>>>>>>>>>> content.
>>>>>>>>>>>>> Only share some thoughts about the "2/3 Majority". The
>>>> main
>>>>>>>> concern
>>>>>>>>>> is
>>>>>>>>>>> I
>>>>>>>>>>>> am
>>>>>>>>>>>>> not sure if it is doable in practice. The reasons are:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. If we follow the bylaws strictly, it means a
>>> committer
>>>>> or a
>>>>>>> PMC
>>>>>>>>>>> member
>>>>>>>>>>>>> is active if he or she sends one email to the mailing
>>> list
>>>>>>> every 6
>>>>>>>>>>>> months.
>>>>>>>>>>>>> While the minimum length of the vote is only 6 days.
>>> There
>>>>> are
>>>>>>>>>> chances
>>>>>>>>>>>> that
>>>>>>>>>>>>> during the vote, some of the active members are still
>>>>> offline
>>>>>> of
>>>>>>>> the
>>>>>>>>>>>>> community.
>>>>>>>>>>>>> 2. The code of Flink is changing fast and not everyone
>>>> fully
>>>>>>>>>>> understands
>>>>>>>>>>>>> every part. We don't need to force people to vote if
>>> they
>>>>> are
>>>>>>> not
>>>>>>>>>> sure
>>>>>>>>>>>>> about it. It may also make the final result less
>>> credible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Given the above reasons, perhaps we can change the 2/3
>>>>>> Majority
>>>>>>> to
>>>>>>>>>> lazy
>>>>>>>>>>>> 2/3
>>>>>>>>>>>>> Majority, just as the Hadoop bylaws[1]. It makes a
>>> higher
>>>>>>>> threshold,
>>>>>>>>>>>>> however, more practical.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://hadoop.apache.org/bylaws.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
>>>>>>> becket.qin@gmail.com
>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Jincheng,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the comments. I replied on the wiki page.
>>>> Just
>>>>> a
>>>>>>>> brief
>>>>>>>>>>>>> summary,
>>>>>>>>>>>>>> the current bylaws do require some of the FLIPs to
>> get
>>>> PMC
>>>>>>>>>> approval
>>>>>>>>>>> if
>>>>>>>>>>>>>> their impact is big enough. But it leaves majority
>> of
>>>> the
>>>>>>>>>> technical
>>>>>>>>>>>>>> decisions to the committers who are supposed to be
>>>>>> responsible
>>>>>>>> for
>>>>>>>>>>>> making
>>>>>>>>>>>>>> such decisions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Re: Robert,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree we can simply remove the requirement of +1
>>> from
>>>> a
>>>>>>>>>> non-author
>>>>>>>>>>>>>> committer and revisit it in a bit. After all, it
>> does
>>>> not
>>>>>> make
>>>>>>>>>> sense
>>>>>>>>>>> to
>>>>>>>>>>>>>> have a bylaw that we cannot afford. I have just
>>> updated
>>>>> the
>>>>>>>> bylaws
>>>>>>>>>>>> wiki.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
>>>>>>>>>> rmetzger@apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>> I agree with Aljoscha that trying to reflect the
>>>> current
>>>>>>>> status
>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> bylaws, and then implementing changes one by one
>> is
>>> a
>>>>> very
>>>>>>>>>> involved
>>>>>>>>>>>>> task.
>>>>>>>>>>>>>>> Unless there's somebody who's really eager to
>> drive
>>>>> this,
>>>>>> I
>>>>>>>>>> would
>>>>>>>>>>>> stick
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> Becket's initiative to come up with Bylaws for
>>> Flink,
>>>>> even
>>>>>>> if
>>>>>>>>>> this
>>>>>>>>>>>>> means
>>>>>>>>>>>>>>> some changes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The cross-review requirement is the last big open
>>>> point
>>>>> in
>>>>>>>> this
>>>>>>>>>>>>>> discussion.
>>>>>>>>>>>>>>> It seems that a there is a slight tendency in the
>>>>>> discussion
>>>>>>>>>> that
>>>>>>>>>>>> this
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> not feasible given the current pull request review
>>>>>>> situation.
>>>>>>>>>>>>>>> For the sake of bringing this discussion to a
>>>>> conclusion,
>>>>>>> I'm
>>>>>>>>>> fine
>>>>>>>>>>>> with
>>>>>>>>>>>>>>> leaving this requirement out. As we are currently
>>>> adding
>>>>>>> more
>>>>>>>>>>>>> committers
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> the project, we might be able to revisit this
>>>> discussion
>>>>>> in
>>>>>>> 3
>>>>>>>> -
>>>>>>>>>> 6
>>>>>>>>>>>>> months.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
>>>>>>>>>>>> sunjincheng121@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Becket,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for the proposal.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regarding the vote of FLIP, preferably at least
>>>>>> includes a
>>>>>>>> PMC
>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>> Because FLIP is usually a big change or affects
>>> the
>>>>>> user's
>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>> changes. What do you think? (I leave the comment
>>> in
>>>>> the
>>>>>>>> wiki.)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>> Jincheng
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dawid Wysakowicz <dw...@apache.org>
>>>>> 于2019年7月17日周三
>>>>>>>>>>> 下午9:12写道：
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sorry for joining late. I just wanted to say
>>> that
>>>> I
>>>>>>> really
>>>>>>>>>> like
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> proposed bylaws!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> One comment, I also have the same concerns as
>>>>>> expressed
>>>>>>> by
>>>>>>>>>> few
>>>>>>>>>>>>> people
>>>>>>>>>>>>>>>>> before that the "committer +1" on code change
>>>> might
>>>>> be
>>>>>>>> hard
>>>>>>>>>> to
>>>>>>>>>>>>>> achieve
>>>>>>>>>>>>>>>>> currently. On the other hand I would say this
>>>> would
>>>>> be
>>>>>>>>>>> beneficial
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> the quality/uniformity of our codebase and
>>>> knowledge
>>>>>>>>>> sharing.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I was just wondering what should be the next
>>> step
>>>>> for
>>>>>>>> this?
>>>>>>>>>> I
>>>>>>>>>>>> think
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> would make sense to already use those bylaws
>> and
>>>> put
>>>>>>> them
>>>>>>>> to
>>>>>>>>>>> PMC
>>>>>>>>>>>>>> vote.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Dawid
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 12/07/2019 13:35, Piotr Nowojski wrote:
>>>>>>>>>>>>>>>>>> Hi Aljoscha and Becket
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, 3 days for FLIP voting is fine I
>> think.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
>>> If
>>>> we
>>>>>> are
>>>>>>>>>>> stating
>>>>>>>>>>>>>> that a
>>>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>>>>>>> committers +1 is good enough for code
>>> review,
>>>>>> with 0
>>>>>>>>>> hours
>>>>>>>>>>>>> delay
>>>>>>>>>>>>>>> (de
>>>>>>>>>>>>>>>>> facto
>>>>>>>>>>>>>>>>>>>> the current state), we should also write
>>> down
>>>>> that
>>>>>>>> this
>>>>>>>>>> is
>>>>>>>>>>>>>> subject
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> best judgement of the committer to respect
>>> the
>>>>>>>>>> components
>>>>>>>>>>>>>> expertise
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> ongoing development plans (also the de
>> facto
>>>>>> current
>>>>>>>>>>> state).
>>>>>>>>>>>>>>>>>>> Adding the statement would help clarify the
>>>>>>> intention,
>>>>>>>>>> but
>>>>>>>>>>> it
>>>>>>>>>>>>> may
>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>>>> little difficult to enforce and follow..
>>>>>>>>>>>>>>>>>> I would be fine with that, it’s a soft/vague
>>>> rule
>>>>>>>> anyway,
>>>>>>>>>>>>> intended
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> used with your “best judgemenet". I would like
>>> to
>>>>> just
>>>>>>>>>> avoid a
>>>>>>>>>>>>>>> situation
>>>>>>>>>>>>>>>>> when someone violates current uncodified state
>>> and
>>>>>>> refers
>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>>>>> bylaws
>>>>>>>>>>>>>>>>> which are saying merging with any committer +1
>>> is
>>>>>> always
>>>>>>>>>> fine
>>>>>>>>>>>> (like
>>>>>>>>>>>>>>> mine
>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>> for flink-python or flink-ml).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Piotrek
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 11:29, Aljoscha Krettek
>> <
>>>>>>>>>>>> aljoscha@apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> @Piotr regarding the 3 days voting on the
>>> FLIP.
>>>>>> This
>>>>>>> is
>>>>>>>>>> just
>>>>>>>>>>>>> about
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> voting, before that there needs to be the
>>>> discussion
>>>>>>>>>> thread. If
>>>>>>>>>>>>> three
>>>>>>>>>>>>>>>> days
>>>>>>>>>>>>>>>>> have passed on a vote and there is consensus
>>>> (i.e. 3
>>>>>>>>>>>>> committers/PMCs
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> voted +1) that seems a high enough bar for me.
>>> So
>>>>> far,
>>>>>>> we
>>>>>>>>>> have
>>>>>>>>>>>>> rarely
>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>> any FLIPs pass that formal bar.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> According to the recent META-FLIP thread,
>> we
>>>> want
>>>>>> to
>>>>>>>> use
>>>>>>>>>>> "lazy
>>>>>>>>>>>>>>>>> majority" for the FLIP voting process. I think
>>>> that
>>>>>>> should
>>>>>>>>>> be
>>>>>>>>>>>>> changed
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>> “consensus” in the proposed bylaws.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regarding the current state: do we have a
>>>> current
>>>>>>> state
>>>>>>>>>> that
>>>>>>>>>>>> we
>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>> agree on? I have the feeling that if we try to
>>>> come
>>>>> up
>>>>>>>> with
>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> reflects the common state, according to
>>>>>> PMCs/commiters,
>>>>>>>> that
>>>>>>>>>>>> might
>>>>>>>>>>>>>>> take a
>>>>>>>>>>>>>>>>> very long time. In that case I think it’s
>> better
>>>> to
>>>>>>> adopt
>>>>>>>>>>>> something
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> all like, rather than trying to capture how we
>>> do
>>>> it
>>>>>>> now.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 12. Jul 2019, at 11:07, Piotr Nowojski
>> <
>>>>>>>>>>>> piotr@ververica.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks for the proposal. Generally
>> speaking
>>> +1
>>>>>> from
>>>>>>> my
>>>>>>>>>> side
>>>>>>>>>>>> to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> general idea and most of the content. I also
>> see
>>>>> merit
>>>>>>> to
>>>>>>>>>> the
>>>>>>>>>>>>>> Chesney's
>>>>>>>>>>>>>>>>> proposal to start from the current state. I
>>> think
>>>>>> either
>>>>>>>>>> would
>>>>>>>>>>> be
>>>>>>>>>>>>>> fine
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> me.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Couple of comments:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I also think that requiring +1 from
>> another
>>>>>>> committer
>>>>>>>>>> would
>>>>>>>>>>>>> slow
>>>>>>>>>>>>>>> down
>>>>>>>>>>>>>>>>> and put even more strain on the current
>>> reviewing
>>>>>>>> bottleneck
>>>>>>>>>>> that
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> having. Even if the change clear and simple,
>>>> context
>>>>>>>> switch
>>>>>>>>>>> cost
>>>>>>>>>>>> is
>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>> high, and that’s just one less PR that the
>>> second
>>>>>>> “cross”
>>>>>>>>>>>> committer
>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>> have reviewed somewhere else in that time.
>>>> Besides,
>>>>>>>> current
>>>>>>>>>>> setup
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> have (with no cross +1 from another committer
>>>>>> required)
>>>>>>>>>> works
>>>>>>>>>>>> quite
>>>>>>>>>>>>>>> well
>>>>>>>>>>>>>>>>> and I do not feel that’s causing troubles. On
>>> the
>>>>>> other
>>>>>>>> hand
>>>>>>>>>>>>>> reviewing
>>>>>>>>>>>>>>>>> bottleneck is.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I think a committer should know when to
>> ask
>>>>>> another
>>>>>>>>>>>> committer
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> feedback or not.
>>>>>>>>>>>>>>>>>>>> I’m missing this stated somewhere clearly.
>>> If
>>>> we
>>>>>> are
>>>>>>>>>>> stating
>>>>>>>>>>>>>> that a
>>>>>>>>>>>>>>>>> single committers +1 is good enough for code
>>>> review,
>>>>>>> with
>>>>>>>> 0
>>>>>>>>>>> hours
>>>>>>>>>>>>>> delay
>>>>>>>>>>>>>>>> (de
>>>>>>>>>>>>>>>>> facto the current state), we should also write
>>>> down
>>>>>> that
>>>>>>>>>> this
>>>>>>>>>>> is
>>>>>>>>>>>>>>> subject
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> the best judgement of the committer to respect
>>> the
>>>>>>>>>> components
>>>>>>>>>>>>>> expertise
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> ongoing development plans (also the de facto
>>>> current
>>>>>>>> state).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 3.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Minimum length of 3 days for FLIP I think
>>>>>> currently
>>>>>>>>>> might
>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> problematic/too quick and can lead to problems
>>> if
>>>>>>>> respected
>>>>>>>>>> to
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> letter.
>>>>>>>>>>>>>>>>> Again I think it depends highly on whether the
>>>>>>> committers
>>>>>>>>>> with
>>>>>>>>>>>>>> highest
>>>>>>>>>>>>>>>>> expertise in the affected components managed
>> to
>>>>>> respond
>>>>>>> or
>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Piotrek
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 12 Jul 2019, at 09:42, Chesnay
>> Schepler
>>> <
>>>>>>>>>>>>> chesnay@apache.org>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I'm wondering whether we shouldn't first
>>>> write
>>>>>> down
>>>>>>>>>> Bylaws
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> reflect the current state, and then have
>>> separate
>>>>>>>>>> discussions
>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> individual amendments. My gut feeling is that
>>> this
>>>>>>>>>> discussion
>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> quickly
>>>>>>>>>>>>>>>>> become a chaotic mess with plenty points being
>>>>>> discussed
>>>>>>>> at
>>>>>>>>>>> once.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 20:03, Bowen Li wrote:
>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
>>> Qin
>>>> <
>>>>>>>>>>>>>>> becket.qin@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks everyone for all the comments
>> and
>>>>>>> feedback.
>>>>>>>>>>> Please
>>>>>>>>>>>>> see
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> replies
>>>>>>>>>>>>>>>>>>>>>>> below:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
>> Change"
>>> we
>>>>>> could
>>>>>>>>>> also
>>>>>>>>>>>> add a
>>>>>>>>>>>>>> row
>>>>>>>>>>>>>>>>> for "Code
>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
>>> reference
>>>> to
>>>>>> the
>>>>>>>>>> FLIP
>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>> page. A
>>>>>>>>>>>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different rules
>> for
>>>>>>> approvals,
>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>>>>>> Good point. Just added the entry.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -------------------------------
>>>>>>>>>>>>>>>>>>>>>>> Re: Konstantin
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
>> currently
>>>>>> requires
>>>>>>>>>> "one
>>>>>>>>>>> +1
>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
>> followed
>>>> by a
>>>>>>> Lazy
>>>>>>>>>>>> approval
>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>>> counting
>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor), moving
>> to
>>>> lazy
>>>>>>>>>> majority
>>>>>>>>>>> if
>>>>>>>>>>>> a
>>>>>>>>>>>>> -1
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>> received".
>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means, that a
>>>>>> committer
>>>>>>>>>> always
>>>>>>>>>>>>>> needs a
>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far as I
>>>> know
>>>>>> this
>>>>>>>> is
>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>>>>> contributor
>>>>>>>>>> reviews
>>>>>>>>>>> &
>>>>>>>>>>>>>> +1s).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about how
>> we
>>>> can
>>>>>>> make
>>>>>>>> it
>>>>>>>>>>> easy
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> follow the
>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
>>> Flink-specific
>>>>> Jira
>>>>>>>>>>> workflows
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>>>>> types +
>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While this
>> is
>>>>>>> certainly
>>>>>>>>>>> "Step
>>>>>>>>>>>>> 2",
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> believe,
>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
>>>> transparent
>>>>>> as
>>>>>>>>>>> possible,
>>>>>>>>>>>>>>>>> otherwise they
>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
>>>>>>>>>>>>>>>>>>>>>>> & Re: Till
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
>>>> author
>>>>>> and
>>>>>>>>>>> getting
>>>>>>>>>>>> a
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
>>> should
>>>>> know
>>>>>>>> when
>>>>>>>>>> to
>>>>>>>>>>>> ask
>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not. Hence,
>> I
>>>>> would
>>>>>>> not
>>>>>>>>>>> enforce
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>> strictly
>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
>> author
>>>> is
>>>>> a
>>>>>>>>>> committer
>>>>>>>>>>>> but
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> course
>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
>>>>>>>>>>>>>>>>>>>>>>> I am with Robert and Aljoscha on this.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I completely understand the concern
>> here.
>>>>> TBH,
>>>>>> in
>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>> occasionally
>>>>>>>>>>>>>>>>>>>>>>> trivial patches from committers are
>> still
>>>>>> merged
>>>>>>>>>> without
>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> cross-review requirement, but it is
>> rare.
>>>>> That
>>>>>>>> said,
>>>>>>>>>> I
>>>>>>>>>>>> still
>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>> additional committer's review makes
>> sense
>>>> due
>>>>>> to
>>>>>>>> the
>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>> reasons:
>>>>>>>>>>>>>>>>>>>>>>> 1. The bottom line here is that we need
>>> to
>>>>> make
>>>>>>>> sure
>>>>>>>>>>> every
>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>> reviewed with a high quality. This is a
>>>>> little
>>>>>>>>>> difficult
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> guarantee if
>>>>>>>>>>>>>>>>>>>>>>> the review comes from a contributor for
>>>> many
>>>>>>>>>> reasons. In
>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>> cases, a
>>>>>>>>>>>>>>>>>>>>>>> contributor may not have enough
>> knowledge
>>>>> about
>>>>>>> the
>>>>>>>>>>>> project
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>> a good
>>>>>>>>>>>>>>>>>>>>>>> judgement. Also sometimes the
>>> contributors
>>>>> are
>>>>>>> more
>>>>>>>>>>>> eagerly
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> get a
>>>>>>>>>>>>>>>>>>>>>>> particular issue fixed, so they are
>>> willing
>>>>> to
>>>>>>>> lower
>>>>>>>>>> the
>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>> bar.
>>>>>>>>>>>>>>>>>>>>>>> 2. One byproduct of such cross review
>>> among
>>>>>>>>>> committers,
>>>>>>>>>>>>> which
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> personally
>>>>>>>>>>>>>>>>>>>>>>> feel useful, is that it helps gradually
>>>> form
>>>>>>>>>> consistent
>>>>>>>>>>>>> design
>>>>>>>>>>>>>>>>> principles
>>>>>>>>>>>>>>>>>>>>>>> and code style. This is because the
>>>>> committers
>>>>>>> will
>>>>>>>>>> know
>>>>>>>>>>>> how
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>>> committers are writing code and learn
>>> from
>>>>> each
>>>>>>>>>> other.
>>>>>>>>>>> So
>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>> tend
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> reach some tacit understanding on how
>>>> things
>>>>>>> should
>>>>>>>>>> be
>>>>>>>>>>>> done
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> general.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Another way to think about this is to
>>>>> consider
>>>>>>> the
>>>>>>>>>>>> following
>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>>> scenarios:
>>>>>>>>>>>>>>>>>>>>>>> 1. Reviewing a committer's patch takes
>> a
>>>> lot
>>>>> of
>>>>>>>>>>>> iterations.
>>>>>>>>>>>>>> Then
>>>>>>>>>>>>>>>>> the patch
>>>>>>>>>>>>>>>>>>>>>>> needs to be reviewed even if it takes
>>> time
>>>>>>> because
>>>>>>>>>> there
>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> things
>>>>>>>>>>>>>>>>>>>>>>> actually needs to be clarified /
>> changed.
>>>>>>>>>>>>>>>>>>>>>>> 2. Reviewing a committer's patch is
>> very
>>>>> smooth
>>>>>>> and
>>>>>>>>>>> quick,
>>>>>>>>>>>>> so
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> patch is
>>>>>>>>>>>>>>>>>>>>>>> merged soon. Then reviewing such a
>> patch
>>>> does
>>>>>> not
>>>>>>>>>> take
>>>>>>>>>>>> much
>>>>>>>>>>>>>>> time.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Letting another committer review the
>>> patch
>>>>>> from a
>>>>>>>>>>>> committer
>>>>>>>>>>>>>>> falls
>>>>>>>>>>>>>>>>> either in
>>>>>>>>>>>>>>>>>>>>>>> case 1 or case 2. The best option here
>> is
>>>> to
>>>>>>> review
>>>>>>>>>> the
>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>>>>> If it is case 1, the patch actually
>> needs
>>>> to
>>>>> be
>>>>>>>>>>> reviewed.
>>>>>>>>>>>>>>>>>>>>>>> If it is case 2, the review should not
>>> take
>>>>>> much
>>>>>>>> time
>>>>>>>>>>>>> anyways.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> In the contrast, we will risk encounter
>>>> case
>>>>> 1
>>>>>> if
>>>>>>>> we
>>>>>>>>>>> skip
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> cross-review.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>>> Re: Robert
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I replied to your comments in the wiki
>>> and
>>>>> made
>>>>>>> the
>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>> modifications
>>>>>>>>>>>>>>>>>>>>>>> to resolve some of your comments:
>>>>>>>>>>>>>>>>>>>>>>> 1. Added a release manager role
>> section.
>>>>>>>>>>>>>>>>>>>>>>> 2. changed the name of "lazy consensus"
>>> to
>>>>>>>>>> "consensus"
>>>>>>>>>>> to
>>>>>>>>>>>>>> align
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>> general definition of Apache glossary
>> and
>>>>> other
>>>>>>>>>>> projects.
>>>>>>>>>>>>>>>>>>>>>>> 3. review board  -> pull request
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -------------------------
>>>>>>>>>>>>>>>>>>>>>>> Re: Chesnay
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
>> unnecessary
>>>>>> noise.
>>>>>>>>>>>>>>>>>>>>>>> As Till mentioned, this is to make sure
>>> 2/3
>>>>>>>> majority
>>>>>>>>>> is
>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>> feasible in
>>>>>>>>>>>>>>>>>>>>>>> practice.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
>> the
>>>>> draft
>>>>>>>>>> compared
>>>>>>>>>>> to
>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way to
>>>>>> highlight
>>>>>>>>>> these
>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>>>>> one by one.
>>>>>>>>>>>>>>>>>>>>>>> That is a good suggestion. I am not
>>>> familiar
>>>>>>> enough
>>>>>>>>>> with
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> current Flink
>>>>>>>>>>>>>>>>>>>>>>> convention. Will you help on this? I
>> saw
>>>> you
>>>>>>>>>> commented
>>>>>>>>>>> on
>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>>>> wiki. Are those complete?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --------------------------
>>>>>>>>>>>>>>>>>>>>>>> Re: Aljoscha
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
>>>> bylaws?
>>>>>> I’m
>>>>>>>>>> asking
>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
>> essentially
>>>>>> adopting
>>>>>>>> the
>>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>> bylaws.
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>> mean,
>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
>>> try
>>>>> to
>>>>>>>>>> re-invent
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> wheel
>>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>>>>>>>>> Ha, you got me on this. The first
>> version
>>>> of
>>>>>> the
>>>>>>>>>> draft
>>>>>>>>>>> was
>>>>>>>>>>>>>>> almost
>>>>>>>>>>>>>>>>> identical
>>>>>>>>>>>>>>>>>>>>>>> to Kafka. But Robert has already
>> caught a
>>>> few
>>>>>>>>>>> inconsistent
>>>>>>>>>>>>>>> places.
>>>>>>>>>>>>>>>>> So it
>>>>>>>>>>>>>>>>>>>>>>> might still worth going through it to
>>> make
>>>>> sure
>>>>>>> we
>>>>>>>>>> truly
>>>>>>>>>>>>> agree
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>>>>>>>> Otherwise we may end up modifying them
>>>>> shortly
>>>>>>>> after
>>>>>>>>>>>>> adoption.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks again folks, for all the
>> valuable
>>>>>>> feedback.
>>>>>>>>>> These
>>>>>>>>>>>> are
>>>>>>>>>>>>>>> great
>>>>>>>>>>>>>>>>>>>>>>> discussion.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:55 PM
>> Aljoscha
>>>>>> Krettek
>>>>>>> <
>>>>>>>>>>>>>>>>> aljoscha@apache.org>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Big +1
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> How different is this from the Kafka
>>>> bylaws?
>>>>>> I’m
>>>>>>>>>> asking
>>>>>>>>>>>>>>> because I
>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>>>>> like them and wouldn’t mind
>> essentially
>>>>>> adopting
>>>>>>>> the
>>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>> bylaws.
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>> mean,
>>>>>>>>>>>>>>>>>>>>>>>> it’s open source, and we don’t have to
>>> try
>>>>> to
>>>>>>>>>> re-invent
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> wheel
>>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I think it’s worthwhile to discuss the
>>>>>>> “committer
>>>>>>>>>> +1”
>>>>>>>>>>>>>>>> requirement.
>>>>>>>>>>>>>>>>> We
>>>>>>>>>>>>>>>>>>>>>>>> don’t usually have that now but I
>> would
>>>>>> actually
>>>>>>>> be
>>>>>>>>>> in
>>>>>>>>>>>>> favour
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>> requiring
>>>>>>>>>>>>>>>>>>>>>>>> it, although it might make stuff more
>>>>>>> complicated.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Aljoscha
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 11. Jul 2019, at 15:31, Till
>>> Rohrmann
>>>> <
>>>>>>>>>>>>>>> trohrmann@apache.org>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks a lot for creating this draft
>>>>> Becket.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I think without the notion of
>> emeritus
>>>> (or
>>>>>>> active
>>>>>>>>>> vs.
>>>>>>>>>>>>>>> inactive),
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>> won't
>>>>>>>>>>>>>>>>>>>>>>>>> be possible to have a 2/3 majority
>> vote
>>>>>> because
>>>>>>>> we
>>>>>>>>>>>> already
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>>>>> many
>>>>>>>>>>>>>>>>>>>>>>>>> inactive PMCs/committers.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> For the case of a committer being the
>>>>> author
>>>>>>> and
>>>>>>>>>>>> getting a
>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>>>>>>> non-committer: I think a committer
>>> should
>>>>>> know
>>>>>>>>>> when to
>>>>>>>>>>>> ask
>>>>>>>>>>>>>>>> another
>>>>>>>>>>>>>>>>>>>>>>>>> committer for feedback or not.
>> Hence, I
>>>>> would
>>>>>>> not
>>>>>>>>>>>> enforce
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>> strictly
>>>>>>>>>>>>>>>>>>>>>>>>> need a +1 from a committer if the
>>> author
>>>>> is a
>>>>>>>>>>> committer
>>>>>>>>>>>>> but
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> course
>>>>>>>>>>>>>>>>>>>>>>>>> encourage it if capacities exist.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>>>>> Till
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
>> Chesnay
>>>>>>> Schepler
>>>>>>>> <
>>>>>>>>>>>>>>>>> chesnay@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> The emeritus stuff seems like
>>>> unnecessary
>>>>>>> noise.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> There's a bunch of subtle changes in
>>> the
>>>>>> draft
>>>>>>>>>>> compared
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>>>>>>> "conventions"; we should find a way
>> to
>>>>>>> highlight
>>>>>>>>>>> these
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> discuss
>>>>>>>>>>>>>>>>>>>>>>> them
>>>>>>>>>>>>>>>>>>>>>>>>>> one by one.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/07/2019 14:29, Robert Metzger
>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you Becket for kicking off
>> this
>>>>>>>> discussion
>>>>>>>>>> and
>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> draft
>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I left some comments in the wiki.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
>> that
>>> a
>>>>>>>> committer
>>>>>>>>>>>> always
>>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
>>> as I
>>>>>> know
>>>>>>>>>> this is
>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>>>>>>> contributor
>>>>>>>>>>>> reviews
>>>>>>>>>>>>> &
>>>>>>>>>>>>>>>> +1s).
>>>>>>>>>>>>>>>>>>>>>>>>>>> I would agree to add such a bylaw,
>> if
>>>> we
>>>>>> had
>>>>>>>>>> cases
>>>>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> past
>>>>>>>>>>>>>>>>> where
>>>>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>>>>> was not sufficiently reviewed AND
>> we
>>>>>> believe
>>>>>>>>>> that we
>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> enough
>>>>>>>>>>>>>>>>>>>>>>>> capacity
>>>>>>>>>>>>>>>>>>>>>>>>>>> to ensure a separate committer's
>>>>> approval.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
>>>>> Konstantin
>>>>>>>> Knauf
>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>> konstantin@ververica.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> thanks a lot for driving this,
>>>> Becket. I
>>>>>>> have
>>>>>>>>>> two
>>>>>>>>>>>>> remarks
>>>>>>>>>>>>>>>>> regarding
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Actions" section:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> * In addition to a simple "Code
>>>> Change"
>>>>> we
>>>>>>>> could
>>>>>>>>>>> also
>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>>>>> row for
>>>>>>>>>>>>>>>>>>>>>>>>>> "Code
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Change requiring a FLIP" with a
>>>>> reference
>>>>>> to
>>>>>>>> the
>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>> page.
>>>>>>>>>>>>>>>>>>>>>>> A
>>>>>>>>>>>>>>>>>>>>>>>>>> FLIP
>>>>>>>>>>>>>>>>>>>>>>>>>>>> will have/does have different
>> rules
>>>> for
>>>>>>>>>> approvals,
>>>>>>>>>>>> etc.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> * For "Code Change" the draft
>>>> currently
>>>>>>>> requires
>>>>>>>>>>> "one
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>>>>>>>>>>>>> committer
>>>>>>>>>>>>>>>>>>>>>>>>>>>> who has not authored the patch
>>>> followed
>>>>>> by a
>>>>>>>>>> Lazy
>>>>>>>>>>>>>> approval
>>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>>>>>>>>>> counting
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the vote of the contributor),
>> moving
>>>> to
>>>>>> lazy
>>>>>>>>>>> majority
>>>>>>>>>>>>> if
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> -1
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>> received".
>>>>>>>>>>>>>>>>>>>>>>>>>>>> In my understanding this means,
>>> that a
>>>>>>>> committer
>>>>>>>>>>>> always
>>>>>>>>>>>>>>>> needs a
>>>>>>>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 from another committer. As far
>>> as I
>>>>>> know
>>>>>>>>>> this is
>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the case (often committer authors,
>>>>>>> contributor
>>>>>>>>>>>> reviews
>>>>>>>>>>>>> &
>>>>>>>>>>>>>>>> +1s).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it is worth thinking about
>>> how
>>>>> we
>>>>>>> can
>>>>>>>>>> make
>>>>>>>>>>> it
>>>>>>>>>>>>>> easy
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws e.g. by having more
>>>>> Flink-specific
>>>>>>> Jira
>>>>>>>>>>>>> workflows
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>>>>>>>>> types +
>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding permissions. While
>>> this
>>>> is
>>>>>>>>>> certainly
>>>>>>>>>>>>> "Step
>>>>>>>>>>>>>>> 2",
>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>> believe,
>>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>>> really need to make it as easy &
>>>>>> transparent
>>>>>>>> as
>>>>>>>>>>>>> possible,
>>>>>>>>>>>>>>>>> otherwise
>>>>>>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be unintentionally broken.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers and thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
>>> Becket
>>>>>> Qin <
>>>>>>>>>>>>>>>>> becket.qin@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As it was raised in the FLIP
>>> process
>>>>>>>> discussion
>>>>>>>>>>>> thread
>>>>>>>>>>>>>>> [1],
>>>>>>>>>>>>>>>>>>>>>>> currently
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Flink
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not have official bylaws to
>>>> govern
>>>>>> the
>>>>>>>>>>>> operation
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> project.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Such
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bylaws are critical for the
>>> community
>>>>> to
>>>>>>>>>>> coordinate
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> contribute
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> together. It is also the basis of
>>>> other
>>>>>>>>>> processes
>>>>>>>>>>>> such
>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>> FLIP.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have drafted a Flink bylaws
>> page
>>>> and
>>>>>>> would
>>>>>>>>>> like
>>>>>>>>>>> to
>>>>>>>>>>>>>>> start a
>>>>>>>>>>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thread on this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The bylaws will affect everyone
>> in
>>>> the
>>>>>>>>>> community.
>>>>>>>>>>>>> It'll
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> great to
>>>>>>>>>>>>>>>>>>>>>>>>>> hear
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your thoughts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Konstantin Knauf | Solutions
>>> Architect
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> +49 160 91394525
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Planned Absences: 10.08.2019 -
>>>>> 31.08.2019,
>>>>>>>>>> 05.09. -
>>>>>>>>>>>>>>>> 06.09.2010
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH | Invalidenstrasse
>>> 115,
>>>>>> 10115
>>>>>>>>>>> Berlin,
>>>>>>>>>>>>>>> Germany
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ververica GmbH
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Registered at Amtsgericht
>>>>> Charlottenburg:
>>>>>>> HRB
>>>>>>>>>>> 158244
>>>>>>>>>>>> B
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Managing Directors: Dr. Kostas
>>>> Tzoumas,
>>>>>> Dr.
>>>>>>>>>> Stephan
>>>>>>>>>>>>> Ewen
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: [DISCUSS] Flink project bylaws

[Becket Qin <be...@gmail.com>]

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 <fh...@gmail.com> wrote:

> Thanks for the update and driving the discussion Becket!
> +1 for starting a vote.
>
> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <becket.qin@gmail.com
> >:
>
> > Thanks Stephan.
> >
> > I think we have resolved all the comments on the wiki page. There are two
> > minor changes made to the bylaws since last week.
> > 1. For 2/3 majority, the required attempts to reach out to binding voters
> > is reduced from 3 to 2. This helps shorten the voting process a little
> bit.
> > 2. Clarified what is considered as the adoption of new codebase.
> >
> > I think we almost reached consensus. I'll start a voting thread in two
> days
> > if there is no new concerns.
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org> wrote:
> >
> > > I added a clarification to the table, clarifying that the current
> > phrasing
> > > means that committers do not need another +1 for their commits.
> > >
> > > On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fh...@gmail.com>
> wrote:
> > >
> > > > Hi Becket,
> > > >
> > > > Thanks a lot for pushing this forward and addressing the feedback.
> > > > I'm very happy with the current state of the bylaws.
> > > > +1 to wait until Friday before starting a vote.
> > > >
> > > > Best, Fabian
> > > >
> > > > Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> > > > becket.qin@gmail.com
> > > > >:
> > > >
> > > > > Hi Everyone,
> > > > >
> > > > > Thanks for all the discussion and feedback.
> > > > >
> > > > > It seems that we have almost reached consensus. I'll leave the
> > > discussion
> > > > > thread open until this Friday. If there is no more concerns raised,
> > > I'll
> > > > > start a voting thread after that.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jiangjie (Becket) Qin
> > > > >
> > > > > On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com> wrote:
> > > > >
> > > > > > Hi Becket,
> > > > > >
> > > > > > Thanks for noticing and resolving my comment around PMC removal
> and
> > > ASF
> > > > > > rules of PMC membership change process, which you seem to neglect
> > in
> > > > the
> > > > > > summary of updates (smile).
> > > > > >
> > > > > > Best Regards,
> > > > > > Yu
> > > > > >
> > > > > >
> > > > > > On Wed, 24 Jul 2019 at 04:32, Becket Qin <be...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Hi folks,
> > > > > > >
> > > > > > > Thanks for all the feedback.
> > > > > > >
> > > > > > > It seems that there are a few concerns over the emeritus status
> > > > after 6
> > > > > > > months of inactivity. Given that the main purpose is just to
> make
> > > > sure
> > > > > > 2/3
> > > > > > > majority can pass and we sort of have a solution for that, I
> just
> > > > > updated
> > > > > > > the draft with the following changes:
> > > > > > >
> > > > > > > 1. Removed the inactivity term for emeritus committers / PMCs.
> A
> > > > > > committer
> > > > > > > / PMC will only be considered emeritus by their own claim.
> > > > > > > 2. Removed the approval process for reinstatement of the
> emeritus
> > > > > > > committers / PMCs. An emeritus committer / PMC will be
> reinstated
> > > > when
> > > > > > they
> > > > > > > send an email to the private@flink.apache.org.
> > > > > > > 3. Adde the term to ensure 2/3 majority voting is still doable
> > when
> > > > > there
> > > > > > > are non-emeritus committers / PMCs who do not cast the vote.
> > > > > > >
> > > > > > > Please let me know if you have any further thoughts.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Jiangjie (Becket) Qin
> > > > > > >
> > > > > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
> > becket.qin@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Fabian,
> > > > > > > >
> > > > > > > > Thanks for the feedback.
> > > > > > > >
> > > > > > > > I agree that if we don't like emeritus committers / PMCs, we
> > > don't
> > > > > have
> > > > > > > to
> > > > > > > > do it. That said, emeritus status simply means whether an
> > > > individual
> > > > > is
> > > > > > > > active / inactive in the community. It does not make the
> merits
> > > > > earned
> > > > > > to
> > > > > > > > go away. For our purpose, emeritus status is mostly just a
> way
> > to
> > > > > make
> > > > > > > 2/3
> > > > > > > > majority possible. As you noticed, since reaching out to
> > binding
> > > > > voters
> > > > > > > who
> > > > > > > > have not voted can achieve the same goal, the emeritus status
> > is
> > > > more
> > > > > > of
> > > > > > > an
> > > > > > > > optimization so we don't have to ping the inactive binding
> > voters
> > > > > every
> > > > > > > > time and wait for long. However, given that 2/3 majority
> > votings
> > > > are
> > > > > > > rare,
> > > > > > > > such communication cost is probably OK. So I think we can
> > remove
> > > > that
> > > > > > > > emeritus part from the bylaws.
> > > > > > > >
> > > > > > > > 1) We should add to the requirements of the PMC that they
> need
> > to
> > > > > make
> > > > > > > >> sure the project complies with brand issues and reports
> misuse
> > > of
> > > > > ASF
> > > > > > > >> brands.
> > > > > > > >
> > > > > > > > Good point. Added.
> > > > > > > >
> > > > > > > > 2) Do we want to restrict voting days to working days, i.e.,
> a
> > 3
> > > > day
> > > > > > vote
> > > > > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > > > > > >
> > > > > > > > This might be a little tricky because people are from
> countries
> > > in
> > > > > > > > different time zones and with different holidays, and so on.
> If
> > > we
> > > > > are
> > > > > > > > worrying about 3 days minimum length is not enough for those
> > who
> > > > want
> > > > > > to
> > > > > > > > give feedback, we can make it 5 days.
> > > > > > > >
> > > > > > > > 3) Do we need a process do decide about removal of features
> > (like
> > > > the
> > > > > > > >> DataSet API for instance or the legacy DataSet/DataStream
> > Python
> > > > > > APIs)?
> > > > > > > >
> > > > > > > > I assume such action should be covered by FLIP as it is a
> > change
> > > to
> > > > > the
> > > > > > > > API and probably needs a migration plan. It would be useful
> to
> > > > have a
> > > > > > > > formal deprecation procedure. But that might be better to be
> > put
> > > > into
> > > > > > > > somewhere else because the bylaws are primarily focusing on
> the
> > > > > > > > non-technical rules, whereas the deprecation seems more on
> the
> > > > > > technical
> > > > > > > > side.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Jiangjie (Becket) Qin
> > > > > > > >
> > > > > > > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
> > > fhueske@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Hi all,
> > > > > > > >>
> > > > > > > >> First of all thank you very much Becket for starting this
> > > > > discussion!
> > > > > > > >> I think it is a very good idea and overdue to formally
> define
> > > some
> > > > > of
> > > > > > > our
> > > > > > > >> community processes.
> > > > > > > >>
> > > > > > > >> Similar to Chesnay, I have concerns about the distinction
> > > between
> > > > > > active
> > > > > > > >> and non-active / emeritus committers and PMC members.
> > > > > > > >> My foremost concern is that this is not in the spirit of the
> > > > Apache
> > > > > > Way
> > > > > > > >> [1]
> > > > > > > >> which is (among other things) based on the idea of merit
> which
> > > > once
> > > > > > > >> earned,
> > > > > > > >> does not go away over time.
> > > > > > > >> I know other projects like Hadoop and Kafka have similar
> > clauses
> > > > in
> > > > > > the
> > > > > > > >> bylaws but IMO we don't need to adopt them if we don't like
> > > them.
> > > > > > > >> For example, I don't like the idea that committers or PMC
> > > members
> > > > > who
> > > > > > > are
> > > > > > > >> temporarily away from the project (for whatever reason:
> > parental
> > > > > > leave,
> > > > > > > >> sabbatical, health issues, etc.) need the PMC approval to be
> > > > > "active"
> > > > > > > >> again.
> > > > > > > >> As far as I am aware, we have not seen any issues with
> > inactive
> > > > > > members
> > > > > > > in
> > > > > > > >> the past.
> > > > > > > >> Moreover, it would be hard to track whether somebody became
> > > > inactive
> > > > > > at
> > > > > > > >> some point in time (which we would need to do, if I
> understand
> > > the
> > > > > > > >> proposal
> > > > > > > >> correctly).
> > > > > > > >> With the approach that Becket suggested in his last email
> > > > (reaching
> > > > > > out
> > > > > > > to
> > > > > > > >> binding voters who haven't voted yet), we could drop the
> > > > distinction
> > > > > > > >> between active and non-active committers and PMC members.
> > > > > > > >>
> > > > > > > >> I also have a few minor comments:
> > > > > > > >>
> > > > > > > >> 1) We should add to the requirements of the PMC [2] that
> they
> > > need
> > > > > to
> > > > > > > make
> > > > > > > >> sure the project complies with brand issues and reports
> misuse
> > > of
> > > > > ASF
> > > > > > > >> brands.
> > > > > > > >> 2) Do we want to restrict voting days to working days, i.e.,
> > a 3
> > > > day
> > > > > > > vote
> > > > > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > > > > > >> 3) Do we need a process do decide about removal of features
> > > (like
> > > > > the
> > > > > > > >> DataSet API for instance or the legacy DataSet/DataStream
> > Python
> > > > > > APIs)?
> > > > > > > >>
> > > > > > > >> Thank you,
> > > > > > > >> Fabian
> > > > > > > >>
> > > > > > > >> [1] https://www.apache.org/theapacheway/
> > > > > > > >> [2] https://www.apache.org/dev/pmc.html
> > > > > > > >>
> > > > > > > >> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> > > > > > > >> becket.qin@gmail.com
> > > > > > > >> >:
> > > > > > > >>
> > > > > > > >> > Hi Hequn,
> > > > > > > >> >
> > > > > > > >> > Thanks for sharing your thoughts. Please see the reply
> > below:
> > > > > > > >> >
> > > > > > > >> > > Perhaps what Jincheng means is to hold at least one PMC
> in
> > > > the 3
> > > > > > > >> binding
> > > > > > > >> > > votes? i.e, the vote could have 2 binding committers
> and 1
> > > > PMC.
> > > > > > > >> > > I think this makes sense considering a FLIP could
> somehow
> > > be a
> > > > > big
> > > > > > > >> > feature
> > > > > > > >> > > which may impacts Flink a lot. Meanwhile, there is no
> loss
> > > of
> > > > > > > >> flexibility
> > > > > > > >> > > as committers also have a chance to vote and participate
> > in
> > > > it.
> > > > > > > >> > A few concerns of requiring a PMC vote in all FLIPs are
> the
> > > > > > following:
> > > > > > > >> >
> > > > > > > >> > 1. Generally speaking, the PMC's primary responsibility is
> > > > > operating
> > > > > > > the
> > > > > > > >> > project and deciding what software to release on behalf of
> > > ASF.
> > > > > > > >> Committers,
> > > > > > > >> > on the other hand, are responsible for the technical part
> of
> > > the
> > > > > > > >> project.
> > > > > > > >> > So for FLIPs, a PMC's vote probably should not outweigh a
> > > > > > committer's
> > > > > > > >> vote.
> > > > > > > >> > Besides, I am not sure whether a single PMCs +1 is really
> > > > > convincing
> > > > > > > >> enough
> > > > > > > >> > to decide whether the FLIP is good to go or not. Also, if
> > some
> > > > > > > >> committers
> > > > > > > >> > have concern over a FLIP, they could just veto it. To me
> it
> > is
> > > > > > > actually
> > > > > > > >> a
> > > > > > > >> > more strict requirement to pass a FLIP than asking a PMC
> to
> > > > vote.
> > > > > In
> > > > > > > >> > practice, people will usually also address the concerns
> even
> > > if
> > > > > they
> > > > > > > are
> > > > > > > >> > not from a PMC/committer before they start the voting
> > process.
> > > > So
> > > > > I
> > > > > > > >> don't
> > > > > > > >> > see much benefit of requiring a PMC's vote in this case.
> > > > > > > >> >
> > > > > > > >> > 2. The at-least-one-PMC-vote requirement makes the votes
> no
> > > > longer
> > > > > > > >> > independent. Ideally, a vote is either binding or
> > non-binding
> > > by
> > > > > > > >> itself. If
> > > > > > > >> > we have the at-least-one-PMC-vote requirement here,
> imagine
> > > > there
> > > > > > have
> > > > > > > >> been
> > > > > > > >> > 3 committers who voted +1. But the FLIP still has not
> > passed,
> > > so
> > > > > > those
> > > > > > > >> > votes are effectively non-binding. Now a PMC votes a +1,
> > those
> > > > > votes
> > > > > > > >> > suddenly become binding, which is a little awkward.
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > The lazy 2/3 majority suggestion sounds reasonable to me.
> > Some
> > > > > > > thoughts
> > > > > > > >> on
> > > > > > > >> > this:
> > > > > > > >> > 1. One reason Hadoop uses lazy 2/3 majority is probably
> > > because
> > > > > > there
> > > > > > > >> are
> > > > > > > >> > 104 PMC members[1] for Hadoop which makes the 2/3 majority
> > > > > > > prohibitively
> > > > > > > >> > expensive. In our case, there are only 22 PMCs for
> Flink[2]
> > > and
> > > > a
> > > > > > > quick
> > > > > > > >> > search shows at most 6 of them have not sent email in the
> > > > recent 6
> > > > > > > >> months
> > > > > > > >> > or so.
> > > > > > > >> >
> > > > > > > >> > 2. 2/3 majority votes are supposed to be very rare. It is
> > > > designed
> > > > > > in
> > > > > > > >> > particular for the cases that broad opinions are
> important,
> > > more
> > > > > > > >> > specifically new codebase adoption or modification to the
> > > > bylaws.
> > > > > > > >> Therefore
> > > > > > > >> > such vote by its nature favors consensus over convenience.
> > > That
> > > > > > means
> > > > > > > >> any
> > > > > > > >> > alternative voting type reducing the coverage worth a
> > careful
> > > > > > > thinking.
> > > > > > > >> >
> > > > > > > >> > 3. I do agree that it does not make sense to have 2/3
> > majority
> > > > if
> > > > > > such
> > > > > > > >> > requirement is no-longer doable over time. But I am a
> little
> > > > > > hesitant
> > > > > > > to
> > > > > > > >> > lower the threshold to lazy 2/3 majority in our case. What
> > do
> > > > you
> > > > > > > think
> > > > > > > >> > about doing the following:
> > > > > > > >> >     - After the voting started, there will be at least 6
> > days
> > > > for
> > > > > > > >> people to
> > > > > > > >> > cast their votes.
> > > > > > > >> >     - After 6 days, if the result of the vote is still not
> > > > > > determined,
> > > > > > > >> the
> > > > > > > >> > person who started the vote should reach out to the
> binding
> > > > voters
> > > > > > who
> > > > > > > >> have
> > > > > > > >> > not voted yet for at least 3 times and at least 7 days
> > between
> > > > > each
> > > > > > > >> time.
> > > > > > > >> > If a binding voter still did not respond, the vote from
> that
> > > > voter
> > > > > > > will
> > > > > > > >> be
> > > > > > > >> > excluded from the 2/3 majority counting.
> > > > > > > >> > This would ensure the coverage at our best effort while
> > still
> > > > let
> > > > > > the
> > > > > > > >> 2/3
> > > > > > > >> > majority vote make progress.
> > > > > > > >> >
> > > > > > > >> > Thanks,
> > > > > > > >> >
> > > > > > > >> > Jiangjie (Becket) Qin
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > [1] https://projects.apache.org/committee.html?hadoop
> > > > > > > >> > [2] https://projects.apache.org/committee.html?flink
> > > > > > > >> >
> > > > > > > >> > On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> > > > > forwardxu315@gmail.com>
> > > > > > > >> wrote:
> > > > > > > >> >
> > > > > > > >> > > Big +1 on this.
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > best
> > > > > > > >> > >
> > > > > > > >> > > forward
> > > > > > > >> > >
> > > > > > > >> > > Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
> > 下午1:30写道：
> > > > > > > >> > >
> > > > > > > >> > > > Hi Becket,
> > > > > > > >> > > >
> > > > > > > >> > > > Big +1 on this.
> > > > > > > >> > > >
> > > > > > > >> > > > > Regarding the vote of FLIP, preferably at least
> > > includes a
> > > > > PMC
> > > > > > > >> vote.
> > > > > > > >> > > > Perhaps what Jincheng means is to hold at least one
> PMC
> > in
> > > > > the 3
> > > > > > > >> > binding
> > > > > > > >> > > > votes? i.e, the vote could have 2 binding committers
> > and 1
> > > > > PMC.
> > > > > > > >> > > > I think this makes sense considering a FLIP could
> > somehow
> > > > be a
> > > > > > big
> > > > > > > >> > > feature
> > > > > > > >> > > > which may impacts Flink a lot. Meanwhile, there is no
> > loss
> > > > of
> > > > > > > >> > flexibility
> > > > > > > >> > > > as committers also have a chance to vote and
> participate
> > > in
> > > > > it.
> > > > > > > >> > > >
> > > > > > > >> > > > ========Seperator========
> > > > > > > >> > > >
> > > > > > > >> > > > For the nice bylaws, I agree with the general idea and
> > > most
> > > > of
> > > > > > the
> > > > > > > >> > > content.
> > > > > > > >> > > > Only share some thoughts about the "2/3 Majority". The
> > > main
> > > > > > > concern
> > > > > > > >> is
> > > > > > > >> > I
> > > > > > > >> > > am
> > > > > > > >> > > > not sure if it is doable in practice. The reasons are:
> > > > > > > >> > > >
> > > > > > > >> > > > 1. If we follow the bylaws strictly, it means a
> > committer
> > > > or a
> > > > > > PMC
> > > > > > > >> > member
> > > > > > > >> > > > is active if he or she sends one email to the mailing
> > list
> > > > > > every 6
> > > > > > > >> > > months.
> > > > > > > >> > > > While the minimum length of the vote is only 6 days.
> > There
> > > > are
> > > > > > > >> chances
> > > > > > > >> > > that
> > > > > > > >> > > > during the vote, some of the active members are still
> > > > offline
> > > > > of
> > > > > > > the
> > > > > > > >> > > > community.
> > > > > > > >> > > > 2. The code of Flink is changing fast and not everyone
> > > fully
> > > > > > > >> > understands
> > > > > > > >> > > > every part. We don't need to force people to vote if
> > they
> > > > are
> > > > > > not
> > > > > > > >> sure
> > > > > > > >> > > > about it. It may also make the final result less
> > credible.
> > > > > > > >> > > >
> > > > > > > >> > > > Given the above reasons, perhaps we can change the 2/3
> > > > > Majority
> > > > > > to
> > > > > > > >> lazy
> > > > > > > >> > > 2/3
> > > > > > > >> > > > Majority, just as the Hadoop bylaws[1]. It makes a
> > higher
> > > > > > > threshold,
> > > > > > > >> > > > however, more practical.
> > > > > > > >> > > >
> > > > > > > >> > > > What do you think?
> > > > > > > >> > > >
> > > > > > > >> > > > [1] https://hadoop.apache.org/bylaws.html
> > > > > > > >> > > >
> > > > > > > >> > > > On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> > > > > > becket.qin@gmail.com
> > > > > > > >
> > > > > > > >> > > wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > > Hi Jincheng,
> > > > > > > >> > > > >
> > > > > > > >> > > > > Thanks for the comments. I replied on the wiki page.
> > > Just
> > > > a
> > > > > > > brief
> > > > > > > >> > > > summary,
> > > > > > > >> > > > > the current bylaws do require some of the FLIPs to
> get
> > > PMC
> > > > > > > >> approval
> > > > > > > >> > if
> > > > > > > >> > > > > their impact is big enough. But it leaves majority
> of
> > > the
> > > > > > > >> technical
> > > > > > > >> > > > > decisions to the committers who are supposed to be
> > > > > responsible
> > > > > > > for
> > > > > > > >> > > making
> > > > > > > >> > > > > such decisions.
> > > > > > > >> > > > >
> > > > > > > >> > > > > Re: Robert,
> > > > > > > >> > > > >
> > > > > > > >> > > > > I agree we can simply remove the requirement of +1
> > from
> > > a
> > > > > > > >> non-author
> > > > > > > >> > > > > committer and revisit it in a bit. After all, it
> does
> > > not
> > > > > make
> > > > > > > >> sense
> > > > > > > >> > to
> > > > > > > >> > > > > have a bylaw that we cannot afford. I have just
> > updated
> > > > the
> > > > > > > bylaws
> > > > > > > >> > > wiki.
> > > > > > > >> > > > >
> > > > > > > >> > > > > Thanks,
> > > > > > > >> > > > >
> > > > > > > >> > > > > Jiangjie (Becket) Qin
> > > > > > > >> > > > >
> > > > > > > >> > > > > On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> > > > > > > >> rmetzger@apache.org
> > > > > > > >> > >
> > > > > > > >> > > > > wrote:
> > > > > > > >> > > > >
> > > > > > > >> > > > > > Hi all,
> > > > > > > >> > > > > > I agree with Aljoscha that trying to reflect the
> > > current
> > > > > > > status
> > > > > > > >> in
> > > > > > > >> > > the
> > > > > > > >> > > > > > bylaws, and then implementing changes one by one
> is
> > a
> > > > very
> > > > > > > >> involved
> > > > > > > >> > > > task.
> > > > > > > >> > > > > > Unless there's somebody who's really eager to
> drive
> > > > this,
> > > > > I
> > > > > > > >> would
> > > > > > > >> > > stick
> > > > > > > >> > > > > to
> > > > > > > >> > > > > > Becket's initiative to come up with Bylaws for
> > Flink,
> > > > even
> > > > > > if
> > > > > > > >> this
> > > > > > > >> > > > means
> > > > > > > >> > > > > > some changes.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > The cross-review requirement is the last big open
> > > point
> > > > in
> > > > > > > this
> > > > > > > >> > > > > discussion.
> > > > > > > >> > > > > > It seems that a there is a slight tendency in the
> > > > > discussion
> > > > > > > >> that
> > > > > > > >> > > this
> > > > > > > >> > > > is
> > > > > > > >> > > > > > not feasible given the current pull request review
> > > > > > situation.
> > > > > > > >> > > > > > For the sake of bringing this discussion to a
> > > > conclusion,
> > > > > > I'm
> > > > > > > >> fine
> > > > > > > >> > > with
> > > > > > > >> > > > > > leaving this requirement out. As we are currently
> > > adding
> > > > > > more
> > > > > > > >> > > > committers
> > > > > > > >> > > > > to
> > > > > > > >> > > > > > the project, we might be able to revisit this
> > > discussion
> > > > > in
> > > > > > 3
> > > > > > > -
> > > > > > > >> 6
> > > > > > > >> > > > months.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> > > > > > > >> > > sunjincheng121@gmail.com
> > > > > > > >> > > > >
> > > > > > > >> > > > > > wrote:
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > Hi Becket,
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > Thanks for the proposal.
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > Regarding the vote of FLIP, preferably at least
> > > > > includes a
> > > > > > > PMC
> > > > > > > >> > > vote.
> > > > > > > >> > > > > > > Because FLIP is usually a big change or affects
> > the
> > > > > user's
> > > > > > > >> > > interface
> > > > > > > >> > > > > > > changes. What do you think? (I leave the comment
> > in
> > > > the
> > > > > > > wiki.)
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > Best,
> > > > > > > >> > > > > > > Jincheng
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > Dawid Wysakowicz <dw...@apache.org>
> > > > 于2019年7月17日周三
> > > > > > > >> > 下午9:12写道：
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > > Hi all,
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > Sorry for joining late. I just wanted to say
> > that
> > > I
> > > > > > really
> > > > > > > >> like
> > > > > > > >> > > the
> > > > > > > >> > > > > > > > proposed bylaws!
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > One comment, I also have the same concerns as
> > > > > expressed
> > > > > > by
> > > > > > > >> few
> > > > > > > >> > > > people
> > > > > > > >> > > > > > > > before that the "committer +1" on code change
> > > might
> > > > be
> > > > > > > hard
> > > > > > > >> to
> > > > > > > >> > > > > achieve
> > > > > > > >> > > > > > > > currently. On the other hand I would say this
> > > would
> > > > be
> > > > > > > >> > beneficial
> > > > > > > >> > > > for
> > > > > > > >> > > > > > > > the quality/uniformity of our codebase and
> > > knowledge
> > > > > > > >> sharing.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > I was just wondering what should be the next
> > step
> > > > for
> > > > > > > this?
> > > > > > > >> I
> > > > > > > >> > > think
> > > > > > > >> > > > > it
> > > > > > > >> > > > > > > > would make sense to already use those bylaws
> and
> > > put
> > > > > > them
> > > > > > > to
> > > > > > > >> > PMC
> > > > > > > >> > > > > vote.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > Best,
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > Dawid
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > > > > >> > > > > > > > > Hi Aljoscha and Becket
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > Right, 3 days for FLIP voting is fine I
> think.
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > >>> I’m missing this stated somewhere clearly.
> > If
> > > we
> > > > > are
> > > > > > > >> > stating
> > > > > > > >> > > > > that a
> > > > > > > >> > > > > > > > single
> > > > > > > >> > > > > > > > >>> committers +1 is good enough for code
> > review,
> > > > > with 0
> > > > > > > >> hours
> > > > > > > >> > > > delay
> > > > > > > >> > > > > > (de
> > > > > > > >> > > > > > > > facto
> > > > > > > >> > > > > > > > >>> the current state), we should also write
> > down
> > > > that
> > > > > > > this
> > > > > > > >> is
> > > > > > > >> > > > > subject
> > > > > > > >> > > > > > to
> > > > > > > >> > > > > > > > the
> > > > > > > >> > > > > > > > >>> best judgement of the committer to respect
> > the
> > > > > > > >> components
> > > > > > > >> > > > > expertise
> > > > > > > >> > > > > > > and
> > > > > > > >> > > > > > > > >>> ongoing development plans (also the de
> facto
> > > > > current
> > > > > > > >> > state).
> > > > > > > >> > > > > > > > >> Adding the statement would help clarify the
> > > > > > intention,
> > > > > > > >> but
> > > > > > > >> > it
> > > > > > > >> > > > may
> > > > > > > >> > > > > > be a
> > > > > > > >> > > > > > > > >> little difficult to enforce and follow..
> > > > > > > >> > > > > > > > > I would be fine with that, it’s a soft/vague
> > > rule
> > > > > > > anyway,
> > > > > > > >> > > > intended
> > > > > > > >> > > > > to
> > > > > > > >> > > > > > > be
> > > > > > > >> > > > > > > > used with your “best judgemenet". I would like
> > to
> > > > just
> > > > > > > >> avoid a
> > > > > > > >> > > > > > situation
> > > > > > > >> > > > > > > > when someone violates current uncodified state
> > and
> > > > > > refers
> > > > > > > to
> > > > > > > >> > the
> > > > > > > >> > > > > bylaws
> > > > > > > >> > > > > > > > which are saying merging with any committer +1
> > is
> > > > > always
> > > > > > > >> fine
> > > > > > > >> > > (like
> > > > > > > >> > > > > > mine
> > > > > > > >> > > > > > > +1
> > > > > > > >> > > > > > > > for flink-python or flink-ml).
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > > Piotrek
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek
> <
> > > > > > > >> > > aljoscha@apache.org
> > > > > > > >> > > > >
> > > > > > > >> > > > > > > wrote:
> > > > > > > >> > > > > > > > >>
> > > > > > > >> > > > > > > > >> @Piotr regarding the 3 days voting on the
> > FLIP.
> > > > > This
> > > > > > is
> > > > > > > >> just
> > > > > > > >> > > > about
> > > > > > > >> > > > > > the
> > > > > > > >> > > > > > > > voting, before that there needs to be the
> > > discussion
> > > > > > > >> thread. If
> > > > > > > >> > > > three
> > > > > > > >> > > > > > > days
> > > > > > > >> > > > > > > > have passed on a vote and there is consensus
> > > (i.e. 3
> > > > > > > >> > > > committers/PMCs
> > > > > > > >> > > > > > have
> > > > > > > >> > > > > > > > voted +1) that seems a high enough bar for me.
> > So
> > > > far,
> > > > > > we
> > > > > > > >> have
> > > > > > > >> > > > rarely
> > > > > > > >> > > > > > see
> > > > > > > >> > > > > > > > any FLIPs pass that formal bar.
> > > > > > > >> > > > > > > > >>
> > > > > > > >> > > > > > > > >> According to the recent META-FLIP thread,
> we
> > > want
> > > > > to
> > > > > > > use
> > > > > > > >> > "lazy
> > > > > > > >> > > > > > > > majority" for the FLIP voting process. I think
> > > that
> > > > > > should
> > > > > > > >> be
> > > > > > > >> > > > changed
> > > > > > > >> > > > > > > from
> > > > > > > >> > > > > > > > “consensus” in the proposed bylaws.
> > > > > > > >> > > > > > > > >>
> > > > > > > >> > > > > > > > >> Regarding the current state: do we have a
> > > current
> > > > > > state
> > > > > > > >> that
> > > > > > > >> > > we
> > > > > > > >> > > > > all
> > > > > > > >> > > > > > > > agree on? I have the feeling that if we try to
> > > come
> > > > up
> > > > > > > with
> > > > > > > >> > > > something
> > > > > > > >> > > > > > > that
> > > > > > > >> > > > > > > > reflects the common state, according to
> > > > > PMCs/commiters,
> > > > > > > that
> > > > > > > >> > > might
> > > > > > > >> > > > > > take a
> > > > > > > >> > > > > > > > very long time. In that case I think it’s
> better
> > > to
> > > > > > adopt
> > > > > > > >> > > something
> > > > > > > >> > > > > > that
> > > > > > > >> > > > > > > we
> > > > > > > >> > > > > > > > all like, rather than trying to capture how we
> > do
> > > it
> > > > > > now.
> > > > > > > >> > > > > > > > >>
> > > > > > > >> > > > > > > > >> Aljoscha
> > > > > > > >> > > > > > > > >>
> > > > > > > >> > > > > > > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski
> <
> > > > > > > >> > > piotr@ververica.com
> > > > > > > >> > > > >
> > > > > > > >> > > > > > > wrote:
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>> Hi,
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>> Thanks for the proposal. Generally
> speaking
> > +1
> > > > > from
> > > > > > my
> > > > > > > >> side
> > > > > > > >> > > to
> > > > > > > >> > > > > the
> > > > > > > >> > > > > > > > general idea and most of the content. I also
> see
> > > > merit
> > > > > > to
> > > > > > > >> the
> > > > > > > >> > > > > Chesney's
> > > > > > > >> > > > > > > > proposal to start from the current state. I
> > think
> > > > > either
> > > > > > > >> would
> > > > > > > >> > be
> > > > > > > >> > > > > fine
> > > > > > > >> > > > > > > for
> > > > > > > >> > > > > > > > me.
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>> Couple of comments:
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>> 1.
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>> I also think that requiring +1 from
> another
> > > > > > committer
> > > > > > > >> would
> > > > > > > >> > > > slow
> > > > > > > >> > > > > > down
> > > > > > > >> > > > > > > > and put even more strain on the current
> > reviewing
> > > > > > > bottleneck
> > > > > > > >> > that
> > > > > > > >> > > > we
> > > > > > > >> > > > > > are
> > > > > > > >> > > > > > > > having. Even if the change clear and simple,
> > > context
> > > > > > > switch
> > > > > > > >> > cost
> > > > > > > >> > > is
> > > > > > > >> > > > > > quite
> > > > > > > >> > > > > > > > high, and that’s just one less PR that the
> > second
> > > > > > “cross”
> > > > > > > >> > > committer
> > > > > > > >> > > > > > could
> > > > > > > >> > > > > > > > have reviewed somewhere else in that time.
> > > Besides,
> > > > > > > current
> > > > > > > >> > setup
> > > > > > > >> > > > > that
> > > > > > > >> > > > > > we
> > > > > > > >> > > > > > > > have (with no cross +1 from another committer
> > > > > required)
> > > > > > > >> works
> > > > > > > >> > > quite
> > > > > > > >> > > > > > well
> > > > > > > >> > > > > > > > and I do not feel that’s causing troubles. On
> > the
> > > > > other
> > > > > > > hand
> > > > > > > >> > > > > reviewing
> > > > > > > >> > > > > > > > bottleneck is.
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>> 2.
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>>> I think a committer should know when to
> ask
> > > > > another
> > > > > > > >> > > committer
> > > > > > > >> > > > > for
> > > > > > > >> > > > > > > > feedback or not.
> > > > > > > >> > > > > > > > >>> I’m missing this stated somewhere clearly.
> > If
> > > we
> > > > > are
> > > > > > > >> > stating
> > > > > > > >> > > > > that a
> > > > > > > >> > > > > > > > single committers +1 is good enough for code
> > > review,
> > > > > > with
> > > > > > > 0
> > > > > > > >> > hours
> > > > > > > >> > > > > delay
> > > > > > > >> > > > > > > (de
> > > > > > > >> > > > > > > > facto the current state), we should also write
> > > down
> > > > > that
> > > > > > > >> this
> > > > > > > >> > is
> > > > > > > >> > > > > > subject
> > > > > > > >> > > > > > > to
> > > > > > > >> > > > > > > > the best judgement of the committer to respect
> > the
> > > > > > > >> components
> > > > > > > >> > > > > expertise
> > > > > > > >> > > > > > > and
> > > > > > > >> > > > > > > > ongoing development plans (also the de facto
> > > current
> > > > > > > state).
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>> 3.
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>> Minimum length of 3 days for FLIP I think
> > > > > currently
> > > > > > > >> might
> > > > > > > >> > be
> > > > > > > >> > > > > > > > problematic/too quick and can lead to problems
> > if
> > > > > > > respected
> > > > > > > >> to
> > > > > > > >> > > the
> > > > > > > >> > > > > > > letter.
> > > > > > > >> > > > > > > > Again I think it depends highly on whether the
> > > > > > committers
> > > > > > > >> with
> > > > > > > >> > > > > highest
> > > > > > > >> > > > > > > > expertise in the affected components managed
> to
> > > > > respond
> > > > > > or
> > > > > > > >> not.
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>> Piotrek
> > > > > > > >> > > > > > > > >>>
> > > > > > > >> > > > > > > > >>>> On 12 Jul 2019, at 09:42, Chesnay
> Schepler
> > <
> > > > > > > >> > > > chesnay@apache.org>
> > > > > > > >> > > > > > > > wrote:
> > > > > > > >> > > > > > > > >>>>
> > > > > > > >> > > > > > > > >>>> I'm wondering whether we shouldn't first
> > > write
> > > > > down
> > > > > > > >> Bylaws
> > > > > > > >> > > > that
> > > > > > > >> > > > > > > > reflect the current state, and then have
> > separate
> > > > > > > >> discussions
> > > > > > > >> > for
> > > > > > > >> > > > > > > > individual amendments. My gut feeling is that
> > this
> > > > > > > >> discussion
> > > > > > > >> > > will
> > > > > > > >> > > > > > > quickly
> > > > > > > >> > > > > > > > become a chaotic mess with plenty points being
> > > > > discussed
> > > > > > > at
> > > > > > > >> > once.
> > > > > > > >> > > > > > > > >>>>
> > > > > > > >> > > > > > > > >>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > > > > > >> > > > > > > > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
> > Qin
> > > <
> > > > > > > >> > > > > > becket.qin@gmail.com>
> > > > > > > >> > > > > > > > wrote:
> > > > > > > >> > > > > > > > >>>>>
> > > > > > > >> > > > > > > > >>>>>> Thanks everyone for all the comments
> and
> > > > > > feedback.
> > > > > > > >> > Please
> > > > > > > >> > > > see
> > > > > > > >> > > > > > the
> > > > > > > >> > > > > > > > replies
> > > > > > > >> > > > > > > > >>>>>> below:
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> --------------------------------
> > > > > > > >> > > > > > > > >>>>>> Re: Konstantin
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>>> * In addition to a simple "Code
> Change"
> > we
> > > > > could
> > > > > > > >> also
> > > > > > > >> > > add a
> > > > > > > >> > > > > row
> > > > > > > >> > > > > > > > for "Code
> > > > > > > >> > > > > > > > >>>>>>> Change requiring a FLIP" with a
> > reference
> > > to
> > > > > the
> > > > > > > >> FLIP
> > > > > > > >> > > > process
> > > > > > > >> > > > > > > > page. A
> > > > > > > >> > > > > > > > >>>>>> FLIP
> > > > > > > >> > > > > > > > >>>>>>> will have/does have different rules
> for
> > > > > > approvals,
> > > > > > > >> etc.
> > > > > > > >> > > > > > > > >>>>>> Good point. Just added the entry.
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> -------------------------------
> > > > > > > >> > > > > > > > >>>>>> Re: Konstantin
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>>> * For "Code Change" the draft
> currently
> > > > > requires
> > > > > > > >> "one
> > > > > > > >> > +1
> > > > > > > >> > > > > from a
> > > > > > > >> > > > > > > > committer
> > > > > > > >> > > > > > > > >>>>>>> who has not authored the patch
> followed
> > > by a
> > > > > > Lazy
> > > > > > > >> > > approval
> > > > > > > >> > > > > (not
> > > > > > > >> > > > > > > > counting
> > > > > > > >> > > > > > > > >>>>>>> the vote of the contributor), moving
> to
> > > lazy
> > > > > > > >> majority
> > > > > > > >> > if
> > > > > > > >> > > a
> > > > > > > >> > > > -1
> > > > > > > >> > > > > > is
> > > > > > > >> > > > > > > > >>>>>> received".
> > > > > > > >> > > > > > > > >>>>>>> In my understanding this means, that a
> > > > > committer
> > > > > > > >> always
> > > > > > > >> > > > > needs a
> > > > > > > >> > > > > > > > review
> > > > > > > >> > > > > > > > >>>>>> and
> > > > > > > >> > > > > > > > >>>>>>> +1 from another committer. As far as I
> > > know
> > > > > this
> > > > > > > is
> > > > > > > >> > > > currently
> > > > > > > >> > > > > > not
> > > > > > > >> > > > > > > > always
> > > > > > > >> > > > > > > > >>>>>>> the case (often committer authors,
> > > > contributor
> > > > > > > >> reviews
> > > > > > > >> > &
> > > > > > > >> > > > > +1s).
> > > > > > > >> > > > > > > > >>>>>>>
> > > > > > > >> > > > > > > > >>>>>> I think it is worth thinking about how
> we
> > > can
> > > > > > make
> > > > > > > it
> > > > > > > >> > easy
> > > > > > > >> > > > to
> > > > > > > >> > > > > > > > follow the
> > > > > > > >> > > > > > > > >>>>>>> bylaws e.g. by having more
> > Flink-specific
> > > > Jira
> > > > > > > >> > workflows
> > > > > > > >> > > > and
> > > > > > > >> > > > > > > ticket
> > > > > > > >> > > > > > > > >>>>>> types +
> > > > > > > >> > > > > > > > >>>>>>> corresponding permissions. While this
> is
> > > > > > certainly
> > > > > > > >> > "Step
> > > > > > > >> > > > 2",
> > > > > > > >> > > > > I
> > > > > > > >> > > > > > > > believe,
> > > > > > > >> > > > > > > > >>>>>> we
> > > > > > > >> > > > > > > > >>>>>>> really need to make it as easy &
> > > transparent
> > > > > as
> > > > > > > >> > possible,
> > > > > > > >> > > > > > > > otherwise they
> > > > > > > >> > > > > > > > >>>>>>> will be unintentionally broken.
> > > > > > > >> > > > > > > > >>>>>> & Re: Till
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>>> For the case of a committer being the
> > > author
> > > > > and
> > > > > > > >> > getting
> > > > > > > >> > > a
> > > > > > > >> > > > +1
> > > > > > > >> > > > > > > from
> > > > > > > >> > > > > > > > a
> > > > > > > >> > > > > > > > >>>>>>> non-committer: I think a committer
> > should
> > > > know
> > > > > > > when
> > > > > > > >> to
> > > > > > > >> > > ask
> > > > > > > >> > > > > > > another
> > > > > > > >> > > > > > > > >>>>>>> committer for feedback or not. Hence,
> I
> > > > would
> > > > > > not
> > > > > > > >> > enforce
> > > > > > > >> > > > > that
> > > > > > > >> > > > > > we
> > > > > > > >> > > > > > > > >>>>>> strictly
> > > > > > > >> > > > > > > > >>>>>>> need a +1 from a committer if the
> author
> > > is
> > > > a
> > > > > > > >> committer
> > > > > > > >> > > but
> > > > > > > >> > > > > of
> > > > > > > >> > > > > > > > course
> > > > > > > >> > > > > > > > >>>>>>> encourage it if capacities exist.
> > > > > > > >> > > > > > > > >>>>>> I am with Robert and Aljoscha on this.
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> I completely understand the concern
> here.
> > > > TBH,
> > > > > in
> > > > > > > >> Kafka
> > > > > > > >> > > > > > > occasionally
> > > > > > > >> > > > > > > > >>>>>> trivial patches from committers are
> still
> > > > > merged
> > > > > > > >> without
> > > > > > > >> > > > > > following
> > > > > > > >> > > > > > > > the
> > > > > > > >> > > > > > > > >>>>>> cross-review requirement, but it is
> rare.
> > > > That
> > > > > > > said,
> > > > > > > >> I
> > > > > > > >> > > still
> > > > > > > >> > > > > > think
> > > > > > > >> > > > > > > > an
> > > > > > > >> > > > > > > > >>>>>> additional committer's review makes
> sense
> > > due
> > > > > to
> > > > > > > the
> > > > > > > >> > > > following
> > > > > > > >> > > > > > > > reasons:
> > > > > > > >> > > > > > > > >>>>>> 1. The bottom line here is that we need
> > to
> > > > make
> > > > > > > sure
> > > > > > > >> > every
> > > > > > > >> > > > > patch
> > > > > > > >> > > > > > > is
> > > > > > > >> > > > > > > > >>>>>> reviewed with a high quality. This is a
> > > > little
> > > > > > > >> difficult
> > > > > > > >> > > to
> > > > > > > >> > > > > > > > guarantee if
> > > > > > > >> > > > > > > > >>>>>> the review comes from a contributor for
> > > many
> > > > > > > >> reasons. In
> > > > > > > >> > > > some
> > > > > > > >> > > > > > > > cases, a
> > > > > > > >> > > > > > > > >>>>>> contributor may not have enough
> knowledge
> > > > about
> > > > > > the
> > > > > > > >> > > project
> > > > > > > >> > > > to
> > > > > > > >> > > > > > > make
> > > > > > > >> > > > > > > > a good
> > > > > > > >> > > > > > > > >>>>>> judgement. Also sometimes the
> > contributors
> > > > are
> > > > > > more
> > > > > > > >> > > eagerly
> > > > > > > >> > > > to
> > > > > > > >> > > > > > > get a
> > > > > > > >> > > > > > > > >>>>>> particular issue fixed, so they are
> > willing
> > > > to
> > > > > > > lower
> > > > > > > >> the
> > > > > > > >> > > > > review
> > > > > > > >> > > > > > > bar.
> > > > > > > >> > > > > > > > >>>>>> 2. One byproduct of such cross review
> > among
> > > > > > > >> committers,
> > > > > > > >> > > > which
> > > > > > > >> > > > > I
> > > > > > > >> > > > > > > > personally
> > > > > > > >> > > > > > > > >>>>>> feel useful, is that it helps gradually
> > > form
> > > > > > > >> consistent
> > > > > > > >> > > > design
> > > > > > > >> > > > > > > > principles
> > > > > > > >> > > > > > > > >>>>>> and code style. This is because the
> > > > committers
> > > > > > will
> > > > > > > >> know
> > > > > > > >> > > how
> > > > > > > >> > > > > the
> > > > > > > >> > > > > > > > other
> > > > > > > >> > > > > > > > >>>>>> committers are writing code and learn
> > from
> > > > each
> > > > > > > >> other.
> > > > > > > >> > So
> > > > > > > >> > > > they
> > > > > > > >> > > > > > > tend
> > > > > > > >> > > > > > > > to
> > > > > > > >> > > > > > > > >>>>>> reach some tacit understanding on how
> > > things
> > > > > > should
> > > > > > > >> be
> > > > > > > >> > > done
> > > > > > > >> > > > in
> > > > > > > >> > > > > > > > general.
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> Another way to think about this is to
> > > > consider
> > > > > > the
> > > > > > > >> > > following
> > > > > > > >> > > > > two
> > > > > > > >> > > > > > > > scenarios:
> > > > > > > >> > > > > > > > >>>>>> 1. Reviewing a committer's patch takes
> a
> > > lot
> > > > of
> > > > > > > >> > > iterations.
> > > > > > > >> > > > > Then
> > > > > > > >> > > > > > > > the patch
> > > > > > > >> > > > > > > > >>>>>> needs to be reviewed even if it takes
> > time
> > > > > > because
> > > > > > > >> there
> > > > > > > >> > > are
> > > > > > > >> > > > > > > things
> > > > > > > >> > > > > > > > >>>>>> actually needs to be clarified /
> changed.
> > > > > > > >> > > > > > > > >>>>>> 2. Reviewing a committer's patch is
> very
> > > > smooth
> > > > > > and
> > > > > > > >> > quick,
> > > > > > > >> > > > so
> > > > > > > >> > > > > > the
> > > > > > > >> > > > > > > > patch is
> > > > > > > >> > > > > > > > >>>>>> merged soon. Then reviewing such a
> patch
> > > does
> > > > > not
> > > > > > > >> take
> > > > > > > >> > > much
> > > > > > > >> > > > > > time.
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> Letting another committer review the
> > patch
> > > > > from a
> > > > > > > >> > > committer
> > > > > > > >> > > > > > falls
> > > > > > > >> > > > > > > > either in
> > > > > > > >> > > > > > > > >>>>>> case 1 or case 2. The best option here
> is
> > > to
> > > > > > review
> > > > > > > >> the
> > > > > > > >> > > > patch
> > > > > > > >> > > > > > > > because
> > > > > > > >> > > > > > > > >>>>>> If it is case 1, the patch actually
> needs
> > > to
> > > > be
> > > > > > > >> > reviewed.
> > > > > > > >> > > > > > > > >>>>>> If it is case 2, the review should not
> > take
> > > > > much
> > > > > > > time
> > > > > > > >> > > > anyways.
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> In the contrast, we will risk encounter
> > > case
> > > > 1
> > > > > if
> > > > > > > we
> > > > > > > >> > skip
> > > > > > > >> > > > the
> > > > > > > >> > > > > > > > cross-review.
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> ------------------------
> > > > > > > >> > > > > > > > >>>>>> Re: Robert
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> I replied to your comments in the wiki
> > and
> > > > made
> > > > > > the
> > > > > > > >> > > > following
> > > > > > > >> > > > > > > > modifications
> > > > > > > >> > > > > > > > >>>>>> to resolve some of your comments:
> > > > > > > >> > > > > > > > >>>>>> 1. Added a release manager role
> section.
> > > > > > > >> > > > > > > > >>>>>> 2. changed the name of "lazy consensus"
> > to
> > > > > > > >> "consensus"
> > > > > > > >> > to
> > > > > > > >> > > > > align
> > > > > > > >> > > > > > > with
> > > > > > > >> > > > > > > > >>>>>> general definition of Apache glossary
> and
> > > > other
> > > > > > > >> > projects.
> > > > > > > >> > > > > > > > >>>>>> 3. review board  -> pull request
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> -------------------------
> > > > > > > >> > > > > > > > >>>>>> Re: Chesnay
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> The emeritus stuff seems like
> unnecessary
> > > > > noise.
> > > > > > > >> > > > > > > > >>>>>> As Till mentioned, this is to make sure
> > 2/3
> > > > > > > majority
> > > > > > > >> is
> > > > > > > >> > > > still
> > > > > > > >> > > > > > > > feasible in
> > > > > > > >> > > > > > > > >>>>>> practice.
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> There's a bunch of subtle changes in
> the
> > > > draft
> > > > > > > >> compared
> > > > > > > >> > to
> > > > > > > >> > > > > > > existing
> > > > > > > >> > > > > > > > >>>>>>> "conventions"; we should find a way to
> > > > > highlight
> > > > > > > >> these
> > > > > > > >> > > and
> > > > > > > >> > > > > > > discuss
> > > > > > > >> > > > > > > > them
> > > > > > > >> > > > > > > > >>>>>>> one by one.
> > > > > > > >> > > > > > > > >>>>>> That is a good suggestion. I am not
> > > familiar
> > > > > > enough
> > > > > > > >> with
> > > > > > > >> > > the
> > > > > > > >> > > > > > > > current Flink
> > > > > > > >> > > > > > > > >>>>>> convention. Will you help on this? I
> saw
> > > you
> > > > > > > >> commented
> > > > > > > >> > on
> > > > > > > >> > > > some
> > > > > > > >> > > > > > > part
> > > > > > > >> > > > > > > > in the
> > > > > > > >> > > > > > > > >>>>>> wiki. Are those complete?
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> --------------------------
> > > > > > > >> > > > > > > > >>>>>> Re: Aljoscha
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> How different is this from the Kafka
> > > bylaws?
> > > > > I’m
> > > > > > > >> asking
> > > > > > > >> > > > > because
> > > > > > > >> > > > > > I
> > > > > > > >> > > > > > > > quite
> > > > > > > >> > > > > > > > >>>>>>> like them and wouldn’t mind
> essentially
> > > > > adopting
> > > > > > > the
> > > > > > > >> > > Kafka
> > > > > > > >> > > > > > > bylaws.
> > > > > > > >> > > > > > > > I
> > > > > > > >> > > > > > > > >>>>>> mean,
> > > > > > > >> > > > > > > > >>>>>>> it’s open source, and we don’t have to
> > try
> > > > to
> > > > > > > >> re-invent
> > > > > > > >> > > the
> > > > > > > >> > > > > > wheel
> > > > > > > >> > > > > > > > here.
> > > > > > > >> > > > > > > > >>>>>> Ha, you got me on this. The first
> version
> > > of
> > > > > the
> > > > > > > >> draft
> > > > > > > >> > was
> > > > > > > >> > > > > > almost
> > > > > > > >> > > > > > > > identical
> > > > > > > >> > > > > > > > >>>>>> to Kafka. But Robert has already
> caught a
> > > few
> > > > > > > >> > inconsistent
> > > > > > > >> > > > > > places.
> > > > > > > >> > > > > > > > So it
> > > > > > > >> > > > > > > > >>>>>> might still worth going through it to
> > make
> > > > sure
> > > > > > we
> > > > > > > >> truly
> > > > > > > >> > > > agree
> > > > > > > >> > > > > > on
> > > > > > > >> > > > > > > > them.
> > > > > > > >> > > > > > > > >>>>>> Otherwise we may end up modifying them
> > > > shortly
> > > > > > > after
> > > > > > > >> > > > adoption.
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> Thanks again folks, for all the
> valuable
> > > > > > feedback.
> > > > > > > >> These
> > > > > > > >> > > are
> > > > > > > >> > > > > > great
> > > > > > > >> > > > > > > > >>>>>> discussion.
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> Jiangjie (Becket) Qin
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM
> Aljoscha
> > > > > Krettek
> > > > > > <
> > > > > > > >> > > > > > > > aljoscha@apache.org>
> > > > > > > >> > > > > > > > >>>>>> wrote:
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > > >>>>>>> Big +1
> > > > > > > >> > > > > > > > >>>>>>>
> > > > > > > >> > > > > > > > >>>>>>> How different is this from the Kafka
> > > bylaws?
> > > > > I’m
> > > > > > > >> asking
> > > > > > > >> > > > > > because I
> > > > > > > >> > > > > > > > quite
> > > > > > > >> > > > > > > > >>>>>>> like them and wouldn’t mind
> essentially
> > > > > adopting
> > > > > > > the
> > > > > > > >> > > Kafka
> > > > > > > >> > > > > > > bylaws.
> > > > > > > >> > > > > > > > I
> > > > > > > >> > > > > > > > >>>>>> mean,
> > > > > > > >> > > > > > > > >>>>>>> it’s open source, and we don’t have to
> > try
> > > > to
> > > > > > > >> re-invent
> > > > > > > >> > > the
> > > > > > > >> > > > > > wheel
> > > > > > > >> > > > > > > > here.
> > > > > > > >> > > > > > > > >>>>>>>
> > > > > > > >> > > > > > > > >>>>>>> I think it’s worthwhile to discuss the
> > > > > > “committer
> > > > > > > >> +1”
> > > > > > > >> > > > > > > requirement.
> > > > > > > >> > > > > > > > We
> > > > > > > >> > > > > > > > >>>>>>> don’t usually have that now but I
> would
> > > > > actually
> > > > > > > be
> > > > > > > >> in
> > > > > > > >> > > > favour
> > > > > > > >> > > > > > of
> > > > > > > >> > > > > > > > >>>>>> requiring
> > > > > > > >> > > > > > > > >>>>>>> it, although it might make stuff more
> > > > > > complicated.
> > > > > > > >> > > > > > > > >>>>>>>
> > > > > > > >> > > > > > > > >>>>>>> Aljoscha
> > > > > > > >> > > > > > > > >>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>> On 11. Jul 2019, at 15:31, Till
> > Rohrmann
> > > <
> > > > > > > >> > > > > > trohrmann@apache.org>
> > > > > > > >> > > > > > > > wrote:
> > > > > > > >> > > > > > > > >>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>> Thanks a lot for creating this draft
> > > > Becket.
> > > > > > > >> > > > > > > > >>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>> I think without the notion of
> emeritus
> > > (or
> > > > > > active
> > > > > > > >> vs.
> > > > > > > >> > > > > > inactive),
> > > > > > > >> > > > > > > > it
> > > > > > > >> > > > > > > > >>>>>> won't
> > > > > > > >> > > > > > > > >>>>>>>> be possible to have a 2/3 majority
> vote
> > > > > because
> > > > > > > we
> > > > > > > >> > > already
> > > > > > > >> > > > > > have
> > > > > > > >> > > > > > > > too
> > > > > > > >> > > > > > > > >>>>>> many
> > > > > > > >> > > > > > > > >>>>>>>> inactive PMCs/committers.
> > > > > > > >> > > > > > > > >>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>> For the case of a committer being the
> > > > author
> > > > > > and
> > > > > > > >> > > getting a
> > > > > > > >> > > > > +1
> > > > > > > >> > > > > > > > from a
> > > > > > > >> > > > > > > > >>>>>>>> non-committer: I think a committer
> > should
> > > > > know
> > > > > > > >> when to
> > > > > > > >> > > ask
> > > > > > > >> > > > > > > another
> > > > > > > >> > > > > > > > >>>>>>>> committer for feedback or not.
> Hence, I
> > > > would
> > > > > > not
> > > > > > > >> > > enforce
> > > > > > > >> > > > > that
> > > > > > > >> > > > > > > we
> > > > > > > >> > > > > > > > >>>>>>> strictly
> > > > > > > >> > > > > > > > >>>>>>>> need a +1 from a committer if the
> > author
> > > > is a
> > > > > > > >> > committer
> > > > > > > >> > > > but
> > > > > > > >> > > > > of
> > > > > > > >> > > > > > > > course
> > > > > > > >> > > > > > > > >>>>>>>> encourage it if capacities exist.
> > > > > > > >> > > > > > > > >>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>> Cheers,
> > > > > > > >> > > > > > > > >>>>>>>> Till
> > > > > > > >> > > > > > > > >>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM
> Chesnay
> > > > > > Schepler
> > > > > > > <
> > > > > > > >> > > > > > > > chesnay@apache.org>
> > > > > > > >> > > > > > > > >>>>>>> wrote:
> > > > > > > >> > > > > > > > >>>>>>>>> The emeritus stuff seems like
> > > unnecessary
> > > > > > noise.
> > > > > > > >> > > > > > > > >>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>> There's a bunch of subtle changes in
> > the
> > > > > draft
> > > > > > > >> > compared
> > > > > > > >> > > > to
> > > > > > > >> > > > > > > > existing
> > > > > > > >> > > > > > > > >>>>>>>>> "conventions"; we should find a way
> to
> > > > > > highlight
> > > > > > > >> > these
> > > > > > > >> > > > and
> > > > > > > >> > > > > > > > discuss
> > > > > > > >> > > > > > > > >>>>>> them
> > > > > > > >> > > > > > > > >>>>>>>>> one by one.
> > > > > > > >> > > > > > > > >>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>> On 11/07/2019 14:29, Robert Metzger
> > > wrote:
> > > > > > > >> > > > > > > > >>>>>>>>>> Thank you Becket for kicking off
> this
> > > > > > > discussion
> > > > > > > >> and
> > > > > > > >> > > > > > creating
> > > > > > > >> > > > > > > a
> > > > > > > >> > > > > > > > draft
> > > > > > > >> > > > > > > > >>>>>>> in
> > > > > > > >> > > > > > > > >>>>>>>>>> the Wiki.
> > > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>> I left some comments in the wiki.
> > > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>> In my understanding this means,
> that
> > a
> > > > > > > committer
> > > > > > > >> > > always
> > > > > > > >> > > > > > needs
> > > > > > > >> > > > > > > a
> > > > > > > >> > > > > > > > >>>>>> review
> > > > > > > >> > > > > > > > >>>>>>>>> and
> > > > > > > >> > > > > > > > >>>>>>>>>>> +1 from another committer. As far
> > as I
> > > > > know
> > > > > > > >> this is
> > > > > > > >> > > > > > currently
> > > > > > > >> > > > > > > > not
> > > > > > > >> > > > > > > > >>>>>>> always
> > > > > > > >> > > > > > > > >>>>>>>>>>> the case (often committer authors,
> > > > > > contributor
> > > > > > > >> > > reviews
> > > > > > > >> > > > &
> > > > > > > >> > > > > > > +1s).
> > > > > > > >> > > > > > > > >>>>>>>>>> I would agree to add such a bylaw,
> if
> > > we
> > > > > had
> > > > > > > >> cases
> > > > > > > >> > in
> > > > > > > >> > > > the
> > > > > > > >> > > > > > past
> > > > > > > >> > > > > > > > where
> > > > > > > >> > > > > > > > >>>>>>> code
> > > > > > > >> > > > > > > > >>>>>>>>>> was not sufficiently reviewed AND
> we
> > > > > believe
> > > > > > > >> that we
> > > > > > > >> > > > have
> > > > > > > >> > > > > > > enough
> > > > > > > >> > > > > > > > >>>>>>> capacity
> > > > > > > >> > > > > > > > >>>>>>>>>> to ensure a separate committer's
> > > > approval.
> > > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> > > > Konstantin
> > > > > > > Knauf
> > > > > > > >> <
> > > > > > > >> > > > > > > > >>>>>>>>> konstantin@ververica.com>
> > > > > > > >> > > > > > > > >>>>>>>>>> wrote:
> > > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> Hi all,
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> thanks a lot for driving this,
> > > Becket. I
> > > > > > have
> > > > > > > >> two
> > > > > > > >> > > > remarks
> > > > > > > >> > > > > > > > regarding
> > > > > > > >> > > > > > > > >>>>>>> the
> > > > > > > >> > > > > > > > >>>>>>>>>>> "Actions" section:
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> * In addition to a simple "Code
> > > Change"
> > > > we
> > > > > > > could
> > > > > > > >> > also
> > > > > > > >> > > > > add a
> > > > > > > >> > > > > > > > row for
> > > > > > > >> > > > > > > > >>>>>>>>> "Code
> > > > > > > >> > > > > > > > >>>>>>>>>>> Change requiring a FLIP" with a
> > > > reference
> > > > > to
> > > > > > > the
> > > > > > > >> > FLIP
> > > > > > > >> > > > > > process
> > > > > > > >> > > > > > > > page.
> > > > > > > >> > > > > > > > >>>>>> A
> > > > > > > >> > > > > > > > >>>>>>>>> FLIP
> > > > > > > >> > > > > > > > >>>>>>>>>>> will have/does have different
> rules
> > > for
> > > > > > > >> approvals,
> > > > > > > >> > > etc.
> > > > > > > >> > > > > > > > >>>>>>>>>>> * For "Code Change" the draft
> > > currently
> > > > > > > requires
> > > > > > > >> > "one
> > > > > > > >> > > > +1
> > > > > > > >> > > > > > > from a
> > > > > > > >> > > > > > > > >>>>>>>>> committer
> > > > > > > >> > > > > > > > >>>>>>>>>>> who has not authored the patch
> > > followed
> > > > > by a
> > > > > > > >> Lazy
> > > > > > > >> > > > > approval
> > > > > > > >> > > > > > > (not
> > > > > > > >> > > > > > > > >>>>>>> counting
> > > > > > > >> > > > > > > > >>>>>>>>>>> the vote of the contributor),
> moving
> > > to
> > > > > lazy
> > > > > > > >> > majority
> > > > > > > >> > > > if
> > > > > > > >> > > > > a
> > > > > > > >> > > > > > -1
> > > > > > > >> > > > > > > > is
> > > > > > > >> > > > > > > > >>>>>>>>> received".
> > > > > > > >> > > > > > > > >>>>>>>>>>> In my understanding this means,
> > that a
> > > > > > > committer
> > > > > > > >> > > always
> > > > > > > >> > > > > > > needs a
> > > > > > > >> > > > > > > > >>>>>> review
> > > > > > > >> > > > > > > > >>>>>>>>> and
> > > > > > > >> > > > > > > > >>>>>>>>>>> +1 from another committer. As far
> > as I
> > > > > know
> > > > > > > >> this is
> > > > > > > >> > > > > > currently
> > > > > > > >> > > > > > > > not
> > > > > > > >> > > > > > > > >>>>>>> always
> > > > > > > >> > > > > > > > >>>>>>>>>>> the case (often committer authors,
> > > > > > contributor
> > > > > > > >> > > reviews
> > > > > > > >> > > > &
> > > > > > > >> > > > > > > +1s).
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> I think it is worth thinking about
> > how
> > > > we
> > > > > > can
> > > > > > > >> make
> > > > > > > >> > it
> > > > > > > >> > > > > easy
> > > > > > > >> > > > > > to
> > > > > > > >> > > > > > > > follow
> > > > > > > >> > > > > > > > >>>>>>> the
> > > > > > > >> > > > > > > > >>>>>>>>>>> bylaws e.g. by having more
> > > > Flink-specific
> > > > > > Jira
> > > > > > > >> > > > workflows
> > > > > > > >> > > > > > and
> > > > > > > >> > > > > > > > ticket
> > > > > > > >> > > > > > > > >>>>>>>>> types +
> > > > > > > >> > > > > > > > >>>>>>>>>>> corresponding permissions. While
> > this
> > > is
> > > > > > > >> certainly
> > > > > > > >> > > > "Step
> > > > > > > >> > > > > > 2",
> > > > > > > >> > > > > > > I
> > > > > > > >> > > > > > > > >>>>>>> believe,
> > > > > > > >> > > > > > > > >>>>>>>>> we
> > > > > > > >> > > > > > > > >>>>>>>>>>> really need to make it as easy &
> > > > > transparent
> > > > > > > as
> > > > > > > >> > > > possible,
> > > > > > > >> > > > > > > > otherwise
> > > > > > > >> > > > > > > > >>>>>>> they
> > > > > > > >> > > > > > > > >>>>>>>>>>> will be unintentionally broken.
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> Cheers and thanks,
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> Konstantin
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
> > Becket
> > > > > Qin <
> > > > > > > >> > > > > > > > becket.qin@gmail.com>
> > > > > > > >> > > > > > > > >>>>>>>>> wrote:
> > > > > > > >> > > > > > > > >>>>>>>>>>>> Hi all,
> > > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>> As it was raised in the FLIP
> > process
> > > > > > > discussion
> > > > > > > >> > > thread
> > > > > > > >> > > > > > [1],
> > > > > > > >> > > > > > > > >>>>>> currently
> > > > > > > >> > > > > > > > >>>>>>>>>>> Flink
> > > > > > > >> > > > > > > > >>>>>>>>>>>> does not have official bylaws to
> > > govern
> > > > > the
> > > > > > > >> > > operation
> > > > > > > >> > > > of
> > > > > > > >> > > > > > the
> > > > > > > >> > > > > > > > >>>>>> project.
> > > > > > > >> > > > > > > > >>>>>>>>>>> Such
> > > > > > > >> > > > > > > > >>>>>>>>>>>> bylaws are critical for the
> > community
> > > > to
> > > > > > > >> > coordinate
> > > > > > > >> > > > and
> > > > > > > >> > > > > > > > contribute
> > > > > > > >> > > > > > > > >>>>>>>>>>>> together. It is also the basis of
> > > other
> > > > > > > >> processes
> > > > > > > >> > > such
> > > > > > > >> > > > > as
> > > > > > > >> > > > > > > > FLIP.
> > > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>> I have drafted a Flink bylaws
> page
> > > and
> > > > > > would
> > > > > > > >> like
> > > > > > > >> > to
> > > > > > > >> > > > > > start a
> > > > > > > >> > > > > > > > >>>>>>> discussion
> > > > > > > >> > > > > > > > >>>>>>>>>>>> thread on this.
> > > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > > > > > >> > > > > > > > >>>>>>>>>>>> The bylaws will affect everyone
> in
> > > the
> > > > > > > >> community.
> > > > > > > >> > > > It'll
> > > > > > > >> > > > > be
> > > > > > > >> > > > > > > > great to
> > > > > > > >> > > > > > > > >>>>>>>>> hear
> > > > > > > >> > > > > > > > >>>>>>>>>>>> your thoughts.
> > > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>> Thanks,
> > > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>> [1]
> > > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> > > > > > > >> > > > > > > > >>>>>>>>>>> --
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> Konstantin Knauf | Solutions
> > Architect
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> +49 160 91394525
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> Planned Absences: 10.08.2019 -
> > > > 31.08.2019,
> > > > > > > >> 05.09. -
> > > > > > > >> > > > > > > 06.09.2010
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> --
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> Ververica GmbH | Invalidenstrasse
> > 115,
> > > > > 10115
> > > > > > > >> > Berlin,
> > > > > > > >> > > > > > Germany
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> --
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > > >>>>>>>>>>> Ververica GmbH
> > > > > > > >> > > > > > > > >>>>>>>>>>> Registered at Amtsgericht
> > > > Charlottenburg:
> > > > > > HRB
> > > > > > > >> > 158244
> > > > > > > >> > > B
> > > > > > > >> > > > > > > > >>>>>>>>>>> Managing Directors: Dr. Kostas
> > > Tzoumas,
> > > > > Dr.
> > > > > > > >> Stephan
> > > > > > > >> > > > Ewen
> > > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Flink project bylaws

[Fabian Hueske <fh...@gmail.com>]

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 <be...@gmail.com>:

> Thanks Stephan.
>
> I think we have resolved all the comments on the wiki page. There are two
> minor changes made to the bylaws since last week.
> 1. For 2/3 majority, the required attempts to reach out to binding voters
> is reduced from 3 to 2. This helps shorten the voting process a little bit.
> 2. Clarified what is considered as the adoption of new codebase.
>
> I think we almost reached consensus. I'll start a voting thread in two days
> if there is no new concerns.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org> wrote:
>
> > I added a clarification to the table, clarifying that the current
> phrasing
> > means that committers do not need another +1 for their commits.
> >
> > On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fh...@gmail.com> wrote:
> >
> > > Hi Becket,
> > >
> > > Thanks a lot for pushing this forward and addressing the feedback.
> > > I'm very happy with the current state of the bylaws.
> > > +1 to wait until Friday before starting a vote.
> > >
> > > Best, Fabian
> > >
> > > Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> > > becket.qin@gmail.com
> > > >:
> > >
> > > > Hi Everyone,
> > > >
> > > > Thanks for all the discussion and feedback.
> > > >
> > > > It seems that we have almost reached consensus. I'll leave the
> > discussion
> > > > thread open until this Friday. If there is no more concerns raised,
> > I'll
> > > > start a voting thread after that.
> > > >
> > > > Thanks,
> > > >
> > > > Jiangjie (Becket) Qin
> > > >
> > > > On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com> wrote:
> > > >
> > > > > Hi Becket,
> > > > >
> > > > > Thanks for noticing and resolving my comment around PMC removal and
> > ASF
> > > > > rules of PMC membership change process, which you seem to neglect
> in
> > > the
> > > > > summary of updates (smile).
> > > > >
> > > > > Best Regards,
> > > > > Yu
> > > > >
> > > > >
> > > > > On Wed, 24 Jul 2019 at 04:32, Becket Qin <be...@gmail.com>
> > wrote:
> > > > >
> > > > > > Hi folks,
> > > > > >
> > > > > > Thanks for all the feedback.
> > > > > >
> > > > > > It seems that there are a few concerns over the emeritus status
> > > after 6
> > > > > > months of inactivity. Given that the main purpose is just to make
> > > sure
> > > > > 2/3
> > > > > > majority can pass and we sort of have a solution for that, I just
> > > > updated
> > > > > > the draft with the following changes:
> > > > > >
> > > > > > 1. Removed the inactivity term for emeritus committers / PMCs. A
> > > > > committer
> > > > > > / PMC will only be considered emeritus by their own claim.
> > > > > > 2. Removed the approval process for reinstatement of the emeritus
> > > > > > committers / PMCs. An emeritus committer / PMC will be reinstated
> > > when
> > > > > they
> > > > > > send an email to the private@flink.apache.org.
> > > > > > 3. Adde the term to ensure 2/3 majority voting is still doable
> when
> > > > there
> > > > > > are non-emeritus committers / PMCs who do not cast the vote.
> > > > > >
> > > > > > Please let me know if you have any further thoughts.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Jiangjie (Becket) Qin
> > > > > >
> > > > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
> becket.qin@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hi Fabian,
> > > > > > >
> > > > > > > Thanks for the feedback.
> > > > > > >
> > > > > > > I agree that if we don't like emeritus committers / PMCs, we
> > don't
> > > > have
> > > > > > to
> > > > > > > do it. That said, emeritus status simply means whether an
> > > individual
> > > > is
> > > > > > > active / inactive in the community. It does not make the merits
> > > > earned
> > > > > to
> > > > > > > go away. For our purpose, emeritus status is mostly just a way
> to
> > > > make
> > > > > > 2/3
> > > > > > > majority possible. As you noticed, since reaching out to
> binding
> > > > voters
> > > > > > who
> > > > > > > have not voted can achieve the same goal, the emeritus status
> is
> > > more
> > > > > of
> > > > > > an
> > > > > > > optimization so we don't have to ping the inactive binding
> voters
> > > > every
> > > > > > > time and wait for long. However, given that 2/3 majority
> votings
> > > are
> > > > > > rare,
> > > > > > > such communication cost is probably OK. So I think we can
> remove
> > > that
> > > > > > > emeritus part from the bylaws.
> > > > > > >
> > > > > > > 1) We should add to the requirements of the PMC that they need
> to
> > > > make
> > > > > > >> sure the project complies with brand issues and reports misuse
> > of
> > > > ASF
> > > > > > >> brands.
> > > > > > >
> > > > > > > Good point. Added.
> > > > > > >
> > > > > > > 2) Do we want to restrict voting days to working days, i.e., a
> 3
> > > day
> > > > > vote
> > > > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > > > > >
> > > > > > > This might be a little tricky because people are from countries
> > in
> > > > > > > different time zones and with different holidays, and so on. If
> > we
> > > > are
> > > > > > > worrying about 3 days minimum length is not enough for those
> who
> > > want
> > > > > to
> > > > > > > give feedback, we can make it 5 days.
> > > > > > >
> > > > > > > 3) Do we need a process do decide about removal of features
> (like
> > > the
> > > > > > >> DataSet API for instance or the legacy DataSet/DataStream
> Python
> > > > > APIs)?
> > > > > > >
> > > > > > > I assume such action should be covered by FLIP as it is a
> change
> > to
> > > > the
> > > > > > > API and probably needs a migration plan. It would be useful to
> > > have a
> > > > > > > formal deprecation procedure. But that might be better to be
> put
> > > into
> > > > > > > somewhere else because the bylaws are primarily focusing on the
> > > > > > > non-technical rules, whereas the deprecation seems more on the
> > > > > technical
> > > > > > > side.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Jiangjie (Becket) Qin
> > > > > > >
> > > > > > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
> > fhueske@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > >> Hi all,
> > > > > > >>
> > > > > > >> First of all thank you very much Becket for starting this
> > > > discussion!
> > > > > > >> I think it is a very good idea and overdue to formally define
> > some
> > > > of
> > > > > > our
> > > > > > >> community processes.
> > > > > > >>
> > > > > > >> Similar to Chesnay, I have concerns about the distinction
> > between
> > > > > active
> > > > > > >> and non-active / emeritus committers and PMC members.
> > > > > > >> My foremost concern is that this is not in the spirit of the
> > > Apache
> > > > > Way
> > > > > > >> [1]
> > > > > > >> which is (among other things) based on the idea of merit which
> > > once
> > > > > > >> earned,
> > > > > > >> does not go away over time.
> > > > > > >> I know other projects like Hadoop and Kafka have similar
> clauses
> > > in
> > > > > the
> > > > > > >> bylaws but IMO we don't need to adopt them if we don't like
> > them.
> > > > > > >> For example, I don't like the idea that committers or PMC
> > members
> > > > who
> > > > > > are
> > > > > > >> temporarily away from the project (for whatever reason:
> parental
> > > > > leave,
> > > > > > >> sabbatical, health issues, etc.) need the PMC approval to be
> > > > "active"
> > > > > > >> again.
> > > > > > >> As far as I am aware, we have not seen any issues with
> inactive
> > > > > members
> > > > > > in
> > > > > > >> the past.
> > > > > > >> Moreover, it would be hard to track whether somebody became
> > > inactive
> > > > > at
> > > > > > >> some point in time (which we would need to do, if I understand
> > the
> > > > > > >> proposal
> > > > > > >> correctly).
> > > > > > >> With the approach that Becket suggested in his last email
> > > (reaching
> > > > > out
> > > > > > to
> > > > > > >> binding voters who haven't voted yet), we could drop the
> > > distinction
> > > > > > >> between active and non-active committers and PMC members.
> > > > > > >>
> > > > > > >> I also have a few minor comments:
> > > > > > >>
> > > > > > >> 1) We should add to the requirements of the PMC [2] that they
> > need
> > > > to
> > > > > > make
> > > > > > >> sure the project complies with brand issues and reports misuse
> > of
> > > > ASF
> > > > > > >> brands.
> > > > > > >> 2) Do we want to restrict voting days to working days, i.e.,
> a 3
> > > day
> > > > > > vote
> > > > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > > > > >> 3) Do we need a process do decide about removal of features
> > (like
> > > > the
> > > > > > >> DataSet API for instance or the legacy DataSet/DataStream
> Python
> > > > > APIs)?
> > > > > > >>
> > > > > > >> Thank you,
> > > > > > >> Fabian
> > > > > > >>
> > > > > > >> [1] https://www.apache.org/theapacheway/
> > > > > > >> [2] https://www.apache.org/dev/pmc.html
> > > > > > >>
> > > > > > >> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> > > > > > >> becket.qin@gmail.com
> > > > > > >> >:
> > > > > > >>
> > > > > > >> > Hi Hequn,
> > > > > > >> >
> > > > > > >> > Thanks for sharing your thoughts. Please see the reply
> below:
> > > > > > >> >
> > > > > > >> > > Perhaps what Jincheng means is to hold at least one PMC in
> > > the 3
> > > > > > >> binding
> > > > > > >> > > votes? i.e, the vote could have 2 binding committers and 1
> > > PMC.
> > > > > > >> > > I think this makes sense considering a FLIP could somehow
> > be a
> > > > big
> > > > > > >> > feature
> > > > > > >> > > which may impacts Flink a lot. Meanwhile, there is no loss
> > of
> > > > > > >> flexibility
> > > > > > >> > > as committers also have a chance to vote and participate
> in
> > > it.
> > > > > > >> > A few concerns of requiring a PMC vote in all FLIPs are the
> > > > > following:
> > > > > > >> >
> > > > > > >> > 1. Generally speaking, the PMC's primary responsibility is
> > > > operating
> > > > > > the
> > > > > > >> > project and deciding what software to release on behalf of
> > ASF.
> > > > > > >> Committers,
> > > > > > >> > on the other hand, are responsible for the technical part of
> > the
> > > > > > >> project.
> > > > > > >> > So for FLIPs, a PMC's vote probably should not outweigh a
> > > > > committer's
> > > > > > >> vote.
> > > > > > >> > Besides, I am not sure whether a single PMCs +1 is really
> > > > convincing
> > > > > > >> enough
> > > > > > >> > to decide whether the FLIP is good to go or not. Also, if
> some
> > > > > > >> committers
> > > > > > >> > have concern over a FLIP, they could just veto it. To me it
> is
> > > > > > actually
> > > > > > >> a
> > > > > > >> > more strict requirement to pass a FLIP than asking a PMC to
> > > vote.
> > > > In
> > > > > > >> > practice, people will usually also address the concerns even
> > if
> > > > they
> > > > > > are
> > > > > > >> > not from a PMC/committer before they start the voting
> process.
> > > So
> > > > I
> > > > > > >> don't
> > > > > > >> > see much benefit of requiring a PMC's vote in this case.
> > > > > > >> >
> > > > > > >> > 2. The at-least-one-PMC-vote requirement makes the votes no
> > > longer
> > > > > > >> > independent. Ideally, a vote is either binding or
> non-binding
> > by
> > > > > > >> itself. If
> > > > > > >> > we have the at-least-one-PMC-vote requirement here, imagine
> > > there
> > > > > have
> > > > > > >> been
> > > > > > >> > 3 committers who voted +1. But the FLIP still has not
> passed,
> > so
> > > > > those
> > > > > > >> > votes are effectively non-binding. Now a PMC votes a +1,
> those
> > > > votes
> > > > > > >> > suddenly become binding, which is a little awkward.
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > The lazy 2/3 majority suggestion sounds reasonable to me.
> Some
> > > > > > thoughts
> > > > > > >> on
> > > > > > >> > this:
> > > > > > >> > 1. One reason Hadoop uses lazy 2/3 majority is probably
> > because
> > > > > there
> > > > > > >> are
> > > > > > >> > 104 PMC members[1] for Hadoop which makes the 2/3 majority
> > > > > > prohibitively
> > > > > > >> > expensive. In our case, there are only 22 PMCs for Flink[2]
> > and
> > > a
> > > > > > quick
> > > > > > >> > search shows at most 6 of them have not sent email in the
> > > recent 6
> > > > > > >> months
> > > > > > >> > or so.
> > > > > > >> >
> > > > > > >> > 2. 2/3 majority votes are supposed to be very rare. It is
> > > designed
> > > > > in
> > > > > > >> > particular for the cases that broad opinions are important,
> > more
> > > > > > >> > specifically new codebase adoption or modification to the
> > > bylaws.
> > > > > > >> Therefore
> > > > > > >> > such vote by its nature favors consensus over convenience.
> > That
> > > > > means
> > > > > > >> any
> > > > > > >> > alternative voting type reducing the coverage worth a
> careful
> > > > > > thinking.
> > > > > > >> >
> > > > > > >> > 3. I do agree that it does not make sense to have 2/3
> majority
> > > if
> > > > > such
> > > > > > >> > requirement is no-longer doable over time. But I am a little
> > > > > hesitant
> > > > > > to
> > > > > > >> > lower the threshold to lazy 2/3 majority in our case. What
> do
> > > you
> > > > > > think
> > > > > > >> > about doing the following:
> > > > > > >> >     - After the voting started, there will be at least 6
> days
> > > for
> > > > > > >> people to
> > > > > > >> > cast their votes.
> > > > > > >> >     - After 6 days, if the result of the vote is still not
> > > > > determined,
> > > > > > >> the
> > > > > > >> > person who started the vote should reach out to the binding
> > > voters
> > > > > who
> > > > > > >> have
> > > > > > >> > not voted yet for at least 3 times and at least 7 days
> between
> > > > each
> > > > > > >> time.
> > > > > > >> > If a binding voter still did not respond, the vote from that
> > > voter
> > > > > > will
> > > > > > >> be
> > > > > > >> > excluded from the 2/3 majority counting.
> > > > > > >> > This would ensure the coverage at our best effort while
> still
> > > let
> > > > > the
> > > > > > >> 2/3
> > > > > > >> > majority vote make progress.
> > > > > > >> >
> > > > > > >> > Thanks,
> > > > > > >> >
> > > > > > >> > Jiangjie (Becket) Qin
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > [1] https://projects.apache.org/committee.html?hadoop
> > > > > > >> > [2] https://projects.apache.org/committee.html?flink
> > > > > > >> >
> > > > > > >> > On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> > > > forwardxu315@gmail.com>
> > > > > > >> wrote:
> > > > > > >> >
> > > > > > >> > > Big +1 on this.
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > best
> > > > > > >> > >
> > > > > > >> > > forward
> > > > > > >> > >
> > > > > > >> > > Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日
> 下午1:30写道：
> > > > > > >> > >
> > > > > > >> > > > Hi Becket,
> > > > > > >> > > >
> > > > > > >> > > > Big +1 on this.
> > > > > > >> > > >
> > > > > > >> > > > > Regarding the vote of FLIP, preferably at least
> > includes a
> > > > PMC
> > > > > > >> vote.
> > > > > > >> > > > Perhaps what Jincheng means is to hold at least one PMC
> in
> > > > the 3
> > > > > > >> > binding
> > > > > > >> > > > votes? i.e, the vote could have 2 binding committers
> and 1
> > > > PMC.
> > > > > > >> > > > I think this makes sense considering a FLIP could
> somehow
> > > be a
> > > > > big
> > > > > > >> > > feature
> > > > > > >> > > > which may impacts Flink a lot. Meanwhile, there is no
> loss
> > > of
> > > > > > >> > flexibility
> > > > > > >> > > > as committers also have a chance to vote and participate
> > in
> > > > it.
> > > > > > >> > > >
> > > > > > >> > > > ========Seperator========
> > > > > > >> > > >
> > > > > > >> > > > For the nice bylaws, I agree with the general idea and
> > most
> > > of
> > > > > the
> > > > > > >> > > content.
> > > > > > >> > > > Only share some thoughts about the "2/3 Majority". The
> > main
> > > > > > concern
> > > > > > >> is
> > > > > > >> > I
> > > > > > >> > > am
> > > > > > >> > > > not sure if it is doable in practice. The reasons are:
> > > > > > >> > > >
> > > > > > >> > > > 1. If we follow the bylaws strictly, it means a
> committer
> > > or a
> > > > > PMC
> > > > > > >> > member
> > > > > > >> > > > is active if he or she sends one email to the mailing
> list
> > > > > every 6
> > > > > > >> > > months.
> > > > > > >> > > > While the minimum length of the vote is only 6 days.
> There
> > > are
> > > > > > >> chances
> > > > > > >> > > that
> > > > > > >> > > > during the vote, some of the active members are still
> > > offline
> > > > of
> > > > > > the
> > > > > > >> > > > community.
> > > > > > >> > > > 2. The code of Flink is changing fast and not everyone
> > fully
> > > > > > >> > understands
> > > > > > >> > > > every part. We don't need to force people to vote if
> they
> > > are
> > > > > not
> > > > > > >> sure
> > > > > > >> > > > about it. It may also make the final result less
> credible.
> > > > > > >> > > >
> > > > > > >> > > > Given the above reasons, perhaps we can change the 2/3
> > > > Majority
> > > > > to
> > > > > > >> lazy
> > > > > > >> > > 2/3
> > > > > > >> > > > Majority, just as the Hadoop bylaws[1]. It makes a
> higher
> > > > > > threshold,
> > > > > > >> > > > however, more practical.
> > > > > > >> > > >
> > > > > > >> > > > What do you think?
> > > > > > >> > > >
> > > > > > >> > > > [1] https://hadoop.apache.org/bylaws.html
> > > > > > >> > > >
> > > > > > >> > > > On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> > > > > becket.qin@gmail.com
> > > > > > >
> > > > > > >> > > wrote:
> > > > > > >> > > >
> > > > > > >> > > > > Hi Jincheng,
> > > > > > >> > > > >
> > > > > > >> > > > > Thanks for the comments. I replied on the wiki page.
> > Just
> > > a
> > > > > > brief
> > > > > > >> > > > summary,
> > > > > > >> > > > > the current bylaws do require some of the FLIPs to get
> > PMC
> > > > > > >> approval
> > > > > > >> > if
> > > > > > >> > > > > their impact is big enough. But it leaves majority of
> > the
> > > > > > >> technical
> > > > > > >> > > > > decisions to the committers who are supposed to be
> > > > responsible
> > > > > > for
> > > > > > >> > > making
> > > > > > >> > > > > such decisions.
> > > > > > >> > > > >
> > > > > > >> > > > > Re: Robert,
> > > > > > >> > > > >
> > > > > > >> > > > > I agree we can simply remove the requirement of +1
> from
> > a
> > > > > > >> non-author
> > > > > > >> > > > > committer and revisit it in a bit. After all, it does
> > not
> > > > make
> > > > > > >> sense
> > > > > > >> > to
> > > > > > >> > > > > have a bylaw that we cannot afford. I have just
> updated
> > > the
> > > > > > bylaws
> > > > > > >> > > wiki.
> > > > > > >> > > > >
> > > > > > >> > > > > Thanks,
> > > > > > >> > > > >
> > > > > > >> > > > > Jiangjie (Becket) Qin
> > > > > > >> > > > >
> > > > > > >> > > > > On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> > > > > > >> rmetzger@apache.org
> > > > > > >> > >
> > > > > > >> > > > > wrote:
> > > > > > >> > > > >
> > > > > > >> > > > > > Hi all,
> > > > > > >> > > > > > I agree with Aljoscha that trying to reflect the
> > current
> > > > > > status
> > > > > > >> in
> > > > > > >> > > the
> > > > > > >> > > > > > bylaws, and then implementing changes one by one is
> a
> > > very
> > > > > > >> involved
> > > > > > >> > > > task.
> > > > > > >> > > > > > Unless there's somebody who's really eager to drive
> > > this,
> > > > I
> > > > > > >> would
> > > > > > >> > > stick
> > > > > > >> > > > > to
> > > > > > >> > > > > > Becket's initiative to come up with Bylaws for
> Flink,
> > > even
> > > > > if
> > > > > > >> this
> > > > > > >> > > > means
> > > > > > >> > > > > > some changes.
> > > > > > >> > > > > >
> > > > > > >> > > > > > The cross-review requirement is the last big open
> > point
> > > in
> > > > > > this
> > > > > > >> > > > > discussion.
> > > > > > >> > > > > > It seems that a there is a slight tendency in the
> > > > discussion
> > > > > > >> that
> > > > > > >> > > this
> > > > > > >> > > > is
> > > > > > >> > > > > > not feasible given the current pull request review
> > > > > situation.
> > > > > > >> > > > > > For the sake of bringing this discussion to a
> > > conclusion,
> > > > > I'm
> > > > > > >> fine
> > > > > > >> > > with
> > > > > > >> > > > > > leaving this requirement out. As we are currently
> > adding
> > > > > more
> > > > > > >> > > > committers
> > > > > > >> > > > > to
> > > > > > >> > > > > > the project, we might be able to revisit this
> > discussion
> > > > in
> > > > > 3
> > > > > > -
> > > > > > >> 6
> > > > > > >> > > > months.
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> > > > > > >> > > sunjincheng121@gmail.com
> > > > > > >> > > > >
> > > > > > >> > > > > > wrote:
> > > > > > >> > > > > >
> > > > > > >> > > > > > > Hi Becket,
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > Thanks for the proposal.
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > Regarding the vote of FLIP, preferably at least
> > > > includes a
> > > > > > PMC
> > > > > > >> > > vote.
> > > > > > >> > > > > > > Because FLIP is usually a big change or affects
> the
> > > > user's
> > > > > > >> > > interface
> > > > > > >> > > > > > > changes. What do you think? (I leave the comment
> in
> > > the
> > > > > > wiki.)
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > Best,
> > > > > > >> > > > > > > Jincheng
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > Dawid Wysakowicz <dw...@apache.org>
> > > 于2019年7月17日周三
> > > > > > >> > 下午9:12写道：
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > > Hi all,
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > Sorry for joining late. I just wanted to say
> that
> > I
> > > > > really
> > > > > > >> like
> > > > > > >> > > the
> > > > > > >> > > > > > > > proposed bylaws!
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > One comment, I also have the same concerns as
> > > > expressed
> > > > > by
> > > > > > >> few
> > > > > > >> > > > people
> > > > > > >> > > > > > > > before that the "committer +1" on code change
> > might
> > > be
> > > > > > hard
> > > > > > >> to
> > > > > > >> > > > > achieve
> > > > > > >> > > > > > > > currently. On the other hand I would say this
> > would
> > > be
> > > > > > >> > beneficial
> > > > > > >> > > > for
> > > > > > >> > > > > > > > the quality/uniformity of our codebase and
> > knowledge
> > > > > > >> sharing.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > I was just wondering what should be the next
> step
> > > for
> > > > > > this?
> > > > > > >> I
> > > > > > >> > > think
> > > > > > >> > > > > it
> > > > > > >> > > > > > > > would make sense to already use those bylaws and
> > put
> > > > > them
> > > > > > to
> > > > > > >> > PMC
> > > > > > >> > > > > vote.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > Best,
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > Dawid
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > > > >> > > > > > > > > Hi Aljoscha and Becket
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > Right, 3 days for FLIP voting is fine I think.
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > >>> I’m missing this stated somewhere clearly.
> If
> > we
> > > > are
> > > > > > >> > stating
> > > > > > >> > > > > that a
> > > > > > >> > > > > > > > single
> > > > > > >> > > > > > > > >>> committers +1 is good enough for code
> review,
> > > > with 0
> > > > > > >> hours
> > > > > > >> > > > delay
> > > > > > >> > > > > > (de
> > > > > > >> > > > > > > > facto
> > > > > > >> > > > > > > > >>> the current state), we should also write
> down
> > > that
> > > > > > this
> > > > > > >> is
> > > > > > >> > > > > subject
> > > > > > >> > > > > > to
> > > > > > >> > > > > > > > the
> > > > > > >> > > > > > > > >>> best judgement of the committer to respect
> the
> > > > > > >> components
> > > > > > >> > > > > expertise
> > > > > > >> > > > > > > and
> > > > > > >> > > > > > > > >>> ongoing development plans (also the de facto
> > > > current
> > > > > > >> > state).
> > > > > > >> > > > > > > > >> Adding the statement would help clarify the
> > > > > intention,
> > > > > > >> but
> > > > > > >> > it
> > > > > > >> > > > may
> > > > > > >> > > > > > be a
> > > > > > >> > > > > > > > >> little difficult to enforce and follow..
> > > > > > >> > > > > > > > > I would be fine with that, it’s a soft/vague
> > rule
> > > > > > anyway,
> > > > > > >> > > > intended
> > > > > > >> > > > > to
> > > > > > >> > > > > > > be
> > > > > > >> > > > > > > > used with your “best judgemenet". I would like
> to
> > > just
> > > > > > >> avoid a
> > > > > > >> > > > > > situation
> > > > > > >> > > > > > > > when someone violates current uncodified state
> and
> > > > > refers
> > > > > > to
> > > > > > >> > the
> > > > > > >> > > > > bylaws
> > > > > > >> > > > > > > > which are saying merging with any committer +1
> is
> > > > always
> > > > > > >> fine
> > > > > > >> > > (like
> > > > > > >> > > > > > mine
> > > > > > >> > > > > > > +1
> > > > > > >> > > > > > > > for flink-python or flink-ml).
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > Piotrek
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <
> > > > > > >> > > aljoscha@apache.org
> > > > > > >> > > > >
> > > > > > >> > > > > > > wrote:
> > > > > > >> > > > > > > > >>
> > > > > > >> > > > > > > > >> @Piotr regarding the 3 days voting on the
> FLIP.
> > > > This
> > > > > is
> > > > > > >> just
> > > > > > >> > > > about
> > > > > > >> > > > > > the
> > > > > > >> > > > > > > > voting, before that there needs to be the
> > discussion
> > > > > > >> thread. If
> > > > > > >> > > > three
> > > > > > >> > > > > > > days
> > > > > > >> > > > > > > > have passed on a vote and there is consensus
> > (i.e. 3
> > > > > > >> > > > committers/PMCs
> > > > > > >> > > > > > have
> > > > > > >> > > > > > > > voted +1) that seems a high enough bar for me.
> So
> > > far,
> > > > > we
> > > > > > >> have
> > > > > > >> > > > rarely
> > > > > > >> > > > > > see
> > > > > > >> > > > > > > > any FLIPs pass that formal bar.
> > > > > > >> > > > > > > > >>
> > > > > > >> > > > > > > > >> According to the recent META-FLIP thread, we
> > want
> > > > to
> > > > > > use
> > > > > > >> > "lazy
> > > > > > >> > > > > > > > majority" for the FLIP voting process. I think
> > that
> > > > > should
> > > > > > >> be
> > > > > > >> > > > changed
> > > > > > >> > > > > > > from
> > > > > > >> > > > > > > > “consensus” in the proposed bylaws.
> > > > > > >> > > > > > > > >>
> > > > > > >> > > > > > > > >> Regarding the current state: do we have a
> > current
> > > > > state
> > > > > > >> that
> > > > > > >> > > we
> > > > > > >> > > > > all
> > > > > > >> > > > > > > > agree on? I have the feeling that if we try to
> > come
> > > up
> > > > > > with
> > > > > > >> > > > something
> > > > > > >> > > > > > > that
> > > > > > >> > > > > > > > reflects the common state, according to
> > > > PMCs/commiters,
> > > > > > that
> > > > > > >> > > might
> > > > > > >> > > > > > take a
> > > > > > >> > > > > > > > very long time. In that case I think it’s better
> > to
> > > > > adopt
> > > > > > >> > > something
> > > > > > >> > > > > > that
> > > > > > >> > > > > > > we
> > > > > > >> > > > > > > > all like, rather than trying to capture how we
> do
> > it
> > > > > now.
> > > > > > >> > > > > > > > >>
> > > > > > >> > > > > > > > >> Aljoscha
> > > > > > >> > > > > > > > >>
> > > > > > >> > > > > > > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <
> > > > > > >> > > piotr@ververica.com
> > > > > > >> > > > >
> > > > > > >> > > > > > > wrote:
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>> Hi,
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>> Thanks for the proposal. Generally speaking
> +1
> > > > from
> > > > > my
> > > > > > >> side
> > > > > > >> > > to
> > > > > > >> > > > > the
> > > > > > >> > > > > > > > general idea and most of the content. I also see
> > > merit
> > > > > to
> > > > > > >> the
> > > > > > >> > > > > Chesney's
> > > > > > >> > > > > > > > proposal to start from the current state. I
> think
> > > > either
> > > > > > >> would
> > > > > > >> > be
> > > > > > >> > > > > fine
> > > > > > >> > > > > > > for
> > > > > > >> > > > > > > > me.
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>> Couple of comments:
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>> 1.
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>> I also think that requiring +1 from another
> > > > > committer
> > > > > > >> would
> > > > > > >> > > > slow
> > > > > > >> > > > > > down
> > > > > > >> > > > > > > > and put even more strain on the current
> reviewing
> > > > > > bottleneck
> > > > > > >> > that
> > > > > > >> > > > we
> > > > > > >> > > > > > are
> > > > > > >> > > > > > > > having. Even if the change clear and simple,
> > context
> > > > > > switch
> > > > > > >> > cost
> > > > > > >> > > is
> > > > > > >> > > > > > quite
> > > > > > >> > > > > > > > high, and that’s just one less PR that the
> second
> > > > > “cross”
> > > > > > >> > > committer
> > > > > > >> > > > > > could
> > > > > > >> > > > > > > > have reviewed somewhere else in that time.
> > Besides,
> > > > > > current
> > > > > > >> > setup
> > > > > > >> > > > > that
> > > > > > >> > > > > > we
> > > > > > >> > > > > > > > have (with no cross +1 from another committer
> > > > required)
> > > > > > >> works
> > > > > > >> > > quite
> > > > > > >> > > > > > well
> > > > > > >> > > > > > > > and I do not feel that’s causing troubles. On
> the
> > > > other
> > > > > > hand
> > > > > > >> > > > > reviewing
> > > > > > >> > > > > > > > bottleneck is.
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>> 2.
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>>> I think a committer should know when to ask
> > > > another
> > > > > > >> > > committer
> > > > > > >> > > > > for
> > > > > > >> > > > > > > > feedback or not.
> > > > > > >> > > > > > > > >>> I’m missing this stated somewhere clearly.
> If
> > we
> > > > are
> > > > > > >> > stating
> > > > > > >> > > > > that a
> > > > > > >> > > > > > > > single committers +1 is good enough for code
> > review,
> > > > > with
> > > > > > 0
> > > > > > >> > hours
> > > > > > >> > > > > delay
> > > > > > >> > > > > > > (de
> > > > > > >> > > > > > > > facto the current state), we should also write
> > down
> > > > that
> > > > > > >> this
> > > > > > >> > is
> > > > > > >> > > > > > subject
> > > > > > >> > > > > > > to
> > > > > > >> > > > > > > > the best judgement of the committer to respect
> the
> > > > > > >> components
> > > > > > >> > > > > expertise
> > > > > > >> > > > > > > and
> > > > > > >> > > > > > > > ongoing development plans (also the de facto
> > current
> > > > > > state).
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>> 3.
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>> Minimum length of 3 days for FLIP I think
> > > > currently
> > > > > > >> might
> > > > > > >> > be
> > > > > > >> > > > > > > > problematic/too quick and can lead to problems
> if
> > > > > > respected
> > > > > > >> to
> > > > > > >> > > the
> > > > > > >> > > > > > > letter.
> > > > > > >> > > > > > > > Again I think it depends highly on whether the
> > > > > committers
> > > > > > >> with
> > > > > > >> > > > > highest
> > > > > > >> > > > > > > > expertise in the affected components managed to
> > > > respond
> > > > > or
> > > > > > >> not.
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>> Piotrek
> > > > > > >> > > > > > > > >>>
> > > > > > >> > > > > > > > >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler
> <
> > > > > > >> > > > chesnay@apache.org>
> > > > > > >> > > > > > > > wrote:
> > > > > > >> > > > > > > > >>>>
> > > > > > >> > > > > > > > >>>> I'm wondering whether we shouldn't first
> > write
> > > > down
> > > > > > >> Bylaws
> > > > > > >> > > > that
> > > > > > >> > > > > > > > reflect the current state, and then have
> separate
> > > > > > >> discussions
> > > > > > >> > for
> > > > > > >> > > > > > > > individual amendments. My gut feeling is that
> this
> > > > > > >> discussion
> > > > > > >> > > will
> > > > > > >> > > > > > > quickly
> > > > > > >> > > > > > > > become a chaotic mess with plenty points being
> > > > discussed
> > > > > > at
> > > > > > >> > once.
> > > > > > >> > > > > > > > >>>>
> > > > > > >> > > > > > > > >>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > > > > >> > > > > > > > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket
> Qin
> > <
> > > > > > >> > > > > > becket.qin@gmail.com>
> > > > > > >> > > > > > > > wrote:
> > > > > > >> > > > > > > > >>>>>
> > > > > > >> > > > > > > > >>>>>> Thanks everyone for all the comments and
> > > > > feedback.
> > > > > > >> > Please
> > > > > > >> > > > see
> > > > > > >> > > > > > the
> > > > > > >> > > > > > > > replies
> > > > > > >> > > > > > > > >>>>>> below:
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> --------------------------------
> > > > > > >> > > > > > > > >>>>>> Re: Konstantin
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>>> * In addition to a simple "Code Change"
> we
> > > > could
> > > > > > >> also
> > > > > > >> > > add a
> > > > > > >> > > > > row
> > > > > > >> > > > > > > > for "Code
> > > > > > >> > > > > > > > >>>>>>> Change requiring a FLIP" with a
> reference
> > to
> > > > the
> > > > > > >> FLIP
> > > > > > >> > > > process
> > > > > > >> > > > > > > > page. A
> > > > > > >> > > > > > > > >>>>>> FLIP
> > > > > > >> > > > > > > > >>>>>>> will have/does have different rules for
> > > > > approvals,
> > > > > > >> etc.
> > > > > > >> > > > > > > > >>>>>> Good point. Just added the entry.
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> -------------------------------
> > > > > > >> > > > > > > > >>>>>> Re: Konstantin
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>>> * For "Code Change" the draft currently
> > > > requires
> > > > > > >> "one
> > > > > > >> > +1
> > > > > > >> > > > > from a
> > > > > > >> > > > > > > > committer
> > > > > > >> > > > > > > > >>>>>>> who has not authored the patch followed
> > by a
> > > > > Lazy
> > > > > > >> > > approval
> > > > > > >> > > > > (not
> > > > > > >> > > > > > > > counting
> > > > > > >> > > > > > > > >>>>>>> the vote of the contributor), moving to
> > lazy
> > > > > > >> majority
> > > > > > >> > if
> > > > > > >> > > a
> > > > > > >> > > > -1
> > > > > > >> > > > > > is
> > > > > > >> > > > > > > > >>>>>> received".
> > > > > > >> > > > > > > > >>>>>>> In my understanding this means, that a
> > > > committer
> > > > > > >> always
> > > > > > >> > > > > needs a
> > > > > > >> > > > > > > > review
> > > > > > >> > > > > > > > >>>>>> and
> > > > > > >> > > > > > > > >>>>>>> +1 from another committer. As far as I
> > know
> > > > this
> > > > > > is
> > > > > > >> > > > currently
> > > > > > >> > > > > > not
> > > > > > >> > > > > > > > always
> > > > > > >> > > > > > > > >>>>>>> the case (often committer authors,
> > > contributor
> > > > > > >> reviews
> > > > > > >> > &
> > > > > > >> > > > > +1s).
> > > > > > >> > > > > > > > >>>>>>>
> > > > > > >> > > > > > > > >>>>>> I think it is worth thinking about how we
> > can
> > > > > make
> > > > > > it
> > > > > > >> > easy
> > > > > > >> > > > to
> > > > > > >> > > > > > > > follow the
> > > > > > >> > > > > > > > >>>>>>> bylaws e.g. by having more
> Flink-specific
> > > Jira
> > > > > > >> > workflows
> > > > > > >> > > > and
> > > > > > >> > > > > > > ticket
> > > > > > >> > > > > > > > >>>>>> types +
> > > > > > >> > > > > > > > >>>>>>> corresponding permissions. While this is
> > > > > certainly
> > > > > > >> > "Step
> > > > > > >> > > > 2",
> > > > > > >> > > > > I
> > > > > > >> > > > > > > > believe,
> > > > > > >> > > > > > > > >>>>>> we
> > > > > > >> > > > > > > > >>>>>>> really need to make it as easy &
> > transparent
> > > > as
> > > > > > >> > possible,
> > > > > > >> > > > > > > > otherwise they
> > > > > > >> > > > > > > > >>>>>>> will be unintentionally broken.
> > > > > > >> > > > > > > > >>>>>> & Re: Till
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>>> For the case of a committer being the
> > author
> > > > and
> > > > > > >> > getting
> > > > > > >> > > a
> > > > > > >> > > > +1
> > > > > > >> > > > > > > from
> > > > > > >> > > > > > > > a
> > > > > > >> > > > > > > > >>>>>>> non-committer: I think a committer
> should
> > > know
> > > > > > when
> > > > > > >> to
> > > > > > >> > > ask
> > > > > > >> > > > > > > another
> > > > > > >> > > > > > > > >>>>>>> committer for feedback or not. Hence, I
> > > would
> > > > > not
> > > > > > >> > enforce
> > > > > > >> > > > > that
> > > > > > >> > > > > > we
> > > > > > >> > > > > > > > >>>>>> strictly
> > > > > > >> > > > > > > > >>>>>>> need a +1 from a committer if the author
> > is
> > > a
> > > > > > >> committer
> > > > > > >> > > but
> > > > > > >> > > > > of
> > > > > > >> > > > > > > > course
> > > > > > >> > > > > > > > >>>>>>> encourage it if capacities exist.
> > > > > > >> > > > > > > > >>>>>> I am with Robert and Aljoscha on this.
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> I completely understand the concern here.
> > > TBH,
> > > > in
> > > > > > >> Kafka
> > > > > > >> > > > > > > occasionally
> > > > > > >> > > > > > > > >>>>>> trivial patches from committers are still
> > > > merged
> > > > > > >> without
> > > > > > >> > > > > > following
> > > > > > >> > > > > > > > the
> > > > > > >> > > > > > > > >>>>>> cross-review requirement, but it is rare.
> > > That
> > > > > > said,
> > > > > > >> I
> > > > > > >> > > still
> > > > > > >> > > > > > think
> > > > > > >> > > > > > > > an
> > > > > > >> > > > > > > > >>>>>> additional committer's review makes sense
> > due
> > > > to
> > > > > > the
> > > > > > >> > > > following
> > > > > > >> > > > > > > > reasons:
> > > > > > >> > > > > > > > >>>>>> 1. The bottom line here is that we need
> to
> > > make
> > > > > > sure
> > > > > > >> > every
> > > > > > >> > > > > patch
> > > > > > >> > > > > > > is
> > > > > > >> > > > > > > > >>>>>> reviewed with a high quality. This is a
> > > little
> > > > > > >> difficult
> > > > > > >> > > to
> > > > > > >> > > > > > > > guarantee if
> > > > > > >> > > > > > > > >>>>>> the review comes from a contributor for
> > many
> > > > > > >> reasons. In
> > > > > > >> > > > some
> > > > > > >> > > > > > > > cases, a
> > > > > > >> > > > > > > > >>>>>> contributor may not have enough knowledge
> > > about
> > > > > the
> > > > > > >> > > project
> > > > > > >> > > > to
> > > > > > >> > > > > > > make
> > > > > > >> > > > > > > > a good
> > > > > > >> > > > > > > > >>>>>> judgement. Also sometimes the
> contributors
> > > are
> > > > > more
> > > > > > >> > > eagerly
> > > > > > >> > > > to
> > > > > > >> > > > > > > get a
> > > > > > >> > > > > > > > >>>>>> particular issue fixed, so they are
> willing
> > > to
> > > > > > lower
> > > > > > >> the
> > > > > > >> > > > > review
> > > > > > >> > > > > > > bar.
> > > > > > >> > > > > > > > >>>>>> 2. One byproduct of such cross review
> among
> > > > > > >> committers,
> > > > > > >> > > > which
> > > > > > >> > > > > I
> > > > > > >> > > > > > > > personally
> > > > > > >> > > > > > > > >>>>>> feel useful, is that it helps gradually
> > form
> > > > > > >> consistent
> > > > > > >> > > > design
> > > > > > >> > > > > > > > principles
> > > > > > >> > > > > > > > >>>>>> and code style. This is because the
> > > committers
> > > > > will
> > > > > > >> know
> > > > > > >> > > how
> > > > > > >> > > > > the
> > > > > > >> > > > > > > > other
> > > > > > >> > > > > > > > >>>>>> committers are writing code and learn
> from
> > > each
> > > > > > >> other.
> > > > > > >> > So
> > > > > > >> > > > they
> > > > > > >> > > > > > > tend
> > > > > > >> > > > > > > > to
> > > > > > >> > > > > > > > >>>>>> reach some tacit understanding on how
> > things
> > > > > should
> > > > > > >> be
> > > > > > >> > > done
> > > > > > >> > > > in
> > > > > > >> > > > > > > > general.
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> Another way to think about this is to
> > > consider
> > > > > the
> > > > > > >> > > following
> > > > > > >> > > > > two
> > > > > > >> > > > > > > > scenarios:
> > > > > > >> > > > > > > > >>>>>> 1. Reviewing a committer's patch takes a
> > lot
> > > of
> > > > > > >> > > iterations.
> > > > > > >> > > > > Then
> > > > > > >> > > > > > > > the patch
> > > > > > >> > > > > > > > >>>>>> needs to be reviewed even if it takes
> time
> > > > > because
> > > > > > >> there
> > > > > > >> > > are
> > > > > > >> > > > > > > things
> > > > > > >> > > > > > > > >>>>>> actually needs to be clarified / changed.
> > > > > > >> > > > > > > > >>>>>> 2. Reviewing a committer's patch is very
> > > smooth
> > > > > and
> > > > > > >> > quick,
> > > > > > >> > > > so
> > > > > > >> > > > > > the
> > > > > > >> > > > > > > > patch is
> > > > > > >> > > > > > > > >>>>>> merged soon. Then reviewing such a patch
> > does
> > > > not
> > > > > > >> take
> > > > > > >> > > much
> > > > > > >> > > > > > time.
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> Letting another committer review the
> patch
> > > > from a
> > > > > > >> > > committer
> > > > > > >> > > > > > falls
> > > > > > >> > > > > > > > either in
> > > > > > >> > > > > > > > >>>>>> case 1 or case 2. The best option here is
> > to
> > > > > review
> > > > > > >> the
> > > > > > >> > > > patch
> > > > > > >> > > > > > > > because
> > > > > > >> > > > > > > > >>>>>> If it is case 1, the patch actually needs
> > to
> > > be
> > > > > > >> > reviewed.
> > > > > > >> > > > > > > > >>>>>> If it is case 2, the review should not
> take
> > > > much
> > > > > > time
> > > > > > >> > > > anyways.
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> In the contrast, we will risk encounter
> > case
> > > 1
> > > > if
> > > > > > we
> > > > > > >> > skip
> > > > > > >> > > > the
> > > > > > >> > > > > > > > cross-review.
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> ------------------------
> > > > > > >> > > > > > > > >>>>>> Re: Robert
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> I replied to your comments in the wiki
> and
> > > made
> > > > > the
> > > > > > >> > > > following
> > > > > > >> > > > > > > > modifications
> > > > > > >> > > > > > > > >>>>>> to resolve some of your comments:
> > > > > > >> > > > > > > > >>>>>> 1. Added a release manager role section.
> > > > > > >> > > > > > > > >>>>>> 2. changed the name of "lazy consensus"
> to
> > > > > > >> "consensus"
> > > > > > >> > to
> > > > > > >> > > > > align
> > > > > > >> > > > > > > with
> > > > > > >> > > > > > > > >>>>>> general definition of Apache glossary and
> > > other
> > > > > > >> > projects.
> > > > > > >> > > > > > > > >>>>>> 3. review board  -> pull request
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> -------------------------
> > > > > > >> > > > > > > > >>>>>> Re: Chesnay
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> The emeritus stuff seems like unnecessary
> > > > noise.
> > > > > > >> > > > > > > > >>>>>> As Till mentioned, this is to make sure
> 2/3
> > > > > > majority
> > > > > > >> is
> > > > > > >> > > > still
> > > > > > >> > > > > > > > feasible in
> > > > > > >> > > > > > > > >>>>>> practice.
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> There's a bunch of subtle changes in the
> > > draft
> > > > > > >> compared
> > > > > > >> > to
> > > > > > >> > > > > > > existing
> > > > > > >> > > > > > > > >>>>>>> "conventions"; we should find a way to
> > > > highlight
> > > > > > >> these
> > > > > > >> > > and
> > > > > > >> > > > > > > discuss
> > > > > > >> > > > > > > > them
> > > > > > >> > > > > > > > >>>>>>> one by one.
> > > > > > >> > > > > > > > >>>>>> That is a good suggestion. I am not
> > familiar
> > > > > enough
> > > > > > >> with
> > > > > > >> > > the
> > > > > > >> > > > > > > > current Flink
> > > > > > >> > > > > > > > >>>>>> convention. Will you help on this? I saw
> > you
> > > > > > >> commented
> > > > > > >> > on
> > > > > > >> > > > some
> > > > > > >> > > > > > > part
> > > > > > >> > > > > > > > in the
> > > > > > >> > > > > > > > >>>>>> wiki. Are those complete?
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> --------------------------
> > > > > > >> > > > > > > > >>>>>> Re: Aljoscha
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> How different is this from the Kafka
> > bylaws?
> > > > I’m
> > > > > > >> asking
> > > > > > >> > > > > because
> > > > > > >> > > > > > I
> > > > > > >> > > > > > > > quite
> > > > > > >> > > > > > > > >>>>>>> like them and wouldn’t mind essentially
> > > > adopting
> > > > > > the
> > > > > > >> > > Kafka
> > > > > > >> > > > > > > bylaws.
> > > > > > >> > > > > > > > I
> > > > > > >> > > > > > > > >>>>>> mean,
> > > > > > >> > > > > > > > >>>>>>> it’s open source, and we don’t have to
> try
> > > to
> > > > > > >> re-invent
> > > > > > >> > > the
> > > > > > >> > > > > > wheel
> > > > > > >> > > > > > > > here.
> > > > > > >> > > > > > > > >>>>>> Ha, you got me on this. The first version
> > of
> > > > the
> > > > > > >> draft
> > > > > > >> > was
> > > > > > >> > > > > > almost
> > > > > > >> > > > > > > > identical
> > > > > > >> > > > > > > > >>>>>> to Kafka. But Robert has already caught a
> > few
> > > > > > >> > inconsistent
> > > > > > >> > > > > > places.
> > > > > > >> > > > > > > > So it
> > > > > > >> > > > > > > > >>>>>> might still worth going through it to
> make
> > > sure
> > > > > we
> > > > > > >> truly
> > > > > > >> > > > agree
> > > > > > >> > > > > > on
> > > > > > >> > > > > > > > them.
> > > > > > >> > > > > > > > >>>>>> Otherwise we may end up modifying them
> > > shortly
> > > > > > after
> > > > > > >> > > > adoption.
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> Thanks again folks, for all the valuable
> > > > > feedback.
> > > > > > >> These
> > > > > > >> > > are
> > > > > > >> > > > > > great
> > > > > > >> > > > > > > > >>>>>> discussion.
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> Jiangjie (Becket) Qin
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha
> > > > Krettek
> > > > > <
> > > > > > >> > > > > > > > aljoscha@apache.org>
> > > > > > >> > > > > > > > >>>>>> wrote:
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > > >>>>>>> Big +1
> > > > > > >> > > > > > > > >>>>>>>
> > > > > > >> > > > > > > > >>>>>>> How different is this from the Kafka
> > bylaws?
> > > > I’m
> > > > > > >> asking
> > > > > > >> > > > > > because I
> > > > > > >> > > > > > > > quite
> > > > > > >> > > > > > > > >>>>>>> like them and wouldn’t mind essentially
> > > > adopting
> > > > > > the
> > > > > > >> > > Kafka
> > > > > > >> > > > > > > bylaws.
> > > > > > >> > > > > > > > I
> > > > > > >> > > > > > > > >>>>>> mean,
> > > > > > >> > > > > > > > >>>>>>> it’s open source, and we don’t have to
> try
> > > to
> > > > > > >> re-invent
> > > > > > >> > > the
> > > > > > >> > > > > > wheel
> > > > > > >> > > > > > > > here.
> > > > > > >> > > > > > > > >>>>>>>
> > > > > > >> > > > > > > > >>>>>>> I think it’s worthwhile to discuss the
> > > > > “committer
> > > > > > >> +1”
> > > > > > >> > > > > > > requirement.
> > > > > > >> > > > > > > > We
> > > > > > >> > > > > > > > >>>>>>> don’t usually have that now but I would
> > > > actually
> > > > > > be
> > > > > > >> in
> > > > > > >> > > > favour
> > > > > > >> > > > > > of
> > > > > > >> > > > > > > > >>>>>> requiring
> > > > > > >> > > > > > > > >>>>>>> it, although it might make stuff more
> > > > > complicated.
> > > > > > >> > > > > > > > >>>>>>>
> > > > > > >> > > > > > > > >>>>>>> Aljoscha
> > > > > > >> > > > > > > > >>>>>>>
> > > > > > >> > > > > > > > >>>>>>>> On 11. Jul 2019, at 15:31, Till
> Rohrmann
> > <
> > > > > > >> > > > > > trohrmann@apache.org>
> > > > > > >> > > > > > > > wrote:
> > > > > > >> > > > > > > > >>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>> Thanks a lot for creating this draft
> > > Becket.
> > > > > > >> > > > > > > > >>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>> I think without the notion of emeritus
> > (or
> > > > > active
> > > > > > >> vs.
> > > > > > >> > > > > > inactive),
> > > > > > >> > > > > > > > it
> > > > > > >> > > > > > > > >>>>>> won't
> > > > > > >> > > > > > > > >>>>>>>> be possible to have a 2/3 majority vote
> > > > because
> > > > > > we
> > > > > > >> > > already
> > > > > > >> > > > > > have
> > > > > > >> > > > > > > > too
> > > > > > >> > > > > > > > >>>>>> many
> > > > > > >> > > > > > > > >>>>>>>> inactive PMCs/committers.
> > > > > > >> > > > > > > > >>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>> For the case of a committer being the
> > > author
> > > > > and
> > > > > > >> > > getting a
> > > > > > >> > > > > +1
> > > > > > >> > > > > > > > from a
> > > > > > >> > > > > > > > >>>>>>>> non-committer: I think a committer
> should
> > > > know
> > > > > > >> when to
> > > > > > >> > > ask
> > > > > > >> > > > > > > another
> > > > > > >> > > > > > > > >>>>>>>> committer for feedback or not. Hence, I
> > > would
> > > > > not
> > > > > > >> > > enforce
> > > > > > >> > > > > that
> > > > > > >> > > > > > > we
> > > > > > >> > > > > > > > >>>>>>> strictly
> > > > > > >> > > > > > > > >>>>>>>> need a +1 from a committer if the
> author
> > > is a
> > > > > > >> > committer
> > > > > > >> > > > but
> > > > > > >> > > > > of
> > > > > > >> > > > > > > > course
> > > > > > >> > > > > > > > >>>>>>>> encourage it if capacities exist.
> > > > > > >> > > > > > > > >>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>> Cheers,
> > > > > > >> > > > > > > > >>>>>>>> Till
> > > > > > >> > > > > > > > >>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM Chesnay
> > > > > Schepler
> > > > > > <
> > > > > > >> > > > > > > > chesnay@apache.org>
> > > > > > >> > > > > > > > >>>>>>> wrote:
> > > > > > >> > > > > > > > >>>>>>>>> The emeritus stuff seems like
> > unnecessary
> > > > > noise.
> > > > > > >> > > > > > > > >>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>> There's a bunch of subtle changes in
> the
> > > > draft
> > > > > > >> > compared
> > > > > > >> > > > to
> > > > > > >> > > > > > > > existing
> > > > > > >> > > > > > > > >>>>>>>>> "conventions"; we should find a way to
> > > > > highlight
> > > > > > >> > these
> > > > > > >> > > > and
> > > > > > >> > > > > > > > discuss
> > > > > > >> > > > > > > > >>>>>> them
> > > > > > >> > > > > > > > >>>>>>>>> one by one.
> > > > > > >> > > > > > > > >>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>> On 11/07/2019 14:29, Robert Metzger
> > wrote:
> > > > > > >> > > > > > > > >>>>>>>>>> Thank you Becket for kicking off this
> > > > > > discussion
> > > > > > >> and
> > > > > > >> > > > > > creating
> > > > > > >> > > > > > > a
> > > > > > >> > > > > > > > draft
> > > > > > >> > > > > > > > >>>>>>> in
> > > > > > >> > > > > > > > >>>>>>>>>> the Wiki.
> > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>> I left some comments in the wiki.
> > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>> In my understanding this means, that
> a
> > > > > > committer
> > > > > > >> > > always
> > > > > > >> > > > > > needs
> > > > > > >> > > > > > > a
> > > > > > >> > > > > > > > >>>>>> review
> > > > > > >> > > > > > > > >>>>>>>>> and
> > > > > > >> > > > > > > > >>>>>>>>>>> +1 from another committer. As far
> as I
> > > > know
> > > > > > >> this is
> > > > > > >> > > > > > currently
> > > > > > >> > > > > > > > not
> > > > > > >> > > > > > > > >>>>>>> always
> > > > > > >> > > > > > > > >>>>>>>>>>> the case (often committer authors,
> > > > > contributor
> > > > > > >> > > reviews
> > > > > > >> > > > &
> > > > > > >> > > > > > > +1s).
> > > > > > >> > > > > > > > >>>>>>>>>> I would agree to add such a bylaw, if
> > we
> > > > had
> > > > > > >> cases
> > > > > > >> > in
> > > > > > >> > > > the
> > > > > > >> > > > > > past
> > > > > > >> > > > > > > > where
> > > > > > >> > > > > > > > >>>>>>> code
> > > > > > >> > > > > > > > >>>>>>>>>> was not sufficiently reviewed AND we
> > > > believe
> > > > > > >> that we
> > > > > > >> > > > have
> > > > > > >> > > > > > > enough
> > > > > > >> > > > > > > > >>>>>>> capacity
> > > > > > >> > > > > > > > >>>>>>>>>> to ensure a separate committer's
> > > approval.
> > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> > > Konstantin
> > > > > > Knauf
> > > > > > >> <
> > > > > > >> > > > > > > > >>>>>>>>> konstantin@ververica.com>
> > > > > > >> > > > > > > > >>>>>>>>>> wrote:
> > > > > > >> > > > > > > > >>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> Hi all,
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> thanks a lot for driving this,
> > Becket. I
> > > > > have
> > > > > > >> two
> > > > > > >> > > > remarks
> > > > > > >> > > > > > > > regarding
> > > > > > >> > > > > > > > >>>>>>> the
> > > > > > >> > > > > > > > >>>>>>>>>>> "Actions" section:
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> * In addition to a simple "Code
> > Change"
> > > we
> > > > > > could
> > > > > > >> > also
> > > > > > >> > > > > add a
> > > > > > >> > > > > > > > row for
> > > > > > >> > > > > > > > >>>>>>>>> "Code
> > > > > > >> > > > > > > > >>>>>>>>>>> Change requiring a FLIP" with a
> > > reference
> > > > to
> > > > > > the
> > > > > > >> > FLIP
> > > > > > >> > > > > > process
> > > > > > >> > > > > > > > page.
> > > > > > >> > > > > > > > >>>>>> A
> > > > > > >> > > > > > > > >>>>>>>>> FLIP
> > > > > > >> > > > > > > > >>>>>>>>>>> will have/does have different rules
> > for
> > > > > > >> approvals,
> > > > > > >> > > etc.
> > > > > > >> > > > > > > > >>>>>>>>>>> * For "Code Change" the draft
> > currently
> > > > > > requires
> > > > > > >> > "one
> > > > > > >> > > > +1
> > > > > > >> > > > > > > from a
> > > > > > >> > > > > > > > >>>>>>>>> committer
> > > > > > >> > > > > > > > >>>>>>>>>>> who has not authored the patch
> > followed
> > > > by a
> > > > > > >> Lazy
> > > > > > >> > > > > approval
> > > > > > >> > > > > > > (not
> > > > > > >> > > > > > > > >>>>>>> counting
> > > > > > >> > > > > > > > >>>>>>>>>>> the vote of the contributor), moving
> > to
> > > > lazy
> > > > > > >> > majority
> > > > > > >> > > > if
> > > > > > >> > > > > a
> > > > > > >> > > > > > -1
> > > > > > >> > > > > > > > is
> > > > > > >> > > > > > > > >>>>>>>>> received".
> > > > > > >> > > > > > > > >>>>>>>>>>> In my understanding this means,
> that a
> > > > > > committer
> > > > > > >> > > always
> > > > > > >> > > > > > > needs a
> > > > > > >> > > > > > > > >>>>>> review
> > > > > > >> > > > > > > > >>>>>>>>> and
> > > > > > >> > > > > > > > >>>>>>>>>>> +1 from another committer. As far
> as I
> > > > know
> > > > > > >> this is
> > > > > > >> > > > > > currently
> > > > > > >> > > > > > > > not
> > > > > > >> > > > > > > > >>>>>>> always
> > > > > > >> > > > > > > > >>>>>>>>>>> the case (often committer authors,
> > > > > contributor
> > > > > > >> > > reviews
> > > > > > >> > > > &
> > > > > > >> > > > > > > +1s).
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> I think it is worth thinking about
> how
> > > we
> > > > > can
> > > > > > >> make
> > > > > > >> > it
> > > > > > >> > > > > easy
> > > > > > >> > > > > > to
> > > > > > >> > > > > > > > follow
> > > > > > >> > > > > > > > >>>>>>> the
> > > > > > >> > > > > > > > >>>>>>>>>>> bylaws e.g. by having more
> > > Flink-specific
> > > > > Jira
> > > > > > >> > > > workflows
> > > > > > >> > > > > > and
> > > > > > >> > > > > > > > ticket
> > > > > > >> > > > > > > > >>>>>>>>> types +
> > > > > > >> > > > > > > > >>>>>>>>>>> corresponding permissions. While
> this
> > is
> > > > > > >> certainly
> > > > > > >> > > > "Step
> > > > > > >> > > > > > 2",
> > > > > > >> > > > > > > I
> > > > > > >> > > > > > > > >>>>>>> believe,
> > > > > > >> > > > > > > > >>>>>>>>> we
> > > > > > >> > > > > > > > >>>>>>>>>>> really need to make it as easy &
> > > > transparent
> > > > > > as
> > > > > > >> > > > possible,
> > > > > > >> > > > > > > > otherwise
> > > > > > >> > > > > > > > >>>>>>> they
> > > > > > >> > > > > > > > >>>>>>>>>>> will be unintentionally broken.
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> Cheers and thanks,
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> Konstantin
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM
> Becket
> > > > Qin <
> > > > > > >> > > > > > > > becket.qin@gmail.com>
> > > > > > >> > > > > > > > >>>>>>>>> wrote:
> > > > > > >> > > > > > > > >>>>>>>>>>>> Hi all,
> > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>> As it was raised in the FLIP
> process
> > > > > > discussion
> > > > > > >> > > thread
> > > > > > >> > > > > > [1],
> > > > > > >> > > > > > > > >>>>>> currently
> > > > > > >> > > > > > > > >>>>>>>>>>> Flink
> > > > > > >> > > > > > > > >>>>>>>>>>>> does not have official bylaws to
> > govern
> > > > the
> > > > > > >> > > operation
> > > > > > >> > > > of
> > > > > > >> > > > > > the
> > > > > > >> > > > > > > > >>>>>> project.
> > > > > > >> > > > > > > > >>>>>>>>>>> Such
> > > > > > >> > > > > > > > >>>>>>>>>>>> bylaws are critical for the
> community
> > > to
> > > > > > >> > coordinate
> > > > > > >> > > > and
> > > > > > >> > > > > > > > contribute
> > > > > > >> > > > > > > > >>>>>>>>>>>> together. It is also the basis of
> > other
> > > > > > >> processes
> > > > > > >> > > such
> > > > > > >> > > > > as
> > > > > > >> > > > > > > > FLIP.
> > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>> I have drafted a Flink bylaws page
> > and
> > > > > would
> > > > > > >> like
> > > > > > >> > to
> > > > > > >> > > > > > start a
> > > > > > >> > > > > > > > >>>>>>> discussion
> > > > > > >> > > > > > > > >>>>>>>>>>>> thread on this.
> > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > > > > >> > > > > > > > >>>>>>>>>>>> The bylaws will affect everyone in
> > the
> > > > > > >> community.
> > > > > > >> > > > It'll
> > > > > > >> > > > > be
> > > > > > >> > > > > > > > great to
> > > > > > >> > > > > > > > >>>>>>>>> hear
> > > > > > >> > > > > > > > >>>>>>>>>>>> your thoughts.
> > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>> Thanks,
> > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>> [1]
> > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> > > > > > >> > > > > > > > >>>>>>>>>>> --
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> Konstantin Knauf | Solutions
> Architect
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> +49 160 91394525
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> Planned Absences: 10.08.2019 -
> > > 31.08.2019,
> > > > > > >> 05.09. -
> > > > > > >> > > > > > > 06.09.2010
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> --
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> Ververica GmbH | Invalidenstrasse
> 115,
> > > > 10115
> > > > > > >> > Berlin,
> > > > > > >> > > > > > Germany
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> --
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > > >>>>>>>>>>> Ververica GmbH
> > > > > > >> > > > > > > > >>>>>>>>>>> Registered at Amtsgericht
> > > Charlottenburg:
> > > > > HRB
> > > > > > >> > 158244
> > > > > > >> > > B
> > > > > > >> > > > > > > > >>>>>>>>>>> Managing Directors: Dr. Kostas
> > Tzoumas,
> > > > Dr.
> > > > > > >> Stephan
> > > > > > >> > > > Ewen
> > > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Flink project bylaws

[Becket Qin <be...@gmail.com>]

Thanks Stephan.

I think we have resolved all the comments on the wiki page. There are two
minor changes made to the bylaws since last week.
1. For 2/3 majority, the required attempts to reach out to binding voters
is reduced from 3 to 2. This helps shorten the voting process a little bit.
2. Clarified what is considered as the adoption of new codebase.

I think we almost reached consensus. I'll start a voting thread in two days
if there is no new concerns.

Thanks,

Jiangjie (Becket) Qin

On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <se...@apache.org> wrote:

> I added a clarification to the table, clarifying that the current phrasing
> means that committers do not need another +1 for their commits.
>
> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <fh...@gmail.com> wrote:
>
> > Hi Becket,
> >
> > Thanks a lot for pushing this forward and addressing the feedback.
> > I'm very happy with the current state of the bylaws.
> > +1 to wait until Friday before starting a vote.
> >
> > Best, Fabian
> >
> > Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
> > becket.qin@gmail.com
> > >:
> >
> > > Hi Everyone,
> > >
> > > Thanks for all the discussion and feedback.
> > >
> > > It seems that we have almost reached consensus. I'll leave the
> discussion
> > > thread open until this Friday. If there is no more concerns raised,
> I'll
> > > start a voting thread after that.
> > >
> > > Thanks,
> > >
> > > Jiangjie (Becket) Qin
> > >
> > > On Fri, Jul 26, 2019 at 6:49 PM Yu Li <ca...@gmail.com> wrote:
> > >
> > > > Hi Becket,
> > > >
> > > > Thanks for noticing and resolving my comment around PMC removal and
> ASF
> > > > rules of PMC membership change process, which you seem to neglect in
> > the
> > > > summary of updates (smile).
> > > >
> > > > Best Regards,
> > > > Yu
> > > >
> > > >
> > > > On Wed, 24 Jul 2019 at 04:32, Becket Qin <be...@gmail.com>
> wrote:
> > > >
> > > > > Hi folks,
> > > > >
> > > > > Thanks for all the feedback.
> > > > >
> > > > > It seems that there are a few concerns over the emeritus status
> > after 6
> > > > > months of inactivity. Given that the main purpose is just to make
> > sure
> > > > 2/3
> > > > > majority can pass and we sort of have a solution for that, I just
> > > updated
> > > > > the draft with the following changes:
> > > > >
> > > > > 1. Removed the inactivity term for emeritus committers / PMCs. A
> > > > committer
> > > > > / PMC will only be considered emeritus by their own claim.
> > > > > 2. Removed the approval process for reinstatement of the emeritus
> > > > > committers / PMCs. An emeritus committer / PMC will be reinstated
> > when
> > > > they
> > > > > send an email to the private@flink.apache.org.
> > > > > 3. Adde the term to ensure 2/3 majority voting is still doable when
> > > there
> > > > > are non-emeritus committers / PMCs who do not cast the vote.
> > > > >
> > > > > Please let me know if you have any further thoughts.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jiangjie (Becket) Qin
> > > > >
> > > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <be...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Hi Fabian,
> > > > > >
> > > > > > Thanks for the feedback.
> > > > > >
> > > > > > I agree that if we don't like emeritus committers / PMCs, we
> don't
> > > have
> > > > > to
> > > > > > do it. That said, emeritus status simply means whether an
> > individual
> > > is
> > > > > > active / inactive in the community. It does not make the merits
> > > earned
> > > > to
> > > > > > go away. For our purpose, emeritus status is mostly just a way to
> > > make
> > > > > 2/3
> > > > > > majority possible. As you noticed, since reaching out to binding
> > > voters
> > > > > who
> > > > > > have not voted can achieve the same goal, the emeritus status is
> > more
> > > > of
> > > > > an
> > > > > > optimization so we don't have to ping the inactive binding voters
> > > every
> > > > > > time and wait for long. However, given that 2/3 majority votings
> > are
> > > > > rare,
> > > > > > such communication cost is probably OK. So I think we can remove
> > that
> > > > > > emeritus part from the bylaws.
> > > > > >
> > > > > > 1) We should add to the requirements of the PMC that they need to
> > > make
> > > > > >> sure the project complies with brand issues and reports misuse
> of
> > > ASF
> > > > > >> brands.
> > > > > >
> > > > > > Good point. Added.
> > > > > >
> > > > > > 2) Do we want to restrict voting days to working days, i.e., a 3
> > day
> > > > vote
> > > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > > > >
> > > > > > This might be a little tricky because people are from countries
> in
> > > > > > different time zones and with different holidays, and so on. If
> we
> > > are
> > > > > > worrying about 3 days minimum length is not enough for those who
> > want
> > > > to
> > > > > > give feedback, we can make it 5 days.
> > > > > >
> > > > > > 3) Do we need a process do decide about removal of features (like
> > the
> > > > > >> DataSet API for instance or the legacy DataSet/DataStream Python
> > > > APIs)?
> > > > > >
> > > > > > I assume such action should be covered by FLIP as it is a change
> to
> > > the
> > > > > > API and probably needs a migration plan. It would be useful to
> > have a
> > > > > > formal deprecation procedure. But that might be better to be put
> > into
> > > > > > somewhere else because the bylaws are primarily focusing on the
> > > > > > non-technical rules, whereas the deprecation seems more on the
> > > > technical
> > > > > > side.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Jiangjie (Becket) Qin
> > > > > >
> > > > > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
> fhueske@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> Hi all,
> > > > > >>
> > > > > >> First of all thank you very much Becket for starting this
> > > discussion!
> > > > > >> I think it is a very good idea and overdue to formally define
> some
> > > of
> > > > > our
> > > > > >> community processes.
> > > > > >>
> > > > > >> Similar to Chesnay, I have concerns about the distinction
> between
> > > > active
> > > > > >> and non-active / emeritus committers and PMC members.
> > > > > >> My foremost concern is that this is not in the spirit of the
> > Apache
> > > > Way
> > > > > >> [1]
> > > > > >> which is (among other things) based on the idea of merit which
> > once
> > > > > >> earned,
> > > > > >> does not go away over time.
> > > > > >> I know other projects like Hadoop and Kafka have similar clauses
> > in
> > > > the
> > > > > >> bylaws but IMO we don't need to adopt them if we don't like
> them.
> > > > > >> For example, I don't like the idea that committers or PMC
> members
> > > who
> > > > > are
> > > > > >> temporarily away from the project (for whatever reason: parental
> > > > leave,
> > > > > >> sabbatical, health issues, etc.) need the PMC approval to be
> > > "active"
> > > > > >> again.
> > > > > >> As far as I am aware, we have not seen any issues with inactive
> > > > members
> > > > > in
> > > > > >> the past.
> > > > > >> Moreover, it would be hard to track whether somebody became
> > inactive
> > > > at
> > > > > >> some point in time (which we would need to do, if I understand
> the
> > > > > >> proposal
> > > > > >> correctly).
> > > > > >> With the approach that Becket suggested in his last email
> > (reaching
> > > > out
> > > > > to
> > > > > >> binding voters who haven't voted yet), we could drop the
> > distinction
> > > > > >> between active and non-active committers and PMC members.
> > > > > >>
> > > > > >> I also have a few minor comments:
> > > > > >>
> > > > > >> 1) We should add to the requirements of the PMC [2] that they
> need
> > > to
> > > > > make
> > > > > >> sure the project complies with brand issues and reports misuse
> of
> > > ASF
> > > > > >> brands.
> > > > > >> 2) Do we want to restrict voting days to working days, i.e., a 3
> > day
> > > > > vote
> > > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > > > > >> 3) Do we need a process do decide about removal of features
> (like
> > > the
> > > > > >> DataSet API for instance or the legacy DataSet/DataStream Python
> > > > APIs)?
> > > > > >>
> > > > > >> Thank you,
> > > > > >> Fabian
> > > > > >>
> > > > > >> [1] https://www.apache.org/theapacheway/
> > > > > >> [2] https://www.apache.org/dev/pmc.html
> > > > > >>
> > > > > >> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> > > > > >> becket.qin@gmail.com
> > > > > >> >:
> > > > > >>
> > > > > >> > Hi Hequn,
> > > > > >> >
> > > > > >> > Thanks for sharing your thoughts. Please see the reply below:
> > > > > >> >
> > > > > >> > > Perhaps what Jincheng means is to hold at least one PMC in
> > the 3
> > > > > >> binding
> > > > > >> > > votes? i.e, the vote could have 2 binding committers and 1
> > PMC.
> > > > > >> > > I think this makes sense considering a FLIP could somehow
> be a
> > > big
> > > > > >> > feature
> > > > > >> > > which may impacts Flink a lot. Meanwhile, there is no loss
> of
> > > > > >> flexibility
> > > > > >> > > as committers also have a chance to vote and participate in
> > it.
> > > > > >> > A few concerns of requiring a PMC vote in all FLIPs are the
> > > > following:
> > > > > >> >
> > > > > >> > 1. Generally speaking, the PMC's primary responsibility is
> > > operating
> > > > > the
> > > > > >> > project and deciding what software to release on behalf of
> ASF.
> > > > > >> Committers,
> > > > > >> > on the other hand, are responsible for the technical part of
> the
> > > > > >> project.
> > > > > >> > So for FLIPs, a PMC's vote probably should not outweigh a
> > > > committer's
> > > > > >> vote.
> > > > > >> > Besides, I am not sure whether a single PMCs +1 is really
> > > convincing
> > > > > >> enough
> > > > > >> > to decide whether the FLIP is good to go or not. Also, if some
> > > > > >> committers
> > > > > >> > have concern over a FLIP, they could just veto it. To me it is
> > > > > actually
> > > > > >> a
> > > > > >> > more strict requirement to pass a FLIP than asking a PMC to
> > vote.
> > > In
> > > > > >> > practice, people will usually also address the concerns even
> if
> > > they
> > > > > are
> > > > > >> > not from a PMC/committer before they start the voting process.
> > So
> > > I
> > > > > >> don't
> > > > > >> > see much benefit of requiring a PMC's vote in this case.
> > > > > >> >
> > > > > >> > 2. The at-least-one-PMC-vote requirement makes the votes no
> > longer
> > > > > >> > independent. Ideally, a vote is either binding or non-binding
> by
> > > > > >> itself. If
> > > > > >> > we have the at-least-one-PMC-vote requirement here, imagine
> > there
> > > > have
> > > > > >> been
> > > > > >> > 3 committers who voted +1. But the FLIP still has not passed,
> so
> > > > those
> > > > > >> > votes are effectively non-binding. Now a PMC votes a +1, those
> > > votes
> > > > > >> > suddenly become binding, which is a little awkward.
> > > > > >> >
> > > > > >> >
> > > > > >> > The lazy 2/3 majority suggestion sounds reasonable to me. Some
> > > > > thoughts
> > > > > >> on
> > > > > >> > this:
> > > > > >> > 1. One reason Hadoop uses lazy 2/3 majority is probably
> because
> > > > there
> > > > > >> are
> > > > > >> > 104 PMC members[1] for Hadoop which makes the 2/3 majority
> > > > > prohibitively
> > > > > >> > expensive. In our case, there are only 22 PMCs for Flink[2]
> and
> > a
> > > > > quick
> > > > > >> > search shows at most 6 of them have not sent email in the
> > recent 6
> > > > > >> months
> > > > > >> > or so.
> > > > > >> >
> > > > > >> > 2. 2/3 majority votes are supposed to be very rare. It is
> > designed
> > > > in
> > > > > >> > particular for the cases that broad opinions are important,
> more
> > > > > >> > specifically new codebase adoption or modification to the
> > bylaws.
> > > > > >> Therefore
> > > > > >> > such vote by its nature favors consensus over convenience.
> That
> > > > means
> > > > > >> any
> > > > > >> > alternative voting type reducing the coverage worth a careful
> > > > > thinking.
> > > > > >> >
> > > > > >> > 3. I do agree that it does not make sense to have 2/3 majority
> > if
> > > > such
> > > > > >> > requirement is no-longer doable over time. But I am a little
> > > > hesitant
> > > > > to
> > > > > >> > lower the threshold to lazy 2/3 majority in our case. What do
> > you
> > > > > think
> > > > > >> > about doing the following:
> > > > > >> >     - After the voting started, there will be at least 6 days
> > for
> > > > > >> people to
> > > > > >> > cast their votes.
> > > > > >> >     - After 6 days, if the result of the vote is still not
> > > > determined,
> > > > > >> the
> > > > > >> > person who started the vote should reach out to the binding
> > voters
> > > > who
> > > > > >> have
> > > > > >> > not voted yet for at least 3 times and at least 7 days between
> > > each
> > > > > >> time.
> > > > > >> > If a binding voter still did not respond, the vote from that
> > voter
> > > > > will
> > > > > >> be
> > > > > >> > excluded from the 2/3 majority counting.
> > > > > >> > This would ensure the coverage at our best effort while still
> > let
> > > > the
> > > > > >> 2/3
> > > > > >> > majority vote make progress.
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> >
> > > > > >> > Jiangjie (Becket) Qin
> > > > > >> >
> > > > > >> >
> > > > > >> > [1] https://projects.apache.org/committee.html?hadoop
> > > > > >> > [2] https://projects.apache.org/committee.html?flink
> > > > > >> >
> > > > > >> > On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <
> > > forwardxu315@gmail.com>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > > Big +1 on this.
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > best
> > > > > >> > >
> > > > > >> > > forward
> > > > > >> > >
> > > > > >> > > Hequn Cheng <ch...@gmail.com> 于2019年7月21日周日 下午1:30写道：
> > > > > >> > >
> > > > > >> > > > Hi Becket,
> > > > > >> > > >
> > > > > >> > > > Big +1 on this.
> > > > > >> > > >
> > > > > >> > > > > Regarding the vote of FLIP, preferably at least
> includes a
> > > PMC
> > > > > >> vote.
> > > > > >> > > > Perhaps what Jincheng means is to hold at least one PMC in
> > > the 3
> > > > > >> > binding
> > > > > >> > > > votes? i.e, the vote could have 2 binding committers and 1
> > > PMC.
> > > > > >> > > > I think this makes sense considering a FLIP could somehow
> > be a
> > > > big
> > > > > >> > > feature
> > > > > >> > > > which may impacts Flink a lot. Meanwhile, there is no loss
> > of
> > > > > >> > flexibility
> > > > > >> > > > as committers also have a chance to vote and participate
> in
> > > it.
> > > > > >> > > >
> > > > > >> > > > ========Seperator========
> > > > > >> > > >
> > > > > >> > > > For the nice bylaws, I agree with the general idea and
> most
> > of
> > > > the
> > > > > >> > > content.
> > > > > >> > > > Only share some thoughts about the "2/3 Majority". The
> main
> > > > > concern
> > > > > >> is
> > > > > >> > I
> > > > > >> > > am
> > > > > >> > > > not sure if it is doable in practice. The reasons are:
> > > > > >> > > >
> > > > > >> > > > 1. If we follow the bylaws strictly, it means a committer
> > or a
> > > > PMC
> > > > > >> > member
> > > > > >> > > > is active if he or she sends one email to the mailing list
> > > > every 6
> > > > > >> > > months.
> > > > > >> > > > While the minimum length of the vote is only 6 days. There
> > are
> > > > > >> chances
> > > > > >> > > that
> > > > > >> > > > during the vote, some of the active members are still
> > offline
> > > of
> > > > > the
> > > > > >> > > > community.
> > > > > >> > > > 2. The code of Flink is changing fast and not everyone
> fully
> > > > > >> > understands
> > > > > >> > > > every part. We don't need to force people to vote if they
> > are
> > > > not
> > > > > >> sure
> > > > > >> > > > about it. It may also make the final result less credible.
> > > > > >> > > >
> > > > > >> > > > Given the above reasons, perhaps we can change the 2/3
> > > Majority
> > > > to
> > > > > >> lazy
> > > > > >> > > 2/3
> > > > > >> > > > Majority, just as the Hadoop bylaws[1]. It makes a higher
> > > > > threshold,
> > > > > >> > > > however, more practical.
> > > > > >> > > >
> > > > > >> > > > What do you think?
> > > > > >> > > >
> > > > > >> > > > [1] https://hadoop.apache.org/bylaws.html
> > > > > >> > > >
> > > > > >> > > > On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <
> > > > becket.qin@gmail.com
> > > > > >
> > > > > >> > > wrote:
> > > > > >> > > >
> > > > > >> > > > > Hi Jincheng,
> > > > > >> > > > >
> > > > > >> > > > > Thanks for the comments. I replied on the wiki page.
> Just
> > a
> > > > > brief
> > > > > >> > > > summary,
> > > > > >> > > > > the current bylaws do require some of the FLIPs to get
> PMC
> > > > > >> approval
> > > > > >> > if
> > > > > >> > > > > their impact is big enough. But it leaves majority of
> the
> > > > > >> technical
> > > > > >> > > > > decisions to the committers who are supposed to be
> > > responsible
> > > > > for
> > > > > >> > > making
> > > > > >> > > > > such decisions.
> > > > > >> > > > >
> > > > > >> > > > > Re: Robert,
> > > > > >> > > > >
> > > > > >> > > > > I agree we can simply remove the requirement of +1 from
> a
> > > > > >> non-author
> > > > > >> > > > > committer and revisit it in a bit. After all, it does
> not
> > > make
> > > > > >> sense
> > > > > >> > to
> > > > > >> > > > > have a bylaw that we cannot afford. I have just updated
> > the
> > > > > bylaws
> > > > > >> > > wiki.
> > > > > >> > > > >
> > > > > >> > > > > Thanks,
> > > > > >> > > > >
> > > > > >> > > > > Jiangjie (Becket) Qin
> > > > > >> > > > >
> > > > > >> > > > > On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <
> > > > > >> rmetzger@apache.org
> > > > > >> > >
> > > > > >> > > > > wrote:
> > > > > >> > > > >
> > > > > >> > > > > > Hi all,
> > > > > >> > > > > > I agree with Aljoscha that trying to reflect the
> current
> > > > > status
> > > > > >> in
> > > > > >> > > the
> > > > > >> > > > > > bylaws, and then implementing changes one by one is a
> > very
> > > > > >> involved
> > > > > >> > > > task.
> > > > > >> > > > > > Unless there's somebody who's really eager to drive
> > this,
> > > I
> > > > > >> would
> > > > > >> > > stick
> > > > > >> > > > > to
> > > > > >> > > > > > Becket's initiative to come up with Bylaws for Flink,
> > even
> > > > if
> > > > > >> this
> > > > > >> > > > means
> > > > > >> > > > > > some changes.
> > > > > >> > > > > >
> > > > > >> > > > > > The cross-review requirement is the last big open
> point
> > in
> > > > > this
> > > > > >> > > > > discussion.
> > > > > >> > > > > > It seems that a there is a slight tendency in the
> > > discussion
> > > > > >> that
> > > > > >> > > this
> > > > > >> > > > is
> > > > > >> > > > > > not feasible given the current pull request review
> > > > situation.
> > > > > >> > > > > > For the sake of bringing this discussion to a
> > conclusion,
> > > > I'm
> > > > > >> fine
> > > > > >> > > with
> > > > > >> > > > > > leaving this requirement out. As we are currently
> adding
> > > > more
> > > > > >> > > > committers
> > > > > >> > > > > to
> > > > > >> > > > > > the project, we might be able to revisit this
> discussion
> > > in
> > > > 3
> > > > > -
> > > > > >> 6
> > > > > >> > > > months.
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> > > > > >> > > sunjincheng121@gmail.com
> > > > > >> > > > >
> > > > > >> > > > > > wrote:
> > > > > >> > > > > >
> > > > > >> > > > > > > Hi Becket,
> > > > > >> > > > > > >
> > > > > >> > > > > > > Thanks for the proposal.
> > > > > >> > > > > > >
> > > > > >> > > > > > > Regarding the vote of FLIP, preferably at least
> > > includes a
> > > > > PMC
> > > > > >> > > vote.
> > > > > >> > > > > > > Because FLIP is usually a big change or affects the
> > > user's
> > > > > >> > > interface
> > > > > >> > > > > > > changes. What do you think? (I leave the comment in
> > the
> > > > > wiki.)
> > > > > >> > > > > > >
> > > > > >> > > > > > > Best,
> > > > > >> > > > > > > Jincheng
> > > > > >> > > > > > >
> > > > > >> > > > > > > Dawid Wysakowicz <dw...@apache.org>
> > 于2019年7月17日周三
> > > > > >> > 下午9:12写道：
> > > > > >> > > > > > >
> > > > > >> > > > > > > > Hi all,
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > Sorry for joining late. I just wanted to say that
> I
> > > > really
> > > > > >> like
> > > > > >> > > the
> > > > > >> > > > > > > > proposed bylaws!
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > One comment, I also have the same concerns as
> > > expressed
> > > > by
> > > > > >> few
> > > > > >> > > > people
> > > > > >> > > > > > > > before that the "committer +1" on code change
> might
> > be
> > > > > hard
> > > > > >> to
> > > > > >> > > > > achieve
> > > > > >> > > > > > > > currently. On the other hand I would say this
> would
> > be
> > > > > >> > beneficial
> > > > > >> > > > for
> > > > > >> > > > > > > > the quality/uniformity of our codebase and
> knowledge
> > > > > >> sharing.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > I was just wondering what should be the next step
> > for
> > > > > this?
> > > > > >> I
> > > > > >> > > think
> > > > > >> > > > > it
> > > > > >> > > > > > > > would make sense to already use those bylaws and
> put
> > > > them
> > > > > to
> > > > > >> > PMC
> > > > > >> > > > > vote.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > Best,
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > Dawid
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > > >> > > > > > > > > Hi Aljoscha and Becket
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > Right, 3 days for FLIP voting is fine I think.
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > >>> I’m missing this stated somewhere clearly. If
> we
> > > are
> > > > > >> > stating
> > > > > >> > > > > that a
> > > > > >> > > > > > > > single
> > > > > >> > > > > > > > >>> committers +1 is good enough for code review,
> > > with 0
> > > > > >> hours
> > > > > >> > > > delay
> > > > > >> > > > > > (de
> > > > > >> > > > > > > > facto
> > > > > >> > > > > > > > >>> the current state), we should also write down
> > that
> > > > > this
> > > > > >> is
> > > > > >> > > > > subject
> > > > > >> > > > > > to
> > > > > >> > > > > > > > the
> > > > > >> > > > > > > > >>> best judgement of the committer to respect the
> > > > > >> components
> > > > > >> > > > > expertise
> > > > > >> > > > > > > and
> > > > > >> > > > > > > > >>> ongoing development plans (also the de facto
> > > current
> > > > > >> > state).
> > > > > >> > > > > > > > >> Adding the statement would help clarify the
> > > > intention,
> > > > > >> but
> > > > > >> > it
> > > > > >> > > > may
> > > > > >> > > > > > be a
> > > > > >> > > > > > > > >> little difficult to enforce and follow..
> > > > > >> > > > > > > > > I would be fine with that, it’s a soft/vague
> rule
> > > > > anyway,
> > > > > >> > > > intended
> > > > > >> > > > > to
> > > > > >> > > > > > > be
> > > > > >> > > > > > > > used with your “best judgemenet". I would like to
> > just
> > > > > >> avoid a
> > > > > >> > > > > > situation
> > > > > >> > > > > > > > when someone violates current uncodified state and
> > > > refers
> > > > > to
> > > > > >> > the
> > > > > >> > > > > bylaws
> > > > > >> > > > > > > > which are saying merging with any committer +1 is
> > > always
> > > > > >> fine
> > > > > >> > > (like
> > > > > >> > > > > > mine
> > > > > >> > > > > > > +1
> > > > > >> > > > > > > > for flink-python or flink-ml).
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > Piotrek
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <
> > > > > >> > > aljoscha@apache.org
> > > > > >> > > > >
> > > > > >> > > > > > > wrote:
> > > > > >> > > > > > > > >>
> > > > > >> > > > > > > > >> @Piotr regarding the 3 days voting on the FLIP.
> > > This
> > > > is
> > > > > >> just
> > > > > >> > > > about
> > > > > >> > > > > > the
> > > > > >> > > > > > > > voting, before that there needs to be the
> discussion
> > > > > >> thread. If
> > > > > >> > > > three
> > > > > >> > > > > > > days
> > > > > >> > > > > > > > have passed on a vote and there is consensus
> (i.e. 3
> > > > > >> > > > committers/PMCs
> > > > > >> > > > > > have
> > > > > >> > > > > > > > voted +1) that seems a high enough bar for me. So
> > far,
> > > > we
> > > > > >> have
> > > > > >> > > > rarely
> > > > > >> > > > > > see
> > > > > >> > > > > > > > any FLIPs pass that formal bar.
> > > > > >> > > > > > > > >>
> > > > > >> > > > > > > > >> According to the recent META-FLIP thread, we
> want
> > > to
> > > > > use
> > > > > >> > "lazy
> > > > > >> > > > > > > > majority" for the FLIP voting process. I think
> that
> > > > should
> > > > > >> be
> > > > > >> > > > changed
> > > > > >> > > > > > > from
> > > > > >> > > > > > > > “consensus” in the proposed bylaws.
> > > > > >> > > > > > > > >>
> > > > > >> > > > > > > > >> Regarding the current state: do we have a
> current
> > > > state
> > > > > >> that
> > > > > >> > > we
> > > > > >> > > > > all
> > > > > >> > > > > > > > agree on? I have the feeling that if we try to
> come
> > up
> > > > > with
> > > > > >> > > > something
> > > > > >> > > > > > > that
> > > > > >> > > > > > > > reflects the common state, according to
> > > PMCs/commiters,
> > > > > that
> > > > > >> > > might
> > > > > >> > > > > > take a
> > > > > >> > > > > > > > very long time. In that case I think it’s better
> to
> > > > adopt
> > > > > >> > > something
> > > > > >> > > > > > that
> > > > > >> > > > > > > we
> > > > > >> > > > > > > > all like, rather than trying to capture how we do
> it
> > > > now.
> > > > > >> > > > > > > > >>
> > > > > >> > > > > > > > >> Aljoscha
> > > > > >> > > > > > > > >>
> > > > > >> > > > > > > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <
> > > > > >> > > piotr@ververica.com
> > > > > >> > > > >
> > > > > >> > > > > > > wrote:
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>> Hi,
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>> Thanks for the proposal. Generally speaking +1
> > > from
> > > > my
> > > > > >> side
> > > > > >> > > to
> > > > > >> > > > > the
> > > > > >> > > > > > > > general idea and most of the content. I also see
> > merit
> > > > to
> > > > > >> the
> > > > > >> > > > > Chesney's
> > > > > >> > > > > > > > proposal to start from the current state. I think
> > > either
> > > > > >> would
> > > > > >> > be
> > > > > >> > > > > fine
> > > > > >> > > > > > > for
> > > > > >> > > > > > > > me.
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>> Couple of comments:
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>> 1.
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>> I also think that requiring +1 from another
> > > > committer
> > > > > >> would
> > > > > >> > > > slow
> > > > > >> > > > > > down
> > > > > >> > > > > > > > and put even more strain on the current reviewing
> > > > > bottleneck
> > > > > >> > that
> > > > > >> > > > we
> > > > > >> > > > > > are
> > > > > >> > > > > > > > having. Even if the change clear and simple,
> context
> > > > > switch
> > > > > >> > cost
> > > > > >> > > is
> > > > > >> > > > > > quite
> > > > > >> > > > > > > > high, and that’s just one less PR that the second
> > > > “cross”
> > > > > >> > > committer
> > > > > >> > > > > > could
> > > > > >> > > > > > > > have reviewed somewhere else in that time.
> Besides,
> > > > > current
> > > > > >> > setup
> > > > > >> > > > > that
> > > > > >> > > > > > we
> > > > > >> > > > > > > > have (with no cross +1 from another committer
> > > required)
> > > > > >> works
> > > > > >> > > quite
> > > > > >> > > > > > well
> > > > > >> > > > > > > > and I do not feel that’s causing troubles. On the
> > > other
> > > > > hand
> > > > > >> > > > > reviewing
> > > > > >> > > > > > > > bottleneck is.
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>> 2.
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>>> I think a committer should know when to ask
> > > another
> > > > > >> > > committer
> > > > > >> > > > > for
> > > > > >> > > > > > > > feedback or not.
> > > > > >> > > > > > > > >>> I’m missing this stated somewhere clearly. If
> we
> > > are
> > > > > >> > stating
> > > > > >> > > > > that a
> > > > > >> > > > > > > > single committers +1 is good enough for code
> review,
> > > > with
> > > > > 0
> > > > > >> > hours
> > > > > >> > > > > delay
> > > > > >> > > > > > > (de
> > > > > >> > > > > > > > facto the current state), we should also write
> down
> > > that
> > > > > >> this
> > > > > >> > is
> > > > > >> > > > > > subject
> > > > > >> > > > > > > to
> > > > > >> > > > > > > > the best judgement of the committer to respect the
> > > > > >> components
> > > > > >> > > > > expertise
> > > > > >> > > > > > > and
> > > > > >> > > > > > > > ongoing development plans (also the de facto
> current
> > > > > state).
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>> 3.
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>> Minimum length of 3 days for FLIP I think
> > > currently
> > > > > >> might
> > > > > >> > be
> > > > > >> > > > > > > > problematic/too quick and can lead to problems if
> > > > > respected
> > > > > >> to
> > > > > >> > > the
> > > > > >> > > > > > > letter.
> > > > > >> > > > > > > > Again I think it depends highly on whether the
> > > > committers
> > > > > >> with
> > > > > >> > > > > highest
> > > > > >> > > > > > > > expertise in the affected components managed to
> > > respond
> > > > or
> > > > > >> not.
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>> Piotrek
> > > > > >> > > > > > > > >>>
> > > > > >> > > > > > > > >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <
> > > > > >> > > > chesnay@apache.org>
> > > > > >> > > > > > > > wrote:
> > > > > >> > > > > > > > >>>>
> > > > > >> > > > > > > > >>>> I'm wondering whether we shouldn't first
> write
> > > down
> > > > > >> Bylaws
> > > > > >> > > > that
> > > > > >> > > > > > > > reflect the current state, and then have separate
> > > > > >> discussions
> > > > > >> > for
> > > > > >> > > > > > > > individual amendments. My gut feeling is that this
> > > > > >> discussion
> > > > > >> > > will
> > > > > >> > > > > > > quickly
> > > > > >> > > > > > > > become a chaotic mess with plenty points being
> > > discussed
> > > > > at
> > > > > >> > once.
> > > > > >> > > > > > > > >>>>
> > > > > >> > > > > > > > >>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > > > >> > > > > > > > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin
> <
> > > > > >> > > > > > becket.qin@gmail.com>
> > > > > >> > > > > > > > wrote:
> > > > > >> > > > > > > > >>>>>
> > > > > >> > > > > > > > >>>>>> Thanks everyone for all the comments and
> > > > feedback.
> > > > > >> > Please
> > > > > >> > > > see
> > > > > >> > > > > > the
> > > > > >> > > > > > > > replies
> > > > > >> > > > > > > > >>>>>> below:
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> --------------------------------
> > > > > >> > > > > > > > >>>>>> Re: Konstantin
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>>> * In addition to a simple "Code Change" we
> > > could
> > > > > >> also
> > > > > >> > > add a
> > > > > >> > > > > row
> > > > > >> > > > > > > > for "Code
> > > > > >> > > > > > > > >>>>>>> Change requiring a FLIP" with a reference
> to
> > > the
> > > > > >> FLIP
> > > > > >> > > > process
> > > > > >> > > > > > > > page. A
> > > > > >> > > > > > > > >>>>>> FLIP
> > > > > >> > > > > > > > >>>>>>> will have/does have different rules for
> > > > approvals,
> > > > > >> etc.
> > > > > >> > > > > > > > >>>>>> Good point. Just added the entry.
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> -------------------------------
> > > > > >> > > > > > > > >>>>>> Re: Konstantin
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>>> * For "Code Change" the draft currently
> > > requires
> > > > > >> "one
> > > > > >> > +1
> > > > > >> > > > > from a
> > > > > >> > > > > > > > committer
> > > > > >> > > > > > > > >>>>>>> who has not authored the patch followed
> by a
> > > > Lazy
> > > > > >> > > approval
> > > > > >> > > > > (not
> > > > > >> > > > > > > > counting
> > > > > >> > > > > > > > >>>>>>> the vote of the contributor), moving to
> lazy
> > > > > >> majority
> > > > > >> > if
> > > > > >> > > a
> > > > > >> > > > -1
> > > > > >> > > > > > is
> > > > > >> > > > > > > > >>>>>> received".
> > > > > >> > > > > > > > >>>>>>> In my understanding this means, that a
> > > committer
> > > > > >> always
> > > > > >> > > > > needs a
> > > > > >> > > > > > > > review
> > > > > >> > > > > > > > >>>>>> and
> > > > > >> > > > > > > > >>>>>>> +1 from another committer. As far as I
> know
> > > this
> > > > > is
> > > > > >> > > > currently
> > > > > >> > > > > > not
> > > > > >> > > > > > > > always
> > > > > >> > > > > > > > >>>>>>> the case (often committer authors,
> > contributor
> > > > > >> reviews
> > > > > >> > &
> > > > > >> > > > > +1s).
> > > > > >> > > > > > > > >>>>>>>
> > > > > >> > > > > > > > >>>>>> I think it is worth thinking about how we
> can
> > > > make
> > > > > it
> > > > > >> > easy
> > > > > >> > > > to
> > > > > >> > > > > > > > follow the
> > > > > >> > > > > > > > >>>>>>> bylaws e.g. by having more Flink-specific
> > Jira
> > > > > >> > workflows
> > > > > >> > > > and
> > > > > >> > > > > > > ticket
> > > > > >> > > > > > > > >>>>>> types +
> > > > > >> > > > > > > > >>>>>>> corresponding permissions. While this is
> > > > certainly
> > > > > >> > "Step
> > > > > >> > > > 2",
> > > > > >> > > > > I
> > > > > >> > > > > > > > believe,
> > > > > >> > > > > > > > >>>>>> we
> > > > > >> > > > > > > > >>>>>>> really need to make it as easy &
> transparent
> > > as
> > > > > >> > possible,
> > > > > >> > > > > > > > otherwise they
> > > > > >> > > > > > > > >>>>>>> will be unintentionally broken.
> > > > > >> > > > > > > > >>>>>> & Re: Till
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>>> For the case of a committer being the
> author
> > > and
> > > > > >> > getting
> > > > > >> > > a
> > > > > >> > > > +1
> > > > > >> > > > > > > from
> > > > > >> > > > > > > > a
> > > > > >> > > > > > > > >>>>>>> non-committer: I think a committer should
> > know
> > > > > when
> > > > > >> to
> > > > > >> > > ask
> > > > > >> > > > > > > another
> > > > > >> > > > > > > > >>>>>>> committer for feedback or not. Hence, I
> > would
> > > > not
> > > > > >> > enforce
> > > > > >> > > > > that
> > > > > >> > > > > > we
> > > > > >> > > > > > > > >>>>>> strictly
> > > > > >> > > > > > > > >>>>>>> need a +1 from a committer if the author
> is
> > a
> > > > > >> committer
> > > > > >> > > but
> > > > > >> > > > > of
> > > > > >> > > > > > > > course
> > > > > >> > > > > > > > >>>>>>> encourage it if capacities exist.
> > > > > >> > > > > > > > >>>>>> I am with Robert and Aljoscha on this.
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> I completely understand the concern here.
> > TBH,
> > > in
> > > > > >> Kafka
> > > > > >> > > > > > > occasionally
> > > > > >> > > > > > > > >>>>>> trivial patches from committers are still
> > > merged
> > > > > >> without
> > > > > >> > > > > > following
> > > > > >> > > > > > > > the
> > > > > >> > > > > > > > >>>>>> cross-review requirement, but it is rare.
> > That
> > > > > said,
> > > > > >> I
> > > > > >> > > still
> > > > > >> > > > > > think
> > > > > >> > > > > > > > an
> > > > > >> > > > > > > > >>>>>> additional committer's review makes sense
> due
> > > to
> > > > > the
> > > > > >> > > > following
> > > > > >> > > > > > > > reasons:
> > > > > >> > > > > > > > >>>>>> 1. The bottom line here is that we need to
> > make
> > > > > sure
> > > > > >> > every
> > > > > >> > > > > patch
> > > > > >> > > > > > > is
> > > > > >> > > > > > > > >>>>>> reviewed with a high quality. This is a
> > little
> > > > > >> difficult
> > > > > >> > > to
> > > > > >> > > > > > > > guarantee if
> > > > > >> > > > > > > > >>>>>> the review comes from a contributor for
> many
> > > > > >> reasons. In
> > > > > >> > > > some
> > > > > >> > > > > > > > cases, a
> > > > > >> > > > > > > > >>>>>> contributor may not have enough knowledge
> > about
> > > > the
> > > > > >> > > project
> > > > > >> > > > to
> > > > > >> > > > > > > make
> > > > > >> > > > > > > > a good
> > > > > >> > > > > > > > >>>>>> judgement. Also sometimes the contributors
> > are
> > > > more
> > > > > >> > > eagerly
> > > > > >> > > > to
> > > > > >> > > > > > > get a
> > > > > >> > > > > > > > >>>>>> particular issue fixed, so they are willing
> > to
> > > > > lower
> > > > > >> the
> > > > > >> > > > > review
> > > > > >> > > > > > > bar.
> > > > > >> > > > > > > > >>>>>> 2. One byproduct of such cross review among
> > > > > >> committers,
> > > > > >> > > > which
> > > > > >> > > > > I
> > > > > >> > > > > > > > personally
> > > > > >> > > > > > > > >>>>>> feel useful, is that it helps gradually
> form
> > > > > >> consistent
> > > > > >> > > > design
> > > > > >> > > > > > > > principles
> > > > > >> > > > > > > > >>>>>> and code style. This is because the
> > committers
> > > > will
> > > > > >> know
> > > > > >> > > how
> > > > > >> > > > > the
> > > > > >> > > > > > > > other
> > > > > >> > > > > > > > >>>>>> committers are writing code and learn from
> > each
> > > > > >> other.
> > > > > >> > So
> > > > > >> > > > they
> > > > > >> > > > > > > tend
> > > > > >> > > > > > > > to
> > > > > >> > > > > > > > >>>>>> reach some tacit understanding on how
> things
> > > > should
> > > > > >> be
> > > > > >> > > done
> > > > > >> > > > in
> > > > > >> > > > > > > > general.
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> Another way to think about this is to
> > consider
> > > > the
> > > > > >> > > following
> > > > > >> > > > > two
> > > > > >> > > > > > > > scenarios:
> > > > > >> > > > > > > > >>>>>> 1. Reviewing a committer's patch takes a
> lot
> > of
> > > > > >> > > iterations.
> > > > > >> > > > > Then
> > > > > >> > > > > > > > the patch
> > > > > >> > > > > > > > >>>>>> needs to be reviewed even if it takes time
> > > > because
> > > > > >> there
> > > > > >> > > are
> > > > > >> > > > > > > things
> > > > > >> > > > > > > > >>>>>> actually needs to be clarified / changed.
> > > > > >> > > > > > > > >>>>>> 2. Reviewing a committer's patch is very
> > smooth
> > > > and
> > > > > >> > quick,
> > > > > >> > > > so
> > > > > >> > > > > > the
> > > > > >> > > > > > > > patch is
> > > > > >> > > > > > > > >>>>>> merged soon. Then reviewing such a patch
> does
> > > not
> > > > > >> take
> > > > > >> > > much
> > > > > >> > > > > > time.
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> Letting another committer review the patch
> > > from a
> > > > > >> > > committer
> > > > > >> > > > > > falls
> > > > > >> > > > > > > > either in
> > > > > >> > > > > > > > >>>>>> case 1 or case 2. The best option here is
> to
> > > > review
> > > > > >> the
> > > > > >> > > > patch
> > > > > >> > > > > > > > because
> > > > > >> > > > > > > > >>>>>> If it is case 1, the patch actually needs
> to
> > be
> > > > > >> > reviewed.
> > > > > >> > > > > > > > >>>>>> If it is case 2, the review should not take
> > > much
> > > > > time
> > > > > >> > > > anyways.
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> In the contrast, we will risk encounter
> case
> > 1
> > > if
> > > > > we
> > > > > >> > skip
> > > > > >> > > > the
> > > > > >> > > > > > > > cross-review.
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> ------------------------
> > > > > >> > > > > > > > >>>>>> Re: Robert
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> I replied to your comments in the wiki and
> > made
> > > > the
> > > > > >> > > > following
> > > > > >> > > > > > > > modifications
> > > > > >> > > > > > > > >>>>>> to resolve some of your comments:
> > > > > >> > > > > > > > >>>>>> 1. Added a release manager role section.
> > > > > >> > > > > > > > >>>>>> 2. changed the name of "lazy consensus" to
> > > > > >> "consensus"
> > > > > >> > to
> > > > > >> > > > > align
> > > > > >> > > > > > > with
> > > > > >> > > > > > > > >>>>>> general definition of Apache glossary and
> > other
> > > > > >> > projects.
> > > > > >> > > > > > > > >>>>>> 3. review board  -> pull request
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> -------------------------
> > > > > >> > > > > > > > >>>>>> Re: Chesnay
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> The emeritus stuff seems like unnecessary
> > > noise.
> > > > > >> > > > > > > > >>>>>> As Till mentioned, this is to make sure 2/3
> > > > > majority
> > > > > >> is
> > > > > >> > > > still
> > > > > >> > > > > > > > feasible in
> > > > > >> > > > > > > > >>>>>> practice.
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> There's a bunch of subtle changes in the
> > draft
> > > > > >> compared
> > > > > >> > to
> > > > > >> > > > > > > existing
> > > > > >> > > > > > > > >>>>>>> "conventions"; we should find a way to
> > > highlight
> > > > > >> these
> > > > > >> > > and
> > > > > >> > > > > > > discuss
> > > > > >> > > > > > > > them
> > > > > >> > > > > > > > >>>>>>> one by one.
> > > > > >> > > > > > > > >>>>>> That is a good suggestion. I am not
> familiar
> > > > enough
> > > > > >> with
> > > > > >> > > the
> > > > > >> > > > > > > > current Flink
> > > > > >> > > > > > > > >>>>>> convention. Will you help on this? I saw
> you
> > > > > >> commented
> > > > > >> > on
> > > > > >> > > > some
> > > > > >> > > > > > > part
> > > > > >> > > > > > > > in the
> > > > > >> > > > > > > > >>>>>> wiki. Are those complete?
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> --------------------------
> > > > > >> > > > > > > > >>>>>> Re: Aljoscha
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> How different is this from the Kafka
> bylaws?
> > > I’m
> > > > > >> asking
> > > > > >> > > > > because
> > > > > >> > > > > > I
> > > > > >> > > > > > > > quite
> > > > > >> > > > > > > > >>>>>>> like them and wouldn’t mind essentially
> > > adopting
> > > > > the
> > > > > >> > > Kafka
> > > > > >> > > > > > > bylaws.
> > > > > >> > > > > > > > I
> > > > > >> > > > > > > > >>>>>> mean,
> > > > > >> > > > > > > > >>>>>>> it’s open source, and we don’t have to try
> > to
> > > > > >> re-invent
> > > > > >> > > the
> > > > > >> > > > > > wheel
> > > > > >> > > > > > > > here.
> > > > > >> > > > > > > > >>>>>> Ha, you got me on this. The first version
> of
> > > the
> > > > > >> draft
> > > > > >> > was
> > > > > >> > > > > > almost
> > > > > >> > > > > > > > identical
> > > > > >> > > > > > > > >>>>>> to Kafka. But Robert has already caught a
> few
> > > > > >> > inconsistent
> > > > > >> > > > > > places.
> > > > > >> > > > > > > > So it
> > > > > >> > > > > > > > >>>>>> might still worth going through it to make
> > sure
> > > > we
> > > > > >> truly
> > > > > >> > > > agree
> > > > > >> > > > > > on
> > > > > >> > > > > > > > them.
> > > > > >> > > > > > > > >>>>>> Otherwise we may end up modifying them
> > shortly
> > > > > after
> > > > > >> > > > adoption.
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> Thanks again folks, for all the valuable
> > > > feedback.
> > > > > >> These
> > > > > >> > > are
> > > > > >> > > > > > great
> > > > > >> > > > > > > > >>>>>> discussion.
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> Jiangjie (Becket) Qin
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha
> > > Krettek
> > > > <
> > > > > >> > > > > > > > aljoscha@apache.org>
> > > > > >> > > > > > > > >>>>>> wrote:
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > > >>>>>>> Big +1
> > > > > >> > > > > > > > >>>>>>>
> > > > > >> > > > > > > > >>>>>>> How different is this from the Kafka
> bylaws?
> > > I’m
> > > > > >> asking
> > > > > >> > > > > > because I
> > > > > >> > > > > > > > quite
> > > > > >> > > > > > > > >>>>>>> like them and wouldn’t mind essentially
> > > adopting
> > > > > the
> > > > > >> > > Kafka
> > > > > >> > > > > > > bylaws.
> > > > > >> > > > > > > > I
> > > > > >> > > > > > > > >>>>>> mean,
> > > > > >> > > > > > > > >>>>>>> it’s open source, and we don’t have to try
> > to
> > > > > >> re-invent
> > > > > >> > > the
> > > > > >> > > > > > wheel
> > > > > >> > > > > > > > here.
> > > > > >> > > > > > > > >>>>>>>
> > > > > >> > > > > > > > >>>>>>> I think it’s worthwhile to discuss the
> > > > “committer
> > > > > >> +1”
> > > > > >> > > > > > > requirement.
> > > > > >> > > > > > > > We
> > > > > >> > > > > > > > >>>>>>> don’t usually have that now but I would
> > > actually
> > > > > be
> > > > > >> in
> > > > > >> > > > favour
> > > > > >> > > > > > of
> > > > > >> > > > > > > > >>>>>> requiring
> > > > > >> > > > > > > > >>>>>>> it, although it might make stuff more
> > > > complicated.
> > > > > >> > > > > > > > >>>>>>>
> > > > > >> > > > > > > > >>>>>>> Aljoscha
> > > > > >> > > > > > > > >>>>>>>
> > > > > >> > > > > > > > >>>>>>>> On 11. Jul 2019, at 15:31, Till Rohrmann
> <
> > > > > >> > > > > > trohrmann@apache.org>
> > > > > >> > > > > > > > wrote:
> > > > > >> > > > > > > > >>>>>>>>
> > > > > >> > > > > > > > >>>>>>>> Thanks a lot for creating this draft
> > Becket.
> > > > > >> > > > > > > > >>>>>>>>
> > > > > >> > > > > > > > >>>>>>>> I think without the notion of emeritus
> (or
> > > > active
> > > > > >> vs.
> > > > > >> > > > > > inactive),
> > > > > >> > > > > > > > it
> > > > > >> > > > > > > > >>>>>> won't
> > > > > >> > > > > > > > >>>>>>>> be possible to have a 2/3 majority vote
> > > because
> > > > > we
> > > > > >> > > already
> > > > > >> > > > > > have
> > > > > >> > > > > > > > too
> > > > > >> > > > > > > > >>>>>> many
> > > > > >> > > > > > > > >>>>>>>> inactive PMCs/committers.
> > > > > >> > > > > > > > >>>>>>>>
> > > > > >> > > > > > > > >>>>>>>> For the case of a committer being the
> > author
> > > > and
> > > > > >> > > getting a
> > > > > >> > > > > +1
> > > > > >> > > > > > > > from a
> > > > > >> > > > > > > > >>>>>>>> non-committer: I think a committer should
> > > know
> > > > > >> when to
> > > > > >> > > ask
> > > > > >> > > > > > > another
> > > > > >> > > > > > > > >>>>>>>> committer for feedback or not. Hence, I
> > would
> > > > not
> > > > > >> > > enforce
> > > > > >> > > > > that
> > > > > >> > > > > > > we
> > > > > >> > > > > > > > >>>>>>> strictly
> > > > > >> > > > > > > > >>>>>>>> need a +1 from a committer if the author
> > is a
> > > > > >> > committer
> > > > > >> > > > but
> > > > > >> > > > > of
> > > > > >> > > > > > > > course
> > > > > >> > > > > > > > >>>>>>>> encourage it if capacities exist.
> > > > > >> > > > > > > > >>>>>>>>
> > > > > >> > > > > > > > >>>>>>>> Cheers,
> > > > > >> > > > > > > > >>>>>>>> Till
> > > > > >> > > > > > > > >>>>>>>>
> > > > > >> > > > > > > > >>>>>>>> On Thu, Jul 11, 2019 at 3:08 PM Chesnay
> > > > Schepler
> > > > > <
> > > > > >> > > > > > > > chesnay@apache.org>
> > > > > >> > > > > > > > >>>>>>> wrote:
> > > > > >> > > > > > > > >>>>>>>>> The emeritus stuff seems like
> unnecessary
> > > > noise.
> > > > > >> > > > > > > > >>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>> There's a bunch of subtle changes in the
> > > draft
> > > > > >> > compared
> > > > > >> > > > to
> > > > > >> > > > > > > > existing
> > > > > >> > > > > > > > >>>>>>>>> "conventions"; we should find a way to
> > > > highlight
> > > > > >> > these
> > > > > >> > > > and
> > > > > >> > > > > > > > discuss
> > > > > >> > > > > > > > >>>>>> them
> > > > > >> > > > > > > > >>>>>>>>> one by one.
> > > > > >> > > > > > > > >>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>> On 11/07/2019 14:29, Robert Metzger
> wrote:
> > > > > >> > > > > > > > >>>>>>>>>> Thank you Becket for kicking off this
> > > > > discussion
> > > > > >> and
> > > > > >> > > > > > creating
> > > > > >> > > > > > > a
> > > > > >> > > > > > > > draft
> > > > > >> > > > > > > > >>>>>>> in
> > > > > >> > > > > > > > >>>>>>>>>> the Wiki.
> > > > > >> > > > > > > > >>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>> I left some comments in the wiki.
> > > > > >> > > > > > > > >>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>> In my understanding this means, that a
> > > > > committer
> > > > > >> > > always
> > > > > >> > > > > > needs
> > > > > >> > > > > > > a
> > > > > >> > > > > > > > >>>>>> review
> > > > > >> > > > > > > > >>>>>>>>> and
> > > > > >> > > > > > > > >>>>>>>>>>> +1 from another committer. As far as I
> > > know
> > > > > >> this is
> > > > > >> > > > > > currently
> > > > > >> > > > > > > > not
> > > > > >> > > > > > > > >>>>>>> always
> > > > > >> > > > > > > > >>>>>>>>>>> the case (often committer authors,
> > > > contributor
> > > > > >> > > reviews
> > > > > >> > > > &
> > > > > >> > > > > > > +1s).
> > > > > >> > > > > > > > >>>>>>>>>> I would agree to add such a bylaw, if
> we
> > > had
> > > > > >> cases
> > > > > >> > in
> > > > > >> > > > the
> > > > > >> > > > > > past
> > > > > >> > > > > > > > where
> > > > > >> > > > > > > > >>>>>>> code
> > > > > >> > > > > > > > >>>>>>>>>> was not sufficiently reviewed AND we
> > > believe
> > > > > >> that we
> > > > > >> > > > have
> > > > > >> > > > > > > enough
> > > > > >> > > > > > > > >>>>>>> capacity
> > > > > >> > > > > > > > >>>>>>>>>> to ensure a separate committer's
> > approval.
> > > > > >> > > > > > > > >>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>> On Thu, Jul 11, 2019 at 9:49 AM
> > Konstantin
> > > > > Knauf
> > > > > >> <
> > > > > >> > > > > > > > >>>>>>>>> konstantin@ververica.com>
> > > > > >> > > > > > > > >>>>>>>>>> wrote:
> > > > > >> > > > > > > > >>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> Hi all,
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> thanks a lot for driving this,
> Becket. I
> > > > have
> > > > > >> two
> > > > > >> > > > remarks
> > > > > >> > > > > > > > regarding
> > > > > >> > > > > > > > >>>>>>> the
> > > > > >> > > > > > > > >>>>>>>>>>> "Actions" section:
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> * In addition to a simple "Code
> Change"
> > we
> > > > > could
> > > > > >> > also
> > > > > >> > > > > add a
> > > > > >> > > > > > > > row for
> > > > > >> > > > > > > > >>>>>>>>> "Code
> > > > > >> > > > > > > > >>>>>>>>>>> Change requiring a FLIP" with a
> > reference
> > > to
> > > > > the
> > > > > >> > FLIP
> > > > > >> > > > > > process
> > > > > >> > > > > > > > page.
> > > > > >> > > > > > > > >>>>>> A
> > > > > >> > > > > > > > >>>>>>>>> FLIP
> > > > > >> > > > > > > > >>>>>>>>>>> will have/does have different rules
> for
> > > > > >> approvals,
> > > > > >> > > etc.
> > > > > >> > > > > > > > >>>>>>>>>>> * For "Code Change" the draft
> currently
> > > > > requires
> > > > > >> > "one
> > > > > >> > > > +1
> > > > > >> > > > > > > from a
> > > > > >> > > > > > > > >>>>>>>>> committer
> > > > > >> > > > > > > > >>>>>>>>>>> who has not authored the patch
> followed
> > > by a
> > > > > >> Lazy
> > > > > >> > > > > approval
> > > > > >> > > > > > > (not
> > > > > >> > > > > > > > >>>>>>> counting
> > > > > >> > > > > > > > >>>>>>>>>>> the vote of the contributor), moving
> to
> > > lazy
> > > > > >> > majority
> > > > > >> > > > if
> > > > > >> > > > > a
> > > > > >> > > > > > -1
> > > > > >> > > > > > > > is
> > > > > >> > > > > > > > >>>>>>>>> received".
> > > > > >> > > > > > > > >>>>>>>>>>> In my understanding this means, that a
> > > > > committer
> > > > > >> > > always
> > > > > >> > > > > > > needs a
> > > > > >> > > > > > > > >>>>>> review
> > > > > >> > > > > > > > >>>>>>>>> and
> > > > > >> > > > > > > > >>>>>>>>>>> +1 from another committer. As far as I
> > > know
> > > > > >> this is
> > > > > >> > > > > > currently
> > > > > >> > > > > > > > not
> > > > > >> > > > > > > > >>>>>>> always
> > > > > >> > > > > > > > >>>>>>>>>>> the case (often committer authors,
> > > > contributor
> > > > > >> > > reviews
> > > > > >> > > > &
> > > > > >> > > > > > > +1s).
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> I think it is worth thinking about how
> > we
> > > > can
> > > > > >> make
> > > > > >> > it
> > > > > >> > > > > easy
> > > > > >> > > > > > to
> > > > > >> > > > > > > > follow
> > > > > >> > > > > > > > >>>>>>> the
> > > > > >> > > > > > > > >>>>>>>>>>> bylaws e.g. by having more
> > Flink-specific
> > > > Jira
> > > > > >> > > > workflows
> > > > > >> > > > > > and
> > > > > >> > > > > > > > ticket
> > > > > >> > > > > > > > >>>>>>>>> types +
> > > > > >> > > > > > > > >>>>>>>>>>> corresponding permissions. While this
> is
> > > > > >> certainly
> > > > > >> > > > "Step
> > > > > >> > > > > > 2",
> > > > > >> > > > > > > I
> > > > > >> > > > > > > > >>>>>>> believe,
> > > > > >> > > > > > > > >>>>>>>>> we
> > > > > >> > > > > > > > >>>>>>>>>>> really need to make it as easy &
> > > transparent
> > > > > as
> > > > > >> > > > possible,
> > > > > >> > > > > > > > otherwise
> > > > > >> > > > > > > > >>>>>>> they
> > > > > >> > > > > > > > >>>>>>>>>>> will be unintentionally broken.
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> Cheers and thanks,
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> Konstantin
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> On Thu, Jul 11, 2019 at 9:10 AM Becket
> > > Qin <
> > > > > >> > > > > > > > becket.qin@gmail.com>
> > > > > >> > > > > > > > >>>>>>>>> wrote:
> > > > > >> > > > > > > > >>>>>>>>>>>> Hi all,
> > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>> As it was raised in the FLIP process
> > > > > discussion
> > > > > >> > > thread
> > > > > >> > > > > > [1],
> > > > > >> > > > > > > > >>>>>> currently
> > > > > >> > > > > > > > >>>>>>>>>>> Flink
> > > > > >> > > > > > > > >>>>>>>>>>>> does not have official bylaws to
> govern
> > > the
> > > > > >> > > operation
> > > > > >> > > > of
> > > > > >> > > > > > the
> > > > > >> > > > > > > > >>>>>> project.
> > > > > >> > > > > > > > >>>>>>>>>>> Such
> > > > > >> > > > > > > > >>>>>>>>>>>> bylaws are critical for the community
> > to
> > > > > >> > coordinate
> > > > > >> > > > and
> > > > > >> > > > > > > > contribute
> > > > > >> > > > > > > > >>>>>>>>>>>> together. It is also the basis of
> other
> > > > > >> processes
> > > > > >> > > such
> > > > > >> > > > > as
> > > > > >> > > > > > > > FLIP.
> > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>> I have drafted a Flink bylaws page
> and
> > > > would
> > > > > >> like
> > > > > >> > to
> > > > > >> > > > > > start a
> > > > > >> > > > > > > > >>>>>>> discussion
> > > > > >> > > > > > > > >>>>>>>>>>>> thread on this.
> > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > > > >> > > > > > > > >>>>>>>>>>>> The bylaws will affect everyone in
> the
> > > > > >> community.
> > > > > >> > > > It'll
> > > > > >> > > > > be
> > > > > >> > > > > > > > great to
> > > > > >> > > > > > > > >>>>>>>>> hear
> > > > > >> > > > > > > > >>>>>>>>>>>> your thoughts.
> > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>> Thanks,
> > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>> Jiangjie (Becket) Qin
> > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>> [1]
> > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>
> > > > > >> > > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
> > > > > >> > > > > > > > >>>>>>>>>>> --
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> Konstantin Knauf | Solutions Architect
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> +49 160 91394525
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> Planned Absences: 10.08.2019 -
> > 31.08.2019,
> > > > > >> 05.09. -
> > > > > >> > > > > > > 06.09.2010
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> --
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> Ververica GmbH | Invalidenstrasse 115,
> > > 10115
> > > > > >> > Berlin,
> > > > > >> > > > > > Germany
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> --
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > > >>>>>>>>>>> Ververica GmbH
> > > > > >> > > > > > > > >>>>>>>>>>> Registered at Amtsgericht
> > Charlottenburg:
> > > > HRB
> > > > > >> > 158244
> > > > > >> > > B
> > > > > >> > > > > > > > >>>>>>>>>>> Managing Directors: Dr. Kostas
> Tzoumas,
> > > Dr.
> > > > > >> Stephan
> > > > > >> > > > Ewen
> > > > > >> > > > > > > > >>>>>>>>>>>
> > > > > >> > > > > > > >
> > > > > >> > > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>