Thanks for the KIP!
+1 (binding)
Best,
Bruno
On 11/3/23 7:55 AM, Chris Egerton wrote:
+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
