You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Asaf Mesika <as...@gmail.com> on 2023/06/20 19:14:09 UTC
New pip process reminder
Hi,
This is just a reminder that PMC/Committers can only merge the PIP PR when
the vote thread is concluded and in a positive manner, as described (" a lazy
majority of at least 3 binding +1s votes")
So please, before clicking that merge button, double-check those two
conditions
Thanks!
Asaf
Re: New pip process reminder
Posted by tison <wa...@gmail.com>.
Looking into the discussion and reviewing our membership list, from module
experts' distribution perspective, I agree that specific modules can have
fewer PMC members overseeing.
According to my experience in the Flink community[1] and the natural that
improvement proposals are mainly about development, I suggest we regard
committers (PMC members are committers) vote as binding vote for a PIP.
In this way, we can trade off the more eye target with frequent development.
Best,
tison.
[1]
https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws#FlinkBylaws-Actions
tison <wa...@gmail.com> 于2023年6月21日周三 18:41写道：
> > mostly part of one enterprise and only their PIP/PRs are moving forward
>
> No. PIPs are processed in a vendor natural bias. At least the difference
> between lazy consensus and at least 3 +1 binding votes won't change it.
>
> > help other community members to let them contribute to Pulsar so
>
> I'm doing so and you can do so. As you may know I help with nudging some
> of your PRs and send an email about promoting client contribution to the
> PMC list in the last day. It's a separate topic that community members can
> contribute to. Someone spends time to try to formalize the PIP process and
> make these proposals clear and workable. It won't block "help other
> community members". If you ask a person _not_ to do A, it doesn't mean they
> _will_ do B.
>
> > there are many examples where PRs are sitting unreviewed for a long
> time
>
> At the end of the last year, there are over 400 open PRs. And now it's
> about 250+. I'm actively handling them and with several discussions with
> other committers I know it's not easy to _ask_ people to spend time
> reviewing others' patches. But following a tit-for-tat strategy I'm now
> happy to cooperate with Jiwei, Yunzu, Lari, Michael, Zixuan, and so on.
> There should not be a blocker; if so, you can discuss it on the private@
> mailing list - that's a certain issue we should handle for a better
> community.
>
> > indirectly making it difficult for many Pulsar committers and
> contributors
>
> From my observation, Asaf is actively reviewing almost all PIPs following
> the rule he proposed so the bandwidth effectively grows instead of
> decreases. 3 binding +1 votes are not a far more strict rule than lazy
> consensus with any proposer. According to the proposal you made, it
> requires spending more time on community traffic to help contributions make
> progress and it should be in the same way as the current PIP process
> direction (more eyes). "Let's skip voting and let it pass" won't help in
> delivering high-quality design implementation which are PIPs aimed at.
>
> Best,
> tison.
>
>
> Asaf Mesika <as...@gmail.com> 于2023年6月21日周三 15:59写道：
>
>> On Wed, Jun 21, 2023 at 10:27 AM Zixuan Liu <no...@gmail.com> wrote:
>>
>> > I think we can reference https://www.apache.org/foundation/voting.html
>> >
>> > > Votes on code modifications follow a different model. In this
>> scenario,
>> > a negative vote constitutes a veto , which the voting group (generally
>> the
>> > PMC of a project) cannot override. Again, this model may be modified by
>> a
>> > lazy consensus declaration when the request for a vote is raised, but
>> the
>> > full-stop nature of a negative vote does not change. Under normal
>> (non-lazy
>> > consensus) conditions, the proposal requires three positive votes and no
>> > negative votes in order to pass; if it fails to garner the requisite
>> amount
>> > of support, it doesn't. Then the proposer either withdraws the proposal
>> or
>> > modifies the code and resubmits it, or the proposal simply languishes
>> as an
>> > open issue until someone gets around to removing it.
>> >
>> > It seems that there is no need for three binding votes for code
>> > modifications. If I am wrong, please point it out.
>> >
>> > I believe you may be wrong.
>>
>> Lazy Consensus is described here
>> <https://www.apache.org/foundation/voting.html#LazyConsensus> as:
>>
>> Lazy consensus is simply an announcement of 'silence gives assent.' When
>> > someone wants to determine the sense of the community this way, they
>> might
>> > do so with a mail message such as:
>> > "The patch below fixes bug #8271847; if no-one objects within three
>> > days, I'll assume lazy consensus and commit it."
>> > You cannot apply lazy consensus to code changes when the
>> > review-then-commit
>> > <https://www.apache.org/foundation/glossary.html#ReviewThenCommit>
>> policy
>> > is in effect.
>>
>>
>> My understanding is that for the PIP process, we are using a
>> review-then-commit policy, which actually means we can't use lazy
>> consensus.
>>
>> The definition of a Lazy Consensus defined here
>> <https://www.apache.org/foundation/glossary.html#LazyConsensus> is:
>>
>> A decision-making policy which assumes general consent if no responses are
>> > posted within a defined period. For example, "I'm going to commit this
>> by
>> > lazy consensus if no-one objects within the next three days." Also see
>> Consensus
>> > Approval
>> > <https://www.apache.org/foundation/glossary.html#ConsensusApproval> ,
>> Majority
>> > Approval
>> > <https://www.apache.org/foundation/glossary.html#MajorityApproval> ,
>> and
>> > the description of the voting process
>> > <https://www.apache.org/foundation/voting.html>.
>>
>>
>>
>> So if I summarize, a PIP needs to follow the "the proposal requires three
>> positive votes and no negative votes in order to pass;"
>>
>>
>> > Thanks,
>> > Zixuan
>> >
>> > Asaf Mesika <as...@gmail.com> 于2023年6月21日周三 14:59写道：
>> > >
>> > > I'm not a committer or PMC member, so I can't comment on this.
>> > >
>> > > I am curious to know the difference between other Apache projects and
>> > other
>> > > foundation projects, such as CNCF, if you know about it.
>> > > Do you think the Apache Foundation's view on individuals, not part of
>> a
>> > > commercial entity, does not live up to today's state of affairs?
>> > >
>> > > On Tue, Jun 20, 2023 at 10:40 PM Rajan Dhabalia <rdhabalia@apache.org
>> >
>> > > wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > > (" a lazy majority of at least 3 binding +1s votes")
>> > > >
>> > > > I don't think it's fair at this stage where majority Pulsar
>> committers
>> > are
>> > > > mostly part of one enterprise and only their PIP/PRs are moving
>> > forward and
>> > > > PR/PIP created by other community members get blocked or not
>> reviewed
>> > > > without any major reasons. I can list down many different examples
>> but
>> > I
>> > > > don't want to start that destructive discussion for now but I
>> strongly
>> > ask
>> > > > to help other community members to let them contribute to Pulsar so,
>> > we can
>> > > > grow Pulsar community and let Pulsar be at the stage where it has
>> > > > committers from various different institutions and we have good
>> number
>> > of
>> > > > reviewers to review PIP/PR on time.
>> > > > Right now, there are many examples where PRs are sitting unreviewed
>> > for a
>> > > > long time and we have to fix it first by encouraging and having more
>> > > > committers/reviewers across multiple organizations as a part of the
>> > Pulsar
>> > > > community. So, this is not the right time to restrict and this is
>> > > > indirectly making it difficult for many Pulsar committers and
>> > contributors
>> > > > who don't belong to specific enterprises.
>> > > >
>> > > > Thanks,
>> > > > Rajan
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Tue, Jun 20, 2023 at 12:14 PM Asaf Mesika <asaf.mesika@gmail.com
>> >
>> > > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > This is just a reminder that PMC/Committers can only merge the
>> PIP PR
>> > > > when
>> > > > > the vote thread is concluded and in a positive manner, as
>> described
>> > (" a
>> > > > > lazy
>> > > > > majority of at least 3 binding +1s votes")
>> > > > >
>> > > > > So please, before clicking that merge button, double-check those
>> two
>> > > > > conditions
>> > > > >
>> > > > > Thanks!
>> > > > >
>> > > > > Asaf
>> > > > >
>> > > >
>> >
>>
>
Re: New pip process reminder
Posted by tison <wa...@gmail.com>.
> mostly part of one enterprise and only their PIP/PRs are moving forward
No. PIPs are processed in a vendor natural bias. At least the difference
between lazy consensus and at least 3 +1 binding votes won't change it.
> help other community members to let them contribute to Pulsar so
I'm doing so and you can do so. As you may know I help with nudging some of
your PRs and send an email about promoting client contribution to the PMC
list in the last day. It's a separate topic that community members can
contribute to. Someone spends time to try to formalize the PIP process and
make these proposals clear and workable. It won't block "help other
community members". If you ask a person _not_ to do A, it doesn't mean they
_will_ do B.
> there are many examples where PRs are sitting unreviewed for a long time
At the end of the last year, there are over 400 open PRs. And now it's
about 250+. I'm actively handling them and with several discussions with
other committers I know it's not easy to _ask_ people to spend time
reviewing others' patches. But following a tit-for-tat strategy I'm now
happy to cooperate with Jiwei, Yunzu, Lari, Michael, Zixuan, and so on.
There should not be a blocker; if so, you can discuss it on the private@
mailing list - that's a certain issue we should handle for a better
community.
> indirectly making it difficult for many Pulsar committers and contributors
From my observation, Asaf is actively reviewing almost all PIPs following
the rule he proposed so the bandwidth effectively grows instead of
decreases. 3 binding +1 votes are not a far more strict rule than lazy
consensus with any proposer. According to the proposal you made, it
requires spending more time on community traffic to help contributions make
progress and it should be in the same way as the current PIP process
direction (more eyes). "Let's skip voting and let it pass" won't help in
delivering high-quality design implementation which are PIPs aimed at.
Best,
tison.
Asaf Mesika <as...@gmail.com> 于2023年6月21日周三 15:59写道：
> On Wed, Jun 21, 2023 at 10:27 AM Zixuan Liu <no...@gmail.com> wrote:
>
> > I think we can reference https://www.apache.org/foundation/voting.html
> >
> > > Votes on code modifications follow a different model. In this scenario,
> > a negative vote constitutes a veto , which the voting group (generally
> the
> > PMC of a project) cannot override. Again, this model may be modified by a
> > lazy consensus declaration when the request for a vote is raised, but the
> > full-stop nature of a negative vote does not change. Under normal
> (non-lazy
> > consensus) conditions, the proposal requires three positive votes and no
> > negative votes in order to pass; if it fails to garner the requisite
> amount
> > of support, it doesn't. Then the proposer either withdraws the proposal
> or
> > modifies the code and resubmits it, or the proposal simply languishes as
> an
> > open issue until someone gets around to removing it.
> >
> > It seems that there is no need for three binding votes for code
> > modifications. If I am wrong, please point it out.
> >
> > I believe you may be wrong.
>
> Lazy Consensus is described here
> <https://www.apache.org/foundation/voting.html#LazyConsensus> as:
>
> Lazy consensus is simply an announcement of 'silence gives assent.' When
> > someone wants to determine the sense of the community this way, they
> might
> > do so with a mail message such as:
> > "The patch below fixes bug #8271847; if no-one objects within three
> > days, I'll assume lazy consensus and commit it."
> > You cannot apply lazy consensus to code changes when the
> > review-then-commit
> > <https://www.apache.org/foundation/glossary.html#ReviewThenCommit>
> policy
> > is in effect.
>
>
> My understanding is that for the PIP process, we are using a
> review-then-commit policy, which actually means we can't use lazy
> consensus.
>
> The definition of a Lazy Consensus defined here
> <https://www.apache.org/foundation/glossary.html#LazyConsensus> is:
>
> A decision-making policy which assumes general consent if no responses are
> > posted within a defined period. For example, "I'm going to commit this by
> > lazy consensus if no-one objects within the next three days." Also see
> Consensus
> > Approval
> > <https://www.apache.org/foundation/glossary.html#ConsensusApproval> ,
> Majority
> > Approval
> > <https://www.apache.org/foundation/glossary.html#MajorityApproval> , and
> > the description of the voting process
> > <https://www.apache.org/foundation/voting.html>.
>
>
>
> So if I summarize, a PIP needs to follow the "the proposal requires three
> positive votes and no negative votes in order to pass;"
>
>
> > Thanks,
> > Zixuan
> >
> > Asaf Mesika <as...@gmail.com> 于2023年6月21日周三 14:59写道：
> > >
> > > I'm not a committer or PMC member, so I can't comment on this.
> > >
> > > I am curious to know the difference between other Apache projects and
> > other
> > > foundation projects, such as CNCF, if you know about it.
> > > Do you think the Apache Foundation's view on individuals, not part of a
> > > commercial entity, does not live up to today's state of affairs?
> > >
> > > On Tue, Jun 20, 2023 at 10:40 PM Rajan Dhabalia <rd...@apache.org>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > > (" a lazy majority of at least 3 binding +1s votes")
> > > >
> > > > I don't think it's fair at this stage where majority Pulsar
> committers
> > are
> > > > mostly part of one enterprise and only their PIP/PRs are moving
> > forward and
> > > > PR/PIP created by other community members get blocked or not reviewed
> > > > without any major reasons. I can list down many different examples
> but
> > I
> > > > don't want to start that destructive discussion for now but I
> strongly
> > ask
> > > > to help other community members to let them contribute to Pulsar so,
> > we can
> > > > grow Pulsar community and let Pulsar be at the stage where it has
> > > > committers from various different institutions and we have good
> number
> > of
> > > > reviewers to review PIP/PR on time.
> > > > Right now, there are many examples where PRs are sitting unreviewed
> > for a
> > > > long time and we have to fix it first by encouraging and having more
> > > > committers/reviewers across multiple organizations as a part of the
> > Pulsar
> > > > community. So, this is not the right time to restrict and this is
> > > > indirectly making it difficult for many Pulsar committers and
> > contributors
> > > > who don't belong to specific enterprises.
> > > >
> > > > Thanks,
> > > > Rajan
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Jun 20, 2023 at 12:14 PM Asaf Mesika <as...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > This is just a reminder that PMC/Committers can only merge the PIP
> PR
> > > > when
> > > > > the vote thread is concluded and in a positive manner, as described
> > (" a
> > > > > lazy
> > > > > majority of at least 3 binding +1s votes")
> > > > >
> > > > > So please, before clicking that merge button, double-check those
> two
> > > > > conditions
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Asaf
> > > > >
> > > >
> >
>
Re: New pip process reminder
Posted by Asaf Mesika <as...@gmail.com>.
On Wed, Jun 21, 2023 at 10:27 AM Zixuan Liu <no...@gmail.com> wrote:
> I think we can reference https://www.apache.org/foundation/voting.html
>
> > Votes on code modifications follow a different model. In this scenario,
> a negative vote constitutes a veto , which the voting group (generally the
> PMC of a project) cannot override. Again, this model may be modified by a
> lazy consensus declaration when the request for a vote is raised, but the
> full-stop nature of a negative vote does not change. Under normal (non-lazy
> consensus) conditions, the proposal requires three positive votes and no
> negative votes in order to pass; if it fails to garner the requisite amount
> of support, it doesn't. Then the proposer either withdraws the proposal or
> modifies the code and resubmits it, or the proposal simply languishes as an
> open issue until someone gets around to removing it.
>
> It seems that there is no need for three binding votes for code
> modifications. If I am wrong, please point it out.
>
> I believe you may be wrong.
Lazy Consensus is described here
<https://www.apache.org/foundation/voting.html#LazyConsensus> as:
Lazy consensus is simply an announcement of 'silence gives assent.' When
> someone wants to determine the sense of the community this way, they might
> do so with a mail message such as:
> "The patch below fixes bug #8271847; if no-one objects within three
> days, I'll assume lazy consensus and commit it."
> You cannot apply lazy consensus to code changes when the
> review-then-commit
> <https://www.apache.org/foundation/glossary.html#ReviewThenCommit> policy
> is in effect.
My understanding is that for the PIP process, we are using a
review-then-commit policy, which actually means we can't use lazy consensus.
The definition of a Lazy Consensus defined here
<https://www.apache.org/foundation/glossary.html#LazyConsensus> is:
A decision-making policy which assumes general consent if no responses are
> posted within a defined period. For example, "I'm going to commit this by
> lazy consensus if no-one objects within the next three days." Also see Consensus
> Approval
> <https://www.apache.org/foundation/glossary.html#ConsensusApproval> , Majority
> Approval
> <https://www.apache.org/foundation/glossary.html#MajorityApproval> , and
> the description of the voting process
> <https://www.apache.org/foundation/voting.html>.
So if I summarize, a PIP needs to follow the "the proposal requires three
positive votes and no negative votes in order to pass;"
> Thanks,
> Zixuan
>
> Asaf Mesika <as...@gmail.com> 于2023年6月21日周三 14:59写道：
> >
> > I'm not a committer or PMC member, so I can't comment on this.
> >
> > I am curious to know the difference between other Apache projects and
> other
> > foundation projects, such as CNCF, if you know about it.
> > Do you think the Apache Foundation's view on individuals, not part of a
> > commercial entity, does not live up to today's state of affairs?
> >
> > On Tue, Jun 20, 2023 at 10:40 PM Rajan Dhabalia <rd...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > > (" a lazy majority of at least 3 binding +1s votes")
> > >
> > > I don't think it's fair at this stage where majority Pulsar committers
> are
> > > mostly part of one enterprise and only their PIP/PRs are moving
> forward and
> > > PR/PIP created by other community members get blocked or not reviewed
> > > without any major reasons. I can list down many different examples but
> I
> > > don't want to start that destructive discussion for now but I strongly
> ask
> > > to help other community members to let them contribute to Pulsar so,
> we can
> > > grow Pulsar community and let Pulsar be at the stage where it has
> > > committers from various different institutions and we have good number
> of
> > > reviewers to review PIP/PR on time.
> > > Right now, there are many examples where PRs are sitting unreviewed
> for a
> > > long time and we have to fix it first by encouraging and having more
> > > committers/reviewers across multiple organizations as a part of the
> Pulsar
> > > community. So, this is not the right time to restrict and this is
> > > indirectly making it difficult for many Pulsar committers and
> contributors
> > > who don't belong to specific enterprises.
> > >
> > > Thanks,
> > > Rajan
> > >
> > >
> > >
> > >
> > > On Tue, Jun 20, 2023 at 12:14 PM Asaf Mesika <as...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > This is just a reminder that PMC/Committers can only merge the PIP PR
> > > when
> > > > the vote thread is concluded and in a positive manner, as described
> (" a
> > > > lazy
> > > > majority of at least 3 binding +1s votes")
> > > >
> > > > So please, before clicking that merge button, double-check those two
> > > > conditions
> > > >
> > > > Thanks!
> > > >
> > > > Asaf
> > > >
> > >
>
Re: New pip process reminder
Posted by Zixuan Liu <no...@gmail.com>.
I think we can reference https://www.apache.org/foundation/voting.html
> Votes on code modifications follow a different model. In this scenario, a negative vote constitutes a veto , which the voting group (generally the PMC of a project) cannot override. Again, this model may be modified by a lazy consensus declaration when the request for a vote is raised, but the full-stop nature of a negative vote does not change. Under normal (non-lazy consensus) conditions, the proposal requires three positive votes and no negative votes in order to pass; if it fails to garner the requisite amount of support, it doesn't. Then the proposer either withdraws the proposal or modifies the code and resubmits it, or the proposal simply languishes as an open issue until someone gets around to removing it.
It seems that there is no need for three binding votes for code
modifications. If I am wrong, please point it out.
Thanks,
Zixuan
Asaf Mesika <as...@gmail.com> 于2023年6月21日周三 14:59写道：
>
> I'm not a committer or PMC member, so I can't comment on this.
>
> I am curious to know the difference between other Apache projects and other
> foundation projects, such as CNCF, if you know about it.
> Do you think the Apache Foundation's view on individuals, not part of a
> commercial entity, does not live up to today's state of affairs?
>
> On Tue, Jun 20, 2023 at 10:40 PM Rajan Dhabalia <rd...@apache.org>
> wrote:
>
> > Hi,
> >
> > > (" a lazy majority of at least 3 binding +1s votes")
> >
> > I don't think it's fair at this stage where majority Pulsar committers are
> > mostly part of one enterprise and only their PIP/PRs are moving forward and
> > PR/PIP created by other community members get blocked or not reviewed
> > without any major reasons. I can list down many different examples but I
> > don't want to start that destructive discussion for now but I strongly ask
> > to help other community members to let them contribute to Pulsar so, we can
> > grow Pulsar community and let Pulsar be at the stage where it has
> > committers from various different institutions and we have good number of
> > reviewers to review PIP/PR on time.
> > Right now, there are many examples where PRs are sitting unreviewed for a
> > long time and we have to fix it first by encouraging and having more
> > committers/reviewers across multiple organizations as a part of the Pulsar
> > community. So, this is not the right time to restrict and this is
> > indirectly making it difficult for many Pulsar committers and contributors
> > who don't belong to specific enterprises.
> >
> > Thanks,
> > Rajan
> >
> >
> >
> >
> > On Tue, Jun 20, 2023 at 12:14 PM Asaf Mesika <as...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > This is just a reminder that PMC/Committers can only merge the PIP PR
> > when
> > > the vote thread is concluded and in a positive manner, as described (" a
> > > lazy
> > > majority of at least 3 binding +1s votes")
> > >
> > > So please, before clicking that merge button, double-check those two
> > > conditions
> > >
> > > Thanks!
> > >
> > > Asaf
> > >
> >
Re: New pip process reminder
Posted by Asaf Mesika <as...@gmail.com>.
I'm not a committer or PMC member, so I can't comment on this.
I am curious to know the difference between other Apache projects and other
foundation projects, such as CNCF, if you know about it.
Do you think the Apache Foundation's view on individuals, not part of a
commercial entity, does not live up to today's state of affairs?
On Tue, Jun 20, 2023 at 10:40 PM Rajan Dhabalia <rd...@apache.org>
wrote:
> Hi,
>
> > (" a lazy majority of at least 3 binding +1s votes")
>
> I don't think it's fair at this stage where majority Pulsar committers are
> mostly part of one enterprise and only their PIP/PRs are moving forward and
> PR/PIP created by other community members get blocked or not reviewed
> without any major reasons. I can list down many different examples but I
> don't want to start that destructive discussion for now but I strongly ask
> to help other community members to let them contribute to Pulsar so, we can
> grow Pulsar community and let Pulsar be at the stage where it has
> committers from various different institutions and we have good number of
> reviewers to review PIP/PR on time.
> Right now, there are many examples where PRs are sitting unreviewed for a
> long time and we have to fix it first by encouraging and having more
> committers/reviewers across multiple organizations as a part of the Pulsar
> community. So, this is not the right time to restrict and this is
> indirectly making it difficult for many Pulsar committers and contributors
> who don't belong to specific enterprises.
>
> Thanks,
> Rajan
>
>
>
>
> On Tue, Jun 20, 2023 at 12:14 PM Asaf Mesika <as...@gmail.com>
> wrote:
>
> > Hi,
> >
> > This is just a reminder that PMC/Committers can only merge the PIP PR
> when
> > the vote thread is concluded and in a positive manner, as described (" a
> > lazy
> > majority of at least 3 binding +1s votes")
> >
> > So please, before clicking that merge button, double-check those two
> > conditions
> >
> > Thanks!
> >
> > Asaf
> >
>
Re: New pip process reminder
Posted by Rajan Dhabalia <rd...@apache.org>.
Hi,
> (" a lazy majority of at least 3 binding +1s votes")
I don't think it's fair at this stage where majority Pulsar committers are
mostly part of one enterprise and only their PIP/PRs are moving forward and
PR/PIP created by other community members get blocked or not reviewed
without any major reasons. I can list down many different examples but I
don't want to start that destructive discussion for now but I strongly ask
to help other community members to let them contribute to Pulsar so, we can
grow Pulsar community and let Pulsar be at the stage where it has
committers from various different institutions and we have good number of
reviewers to review PIP/PR on time.
Right now, there are many examples where PRs are sitting unreviewed for a
long time and we have to fix it first by encouraging and having more
committers/reviewers across multiple organizations as a part of the Pulsar
community. So, this is not the right time to restrict and this is
indirectly making it difficult for many Pulsar committers and contributors
who don't belong to specific enterprises.
Thanks,
Rajan
On Tue, Jun 20, 2023 at 12:14 PM Asaf Mesika <as...@gmail.com> wrote:
> Hi,
>
> This is just a reminder that PMC/Committers can only merge the PIP PR when
> the vote thread is concluded and in a positive manner, as described (" a
> lazy
> majority of at least 3 binding +1s votes")
>
> So please, before clicking that merge button, double-check those two
> conditions
>
> Thanks!
>
> Asaf
>