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 <x...@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 <w...@apache.org> wrote: > > > > > > > > > On Mar 6, 2024, at 10:01 PM, Kalwit S <skalwit...@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 > > > > > >
