From the peanut gallery. > On Feb 26, 2025, at 12:56 AM, Lari Hotari <lhot...@apache.org> wrote: > > On Wed, 26 Feb 2025 at 09:47, Yunze Xu <x...@apache.org > <mailto:x...@apache.org>> wrote: >> >> Creating a PIP could emphasize that new configs are added and explain >> why these configs are introduced. While with a regular PR, especially >> for many recent PRs that have thousands lines of changes, the >> configuration changes are easy to be ignored. Your question can be >> applied for all changes required by a PIP: what's the problem for >> changes to metrics, wire protocol APIs to users? > > I agree that's a fair point. PIPs might not be the best way to capture > the purpose of each configuration setting and when they are added. In > many bug fix cases, a PIP was added long ago, but configurables are > added later when it's noticed that fixing a bug requires a different > solution which introduces a new configurable setting.
If a PIP introduces a bug that then later requires a new configurable setting to fix that looks like the PIP is not well thought out. One hopes that the new configurables do not require setting to keep the old, expected behavior. IMO PIPs should be tested for performance and never regress from the standard configuration. BTW - Huntr is now a podling in the Incubator as Apache Otava, perhaps this can be incorporated into Pulsar CI? Best, Dave
