[VOTE] Pulsar Release 3.2.1 Candidate 2

[guo jiwei]

This is the second release candidate for Apache Pulsar version 3.2.1.

It fixes the following issues:
https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Amerged+label%3Arelease%2F3.2.1+label%3Acherry-picked%2Fbranch-3.2+

*** Please download, test and verify on this release. This vote will stay
open for at least 72 hours ***

Note that we are verifying upon the source (tag), binaries are provided for
convenience.

Source and binary files:
https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.2.1-candidate-2/

SHA-512 checksums:

bc66d777977aaa06a6e30c291e4e400e8ec4a3f619a3fc046ade6c9d9a711610099be3578f5dd1eee4eeab8afdd67963cfef49521219107ca829465762689494

apache-pulsar-3.2.1-bin.tar.gz

dc09d5246075f56456f00875a3b9654b3a31d69a3e502a61db4481e493c2d20babb46b48e47ff95b66ad60d0e6e3455b13e1f01259366ab6b982b07b00aabda6

apache-pulsar-3.2.1-src.tar.gz

Maven staging repo:
https://repository.apache.org/content/repositories/orgapachepulsar-1271/

The tag to verify:
v3.2.1-candidate-2 (da98b8d8d0bc0c2bdd2d14d3e2e8058fb4c5dfd2)
https://github.com/apache/pulsar/commits/v3.2.1-candidate-2/

Pulsar's KEYS file containing PGP keys you use to sign the release:
https://dist.apache.org/repos/dist/dev/pulsar/KEYS

Docker images:

pulsar images:
https://hub.docker.com/layers/technoboy8/pulsar/3.2.1-da98b8d/images/sha256-e3ae82ff5504470878f8c871e8737d71be8a58507937be3c2d6b4d31e7480f42?context=repo

pulsar-all images:
https://hub.docker.com/layers/technoboy8/pulsar-all/3.2.1-da98b8d/images/sha256-be975933560b0bff3ae5f1d72b9be1b150c049eff7692a7e14308648c4103f0e?context=repo

Please download the source package, and follow the README to build
and run the Pulsar standalone service.


Regards
Jiwei Guo (Tboy)

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Yunze Xu]

My fault for missing the discussion mails for these PIPs because I
didn't check the archives of previous months.

Thanks,
Yunze

On Thu, Mar 7, 2024 at 3:05 PM Lari Hotari  wrote:
>
> On Thu, 7 Mar 2024 at 08:14, Girish Sharma  wrote:
> > There is for 310 -
> > https://lists.apache.org/thread/13ncst2nc311vxok1s75thl2gtnk7w1t
>
> Girish, thank you for sharing the link to the PIP-310 thread.
> We also met in community meetings to discuss PIP-310
> (https://lists.apache.org/thread/y1sqpyv37fo0k4bm1ox28wggvkb7pbtw).
>
> I believe PIP-310 is a successful example of excellent community 
> collaboration.
> With PIP-310, Girish provided insightful feedback and also presented a
> thorough analysis
> of the Pulsar Rate Limiters. As a first step, this led to PIP-322,
> Pulsar Rate Limiting Refactoring
> (https://github.com/apache/pulsar/blob/master/pip/pip-322.md). PIP-322
> has been implemented and delivered in Pulsar 3.2.0.
>
> There are also plans to continue the improvements with the next set of
> enhancements
> following PIP-322 (refer to:
> https://lists.apache.org/thread/rj14rmzd5z5sy7kfg22kt4l5dzjwk9vn)
> and to cover the original requirements behind PIP-310.
>
> I'm looking forward to continuing this collaboration to deliver
> further improvements to the
> existing multi-tenancy features. The areas of improvement are service
> level management
> and capacity management of a large Pulsar system. This is also a key concern 
> of
> messaging-as-a-service / streaming-as-a-service platform teams that
> build upon Apache Pulsar.
>
> -Lari

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Lari Hotari]

On Thu, 7 Mar 2024 at 08:14, Girish Sharma  wrote:
> There is for 310 -
> https://lists.apache.org/thread/13ncst2nc311vxok1s75thl2gtnk7w1t

Girish, thank you for sharing the link to the PIP-310 thread.
We also met in community meetings to discuss PIP-310
(https://lists.apache.org/thread/y1sqpyv37fo0k4bm1ox28wggvkb7pbtw).

I believe PIP-310 is a successful example of excellent community collaboration.
With PIP-310, Girish provided insightful feedback and also presented a
thorough analysis
of the Pulsar Rate Limiters. As a first step, this led to PIP-322,
Pulsar Rate Limiting Refactoring
(https://github.com/apache/pulsar/blob/master/pip/pip-322.md). PIP-322
has been implemented and delivered in Pulsar 3.2.0.

There are also plans to continue the improvements with the next set of
enhancements
following PIP-322 (refer to:
https://lists.apache.org/thread/rj14rmzd5z5sy7kfg22kt4l5dzjwk9vn)
and to cover the original requirements behind PIP-310.

I'm looking forward to continuing this collaboration to deliver
further improvements to the
existing multi-tenancy features. The areas of improvement are service
level management
and capacity management of a large Pulsar system. This is also a key concern of
messaging-as-a-service / streaming-as-a-service platform teams that
build upon Apache Pulsar.

-Lari

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Joe F]

>
> know I’m not trying to be disrespectful, but it’s not respectful to be
> biased and act like an expert during the reviews, while you’ve contributed
> just for documentation PRs. When I talk about experience, I’m talking about
> reviewers who don’t contribute to the project, they ask questions to get to
> know Pulsar’s internals during the PIP, and then they give judgment based
> on their limited understanding, which is rude.


This is a very negative and corrosive way of looking at things.  Anyone -
anyone - who takes the time and effort to review a change or PIP  is
helping you.  Here you are, complaining about your PIPs and PRs not getting
support,  and  at the same time belittling someone who does take the time
to help you in moving things forward.

Asking questions, understanding the  changes , seeking explanations ..   is
all part of the process. One hopes that a reviewer does poke some holes and
finds weaknesses.  So that the end result is better than the original,
because of the process, not just the person.  By no means is that process
'rude'.

I can even cite a few examples from recent times from different users
> (PIP-337, PIP-338, PIP-332, PIP-310, etc) to illustrate how some
> improvements are simply ignored


This is strange, as all of those PIPs have comments and questions.
Discussions and voting need to be championed by the proposer. People have
multiple claims on their time. There is no uber person dictating what get's
attention or who should do what.  You need to canvass  people and  push for
your changes all the way through.

  There are many examples
> (PIP-321) where it was developed by SN contributors, and while there is no
> consensus, they will still be a part of the system.


As for PIP-321 getting in without a  consensus, I was one who had concerns
with it (and still think poorly of it),   but I don't think it was decided
in violation to the rules.



On Wed, Mar 6, 2024 at 10:14 PM Girish Sharma 
wrote:

> On Thu, Mar 7, 2024 at 11:38 AM Yunze Xu  wrote:
>
> > Regarding PIP-332 and PIP 310, similar to PIP-337, there is no
> > discussion mail in the dev mail list. David left a comment [1] in
> >
>
> There is for 310 -
> https://lists.apache.org/thread/13ncst2nc311vxok1s75thl2gtnk7w1t
>
>
> Regards
> --
> Girish Sharma
>

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Apurva Telang]

Hello,

Please find the discussion thread for PIP-337 on the Dev mailing list:
https://lists.apache.org/thread/v4xh3fqy2t62xdk37b2ghvkrvvnqrx80

In the case of PIP-337, Lari was prompt in helping review the PIP and PR
and providing valuable feedback. I acknowledged it via slack direct message
to him. Personally, I have not gotten the chance to make changes due to
other priorities at work. Hence, the delay in PIP-337's progress is my own
fault as the author.

My personal opinion is that joining community meetings and pinging in the
"Dev" slack channel has been really helpful in receiving the attention from
the community irrespective of the company you belong to.

Best regards,
Apurva Telang

On Wed, Mar 6, 2024 at 10:13 PM Girish Sharma 
wrote:

> On Thu, Mar 7, 2024 at 11:38 AM Yunze Xu  wrote:
>
> > Regarding PIP-332 and PIP 310, similar to PIP-337, there is no
> > discussion mail in the dev mail list. David left a comment [1] in
> >
>
> There is for 310 -
> https://lists.apache.org/thread/13ncst2nc311vxok1s75thl2gtnk7w1t
>
>
> Regards
> --
> Girish Sharma
>


-- 
Best regards,
Apurva Telang.

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Girish Sharma]

On Thu, Mar 7, 2024 at 11:38 AM Yunze Xu  wrote:

> Regarding PIP-332 and PIP 310, similar to PIP-337, there is no
> discussion mail in the dev mail list. David left a comment [1] in
>

There is for 310 -
https://lists.apache.org/thread/13ncst2nc311vxok1s75thl2gtnk7w1t


Regards
-- 
Girish Sharma

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Yunze Xu]

Regarding PIP-332 and PIP 310, similar to PIP-337, there is no
discussion mail in the dev mail list. David left a comment [1] in
PIP-332 and there is no response. We can see discussions among Lari,
Asaf and the author in PIP-310. And eventually PIP-310 is closed
because the author has a different way to go ahead [2].

How can you say it's simply ignored without discussion? But I can
confirm from those examples that
https://github.com/apache/pulsar/blob/master/pip/README.md is ignored
many times.

[1] https://github.com/apache/pulsar/pull/21927#issuecomment-1948954577
[2] https://github.com/apache/pulsar/pull/21399#issuecomment-1857889100

Thanks,
Yunze

On Thu, Mar 7, 2024 at 1:57 PM Yunze Xu  wrote:
>
> > Our team has also tried to submit multiple
> enhancements and also PIP, but most of them are bogged down by
> reviewers who are very new to Pulsar, might not understand messaging
> correctly, or don’t find such enhancements useful for their usecases.
>
> If  your PRs or PIPs are not taken enough care of, please show
> concrete examples and ping committers in GitHub, Slack or the mail
> list. If you're suspicious of the committers that blocked your
> contributions, you can also make the discussion open in the mail list
> for more visibility.
>
> You mentioned PIP-337 [1] as an example. Unfortunately, I see Lari
> left many comments 3 weeks ago and there are no responses. The author
> also does not send any mail to the dev mail list.
>
> Regarding the fact that SN's proposals get more focus. It's true and
> reasonable because many committers work for SN. If one wants to
> promote his proposal, he could ping others in the company. For non-SN
> contributors, they can also reach Pulsar committers in GitHub, Slack
> as I mentioned before.
>
> Let's take PIP-338 [2] as another example. I can tell you that my team
> (from SN) has tracked this proposal internally from the mail [3]
> though the priority is not high so we don't have much time to review
> it for now. And I see there are many discussions from Lari and Girish,
> while the author (Meet0861) only left 1 comment in these discussions.
> Anyway, I don't think it should be "simply ignored without
> discussion".
>
> [1] https://github.com/apache/pulsar/pull/22016
> [2] https://github.com/apache/pulsar/pull/22039
> [3] https://lists.apache.org/thread/0ythswmt6d0q10f1knctc7py0gh5s4rd
>
> Thanks,
> Yunze
>
>
> On Thu, Mar 7, 2024 at 11:23 AM Dave Fisher  wrote:
> >
> >
> >
> > > On Mar 6, 2024, at 10:01 PM, Kalwit S  wrote:
> > >
> > > Also, Pulsar may have
> > > numbers of non-SM PMC’s and committers, but if you look at the numbers 
> > > over
> > > the last 2-3 years, you’ll see that 99% are from SM.
> >
> > If you are saying that this is the proportion of new committers and PMC 
> > members in the last 2-3 years then 99% implies not a single non-SN 
> > committer and/or PMC member added. This statement is categorically 
> > incorrect and completely wrong. A number of individuals involved who are 
> > committers and PMC members have changed jobs during the course of their 
> > involvement. A surprising number have continued their involvement during 
> > their work transitions.
> >
> > > I can even cite a few examples from recent times from different users
> > > (PIP-337, PIP-338, PIP-332, PIP-310, etc) to illustrate how some
> > > improvements are simply ignored without discussion, some are without any
> > > conclusion, and some are not given the opportunity to be implemented, 
> > > which
> > > could have allowed other companies to implement a customized 
> > > implementation
> > > for their need based on plugged-in approach.
> >
> > You were asked to provide an example. You need to pick one PIP,  take the 
> > time to research the conversations, gather references (links) to emails, 
> > and explain how you think it is a problem. Be technical about just one. I 
> > promised to help investigate, but I won’t help if you won’t do anything to 
> > help us all understand.
> >
> >
> > > There are many examples
> > > (PIP-321) where it was developed by SN contributors, and while there is no
> > > consensus, they will still be a part of the system. Other PR examples show
> > > the same pattern, ignoring the needs of other companies, and merging the 
> > > PR
> > > of SN contributors on an immediate basis.
> >
> > You have not shown any pattern, you have merely asserted it is there. Your 
> > “unit test” is flawed. Do the work to factually prove your point.
> >
> > Thanks,
> > Dave
> >
> >
> >

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Matteo Merli]

On Wed, Mar 6, 2024 at 7:02 PM Kalwit S  wrote:

> I know I’m not trying to be disrespectful, but it’s not respectful to be
> biased and act like an expert during the reviews, while you’ve contributed
> just for documentation PRs. When I talk about experience, I’m talking about
> reviewers who don’t contribute to the project, they ask questions to get to
> know Pulsar’s internals during the PIP, and then they give judgment based
> on their limited understanding, which is rude. Also, Pulsar may have
>

Since you keep questioning the contribution of various people, can I
respectfully ask what you have contributed to the project?

*Everyone* has a right to ask questions in a PR or in a PIP review. It is
actually
encouraged that non-committers/non-pmc member contribute to the project by
reviewing code
and providing feedback and different perspectives.

It is the main reason for why the proposals are discussed in such a
transparent manner

*No one* has the right to tell someone that they cannot ask questions
because "they are not qualified" in your view.

I can even cite a few examples from recent times from different users
> (PIP-337, PIP-338, PIP-332, PIP-310, etc) to illustrate how some
> improvements are simply ignored without discussion, some are without any
> conclusion, and some are not given the opportunity to be implemented, which
> could have allowed other companies to implement a customized implementation
> for their need based on plugged-in approach.


Well, I think you've chosen *very* bad examples. In none of these cases the
discussion
has been ignored. Great feedback was always provided and follow up actions
are on the person making the proposal.

* PIP-310: https://github.com/apache/pulsar/pull/21399
A very productive series of technical discussions was sparked by this
proposal, resulting in an alternative implementation that would satisfy the
problem described.

* PIP-332: https://github.com/apache/pulsar/pull/21927
The proposal also includes some code changes (while the instructions are
clear to first send and discuss a proposal). Not very clear. No tests. Some
questions were asked, no answers from the proposer.

* PIP-337: https://github.com/apache/pulsar/pull/22016
Very reasonable feedback was provided, it's up to the proposer to follow up
on that and eventually to close the discussion and start a vote thread.

* PIP-338: https://github.com/apache/pulsar/pull/22039
It looks to me this was provided very thoughtful feedback and that there
are still some action items.


> There are many examples
> (PIP-321) where it was developed by SN contributors, and while there is no
> consensus, they will still be a part of the system. Other PR examples show
> the same pattern, ignoring the needs of other companies, and merging the PR
> of SN contributors on an immediate basis.


Consensus does not equate unanimity and the acceptance is ultimately
determined by the PMC voting decision.

We can discuss for ages about a particular solution, though at some point,
a decision has to be taken to go one way or another.
No single person has veto power to stop a proposal, same as no single
person has a right to bypass the process.

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Yunze Xu]

> Our team has also tried to submit multiple
enhancements and also PIP, but most of them are bogged down by
reviewers who are very new to Pulsar, might not understand messaging
correctly, or don’t find such enhancements useful for their usecases.

If  your PRs or PIPs are not taken enough care of, please show
concrete examples and ping committers in GitHub, Slack or the mail
list. If you're suspicious of the committers that blocked your
contributions, you can also make the discussion open in the mail list
for more visibility.

You mentioned PIP-337 [1] as an example. Unfortunately, I see Lari
left many comments 3 weeks ago and there are no responses. The author
also does not send any mail to the dev mail list.

Regarding the fact that SN's proposals get more focus. It's true and
reasonable because many committers work for SN. If one wants to
promote his proposal, he could ping others in the company. For non-SN
contributors, they can also reach Pulsar committers in GitHub, Slack
as I mentioned before.

Let's take PIP-338 [2] as another example. I can tell you that my team
(from SN) has tracked this proposal internally from the mail [3]
though the priority is not high so we don't have much time to review
it for now. And I see there are many discussions from Lari and Girish,
while the author (Meet0861) only left 1 comment in these discussions.
Anyway, I don't think it should be "simply ignored without
discussion".

[1] https://github.com/apache/pulsar/pull/22016
[2] https://github.com/apache/pulsar/pull/22039
[3] https://lists.apache.org/thread/0ythswmt6d0q10f1knctc7py0gh5s4rd

Thanks,
Yunze


On Thu, Mar 7, 2024 at 11:23 AM Dave Fisher  wrote:
>
>
>
> > On Mar 6, 2024, at 10:01 PM, Kalwit S  wrote:
> >
> > Also, Pulsar may have
> > numbers of non-SM PMC’s and committers, but if you look at the numbers over
> > the last 2-3 years, you’ll see that 99% are from SM.
>
> If you are saying that this is the proportion of new committers and PMC 
> members in the last 2-3 years then 99% implies not a single non-SN committer 
> and/or PMC member added. This statement is categorically incorrect and 
> completely wrong. A number of individuals involved who are committers and PMC 
> members have changed jobs during the course of their involvement. A 
> surprising number have continued their involvement during their work 
> transitions.
>
> > I can even cite a few examples from recent times from different users
> > (PIP-337, PIP-338, PIP-332, PIP-310, etc) to illustrate how some
> > improvements are simply ignored without discussion, some are without any
> > conclusion, and some are not given the opportunity to be implemented, which
> > could have allowed other companies to implement a customized implementation
> > for their need based on plugged-in approach.
>
> You were asked to provide an example. You need to pick one PIP,  take the 
> time to research the conversations, gather references (links) to emails, and 
> explain how you think it is a problem. Be technical about just one. I 
> promised to help investigate, but I won’t help if you won’t do anything to 
> help us all understand.
>
>
> > There are many examples
> > (PIP-321) where it was developed by SN contributors, and while there is no
> > consensus, they will still be a part of the system. Other PR examples show
> > the same pattern, ignoring the needs of other companies, and merging the PR
> > of SN contributors on an immediate basis.
>
> You have not shown any pattern, you have merely asserted it is there. Your 
> “unit test” is flawed. Do the work to factually prove your point.
>
> Thanks,
> Dave
>
>
>

Re: [VOTE] Pulsar Client Go Release 0.12.1 Candidate 1

[Yunze Xu]

+1 (binding)

- Verified checksum and signatures
- Run OAuth2 e2e examples with 0.12.1-candidate-1
- Built from source and run perf to produce and consume

Thanks,
Yunze

On Thu, Feb 29, 2024 at 11:05 AM Zike Yang  wrote:
>
> Hi everyone,
> Please review and vote on the release candidate #1 for the version
> 0.12.1, as follows:
> [ ] +1, Approve the release
> [ ] -1, Do not approve the release (please provide specific comments)
>
> This is the first release candidate for Apache Pulsar Go client, version 
> 0.12.1.
>
> The release note/changelog for Go client 0.12.1:
> https://github.com/apache/pulsar-client-go/pull/1189/files
>
> Pulsar Client Go's KEYS file contains PGP keys we used to sign this release:
> https://downloads.apache.org/pulsar/KEYS
>
> Please download these packages and review this release candidate:
> - Review release notes: https://github.com/apache/pulsar-client-go/pull/1189
> - Download the source package (verify shasum, and asc) and follow the
> README.md to build and run the pulsar-client-go.
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
> Source file:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-client-go-0.12.1-candidate-1/
>
> The tag to be voted upon:
> v0.12.1-candidate-1
> https://github.com/apache/pulsar-client-go/tree/v0.12.1-candidate-1
>
> SHA-512 checksums:
> 691a301d099a602baa30bb7ec22dc33b8503d5ad5aa5fe43f51aab188099e4781844070de11584fd82d40227a28fe763ed8bd2cfa93b99d73ebfd34c6061e02d
>  apache-pulsar-client-go-0.12.1-src.tar.gz

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Dave Fisher]

> On Mar 6, 2024, at 10:01 PM, Kalwit S  wrote:
> 
> Also, Pulsar may have
> numbers of non-SM PMC’s and committers, but if you look at the numbers over
> the last 2-3 years, you’ll see that 99% are from SM.

If you are saying that this is the proportion of new committers and PMC members 
in the last 2-3 years then 99% implies not a single non-SN committer and/or PMC 
member added. This statement is categorically incorrect and completely wrong. A 
number of individuals involved who are committers and PMC members have changed 
jobs during the course of their involvement. A surprising number have continued 
their involvement during their work transitions.

> I can even cite a few examples from recent times from different users
> (PIP-337, PIP-338, PIP-332, PIP-310, etc) to illustrate how some
> improvements are simply ignored without discussion, some are without any
> conclusion, and some are not given the opportunity to be implemented, which
> could have allowed other companies to implement a customized implementation
> for their need based on plugged-in approach.

You were asked to provide an example. You need to pick one PIP,  take the time 
to research the conversations, gather references (links) to emails, and explain 
how you think it is a problem. Be technical about just one. I promised to help 
investigate, but I won’t help if you won’t do anything to help us all 
understand.


> There are many examples
> (PIP-321) where it was developed by SN contributors, and while there is no
> consensus, they will still be a part of the system. Other PR examples show
> the same pattern, ignoring the needs of other companies, and merging the PR
> of SN contributors on an immediate basis.

You have not shown any pattern, you have merely asserted it is there. Your 
“unit test” is flawed. Do the work to factually prove your point.

Thanks,
Dave

Re: [DISCUSS] PIP-343: Use picocli instead of jcommander

[Zixuan Liu]

Sync conversations from Slack.

Lari Hotari:
After this PR is completed, I will add the automatic completion feature.
sounds great. Just wondering if there's an overlap with pulsar-shell. Is
there a way to unite pulsar-admin and pulsar-shell in the future? Would
that make sense? /cc
@Nicoló Boschi @Enrico Olivelli

Zixuan Liu:
This feature has different implementations between pulsar-admin/client and
pulsar-shell.
pulsar-admin and pulsar-client uses the completion script, which will be
installed to you shell(bash, zsh), please
https://picocli.info/autocomplete.html
pulsar-shell depends on the jline3.

Enrico Olivelli:
Pulsar Shell is a wrapper for Pulsar admin and Pulsar client
It is not a distict codebase.

Nicoló Boschi:
In general pulsar shell should be used as a replacement for pulsar admin
because it brings many improvements such as config management, performance,
auto completion, client commands

Lari Hotari:
It just feels that it would be good to consider pulsar-shell in PIP-343 too
so that things work seamlessly also after making the improvements.
> In general pulsar shell should be used as a replacement for pulsar admin
because it brings many improvements such as config management, performance,
auto completion, client commands
yes. just one thought: a common use case is to run a set of commands with
pulsar-admin in a shell script. this is very inefficient with pulsar-admin
since for each call everything is started, connections created etc. and
then stopped. Does pulsar-shell support non-interactive usage where you'd
pass a list of commands and somehow also do scripting? There might be a
need for conditionals in error handling so it might be hard to handle?

Nicoló Boschi:
Yes it does
https://pulsar.apache.org/docs/next/administration-pulsar-shell/#run-commands-sequentially

Thanks,
Zixuan

Zixuan Liu  于2024年3月4日周一 01:05写道：

> Hello,
>
> A new proposal to improve the CLI user experience.
>
> PIP: https://github.com/apache/pulsar/pull/22181
>
> Thanks,
> Zixuan
>

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Kalwit S]

I know I’m not trying to be disrespectful, but it’s not respectful to be
biased and act like an expert during the reviews, while you’ve contributed
just for documentation PRs. When I talk about experience, I’m talking about
reviewers who don’t contribute to the project, they ask questions to get to
know Pulsar’s internals during the PIP, and then they give judgment based
on their limited understanding, which is rude. Also, Pulsar may have
numbers of non-SM PMC’s and committers, but if you look at the numbers over
the last 2-3 years, you’ll see that 99% are from SM.
I can even cite a few examples from recent times from different users
(PIP-337, PIP-338, PIP-332, PIP-310, etc) to illustrate how some
improvements are simply ignored without discussion, some are without any
conclusion, and some are not given the opportunity to be implemented, which
could have allowed other companies to implement a customized implementation
for their need based on plugged-in approach. There are many examples
(PIP-321) where it was developed by SN contributors, and while there is no
consensus, they will still be a part of the system. Other PR examples show
the same pattern, ignoring the needs of other companies, and merging the PR
of SN contributors on an immediate basis.
We also had a very difficult time in finding and running a stable version
of Pulsar that has no major issues and we are constantly looking for the
root cause in the main branch or newer versions for possible bug fixes and
that is very painful. I'm sure that many users are feeling the same way and
it's only a question of time until they start to speak up about their
experiences. Please don't take this as an accusation because we have also
spent a couple of years evaluating this project and this frustration comes
after dealing with a lot of different issues in the Pulsar project and
dealing with these non-technical problems is not acceptable when you are
picking Pulsar over other projects.

On Wed, Mar 6, 2024 at 2:40 PM Matteo Merli  wrote:

> On Wed, Mar 6, 2024 at 12:49 PM Kalwit S  wrote:
>
> > Thanks for your reply. But I wasn’t going to go after a specific person.
> I
> >
>
> Though that's precisely what your message was doing, in a very rude way.
>
> (1) How many reviewers (less than 1) have been involved in PIP review
> > outside of the streamnative provider and how many of them have experience
> > with Pulsar for more than 2 years (less than 1 or 2)?
> >
>
> You are clearly stating many accusations that are completely false and
> uninformed.
>
> The PIP process is structured in a way that all community members are
> encouraged to
> contribute reviews and opinions and PMC members have a binding vote to
> ratify the acceptance of a proposal.
>
> You can check the PMC composition here:
> https://pulsar.apache.org/community/#section-community
>
> There are a total of 82 between PMC members and committers in Pulsar.
>
> Out of 41 PMC members, only 9 are StreamNative employees.
> Of the additional 41 committers, 13 are StreamNative employees.
>
> I don't know what you wanted to prove exactly, though, since you are
> asking,
> I can tell you that every single one of the SN employees who is a
> committer,
> has > 2 years of experience with Pulsar and participation in the Pulsar
> community.
>
> If we are looking at SN employees  who are PMC members, that number of
> years of
> experience definitely goes way up.
>
> If you check the votes and the participation in discussion of PIPs it is
> *always*
> involving contributions of >3 different companies.
>
> will wait forever for 3 approvals to merge your enhancements. Streamnative
> > provider isn’t motivated to review all the enhancements, but they have
> set
> > a limit for you to get certain approvals and block every small
> > feature required by other companies.
> >
>
> That is some very bold accusation here. As others have been repeatedly
> asking: can you share any specific examples of it?
>

Re: [VOTE] Pulsar Release 3.2.1 Candidate 1

[guo jiwei]

Close this candidate, as we have a new fix, #22202, that needs to be
contained in the release.  I will raise a new candidate soon.


Regards
Jiwei Guo (Tboy)


On Wed, Mar 6, 2024 at 7:08 PM PengHui Li  wrote:

> +1 (binding)
>
> - Built from source
> - Checked the signatures
> - Run standalone
> - Checked producer and consumer
> - Verified the Cassandra connector
> - Verified the Stateful function
>
> Regards,
> Penghui
>
> On Wed, Mar 6, 2024 at 3:38 PM guo jiwei  wrote:
>
> > +1 (binding)
> >
> > - Built from source
> > - Checked the signatures
> > - Run standalone
> > - Checked producer and consumer
> > - Verified the Cassandra connector
> > - Verified the Stateful function
> >
> >
> > Regards
> > Jiwei Guo (Tboy)
> >
> >
> > On Wed, Mar 6, 2024 at 2:33 AM Ran Gao  wrote:
> >
> > > +1(non-binding)
> > >
> > > 1. verify the GPG signature for the below files
> > > - apache-pulsar-3.2.1-bin.tar.gz.asc
> > > - apache-pulsar-3.2.1-src.tar.gz.asc
> > > 2. build the source code
> > > 3. test following the release verifying doc.
> > >
> > > Regards,
> > > Ran Gao
> > >
> > > On 2024/03/05 07:05:05 guo jiwei wrote:
> > > > This is the first release candidate for Apache Pulsar version 3.2.1.
> > > >
> > > > It fixes the following issues:
> > > >
> > >
> >
> https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Amerged+label%3Arelease%2F3.2.1+label%3Acherry-picked%2Fbranch-3.2+
> > > >
> > > > *** Please download, test and verify on this release. This vote will
> > stay
> > > > open for at least 72 hours ***
> > > >
> > > > Note that we are verifying upon the source (tag), binaries are
> provided
> > > for
> > > > convenience.
> > > >
> > > > Source and binary files:
> > > >
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.2.1-candidate-1/
> > > >
> > > > SHA-512 checksums:
> > > >
> > > >
> > >
> >
> d500ba21305d56b0f7b4355e1270e50ae5f60e5632b6632d66fec6d1178bb9fdf3f24caa709b6b36ea8273e5a2c094868cf30e389154bc8bb6397e7de4f1bf1d
> > > >
> > > > apache-pulsar-3.2.1-bin.tar.gz
> > > >
> > > >
> > >
> >
> 7aee1623db6dc95058cd0e7a4f108f8a3f43163d798a8eeeaecf5f335225c04f5a0518ce2dfb2d4fa29b7b5e54d27ba24af82fbb3542eb3ffc9e3602cb577878
> > > >
> > > > apache-pulsar-3.2.1-src.tar.gz
> > > >
> > > > Maven staging repo:
> > > >
> > https://repository.apache.org/content/repositories/orgapachepulsar-1267/
> > > >
> > > > The tag to verify:
> > > > v3.2.1-candidate-1 (158d5eb670c9fd7b123c204533ac6cf8cb439ccd)
> > > > https://github.com/apache/pulsar/commits/v3.2.1-candidate-1/
> > > >
> > > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> > > >
> > > > Docker images:
> > > >
> > > > pulsar images:
> > > >
> > >
> >
> https://hub.docker.com/layers/technoboy8/pulsar/3.2.1-158d5eb/images/sha256-23f0cbd54b1fb504dcab16dfcce562ed735ab94db1c5f6fabbe9145f3a2d0fa8?context=repo
> > > > <
> > >
> >
> https://hub.docker.com/layers/mattison/pulsar/3.1.0-candidate-1/images/sha256-0efbaad7d893cc5041a46a2d4d56432bda855ae4068a38349777d1be6e98d27d?context=explore
> > > >
> > > > pulsar-all images:
> > > >
> > >
> >
> https://hub.docker.com/layers/technoboy8/pulsar-all/3.2.1-158d5eb/images/sha256-80ab1d748eff18655a9c247beba74aa107624b9d3e7cc3a2f22e1246f0d3de83?context=repo
> > > >
> > > > Please download the source package, and follow the README to build
> > > > and run the Pulsar standalone service.
> > > >
> > > >
> > > >
> > > > Regards
> > > > Jiwei Guo (Tboy)
> > > >
> > >
> >
>

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Joe F]

I have not seen any specific asks or examples that give rise to these
gripes, so it's all hypotheticals as of now. Please, as Enrico said, bring
up specific issues.

(1) How many reviewers (less than 1) have been involved in PIP review
outside of the streamnative provider and how many of them have experience
with Pulsar for more than 2 years (less than 1 or 2)?
This means that not all of the reviewers are aware of the entire system or
its history. If their opinions do not match the proposed solutions, then it
means that a contributor who is not a streamnative provider cannot
contribute to Pulsar and have the desired feature


(2) How long it takes for streamnative contributors to move forward with
improvements (less than 2 weeks) and how long it takes for other
contributors (more than a couple of months or even forever). ..


If I were to summarize your listed issues, they are about
(1)meritocracy and (2) community.

(1)People who have worked more on something know more about it.  There is
simply nothing that can be done to make a newcomer on the same footing as a
veteran when it comes to expertise, unless  the newcomer is willing to put
in the time to learn and gain the understanding.  There is a big difference
between every idea being considered  vs every idea being accepted.  If one
has an idea/contribution that can stand on its own merits, and has the
technical justifications to back it up, then it would get accepted.  I
would look for other reasons, before accusing people

(2) This is a community. Nobody owes anyone anything . Including providing
help or support.  I do not think "that guy/those guys are not helping me"
or "I am not getting timely help  with reviews"  is a ground for griping.
Everyone volunteers their time, and it is not infinite.   Would it be nice
if everyone helped everyone else out and had the time to do everything?
Yes.  Does it work that way?  Not perfectly.  Can it be better? Yes.  But
you are not going to get there blaming people. One needs to build
relationships and  collaboration with one's peers. That is not something
that can be ordered from your peers in the community. They are all
volunteers. There are ASF community rules, but rules never built a
community.   People and relationships do.

>There are many such examples
> that we can see, where contributors have requested pluggable features such
> as security, rate limiting, etc. These requests were legitimate, but only
> streamnative contributors will have the right to control Pulsar.
>

As someone who has repeatedly said no to  poorly thought out features in
Pulsar, what one user considers "legitimate" is debatable.  Due to a lack
of a clearly spelled out architectural vision, it is common to get feature
requests that don't align well with Pulsar,  or not well thought out,  or
just a niche use case for some specific user which does not fit with a
general streaming platform.  And for that matter, I have been ignored too -
that's community for you

Again, I don't know what your PIPs were, but I would not automatically
assume that everything submitted as a PIP should be accepted,  nor it is
incumbent upon the community to make every PIP evolve, mature and get
released.  People volunteer   time and talent - and for what interests them
in Pulsar.  It is entirely up to them to prioritize as they wish.

-joe

On Wed, Mar 6, 2024 at 12:49 PM Kalwit S  wrote:

> Thanks for your reply. But I wasn’t going to go after a specific person. I
> just wanted to point out this is an example of what we’ve been seeing for a
> while now. And I wanted to point out why we’re not going to go with Pulsar.
> Because if Streamnative is on the same trajectory as Confluent, then
> there’s not a lot of value for either of us to put in a lot of time and
> energy into migrating our systems.
> I’ll share what we’ve seen since we started using Pulsar. Other
> contributors can comment if they don’t agree.
>
> (1) How many reviewers (less than 1) have been involved in PIP review
> outside of the streamnative provider and how many of them have experience
> with Pulsar for more than 2 years (less than 1 or 2)?
> This means that not all of the reviewers are aware of the entire system or
> its history. If their opinions do not match the proposed solutions, then it
> means that a contributor who is not a streamnative provider cannot
> contribute to Pulsar and have the desired feature. On the other hand, if
> the same feature is provided by a streamnative provider, then the same
> enhancement could easily be added to Pulsar. There are many such examples
> that we can see, where contributors have requested pluggable features such
> as security, rate limiting, etc. These requests were legitimate, but only
> streamnative contributors will have the right to control Pulsar.
>
> (2) How long it takes for streamnative contributors to move forward with
> improvements (less than 2 weeks) and how long it takes for other
> contributors (more than a couple of months or 

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Matteo Merli]

On Wed, Mar 6, 2024 at 12:49 PM Kalwit S  wrote:

> Thanks for your reply. But I wasn’t going to go after a specific person. I
>

Though that's precisely what your message was doing, in a very rude way.

(1) How many reviewers (less than 1) have been involved in PIP review
> outside of the streamnative provider and how many of them have experience
> with Pulsar for more than 2 years (less than 1 or 2)?
>

You are clearly stating many accusations that are completely false and
uninformed.

The PIP process is structured in a way that all community members are
encouraged to
contribute reviews and opinions and PMC members have a binding vote to
ratify the acceptance of a proposal.

You can check the PMC composition here:
https://pulsar.apache.org/community/#section-community

There are a total of 82 between PMC members and committers in Pulsar.

Out of 41 PMC members, only 9 are StreamNative employees.
Of the additional 41 committers, 13 are StreamNative employees.

I don't know what you wanted to prove exactly, though, since you are
asking,
I can tell you that every single one of the SN employees who is a
committer,
has > 2 years of experience with Pulsar and participation in the Pulsar
community.

If we are looking at SN employees  who are PMC members, that number of
years of
experience definitely goes way up.

If you check the votes and the participation in discussion of PIPs it is
*always*
involving contributions of >3 different companies.

will wait forever for 3 approvals to merge your enhancements. Streamnative
> provider isn’t motivated to review all the enhancements, but they have set
> a limit for you to get certain approvals and block every small
> feature required by other companies.
>

That is some very bold accusation here. As others have been repeatedly
asking: can you share any specific examples of it?

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Enrico Olivelli]

Kalwit,


Il Mer 6 Mar 2024, 21:49 Kalwit S  ha scritto:

> Thanks for your reply. But I wasn’t going to go after a specific person. I
> just wanted to point out this is an example of what we’ve been seeing for a
> while now. And I wanted to point out why we’re not going to go with Pulsar.
> Because if Streamnative is on the same trajectory as Confluent, then
> there’s not a lot of value for either of us to put in a lot of time and
> energy into migrating our systems.
> I’ll share what we’ve seen since we started using Pulsar. Other
> contributors can comment if they don’t agree.
>
> (1) How many reviewers (less than 1) have been involved in PIP review
> outside of the streamnative provider and how many of them have experience
> with Pulsar for more than 2 years (less than 1 or 2)?
>

The PIP process requires PMC members to approve a decision, but anybody can
comment.
That said it is real that many people in the PMC work for StreamNative at
the moment, but there are also many other people from other companies (you
can checkout our LinkedIn profiles).

This means that not all of the reviewers are aware of the entire system or
> its history.


This is not required, as long as the feedback you provide to a contribution
is accompanied by technical points.


If their opinions do not match the proposed solutions, then it
> means that a contributor who is not a streamnative provider cannot
> contribute to Pulsar and have the desired feature.


 Please point out some examples.



On the other hand, if
> the same feature is provided by a streamnative provider, then the same
> enhancement could easily be added to Pulsar. There are many such examples
> that we can see, where contributors have requested pluggable features such
> as security, rate limiting, etc. These requests were legitimate, but only
> streamnative contributors will have the right to control Pulsar.
>

This sounds wrong, and if you have specific points please share then with
the PMC (priv...@pulsar.apache.org) or with the ASF Board of directors (
bo...@apache.org).

I really thank you for spending your time to share your opinion and your
pain, this is very much useful for our community.


> (2) How long it takes for streamnative contributors to move forward with
> improvements (less than 2 weeks) and how long it takes for other
> contributors (more than a couple of months or even forever). This means
> that no matter how much time and effort you put into contributing the right
> solution to Pulsar, it won’t get approved on time or will never be approved
> at all because only streamnative contributors review them and this review
> will wait forever for 3 approvals to merge your enhancements.


Streamnative
> provider isn’t motivated to review all the enhancements, but they have set
> a limit for you to get certain approvals and block every small
> feature required by other companies.
>

You are doing well in rising up  your voice.

Unfortunately in every OSS project people tend to review the patches that
are more interesting, as (in theory) we are all volunteers.



> Many companies have faced similar issues with Confluent. Pulsar was an
> alternative solution, but unfortunately, we have come to the conclusion
> that Pulsar isn’t better with a streamnative provider and reviewers. We
> also found major bugs in each Pulsar release, which forced us to
> continually upgrade Pulsar with little to no stability.


We can improve this. In my company we are enforcing an high bar for QA
before adopting a new major release and we tend to not pick up the latest
and greatest, but we try it out and then report problems to the community.

For bugfix releases the stability should be guaranteed. If this is not the
case then we have a problem and we should have a retrospective.


With unstable
> releases, a lazy review process, and a single provider-driven system,
> Pulsar will be extremely risky to use for any company and we would rather
> continue with our legacy Kafka clusters.
>

I am aware of many other (big) companies that are using Pulsar (and they
are not related to StreamNative) at scale and the overall feedback is that
Pulsar is stable and robust enough to run such kind of business.

Best regards

Enrico


> On Wed, Mar 6, 2024 at 6:19 AM Dave Fisher  wrote:
>
> >
> >
> > > On Mar 6, 2024, at 4:50 AM, Lari Hotari  wrote:
> > >
> > > Hi Kalwit,
> > >
> > > In Apache Pulsar, as in any other Apache project, everyone is equal
> > > regardless of their committer or PMC status. All project participants
> > > are free to express their opinions, and, where appropriate, have the
> > > community consider them when decisions are made. [1]
> > >
> > > I'm sorry to hear that you haven't felt this way. I believe we can find
> > > a resolution.
> > >
> > > We hold an open community meeting every two weeks on Zoom [2]. Anyone
> > > can join these meetings. The agenda is maintained in a Google Doc [3],
> > > where you can add items before the meeting. During the meeting, we

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Kalwit S]

Thanks for your reply. But I wasn’t going to go after a specific person. I
just wanted to point out this is an example of what we’ve been seeing for a
while now. And I wanted to point out why we’re not going to go with Pulsar.
Because if Streamnative is on the same trajectory as Confluent, then
there’s not a lot of value for either of us to put in a lot of time and
energy into migrating our systems.
I’ll share what we’ve seen since we started using Pulsar. Other
contributors can comment if they don’t agree.

(1) How many reviewers (less than 1) have been involved in PIP review
outside of the streamnative provider and how many of them have experience
with Pulsar for more than 2 years (less than 1 or 2)?
This means that not all of the reviewers are aware of the entire system or
its history. If their opinions do not match the proposed solutions, then it
means that a contributor who is not a streamnative provider cannot
contribute to Pulsar and have the desired feature. On the other hand, if
the same feature is provided by a streamnative provider, then the same
enhancement could easily be added to Pulsar. There are many such examples
that we can see, where contributors have requested pluggable features such
as security, rate limiting, etc. These requests were legitimate, but only
streamnative contributors will have the right to control Pulsar.

(2) How long it takes for streamnative contributors to move forward with
improvements (less than 2 weeks) and how long it takes for other
contributors (more than a couple of months or even forever). This means
that no matter how much time and effort you put into contributing the right
solution to Pulsar, it won’t get approved on time or will never be approved
at all because only streamnative contributors review them and this review
will wait forever for 3 approvals to merge your enhancements. Streamnative
provider isn’t motivated to review all the enhancements, but they have set
a limit for you to get certain approvals and block every small
feature required by other companies.

Many companies have faced similar issues with Confluent. Pulsar was an
alternative solution, but unfortunately, we have come to the conclusion
that Pulsar isn’t better with a streamnative provider and reviewers. We
also found major bugs in each Pulsar release, which forced us to
continually upgrade Pulsar with little to no stability. With unstable
releases, a lazy review process, and a single provider-driven system,
Pulsar will be extremely risky to use for any company and we would rather
continue with our legacy Kafka clusters.

On Wed, Mar 6, 2024 at 6:19 AM Dave Fisher  wrote:

>
>
> > On Mar 6, 2024, at 4:50 AM, Lari Hotari  wrote:
> >
> > Hi Kalwit,
> >
> > In Apache Pulsar, as in any other Apache project, everyone is equal
> > regardless of their committer or PMC status. All project participants
> > are free to express their opinions, and, where appropriate, have the
> > community consider them when decisions are made. [1]
> >
> > I'm sorry to hear that you haven't felt this way. I believe we can find
> > a resolution.
> >
> > We hold an open community meeting every two weeks on Zoom [2]. Anyone
> > can join these meetings. The agenda is maintained in a Google Doc [3],
> > where you can add items before the meeting. During the meeting, we
> > consider all agenda items. If we run out of time, we prioritize the
> > leftover items for the next meeting. The meeting's scope is the
> > development of Apache Pulsar and the community; it is not a place to
> > get free support in using Pulsar.
>
> That’s all very nice, but the Community meeting may not be in a time that
> is easy to engage with on a global scale.
>
> Discussions on an ASF project should be on the mailing lists for three
> important reasons:
>
> 1. Individuals can participate asynchronously on a global scale.
> 2. Conversations are archived and can be reviewed years after they
> occurred.
> 3. Technical issues discussed on slack and the meeting are difficult to
> share with the community because they are in a silo. (
>
> >
> > In remote work, there's a chance of feeling left out even when no one
> > intends to exclude you. In Apache Pulsar, we do have a problem with
> > responding to issues and pull requests in a reasonable time. It can feel
> > disheartening when you put significant effort into making a
> > contribution, and it goes unnoticed or ignored. I understand this
> > feeling. It also feels discouraging when someone gives you feedback
> > about something minor in your contribution, which doesn't really help
> > resolve the problem you're addressing. This happens when we're busy and
> > don't spend enough time caring about others' contributions. Apache
> > Pulsar's development is handled by the community, and there's no company
> > running this project. Therefore, when you don't get feedback, there's no
> > company to blame. We need to resolve the problems together in the
> > Apache Pulsar project. The decision process of 

[HOW TO FOLLOW GITHUB] Re: [PR] WIP: PIP-342: OTel client metrics support [pulsar]

[Dave Fisher]

For anyone who wishes to watch activity from with a Pulsar GitHub repository 
please consider subscribing to comm...@pulsar.apache.org 
 by sending an email to 
commits-subscr...@pulsar.apache.org 
 and replying to a CONFIRM email.

Regards,
Dave

> On Mar 6, 2024, at 12:50 PM, asafm (via GitHub)  wrote:
> 
> 
> asafm commented on code in PR #22179:
> URL: https://github.com/apache/pulsar/pull/22179#discussion_r1514920721
> 
> 
> ##
> pulsar-client-api/src/main/java/org/apache/pulsar/client/api/ClientBuilder.java:
> ##
> @@ -451,15 +452,18 @@ ClientBuilder authentication(String 
> authPluginClassName, Map aut
> ClientBuilder memoryLimit(long memoryLimit, SizeUnit unit);
> 
> /**
> - * Set the interval between each stat info (default: 60 seconds) 
> Stats will be activated with positive
> + * Set the interval between each stat info (default: disabled) 
> Stats will be activated with positive
> 
> Review Comment:
>   How do we alert the users that those metrics are still subject to changes 
> that may break them?
> 
> 
> 
> -- 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
> 
> To unsubscribe, e-mail: commits-unsubscr...@pulsar.apache.org
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 

Re: [VOTE] PIP-343: Use picocli instead of jcommander

[太上玄元道君]

+1 nonbinding

Zixuan Liu 于2024年3月6日 周三23:04写道：

> Hello,
>
> A new proposal to improve the CLI user experience.
>
> PIP: https://github.com/apache/pulsar/pull/22181
> Discussion thread:
> https://lists.apache.org/thread/ydg1q064cd11pxwz693frtk4by74q32f
>
> PR: https://github.com/apache/pulsar/pull/22209
>
> Thanks,
> Zixuan
>

Re: [DISCUSS] Community Meeting Notes Are Missing

[Dave Fisher]

Lari and Matteo,

True to what both of you to wrote. My point is how this may look to new 
community members.

Think outside in for a few minutes.

Even if there is no agenda I think a reminder before the meeting and then a 
summary like what Michael provided, or even a recording would really, really 
help.

Best,
Dave

> On Mar 6, 2024, at 10:44 AM, Matteo Merli  wrote:
> 
> Hi Dave,
> 
> The meeting is being conducted in the same exact way as it was when you
> we’re participating in it.
> 
> 
> --
> Matteo Merli
> 
> 
> 
> On Wed, Mar 6, 2024 at 6:43 AM Dave Fisher  wrote:
> 
>> Hi -
>> 
>> I see from the last meeting the following agenda:
>> 
>>> 2024/02/29
>>> Attendees:
>>> Lari Hotari
>>> Jonas
>>> Kevin Lu
>>> Frank Kelly
>>> Asaf Mesika
>>> Chris Bono
>>> David Jensen
>>> 
>>> Agenda
>>> PIP-341: Pluggable client metrics tracker interface
>>> 1. Should the OTel implementation be included in the PIP, or as a
>> separate follow-up PIP?
>>> 2. Do we want to maintain compatibility with the existing stats system
>> (ex. the public Producer /Consumer’s getStats() API), or keep the tracker
>> interface completely separate (and deprecate the old system)? The current
>> PIP attempts to maintain full compatibility, but I have detailed some of
>> the challenges/solutions for maintaining compatibility with the old system.
>>> Here is the draft https://github.com/apache/pulsar/pull/22145 <
>> https://github.com/apache/pulsar/pull/22145>
>>> Trivy container scan PR (https://github.com/apache/pulsar/pull/22063 <
>> https://github.com/apache/pulsar/pull/22063>)
>>> Pulsar-manager
>>> Release notes / Upgrade notes . Making it easier to upgrade to newer
>> Pulsar versions
>>> Cherry-pick vs cascade branch merge
>> 
>> I do not recall that any of this discussion made it to the mailing list.
>> It looks like decisions are being made in the meeting.
>> 
>> For example:
>> 1. Is there anything in the PIP-341 discussion that could not have been
>> brought to the mailing list in a [DISCUSS] PIP-341 thread?
>>   The only thing I can find on a mailing list is this thread.
>> https://lists.apache.org/thread/nott6fyo2vylv1d7nq3zwhsojm05fkgr <
>> https://lists.apache.org/thread/nott6fyo2vylv1d7nq3zwhsojm05fkgr>
>> 2, Trivy - I don’t see it brought back:
>> https://lists.apache.org/list?*@pulsar.apache.org:dfr=2024-1-1|dto=2024-3-6:Trivy
>> <
>> https://lists.apache.org/list?*@pulsar.apache.org:dfr=2024-1-1%7Cdto=2024-3-6:Trivy
>>> 
>> 3. Pulsar Manager - Nothing brought back to the mailing list:
>> https://lists.apache.org/list?dev@pulsar.apache.org:dfr=2024-1-1|dto=2024-3-6:pulsar%20manager
>> 
>> <
>> https://lists.apache.org/list?dev@pulsar.apache.org:dfr=2024-1-1%7Cdto=2024-3-6:pulsar%20manager
>>> 
>> 4. Cherry pick question came back as this wall of text:
>> https://lists.apache.org/thread/j6qvt45rndnvjypcmqxsfmddqt41bxjv <
>> https://lists.apache.org/thread/j6qvt45rndnvjypcmqxsfmddqt41bxjv>
>> 
>> I can see how this can look to an outsider like decisions are being made
>> in a non-open manner in a synchronous meeting.
>> 
>> If you wish to continue with this meeting then please publish the agenda
>> in advance to the Mailing List!
>> 
>> Best,
>> Dave
>> 
>> 

Re: [DISCUSS] Community Meeting Notes Are Missing

[Matteo Merli]

Hi Dave,

The meeting is being conducted in the same exact way as it was when you
we’re participating in it.


--
Matteo Merli



On Wed, Mar 6, 2024 at 6:43 AM Dave Fisher  wrote:

> Hi -
>
> I see from the last meeting the following agenda:
>
> > 2024/02/29
> > Attendees:
> > Lari Hotari
> > Jonas
> > Kevin Lu
> > Frank Kelly
> > Asaf Mesika
> > Chris Bono
> > David Jensen
> >
> > Agenda
> > PIP-341: Pluggable client metrics tracker interface
> > 1. Should the OTel implementation be included in the PIP, or as a
> separate follow-up PIP?
> > 2. Do we want to maintain compatibility with the existing stats system
> (ex. the public Producer /Consumer’s getStats() API), or keep the tracker
> interface completely separate (and deprecate the old system)? The current
> PIP attempts to maintain full compatibility, but I have detailed some of
> the challenges/solutions for maintaining compatibility with the old system.
> > Here is the draft https://github.com/apache/pulsar/pull/22145 <
> https://github.com/apache/pulsar/pull/22145>
> > Trivy container scan PR (https://github.com/apache/pulsar/pull/22063 <
> https://github.com/apache/pulsar/pull/22063>)
> > Pulsar-manager
> > Release notes / Upgrade notes . Making it easier to upgrade to newer
> Pulsar versions
> > Cherry-pick vs cascade branch merge
>
> I do not recall that any of this discussion made it to the mailing list.
> It looks like decisions are being made in the meeting.
>
> For example:
> 1. Is there anything in the PIP-341 discussion that could not have been
> brought to the mailing list in a [DISCUSS] PIP-341 thread?
>The only thing I can find on a mailing list is this thread.
> https://lists.apache.org/thread/nott6fyo2vylv1d7nq3zwhsojm05fkgr <
> https://lists.apache.org/thread/nott6fyo2vylv1d7nq3zwhsojm05fkgr>
> 2, Trivy - I don’t see it brought back:
> https://lists.apache.org/list?*@pulsar.apache.org:dfr=2024-1-1|dto=2024-3-6:Trivy
> <
> https://lists.apache.org/list?*@pulsar.apache.org:dfr=2024-1-1%7Cdto=2024-3-6:Trivy
> >
> 3. Pulsar Manager - Nothing brought back to the mailing list:
> https://lists.apache.org/list?dev@pulsar.apache.org:dfr=2024-1-1|dto=2024-3-6:pulsar%20manager
> 
> <
> https://lists.apache.org/list?dev@pulsar.apache.org:dfr=2024-1-1%7Cdto=2024-3-6:pulsar%20manager
> >
> 4. Cherry pick question came back as this wall of text:
> https://lists.apache.org/thread/j6qvt45rndnvjypcmqxsfmddqt41bxjv <
> https://lists.apache.org/thread/j6qvt45rndnvjypcmqxsfmddqt41bxjv>
>
> I can see how this can look to an outsider like decisions are being made
> in a non-open manner in a synchronous meeting.
>
> If you wish to continue with this meeting then please publish the agenda
> in advance to the Mailing List!
>
> Best,
> Dave
>
>

Re: [DISCUSS] Community Meeting Notes Are Missing

[Lari Hotari]

On Wed, 6 Mar 2024 at 16:43, Dave Fisher  wrote:
> I do not recall that any of this discussion made it to the mailing list. It 
> looks like decisions are being made in the meeting.

Hi Dave,

I apologize for not being able to keep up with everything and for not
including all the details in the meeting minutes. I will pay more
attention to include a brief summary of the discussions in the meeting
minutes moving forward. While I can't guarantee this will happen every
time, I can assure you that no project decisions are made during these
meetings, so there's no need for concern.

I have thoroughly studied the Apache way and strive to adhere to it in
all my activities within the Apache community. Regarding meetings,
I found a good guideline in the blog post "What makes Apache projects
different?"
(https://blogsarchive.apache.org/comdev/entry/what_makes_apache_projects_different).
"Out-of-band discussions (IRC etc.) are summarized on the dev list as
soon as they have an impact on the project, code, or community."
I have been following this principle, and I haven't observed anyone in the
Pulsar project intentionally acting contrary to these principles.

There's always room for interpretation regarding what impacts the project,
code or community and needs to be summarized on the dev list.
Setting rigid rules isn't productive. Apache isn't about hard rules.
Trust and common sense are also important. We should trust each other's
good intentions and rely on everyone doing their best. I hope we can enjoy
working together in the Apache community and appreciate the joy it brings.

> If you wish to continue with this meeting then please publish the agenda in 
> advance to the Mailing List!

I understand that everyone is very busy. Typically, the agenda is empty
when the meeting begins. We could certainly improve this. However, it's
not practical to say that we can't have the meeting if the agenda items
weren't added beforehand.

I'm open to suggestions for improving the Pulsar community meetings. I
hope everyone feels that they are open and welcoming, and that no one is
excluded. I don't believe anyone wants to complicate things
unnecessarily.

Instead of focusing on meeting logistics, I hope we can direct our
energy and focus towards improving Apache Pulsar and our working
methods. For instance, the challenge of having many open PRs is a clear
sign of problems in providing feedback to our contributors who have
invested time in making PRs. As we have discussed in the other thread,
people can feel excluded and left out when their contributions are
ignored. Let's try to address that problem as soon as possible.

-Lari


-Lari

On Wed, 6 Mar 2024 at 16:43, Dave Fisher  wrote:
>
> Hi -
>
> I see from the last meeting the following agenda:
>
> > 2024/02/29
> > Attendees:
> > Lari Hotari
> > Jonas
> > Kevin Lu
> > Frank Kelly
> > Asaf Mesika
> > Chris Bono
> > David Jensen
> >
> > Agenda
> > PIP-341: Pluggable client metrics tracker interface
> > 1. Should the OTel implementation be included in the PIP, or as a separate 
> > follow-up PIP?
> > 2. Do we want to maintain compatibility with the existing stats system (ex. 
> > the public Producer /Consumer’s getStats() API), or keep the tracker 
> > interface completely separate (and deprecate the old system)? The current 
> > PIP attempts to maintain full compatibility, but I have detailed some of 
> > the challenges/solutions for maintaining compatibility with the old system.
> > Here is the draft https://github.com/apache/pulsar/pull/22145 
> > 
> > Trivy container scan PR (https://github.com/apache/pulsar/pull/22063 
> > )
> > Pulsar-manager
> > Release notes / Upgrade notes . Making it easier to upgrade to newer Pulsar 
> > versions
> > Cherry-pick vs cascade branch merge
>
> I do not recall that any of this discussion made it to the mailing list. It 
> looks like decisions are being made in the meeting.
>
> For example:
> 1. Is there anything in the PIP-341 discussion that could not have been 
> brought to the mailing list in a [DISCUSS] PIP-341 thread?
>The only thing I can find on a mailing list is this thread. 
> https://lists.apache.org/thread/nott6fyo2vylv1d7nq3zwhsojm05fkgr 
> 
> 2, Trivy - I don’t see it brought back: 
> https://lists.apache.org/list?*@pulsar.apache.org:dfr=2024-1-1|dto=2024-3-6:Trivy
>  
> 
> 3. Pulsar Manager - Nothing brought back to the mailing list: 
> https://lists.apache.org/list?dev@pulsar.apache.org:dfr=2024-1-1|dto=2024-3-6:pulsar%20manager
>  
> 
> 4. Cherry pick question came back as this wall of text: 
> https://lists.apache.org/thread/j6qvt45rndnvjypcmqxsfmddqt41bxjv 
> 

Re: [VOTE] PIP-343: Use picocli instead of jcommander

[Enrico Olivelli]

+1 (binding)

Enrico

Il giorno mer 6 mar 2024 alle ore 16:04 Zixuan Liu 
ha scritto:
>
> Hello,
>
> A new proposal to improve the CLI user experience.
>
> PIP: https://github.com/apache/pulsar/pull/22181
> Discussion thread:
> https://lists.apache.org/thread/ydg1q064cd11pxwz693frtk4by74q32f
>
> PR: https://github.com/apache/pulsar/pull/22209
>
> Thanks,
> Zixuan

[VOTE] PIP-343: Use picocli instead of jcommander

[Zixuan Liu]

Hello,

A new proposal to improve the CLI user experience.

PIP: https://github.com/apache/pulsar/pull/22181
Discussion thread:
https://lists.apache.org/thread/ydg1q064cd11pxwz693frtk4by74q32f

PR: https://github.com/apache/pulsar/pull/22209

Thanks,
Zixuan

[DISCUSS] Community Meeting Notes Are Missing

[Dave Fisher]

Hi -

I see from the last meeting the following agenda:

> 2024/02/29
> Attendees:
> Lari Hotari
> Jonas
> Kevin Lu
> Frank Kelly
> Asaf Mesika
> Chris Bono
> David Jensen
> 
> Agenda
> PIP-341: Pluggable client metrics tracker interface
> 1. Should the OTel implementation be included in the PIP, or as a separate 
> follow-up PIP?
> 2. Do we want to maintain compatibility with the existing stats system (ex. 
> the public Producer /Consumer’s getStats() API), or keep the tracker 
> interface completely separate (and deprecate the old system)? The current PIP 
> attempts to maintain full compatibility, but I have detailed some of the 
> challenges/solutions for maintaining compatibility with the old system.
> Here is the draft https://github.com/apache/pulsar/pull/22145 
>  
> Trivy container scan PR (https://github.com/apache/pulsar/pull/22063 
> )
> Pulsar-manager
> Release notes / Upgrade notes . Making it easier to upgrade to newer Pulsar 
> versions
> Cherry-pick vs cascade branch merge

I do not recall that any of this discussion made it to the mailing list. It 
looks like decisions are being made in the meeting.

For example:
1. Is there anything in the PIP-341 discussion that could not have been brought 
to the mailing list in a [DISCUSS] PIP-341 thread?
   The only thing I can find on a mailing list is this thread. 
https://lists.apache.org/thread/nott6fyo2vylv1d7nq3zwhsojm05fkgr 

2, Trivy - I don’t see it brought back: 
https://lists.apache.org/list?*@pulsar.apache.org:dfr=2024-1-1|dto=2024-3-6:Trivy
 

3. Pulsar Manager - Nothing brought back to the mailing list: 
https://lists.apache.org/list?dev@pulsar.apache.org:dfr=2024-1-1|dto=2024-3-6:pulsar%20manager
 

4. Cherry pick question came back as this wall of text: 
https://lists.apache.org/thread/j6qvt45rndnvjypcmqxsfmddqt41bxjv 


I can see how this can look to an outsider like decisions are being made in a 
non-open manner in a synchronous meeting.

If you wish to continue with this meeting then please publish the agenda in 
advance to the Mailing List!

Best,
Dave

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Dave Fisher]

> On Mar 6, 2024, at 4:50 AM, Lari Hotari  wrote:
> 
> Hi Kalwit,
> 
> In Apache Pulsar, as in any other Apache project, everyone is equal
> regardless of their committer or PMC status. All project participants
> are free to express their opinions, and, where appropriate, have the
> community consider them when decisions are made. [1]
> 
> I'm sorry to hear that you haven't felt this way. I believe we can find
> a resolution.
> 
> We hold an open community meeting every two weeks on Zoom [2]. Anyone
> can join these meetings. The agenda is maintained in a Google Doc [3],
> where you can add items before the meeting. During the meeting, we
> consider all agenda items. If we run out of time, we prioritize the
> leftover items for the next meeting. The meeting's scope is the
> development of Apache Pulsar and the community; it is not a place to
> get free support in using Pulsar.

That’s all very nice, but the Community meeting may not be in a time that is 
easy to engage with on a global scale.

Discussions on an ASF project should be on the mailing lists for three 
important reasons:

1. Individuals can participate asynchronously on a global scale.
2. Conversations are archived and can be reviewed years after they occurred.
3. Technical issues discussed on slack and the meeting are difficult to share 
with the community because they are in a silo. (

> 
> In remote work, there's a chance of feeling left out even when no one
> intends to exclude you. In Apache Pulsar, we do have a problem with
> responding to issues and pull requests in a reasonable time. It can feel
> disheartening when you put significant effort into making a
> contribution, and it goes unnoticed or ignored. I understand this
> feeling. It also feels discouraging when someone gives you feedback
> about something minor in your contribution, which doesn't really help
> resolve the problem you're addressing. This happens when we're busy and
> don't spend enough time caring about others' contributions. Apache
> Pulsar's development is handled by the community, and there's no company
> running this project. Therefore, when you don't get feedback, there's no
> company to blame. We need to resolve the problems together in the
> Apache Pulsar project. The decision process of Apache [1] does not
> emphasize the committer or PMC status. I hope everyone could feel
> empowered to express their opinions and have the community consider
> them in order to make decisions to improve. It's also good to remember
> that it's all volunteers and if nobody volunteers to do something that has
> been suggested, it won't happen.

This is correct.

> 
> We need to find ways to improve the Apache Pulsar project so that
> contributors can receive feedback in a reasonable time. Currently,
> It is possible for the contributor to join the community meeting to
> request feedback or promote their contribution on Pulsar Slack's #dev channel
> until someone responds. However, this solution where "the loudest voice gets
> the most attention", doesn't scale very well and limits the Pulsar project.
> It also makes contributing feel very painful and not very welcoming.

This is the trouble with slack which is also time limited to 90 days of history.

Yesterday I saw a comment about a slack channel to discuss a PIP and that is 
wrong for two reasons:
1. The reasoning and discussion are not shared. You have to “know” its 
happening.
2. The reasoning and discussion will be unavailable to anyone trying to 
understand why in a very short amount of time.

If you have a problem please use the mailing list. This has been a standard in 
an ASF project for 25 years for good reasons.

> 
> I agree with Enrico's suggestion of starting a new thread to address
> these problems. It's a good way to begin constructively finding a
> solution. Perhaps defining the problems we have in the Pulsar community
> would be a good starting point. One clear indication of a problem is the
> number of open pull requests we have in apache/pulsar; currently, there
> are 320 open pull requests.

If you want to review PRs then please do so in a way that is a conversation. Do 
it in the PR or issue. The only place the discussion should be moved is here on 
this mailing list in public.

> 
> I believe something good comes out of this. Looking forward to contributions
> and volunteers to help fix things.
> 
> -Lari
> 
> 1 - Decision making in Apache projects:
> https://community.apache.org/committers/decisionMaking.html
> 2 - Calendar and Zoom link to meeting:
> https://github.com/apache/pulsar/wiki/Community-Meetings
> 3 - Meeting agenda doc:
> https://docs.google.com/document/d/19dXkVXeU2q_nHmkG8zURjKnYlvD96TbKf5KjYyASsOE/edit
> 
> On Wed, 6 Mar 2024 at 09:32, Enrico Olivelli  wrote:
>> 
>> Kalwit,
>> All the committers are invited by the PMC, you can reach out to
>> priv...@pulsar.apache.org if you have any problems.
>> 
>> Being a committer is not only about doing code contributions, but also
>> talking care 

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Dave Fisher]

> On Mar 6, 2024, at 2:31 AM, Enrico Olivelli  wrote:
> 
> Kalwit,
> All the committers are invited by the PMC, you can reach out to
> priv...@pulsar.apache.org if you have any problems.
> 
> Being a committer is not only about doing code contributions, but also
> talking care of the project and the community.
> 
> I am sorry to hear that you feel that your contributions are blocked,
> please start a new thread with this problem.

It would help PMC members evaluate the situation if you could point to several 
concrete examples of PRs, issues, and mailing list threads that you think show 
your problems.

If you want to ask one at a time you could do so on this dev@ mailing list to 
discuss the technical merits. This would allow anyone looking into your 
observations a chance to easily understand and evaluate on technical merits. By 
having this discussion here you can assure that the conversation is archived 
where anyone can easily find the discussion years from now at lists.apache.org 
 .

Alternatively, please provide a list of examples with links to the PMC via an 
email to priv...@pulsar.apache.org  so that 
the PMC can look into your concerns. It may take some time, but I promise at 
least I will look into these.

You may find information about how ASF communities should work from the 
resources maintained by the Community Development project here: 
https://community.apache.org/contributors/index.html 


> 
> This is a community,  it is not a product managed by one single company.

I can understand how the fact that a vendor’s engagement may appear to dominate 
by sheer volume, but the ASF and good community development requires that 
anyone joining the community be able to contribute even if they have little 
time.

For those contributors who are still following along, please consider taking 
time to consider, comment, and truly engage with the backlog of issues and PRs 
in the project’s various repositories.

Best,
Dave

> 
> Best regards
> Enrico Olivelli
> 
> Il Mer 6 Mar 2024, 06:27 Matteo Merli  ha scritto:
> 
>> I will not enter into debating the long list of grievances here, though I
>> thought I needed to clarify at least 2 points:
>> 
>> 1. You can ask any questions and direct any feedback to the PMC (and if
>> you're not happy with the response you can take it all the way up to the
>> ASF Board), but personal attacks are not OK here
>> 
>> 2. I don't think it's good looking when you're reacting to people
>> disagreeing with you by claiming they either are incompetent or have some
>> hidden agenda. Perhaps trying to understand why they disagreed with you
>> would be more helpful.
>> 
>> 
>> Matteo
>> 
>> --
>> Matteo Merli
>> 
>> 
>> 
>> On Tue, Mar 5, 2024 at 7:22 PM Kalwit S  wrote:
>> 
>>> Congratulations Asaf.
>>> 
>>> Btw, does the Apache project have any promotion criteria for committers?
>> I
>>> looked at Asaf's commits at
>>> https://github.com/apache/pulsar/commits?author=asafm  and found that
>> 99%
>>> of the commits are simple documentation changes and 1% are related to PIP
>>> monitoring. Most of the PIP monitoring involves adding plugins to
>> existing
>>> metrics APIs. He has also contributed to the PIP reviews, but his
>>> contribution is more philosophical rather than technical. Most of his
>>> comments are comparing Pulsar to other projects, rather than focusing on
>>> the internal insights that Pulsar brings to the table. Our team has been
>>> running production traffic using Apache Pulsar for over a year now. We
>> have
>>> tried several different versions of Pulsar (which we have to constantly
>>> upgrade due to unknown issues in live production traffic) and have never
>>> seen a stable version of Pulsar. Our team has also tried to submit
>> multiple
>>> enhancements and also PIP, but most of them are bogged down by reviewers
>>> who are very new to Pulsar, might not understand messaging correctly, or
>>> don’t find such enhancements useful for their usecases.
>>> I would say that most of these reviewers are brand new to Pulsar, and
>>> almost all of them are from the same company that is also the provider of
>>> Pulsar. The same company controls Pulsar, prevents others from
>>> contributing, and avoids having non-pulsar committers. This is why we
>>> wanted to replace our existing Kafka cluster with Pulsar but we see no
>>> difference in Pulsar provider and Confluent because Pulsar is also
>> largely
>>> controlled by one provider and this company's reviewers are not
>> well-versed
>>> in such systems.
>>> In addition, we can see that almost all the reviewers are from the same
>>> company, and PIP approval requires 3+ votes, which means only specific
>>> reviewers belonging to one company participate and because of that, no
>> one
>>> can promote their improvements without the approval of the provider
>>> company. The Pulsar community needs to break away 

Re: Pulsar Version upgrade guidelines

[Girish Sharma]

Bumping this up.
I cannot be the only one confused by these questions.

Pulsar is at a stage where users have to constantly upgrade due to
stability or feature needs. The answers to the questions I am asking should
help everyone planning upgrades from 2.x to 3.x and other combinations.

Regards

On Fri, Feb 16, 2024 at 6:31 PM Girish Sharma 
wrote:

> There have been a few discussions in the past on the slack channel and I
> recently also started a similar thread [0] regarding if we can skip certain
> releases while upgrading towards pulsar 3.0 and beyond. Starting this dev
> mailing list discussion to get some more input.
>
> As per official release policy [1] itself, there are some open questions:
>
> *Before 3.0, upgrade should be done linearly through each feature version.
>> For example, when upgrading from 2.8 to 2.10, it is important to upgrade to
>> 2.9 before going to 2.10. *
>>
>
> This is a very clear statement. Although lengthy, it makes sense to limit
> the scope of OSS to test upgrades from and to every version.
>
> *Starting from 3.0, additionally, live upgrade/downgrade between one LTS
>> and the next one is guaranteed. For example, *
>>
>
> What does this exactly entail? Does it only mean that I can do 3.0.x <->
> 4.0.x ? The example just below is misleading from that perspective
>
>
>>
>>
>> *3.0 -> 4.0 -> 3.0 is OK;3.2 -> 4.0 -> 3.2 is OK;3.2 -> 4.4 ->
>> 3.2 is OK;3.2 -> 5.0 is not OK.*
>
>
> This seems to give a feeling that it is possible to upgrade from any 3.x
> version to any 3.x or 4.x version including rollbacks. Are we testing this
> as new 3.x versions release?
>
> To add to the confusion, the blog post [2] of 3.2 release mentions this
>
> *For the 3.2 series, you should be able to upgrade from version 3.1 or
>> downgrade from the subsequently released version 3.3. If you are currently
>> using an earlier version, please ensure that you upgrade to version 3.1
>> before proceeding further.*
>
>
> This is confusing now. So 3.2 -> 4.0 would be possible but 3.0 -> 3.2
> isn't? Why is 3.2 -> 4.4 possible then?
>
> Wish to see the community's take on this in order to align the
> recommendation.
>
> [0] https://apache-pulsar.slack.com/archives/C5Z4T36F7/p1705392242948349
> [1]
> https://pulsar.apache.org/contribute/release-policy/#compatibility-between-releases
> [2]
> https://pulsar.apache.org/blog/2024/02/12/announcing-apache-pulsar-3-2/
>
> --
> Girish Sharma
>


-- 
Girish Sharma

Re: [DISCUSS] Clarify the relation between supported Pulsar versions and versioned docs

[Kiryl Valkovich]

Idea: don't require updating versioned docs from contributors.
Making a small documentation fix in a single place is easy, but if we ask 
contributors to fix it in 5-10 places, it may prevent the initiative at all.

It could increase the amount of contributions to the documentation.

I'm not sure how to better organize this process. Who should do this job - the 
PR reviewer or someone else like a technical writer?


Best,
Kiryl

> On Mar 5, 2024, at 12:15 AM, Kiryl Valkovich  wrote:
> 
> The release policy page states that Pulsar has two supported versions on the 
> current date.
> The documentation site provides four versions to choose from in the dropdown 
> list. If some of them aren't actively supported, should they also be updated?
> 
> GitHub issue with more details and screenshots: 
> https://github.com/apache/pulsar/issues/22177
> 
> 
> Best,
> Kiryl

Re: [VOTE] Pulsar Release 3.2.1 Candidate 1

[PengHui Li]

+1 (binding)

- Built from source
- Checked the signatures
- Run standalone
- Checked producer and consumer
- Verified the Cassandra connector
- Verified the Stateful function

Regards,
Penghui

On Wed, Mar 6, 2024 at 3:38 PM guo jiwei  wrote:

> +1 (binding)
>
> - Built from source
> - Checked the signatures
> - Run standalone
> - Checked producer and consumer
> - Verified the Cassandra connector
> - Verified the Stateful function
>
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Wed, Mar 6, 2024 at 2:33 AM Ran Gao  wrote:
>
> > +1(non-binding)
> >
> > 1. verify the GPG signature for the below files
> > - apache-pulsar-3.2.1-bin.tar.gz.asc
> > - apache-pulsar-3.2.1-src.tar.gz.asc
> > 2. build the source code
> > 3. test following the release verifying doc.
> >
> > Regards,
> > Ran Gao
> >
> > On 2024/03/05 07:05:05 guo jiwei wrote:
> > > This is the first release candidate for Apache Pulsar version 3.2.1.
> > >
> > > It fixes the following issues:
> > >
> >
> https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Amerged+label%3Arelease%2F3.2.1+label%3Acherry-picked%2Fbranch-3.2+
> > >
> > > *** Please download, test and verify on this release. This vote will
> stay
> > > open for at least 72 hours ***
> > >
> > > Note that we are verifying upon the source (tag), binaries are provided
> > for
> > > convenience.
> > >
> > > Source and binary files:
> > >
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-3.2.1-candidate-1/
> > >
> > > SHA-512 checksums:
> > >
> > >
> >
> d500ba21305d56b0f7b4355e1270e50ae5f60e5632b6632d66fec6d1178bb9fdf3f24caa709b6b36ea8273e5a2c094868cf30e389154bc8bb6397e7de4f1bf1d
> > >
> > > apache-pulsar-3.2.1-bin.tar.gz
> > >
> > >
> >
> 7aee1623db6dc95058cd0e7a4f108f8a3f43163d798a8eeeaecf5f335225c04f5a0518ce2dfb2d4fa29b7b5e54d27ba24af82fbb3542eb3ffc9e3602cb577878
> > >
> > > apache-pulsar-3.2.1-src.tar.gz
> > >
> > > Maven staging repo:
> > >
> https://repository.apache.org/content/repositories/orgapachepulsar-1267/
> > >
> > > The tag to verify:
> > > v3.2.1-candidate-1 (158d5eb670c9fd7b123c204533ac6cf8cb439ccd)
> > > https://github.com/apache/pulsar/commits/v3.2.1-candidate-1/
> > >
> > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > https://dist.apache.org/repos/dist/dev/pulsar/KEYS
> > >
> > > Docker images:
> > >
> > > pulsar images:
> > >
> >
> https://hub.docker.com/layers/technoboy8/pulsar/3.2.1-158d5eb/images/sha256-23f0cbd54b1fb504dcab16dfcce562ed735ab94db1c5f6fabbe9145f3a2d0fa8?context=repo
> > > <
> >
> https://hub.docker.com/layers/mattison/pulsar/3.1.0-candidate-1/images/sha256-0efbaad7d893cc5041a46a2d4d56432bda855ae4068a38349777d1be6e98d27d?context=explore
> > >
> > > pulsar-all images:
> > >
> >
> https://hub.docker.com/layers/technoboy8/pulsar-all/3.2.1-158d5eb/images/sha256-80ab1d748eff18655a9c247beba74aa107624b9d3e7cc3a2f22e1246f0d3de83?context=repo
> > >
> > > Please download the source package, and follow the README to build
> > > and run the Pulsar standalone service.
> > >
> > >
> > >
> > > Regards
> > > Jiwei Guo (Tboy)
> > >
> >
>

Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

[Lari Hotari]

Hi Kalwit,

In Apache Pulsar, as in any other Apache project, everyone is equal
regardless of their committer or PMC status. All project participants
are free to express their opinions, and, where appropriate, have the
community consider them when decisions are made. [1]

I'm sorry to hear that you haven't felt this way. I believe we can find
a resolution.

We hold an open community meeting every two weeks on Zoom [2]. Anyone
can join these meetings. The agenda is maintained in a Google Doc [3],
where you can add items before the meeting. During the meeting, we
consider all agenda items. If we run out of time, we prioritize the
leftover items for the next meeting. The meeting's scope is the
development of Apache Pulsar and the community; it is not a place to
get free support in using Pulsar.

In remote work, there's a chance of feeling left out even when no one
intends to exclude you. In Apache Pulsar, we do have a problem with
responding to issues and pull requests in a reasonable time. It can feel
disheartening when you put significant effort into making a
contribution, and it goes unnoticed or ignored. I understand this
feeling. It also feels discouraging when someone gives you feedback
about something minor in your contribution, which doesn't really help
resolve the problem you're addressing. This happens when we're busy and
don't spend enough time caring about others' contributions. Apache
Pulsar's development is handled by the community, and there's no company
running this project. Therefore, when you don't get feedback, there's no
company to blame. We need to resolve the problems together in the
Apache Pulsar project. The decision process of Apache [1] does not
emphasize the committer or PMC status. I hope everyone could feel
empowered to express their opinions and have the community consider
them in order to make decisions to improve. It's also good to remember
that it's all volunteers and if nobody volunteers to do something that has
been suggested, it won't happen.

We need to find ways to improve the Apache Pulsar project so that
contributors can receive feedback in a reasonable time. Currently,
It is possible for the contributor to join the community meeting to
request feedback or promote their contribution on Pulsar Slack's #dev channel
until someone responds. However, this solution where "the loudest voice gets
the most attention", doesn't scale very well and limits the Pulsar project.
It also makes contributing feel very painful and not very welcoming.

I agree with Enrico's suggestion of starting a new thread to address
these problems. It's a good way to begin constructively finding a
solution. Perhaps defining the problems we have in the Pulsar community
would be a good starting point. One clear indication of a problem is the
number of open pull requests we have in apache/pulsar; currently, there
are 320 open pull requests.

I believe something good comes out of this. Looking forward to contributions
and volunteers to help fix things.

-Lari

1 - Decision making in Apache projects:
https://community.apache.org/committers/decisionMaking.html
2 - Calendar and Zoom link to meeting:
https://github.com/apache/pulsar/wiki/Community-Meetings
3 - Meeting agenda doc:
https://docs.google.com/document/d/19dXkVXeU2q_nHmkG8zURjKnYlvD96TbKf5KjYyASsOE/edit

On Wed, 6 Mar 2024 at 09:32, Enrico Olivelli  wrote:
>
> Kalwit,
> All the committers are invited by the PMC, you can reach out to
> priv...@pulsar.apache.org if you have any problems.
>
> Being a committer is not only about doing code contributions, but also
> talking care of the project and the community.
>
> I am sorry to hear that you feel that your contributions are blocked,
> please start a new thread with this problem.
>
> This is a community,  it is not a product managed by one single company.
>
> Best regards
> Enrico Olivelli
>
> Il Mer 6 Mar 2024, 06:27 Matteo Merli  ha scritto:
>
> > I will not enter into debating the long list of grievances here, though I
> > thought I needed to clarify at least 2 points:
> >
> > 1. You can ask any questions and direct any feedback to the PMC (and if
> > you're not happy with the response you can take it all the way up to the
> > ASF Board), but personal attacks are not OK here
> >
> > 2. I don't think it's good looking when you're reacting to people
> > disagreeing with you by claiming they either are incompetent or have some
> > hidden agenda. Perhaps trying to understand why they disagreed with you
> > would be more helpful.
> >
> >
> > Matteo
> >
> > --
> > Matteo Merli
> > 
> >
> >
> > On Tue, Mar 5, 2024 at 7:22 PM Kalwit S  wrote:
> >
> > > Congratulations Asaf.
> > >
> > > Btw, does the Apache project have any promotion criteria for committers?
> > I
> > > looked at Asaf's commits at
> > > https://github.com/apache/pulsar/commits?author=asafm  and found that
> > 99%
> > > of the commits are simple documentation changes and 1% are related to PIP
> > > monitoring. Most of the PIP monitoring 

Re: [VOTE] Pulsar Release 2.10.6 Candidate 1

[Zixuan Liu]

It sounds like the version release was triggered due to security issues. If
so, I think we need to update our release policy.

Only when a fatal security issue occurs can we trigger a release of a new
version, but we also need to clarify the maintenance cycle, otherwise this
maintenance is endless.

Thanks,
Zixuan

Xiangying Meng  于2024年3月6日周三 16:45写道：

> Dear Zixuan,
>
> Thank you for your email and your ongoing commitment to the Pulsar project.
>
> I wanted to clarify that this release, 2.10.6, is a special case. It
> was primarily focused on addressing certain security issues that were
> deemed critical. This decision was made following internal discussions
> within the PMC.
>
> I completely understand and respect the release policy defined by
> Pulsar [0]. Under normal circumstances, we would indeed follow the
> policy and consider version 2.10 as EOL, ceasing further maintenance.
>
> However, given the exceptional nature of this release and the
> importance of the security issues it addresses, we felt it was
> necessary to make an exception in this case.
>
> Thank you for your understanding and for bringing this to our
> attention. We appreciate your diligence in adhering to Pulsar's
> release policy.
>
> Best regards,
>
> Xiangying
>
> On Wed, Mar 6, 2024 at 4:22 PM Zixuan Liu  wrote:
> >
> > Thank you for releasing 2.10.6.
> >
> > According to the release policy defined [0] by Pulsar, this version is
> EOL and
> > does not require further maintenance.
> >
> > If we need to continue to maintain the 2.10, we must discuss the
> > maintenance lifecycle of the 2.10, and update our doc.
> >
> > - [0] https://pulsar.apache.org/contribute/release-policy/
> >
> > Thanks,
> > Zixuan
> >
> >
> > Xiangying Meng  于2024年3月6日周三 11:15写道：
> >
> > > This is the first release candidate for Apache Pulsar, version 2.10.6.
> > >
> > > It fixes the following issues:
> > >
> > >
> https://github.com/apache/pulsar/pulls?q=is:pr+label:cherry-picked/branch-2.10+label:release/2.10.6+is:closed
> > >
> > > *** Please download, test and vote on this release. This vote will stay
> > > open
> > > for at least 72 hours ***
> > >
> > > Note that we are voting upon the source (tag), binaries are provided
> for
> > > convenience.
> > >
> > > Source and binary files:
> > >
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.10.6-candidate-1/
> > >
> > > SHA-512 checksums:
> > >
> > >
> 09f29265f8173331d4c05b470c4e77a31146172b27ef333f45d8c8a19074ef25061cb1e80872fc45c323c9ce8e2e17989c6df5d991ef84c4d245197303d9e6d7
> > >  apache-pulsar-2.10.6-bin.tar.gz
> > >
> > >
> 49c8836882818c6f38748dae26b51c598f163606c16993a3287ab1ce9f853a4aaa43c6729c1b6f6957738b4dead3818cd12026da68b328eb2d4ac0d0214957bb
> > >  apache-pulsar-2.10.6-src.tar.gz
> > >
> > > Maven staging repo:
> > >
> https://repository.apache.org/content/repositories/orgapachepulsar-1270
> > >
> > > The tag to be voted upon:
> > > v2.10.6-candidate-1 (9c29b76ff2be865429ad44df8683aec80deacfba)
> > > https://github.com/apache/pulsar/releases/tag/v2.10.6-candidate-1
> > >
> > > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > > https://downloads.apache.org/pulsar/KEYS
> > >
> > > Docker images:
> > >
> > > 
> > >
> > >
> https://hub.docker.com/layers/xiangyingmeng/pulsar/2.10.6/images/sha256-bf8f36e49ff44ef810ab2c76742121205e51d3a04c79afdb5d288c7d8a06443f?context=repo
> > >
> > > 
> > >
> > >
> https://hub.docker.com/layers/xiangyingmeng/pulsar-all/2.10.6/images/sha256-1b3a10db12f6d5a0acd2d4ed73eb11864b6b598294bb905b6ede34aef1157f23?context=repo
> > >
> > > Please download the source package, and follow the README to build
> > > and run the Pulsar standalone service.
> > >
>

Re: [VOTE] Pulsar Release 2.10.6 Candidate 1

[Xiangying Meng]

Dear Zixuan,

Thank you for your email and your ongoing commitment to the Pulsar project.

I wanted to clarify that this release, 2.10.6, is a special case. It
was primarily focused on addressing certain security issues that were
deemed critical. This decision was made following internal discussions
within the PMC.

I completely understand and respect the release policy defined by
Pulsar [0]. Under normal circumstances, we would indeed follow the
policy and consider version 2.10 as EOL, ceasing further maintenance.

However, given the exceptional nature of this release and the
importance of the security issues it addresses, we felt it was
necessary to make an exception in this case.

Thank you for your understanding and for bringing this to our
attention. We appreciate your diligence in adhering to Pulsar's
release policy.

Best regards,

Xiangying

On Wed, Mar 6, 2024 at 4:22 PM Zixuan Liu  wrote:
>
> Thank you for releasing 2.10.6.
>
> According to the release policy defined [0] by Pulsar, this version is EOL and
> does not require further maintenance.
>
> If we need to continue to maintain the 2.10, we must discuss the
> maintenance lifecycle of the 2.10, and update our doc.
>
> - [0] https://pulsar.apache.org/contribute/release-policy/
>
> Thanks,
> Zixuan
>
>
> Xiangying Meng  于2024年3月6日周三 11:15写道：
>
> > This is the first release candidate for Apache Pulsar, version 2.10.6.
> >
> > It fixes the following issues:
> >
> > https://github.com/apache/pulsar/pulls?q=is:pr+label:cherry-picked/branch-2.10+label:release/2.10.6+is:closed
> >
> > *** Please download, test and vote on this release. This vote will stay
> > open
> > for at least 72 hours ***
> >
> > Note that we are voting upon the source (tag), binaries are provided for
> > convenience.
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.10.6-candidate-1/
> >
> > SHA-512 checksums:
> >
> > 09f29265f8173331d4c05b470c4e77a31146172b27ef333f45d8c8a19074ef25061cb1e80872fc45c323c9ce8e2e17989c6df5d991ef84c4d245197303d9e6d7
> >  apache-pulsar-2.10.6-bin.tar.gz
> >
> > 49c8836882818c6f38748dae26b51c598f163606c16993a3287ab1ce9f853a4aaa43c6729c1b6f6957738b4dead3818cd12026da68b328eb2d4ac0d0214957bb
> >  apache-pulsar-2.10.6-src.tar.gz
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachepulsar-1270
> >
> > The tag to be voted upon:
> > v2.10.6-candidate-1 (9c29b76ff2be865429ad44df8683aec80deacfba)
> > https://github.com/apache/pulsar/releases/tag/v2.10.6-candidate-1
> >
> > Pulsar's KEYS file containing PGP keys you use to sign the release:
> > https://downloads.apache.org/pulsar/KEYS
> >
> > Docker images:
> >
> > 
> >
> > https://hub.docker.com/layers/xiangyingmeng/pulsar/2.10.6/images/sha256-bf8f36e49ff44ef810ab2c76742121205e51d3a04c79afdb5d288c7d8a06443f?context=repo
> >
> > 
> >
> > https://hub.docker.com/layers/xiangyingmeng/pulsar-all/2.10.6/images/sha256-1b3a10db12f6d5a0acd2d4ed73eb11864b6b598294bb905b6ede34aef1157f23?context=repo
> >
> > Please download the source package, and follow the README to build
> > and run the Pulsar standalone service.
> >

Re: [VOTE] Pulsar Release 2.10.6 Candidate 1

[Zixuan Liu]

Thank you for releasing 2.10.6.

According to the release policy defined [0] by Pulsar, this version is EOL and
does not require further maintenance.

If we need to continue to maintain the 2.10, we must discuss the
maintenance lifecycle of the 2.10, and update our doc.

- [0] https://pulsar.apache.org/contribute/release-policy/

Thanks,
Zixuan


Xiangying Meng  于2024年3月6日周三 11:15写道：

> This is the first release candidate for Apache Pulsar, version 2.10.6.
>
> It fixes the following issues:
>
> https://github.com/apache/pulsar/pulls?q=is:pr+label:cherry-picked/branch-2.10+label:release/2.10.6+is:closed
>
> *** Please download, test and vote on this release. This vote will stay
> open
> for at least 72 hours ***
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.10.6-candidate-1/
>
> SHA-512 checksums:
>
> 09f29265f8173331d4c05b470c4e77a31146172b27ef333f45d8c8a19074ef25061cb1e80872fc45c323c9ce8e2e17989c6df5d991ef84c4d245197303d9e6d7
>  apache-pulsar-2.10.6-bin.tar.gz
>
> 49c8836882818c6f38748dae26b51c598f163606c16993a3287ab1ce9f853a4aaa43c6729c1b6f6957738b4dead3818cd12026da68b328eb2d4ac0d0214957bb
>  apache-pulsar-2.10.6-src.tar.gz
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachepulsar-1270
>
> The tag to be voted upon:
> v2.10.6-candidate-1 (9c29b76ff2be865429ad44df8683aec80deacfba)
> https://github.com/apache/pulsar/releases/tag/v2.10.6-candidate-1
>
> Pulsar's KEYS file containing PGP keys you use to sign the release:
> https://downloads.apache.org/pulsar/KEYS
>
> Docker images:
>
> 
>
> https://hub.docker.com/layers/xiangyingmeng/pulsar/2.10.6/images/sha256-bf8f36e49ff44ef810ab2c76742121205e51d3a04c79afdb5d288c7d8a06443f?context=repo
>
> 
>
> https://hub.docker.com/layers/xiangyingmeng/pulsar-all/2.10.6/images/sha256-1b3a10db12f6d5a0acd2d4ed73eb11864b6b598294bb905b6ede34aef1157f23?context=repo
>
> Please download the source package, and follow the README to build
> and run the Pulsar standalone service.
>