The problem is not related to whether the patch is simple. It is, adding configurations were very casual in the past few years. Let's look at how many configurations we have from a discussion [1] I started a few months ago.
Adding a configuration is simple, removing it is hard. Most of these configurations are never touched. They were added just because the authors think it's flexible. Let's take a recent PR [2] as example, this PR skips splitting bundles when there is one broker. However, if the author tried to make it configurable and added a config to determine whether to do that. Then, a new config that might never be touched would be added. What's worse, a new config can be applied to the namespace level of topic level policy. More ridiculously, nearly every if statement could bring a new config. To make the Pulsar community grow fast, new contributors can contribute many PRs by adding this and that new configs. BUT, IS IT REALLY GOOD FOR COMMUNITY? The motivation of requiring a PIP for a new configuration is to notify more developers and record the new configuration in the GH issue. > but stopped making progress, only being told an pip is needed. It's the contributor's responsibility to make progress once he's told that a PIP is required. I think pushing the patch without any discussion is bad. It's reasonable for contributors to ask why the PIP is needed, what is the PIP. But it's not reasonable to just ignore the comment and just go away. [1] https://lists.apache.org/thread/j23ny19opmp8jww57gwk7g27b5dvl0ot [2] https://github.com/apache/pulsar/pull/20190 Thanks, Yunze On Fri, Apr 28, 2023 at 11:03 AM lifepuzzlefun <wjl_is_...@163.com> wrote: > > Totally agree. I have seen some patches with little change worth to do, but > stopped making progress, only being told an pip is needed. > I think if we have one fast-path for notice small changes like metrics or > configuration. > > > some pip to add configuration is also simple enough. like just add an > configuration and set the parameter. > contribution will be easy and the separation of different kinds of pip is > helpful for those who only what to know the feature change. > > > also i think an guide is needed to tell people which kind of patch need an > pip, and what should he/she do to make pip making progress. > > > > On 2023/04/28 01:41:09 Rajan Dhabalia wrote: > > Hi, > > > > Thank you Mattison for starting this thread because I am feeling some of > > the community members are making new contributors' life difficult and > > trying to enforce rules which were never discussed and discourage them from > > contributing to Pulsar. I really don't want to see the Pulsar community > > become like Confluent but the Pulsar community should welcome and encourage > > contributors so, we can grow the Pulsar community, If we help and > > encourage companies to contribute for their requirements then we can > > increase the Pulsar adoption. > > For example: our PIP requirement : > > https://github.com/apache/pulsar/blob/master/wiki/proposals/PIP.md doesn't > > talk about anything specific about config changes but that PR was blocked > > because of undocumented reasons. There are many such PRs that might have > > merged but it would not be fair to discourage new contributors by giving > > undocumented and invalid reasons. > > So, let's help and encourage community and new contributors so we can > > increase Pulsar adoption across the industry which should help everyone to > > grow together. > > > > Thanks, > > Rajan > > > > > > On Thu, Apr 27, 2023 at 6:22 PM <ma...@gmail.com> wrote: > > > > > > > > Hi, All > > > > > > I've got two questions want to discuss with you guys. > > > > > > 1. I am wondering if we should draft PIP for small metrics changes, e.g: > > > https://github.com/apache/pulsar/pull/20147 > > > 2. We haven't declear we should draft a PIP for configuration changes. > > > why? Refer to: > > > https://github.com/apache/pulsar/blob/master/wiki/proposals/PIP.md > > > > > > > > > I want to discuss with you all to come to a conclusion within the > > > community, thanks a lot! > > > > > > Best, > > > Mattison > > > > >
