You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Kalwit S <sk...@gmail.com> on 2024/03/05 23:31:32 UTC
Re: [ANNOUNCE] New Committer: Asaf Mesika
Congratulations.!
On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org> wrote:
> The Apache Pulsar Project Management Committee (PMC) has invited
> Asaf Mesika https://github.com/asafm to become a committer and we
> are pleased to announce that he has accepted.
>
> Welcome and Congratulations, Asaf Mesika!
>
> Please join us in congratulating and welcoming Asaf onboard!
>
> Best Regards,
>
> Lari Hotari
> on behalf of the Pulsar PMC
>
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Joe F <jo...@gmail.com>.
>
> 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 <sc...@gmail.com>
wrote:
> On Thu, Mar 7, 2024 at 11:38 AM Yunze Xu <xy...@apache.org> 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
Posted by Apurva Telang <ap...@gmail.com>.
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 <sc...@gmail.com>
wrote:
> On Thu, Mar 7, 2024 at 11:38 AM Yunze Xu <xy...@apache.org> 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
Posted by Asaf Mesika <as...@gmail.com>.
>
> I have selected these examples from the most recent discussions and they
> may not be the best examples to fully illustrate the point.
You should respect people's time by taking the time to craft your replies
in this discussion.
From my experience, I've been contributing a lot in recent years to
OpenTelemetry, and sometimes it takes me a few good hours, even a day to
write a good reply: I research the proposed idea, research the discussions
or issues sent to me and only then craft the reply.
I can tell you from my experience working on OpenTelemetry, that the way
you describe is practically how Open Source works - and OpenTelemetry is
the 2nd biggest project in CNCF!
* I wrote a proposal and it was ignored.
* I joined the weekly community meeting. Pitched my idea and then I had to
ping the people replying to me in that Zoom, a good few times on Slack, to
get a reply. After many days and sometimes weeks waiting between replies, I
scheduled a Zoom call with two of them to get their ideas and mine sync.
* I revised my proposal - and what do you think happened? I had to ping
them AGAIN, and yes, wait sometimes a week for a reply.
In reality, you have to constantly push your proposal, idea, and PR forward.
Today it's so much easier for me in OpenTelemetry. After so many
contributions ranging from specification changes, proposal, documentation
changes and code PRs, the feedback is much more prompt. You know why?
Personal relationship - you build it over time.
If I would act your way, I would never have gotten anything in OpenTelemtry.
Regarding the criteria for accepting a committer. Your response clearly
shows you were not part of the community these past 2 years, otherwise you
would notice the contribution I've made to Apache Pulsar. The PMC members
have noticed hence the invitation to join as committer. Feel free to browse
the mailing list archives to see it and GitHub issues/PRs/Discussions and
Slack.
I can tell you personally that one of my goals when I started reviewing
PIPs in Pulsar roughly 2 years ago, was to "raise the bar" of the quality
of Pulsar. For me, it starts with exceptional design documents. I stated it
multiple times in the mailing list, and it came to manifest itself also in
the new PIP template I proposed and is now used: One should be able to
grasp the PIP from start to bottom without any prior background knowledge.
One of the key reasons for Pulsar's biggest points for improvements is the
documentation: It's a big encyclopedia with a lot of information missing.
Same goes with architecture of the code - many are not documented. As the
person who writes the design already takes the time to research the code
quite well before writing the design, it makes sense to write it in a
concise manner in the PIP. The good PIPs have that. Since the introduction
of the template, and reviewing many PIPs and also writing a few as "show by
example" it finally reached that state in Pulsar.
Those high quality PIPs in my opinion will lead Pulsar to be of higher
quality.
By the way: can you share a personal open source contribution experience
which was vastly different from what you or I described? I personally only
experienced that or worse :)
Cheers,
Asaf
On Fri, Mar 8, 2024 at 12:55 AM Kalwit S <sk...@gmail.com> wrote:
> >> If you check the votes and the participation in discussion of PIPs it is
> *always* involving contributions of >3 different companies.
> >> Well, I think you've chosen *very* bad examples. In none of these cases
> the discussion
> I have selected these examples from the most recent discussions and they
> may not be the best examples to fully illustrate the point. However, there
> are several things to note with most of these examples that are still open
> PIPs and do not have closure after a couple of months. Also, you do not see
> non provider company reviews and VOTE in the majority of the discussion,
> which leads me to believe that you cannot move forward without relying on
> the provider’s mercy (same as Confluent).
>
>
> >> > BTW, if your team is really tired of managing a stable Pulsar,
> StreamNative
> > can help you :)
> >> And so can DataStax ;-)
> I will take this as a conclusion to run a stable Pulsar release.
>
>
> On Thu, Mar 7, 2024 at 5:09 AM Dave Fisher <wa...@apache.org> wrote:
>
> >
> >
> > > On Mar 7, 2024, at 4:20 AM, Neng Lu <nl...@apache.org> wrote:
> > >
> > > BTW, if your team is really tired of managing a stable Pulsar,
> > StreamNative
> > > can help you :)
> >
> > And so can DataStax ;-)
>
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Kalwit S <sk...@gmail.com>.
>> If you check the votes and the participation in discussion of PIPs it is
*always* involving contributions of >3 different companies.
>> Well, I think you've chosen *very* bad examples. In none of these cases
the discussion
I have selected these examples from the most recent discussions and they
may not be the best examples to fully illustrate the point. However, there
are several things to note with most of these examples that are still open
PIPs and do not have closure after a couple of months. Also, you do not see
non provider company reviews and VOTE in the majority of the discussion,
which leads me to believe that you cannot move forward without relying on
the provider’s mercy (same as Confluent).
>> > BTW, if your team is really tired of managing a stable Pulsar,
StreamNative
> can help you :)
>> And so can DataStax ;-)
I will take this as a conclusion to run a stable Pulsar release.
On Thu, Mar 7, 2024 at 5:09 AM Dave Fisher <wa...@apache.org> wrote:
>
>
> > On Mar 7, 2024, at 4:20 AM, Neng Lu <nl...@apache.org> wrote:
> >
> > BTW, if your team is really tired of managing a stable Pulsar,
> StreamNative
> > can help you :)
>
> And so can DataStax ;-)
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Dave Fisher <wa...@apache.org>.
> On Mar 7, 2024, at 4:20 AM, Neng Lu <nl...@apache.org> wrote:
>
> BTW, if your team is really tired of managing a stable Pulsar, StreamNative
> can help you :)
And so can DataStax ;-)
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Neng Lu <nl...@apache.org>.
I normally tend to be a silent observer of the community due to my
limited time schedule.
But I feel the obligation to share my thoughts in this thread so that
people are not misled.
> 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
Please be aware, per ASF Community Guide[1], "There is nothing at the
Apache Software Foundation that says you must write code in order to be a
committer. Anyone who is supportive of the community and works in any of
the CoPDoC areas is a likely candidate for committership."
And I personally hold this view (which you may disagree): at this stage,
philosophical contributions have a very big impact on the overall health of
Pulsar and community.
And many of Asaf's contributions are guiding us toward the right direction.
> The Pulsar community needs to break away from the monopolies of
> the provider companies, start focusing on stable releases, and let other
> companies make their enhancements to meet their requirements, and
> experienced contributors or Pulsar creators should be active to prevent
> unfairness in the community.
First of all, if there's unfair treatment to any contributor, please
collect the specific proof and file a complaint to the Pulsar PMC and ASF
Board if you want.
I believe they will investigate and decide if that's true or not in an open
and fair way.
Secondly, you can help increase the community diversity by starting working
on Pulsar issues and making more contributions right now.
Thirdly, having a company behind an open source project isn't necessarily a
bad thing. A few examples:
- Apache Spark -- Databricks
- Apache Kafka -- Confluent
- Apache Hadoop -- Cloudera, Hortonworks, MapR
- Apache Cassandra -- DataStax
- Apache Flink -- Ververica
- Apache Beam -- Google
These companies are paying their employees money to work on the open source
project. As long as all the activities follow the community rule, everyone
using these projects are benefiting from these companies' contribution.
> 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.
People have replied previously regarding your statement about committers,
so I won't tackle it again.
Instead of just looking at where these new committers are coming from, I
would suggest you think about the following:
1. Does this new committer make meaningful contributions to the
community?
2. Is the standard of becoming a Pulsar committer consistent regardless
of where people are coming from?
3. Did you find anyone who makes great contributions is left behind or
prevented from becoming a committer?
> 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.
Apache Pulsar is an evolving open source project, so bugs may be identified
along the way when people are using it in various scenarios.
But the community has invested a lot into its correctness and stability, as
other people mentioned every new release improves significantly.
BTW, if your team is really tired of managing a stable Pulsar, StreamNative
can help you :)
> 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 focus on sharing your own specific problems and experiences.
I do see many non-SN people speak up in this thread, and they share a
completely different experience than you.
> 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.
Pulsar has its own unique advantages over Kafka: multi-tenancy,
geo-replication, messaging queue support, zero-down-time scaling out & in.
We also see many companies(DiDi, Tencent, Paypal, etc) adopting OSS Pulsar.
Some of the problems like bugs in release, responsiveness for PR review can
be improved along the way.
To be fair, DataStax is also a vendor for Pulsar, and many of their folks
are also active in the community.
It's okay to choose other technologies that best fits your own
requirements, but please don't assume everyone is the same as you.
[1] https://community.apache.org/contributors/#anyone-can-become-a-committer
On Wed, Mar 6, 2024 at 11:14 PM Yunze Xu <xy...@apache.org> wrote:
> 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 <lh...@apache.org> wrote:
> >
> > On Thu, 7 Mar 2024 at 08:14, Girish Sharma <sc...@gmail.com>
> 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
Posted by Yunze Xu <xy...@apache.org>.
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 <lh...@apache.org> wrote:
>
> On Thu, 7 Mar 2024 at 08:14, Girish Sharma <sc...@gmail.com> 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
Posted by Lari Hotari <lh...@apache.org>.
On Thu, 7 Mar 2024 at 08:14, Girish Sharma <sc...@gmail.com> 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
Posted by Girish Sharma <sc...@gmail.com>.
On Thu, Mar 7, 2024 at 11:38 AM Yunze Xu <xy...@apache.org> 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
Posted by Yunze Xu <xy...@apache.org>.
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 <xy...@apache.org> 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 <wa...@apache.org> wrote:
> >
> >
> >
> > > On Mar 6, 2024, at 10:01 PM, Kalwit S <sk...@gmail.com> 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
Posted by Yunze Xu <xy...@apache.org>.
> 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 <wa...@apache.org> wrote:
>
>
>
> > On Mar 6, 2024, at 10:01 PM, Kalwit S <sk...@gmail.com> 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
Posted by Dave Fisher <wa...@apache.org>.
> On Mar 6, 2024, at 10:01 PM, Kalwit S <sk...@gmail.com> 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
Posted by Matteo Merli <ma...@gmail.com>.
On Wed, Mar 6, 2024 at 7:02 PM Kalwit S <sk...@gmail.com> 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
Posted by Kalwit S <sk...@gmail.com>.
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 <ma...@gmail.com> wrote:
> On Wed, Mar 6, 2024 at 12:49 PM Kalwit S <sk...@gmail.com> 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
Posted by Matteo Merli <ma...@gmail.com>.
On Wed, Mar 6, 2024 at 12:49 PM Kalwit S <sk...@gmail.com> 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
Posted by Joe F <jo...@gmail.com>.
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 <sk...@gmail.com> 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 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 <wa...@apache.org> wrote:
>
> >
> >
> > > On Mar 6, 2024, at 4:50 AM, Lari Hotari <lh...@apache.org> 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 <eo...@gmail.com>
> > wrote:
> > >>
> > >> Kalwit,
> > >> All the committers are invited by the PMC, you can reach out to
> > >> private@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 <ma...@gmail.com> 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
> > >>> <ma...@gmail.com>
> > >>>
> > >>>
> > >>> On Tue, Mar 5, 2024 at 7:22 PM Kalwit S <sk...@gmail.com>
> 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 from the
> monopolies
> > of
> > >>>> the provider companies, start focusing on stable releases, and let
> > other
> > >>>> companies make their enhancements to meet their requirements, and
> > >>>> experienced contributors or Pulsar creators should be active to
> > prevent
> > >>>> unfairness in the community.
> > >>>>
> > >>>> On Tue, Mar 5, 2024 at 3:31 PM Kalwit S <sk...@gmail.com>
> wrote:
> > >>>>
> > >>>>> Congratulations.!
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org>
> > >>> wrote:
> > >>>>>
> > >>>>>> The Apache Pulsar Project Management Committee (PMC) has invited
> > >>>>>> Asaf Mesika https://github.com/asafm to become a committer and we
> > >>>>>> are pleased to announce that he has accepted.
> > >>>>>>
> > >>>>>> Welcome and Congratulations, Asaf Mesika!
> > >>>>>>
> > >>>>>> Please join us in congratulating and welcoming Asaf onboard!
> > >>>>>>
> > >>>>>> Best Regards,
> > >>>>>>
> > >>>>>> Lari Hotari
> > >>>>>> on behalf of the Pulsar PMC
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> >
> >
>
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Enrico Olivelli <eo...@gmail.com>.
Kalwit,
Il Mer 6 Mar 2024, 21:49 Kalwit S <sk...@gmail.com> 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 (private@pulsar.apache.org) or with the ASF Board of directors (
board@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 <wa...@apache.org> wrote:
>
> >
> >
> > > On Mar 6, 2024, at 4:50 AM, Lari Hotari <lh...@apache.org> 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 <eo...@gmail.com>
> > wrote:
> > >>
> > >> Kalwit,
> > >> All the committers are invited by the PMC, you can reach out to
> > >> private@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 <ma...@gmail.com> 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
> > >>> <ma...@gmail.com>
> > >>>
> > >>>
> > >>> On Tue, Mar 5, 2024 at 7:22 PM Kalwit S <sk...@gmail.com>
> 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 from the
> monopolies
> > of
> > >>>> the provider companies, start focusing on stable releases, and let
> > other
> > >>>> companies make their enhancements to meet their requirements, and
> > >>>> experienced contributors or Pulsar creators should be active to
> > prevent
> > >>>> unfairness in the community.
> > >>>>
> > >>>> On Tue, Mar 5, 2024 at 3:31 PM Kalwit S <sk...@gmail.com>
> wrote:
> > >>>>
> > >>>>> Congratulations.!
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org>
> > >>> wrote:
> > >>>>>
> > >>>>>> The Apache Pulsar Project Management Committee (PMC) has invited
> > >>>>>> Asaf Mesika https://github.com/asafm to become a committer and we
> > >>>>>> are pleased to announce that he has accepted.
> > >>>>>>
> > >>>>>> Welcome and Congratulations, Asaf Mesika!
> > >>>>>>
> > >>>>>> Please join us in congratulating and welcoming Asaf onboard!
> > >>>>>>
> > >>>>>> Best Regards,
> > >>>>>>
> > >>>>>> Lari Hotari
> > >>>>>> on behalf of the Pulsar PMC
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> >
> >
>
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Kalwit S <sk...@gmail.com>.
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 <wa...@apache.org> wrote:
>
>
> > On Mar 6, 2024, at 4:50 AM, Lari Hotari <lh...@apache.org> 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 <eo...@gmail.com>
> wrote:
> >>
> >> Kalwit,
> >> All the committers are invited by the PMC, you can reach out to
> >> private@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 <ma...@gmail.com> 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
> >>> <ma...@gmail.com>
> >>>
> >>>
> >>> On Tue, Mar 5, 2024 at 7:22 PM Kalwit S <sk...@gmail.com> 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 from the monopolies
> of
> >>>> the provider companies, start focusing on stable releases, and let
> other
> >>>> companies make their enhancements to meet their requirements, and
> >>>> experienced contributors or Pulsar creators should be active to
> prevent
> >>>> unfairness in the community.
> >>>>
> >>>> On Tue, Mar 5, 2024 at 3:31 PM Kalwit S <sk...@gmail.com> wrote:
> >>>>
> >>>>> Congratulations.!
> >>>>>
> >>>>>
> >>>>> On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org>
> >>> wrote:
> >>>>>
> >>>>>> The Apache Pulsar Project Management Committee (PMC) has invited
> >>>>>> Asaf Mesika https://github.com/asafm to become a committer and we
> >>>>>> are pleased to announce that he has accepted.
> >>>>>>
> >>>>>> Welcome and Congratulations, Asaf Mesika!
> >>>>>>
> >>>>>> Please join us in congratulating and welcoming Asaf onboard!
> >>>>>>
> >>>>>> Best Regards,
> >>>>>>
> >>>>>> Lari Hotari
> >>>>>> on behalf of the Pulsar PMC
> >>>>>>
> >>>>>
> >>>>
> >>>
>
>
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Dave Fisher <wa...@apache.org>.
> On Mar 6, 2024, at 4:50 AM, Lari Hotari <lh...@apache.org> 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 <eo...@gmail.com> wrote:
>>
>> Kalwit,
>> All the committers are invited by the PMC, you can reach out to
>> private@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 <ma...@gmail.com> 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
>>> <ma...@gmail.com>
>>>
>>>
>>> On Tue, Mar 5, 2024 at 7:22 PM Kalwit S <sk...@gmail.com> 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 from the monopolies of
>>>> the provider companies, start focusing on stable releases, and let other
>>>> companies make their enhancements to meet their requirements, and
>>>> experienced contributors or Pulsar creators should be active to prevent
>>>> unfairness in the community.
>>>>
>>>> On Tue, Mar 5, 2024 at 3:31 PM Kalwit S <sk...@gmail.com> wrote:
>>>>
>>>>> Congratulations.!
>>>>>
>>>>>
>>>>> On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org>
>>> wrote:
>>>>>
>>>>>> The Apache Pulsar Project Management Committee (PMC) has invited
>>>>>> Asaf Mesika https://github.com/asafm to become a committer and we
>>>>>> are pleased to announce that he has accepted.
>>>>>>
>>>>>> Welcome and Congratulations, Asaf Mesika!
>>>>>>
>>>>>> Please join us in congratulating and welcoming Asaf onboard!
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Lari Hotari
>>>>>> on behalf of the Pulsar PMC
>>>>>>
>>>>>
>>>>
>>>
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Lari Hotari <lh...@apache.org>.
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 <eo...@gmail.com> wrote:
>
> Kalwit,
> All the committers are invited by the PMC, you can reach out to
> private@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 <ma...@gmail.com> 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
> > <ma...@gmail.com>
> >
> >
> > On Tue, Mar 5, 2024 at 7:22 PM Kalwit S <sk...@gmail.com> 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 from the monopolies of
> > > the provider companies, start focusing on stable releases, and let other
> > > companies make their enhancements to meet their requirements, and
> > > experienced contributors or Pulsar creators should be active to prevent
> > > unfairness in the community.
> > >
> > > On Tue, Mar 5, 2024 at 3:31 PM Kalwit S <sk...@gmail.com> wrote:
> > >
> > > > Congratulations.!
> > > >
> > > >
> > > > On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org>
> > wrote:
> > > >
> > > >> The Apache Pulsar Project Management Committee (PMC) has invited
> > > >> Asaf Mesika https://github.com/asafm to become a committer and we
> > > >> are pleased to announce that he has accepted.
> > > >>
> > > >> Welcome and Congratulations, Asaf Mesika!
> > > >>
> > > >> Please join us in congratulating and welcoming Asaf onboard!
> > > >>
> > > >> Best Regards,
> > > >>
> > > >> Lari Hotari
> > > >> on behalf of the Pulsar PMC
> > > >>
> > > >
> > >
> >
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Dave Fisher <wa...@apache.org>.
> On Mar 6, 2024, at 2:31 AM, Enrico Olivelli <eo...@gmail.com> wrote:
>
> Kalwit,
> All the committers are invited by the PMC, you can reach out to
> private@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 <http://lists.apache.org/> .
Alternatively, please provide a list of examples with links to the PMC via an email to private@pulsar.apache.org <ma...@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 <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 <ma...@gmail.com> 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
>> <ma...@gmail.com>
>>
>>
>> On Tue, Mar 5, 2024 at 7:22 PM Kalwit S <sk...@gmail.com> 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 from the monopolies of
>>> the provider companies, start focusing on stable releases, and let other
>>> companies make their enhancements to meet their requirements, and
>>> experienced contributors or Pulsar creators should be active to prevent
>>> unfairness in the community.
>>>
>>> On Tue, Mar 5, 2024 at 3:31 PM Kalwit S <sk...@gmail.com> wrote:
>>>
>>>> Congratulations.!
>>>>
>>>>
>>>> On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org>
>> wrote:
>>>>
>>>>> The Apache Pulsar Project Management Committee (PMC) has invited
>>>>> Asaf Mesika https://github.com/asafm to become a committer and we
>>>>> are pleased to announce that he has accepted.
>>>>>
>>>>> Welcome and Congratulations, Asaf Mesika!
>>>>>
>>>>> Please join us in congratulating and welcoming Asaf onboard!
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Lari Hotari
>>>>> on behalf of the Pulsar PMC
>>>>>
>>>>
>>>
>>
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Enrico Olivelli <eo...@gmail.com>.
Kalwit,
All the committers are invited by the PMC, you can reach out to
private@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 <ma...@gmail.com> 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
> <ma...@gmail.com>
>
>
> On Tue, Mar 5, 2024 at 7:22 PM Kalwit S <sk...@gmail.com> 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 from the monopolies of
> > the provider companies, start focusing on stable releases, and let other
> > companies make their enhancements to meet their requirements, and
> > experienced contributors or Pulsar creators should be active to prevent
> > unfairness in the community.
> >
> > On Tue, Mar 5, 2024 at 3:31 PM Kalwit S <sk...@gmail.com> wrote:
> >
> > > Congratulations.!
> > >
> > >
> > > On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org>
> wrote:
> > >
> > >> The Apache Pulsar Project Management Committee (PMC) has invited
> > >> Asaf Mesika https://github.com/asafm to become a committer and we
> > >> are pleased to announce that he has accepted.
> > >>
> > >> Welcome and Congratulations, Asaf Mesika!
> > >>
> > >> Please join us in congratulating and welcoming Asaf onboard!
> > >>
> > >> Best Regards,
> > >>
> > >> Lari Hotari
> > >> on behalf of the Pulsar PMC
> > >>
> > >
> >
>
Re: (Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Matteo Merli <ma...@gmail.com>.
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
<ma...@gmail.com>
On Tue, Mar 5, 2024 at 7:22 PM Kalwit S <sk...@gmail.com> 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 from the monopolies of
> the provider companies, start focusing on stable releases, and let other
> companies make their enhancements to meet their requirements, and
> experienced contributors or Pulsar creators should be active to prevent
> unfairness in the community.
>
> On Tue, Mar 5, 2024 at 3:31 PM Kalwit S <sk...@gmail.com> wrote:
>
> > Congratulations.!
> >
> >
> > On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org> wrote:
> >
> >> The Apache Pulsar Project Management Committee (PMC) has invited
> >> Asaf Mesika https://github.com/asafm to become a committer and we
> >> are pleased to announce that he has accepted.
> >>
> >> Welcome and Congratulations, Asaf Mesika!
> >>
> >> Please join us in congratulating and welcoming Asaf onboard!
> >>
> >> Best Regards,
> >>
> >> Lari Hotari
> >> on behalf of the Pulsar PMC
> >>
> >
>
(Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika
Posted by Kalwit S <sk...@gmail.com>.
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 from the monopolies of
the provider companies, start focusing on stable releases, and let other
companies make their enhancements to meet their requirements, and
experienced contributors or Pulsar creators should be active to prevent
unfairness in the community.
On Tue, Mar 5, 2024 at 3:31 PM Kalwit S <sk...@gmail.com> wrote:
> Congratulations.!
>
>
> On Tue, Feb 20, 2024 at 8:50 AM Lari Hotari <lh...@apache.org> wrote:
>
>> The Apache Pulsar Project Management Committee (PMC) has invited
>> Asaf Mesika https://github.com/asafm to become a committer and we
>> are pleased to announce that he has accepted.
>>
>> Welcome and Congratulations, Asaf Mesika!
>>
>> Please join us in congratulating and welcoming Asaf onboard!
>>
>> Best Regards,
>>
>> Lari Hotari
>> on behalf of the Pulsar PMC
>>
>