+1 (binding) FWIW, I agree that this change should require a KIP. Gating upgrades of visibility from private or package-private to protected may be cumbersome, but it comes with the expectation that downgrades in visibility for those same classes/methods will also be gated behind a KIP, which is IMO clearly warranted considering the backwards compatibility implications of taking, e.g., a protected constructor and turning it private.
Cheers, Chris On Fri, Nov 3, 2023, 00:55 Sophie Blee-Goldman <sop...@responsive.dev> wrote: > Hey all, > > This is a trivial one-liner change that it was determined should go through > a KIP during the PR review process (see this thread > <https://github.com/apache/kafka/pull/14681#discussion_r1378591228> for > context). Since the change itself was already reviewed and approved I'm > skipping the discussion thread and bringing it to a vote right away, but of > course I'm open to feedback and can create a discussion thread if there is > need for it. > > The change itself is simply adding the `protected` modifier to the > ProducerConfig constructor that allows for silencing the config logging. > This just brings the ProducerConfig in alignment with the other client > configs, all of which already had this constructor as protected. > > KIP: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-998%3A+Give+ProducerConfig%28props%2C+doLog%29+constructor+protected+access > PR: https://github.com/apache/kafka/pull/14681 > > Thanks! > Sophie >
