You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2022/12/07 03:09:20 UTC

[GitHub] [pulsar] codelipenghui commented on pull request #18663: [improve][admin,broker] Add option to unloadNamespaceBundle with bundle Affinity broker url

codelipenghui commented on PR #18663:
URL: https://github.com/apache/pulsar/pull/18663#issuecomment-1340313375

   > @codelipenghui I don't think this will require PIP as it's part of adding a flag in admin API. There are a large number of PRs which must have gone through PIP with similar changes but merge without any explanation. let me give you few examples
   https://github.com/apache/pulsar/pull/16167
   https://github.com/apache/pulsar/pull/14680
   https://github.com/apache/pulsar/pull/12136
   https://github.com/apache/pulsar/pull/13938
   
   > also PR which breaks backward compatibility https://github.com/apache/pulsar/pull/10601 was merged without any concerns. 
   I have many such examples where I see practice by the specific community to discourage people from their contribution and delay their efforts. I would strongly discourage such destructive practices. 
   There are such bad practices going on in the community and I have many examples. Please let us know if you have any concerns with the PR by adding an option flag if not then you should not BLOCK the PR unnecessarily as it will start -ve and destructive practice in the community and we didn't open source Pulsar for such things.
   
   Sorry for the late response.
   
   Yes, this is why I think it's better to have a proposal to avoid we will not introduce any API changes without a proposal in the future. I agree there are many changes to admin APIs without proposals/discussions. But we are on the wrong way, right? More and more people are starting to use Pulsar. We should be more careful about the API changes than ever. 
   
   I want to say there have been many CLI, and admin API changes without proposals before. If you just don't think we should not start with this PR(proposal required). It's ok for me. I think I should start a discussion under the mailing list first, not block this PR under an uncleared rule. I see all the PRs you provided are from StreamNative's engineers.  Please don't think I mean to facilitate StreamNative engineers. 
   
   Here is an example of a proposal that is not required for new metrics. 
   
   https://github.com/apache/pulsar/issues/18319
   https://github.com/apache/pulsar/issues/18560
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org