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