I second everything Yunze said. Just glance over the amount of configuration Pulsar has - it's almost a book.
Configuration and metrics are basically the public facing side of Pulsar. We want Pulsar to be easy to use , for it to be an awesome developer experience. It starts by making sure we discuss - not months - short discussion - on the added metrics or configuration. Is the name ok? Have you added documentation for it? What does it reflect? Must we have it? Yes we can do it in PRs, but since public API is crucial, a PIP requires 3 votes, thus 3 people to say it's ok. https://github.com/apache/pulsar/blob/master/wiki/proposals/PIP.md does state metrics or public API mandate a PIP. Should we add config there to make it more explicit? On Fri, Apr 28, 2023 at 7:07 AM Yunze Xu <y...@streamnative.io.invalid> wrote: > 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 > > > > > > > >
