RE: [VOTE] KIP-1052: Enable warmup in producer performance test

[Chia-Ping Tsai]

Oh, I apologize for not enabling idempotence on my email producer... :(

On 2024/09/04 22:20:15 "Welch, Matt" wrote:
> Hi Kafka devs, 
> 
> Bumping this VOTE thread again for visibility.
> 
> Thanks,
> Matt
> 
> -Original Message-
> From: Welch, Matt  
> Sent: Friday, August 23, 2024 4:26 PM
> To: dev@kafka.apache.org
> Subject: RE: [VOTE] KIP-1052: Enable warmup in producer performance test
> 
> Hi Kafka devs, 
> 
> Bumping this VOTE thread for visibility.
> 
> Thanks,
> Matt
> 
> -Original Message-
> From: Federico Valeri 
> Sent: Monday, August 19, 2024 12:38 AM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-1052: Enable warmup in producer performance test
> 
> Hi Matt, +1 (non binding) from me. Thanks!
> 
> Just a suggestion: I think that the following output line does not add much 
> value and could be removed.
> 
> "Warmup first 10 records. Steady-state results will print after the 
> complete-test summary."
> 
> On Wed, Aug 14, 2024 at 8:06 PM Welch, Matt  wrote:
> >
> >
> > Hi all,
> >
> > It seems discussion has been quiet for a couple of weeks so I'd like 
> > to call a vote on KIP-1052 
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1052%3A+Enable+w
> > armup+in+producer+performance+test
> >
> > Thanks,
> > Matt Welch
> >
> 

RE: [VOTE] KIP-1052: Enable warmup in producer performance test

[Chia-Ping Tsai]

hi Matt

Apologies for the delayed response. I completely agree that ProducerPerformance 
should separate warmup statistics from steady-state metrics. Overall +1, but I 
have a small question:

Have you considered implementing an explicit check for warmup instead of 
relying on sending a set number of records? My concern is that users may not 
know how many records are necessary to complete the warmup. Rather than relying 
on a rule of thumb, ProducerPerformance could check the metadata and node 
latency (via metrics) to ensure that the node information (such as connection, 
DNS, and metadata) is ready. 

In summary, this approach introduces a flag called enable-warmup instead of 
using warmup-records. The advantage is that users no longer need to specify the 
number of warmup records. When the flag is enabled, ProducerPerformance will 
continue sending warmup records until the node information is fully ready.

Best,
Chia-Ping

On 2024/09/04 22:20:15 "Welch, Matt" wrote:
> Hi Kafka devs, 
> 
> Bumping this VOTE thread again for visibility.
> 
> Thanks,
> Matt
> 
> -Original Message-
> From: Welch, Matt  
> Sent: Friday, August 23, 2024 4:26 PM
> To: dev@kafka.apache.org
> Subject: RE: [VOTE] KIP-1052: Enable warmup in producer performance test
> 
> Hi Kafka devs, 
> 
> Bumping this VOTE thread for visibility.
> 
> Thanks,
> Matt
> 
> -Original Message-
> From: Federico Valeri 
> Sent: Monday, August 19, 2024 12:38 AM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-1052: Enable warmup in producer performance test
> 
> Hi Matt, +1 (non binding) from me. Thanks!
> 
> Just a suggestion: I think that the following output line does not add much 
> value and could be removed.
> 
> "Warmup first 10 records. Steady-state results will print after the 
> complete-test summary."
> 
> On Wed, Aug 14, 2024 at 8:06 PM Welch, Matt  wrote:
> >
> >
> > Hi all,
> >
> > It seems discussion has been quiet for a couple of weeks so I'd like 
> > to call a vote on KIP-1052 
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1052%3A+Enable+w
> > armup+in+producer+performance+test
> >
> > Thanks,
> > Matt Welch
> >
> 

RE: [VOTE] KIP-1052: Enable warmup in producer performance test

[Chia-Ping Tsai]

hi Matt

Apologies for the delayed response. I completely agree that ProducerPerformance 
should separate warmup statistics from steady-state metrics. Overall +1, but I 
have a small question:

Have you considered implementing an explicit check for warmup instead of 
relying on sending a set number of records? My concern is that users may not 
know how many records are necessary to complete the warmup. Rather than relying 
on a rule of thumb, ProducerPerformance could check the metadata and node 
latency (via metrics) to ensure that the node information (such as connection, 
DNS, and metadata) is ready. 

In summary, this approach introduces a flag called enable-warmup instead of 
using warmup-records. The advantage is that users no longer need to specify the 
number of warmup records. When the flag is enabled, ProducerPerformance will 
continue sending warmup records until the node information is fully ready.

Best,
Chia-Ping

On 2024/09/04 22:20:15 "Welch, Matt" wrote:
> Hi Kafka devs, 
> 
> Bumping this VOTE thread again for visibility.
> 
> Thanks,
> Matt
> 
> -Original Message-
> From: Welch, Matt  
> Sent: Friday, August 23, 2024 4:26 PM
> To: dev@kafka.apache.org
> Subject: RE: [VOTE] KIP-1052: Enable warmup in producer performance test
> 
> Hi Kafka devs, 
> 
> Bumping this VOTE thread for visibility.
> 
> Thanks,
> Matt
> 
> -Original Message-
> From: Federico Valeri 
> Sent: Monday, August 19, 2024 12:38 AM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-1052: Enable warmup in producer performance test
> 
> Hi Matt, +1 (non binding) from me. Thanks!
> 
> Just a suggestion: I think that the following output line does not add much 
> value and could be removed.
> 
> "Warmup first 10 records. Steady-state results will print after the 
> complete-test summary."
> 
> On Wed, Aug 14, 2024 at 8:06 PM Welch, Matt  wrote:
> >
> >
> > Hi all,
> >
> > It seems discussion has been quiet for a couple of weeks so I'd like 
> > to call a vote on KIP-1052 
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1052%3A+Enable+w
> > armup+in+producer+performance+test
> >
> > Thanks,
> > Matt Welch
> >
> 

RE: [VOTE] KIP-1052: Enable warmup in producer performance test

[Chia-Ping Tsai]

hi Matt

Apologies for the delayed response. I completely agree that ProducerPerformance 
should separate warmup statistics from steady-state metrics. Overall +1, but I 
have a small question:

Have you considered implementing an explicit check for warmup instead of 
relying on sending a set number of records? My concern is that users may not 
know how many records are necessary to complete the warmup. Rather than relying 
on a rule of thumb, ProducerPerformance could check the metadata and node 
latency (via metrics) to ensure that the node information (such as connection, 
DNS, and metadata) is ready. 

In summary, this approach introduces a flag called enable-warmup instead of 
using warmup-records. The advantage is that users no longer need to specify the 
number of warmup records. When the flag is enabled, ProducerPerformance will 
continue sending warmup records until the node information is fully ready.

Best,
Chia-Ping

On 2024/09/04 22:20:15 "Welch, Matt" wrote:
> Hi Kafka devs, 
> 
> Bumping this VOTE thread again for visibility.
> 
> Thanks,
> Matt
> 
> -Original Message-
> From: Welch, Matt  
> Sent: Friday, August 23, 2024 4:26 PM
> To: dev@kafka.apache.org
> Subject: RE: [VOTE] KIP-1052: Enable warmup in producer performance test
> 
> Hi Kafka devs, 
> 
> Bumping this VOTE thread for visibility.
> 
> Thanks,
> Matt
> 
> -Original Message-
> From: Federico Valeri 
> Sent: Monday, August 19, 2024 12:38 AM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-1052: Enable warmup in producer performance test
> 
> Hi Matt, +1 (non binding) from me. Thanks!
> 
> Just a suggestion: I think that the following output line does not add much 
> value and could be removed.
> 
> "Warmup first 10 records. Steady-state results will print after the 
> complete-test summary."
> 
> On Wed, Aug 14, 2024 at 8:06 PM Welch, Matt  wrote:
> >
> >
> > Hi all,
> >
> > It seems discussion has been quiet for a couple of weeks so I'd like 
> > to call a vote on KIP-1052 
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1052%3A+Enable+w
> > armup+in+producer+performance+test
> >
> > Thanks,
> > Matt Welch
> >
> 

Re: [VOTE] KIP-1052: Enable warmup in producer performance test

[David Jacot]

Hi Matt,

Thanks for the KIP. I have a minor nit. Could you please explicitly mention
the new command line argument in the public interfaces section?

Otherwise, I am +1 (binding).

Best,
David


On Tue, Sep 24, 2024 at 1:48 AM Welch, Matt  wrote:

> Hi Kafka Devs,
>
> Bumping VOTE thread again for visibility.
>
> Thanks to Justine and Federico who've cast their votes on KIP-1052!
> Current vote tally:
> Justine Olshan: +1 (binding)
> Federico Valeri: +1 (non-binding)
>
> Let's keep it going and complete this vote!
>
> Thanks,
> Matt
>
> -Original Message-
> From: Justine Olshan 
> Sent: Wednesday, September 11, 2024 4:36 PM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-1052: Enable warmup in producer performance test
>
> +1 (binding) from me.
>
> Thanks,
> Justine
>
> On Wed, Sep 4, 2024 at 3:22 PM Welch, Matt  wrote:
>
> > Hi Kafka devs,
> >
> > Bumping this VOTE thread again for visibility.
> >
> > Thanks,
> > Matt
> >
> > -Original Message-
> > From: Welch, Matt 
> > Sent: Friday, August 23, 2024 4:26 PM
> > To: dev@kafka.apache.org
> > Subject: RE: [VOTE] KIP-1052: Enable warmup in producer performance
> > test
> >
> > Hi Kafka devs,
> >
> > Bumping this VOTE thread for visibility.
> >
> > Thanks,
> > Matt
> >
> > -Original Message-
> > From: Federico Valeri 
> > Sent: Monday, August 19, 2024 12:38 AM
> > To: dev@kafka.apache.org
> > Subject: Re: [VOTE] KIP-1052: Enable warmup in producer performance
> > test
> >
> > Hi Matt, +1 (non binding) from me. Thanks!
> >
> > Just a suggestion: I think that the following output line does not add
> > much value and could be removed.
> >
> > "Warmup first 10 records. Steady-state results will print after
> > the complete-test summary."
> >
> > On Wed, Aug 14, 2024 at 8:06 PM Welch, Matt 
> wrote:
> > >
> > >
> > > Hi all,
> > >
> > > It seems discussion has been quiet for a couple of weeks so I'd like
> > > to call a vote on KIP-1052
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1052%3A+Enable
> > > +w
> > > armup+in+producer+performance+test
> > >
> > > Thanks,
> > > Matt Welch
> > >
> >
>

RE: [VOTE] KIP-1052: Enable warmup in producer performance test

[Welch, Matt]

Hi Kafka Devs, 

Bumping VOTE thread again for visibility.

Thanks to Justine and Federico who've cast their votes on KIP-1052!
Current vote tally:
Justine Olshan: +1 (binding)
Federico Valeri: +1 (non-binding)

Let's keep it going and complete this vote!

Thanks,
Matt

-Original Message-
From: Justine Olshan  
Sent: Wednesday, September 11, 2024 4:36 PM
To: dev@kafka.apache.org
Subject: Re: [VOTE] KIP-1052: Enable warmup in producer performance test

+1 (binding) from me.

Thanks,
Justine

On Wed, Sep 4, 2024 at 3:22 PM Welch, Matt  wrote:

> Hi Kafka devs,
>
> Bumping this VOTE thread again for visibility.
>
> Thanks,
> Matt
>
> -Original Message-
> From: Welch, Matt 
> Sent: Friday, August 23, 2024 4:26 PM
> To: dev@kafka.apache.org
> Subject: RE: [VOTE] KIP-1052: Enable warmup in producer performance 
> test
>
> Hi Kafka devs,
>
> Bumping this VOTE thread for visibility.
>
> Thanks,
> Matt
>
> -Original Message-
> From: Federico Valeri 
> Sent: Monday, August 19, 2024 12:38 AM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-1052: Enable warmup in producer performance 
> test
>
> Hi Matt, +1 (non binding) from me. Thanks!
>
> Just a suggestion: I think that the following output line does not add 
> much value and could be removed.
>
> "Warmup first 10 records. Steady-state results will print after 
> the complete-test summary."
>
> On Wed, Aug 14, 2024 at 8:06 PM Welch, Matt  wrote:
> >
> >
> > Hi all,
> >
> > It seems discussion has been quiet for a couple of weeks so I'd like 
> > to call a vote on KIP-1052 
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1052%3A+Enable
> > +w
> > armup+in+producer+performance+test
> >
> > Thanks,
> > Matt Welch
> >
>

Re: [VOTE] KIP-1064 - Upgrade slf4j to 2.x

[Muralidhar Basani]

Hi,

I wanted to gently follow up on this thread in case anyone has any thoughts
or would like to take a look.

Thanks,
Murali

On Mon, Sep 16, 2024 at 10:23 AM Muralidhar Basani <
muralidhar.bas...@aiven.io> wrote:

> Thanks Chia.
>
> I have updated KIP with this quote, in the migration plan section.
>
> Thanks,
> Murali
>
> On Sun, Sep 15, 2024 at 3:30 PM Chia-Ping Tsai  wrote:
>
>>
>> > Muralidhar Basani  於 2024年9月15日
>> 晚上9:02 寫道：
>> >
>> > With this, I think, users don't have to make any explicit changes in
>> their
>> > code, if their provider is reload4j. And if it's a different provider
>> (like
>> > logback, log4j), they would have to upgrade that to match it with slf4j.
>>
>> If upgrading the matched provider is the only explicit change and we
>> expect users have responsibility to keep consistent version when using
>> other providers , could we write it down to the KIP?
>>
>> That means we will update slf4j without KIP in the future except for
>> specific reason.
>>
>> Best,
>> Chia-Ping
>
>

[VOTE] KIP-1073: Return fenced brokers in DescribeCluster response

[Gantigmaa Selenge]

Hi everyone,

I would like to start voting for KIP-1073 that extends DescribeCluster API
to optionally return fenced brokers in the response.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-1073%3A+Return+fenced+brokers+in+DescribeCluster+response

Thanks.
Gantigmaa

Re: [VOTE] KIP-1043: Administration of groups

[Apoorv Mittal]

Hi Andrew,
Thanks for the KIP, this will be very helpful.

+1 (non-binding)

Regards,
Apoorv Mittal


On Mon, Sep 23, 2024 at 11:38 AM Lianet M.  wrote:

> Hello Andrew,
>
> Thanks for the KIP.
>
> +1 (binding)
>
> Lianet
>
> On Mon, Sep 23, 2024, 3:37 a.m. Lucas Brutschy
>  wrote:
>
> > Hi Andrew,
> >
> > thanks for the KIP!
> >
> > +1 (binding)
> >
> > Cheers,
> > Lucas
> >
> > On Mon, Sep 23, 2024 at 9:27 AM Andrew Schofield
> >  wrote:
> > >
> > > Hi,
> > > I would like to start voting for KIP-1043: Administration of groups.
> > This KIP enhances the command-line tools to make it easier to administer
> > groups on clusters with a variety of types of groups.
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1043%3A+Administration+of+groups
> > >
> > > Thanks.
> > > Andrew
> >
>

Re: [VOTE] KIP-1043: Administration of groups

[Lianet M.]

Hello Andrew,

Thanks for the KIP.

+1 (binding)

Lianet

On Mon, Sep 23, 2024, 3:37 a.m. Lucas Brutschy
 wrote:

> Hi Andrew,
>
> thanks for the KIP!
>
> +1 (binding)
>
> Cheers,
> Lucas
>
> On Mon, Sep 23, 2024 at 9:27 AM Andrew Schofield
>  wrote:
> >
> > Hi,
> > I would like to start voting for KIP-1043: Administration of groups.
> This KIP enhances the command-line tools to make it easier to administer
> groups on clusters with a variety of types of groups.
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1043%3A+Administration+of+groups
> >
> > Thanks.
> > Andrew
>

RE: [VOTE] KIP-1034: Dead letter queue in Kafka Streams

[Sebastien Viale]

Hi everyone,

Just a quick reminder that the vote for KIP-1034 is still open.
Thank you all for your participation!

Best regards,
Damien Sebastien and Loic



De : Sebastien Viale 
Envoyé : mercredi 11 septembre 2024 09:26
À : dev 
Objet : Marketing: [VOTE] KIP-1034: Dead letter queue in Kafka Streams

Hi all,

We would like to start a vote for KIP-1034: Dead letter queue in Kafka 
Streams<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1034%3A+Dead+letter+queue+in+Kafka+Streams<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1034%3A+Dead+letter+queue+in+Kafka+Streams>>

The KIP is available on 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1034%3A+Dead+letter+queue+in+Kafka+Streams<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1034%3A+Dead+letter+queue+in+Kafka+Streams>

If you have any suggestions or feedback, feel free to participate to the 
discussion thread:
https://lists.apache.org/thread/1nhhsrogmmv15o7mk9nj4kvkb5k2bx9s<https://lists.apache.org/thread/1nhhsrogmmv15o7mk9nj4kvkb5k2bx9s>

Best regards,

Damien Sebastien and Loic


This email was screened for spam and malicious content but exercise caution 
anyway.

Re: [VOTE] KIP-1043: Administration of groups

[Lucas Brutschy]

Hi Andrew,

thanks for the KIP!

+1 (binding)

Cheers,
Lucas

On Mon, Sep 23, 2024 at 9:27 AM Andrew Schofield
 wrote:
>
> Hi,
> I would like to start voting for KIP-1043: Administration of groups. This KIP 
> enhances the command-line tools to make it easier to administer groups on 
> clusters with a variety of types of groups.
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1043%3A+Administration+of+groups
>
> Thanks.
> Andrew

[VOTE] KIP-1043: Administration of groups

[Andrew Schofield]

Hi,
I would like to start voting for KIP-1043: Administration of groups. This KIP 
enhances the command-line tools to make it easier to administer groups on 
clusters with a variety of types of groups.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-1043%3A+Administration+of+groups

Thanks.
Andrew

Re: [VOTE] KIP-1074: Allow the replication of user internal topics

[Patrik Marton]

Hi All,

Thank you so much for the votes so far! We're just one vote away from
reaching our goal for the KIP. I’d really appreciate it if you could take a
moment to vote or share your thoughts!

Thanks,
Patrik

On Mon, Sep 9, 2024 at 4:20 PM Chris Egerton 
wrote:

> Hi Patrik,
>
> Sorry for the delay, I've been on PTO. LGTM! +1 (binding)
>
> Cheers,
>
> Chris
>
> On Tue, Sep 3, 2024 at 5:10 AM Viktor Somogyi-Vass
>  wrote:
>
> > Hi Patrik,
> >
> > Thanks for working on this. +1 from me (binding).
> >
> > Best,
> > Viktor
> >
> > On Wed, Aug 28, 2024 at 1:34 PM Patrik Marton
>  > >
> > wrote:
> >
> > > Hi all,
> > >
> > > As the proposal is finalized, and there was no new feedback in the past
> > > week, I would like to open voting for KIP-1074
> > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1074%3A+Allow+the+replication+of+user+internal+topics
> > > >
> > > .
> > >
> > > Please vote / let me know your thoughts.
> > >
> > > Thanks,
> > > Patrik
> > >
> >
>

Re: [VOTE] 3.9.0 RC0

[Colin McCabe]

Hi all,

Thanks, everyone who took a look at RC0. Let's sink this RC since we discovered 
several problems:

- the current error message for KAFKA-17543 is unclear (fixed by PR #17210)
- docs/ops.html has not been updated for KIP-853
- some maven artifacts are missing
- the documentation generation is slightly wonky

I'll create a new RC in a day or two that will fix these issues.

best,
Colin

On Wed, Sep 18, 2024, at 07:21, Jakub Scholz wrote:
> One more thing I noticed - the documentation at
> https://kafka.apache.org/39/documentation.html#brokerconfigs seems to be
> missing all the configuration options for brokers, producers, consumers etc.
>
> Not sure if that is normal for RCs or if this is some bug in the docs
> generator.
>
> Thanks & Regards
> Jakub
>
> On Wed, Sep 18, 2024 at 5:07 AM Colin McCabe  wrote:
>
>> Hello Kafka users, developers and client-developers,
>>
>>
>>
>> This is the first candidate for release of Apache Kafka 3.9.0.
>>
>>
>> - This is a major release, the final one in the 3.x line. (There may of
>> course be other minor releases in this line, such as 3.9.1.)
>> - Tiered storage will be considered production-ready in this release.
>> - This will be the final major release to feature the deprecated ZooKeeper
>> mode.
>>
>> This release includes the following KIPs:
>> - KIP-853: Support dynamically changing KRaft controller membership
>> - KIP-1057: Add remote log metadata flag to the dump log tool
>> - KIP-1049: Add config log.summary.interval.ms to Kafka Streams
>> - KIP-1040: Improve handling of nullable values in InsertField,
>> ExtractField, and other transformations
>> - KIP-1031: Control offset translation in MirrorSourceConnector
>> - KIP-1033: Add Kafka Streams exception handler for exceptions occurring
>> during processing
>> - KIP-1017: Health check endpoint for Kafka Connect
>> - KIP-1025: Optionally URL-encode clientID and clientSecret in
>> authorization header
>> - KIP-1005: Expose EarliestLocalOffset and TieredOffset
>> - KIP-950: Tiered Storage Disablement
>> - KIP-956: Tiered Storage Quotas
>>
>> Release notes for the 3.9.0 release:
>> https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/RELEASE_NOTES.html
>>
>> *** Please download, test and vote by September 23, 2024.
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> https://kafka.apache.org/KEYS
>>
>> * Release artifacts to be voted upon (source and binary):
>> https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/
>>
>> * Docker release artifacts to be voted upon:
>> apache/kafka:3.9.0-rc0
>> apache/kafka-native:3.9.0-rc0
>>
>> * Maven artifacts to be voted upon:
>> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>>
>> * Javadoc:
>> https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/javadoc/
>>
>> * Documentation:
>> https://kafka.apache.org/39/documentation.html
>>
>> * Protocol:
>> https://kafka.apache.org/39/protocol.html
>>
>> * Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc0 tag:
>> https://github.com/apache/kafka/releases/tag/3.9.0-rc0
>>
>> I've run several successful junit and ducktape builds. While there were
>> some flaky tests, when re-running them, they passed.
>>
>> * Successful Docker Image Github Actions Pipeline for 3.8 branch:
>> Docker Build Test Pipeline (JVM):
>> https://github.com/apache/kafka/actions/runs/10912118987
>> Docker Build Test Pipeline (Native):
>> https://github.com/apache/kafka/actions/runs/10914303515
>>
>> Thanks to everyone who helped with this release candidate, either by
>> contributing code, testing, or documentation.
>>
>> Regards,
>> Colin
>>

Re: [VOTE] KIP-1082: Require Client-Generated IDs over the ConsumerGroupHeartbeat RPC

[Chris Egerton]

Thanks for the KIP! +1 (binding)

On Tue, Sep 17, 2024 at 12:45 PM Andrew Schofield <
andrew_schofield_j...@outlook.com> wrote:

> +1 (non-binding)
>
> 
> From: 吳岱儒 
> Sent: 17 September 2024 04:24
> To: dev@kafka.apache.org 
> Subject: Re: [VOTE] KIP-1082: Require Client-Generated IDs over the
> ConsumerGroupHeartbeat RPC
>
> +1 (non-binding)
>
> Best,
> TaiJuWu
>
> Chia-Ping Tsai  於 2024年9月16日 週一 下午11:41寫道：
>
> > +1 (binding)
> >
> > thanks for reaching out to the corner case.
> >
> > Best,
> > Chia-Ping
> >
> > Kirk True  於 2024年9月16日 週一 下午11:36寫道：
> >
> > > Hi TengYao,
> > >
> > > +1 (non-binding)
> > >
> > > Thanks for all the hard work with the tricky edge cases :)
> > >
> > > Kirk
> > >
> > > > On Sep 16, 2024, at 6:47 AM, TengYao Chi 
> wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > Based on our discussion
> > > > <https://lists.apache.org/thread/vvytypk3l8cvv8yltrckfg6yf7ovd371>
> > > > regarding KIP-1082 <https://cwiki.apache.org/confluence/x/XBDOEg>, I
> > > > believe this KIP is now ready for a vote.
> > > >
> > > > Sincerely,
> > > > TengYao
> > >
> > >
> >
>

Re: [VOTE] 3.9.0 RC0

[Jakub Scholz]

One more thing I noticed - the documentation at
https://kafka.apache.org/39/documentation.html#brokerconfigs seems to be
missing all the configuration options for brokers, producers, consumers etc.

Not sure if that is normal for RCs or if this is some bug in the docs
generator.

Thanks & Regards
Jakub

On Wed, Sep 18, 2024 at 5:07 AM Colin McCabe  wrote:

> Hello Kafka users, developers and client-developers,
>
>
>
> This is the first candidate for release of Apache Kafka 3.9.0.
>
>
> - This is a major release, the final one in the 3.x line. (There may of
> course be other minor releases in this line, such as 3.9.1.)
> - Tiered storage will be considered production-ready in this release.
> - This will be the final major release to feature the deprecated ZooKeeper
> mode.
>
> This release includes the following KIPs:
> - KIP-853: Support dynamically changing KRaft controller membership
> - KIP-1057: Add remote log metadata flag to the dump log tool
> - KIP-1049: Add config log.summary.interval.ms to Kafka Streams
> - KIP-1040: Improve handling of nullable values in InsertField,
> ExtractField, and other transformations
> - KIP-1031: Control offset translation in MirrorSourceConnector
> - KIP-1033: Add Kafka Streams exception handler for exceptions occurring
> during processing
> - KIP-1017: Health check endpoint for Kafka Connect
> - KIP-1025: Optionally URL-encode clientID and clientSecret in
> authorization header
> - KIP-1005: Expose EarliestLocalOffset and TieredOffset
> - KIP-950: Tiered Storage Disablement
> - KIP-956: Tiered Storage Quotas
>
> Release notes for the 3.9.0 release:
> https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/RELEASE_NOTES.html
>
> *** Please download, test and vote by September 23, 2024.
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> https://kafka.apache.org/KEYS
>
> * Release artifacts to be voted upon (source and binary):
> https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/
>
> * Docker release artifacts to be voted upon:
> apache/kafka:3.9.0-rc0
> apache/kafka-native:3.9.0-rc0
>
> * Maven artifacts to be voted upon:
> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>
> * Javadoc:
> https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/javadoc/
>
> * Documentation:
> https://kafka.apache.org/39/documentation.html
>
> * Protocol:
> https://kafka.apache.org/39/protocol.html
>
> * Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc0 tag:
> https://github.com/apache/kafka/releases/tag/3.9.0-rc0
>
> I've run several successful junit and ducktape builds. While there were
> some flaky tests, when re-running them, they passed.
>
> * Successful Docker Image Github Actions Pipeline for 3.8 branch:
> Docker Build Test Pipeline (JVM):
> https://github.com/apache/kafka/actions/runs/10912118987
> Docker Build Test Pipeline (Native):
> https://github.com/apache/kafka/actions/runs/10914303515
>
> Thanks to everyone who helped with this release candidate, either by
> contributing code, testing, or documentation.
>
> Regards,
> Colin
>

Re: [kafka-clients] Re: [VOTE] 3.9.0 RC0

[Colin McCabe]

Hi all,

I think this is my error since I only "closed" one entry, and "dropped" the 
others. Sorry about that. Let me try the Maven upload task again when I'm in 
front of my laptop.

best,
Colin

On Wed, Sep 18, 2024, at 04:37, 'Josep Prat' via kafka-clients wrote:
> I can see the Stream Quickstart ones in the staging repo, but only these.
> When I did the 3.8 release I realized that 
> https://repository.apache.org/#stagingRepositories had 3 different entries 
> (repositories) every time I tried to upload to maven central (1 was kind of 
> faulty with only togdor jar file and no metadata, and the other 2 were for 
> StreamQuickStart jars, and all the other jars). Taking a look there now, I 
> see only the repository for the quickstart is present. Colin, did you happen 
> to see the other repositories as well?
> 
> Best,
> 
> 
> On Wed, Sep 18, 2024 at 11:26 AM Luke Chen  wrote:
>> Same here, no 3.9.0 artifacts in the staging repo.
>> 
>> Thanks.
>> Luke
>> 
>> 
>> On Wed, Sep 18, 2024 at 4:49 PM Jakub Scholz  wrote:
>> 
>> > Hi Colin,
>> >
>> > Thanks for the RC.
>> >
>> > It looks like the Maven artifacts are missing for 3.9.0 in the staging
>> > repo. Are we still waiting for some staging job to complete? Or is that
>> > some CDN issue and I'm the only one not seeing them? Or is that some
>> > general problem?
>> >
>> > Thanks & Regards
>> > Jakub
>> >
>> > On Wed, Sep 18, 2024 at 5:07 AM Colin McCabe  wrote:
>> >
>> > > Hello Kafka users, developers and client-developers,
>> > >
>> > >
>> > >
>> > > This is the first candidate for release of Apache Kafka 3.9.0.
>> > >
>> > >
>> > > - This is a major release, the final one in the 3.x line. (There may of
>> > > course be other minor releases in this line, such as 3.9.1.)
>> > > - Tiered storage will be considered production-ready in this release.
>> > > - This will be the final major release to feature the deprecated
>> > ZooKeeper
>> > > mode.
>> > >
>> > > This release includes the following KIPs:
>> > > - KIP-853: Support dynamically changing KRaft controller membership
>> > > - KIP-1057: Add remote log metadata flag to the dump log tool
>> > > - KIP-1049: Add config log.summary.interval.ms to Kafka Streams
>> > > - KIP-1040: Improve handling of nullable values in InsertField,
>> > > ExtractField, and other transformations
>> > > - KIP-1031: Control offset translation in MirrorSourceConnector
>> > > - KIP-1033: Add Kafka Streams exception handler for exceptions occurring
>> > > during processing
>> > > - KIP-1017: Health check endpoint for Kafka Connect
>> > > - KIP-1025: Optionally URL-encode clientID and clientSecret in
>> > > authorization header
>> > > - KIP-1005: Expose EarliestLocalOffset and TieredOffset
>> > > - KIP-950: Tiered Storage Disablement
>> > > - KIP-956: Tiered Storage Quotas
>> > >
>> > > Release notes for the 3.9.0 release:
>> > > https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/RELEASE_NOTES.html
>> > >
>> > > *** Please download, test and vote by September 23, 2024.
>> > >
>> > > Kafka's KEYS file containing PGP keys we use to sign the release:
>> > > https://kafka.apache.org/KEYS
>> > >
>> > > * Release artifacts to be voted upon (source and binary):
>> > > https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/
>> > >
>> > > * Docker release artifacts to be voted upon:
>> > > apache/kafka:3.9.0-rc0
>> > > apache/kafka-native:3.9.0-rc0
>> > >
>> > > * Maven artifacts to be voted upon:
>> > > https://repository.apache.org/content/groups/staging/org/apache/kafka/
>> > >
>> > > * Javadoc:
>> > > https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/javadoc/
>> > >
>> > > * Documentation:
>> > > https://kafka.apache.org/39/documentation.html
>> > >
>> > > * Protocol:
>> > > https://kafka.apache.org/39/protocol.html
>> > >
>> > > * Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc0 tag:
>> > > https://github.com/apache/kafka/releases/tag/3.9.0-rc0
>> > >
>> > > I've run several successful junit and ducktape builds. While there were
>> > > some 

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[Federico Valeri]

Hey TengYao, no problem, thanks for the KIP. Well done.

On Wed, Sep 18, 2024 at 6:34 AM TengYao Chi  wrote:
>
> Hello Federico
> I'm sorry that I missed your email.
> The ticket used to track future removal has been filed. (KAFKA-17556
> <https://issues.apache.org/jira/browse/KAFKA-17556>)
> Please take a look and sorry for the inconvenience.
>
> Sincerely,
> TengYao
>
>
> TengYao Chi  於 2024年9月18日 週三 下午12:30寫道：
>
> > Hello everyone,
> >
> > The vote is now closed, and the KIP has been accepted with 3 binding +1s
> > from Chia-Ping, Lianet, Justine, as well as 4 non-binding +1 from TaiJu,
> > Federico, Andrew, Kirk.
> >
> > Thank you all for your participation!
> >
> > Sincerely,
> > TengYao
> >
> > Justine Olshan  於 2024年9月17日 週二 下午9:41寫道：
> >
> >> +1 (binding) from me
> >>
> >> Justine
> >>
> >> On Mon, Sep 16, 2024 at 7:36 PM TengYao Chi  wrote:
> >>
> >> > Hi Kirk
> >> > Thanks for pointing out. I have updated the description of KAFKA-17087.
> >> >
> >> > Sincerely,
> >> > TengYao
> >> >
> >> > Kirk True  於 2024年9月16日 週一 下午11:45寫道：
> >> >
> >> > > Hi TengYao,
> >> > >
> >> > > +1 (non-binding).
> >> > >
> >> > > Using KAFKA-17087 to track the actual removal in 5.0 is going to help
> >> > this
> >> > > not fall through the cracks. One minor point is that the description
> >> for
> >> > > the Jira states that "we should deprecate it in 3.9 and then remove it
> >> > from
> >> > > 4.0” which should be "we should deprecate it in 4.0 and then remove it
> >> > from
> >> > > 5.0"
> >> > >
> >> > > Thanks!
> >> > >
> >> > > > On Sep 16, 2024, at 6:54 AM, Lianet M.  wrote:
> >> > > >
> >> > > > Thanks for the update! Looks good to me now.
> >> > > >
> >> > > > +1 (binding)
> >> > > >
> >> > > > Cheers,
> >> > > >
> >> > > > Lianet
> >> > > >
> >> > > > On Mon, Sep 16, 2024 at 9:31 AM TengYao Chi 
> >> > wrote:
> >> > > >
> >> > > >> Hi Lianet,
> >> > > >>
> >> > > >> Thanks for comment.
> >> > > >> It is very helpful and I have applied it to the content of this
> >> KIP.
> >> > > >> Please take a look.
> >> > > >>
> >> > > >> Sincerely,
> >> > > >> TengYao
> >> > > >>
> >> > > >> Lianet M.  於 2024年9月16日 週一 下午7:16寫道：
> >> > > >>
> >> > > >>> Hello TengYao.
> >> > > >>>
> >> > > >>> Thanks for the KIP, nice cleanup. Just one question left. I wonder
> >> > how
> >> > > we
> >> > > >>> make sure that we don't just bring in this KIP, deprecate the arg
> >> and
> >> > > >>> forget about it?. First we could maybe mention in the KIP that is
> >> > with
> >> > > >> the
> >> > > >>> intention of removing the option in 5.0 (just for reference), and
> >> > also
> >> > > >>> create and include here the jira for it already (maybe in the
> >> > > >>> "Compatibility, Deprecation, and Migration Plan" section)?
> >> > > >>>
> >> > > >>> Thanks!
> >> > > >>>
> >> > > >>> Lianet
> >> > > >>>
> >> > > >>> On Mon, Sep 16, 2024 at 1:01 AM TengYao Chi 
> >> > > wrote:
> >> > > >>>
> >> > > >>>> Hello everyone,
> >> > > >>>> I hope this message finds you well.
> >> > > >>>> As the vote has been pending for two weeks, I would like to push
> >> it
> >> > > >>>> manually.
> >> > > >>>>
> >> > > >>>> Thank you for your attention.
> >> > > >>>>
> >> > > >>>> Sincerely,
> >> > > >>>> TengYao
> >> > > >>>>
> >> > > >>>> Andrew Schofield  於 2024年8月27日 週二
> >> > > >> 下午10:20寫道：
> >> > > >>>>
> >> > > >>>>> Thanks for the KIP.
> >> > > >>>>>
> >> > > >>>>> +1 (non-binding)
> >> > > >>>>>
> >> > > >>>>> Andrew
> >> > > >>>>>
> >> > > >>>>>> On 27 Aug 2024, at 10:31, Federico Valeri <
> >> fedeval...@gmail.com>
> >> > > >>>> wrote:
> >> > > >>>>>>
> >> > > >>>>>> +1 non binding
> >> > > >>>>>>
> >> > > >>>>>> Should we also create a Jira to track future removal?
> >> > > >>>>>>
> >> > > >>>>>> On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai <
> >> > > >> chia7...@apache.org
> >> > > >>>>
> >> > > >>>>> wrote:
> >> > > >>>>>>>
> >> > > >>>>>>> +1 (binding)
> >> > > >>>>>>>
> >> > > >>>>>>> On 2024/08/27 06:15:57 TengYao Chi wrote:
> >> > > >>>>>>>> Hi everyone,
> >> > > >>>>>>>>
> >> > > >>>>>>>> The discussion
> >> > > >>>>>>>> <
> >> > > >> https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j>
> >> > > >>>> of
> >> > > >>>>>>>> KIP-1079
> >> > > >>>>>>>> <
> >> > > >>>>>
> >> > > >>>>
> >> > > >>>
> >> > > >>
> >> > >
> >> >
> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
> >> > > >>>>>>
> >> > > >>>>>>>> has
> >> > > >>>>>>>> been silent for a long time, I believe this KIP is now ready
> >> for
> >> > > >> a
> >> > > >>>>> vote.
> >> > > >>>>>>>>
> >> > > >>>>>>>> Sincerely,
> >> > > >>>>>>>> TengYao
> >> > > >>>>>>>>
> >> > > >>>>>
> >> > > >>>>>
> >> > > >>>>
> >> > > >>>
> >> > > >>
> >> > >
> >> > >
> >> >
> >>
> >

Re: [VOTE] 3.9.0 RC0

[Josep Prat]

I can see the Stream Quickstart ones in the staging repo, but only these.
When I did the 3.8 release I realized that
https://repository.apache.org/#stagingRepositories had 3 different entries
(repositories) every time I tried to upload to maven central (1 was kind of
faulty with only togdor jar file and no metadata, and the other 2 were for
StreamQuickStart jars, and all the other jars). Taking a look there now, I
see only the repository for the quickstart is present. Colin, did you
happen to see the other repositories as well?

Best,


On Wed, Sep 18, 2024 at 11:26 AM Luke Chen  wrote:

> Same here, no 3.9.0 artifacts in the staging repo.
>
> Thanks.
> Luke
>
>
> On Wed, Sep 18, 2024 at 4:49 PM Jakub Scholz  wrote:
>
> > Hi Colin,
> >
> > Thanks for the RC.
> >
> > It looks like the Maven artifacts are missing for 3.9.0 in the staging
> > repo. Are we still waiting for some staging job to complete? Or is that
> > some CDN issue and I'm the only one not seeing them? Or is that some
> > general problem?
> >
> > Thanks & Regards
> > Jakub
> >
> > On Wed, Sep 18, 2024 at 5:07 AM Colin McCabe  wrote:
> >
> > > Hello Kafka users, developers and client-developers,
> > >
> > >
> > >
> > > This is the first candidate for release of Apache Kafka 3.9.0.
> > >
> > >
> > > - This is a major release, the final one in the 3.x line. (There may of
> > > course be other minor releases in this line, such as 3.9.1.)
> > > - Tiered storage will be considered production-ready in this release.
> > > - This will be the final major release to feature the deprecated
> > ZooKeeper
> > > mode.
> > >
> > > This release includes the following KIPs:
> > > - KIP-853: Support dynamically changing KRaft controller membership
> > > - KIP-1057: Add remote log metadata flag to the dump log tool
> > > - KIP-1049: Add config log.summary.interval.ms to Kafka Streams
> > > - KIP-1040: Improve handling of nullable values in InsertField,
> > > ExtractField, and other transformations
> > > - KIP-1031: Control offset translation in MirrorSourceConnector
> > > - KIP-1033: Add Kafka Streams exception handler for exceptions
> occurring
> > > during processing
> > > - KIP-1017: Health check endpoint for Kafka Connect
> > > - KIP-1025: Optionally URL-encode clientID and clientSecret in
> > > authorization header
> > > - KIP-1005: Expose EarliestLocalOffset and TieredOffset
> > > - KIP-950: Tiered Storage Disablement
> > > - KIP-956: Tiered Storage Quotas
> > >
> > > Release notes for the 3.9.0 release:
> > > https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/RELEASE_NOTES.html
> > >
> > > *** Please download, test and vote by September 23, 2024.
> > >
> > > Kafka's KEYS file containing PGP keys we use to sign the release:
> > > https://kafka.apache.org/KEYS
> > >
> > > * Release artifacts to be voted upon (source and binary):
> > > https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/
> > >
> > > * Docker release artifacts to be voted upon:
> > > apache/kafka:3.9.0-rc0
> > > apache/kafka-native:3.9.0-rc0
> > >
> > > * Maven artifacts to be voted upon:
> > > https://repository.apache.org/content/groups/staging/org/apache/kafka/
> > >
> > > * Javadoc:
> > > https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/javadoc/
> > >
> > > * Documentation:
> > > https://kafka.apache.org/39/documentation.html
> > >
> > > * Protocol:
> > > https://kafka.apache.org/39/protocol.html
> > >
> > > * Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc0 tag:
> > > https://github.com/apache/kafka/releases/tag/3.9.0-rc0
> > >
> > > I've run several successful junit and ducktape builds. While there were
> > > some flaky tests, when re-running them, they passed.
> > >
> > > * Successful Docker Image Github Actions Pipeline for 3.8 branch:
> > > Docker Build Test Pipeline (JVM):
> > > https://github.com/apache/kafka/actions/runs/10912118987
> > > Docker Build Test Pipeline (Native):
> > > https://github.com/apache/kafka/actions/runs/10914303515
> > >
> > > Thanks to everyone who helped with this release candidate, either by
> > > contributing code, testing, or documentation.
> > >
> > > Regards,
> > > Colin
> > >
> >
>


-- 
[image: Aiven] <https://www.aiven.io>

*Josep Prat*
Open Source Engineering Director, *Aiven*
josep.p...@aiven.io   |   +491715557497
aiven.io <https://www.aiven.io>   |   <https://www.facebook.com/aivencloud>
  <https://www.linkedin.com/company/aiven/>   <https://twitter.com/aiven_io>
*Aiven Deutschland GmbH*
Alexanderufer 3-7, 10117 Berlin
Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen,
Anna Richardson, Kenneth Chen
Amtsgericht Charlottenburg, HRB 209739 B

Re: [VOTE] 3.9.0 RC0

[Luke Chen]

Same here, no 3.9.0 artifacts in the staging repo.

Thanks.
Luke


On Wed, Sep 18, 2024 at 4:49 PM Jakub Scholz  wrote:

> Hi Colin,
>
> Thanks for the RC.
>
> It looks like the Maven artifacts are missing for 3.9.0 in the staging
> repo. Are we still waiting for some staging job to complete? Or is that
> some CDN issue and I'm the only one not seeing them? Or is that some
> general problem?
>
> Thanks & Regards
> Jakub
>
> On Wed, Sep 18, 2024 at 5:07 AM Colin McCabe  wrote:
>
> > Hello Kafka users, developers and client-developers,
> >
> >
> >
> > This is the first candidate for release of Apache Kafka 3.9.0.
> >
> >
> > - This is a major release, the final one in the 3.x line. (There may of
> > course be other minor releases in this line, such as 3.9.1.)
> > - Tiered storage will be considered production-ready in this release.
> > - This will be the final major release to feature the deprecated
> ZooKeeper
> > mode.
> >
> > This release includes the following KIPs:
> > - KIP-853: Support dynamically changing KRaft controller membership
> > - KIP-1057: Add remote log metadata flag to the dump log tool
> > - KIP-1049: Add config log.summary.interval.ms to Kafka Streams
> > - KIP-1040: Improve handling of nullable values in InsertField,
> > ExtractField, and other transformations
> > - KIP-1031: Control offset translation in MirrorSourceConnector
> > - KIP-1033: Add Kafka Streams exception handler for exceptions occurring
> > during processing
> > - KIP-1017: Health check endpoint for Kafka Connect
> > - KIP-1025: Optionally URL-encode clientID and clientSecret in
> > authorization header
> > - KIP-1005: Expose EarliestLocalOffset and TieredOffset
> > - KIP-950: Tiered Storage Disablement
> > - KIP-956: Tiered Storage Quotas
> >
> > Release notes for the 3.9.0 release:
> > https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/RELEASE_NOTES.html
> >
> > *** Please download, test and vote by September 23, 2024.
> >
> > Kafka's KEYS file containing PGP keys we use to sign the release:
> > https://kafka.apache.org/KEYS
> >
> > * Release artifacts to be voted upon (source and binary):
> > https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/
> >
> > * Docker release artifacts to be voted upon:
> > apache/kafka:3.9.0-rc0
> > apache/kafka-native:3.9.0-rc0
> >
> > * Maven artifacts to be voted upon:
> > https://repository.apache.org/content/groups/staging/org/apache/kafka/
> >
> > * Javadoc:
> > https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/javadoc/
> >
> > * Documentation:
> > https://kafka.apache.org/39/documentation.html
> >
> > * Protocol:
> > https://kafka.apache.org/39/protocol.html
> >
> > * Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc0 tag:
> > https://github.com/apache/kafka/releases/tag/3.9.0-rc0
> >
> > I've run several successful junit and ducktape builds. While there were
> > some flaky tests, when re-running them, they passed.
> >
> > * Successful Docker Image Github Actions Pipeline for 3.8 branch:
> > Docker Build Test Pipeline (JVM):
> > https://github.com/apache/kafka/actions/runs/10912118987
> > Docker Build Test Pipeline (Native):
> > https://github.com/apache/kafka/actions/runs/10914303515
> >
> > Thanks to everyone who helped with this release candidate, either by
> > contributing code, testing, or documentation.
> >
> > Regards,
> > Colin
> >
>

Re: [VOTE] 3.9.0 RC0

[Jakub Scholz]

Hi Colin,

Thanks for the RC.

It looks like the Maven artifacts are missing for 3.9.0 in the staging
repo. Are we still waiting for some staging job to complete? Or is that
some CDN issue and I'm the only one not seeing them? Or is that some
general problem?

Thanks & Regards
Jakub

On Wed, Sep 18, 2024 at 5:07 AM Colin McCabe  wrote:

> Hello Kafka users, developers and client-developers,
>
>
>
> This is the first candidate for release of Apache Kafka 3.9.0.
>
>
> - This is a major release, the final one in the 3.x line. (There may of
> course be other minor releases in this line, such as 3.9.1.)
> - Tiered storage will be considered production-ready in this release.
> - This will be the final major release to feature the deprecated ZooKeeper
> mode.
>
> This release includes the following KIPs:
> - KIP-853: Support dynamically changing KRaft controller membership
> - KIP-1057: Add remote log metadata flag to the dump log tool
> - KIP-1049: Add config log.summary.interval.ms to Kafka Streams
> - KIP-1040: Improve handling of nullable values in InsertField,
> ExtractField, and other transformations
> - KIP-1031: Control offset translation in MirrorSourceConnector
> - KIP-1033: Add Kafka Streams exception handler for exceptions occurring
> during processing
> - KIP-1017: Health check endpoint for Kafka Connect
> - KIP-1025: Optionally URL-encode clientID and clientSecret in
> authorization header
> - KIP-1005: Expose EarliestLocalOffset and TieredOffset
> - KIP-950: Tiered Storage Disablement
> - KIP-956: Tiered Storage Quotas
>
> Release notes for the 3.9.0 release:
> https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/RELEASE_NOTES.html
>
> *** Please download, test and vote by September 23, 2024.
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> https://kafka.apache.org/KEYS
>
> * Release artifacts to be voted upon (source and binary):
> https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/
>
> * Docker release artifacts to be voted upon:
> apache/kafka:3.9.0-rc0
> apache/kafka-native:3.9.0-rc0
>
> * Maven artifacts to be voted upon:
> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>
> * Javadoc:
> https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/javadoc/
>
> * Documentation:
> https://kafka.apache.org/39/documentation.html
>
> * Protocol:
> https://kafka.apache.org/39/protocol.html
>
> * Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc0 tag:
> https://github.com/apache/kafka/releases/tag/3.9.0-rc0
>
> I've run several successful junit and ducktape builds. While there were
> some flaky tests, when re-running them, they passed.
>
> * Successful Docker Image Github Actions Pipeline for 3.8 branch:
> Docker Build Test Pipeline (JVM):
> https://github.com/apache/kafka/actions/runs/10912118987
> Docker Build Test Pipeline (Native):
> https://github.com/apache/kafka/actions/runs/10914303515
>
> Thanks to everyone who helped with this release candidate, either by
> contributing code, testing, or documentation.
>
> Regards,
> Colin
>

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[TengYao Chi]

Hello Federico
I'm sorry that I missed your email.
The ticket used to track future removal has been filed. (KAFKA-17556
<https://issues.apache.org/jira/browse/KAFKA-17556>)
Please take a look and sorry for the inconvenience.

Sincerely,
TengYao


TengYao Chi  於 2024年9月18日 週三 下午12:30寫道：

> Hello everyone,
>
> The vote is now closed, and the KIP has been accepted with 3 binding +1s
> from Chia-Ping, Lianet, Justine, as well as 4 non-binding +1 from TaiJu,
> Federico, Andrew, Kirk.
>
> Thank you all for your participation!
>
> Sincerely,
> TengYao
>
> Justine Olshan  於 2024年9月17日 週二 下午9:41寫道：
>
>> +1 (binding) from me
>>
>> Justine
>>
>> On Mon, Sep 16, 2024 at 7:36 PM TengYao Chi  wrote:
>>
>> > Hi Kirk
>> > Thanks for pointing out. I have updated the description of KAFKA-17087.
>> >
>> > Sincerely,
>> > TengYao
>> >
>> > Kirk True  於 2024年9月16日 週一 下午11:45寫道：
>> >
>> > > Hi TengYao,
>> > >
>> > > +1 (non-binding).
>> > >
>> > > Using KAFKA-17087 to track the actual removal in 5.0 is going to help
>> > this
>> > > not fall through the cracks. One minor point is that the description
>> for
>> > > the Jira states that "we should deprecate it in 3.9 and then remove it
>> > from
>> > > 4.0” which should be "we should deprecate it in 4.0 and then remove it
>> > from
>> > > 5.0"
>> > >
>> > > Thanks!
>> > >
>> > > > On Sep 16, 2024, at 6:54 AM, Lianet M.  wrote:
>> > > >
>> > > > Thanks for the update! Looks good to me now.
>> > > >
>> > > > +1 (binding)
>> > > >
>> > > > Cheers,
>> > > >
>> > > > Lianet
>> > > >
>> > > > On Mon, Sep 16, 2024 at 9:31 AM TengYao Chi 
>> > wrote:
>> > > >
>> > > >> Hi Lianet,
>> > > >>
>> > > >> Thanks for comment.
>> > > >> It is very helpful and I have applied it to the content of this
>> KIP.
>> > > >> Please take a look.
>> > > >>
>> > > >> Sincerely,
>> > > >> TengYao
>> > > >>
>> > > >> Lianet M.  於 2024年9月16日 週一 下午7:16寫道：
>> > > >>
>> > > >>> Hello TengYao.
>> > > >>>
>> > > >>> Thanks for the KIP, nice cleanup. Just one question left. I wonder
>> > how
>> > > we
>> > > >>> make sure that we don't just bring in this KIP, deprecate the arg
>> and
>> > > >>> forget about it?. First we could maybe mention in the KIP that is
>> > with
>> > > >> the
>> > > >>> intention of removing the option in 5.0 (just for reference), and
>> > also
>> > > >>> create and include here the jira for it already (maybe in the
>> > > >>> "Compatibility, Deprecation, and Migration Plan" section)?
>> > > >>>
>> > > >>> Thanks!
>> > > >>>
>> > > >>> Lianet
>> > > >>>
>> > > >>> On Mon, Sep 16, 2024 at 1:01 AM TengYao Chi 
>> > > wrote:
>> > > >>>
>> > > >>>> Hello everyone,
>> > > >>>> I hope this message finds you well.
>> > > >>>> As the vote has been pending for two weeks, I would like to push
>> it
>> > > >>>> manually.
>> > > >>>>
>> > > >>>> Thank you for your attention.
>> > > >>>>
>> > > >>>> Sincerely,
>> > > >>>> TengYao
>> > > >>>>
>> > > >>>> Andrew Schofield  於 2024年8月27日 週二
>> > > >> 下午10:20寫道：
>> > > >>>>
>> > > >>>>> Thanks for the KIP.
>> > > >>>>>
>> > > >>>>> +1 (non-binding)
>> > > >>>>>
>> > > >>>>> Andrew
>> > > >>>>>
>> > > >>>>>> On 27 Aug 2024, at 10:31, Federico Valeri <
>> fedeval...@gmail.com>
>> > > >>>> wrote:
>> > > >>>>>>
>> > > >>>>>> +1 non binding
>> > > >>>>>>
>> > > >>>>>> Should we also create a Jira to track future removal?
>> > > >>>>>>
>> > > >>>>>> On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai <
>> > > >> chia7...@apache.org
>> > > >>>>
>> > > >>>>> wrote:
>> > > >>>>>>>
>> > > >>>>>>> +1 (binding)
>> > > >>>>>>>
>> > > >>>>>>> On 2024/08/27 06:15:57 TengYao Chi wrote:
>> > > >>>>>>>> Hi everyone,
>> > > >>>>>>>>
>> > > >>>>>>>> The discussion
>> > > >>>>>>>> <
>> > > >> https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j>
>> > > >>>> of
>> > > >>>>>>>> KIP-1079
>> > > >>>>>>>> <
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
>> > > >>>>>>
>> > > >>>>>>>> has
>> > > >>>>>>>> been silent for a long time, I believe this KIP is now ready
>> for
>> > > >> a
>> > > >>>>> vote.
>> > > >>>>>>>>
>> > > >>>>>>>> Sincerely,
>> > > >>>>>>>> TengYao
>> > > >>>>>>>>
>> > > >>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>>
>

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[TengYao Chi]

Hello everyone,

The vote is now closed, and the KIP has been accepted with 3 binding +1s
from Chia-Ping, Lianet, Justine, as well as 4 non-binding +1 from TaiJu,
Federico, Andrew, Kirk.

Thank you all for your participation!

Sincerely,
TengYao

Justine Olshan  於 2024年9月17日 週二 下午9:41寫道：

> +1 (binding) from me
>
> Justine
>
> On Mon, Sep 16, 2024 at 7:36 PM TengYao Chi  wrote:
>
> > Hi Kirk
> > Thanks for pointing out. I have updated the description of KAFKA-17087.
> >
> > Sincerely,
> > TengYao
> >
> > Kirk True  於 2024年9月16日 週一 下午11:45寫道：
> >
> > > Hi TengYao,
> > >
> > > +1 (non-binding).
> > >
> > > Using KAFKA-17087 to track the actual removal in 5.0 is going to help
> > this
> > > not fall through the cracks. One minor point is that the description
> for
> > > the Jira states that "we should deprecate it in 3.9 and then remove it
> > from
> > > 4.0” which should be "we should deprecate it in 4.0 and then remove it
> > from
> > > 5.0"
> > >
> > > Thanks!
> > >
> > > > On Sep 16, 2024, at 6:54 AM, Lianet M.  wrote:
> > > >
> > > > Thanks for the update! Looks good to me now.
> > > >
> > > > +1 (binding)
> > > >
> > > > Cheers,
> > > >
> > > > Lianet
> > > >
> > > > On Mon, Sep 16, 2024 at 9:31 AM TengYao Chi 
> > wrote:
> > > >
> > > >> Hi Lianet,
> > > >>
> > > >> Thanks for comment.
> > > >> It is very helpful and I have applied it to the content of this KIP.
> > > >> Please take a look.
> > > >>
> > > >> Sincerely,
> > > >> TengYao
> > > >>
> > > >> Lianet M.  於 2024年9月16日 週一 下午7:16寫道：
> > > >>
> > > >>> Hello TengYao.
> > > >>>
> > > >>> Thanks for the KIP, nice cleanup. Just one question left. I wonder
> > how
> > > we
> > > >>> make sure that we don't just bring in this KIP, deprecate the arg
> and
> > > >>> forget about it?. First we could maybe mention in the KIP that is
> > with
> > > >> the
> > > >>> intention of removing the option in 5.0 (just for reference), and
> > also
> > > >>> create and include here the jira for it already (maybe in the
> > > >>> "Compatibility, Deprecation, and Migration Plan" section)?
> > > >>>
> > > >>> Thanks!
> > > >>>
> > > >>> Lianet
> > > >>>
> > > >>> On Mon, Sep 16, 2024 at 1:01 AM TengYao Chi 
> > > wrote:
> > > >>>
> > > >>>> Hello everyone,
> > > >>>> I hope this message finds you well.
> > > >>>> As the vote has been pending for two weeks, I would like to push
> it
> > > >>>> manually.
> > > >>>>
> > > >>>> Thank you for your attention.
> > > >>>>
> > > >>>> Sincerely,
> > > >>>> TengYao
> > > >>>>
> > > >>>> Andrew Schofield  於 2024年8月27日 週二
> > > >> 下午10:20寫道：
> > > >>>>
> > > >>>>> Thanks for the KIP.
> > > >>>>>
> > > >>>>> +1 (non-binding)
> > > >>>>>
> > > >>>>> Andrew
> > > >>>>>
> > > >>>>>> On 27 Aug 2024, at 10:31, Federico Valeri  >
> > > >>>> wrote:
> > > >>>>>>
> > > >>>>>> +1 non binding
> > > >>>>>>
> > > >>>>>> Should we also create a Jira to track future removal?
> > > >>>>>>
> > > >>>>>> On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai <
> > > >> chia7...@apache.org
> > > >>>>
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>> +1 (binding)
> > > >>>>>>>
> > > >>>>>>> On 2024/08/27 06:15:57 TengYao Chi wrote:
> > > >>>>>>>> Hi everyone,
> > > >>>>>>>>
> > > >>>>>>>> The discussion
> > > >>>>>>>> <
> > > >> https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j>
> > > >>>> of
> > > >>>>>>>> KIP-1079
> > > >>>>>>>> <
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
> > > >>>>>>
> > > >>>>>>>> has
> > > >>>>>>>> been silent for a long time, I believe this KIP is now ready
> for
> > > >> a
> > > >>>>> vote.
> > > >>>>>>>>
> > > >>>>>>>> Sincerely,
> > > >>>>>>>> TengYao
> > > >>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>

[VOTE] 3.9.0 RC0

[Colin McCabe]

Hello Kafka users, developers and client-developers,

 

This is the first candidate for release of Apache Kafka 3.9.0.  

 
- This is a major release, the final one in the 3.x line. (There may of course 
be other minor releases in this line, such as 3.9.1.)
- Tiered storage will be considered production-ready in this release.
- This will be the final major release to feature the deprecated ZooKeeper mode.

This release includes the following KIPs:
- KIP-853: Support dynamically changing KRaft controller membership 
- KIP-1057: Add remote log metadata flag to the dump log tool
- KIP-1049: Add config log.summary.interval.ms to Kafka Streams 
- KIP-1040: Improve handling of nullable values in InsertField, ExtractField, 
and other transformations
- KIP-1031: Control offset translation in MirrorSourceConnector
- KIP-1033: Add Kafka Streams exception handler for exceptions occurring during 
processing
- KIP-1017: Health check endpoint for Kafka Connect   
- KIP-1025: Optionally URL-encode clientID and clientSecret in authorization 
header
- KIP-1005: Expose EarliestLocalOffset and TieredOffset
- KIP-950: Tiered Storage Disablement
- KIP-956: Tiered Storage Quotas

Release notes for the 3.9.0 release:
https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/RELEASE_NOTES.html

*** Please download, test and vote by September 23, 2024.

Kafka's KEYS file containing PGP keys we use to sign the release:
https://kafka.apache.org/KEYS

* Release artifacts to be voted upon (source and binary):
https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/

* Docker release artifacts to be voted upon:
apache/kafka:3.9.0-rc0
apache/kafka-native:3.9.0-rc0

* Maven artifacts to be voted upon:
https://repository.apache.org/content/groups/staging/org/apache/kafka/

* Javadoc:
https://home.apache.org/~cmccabe/kafka-3.9.0-rc0/javadoc/

* Documentation:
https://kafka.apache.org/39/documentation.html

* Protocol:
https://kafka.apache.org/39/protocol.html

* Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc0 tag:
https://github.com/apache/kafka/releases/tag/3.9.0-rc0

I've run several successful junit and ducktape builds. While there were some 
flaky tests, when re-running them, they passed.

* Successful Docker Image Github Actions Pipeline for 3.8 branch:
Docker Build Test Pipeline (JVM): 
https://github.com/apache/kafka/actions/runs/10912118987
Docker Build Test Pipeline (Native): 
https://github.com/apache/kafka/actions/runs/10914303515

Thanks to everyone who helped with this release candidate, either by 
contributing code, testing, or documentation.

Regards,
Colin

Re: [VOTE] KIP-1082: Require Client-Generated IDs over the ConsumerGroupHeartbeat RPC

[Andrew Schofield]

+1 (non-binding)


From: 吳岱儒 
Sent: 17 September 2024 04:24
To: dev@kafka.apache.org 
Subject: Re: [VOTE] KIP-1082: Require Client-Generated IDs over the 
ConsumerGroupHeartbeat RPC

+1 (non-binding)

Best,
TaiJuWu

Chia-Ping Tsai  於 2024年9月16日 週一 下午11:41寫道：

> +1 (binding)
>
> thanks for reaching out to the corner case.
>
> Best,
> Chia-Ping
>
> Kirk True  於 2024年9月16日 週一 下午11:36寫道：
>
> > Hi TengYao,
> >
> > +1 (non-binding)
> >
> > Thanks for all the hard work with the tricky edge cases :)
> >
> > Kirk
> >
> > > On Sep 16, 2024, at 6:47 AM, TengYao Chi  wrote:
> > >
> > > Hi everyone,
> > >
> > > Based on our discussion
> > > <https://lists.apache.org/thread/vvytypk3l8cvv8yltrckfg6yf7ovd371>
> > > regarding KIP-1082 <https://cwiki.apache.org/confluence/x/XBDOEg>, I
> > > believe this KIP is now ready for a vote.
> > >
> > > Sincerely,
> > > TengYao
> >
> >
>

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[Justine Olshan]

+1 (binding) from me

Justine

On Mon, Sep 16, 2024 at 7:36 PM TengYao Chi  wrote:

> Hi Kirk
> Thanks for pointing out. I have updated the description of KAFKA-17087.
>
> Sincerely,
> TengYao
>
> Kirk True  於 2024年9月16日 週一 下午11:45寫道：
>
> > Hi TengYao,
> >
> > +1 (non-binding).
> >
> > Using KAFKA-17087 to track the actual removal in 5.0 is going to help
> this
> > not fall through the cracks. One minor point is that the description for
> > the Jira states that "we should deprecate it in 3.9 and then remove it
> from
> > 4.0” which should be "we should deprecate it in 4.0 and then remove it
> from
> > 5.0"
> >
> > Thanks!
> >
> > > On Sep 16, 2024, at 6:54 AM, Lianet M.  wrote:
> > >
> > > Thanks for the update! Looks good to me now.
> > >
> > > +1 (binding)
> > >
> > > Cheers,
> > >
> > > Lianet
> > >
> > > On Mon, Sep 16, 2024 at 9:31 AM TengYao Chi 
> wrote:
> > >
> > >> Hi Lianet,
> > >>
> > >> Thanks for comment.
> > >> It is very helpful and I have applied it to the content of this KIP.
> > >> Please take a look.
> > >>
> > >> Sincerely,
> > >> TengYao
> > >>
> > >> Lianet M.  於 2024年9月16日 週一 下午7:16寫道：
> > >>
> > >>> Hello TengYao.
> > >>>
> > >>> Thanks for the KIP, nice cleanup. Just one question left. I wonder
> how
> > we
> > >>> make sure that we don't just bring in this KIP, deprecate the arg and
> > >>> forget about it?. First we could maybe mention in the KIP that is
> with
> > >> the
> > >>> intention of removing the option in 5.0 (just for reference), and
> also
> > >>> create and include here the jira for it already (maybe in the
> > >>> "Compatibility, Deprecation, and Migration Plan" section)?
> > >>>
> > >>> Thanks!
> > >>>
> > >>> Lianet
> > >>>
> > >>> On Mon, Sep 16, 2024 at 1:01 AM TengYao Chi 
> > wrote:
> > >>>
> > >>>> Hello everyone,
> > >>>> I hope this message finds you well.
> > >>>> As the vote has been pending for two weeks, I would like to push it
> > >>>> manually.
> > >>>>
> > >>>> Thank you for your attention.
> > >>>>
> > >>>> Sincerely,
> > >>>> TengYao
> > >>>>
> > >>>> Andrew Schofield  於 2024年8月27日 週二
> > >> 下午10:20寫道：
> > >>>>
> > >>>>> Thanks for the KIP.
> > >>>>>
> > >>>>> +1 (non-binding)
> > >>>>>
> > >>>>> Andrew
> > >>>>>
> > >>>>>> On 27 Aug 2024, at 10:31, Federico Valeri 
> > >>>> wrote:
> > >>>>>>
> > >>>>>> +1 non binding
> > >>>>>>
> > >>>>>> Should we also create a Jira to track future removal?
> > >>>>>>
> > >>>>>> On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai <
> > >> chia7...@apache.org
> > >>>>
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>> +1 (binding)
> > >>>>>>>
> > >>>>>>> On 2024/08/27 06:15:57 TengYao Chi wrote:
> > >>>>>>>> Hi everyone,
> > >>>>>>>>
> > >>>>>>>> The discussion
> > >>>>>>>> <
> > >> https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j>
> > >>>> of
> > >>>>>>>> KIP-1079
> > >>>>>>>> <
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
> > >>>>>>
> > >>>>>>>> has
> > >>>>>>>> been silent for a long time, I believe this KIP is now ready for
> > >> a
> > >>>>> vote.
> > >>>>>>>>
> > >>>>>>>> Sincerely,
> > >>>>>>>> TengYao
> > >>>>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Re: [VOTE] KIP-1082: Require Client-Generated IDs over the ConsumerGroupHeartbeat RPC

[吳岱儒]

+1 (non-binding)

Best,
TaiJuWu

Chia-Ping Tsai  於 2024年9月16日 週一 下午11:41寫道：

> +1 (binding)
>
> thanks for reaching out to the corner case.
>
> Best,
> Chia-Ping
>
> Kirk True  於 2024年9月16日 週一 下午11:36寫道：
>
> > Hi TengYao,
> >
> > +1 (non-binding)
> >
> > Thanks for all the hard work with the tricky edge cases :)
> >
> > Kirk
> >
> > > On Sep 16, 2024, at 6:47 AM, TengYao Chi  wrote:
> > >
> > > Hi everyone,
> > >
> > > Based on our discussion
> > > <https://lists.apache.org/thread/vvytypk3l8cvv8yltrckfg6yf7ovd371>
> > > regarding KIP-1082 <https://cwiki.apache.org/confluence/x/XBDOEg>, I
> > > believe this KIP is now ready for a vote.
> > >
> > > Sincerely,
> > > TengYao
> >
> >
>

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[TengYao Chi]

Hi Kirk
Thanks for pointing out. I have updated the description of KAFKA-17087.

Sincerely,
TengYao

Kirk True  於 2024年9月16日 週一 下午11:45寫道：

> Hi TengYao,
>
> +1 (non-binding).
>
> Using KAFKA-17087 to track the actual removal in 5.0 is going to help this
> not fall through the cracks. One minor point is that the description for
> the Jira states that "we should deprecate it in 3.9 and then remove it from
> 4.0” which should be "we should deprecate it in 4.0 and then remove it from
> 5.0"
>
> Thanks!
>
> > On Sep 16, 2024, at 6:54 AM, Lianet M.  wrote:
> >
> > Thanks for the update! Looks good to me now.
> >
> > +1 (binding)
> >
> > Cheers,
> >
> > Lianet
> >
> > On Mon, Sep 16, 2024 at 9:31 AM TengYao Chi  wrote:
> >
> >> Hi Lianet,
> >>
> >> Thanks for comment.
> >> It is very helpful and I have applied it to the content of this KIP.
> >> Please take a look.
> >>
> >> Sincerely,
> >> TengYao
> >>
> >> Lianet M.  於 2024年9月16日 週一 下午7:16寫道：
> >>
> >>> Hello TengYao.
> >>>
> >>> Thanks for the KIP, nice cleanup. Just one question left. I wonder how
> we
> >>> make sure that we don't just bring in this KIP, deprecate the arg and
> >>> forget about it?. First we could maybe mention in the KIP that is with
> >> the
> >>> intention of removing the option in 5.0 (just for reference), and also
> >>> create and include here the jira for it already (maybe in the
> >>> "Compatibility, Deprecation, and Migration Plan" section)?
> >>>
> >>> Thanks!
> >>>
> >>> Lianet
> >>>
> >>> On Mon, Sep 16, 2024 at 1:01 AM TengYao Chi 
> wrote:
> >>>
> >>>> Hello everyone,
> >>>> I hope this message finds you well.
> >>>> As the vote has been pending for two weeks, I would like to push it
> >>>> manually.
> >>>>
> >>>> Thank you for your attention.
> >>>>
> >>>> Sincerely,
> >>>> TengYao
> >>>>
> >>>> Andrew Schofield  於 2024年8月27日 週二
> >> 下午10:20寫道：
> >>>>
> >>>>> Thanks for the KIP.
> >>>>>
> >>>>> +1 (non-binding)
> >>>>>
> >>>>> Andrew
> >>>>>
> >>>>>> On 27 Aug 2024, at 10:31, Federico Valeri 
> >>>> wrote:
> >>>>>>
> >>>>>> +1 non binding
> >>>>>>
> >>>>>> Should we also create a Jira to track future removal?
> >>>>>>
> >>>>>> On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai <
> >> chia7...@apache.org
> >>>>
> >>>>> wrote:
> >>>>>>>
> >>>>>>> +1 (binding)
> >>>>>>>
> >>>>>>> On 2024/08/27 06:15:57 TengYao Chi wrote:
> >>>>>>>> Hi everyone,
> >>>>>>>>
> >>>>>>>> The discussion
> >>>>>>>> <
> >> https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j>
> >>>> of
> >>>>>>>> KIP-1079
> >>>>>>>> <
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
> >>>>>>
> >>>>>>>> has
> >>>>>>>> been silent for a long time, I believe this KIP is now ready for
> >> a
> >>>>> vote.
> >>>>>>>>
> >>>>>>>> Sincerely,
> >>>>>>>> TengYao
> >>>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[Kirk True]

Hi TengYao,

+1 (non-binding).

Using KAFKA-17087 to track the actual removal in 5.0 is going to help this not 
fall through the cracks. One minor point is that the description for the Jira 
states that "we should deprecate it in 3.9 and then remove it from 4.0” which 
should be "we should deprecate it in 4.0 and then remove it from 5.0"

Thanks!

> On Sep 16, 2024, at 6:54 AM, Lianet M.  wrote:
> 
> Thanks for the update! Looks good to me now.
> 
> +1 (binding)
> 
> Cheers,
> 
> Lianet
> 
> On Mon, Sep 16, 2024 at 9:31 AM TengYao Chi  wrote:
> 
>> Hi Lianet,
>> 
>> Thanks for comment.
>> It is very helpful and I have applied it to the content of this KIP.
>> Please take a look.
>> 
>> Sincerely,
>> TengYao
>> 
>> Lianet M.  於 2024年9月16日 週一 下午7:16寫道：
>> 
>>> Hello TengYao.
>>> 
>>> Thanks for the KIP, nice cleanup. Just one question left. I wonder how we
>>> make sure that we don't just bring in this KIP, deprecate the arg and
>>> forget about it?. First we could maybe mention in the KIP that is with
>> the
>>> intention of removing the option in 5.0 (just for reference), and also
>>> create and include here the jira for it already (maybe in the
>>> "Compatibility, Deprecation, and Migration Plan" section)?
>>> 
>>> Thanks!
>>> 
>>> Lianet
>>> 
>>> On Mon, Sep 16, 2024 at 1:01 AM TengYao Chi  wrote:
>>> 
>>>> Hello everyone,
>>>> I hope this message finds you well.
>>>> As the vote has been pending for two weeks, I would like to push it
>>>> manually.
>>>> 
>>>> Thank you for your attention.
>>>> 
>>>> Sincerely,
>>>> TengYao
>>>> 
>>>> Andrew Schofield  於 2024年8月27日 週二
>> 下午10:20寫道：
>>>> 
>>>>> Thanks for the KIP.
>>>>> 
>>>>> +1 (non-binding)
>>>>> 
>>>>> Andrew
>>>>> 
>>>>>> On 27 Aug 2024, at 10:31, Federico Valeri 
>>>> wrote:
>>>>>> 
>>>>>> +1 non binding
>>>>>> 
>>>>>> Should we also create a Jira to track future removal?
>>>>>> 
>>>>>> On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai <
>> chia7...@apache.org
>>>> 
>>>>> wrote:
>>>>>>> 
>>>>>>> +1 (binding)
>>>>>>> 
>>>>>>> On 2024/08/27 06:15:57 TengYao Chi wrote:
>>>>>>>> Hi everyone,
>>>>>>>> 
>>>>>>>> The discussion
>>>>>>>> <
>> https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j>
>>>> of
>>>>>>>> KIP-1079
>>>>>>>> <
>>>>> 
>>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
>>>>>> 
>>>>>>>> has
>>>>>>>> been silent for a long time, I believe this KIP is now ready for
>> a
>>>>> vote.
>>>>>>>> 
>>>>>>>> Sincerely,
>>>>>>>> TengYao
>>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: [VOTE] KIP-1082: Require Client-Generated IDs over the ConsumerGroupHeartbeat RPC

[Chia-Ping Tsai]

+1 (binding)

thanks for reaching out to the corner case.

Best,
Chia-Ping

Kirk True  於 2024年9月16日 週一 下午11:36寫道：

> Hi TengYao,
>
> +1 (non-binding)
>
> Thanks for all the hard work with the tricky edge cases :)
>
> Kirk
>
> > On Sep 16, 2024, at 6:47 AM, TengYao Chi  wrote:
> >
> > Hi everyone,
> >
> > Based on our discussion
> > <https://lists.apache.org/thread/vvytypk3l8cvv8yltrckfg6yf7ovd371>
> > regarding KIP-1082 <https://cwiki.apache.org/confluence/x/XBDOEg>, I
> > believe this KIP is now ready for a vote.
> >
> > Sincerely,
> > TengYao
>
>

Re: [VOTE] KIP-1082: Require Client-Generated IDs over the ConsumerGroupHeartbeat RPC

[Kirk True]

Hi TengYao,

+1 (non-binding)

Thanks for all the hard work with the tricky edge cases :)

Kirk

> On Sep 16, 2024, at 6:47 AM, TengYao Chi  wrote:
> 
> Hi everyone,
> 
> Based on our discussion
> <https://lists.apache.org/thread/vvytypk3l8cvv8yltrckfg6yf7ovd371>
> regarding KIP-1082 <https://cwiki.apache.org/confluence/x/XBDOEg>, I
> believe this KIP is now ready for a vote.
> 
> Sincerely,
> TengYao

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[Lianet M.]

Thanks for the update! Looks good to me now.

+1 (binding)

Cheers,

Lianet

On Mon, Sep 16, 2024 at 9:31 AM TengYao Chi  wrote:

> Hi Lianet,
>
> Thanks for comment.
> It is very helpful and I have applied it to the content of this KIP.
> Please take a look.
>
> Sincerely,
> TengYao
>
> Lianet M.  於 2024年9月16日 週一 下午7:16寫道：
>
> > Hello TengYao.
> >
> > Thanks for the KIP, nice cleanup. Just one question left. I wonder how we
> > make sure that we don't just bring in this KIP, deprecate the arg and
> > forget about it?. First we could maybe mention in the KIP that is with
> the
> > intention of removing the option in 5.0 (just for reference), and also
> > create and include here the jira for it already (maybe in the
> > "Compatibility, Deprecation, and Migration Plan" section)?
> >
> > Thanks!
> >
> > Lianet
> >
> > On Mon, Sep 16, 2024 at 1:01 AM TengYao Chi  wrote:
> >
> > > Hello everyone,
> > > I hope this message finds you well.
> > > As the vote has been pending for two weeks, I would like to push it
> > > manually.
> > >
> > > Thank you for your attention.
> > >
> > > Sincerely,
> > > TengYao
> > >
> > > Andrew Schofield  於 2024年8月27日 週二
> 下午10:20寫道：
> > >
> > > > Thanks for the KIP.
> > > >
> > > > +1 (non-binding)
> > > >
> > > > Andrew
> > > >
> > > > > On 27 Aug 2024, at 10:31, Federico Valeri 
> > > wrote:
> > > > >
> > > > > +1 non binding
> > > > >
> > > > > Should we also create a Jira to track future removal?
> > > > >
> > > > > On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai <
> chia7...@apache.org
> > >
> > > > wrote:
> > > > >>
> > > > >> +1 (binding)
> > > > >>
> > > > >> On 2024/08/27 06:15:57 TengYao Chi wrote:
> > > > >>> Hi everyone,
> > > > >>>
> > > > >>> The discussion
> > > > >>> <
> https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j>
> > > of
> > > > >>> KIP-1079
> > > > >>> <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
> > > > >
> > > > >>> has
> > > > >>> been silent for a long time, I believe this KIP is now ready for
> a
> > > > vote.
> > > > >>>
> > > > >>> Sincerely,
> > > > >>> TengYao
> > > > >>>
> > > >
> > > >
> > >
> >
>

[VOTE] KIP-1082: Require Client-Generated IDs over the ConsumerGroupHeartbeat RPC

[TengYao Chi]

Hi everyone,

Based on our discussion
<https://lists.apache.org/thread/vvytypk3l8cvv8yltrckfg6yf7ovd371>
 regarding KIP-1082 <https://cwiki.apache.org/confluence/x/XBDOEg>, I
believe this KIP is now ready for a vote.

Sincerely,
TengYao

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[TengYao Chi]

Hi Lianet,

Thanks for comment.
It is very helpful and I have applied it to the content of this KIP.
Please take a look.

Sincerely,
TengYao

Lianet M.  於 2024年9月16日 週一 下午7:16寫道：

> Hello TengYao.
>
> Thanks for the KIP, nice cleanup. Just one question left. I wonder how we
> make sure that we don't just bring in this KIP, deprecate the arg and
> forget about it?. First we could maybe mention in the KIP that is with the
> intention of removing the option in 5.0 (just for reference), and also
> create and include here the jira for it already (maybe in the
> "Compatibility, Deprecation, and Migration Plan" section)?
>
> Thanks!
>
> Lianet
>
> On Mon, Sep 16, 2024 at 1:01 AM TengYao Chi  wrote:
>
> > Hello everyone,
> > I hope this message finds you well.
> > As the vote has been pending for two weeks, I would like to push it
> > manually.
> >
> > Thank you for your attention.
> >
> > Sincerely,
> > TengYao
> >
> > Andrew Schofield  於 2024年8月27日 週二 下午10:20寫道：
> >
> > > Thanks for the KIP.
> > >
> > > +1 (non-binding)
> > >
> > > Andrew
> > >
> > > > On 27 Aug 2024, at 10:31, Federico Valeri 
> > wrote:
> > > >
> > > > +1 non binding
> > > >
> > > > Should we also create a Jira to track future removal?
> > > >
> > > > On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai  >
> > > wrote:
> > > >>
> > > >> +1 (binding)
> > > >>
> > > >> On 2024/08/27 06:15:57 TengYao Chi wrote:
> > > >>> Hi everyone,
> > > >>>
> > > >>> The discussion
> > > >>> <https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j>
> > of
> > > >>> KIP-1079
> > > >>> <
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
> > > >
> > > >>> has
> > > >>> been silent for a long time, I believe this KIP is now ready for a
> > > vote.
> > > >>>
> > > >>> Sincerely,
> > > >>> TengYao
> > > >>>
> > >
> > >
> >
>

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[Lianet M.]

Hello TengYao.

Thanks for the KIP, nice cleanup. Just one question left. I wonder how we
make sure that we don't just bring in this KIP, deprecate the arg and
forget about it?. First we could maybe mention in the KIP that is with the
intention of removing the option in 5.0 (just for reference), and also
create and include here the jira for it already (maybe in the
"Compatibility, Deprecation, and Migration Plan" section)?

Thanks!

Lianet

On Mon, Sep 16, 2024 at 1:01 AM TengYao Chi  wrote:

> Hello everyone,
> I hope this message finds you well.
> As the vote has been pending for two weeks, I would like to push it
> manually.
>
> Thank you for your attention.
>
> Sincerely,
> TengYao
>
> Andrew Schofield  於 2024年8月27日 週二 下午10:20寫道：
>
> > Thanks for the KIP.
> >
> > +1 (non-binding)
> >
> > Andrew
> >
> > > On 27 Aug 2024, at 10:31, Federico Valeri 
> wrote:
> > >
> > > +1 non binding
> > >
> > > Should we also create a Jira to track future removal?
> > >
> > > On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai 
> > wrote:
> > >>
> > >> +1 (binding)
> > >>
> > >> On 2024/08/27 06:15:57 TengYao Chi wrote:
> > >>> Hi everyone,
> > >>>
> > >>> The discussion
> > >>> <https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j>
> of
> > >>> KIP-1079
> > >>> <
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
> > >
> > >>> has
> > >>> been silent for a long time, I believe this KIP is now ready for a
> > vote.
> > >>>
> > >>> Sincerely,
> > >>> TengYao
> > >>>
> >
> >
>

Re: [VOTE] KIP-1064 - Upgrade slf4j to 2.x

[Muralidhar Basani]

Thanks Chia.

I have updated KIP with this quote, in the migration plan section.

Thanks,
Murali

On Sun, Sep 15, 2024 at 3:30 PM Chia-Ping Tsai  wrote:

>
> > Muralidhar Basani  於 2024年9月15日
> 晚上9:02 寫道：
> >
> > With this, I think, users don't have to make any explicit changes in
> their
> > code, if their provider is reload4j. And if it's a different provider
> (like
> > logback, log4j), they would have to upgrade that to match it with slf4j.
>
> If upgrading the matched provider is the only explicit change and we
> expect users have responsibility to keep consistent version when using
> other providers , could we write it down to the KIP?
>
> That means we will update slf4j without KIP in the future except for
> specific reason.
>
> Best,
> Chia-Ping

Re: [VOTE] KIP-1058: Txn consumer exerts pressure on remote storage when reading non-txn topic

[Kamal Chandraprakash]

Bumping this thread for vote. PTAL.

On Mon, Sep 9, 2024 at 2:01 PM Kamal Chandraprakash <
kamal.chandraprak...@gmail.com> wrote:

> Hi all,
>
> I'd like to open voting for KIP-1058. This KIP improves the consumer
> reading from remote storage when READ_COMMITTED isolation level is enabled.
> PTAL.
>
> KIP-1058
> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1058%3A+Txn+consumer+exerts+pressure+on+remote+storage+when+collecting+aborted+transactions>
>
> Thanks,
> Kamal
>

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[TengYao Chi]

Hello everyone,
I hope this message finds you well.
As the vote has been pending for two weeks, I would like to push it
manually.

Thank you for your attention.

Sincerely,
TengYao

Andrew Schofield  於 2024年8月27日 週二 下午10:20寫道：

> Thanks for the KIP.
>
> +1 (non-binding)
>
> Andrew
>
> > On 27 Aug 2024, at 10:31, Federico Valeri  wrote:
> >
> > +1 non binding
> >
> > Should we also create a Jira to track future removal?
> >
> > On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai 
> wrote:
> >>
> >> +1 (binding)
> >>
> >> On 2024/08/27 06:15:57 TengYao Chi wrote:
> >>> Hi everyone,
> >>>
> >>> The discussion
> >>> <https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j> of
> >>> KIP-1079
> >>> <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
> >
> >>> has
> >>> been silent for a long time, I believe this KIP is now ready for a
> vote.
> >>>
> >>> Sincerely,
> >>> TengYao
> >>>
>
>

Re: [VOTE] KIP-1064 - Upgrade slf4j to 2.x

[Chia-Ping Tsai]

> Muralidhar Basani  於 2024年9月15日 晚上9:02 寫道：
> 
> With this, I think, users don't have to make any explicit changes in their
> code, if their provider is reload4j. And if it's a different provider (like
> logback, log4j), they would have to upgrade that to match it with slf4j.

If upgrading the matched provider is the only explicit change and we expect 
users have responsibility to keep consistent version when using other providers 
, could we write it down to the KIP?

That means we will update slf4j without KIP in the future except for specific 
reason.

Best,
Chia-Ping

Re: [VOTE] KIP-1064 - Upgrade slf4j to 2.x

[Muralidhar Basani]

Hi Colin and Chia, thank you for your feedback.

Currently we have only reload4j binding dependency, and we
can continue with the same. I have updated kip with only reload4j, and
removed all other providers.
And if users have a different slf4j provider, they can continue to keep it
in the classpath.

With this, I think, users don't have to make any explicit changes in their
code, if their provider is reload4j. And if it's a different provider (like
logback, log4j), they would have to upgrade that to match it with slf4j.

And we may not have to file a new kip, for every slf4j upgrade, if we agree
with the same approach ?

Thanks,
Murali

On Sun, Sep 15, 2024 at 8:50 AM Chia-Ping Tsai  wrote:

>
>
> > Colin McCabe  於 2024年9月15日 凌晨4:26 寫道：
> > I'm also not totally convinced that we need to provide so many logging
> systems. It feels odd to bring in so many dependencies without having a
> clear idea of who is using them. We didn't do this earlier and nobody
> complained. Putting more stuff on the CLASSPATH can lead to problems for
> people.
>
> If we all agree “no nobody will complain the possible compatibility issue
> when we upgrade the slf4j api in the future”, it is fine to NOT add all
> providers to classpath.
>
> I was +1 to ignore the possible compatibility issue before, but user need
> to add extra (slf4j provider) jar to classpath if they want to run with
> different slf4j provider. It seems that is a kind of API requisite so we
> need to be careful about the compatibility issue. However, it is a bit
> weird to file KIP to update slf4j api every time…
>
> Best,
> Chia-Ping
>
>
>
>
>

Re: [VOTE] KIP-1064 - Upgrade slf4j to 2.x

[Chia-Ping Tsai]

> Colin McCabe  於 2024年9月15日 凌晨4:26 寫道：
> I'm also not totally convinced that we need to provide so many logging 
> systems. It feels odd to bring in so many dependencies without having a clear 
> idea of who is using them. We didn't do this earlier and nobody complained. 
> Putting more stuff on the CLASSPATH can lead to problems for people.

If we all agree “no nobody will complain the possible compatibility issue when 
we upgrade the slf4j api in the future”, it is fine to NOT add all providers to 
classpath.

I was +1 to ignore the possible compatibility issue before, but user need to 
add extra (slf4j provider) jar to classpath if they want to run with different 
slf4j provider. It seems that is a kind of API requisite so we need to be 
careful about the compatibility issue. However, it is a bit weird to file KIP 
to update slf4j api every time…

Best,
Chia-Ping

Re: [VOTE] KIP-1086: Add ability to specify a custom produce request parser.

[Maxim Fortun]

David and Colin,
I was confused about the process of the discussion. I mistakenly thought since 
the conversation died out and either there was no interest or no active 
protests it was time to move to voting.
Thank you both for your patience, explanations, and guidance. Hopefully once 
the next version is released the discussion will liven up.
I am working on making Kafka the core component of a large publishing company 
and hope this community can help me with that.
Again, thank you!
Max

> On Sep 14, 2024, at 4:27 PM, Colin McCabe  wrote:
> 
> Yes, I agree. I'm going to leave a -1 just for process reasons. Please let's 
> continue the discussion.
> 
> best,
> Colin
> 
> 
> On Fri, Sep 13, 2024, at 06:55, David Arthur wrote:
>> Max,
>> 
>> First off, thanks for the KIP! Looking back at the discussion thread, I
>> don't feel like we reached consensus on this feature. Generally, there
>> should be overall agreement that the feature is desired and well designed
>> before moving to a vote. Folks are pretty busy at the moment preparing for
>> the 3.9 release as well as the conference in Austin. Maybe give the
>> committers a bit more time to give feedback on the KIP.
>> 
>> Cheers,
>> David
>> 
>> On Thu, Sep 12, 2024 at 1:13 PM Maxim Fortun  wrote:
>> 
>>> Hello everyone,
>>> 
>>> I would like to call for a vote on KIP-1086:
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=318606528
>>> 
>>> Discussion:
>>> https://lists.apache.org/thread/wtgt9jql43qmfsmvqcz0y1phc2n08440
>>> 
>>> Thank you,
>>> 
>>> Max
>>> 
>>> 
>>> 
>> 
>> -- 
>> David Arthur
> 

Re: [VOTE] KIP-1064 - Upgrade slf4j to 2.x

[Colin McCabe]

Hi Muralidhar,

Thanks for working on this. Can you give some context here about whether slf4j 
1 is still maintained? And what code changes are needed to move to slf4j2?

The KIP says that "we also provide the compatible binding jars of a few 
backends like logback, log4j, reload4j, commons logging in kafka itself." I 
think if we're going to do this we should fully specify the jars we're 
providing, not just say "a few jars like...".

I'm also not totally convinced that we need to provide so many logging systems. 
It feels odd to bring in so many dependencies without having a clear idea of 
who is using them. We didn't do this earlier and nobody complained. Putting 
more stuff on the CLASSPATH can lead to problems for people.

best,
Colin

On Wed, Sep 11, 2024, at 00:36, Muralidhar Basani wrote:
> Hi Chia, thank you for the vote.
> I have updated kip motivation with it.
>
> Thanks,
> Murali
>
> On Wed, Sep 11, 2024 at 8:15 AM Chia-Ping Tsai  wrote:
>
>> +1 (binding)
>>
>> BTW, could you please add "compatibility issue" to the motivation?
>>
>> the version of slf4j provider must be equal to slf4j API [0]. Including
>> both in kafka distribution can avoid compatibility issue;
>>
>> [0] https://www.slf4j.org/manual.html#compatibility
>>
>> Muralidhar Basani  於 2024年9月11日 週三
>> 上午4:02寫道：
>>
>> > Hi all,
>> >
>> > I would like to call a vote on KIP-1064 - Upgrade slf4j to 2.x
>> >
>> > Target version : 4.0.0
>> >
>> > KIP -
>> >
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1064%3A+Upgrade+slf4j+to+2.x
>> >
>> > Discussion thread -
>> > https://lists.apache.org/thread/z05rlzbjv89rpvzjmzsr8v4w17qn21r1
>> >
>> > Jira with some discussion :
>> > https://issues.apache.org/jira/browse/KAFKA-16936
>> >
>> > Thanks,
>> > Murali
>> >
>>

Re: [VOTE] KIP-1086: Add ability to specify a custom produce request parser.

[Colin McCabe]

Yes, I agree. I'm going to leave a -1 just for process reasons. Please let's 
continue the discussion.

best,
Colin


On Fri, Sep 13, 2024, at 06:55, David Arthur wrote:
> Max,
>
> First off, thanks for the KIP! Looking back at the discussion thread, I
> don't feel like we reached consensus on this feature. Generally, there
> should be overall agreement that the feature is desired and well designed
> before moving to a vote. Folks are pretty busy at the moment preparing for
> the 3.9 release as well as the conference in Austin. Maybe give the
> committers a bit more time to give feedback on the KIP.
>
> Cheers,
> David
>
> On Thu, Sep 12, 2024 at 1:13 PM Maxim Fortun  wrote:
>
>> Hello everyone,
>>
>> I would like to call for a vote on KIP-1086:
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=318606528
>>
>> Discussion:
>> https://lists.apache.org/thread/wtgt9jql43qmfsmvqcz0y1phc2n08440
>>
>> Thank you,
>>
>> Max
>>
>>
>>
>
> -- 
> David Arthur

Re: [VOTE] KIP-1086: Add ability to specify a custom produce request parser.

[David Arthur]

Max,

First off, thanks for the KIP! Looking back at the discussion thread, I
don't feel like we reached consensus on this feature. Generally, there
should be overall agreement that the feature is desired and well designed
before moving to a vote. Folks are pretty busy at the moment preparing for
the 3.9 release as well as the conference in Austin. Maybe give the
committers a bit more time to give feedback on the KIP.

Cheers,
David

On Thu, Sep 12, 2024 at 1:13 PM Maxim Fortun  wrote:

> Hello everyone,
>
> I would like to call for a vote on KIP-1086:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=318606528
>
> Discussion:
> https://lists.apache.org/thread/wtgt9jql43qmfsmvqcz0y1phc2n08440
>
> Thank you,
>
> Max
>
>
>

-- 
David Arthur

[VOTE] KIP-1086: Add ability to specify a custom produce request parser.

[Maxim Fortun]

Hello everyone,

I would like to call for a vote on KIP-1086: 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=318606528

Discussion: https://lists.apache.org/thread/wtgt9jql43qmfsmvqcz0y1phc2n08440

Thank you,

Max

Re: [VOTE] KIP-1085: Fix leaking *_DOC variables in StreamsConfig

[黃竣陽]

Hi everyone,

The vote is now closed.
The KIP has been accepted with 4 binding votes from Lucas, Matthias,
Luke, and Chia-Ping.
Thanks to everyone for participating!

Regards,
Jiunn-Yang

> Lucas Brutschy  於 2024年9月10日 晚上10:14 寫道：
> 
> +1 (binding). Thanks for the PR!
> 
> On Fri, Sep 6, 2024 at 4:20 AM Luke Chen  wrote:
>> 
>> +1 from me. Thanks.
>> 
>> On Fri, Sep 6, 2024 at 1:04 AM Matthias J. Sax  wrote:
>> 
>>> +1 (binding)
>>> 
>>> On 9/5/24 06:34, Chia-Ping Tsai wrote:
>>>> +1 (binding)
>>>> 
>>>> 黃竣陽  於 2024年9月5日 週四 下午9:13寫道：
>>>> 
>>>>> Hello everyone,
>>>>> 
>>>>> I would like to call for a vote on KIP-1085: <
>>>>> 
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1085%3A+Fix+leaking+*_DOC+variables+in+StreamsConfig
>>>>>> 
>>>>> 
>>>>> The discussion can be found here:
>>>>> <https://lists.apache.org/thread/1wjowoxsf7lvo9fjl4s3x57bv6w8z0nf>
>>>>> 
>>>>> Best regards,
>>>>> Jiunn-Yang
>>>> 
>>> 

Re: [VOTE] KIP-1052: Enable warmup in producer performance test

[Justine Olshan]

+1 (binding) from me.

Thanks,
Justine

On Wed, Sep 4, 2024 at 3:22 PM Welch, Matt  wrote:

> Hi Kafka devs,
>
> Bumping this VOTE thread again for visibility.
>
> Thanks,
> Matt
>
> -Original Message-
> From: Welch, Matt 
> Sent: Friday, August 23, 2024 4:26 PM
> To: dev@kafka.apache.org
> Subject: RE: [VOTE] KIP-1052: Enable warmup in producer performance test
>
> Hi Kafka devs,
>
> Bumping this VOTE thread for visibility.
>
> Thanks,
> Matt
>
> -Original Message-
> From: Federico Valeri 
> Sent: Monday, August 19, 2024 12:38 AM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-1052: Enable warmup in producer performance test
>
> Hi Matt, +1 (non binding) from me. Thanks!
>
> Just a suggestion: I think that the following output line does not add
> much value and could be removed.
>
> "Warmup first 10 records. Steady-state results will print after the
> complete-test summary."
>
> On Wed, Aug 14, 2024 at 8:06 PM Welch, Matt  wrote:
> >
> >
> > Hi all,
> >
> > It seems discussion has been quiet for a couple of weeks so I'd like
> > to call a vote on KIP-1052
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1052%3A+Enable+w
> > armup+in+producer+performance+test
> >
> > Thanks,
> > Matt Welch
> >
>

Re: [VOTE] KIP-1064 - Upgrade slf4j to 2.x

[Muralidhar Basani]

Hi Chia, thank you for the vote.
I have updated kip motivation with it.

Thanks,
Murali

On Wed, Sep 11, 2024 at 8:15 AM Chia-Ping Tsai  wrote:

> +1 (binding)
>
> BTW, could you please add "compatibility issue" to the motivation?
>
> the version of slf4j provider must be equal to slf4j API [0]. Including
> both in kafka distribution can avoid compatibility issue;
>
> [0] https://www.slf4j.org/manual.html#compatibility
>
> Muralidhar Basani  於 2024年9月11日 週三
> 上午4:02寫道：
>
> > Hi all,
> >
> > I would like to call a vote on KIP-1064 - Upgrade slf4j to 2.x
> >
> > Target version : 4.0.0
> >
> > KIP -
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1064%3A+Upgrade+slf4j+to+2.x
> >
> > Discussion thread -
> > https://lists.apache.org/thread/z05rlzbjv89rpvzjmzsr8v4w17qn21r1
> >
> > Jira with some discussion :
> > https://issues.apache.org/jira/browse/KAFKA-16936
> >
> > Thanks,
> > Murali
> >
>

[VOTE] KIP-1034: Dead letter queue in Kafka Streams

[Sebastien Viale]

Hi all,

We would like to start a vote for KIP-1034: Dead letter queue in Kafka 
Streams<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1034%3A+Dead+letter+queue+in+Kafka+Streams>

The KIP is available on 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1034%3A+Dead+letter+queue+in+Kafka+Streams

If you have any suggestions or feedback, feel free to participate to the 
discussion thread:
https://lists.apache.org/thread/1nhhsrogmmv15o7mk9nj4kvkb5k2bx9s

Best regards,

Damien Sebastien and Loic

Re: [VOTE] KIP-1064 - Upgrade slf4j to 2.x

[Chia-Ping Tsai]

+1 (binding)

BTW, could you please add "compatibility issue" to the motivation?

the version of slf4j provider must be equal to slf4j API [0]. Including
both in kafka distribution can avoid compatibility issue;

[0] https://www.slf4j.org/manual.html#compatibility

Muralidhar Basani  於 2024年9月11日 週三
上午4:02寫道：

> Hi all,
>
> I would like to call a vote on KIP-1064 - Upgrade slf4j to 2.x
>
> Target version : 4.0.0
>
> KIP -
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1064%3A+Upgrade+slf4j+to+2.x
>
> Discussion thread -
> https://lists.apache.org/thread/z05rlzbjv89rpvzjmzsr8v4w17qn21r1
>
> Jira with some discussion :
> https://issues.apache.org/jira/browse/KAFKA-16936
>
> Thanks,
> Murali
>

[VOTE] KIP-1064 - Upgrade slf4j to 2.x

[Muralidhar Basani]

Hi all,

I would like to call a vote on KIP-1064 - Upgrade slf4j to 2.x

Target version : 4.0.0

KIP -
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1064%3A+Upgrade+slf4j+to+2.x

Discussion thread -
https://lists.apache.org/thread/z05rlzbjv89rpvzjmzsr8v4w17qn21r1

Jira with some discussion :
https://issues.apache.org/jira/browse/KAFKA-16936

Thanks,
Murali

Re: [VOTE] KIP-1080: Fix the typo: `maxlifeTimeMs` in CreateDelegationTokenOptions

[Lianet M.]

Hello,

Thanks for updating the KIP. Looks good to me now.

+1 (binding)

Lianet


On Thu, Sep 5, 2024, 8:29 p.m. 黃竣陽  wrote:

> It make sense to me, I will change to
> `CreateDelegationTokenRequestData.setMaxLifetimeMs`
>
> > Chia-Ping Tsai  於 2024年9月5日 晚上11:22 寫道：
> >
> >> it aligns better with the RPC field (max_lifetime_ms)
> >
> > That makes sense to me. +1 to align it
> >
> > Best,
> > Chia-Ping
> >
> > Lianet M.  於 2024年9月5日 週四 下午11:13寫道：
> >
> >> Hey all, just one small comment: shouldn't the new method be named "
> >> maxLifetimeMs()" (Lifetime vs LifeTime)? I believe it's the right
> spelling,
> >> but mostly, it aligns better with the RPC field (max_lifetime_ms), that
> >> generates a CreateDelegationTokenRequestData.maxLifetimeMs() and
> >> CreateDelegationTokenRequestData.setMaxLifetimeMs(...)
> >>
> >> Thanks!
> >>
> >> Lianet
> >>
> >> On Thu, Sep 5, 2024 at 9:36 AM Chia-Ping Tsai 
> wrote:
> >>
> >>> +1 (binding)
> >>>
> >>> 黃竣陽  於 2024年9月5日 週四 下午9:08寫道：
> >>>
> >>>> Hello everyone,
> >>>>
> >>>> I would like to call for a vote on KIP-1080: <
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1080%3A+Fix+the+typo%3A+%60maxlifeTimeMs%60+in+CreateDelegationTokenOptions
> >>>>>
> >>>>
> >>>> The discussion can be found here:
> >>>> <https://lists.apache.org/thread/00jvqxoo6d59k5z5cjm9wtj6dd075vro>
> >>>>
> >>>> Best regards,
> >>>> Jiunn-Yang
> >>>
> >>
>
>

Re: [VOTE] KIP-1074: Allow the replication of user internal topics

[Chris Egerton]

Hi Patrik,

Sorry for the delay, I've been on PTO. LGTM! +1 (binding)

Cheers,

Chris

On Tue, Sep 3, 2024 at 5:10 AM Viktor Somogyi-Vass
 wrote:

> Hi Patrik,
>
> Thanks for working on this. +1 from me (binding).
>
> Best,
> Viktor
>
> On Wed, Aug 28, 2024 at 1:34 PM Patrik Marton  >
> wrote:
>
> > Hi all,
> >
> > As the proposal is finalized, and there was no new feedback in the past
> > week, I would like to open voting for KIP-1074
> > <
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1074%3A+Allow+the+replication+of+user+internal+topics
> > >
> > .
> >
> > Please vote / let me know your thoughts.
> >
> > Thanks,
> > Patrik
> >
>

[VOTE] KIP-1058: Txn consumer exerts pressure on remote storage when reading non-txn topic

[Kamal Chandraprakash]

Hi all,

I'd like to open voting for KIP-1058. This KIP improves the consumer
reading from remote storage when READ_COMMITTED isolation level is enabled.
PTAL.

KIP-1058


Thanks,
Kamal

Re: [VOTE] KIP-1080: Fix the typo: `maxlifeTimeMs` in CreateDelegationTokenOptions

[黃竣陽]

It make sense to me, I will change to 
`CreateDelegationTokenRequestData.setMaxLifetimeMs`

> Chia-Ping Tsai  於 2024年9月5日 晚上11:22 寫道：
> 
>> it aligns better with the RPC field (max_lifetime_ms)
> 
> That makes sense to me. +1 to align it
> 
> Best,
> Chia-Ping
> 
> Lianet M.  於 2024年9月5日 週四 下午11:13寫道：
> 
>> Hey all, just one small comment: shouldn't the new method be named "
>> maxLifetimeMs()" (Lifetime vs LifeTime)? I believe it's the right spelling,
>> but mostly, it aligns better with the RPC field (max_lifetime_ms), that
>> generates a CreateDelegationTokenRequestData.maxLifetimeMs() and
>> CreateDelegationTokenRequestData.setMaxLifetimeMs(...)
>> 
>> Thanks!
>> 
>> Lianet
>> 
>> On Thu, Sep 5, 2024 at 9:36 AM Chia-Ping Tsai  wrote:
>> 
>>> +1 (binding)
>>> 
>>> 黃竣陽  於 2024年9月5日 週四 下午9:08寫道：
>>> 
>>>> Hello everyone,
>>>> 
>>>> I would like to call for a vote on KIP-1080: <
>>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1080%3A+Fix+the+typo%3A+%60maxlifeTimeMs%60+in+CreateDelegationTokenOptions
>>>>> 
>>>> 
>>>> The discussion can be found here:
>>>> <https://lists.apache.org/thread/00jvqxoo6d59k5z5cjm9wtj6dd075vro>
>>>> 
>>>> Best regards,
>>>> Jiunn-Yang
>>> 
>> 

Re: [EXT] Re: [VOTE] KIP-1033: Add Kafka Streams exception handler for exceptions occurring during processing

[Matthias J. Sax]

Thanks Colin.

Merged the PR to `trunk` and cherry-picked to `3.9` branch.


-Matthias

On 9/3/24 4:07 PM, Colin McCabe wrote:

Hi Matthias and Sebastien,

This sounds like a very small and low-risk PR for a KIP that is new in 3.9 
(KIP-1033). I think we should be OK to cherry-pick it to 3.9, even though we're 
past code freeze. Please try to get it done this week, though :)

best,
Colin


On Fri, Aug 30, 2024, at 19:03, Matthias J. Sax wrote:

Guess it is a question for Colin, who is the RM for 3.9.



-Matthias



On 8/30/24 2:02 AM, Sebastien Viale wrote:

Hi,

All PRs related to KIP-1033 have been merged.

However, after a last review from Matthias J. Sax and Bill Bejeck, we updated 
the KIP to include the timestamp in the ErrorHandlerContext interface.

A new PR has been initialized.
KAFKA-16448 Add timestamp to error handler context 
(https://github.com/apache/kafka/pull/17054)

Please let us know if we need to work on this for 3.9 or for next release.

thanks very much

Sébastien


De : Matthias J. Sax 
Envoyé : jeudi 1 août 2024 23:46
À : dev@kafka.apache.org 
Objet : [EXT] Re: [VOTE] KIP-1033: Add Kafka Streams exception handler for 
exceptions occurring during processing

Warning External sender Do not click on any links or open any attachments 
unless you trust the sender and know the content is safe.

Thanks Loïc!


This email was screened for spam and malicious content but exercise caution 
anyway.


On 8/1/24 6:19 AM, Loic Greffier wrote:

Hi,

Last PR that completed KIP-1033 has been merged.
Thanks to all participants, for the guidance and the feedbacks!

Just letting you know about some decisions and changes made through the 
different PRs that were not initially mentioned in the KIP:

 *   The sourceRawKey and the sourceRawValue attributes present in the 
ErrorHandlerContext have been removed from this KIP. They will be part of 
KIP-1034 instead.
 *   The number of processing exception handler instance has been fixed to 
one per StreamTask.
 *   The processing exception handling mechanism has been extended to 
punctuations.
 *   The handler crash management has been unified and improved. Exceptions 
thrown from a call to #handle are caught and fail the stream. This change 
covers 5 use-cases:
*   On processingExceptionHandler#handle to cover processing exceptions.
*   On processingExceptionHandler#handle to cover punctuation 
exceptions.
*   On productionExceptionHandler#handle to cover production exceptions.
*   On productionExceptionHandler#handleSerializationException to cover 
serialization exceptions.
*   On deserializationExceptionHandler#handle to cover deserialization 
exceptions.

KIP-1033 has been updated with these changes.

Loïc

Re: [VOTE] KIP-1085: Fix leaking *_DOC variables in StreamsConfig

[Matthias J. Sax]

+1 (binding)

On 9/5/24 06:34, Chia-Ping Tsai wrote:

+1 (binding)

黃竣陽  於 2024年9月5日 週四 下午9:13寫道：


Hello everyone,

I would like to call for a vote on KIP-1085: <
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1085%3A+Fix+leaking+*_DOC+variables+in+StreamsConfig




The discussion can be found here:
<https://lists.apache.org/thread/1wjowoxsf7lvo9fjl4s3x57bv6w8z0nf>

Best regards,
Jiunn-Yang

Re: [VOTE] KIP-1085: Fix leaking *_DOC variables in StreamsConfig

[Matthias J. Sax]

+1 (binding)

On 9/5/24 06:34, Chia-Ping Tsai wrote:

+1 (binding)

黃竣陽  於 2024年9月5日 週四 下午9:13寫道：


Hello everyone,

I would like to call for a vote on KIP-1085: <
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1085%3A+Fix+leaking+*_DOC+variables+in+StreamsConfig




The discussion can be found here:
<https://lists.apache.org/thread/1wjowoxsf7lvo9fjl4s3x57bv6w8z0nf>

Best regards,
Jiunn-Yang

Re: [VOTE] KIP-1080: Fix the typo: `maxlifeTimeMs` in CreateDelegationTokenOptions

[Chia-Ping Tsai]

>  it aligns better with the RPC field (max_lifetime_ms)

That makes sense to me. +1 to align it

Best,
Chia-Ping

Lianet M.  於 2024年9月5日 週四 下午11:13寫道：

> Hey all, just one small comment: shouldn't the new method be named "
> maxLifetimeMs()" (Lifetime vs LifeTime)? I believe it's the right spelling,
> but mostly, it aligns better with the RPC field (max_lifetime_ms), that
> generates a CreateDelegationTokenRequestData.maxLifetimeMs() and
> CreateDelegationTokenRequestData.setMaxLifetimeMs(...)
>
> Thanks!
>
> Lianet
>
> On Thu, Sep 5, 2024 at 9:36 AM Chia-Ping Tsai  wrote:
>
> > +1 (binding)
> >
> > 黃竣陽  於 2024年9月5日 週四 下午9:08寫道：
> >
> > > Hello everyone,
> > >
> > > I would like to call for a vote on KIP-1080: <
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1080%3A+Fix+the+typo%3A+%60maxlifeTimeMs%60+in+CreateDelegationTokenOptions
> > > >
> > >
> > > The discussion can be found here:
> > > <https://lists.apache.org/thread/00jvqxoo6d59k5z5cjm9wtj6dd075vro>
> > >
> > > Best regards,
> > > Jiunn-Yang
> >
>

Re: [VOTE] KIP-1080: Fix the typo: `maxlifeTimeMs` in CreateDelegationTokenOptions

[Lianet M.]

Hey all, just one small comment: shouldn't the new method be named "
maxLifetimeMs()" (Lifetime vs LifeTime)? I believe it's the right spelling,
but mostly, it aligns better with the RPC field (max_lifetime_ms), that
generates a CreateDelegationTokenRequestData.maxLifetimeMs() and
CreateDelegationTokenRequestData.setMaxLifetimeMs(...)

Thanks!

Lianet

On Thu, Sep 5, 2024 at 9:36 AM Chia-Ping Tsai  wrote:

> +1 (binding)
>
> 黃竣陽  於 2024年9月5日 週四 下午9:08寫道：
>
> > Hello everyone,
> >
> > I would like to call for a vote on KIP-1080: <
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1080%3A+Fix+the+typo%3A+%60maxlifeTimeMs%60+in+CreateDelegationTokenOptions
> > >
> >
> > The discussion can be found here:
> > <https://lists.apache.org/thread/00jvqxoo6d59k5z5cjm9wtj6dd075vro>
> >
> > Best regards,
> > Jiunn-Yang
>

Re: [VOTE] KIP-1080: Fix the typo: `maxlifeTimeMs` in CreateDelegationTokenOptions

[Chia-Ping Tsai]

+1 (binding)

黃竣陽  於 2024年9月5日 週四 下午9:08寫道：

> Hello everyone,
>
> I would like to call for a vote on KIP-1080: <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1080%3A+Fix+the+typo%3A+%60maxlifeTimeMs%60+in+CreateDelegationTokenOptions
> >
>
> The discussion can be found here:
> <https://lists.apache.org/thread/00jvqxoo6d59k5z5cjm9wtj6dd075vro>
>
> Best regards,
> Jiunn-Yang

[VOTE] KIP-1085: Fix leaking *_DOC variables in StreamsConfig

[黃竣陽]

Hello everyone,

I would like to call for a vote on KIP-1085: 
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1085%3A+Fix+leaking+*_DOC+variables+in+StreamsConfig>

The discussion can be found here:
<https://lists.apache.org/thread/1wjowoxsf7lvo9fjl4s3x57bv6w8z0nf>

Best regards,
Jiunn-Yang

Re: [EXT] Re: [VOTE] KIP-1033: Add Kafka Streams exception handler for exceptions occurring during processing

[Colin McCabe]

Hi Matthias and Sebastien,

This sounds like a very small and low-risk PR for a KIP that is new in 3.9 
(KIP-1033). I think we should be OK to cherry-pick it to 3.9, even though we're 
past code freeze. Please try to get it done this week, though :)

best,
Colin


On Fri, Aug 30, 2024, at 19:03, Matthias J. Sax wrote:
> Guess it is a question for Colin, who is the RM for 3.9.
>
>
>
> -Matthias
>
>
>
> On 8/30/24 2:02 AM, Sebastien Viale wrote:
>> Hi,
>> 
>> All PRs related to KIP-1033 have been merged.
>> 
>> However, after a last review from Matthias J. Sax and Bill Bejeck, we 
>> updated the KIP to include the timestamp in the ErrorHandlerContext 
>> interface.
>> 
>> A new PR has been initialized.
>> KAFKA-16448 Add timestamp to error handler context 
>> (https://github.com/apache/kafka/pull/17054)
>> 
>> Please let us know if we need to work on this for 3.9 or for next release.
>> 
>> thanks very much
>> 
>> Sébastien
>> 
>> ____
>> De : Matthias J. Sax 
>> Envoyé : jeudi 1 août 2024 23:46
>> À : dev@kafka.apache.org 
>> Objet : [EXT] Re: [VOTE] KIP-1033: Add Kafka Streams exception handler for 
>> exceptions occurring during processing
>> 
>> Warning External sender Do not click on any links or open any attachments 
>> unless you trust the sender and know the content is safe.
>> 
>> Thanks Loïc!
>> 
>> 
>> This email was screened for spam and malicious content but exercise caution 
>> anyway.
>> 
>> 
>> On 8/1/24 6:19 AM, Loic Greffier wrote:
>>> Hi,
>>>
>>> Last PR that completed KIP-1033 has been merged.
>>> Thanks to all participants, for the guidance and the feedbacks!
>>>
>>> Just letting you know about some decisions and changes made through the 
>>> different PRs that were not initially mentioned in the KIP:
>>>
>>> *   The sourceRawKey and the sourceRawValue attributes present in the 
>>> ErrorHandlerContext have been removed from this KIP. They will be part of 
>>> KIP-1034 instead.
>>> *   The number of processing exception handler instance has been fixed 
>>> to one per StreamTask.
>>> *   The processing exception handling mechanism has been extended to 
>>> punctuations.
>>> *   The handler crash management has been unified and improved. 
>>> Exceptions thrown from a call to #handle are caught and fail the stream. 
>>> This change covers 5 use-cases:
>>>*   On processingExceptionHandler#handle to cover processing 
>>> exceptions.
>>>*   On processingExceptionHandler#handle to cover punctuation 
>>> exceptions.
>>>*   On productionExceptionHandler#handle to cover production 
>>> exceptions.
>>>*   On productionExceptionHandler#handleSerializationException to 
>>> cover serialization exceptions.
>>>*   On deserializationExceptionHandler#handle to cover 
>>> deserialization exceptions.
>>>
>>> KIP-1033 has been updated with these changes.
>>>
>>> Loïc
>>>
>> 
>>

Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

[Apoorv Mittal]

Thanks for the KIP, looking forward to it.

+1 (non-binding)

Regards,
Apoorv Mittal


On Tue, Sep 3, 2024 at 9:00 PM Matthias J. Sax  wrote:

> +1 (binding)
>
> On 9/3/24 8:56 AM, Andrew Schofield wrote:
> > Thanks for the KIP. +1 (non-binding)
> >
> > Andrew
> > 
> > From: Lucas Brutschy 
> > Sent: 03 September 2024 16:02
> > To: dev@kafka.apache.org 
> > Subject: Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714
> extension
> >
> > Hi Bill,
> >
> > thanks for the KIP! +1 (binding)
> >
> > Lucas
> >
> > On Tue, Sep 3, 2024 at 4:49 PM Bill Bejeck  wrote:
> >>
> >> Hi All,
> >>
> >> I'd like to call for a vote on KIP-1076
> >> <
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FKAFKA%2FKIP-1076%253A%2B%2BMetrics%2Bfor%2Bclient%2Bapplications%2BKIP-714%2Bextension&data=05%7C02%7C%7C0ba83dece6894a4126b508dccc29a7ed%7C84df9e7fe9f640afb435%7C1%7C0%7C638609726517807511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DqHjamMzaj4gwSvGwZv89CPCONXxNrB%2BNyhte2oJpKE%3D&reserved=0
> <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1076%3A++Metrics+for+client+applications+KIP-714+extension
> >>
> >>   (discussion can be found here
> >> <
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F9yf4w9qy0zr7qy9ftjcft0s32w32b891&data=05%7C02%7C%7C0ba83dece6894a4126b508dccc29a7ed%7C84df9e7fe9f640afb435%7C1%7C0%7C638609726517819714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hP3ykAMVOAb8WigLK92GDLl6pYCty4AgngZrsEDQLhQ%3D&reserved=0
> <https://lists.apache.org/thread/9yf4w9qy0zr7qy9ftjcft0s32w32b891>>)
> >>
> >> -Bill
>

Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

[Matthias J. Sax]

+1 (binding)

On 9/3/24 8:56 AM, Andrew Schofield wrote:

Thanks for the KIP. +1 (non-binding)

Andrew

From: Lucas Brutschy 
Sent: 03 September 2024 16:02
To: dev@kafka.apache.org 
Subject: Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 
extension

Hi Bill,

thanks for the KIP! +1 (binding)

Lucas

On Tue, Sep 3, 2024 at 4:49 PM Bill Bejeck  wrote:


Hi All,

I'd like to call for a vote on KIP-1076
<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FKAFKA%2FKIP-1076%253A%2B%2BMetrics%2Bfor%2Bclient%2Bapplications%2BKIP-714%2Bextension&data=05%7C02%7C%7C0ba83dece6894a4126b508dccc29a7ed%7C84df9e7fe9f640afb435%7C1%7C0%7C638609726517807511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DqHjamMzaj4gwSvGwZv89CPCONXxNrB%2BNyhte2oJpKE%3D&reserved=0<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1076%3A++Metrics+for+client+applications+KIP-714+extension>>
  (discussion can be found here
<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F9yf4w9qy0zr7qy9ftjcft0s32w32b891&data=05%7C02%7C%7C0ba83dece6894a4126b508dccc29a7ed%7C84df9e7fe9f640afb435%7C1%7C0%7C638609726517819714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hP3ykAMVOAb8WigLK92GDLl6pYCty4AgngZrsEDQLhQ%3D&reserved=0<https://lists.apache.org/thread/9yf4w9qy0zr7qy9ftjcft0s32w32b891>>)

-Bill

[VOTE] KIP-1087: Removing intermediateTopicsOption from StreamsResetter

[Arnav Dadarya]

Hello All,

I would like to call for a vote on KIP-1087:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1087%3A+Removing+intermediateTopicsOption+from+StreamsResetter


The discussion can be found here:
https://lists.apache.org/list?dev@kafka.apache.org:lte=1M:1087

Sincerely & Thanks,
Arnav Dadarya

Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

[Andrew Schofield]

Thanks for the KIP. +1 (non-binding)

Andrew

From: Lucas Brutschy 
Sent: 03 September 2024 16:02
To: dev@kafka.apache.org 
Subject: Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 
extension

Hi Bill,

thanks for the KIP! +1 (binding)

Lucas

On Tue, Sep 3, 2024 at 4:49 PM Bill Bejeck  wrote:
>
> Hi All,
>
> I'd like to call for a vote on KIP-1076
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FKAFKA%2FKIP-1076%253A%2B%2BMetrics%2Bfor%2Bclient%2Bapplications%2BKIP-714%2Bextension&data=05%7C02%7C%7C0ba83dece6894a4126b508dccc29a7ed%7C84df9e7fe9f640afb435%7C1%7C0%7C638609726517807511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DqHjamMzaj4gwSvGwZv89CPCONXxNrB%2BNyhte2oJpKE%3D&reserved=0<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1076%3A++Metrics+for+client+applications+KIP-714+extension>>
>  (discussion can be found here
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F9yf4w9qy0zr7qy9ftjcft0s32w32b891&data=05%7C02%7C%7C0ba83dece6894a4126b508dccc29a7ed%7C84df9e7fe9f640afb435%7C1%7C0%7C638609726517819714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hP3ykAMVOAb8WigLK92GDLl6pYCty4AgngZrsEDQLhQ%3D&reserved=0<https://lists.apache.org/thread/9yf4w9qy0zr7qy9ftjcft0s32w32b891>>)
>
> -Bill

Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

[Lucas Brutschy]

Hi Bill,

thanks for the KIP! +1 (binding)

Lucas

On Tue, Sep 3, 2024 at 4:49 PM Bill Bejeck  wrote:
>
> Hi All,
>
> I'd like to call for a vote on KIP-1076
> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1076%3A++Metrics+for+client+applications+KIP-714+extension>
>  (discussion can be found here
> <https://lists.apache.org/thread/9yf4w9qy0zr7qy9ftjcft0s32w32b891>)
>
> -Bill

[VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

[Bill Bejeck]

Hi All,

I'd like to call for a vote on KIP-1076
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1076%3A++Metrics+for+client+applications+KIP-714+extension>
 (discussion can be found here
<https://lists.apache.org/thread/9yf4w9qy0zr7qy9ftjcft0s32w32b891>)

-Bill

Re: [VOTE] KIP-1074: Allow the replication of user internal topics

[Viktor Somogyi-Vass]

Hi Patrik,

Thanks for working on this. +1 from me (binding).

Best,
Viktor

On Wed, Aug 28, 2024 at 1:34 PM Patrik Marton 
wrote:

> Hi all,
>
> As the proposal is finalized, and there was no new feedback in the past
> week, I would like to open voting for KIP-1074
> <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1074%3A+Allow+the+replication+of+user+internal+topics
> >
> .
>
> Please vote / let me know your thoughts.
>
> Thanks,
> Patrik
>

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

[Claude Warren, Jr]

 >> not support them.
> >>
> >> > Code is available on my personal branch [1].  It is not fully
> documented
> >> > and does not meet the checkstyle requirements yet.  I also modified
> the
> >> jmh
> >> > tests to run the Trie tests and limit the test to the single case
> >> mentioned
> >> > in the KIP documentation.
> >> >
> >> > If there are no issues with this code, I will complete the
> documentation
> >> > and fix the checkstyle and then open a pull request.
> >>
> >> It's fine to open a pull request. You can link it on the KIP page. As
> >> always, we don't want to commit it until the KIP is accepted.
> >>
> >> best,
> >> Colin
> >>
> >> >
> >> > Claude
> >> >
> >> > [1]
> >> https://github.com/Claudenw/kafka/pull/new/KIP-1042_Trie_Implementation
> >> >
> >> >
> >> > On Wed, Jul 3, 2024 at 2:21 PM Claude Warren, Jr <
> claude.war...@aiven.io
> >> >
> >> > wrote:
> >> >
> >> >> I think that if we put in a trie based system we should be able to
> halve
> >> >> the normal searhc times and still be able to locate wild card matches
> >> very
> >> >> quickly.  Users should be warned that "head wildcard" matches are
> slow
> >> and
> >> >> to use them sparingly.  I am going to see if I can work out how to do
> >> >> wildcard matches within the trie.
> >> >>
> >> >> But in all cases can show that the trie is faster than the current
> >> >> implementation.
> >> >>
> >> >> Claude
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Jun 19, 2024 at 7:53 PM Muralidhar Basani
> >> >>  wrote:
> >> >>
> >> >>> There are some test results mentioned in the Test Plan section of
> the
> >> Kip,
> >> >>> but we need to do more testing with various patterns and permission
> >> types.
> >> >>> As mentioned in the discuss thread, the trie implementation could
> >> >>> potentially surpass the current speed of ACL match.
> >> >>>
> >> >>> However, we can only accurately assess the results after updating
> the
> >> >>> actual classes and analysing them with AuthorizerBenchmark.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Murali
> >> >>>
> >> >>> On Mon, 17 Jun 2024 at 20:39, Colin McCabe 
> wrote:
> >> >>>
> >> >>> > My concern is that the extra complexity may actually slow us
> down. In
> >> >>> > general people already complain about the speed of ACL matches,
> and
> >> >>> adding
> >> >>> > another "degree of freedom" seems likely to make things worse.
> >> >>> >
> >> >>> > It would be useful to understand how much faster or slower the
> code
> >> is
> >> >>> > with the propsed changes, versus without them.
> >> >>> >
> >> >>> > best,
> >> >>> > Colin
> >> >>> >
> >> >>> >
> >> >>> > On Mon, Jun 17, 2024, at 01:26, Muralidhar Basani wrote:
> >> >>> > > Hi all,
> >> >>> > >
> >> >>> > > I would like to call a vote on KIP-1042 which extends creation
> of
> >> acls
> >> >>> > with
> >> >>> > > MATCH pattern type.
> >> >>> > >
> >> >>> > > KIP -
> >> >>> > >
> >> >>> >
> >> >>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1042%3A+Support+for+wildcard+when+creating+new+acls
> >> >>> > >
> >> >>> > > Discussion thread -
> >> >>> > >
> https://lists.apache.org/thread/xx3lcg60kp4v34x0j9p6xobby8l4cfq2
> >> >>> > >
> >> >>> > > Thanks,
> >> >>> > > Murali
> >> >>> >
> >> >>>
> >> >>
> >>
> >>
> >>
>

Re: [EXT] Re: [VOTE] KIP-1033: Add Kafka Streams exception handler for exceptions occurring during processing

[Matthias J. Sax]

Guess it is a question for Colin, who is the RM for 3.9.



-Matthias



On 8/30/24 2:02 AM, Sebastien Viale wrote:

Hi,

All PRs related to KIP-1033 have been merged.

However, after a last review from Matthias J. Sax and Bill Bejeck, we updated 
the KIP to include the timestamp in the ErrorHandlerContext interface.

A new PR has been initialized.
KAFKA-16448 Add timestamp to error handler context 
(https://github.com/apache/kafka/pull/17054)

Please let us know if we need to work on this for 3.9 or for next release.

thanks very much

Sébastien


De : Matthias J. Sax 
Envoyé : jeudi 1 août 2024 23:46
À : dev@kafka.apache.org 
Objet : [EXT] Re: [VOTE] KIP-1033: Add Kafka Streams exception handler for 
exceptions occurring during processing

Warning External sender Do not click on any links or open any attachments 
unless you trust the sender and know the content is safe.

Thanks Loïc!


This email was screened for spam and malicious content but exercise caution 
anyway.


On 8/1/24 6:19 AM, Loic Greffier wrote:

Hi,

Last PR that completed KIP-1033 has been merged.
Thanks to all participants, for the guidance and the feedbacks!

Just letting you know about some decisions and changes made through the 
different PRs that were not initially mentioned in the KIP:

*   The sourceRawKey and the sourceRawValue attributes present in the 
ErrorHandlerContext have been removed from this KIP. They will be part of 
KIP-1034 instead.
*   The number of processing exception handler instance has been fixed to 
one per StreamTask.
*   The processing exception handling mechanism has been extended to 
punctuations.
*   The handler crash management has been unified and improved. Exceptions 
thrown from a call to #handle are caught and fail the stream. This change 
covers 5 use-cases:
   *   On processingExceptionHandler#handle to cover processing exceptions.
   *   On processingExceptionHandler#handle to cover punctuation exceptions.
   *   On productionExceptionHandler#handle to cover production exceptions.
   *   On productionExceptionHandler#handleSerializationException to cover 
serialization exceptions.
   *   On deserializationExceptionHandler#handle to cover deserialization 
exceptions.

KIP-1033 has been updated with these changes.

Loïc

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

[Colin McCabe]

ast.  For most searches they are at least an
>> > order of magnitude faster and use less memory.  The wildcard search is
>> not
>> > a regular expression but rather a file type wild card (*=1 or more
>> > character, ?=1 character).
>> >
>>
>> Hi Claude,
>>
>> One issue here is that your change is incompatible. For example, if I have
>> a consumer group named '?', and an ALLOW ACL  for '?', this change alters
>> the meaning of that ACL. Previously it just ALLOWed '?' Now it allows any
>> single-character group. This obviously could be a major security issue for
>> people doing upgrades.
>>
>> (This wouldn't be an issue if we restricted consumer group names to a
>> sensible set of characters, like we did with topics. But that ship has
>> sailed...)
>>
>> If you want to add new behavior in a backwards-compatible fashion, your
>> best bet probably is to create a new PatternType. Unfortunately this makes
>> the complexity issue worse, but I don't see a way around it. Perhaps we can
>> deprecate LITERAL and PREFIXED at some future date, if this wildcard thing
>> makes them unecessary.
>>
>> Another issue I see, somewhat related, is that Authorizers are pluggable,
>> and probably won't be updated all at once to support this new type. That
>> should be fine, but we should document the error that is returned when
>> someone tries to create your new-style ACLs with an authorizer that does
>> not support them.
>>
>> > Code is available on my personal branch [1].  It is not fully documented
>> > and does not meet the checkstyle requirements yet.  I also modified the
>> jmh
>> > tests to run the Trie tests and limit the test to the single case
>> mentioned
>> > in the KIP documentation.
>> >
>> > If there are no issues with this code, I will complete the documentation
>> > and fix the checkstyle and then open a pull request.
>>
>> It's fine to open a pull request. You can link it on the KIP page. As
>> always, we don't want to commit it until the KIP is accepted.
>>
>> best,
>> Colin
>>
>> >
>> > Claude
>> >
>> > [1]
>> https://github.com/Claudenw/kafka/pull/new/KIP-1042_Trie_Implementation
>> >
>> >
>> > On Wed, Jul 3, 2024 at 2:21 PM Claude Warren, Jr > >
>> > wrote:
>> >
>> >> I think that if we put in a trie based system we should be able to halve
>> >> the normal searhc times and still be able to locate wild card matches
>> very
>> >> quickly.  Users should be warned that "head wildcard" matches are slow
>> and
>> >> to use them sparingly.  I am going to see if I can work out how to do
>> >> wildcard matches within the trie.
>> >>
>> >> But in all cases can show that the trie is faster than the current
>> >> implementation.
>> >>
>> >> Claude
>> >>
>> >>
>> >>
>> >> On Wed, Jun 19, 2024 at 7:53 PM Muralidhar Basani
>> >>  wrote:
>> >>
>> >>> There are some test results mentioned in the Test Plan section of the
>> Kip,
>> >>> but we need to do more testing with various patterns and permission
>> types.
>> >>> As mentioned in the discuss thread, the trie implementation could
>> >>> potentially surpass the current speed of ACL match.
>> >>>
>> >>> However, we can only accurately assess the results after updating the
>> >>> actual classes and analysing them with AuthorizerBenchmark.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Murali
>> >>>
>> >>> On Mon, 17 Jun 2024 at 20:39, Colin McCabe  wrote:
>> >>>
>> >>> > My concern is that the extra complexity may actually slow us down. In
>> >>> > general people already complain about the speed of ACL matches, and
>> >>> adding
>> >>> > another "degree of freedom" seems likely to make things worse.
>> >>> >
>> >>> > It would be useful to understand how much faster or slower the code
>> is
>> >>> > with the propsed changes, versus without them.
>> >>> >
>> >>> > best,
>> >>> > Colin
>> >>> >
>> >>> >
>> >>> > On Mon, Jun 17, 2024, at 01:26, Muralidhar Basani wrote:
>> >>> > > Hi all,
>> >>> > >
>> >>> > > I would like to call a vote on KIP-1042 which extends creation of
>> acls
>> >>> > with
>> >>> > > MATCH pattern type.
>> >>> > >
>> >>> > > KIP -
>> >>> > >
>> >>> >
>> >>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1042%3A+Support+for+wildcard+when+creating+new+acls
>> >>> > >
>> >>> > > Discussion thread -
>> >>> > > https://lists.apache.org/thread/xx3lcg60kp4v34x0j9p6xobby8l4cfq2
>> >>> > >
>> >>> > > Thanks,
>> >>> > > Murali
>> >>> >
>> >>>
>> >>
>>
>>
>>

RE: [EXT] Re: [VOTE] KIP-1033: Add Kafka Streams exception handler for exceptions occurring during processing

[Sebastien Viale]

Hi,

All PRs related to KIP-1033 have been merged.

However, after a last review from Matthias J. Sax and Bill Bejeck, we updated 
the KIP to include the timestamp in the ErrorHandlerContext interface.

A new PR has been initialized.
KAFKA-16448 Add timestamp to error handler context 
(https://github.com/apache/kafka/pull/17054)

Please let us know if we need to work on this for 3.9 or for next release.

thanks very much

Sébastien


De : Matthias J. Sax 
Envoyé : jeudi 1 août 2024 23:46
À : dev@kafka.apache.org 
Objet : [EXT] Re: [VOTE] KIP-1033: Add Kafka Streams exception handler for 
exceptions occurring during processing

Warning External sender Do not click on any links or open any attachments 
unless you trust the sender and know the content is safe.

Thanks Loïc!


This email was screened for spam and malicious content but exercise caution 
anyway.


On 8/1/24 6:19 AM, Loic Greffier wrote:
> Hi,
>
> Last PR that completed KIP-1033 has been merged.
> Thanks to all participants, for the guidance and the feedbacks!
>
> Just letting you know about some decisions and changes made through the 
> different PRs that were not initially mentioned in the KIP:
>
>*   The sourceRawKey and the sourceRawValue attributes present in the 
> ErrorHandlerContext have been removed from this KIP. They will be part of 
> KIP-1034 instead.
>*   The number of processing exception handler instance has been fixed to 
> one per StreamTask.
>*   The processing exception handling mechanism has been extended to 
> punctuations.
>*   The handler crash management has been unified and improved. Exceptions 
> thrown from a call to #handle are caught and fail the stream. This change 
> covers 5 use-cases:
>   *   On processingExceptionHandler#handle to cover processing exceptions.
>   *   On processingExceptionHandler#handle to cover punctuation 
> exceptions.
>   *   On productionExceptionHandler#handle to cover production exceptions.
>   *   On productionExceptionHandler#handleSerializationException to cover 
> serialization exceptions.
>   *   On deserializationExceptionHandler#handle to cover deserialization 
> exceptions.
>
> KIP-1033 has been updated with these changes.
>
> Loïc
>

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

[Claude Warren, Jr]

 error that is returned when
> someone tries to create your new-style ACLs with an authorizer that does
> not support them.
>
> > Code is available on my personal branch [1].  It is not fully documented
> > and does not meet the checkstyle requirements yet.  I also modified the
> jmh
> > tests to run the Trie tests and limit the test to the single case
> mentioned
> > in the KIP documentation.
> >
> > If there are no issues with this code, I will complete the documentation
> > and fix the checkstyle and then open a pull request.
>
> It's fine to open a pull request. You can link it on the KIP page. As
> always, we don't want to commit it until the KIP is accepted.
>
> best,
> Colin
>
> >
> > Claude
> >
> > [1]
> https://github.com/Claudenw/kafka/pull/new/KIP-1042_Trie_Implementation
> >
> >
> > On Wed, Jul 3, 2024 at 2:21 PM Claude Warren, Jr  >
> > wrote:
> >
> >> I think that if we put in a trie based system we should be able to halve
> >> the normal searhc times and still be able to locate wild card matches
> very
> >> quickly.  Users should be warned that "head wildcard" matches are slow
> and
> >> to use them sparingly.  I am going to see if I can work out how to do
> >> wildcard matches within the trie.
> >>
> >> But in all cases can show that the trie is faster than the current
> >> implementation.
> >>
> >> Claude
> >>
> >>
> >>
> >> On Wed, Jun 19, 2024 at 7:53 PM Muralidhar Basani
> >>  wrote:
> >>
> >>> There are some test results mentioned in the Test Plan section of the
> Kip,
> >>> but we need to do more testing with various patterns and permission
> types.
> >>> As mentioned in the discuss thread, the trie implementation could
> >>> potentially surpass the current speed of ACL match.
> >>>
> >>> However, we can only accurately assess the results after updating the
> >>> actual classes and analysing them with AuthorizerBenchmark.
> >>>
> >>> Thanks,
> >>>
> >>> Murali
> >>>
> >>> On Mon, 17 Jun 2024 at 20:39, Colin McCabe  wrote:
> >>>
> >>> > My concern is that the extra complexity may actually slow us down. In
> >>> > general people already complain about the speed of ACL matches, and
> >>> adding
> >>> > another "degree of freedom" seems likely to make things worse.
> >>> >
> >>> > It would be useful to understand how much faster or slower the code
> is
> >>> > with the propsed changes, versus without them.
> >>> >
> >>> > best,
> >>> > Colin
> >>> >
> >>> >
> >>> > On Mon, Jun 17, 2024, at 01:26, Muralidhar Basani wrote:
> >>> > > Hi all,
> >>> > >
> >>> > > I would like to call a vote on KIP-1042 which extends creation of
> acls
> >>> > with
> >>> > > MATCH pattern type.
> >>> > >
> >>> > > KIP -
> >>> > >
> >>> >
> >>>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1042%3A+Support+for+wildcard+when+creating+new+acls
> >>> > >
> >>> > > Discussion thread -
> >>> > > https://lists.apache.org/thread/xx3lcg60kp4v34x0j9p6xobby8l4cfq2
> >>> > >
> >>> > > Thanks,
> >>> > > Murali
> >>> >
> >>>
> >>
>
>
>

Re: [VOTE] KIP-512: make Record Headers available in onAcknowledgement and onComplete

[Rich C.]

Hi all,

Thanks all. We now have 3 binding +1 votes and no -1 votes. KIP-512 is
accepted.
I will update the KIP status and contribute a PR soon.

Regards,
Rich


On Thu, Aug 29, 2024 at 10:00 PM Lianet M.  wrote:

> Hi all,
>
> I'll re-cast my vote here :)
>
> +1 (binding)
>
> Thanks Rich!
>
>
> On Fri, Aug 23, 2024, 10:32 p.m. Chia-Ping Tsai 
> wrote:
>
> > +1 (binding)
> >
> > On 2024/08/10 17:28:45 "Rich C." wrote:
> > > Hi all,
> > >
> > > After incorporating the feedback received
> > > <https://lists.apache.org/thread/ns5qr66rzvwf26pyp1g1dclo9zr3kp67>, I
> > have
> > > updated KIP-512 to reflect the majority preference for the new
> interface
> > > approach. The KIP is now in its final form and ready for a vote.
> > >
> > > Regards,
> > > Rich
> > >
> >
>

Re: [VOTE] KIP-512: make Record Headers available in onAcknowledgement and onComplete

[Lianet M.]

Hi all,

I'll re-cast my vote here :)

+1 (binding)

Thanks Rich!


On Fri, Aug 23, 2024, 10:32 p.m. Chia-Ping Tsai  wrote:

> +1 (binding)
>
> On 2024/08/10 17:28:45 "Rich C." wrote:
> > Hi all,
> >
> > After incorporating the feedback received
> > <https://lists.apache.org/thread/ns5qr66rzvwf26pyp1g1dclo9zr3kp67>, I
> have
> > updated KIP-512 to reflect the majority preference for the new interface
> > approach. The KIP is now in its final form and ready for a vote.
> >
> > Regards,
> > Rich
> >
>

Re: [VOTE] KIP-1065: Add "retry" return-option to ProductionExceptionHandler

[Matthias J. Sax]

+1 (binding)

Closing this VOTE as "accepted" with 3 binding +1 from Sophie, Bill, and 
myself.



Thanks a lot!

-Matthias

On 8/28/24 6:09 PM, Bill Bejeck wrote:

+1 (binding)

On Wed, Aug 28, 2024 at 8:34 PM Sophie Blee-Goldman 
wrote:


Also :

+1 (binding)

On Wed, Aug 28, 2024 at 3:48 PM Sophie Blee-Goldman 


wrote:


Thanks guys. I filed https://issues.apache.org/jira/browse/KAFKA-17441

to

consider a followup KIP for adding RETRY to the other exception

handlers. I

agree we can move on and vote this through

On Thu, Aug 22, 2024 at 11:28 AM Matthias J. Sax 

wrote:



Hi,

given that there was no further feedback, I would like to start a VOTE
for KIP-1038:



https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311627309




-Matthias

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

[Colin McCabe]

matches within the trie.
>> >>
>> >> But in all cases can show that the trie is faster than the current
>> >> implementation.
>> >>
>> >> Claude
>> >>
>> >>
>> >>
>> >> On Wed, Jun 19, 2024 at 7:53 PM Muralidhar Basani
>> >>  wrote:
>> >>
>> >>> There are some test results mentioned in the Test Plan section of the 
>> >>> Kip,
>> >>> but we need to do more testing with various patterns and permission 
>> >>> types.
>> >>> As mentioned in the discuss thread, the trie implementation could
>> >>> potentially surpass the current speed of ACL match.
>> >>>
>> >>> However, we can only accurately assess the results after updating the
>> >>> actual classes and analysing them with AuthorizerBenchmark.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Murali
>> >>>
>> >>> On Mon, 17 Jun 2024 at 20:39, Colin McCabe  wrote:
>> >>>
>> >>> > My concern is that the extra complexity may actually slow us down. In
>> >>> > general people already complain about the speed of ACL matches, and
>> >>> adding
>> >>> > another "degree of freedom" seems likely to make things worse.
>> >>> >
>> >>> > It would be useful to understand how much faster or slower the code is
>> >>> > with the propsed changes, versus without them.
>> >>> >
>> >>> > best,
>> >>> > Colin
>> >>> >
>> >>> >
>> >>> > On Mon, Jun 17, 2024, at 01:26, Muralidhar Basani wrote:
>> >>> > > Hi all,
>> >>> > >
>> >>> > > I would like to call a vote on KIP-1042 which extends creation of 
>> >>> > > acls
>> >>> > with
>> >>> > > MATCH pattern type.
>> >>> > >
>> >>> > > KIP -
>> >>> > >
>> >>> >
>> >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1042%3A+Support+for+wildcard+when+creating+new+acls
>> >>> > >
>> >>> > > Discussion thread -
>> >>> > > https://lists.apache.org/thread/xx3lcg60kp4v34x0j9p6xobby8l4cfq2
>> >>> > >
>> >>> > > Thanks,
>> >>> > > Murali
>> >>> >
>> >>>
>> >>

Re: [VOTE] KIP-1075: Introduce delayed remote list offsets purgatory to make LIST_OFFSETS async

[Kamal Chandraprakash]

Hi all,

The vote is closed. The KIP has been accepted with 4 +1 binding votes
(Satish, Luke, Christo, and Chia-Ping).

Thank you all for the participation!

--
Kamal

On Thu, Aug 29, 2024 at 5:14 PM Chia-Ping Tsai  wrote:

> +1 (binding)
>
> On 2024/08/19 05:09:27 Kamal Chandraprakash wrote:
> > Hi,
> >
> > I would like to open voting for KIP-1075. I've addressed the review
> > comments in the discussion thread. Please vote if the proposal looks
> good.
> >
> >
> https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=315494171#content/view/315494171
> >
> >
> > Thanks,
> > Kamal
> >
>

Re: [VOTE] KIP-1075: Introduce delayed remote list offsets purgatory to make LIST_OFFSETS async

[Chia-Ping Tsai]

+1 (binding)

On 2024/08/19 05:09:27 Kamal Chandraprakash wrote:
> Hi,
> 
> I would like to open voting for KIP-1075. I've addressed the review
> comments in the discussion thread. Please vote if the proposal looks good.
> 
> https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=315494171#content/view/315494171
> 
> 
> Thanks,
> Kamal
> 

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

[Claude Warren, Jr]

Colin,

Thanks for your insightful comments.  I came to the same conclusion.

I do have 2 Jira tickets to simplify some of this.

1)  KAFKA-17316 <https://issues.apache.org/jira/browse/KAFKA-17316> - Makes
developing a new Authorizer by creating a new implementation of the
StandardAuthorizerData easier.  Basically adds interfaces, abstract classes
and lots of tests.

2) KAFKA-17423 <https://issues.apache.org/jira/browse/KAFKA-17423> - Builds
on KAFKA-17316 by creating a Trie implementation (without the new wildcards
from KIP-1042).  This provides an order of magnitude faster processing of
ACL requests.

My plan is to get these through the process, so I have a better
understanding of the Kafka development process, and then rework KIP-1042 to
create a new PatternType with wildcard processing.

I would appreciate your feedback on the above tickets if you have the time.

Claude

On Fri, Aug 23, 2024 at 9:43 PM Colin McCabe  wrote:

> On Sat, Jul 27, 2024, at 04:20, Claude Warren, Jr wrote:
> > I have updated the KIP with results from the Trie implementation and they
> > are dramatic to say the least.  For most searches they are at least an
> > order of magnitude faster and use less memory.  The wildcard search is
> not
> > a regular expression but rather a file type wild card (*=1 or more
> > character, ?=1 character).
> >
>
> Hi Claude,
>
> One issue here is that your change is incompatible. For example, if I have
> a consumer group named '?', and an ALLOW ACL  for '?', this change alters
> the meaning of that ACL. Previously it just ALLOWed '?' Now it allows any
> single-character group. This obviously could be a major security issue for
> people doing upgrades.
>
> (This wouldn't be an issue if we restricted consumer group names to a
> sensible set of characters, like we did with topics. But that ship has
> sailed...)
>
> If you want to add new behavior in a backwards-compatible fashion, your
> best bet probably is to create a new PatternType. Unfortunately this makes
> the complexity issue worse, but I don't see a way around it. Perhaps we can
> deprecate LITERAL and PREFIXED at some future date, if this wildcard thing
> makes them unecessary.
>
> Another issue I see, somewhat related, is that Authorizers are pluggable,
> and probably won't be updated all at once to support this new type. That
> should be fine, but we should document the error that is returned when
> someone tries to create your new-style ACLs with an authorizer that does
> not support them.
>
> > Code is available on my personal branch [1].  It is not fully documented
> > and does not meet the checkstyle requirements yet.  I also modified the
> jmh
> > tests to run the Trie tests and limit the test to the single case
> mentioned
> > in the KIP documentation.
> >
> > If there are no issues with this code, I will complete the documentation
> > and fix the checkstyle and then open a pull request.
>
> It's fine to open a pull request. You can link it on the KIP page. As
> always, we don't want to commit it until the KIP is accepted.
>
> best,
> Colin
>
> >
> > Claude
> >
> > [1]
> https://github.com/Claudenw/kafka/pull/new/KIP-1042_Trie_Implementation
> >
> >
> > On Wed, Jul 3, 2024 at 2:21 PM Claude Warren, Jr  >
> > wrote:
> >
> >> I think that if we put in a trie based system we should be able to halve
> >> the normal searhc times and still be able to locate wild card matches
> very
> >> quickly.  Users should be warned that "head wildcard" matches are slow
> and
> >> to use them sparingly.  I am going to see if I can work out how to do
> >> wildcard matches within the trie.
> >>
> >> But in all cases can show that the trie is faster than the current
> >> implementation.
> >>
> >> Claude
> >>
> >>
> >>
> >> On Wed, Jun 19, 2024 at 7:53 PM Muralidhar Basani
> >>  wrote:
> >>
> >>> There are some test results mentioned in the Test Plan section of the
> Kip,
> >>> but we need to do more testing with various patterns and permission
> types.
> >>> As mentioned in the discuss thread, the trie implementation could
> >>> potentially surpass the current speed of ACL match.
> >>>
> >>> However, we can only accurately assess the results after updating the
> >>> actual classes and analysing them with AuthorizerBenchmark.
> >>>
> >>> Thanks,
> >>>
> >>> Murali
> >>>
> >>> On Mon, 17 Jun 2024 at 20:39, Colin McCabe  

Re: [VOTE] KIP-1078: Remove Leaking Getter Methods in Joined Helper Class

[TengYao Chi]

Hello everyone,

The vote is now closed, and the KIP has been accepted with 4 binding +1s
from Chia-Ping, Matthias, Bill, and Lucas, as well as 1 non-binding +1 from
黃竣陽.

Thank you all for your participation!

Sincerely,
TengYao

Lucas Brutschy  於 2024年8月26日 週一 下午3:37寫道：

> +1 (binding)
>
> On Thu, Aug 22, 2024 at 11:27 PM Bill Bejeck  wrote:
> >
> > +1 (binding)
> >
> > On Thu, Aug 22, 2024 at 2:15 PM Matthias J. Sax 
> wrote:
> >
> > > +1 (binding)
> > >
> > > On 8/21/24 11:09 PM, 黃竣陽 wrote:
> > > > +1 (non-binding)
> > > >
> > > > Best regard,
> > > > Jiunn Yang
> > > >
> > >
>

Re: [VOTE] KIP-1065: Add "retry" return-option to ProductionExceptionHandler

[Bill Bejeck]

+1 (binding)

On Wed, Aug 28, 2024 at 8:34 PM Sophie Blee-Goldman 
wrote:

> Also :
>
> +1 (binding)
>
> On Wed, Aug 28, 2024 at 3:48 PM Sophie Blee-Goldman  >
> wrote:
>
> > Thanks guys. I filed https://issues.apache.org/jira/browse/KAFKA-17441
> to
> > consider a followup KIP for adding RETRY to the other exception
> handlers. I
> > agree we can move on and vote this through
> >
> > On Thu, Aug 22, 2024 at 11:28 AM Matthias J. Sax 
> wrote:
> >
> >> Hi,
> >>
> >> given that there was no further feedback, I would like to start a VOTE
> >> for KIP-1038:
> >>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311627309
> >>
> >>
> >>
> >> -Matthias
> >>
> >
>

Re: [VOTE] KIP-1065: Add "retry" return-option to ProductionExceptionHandler

[Sophie Blee-Goldman]

Also :

+1 (binding)

On Wed, Aug 28, 2024 at 3:48 PM Sophie Blee-Goldman 
wrote:

> Thanks guys. I filed https://issues.apache.org/jira/browse/KAFKA-17441 to
> consider a followup KIP for adding RETRY to the other exception handlers. I
> agree we can move on and vote this through
>
> On Thu, Aug 22, 2024 at 11:28 AM Matthias J. Sax  wrote:
>
>> Hi,
>>
>> given that there was no further feedback, I would like to start a VOTE
>> for KIP-1038:
>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311627309
>>
>>
>>
>> -Matthias
>>
>

Re: [VOTE] KIP-1065: Add "retry" return-option to ProductionExceptionHandler

[Sophie Blee-Goldman]

Thanks guys. I filed https://issues.apache.org/jira/browse/KAFKA-17441 to
consider a followup KIP for adding RETRY to the other exception handlers. I
agree we can move on and vote this through

On Thu, Aug 22, 2024 at 11:28 AM Matthias J. Sax  wrote:

> Hi,
>
> given that there was no further feedback, I would like to start a VOTE
> for KIP-1038:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311627309
>
>
>
> -Matthias
>

[VOTE] KIP-1074: Allow the replication of user internal topics

[Patrik Marton]

Hi all,

As the proposal is finalized, and there was no new feedback in the past
week, I would like to open voting for KIP-1074
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1074%3A+Allow+the+replication+of+user+internal+topics>
.

Please vote / let me know your thoughts.

Thanks,
Patrik

Re: [VOTE] KIP-1075: Introduce delayed remote list offsets purgatory to make LIST_OFFSETS async

[Christo Lolov]

Hello!

Apologies for the late arrival. I read through the KIP and the discussion
thread and I have no concerns with the proposed approach.
This is a great improvement!

+1 from me.

Best,
Christo

On Fri, 23 Aug 2024 at 02:50, Luke Chen  wrote:

> +1 from me.
>
> Thanks.
>
> On Thu, Aug 22, 2024 at 10:27 PM Satish Duggana 
> wrote:
>
> > Thanks Kamal for the KIP, LGTM.
> >
> > +1 from me.
> >
> > On Mon, 19 Aug 2024 at 10:41, Kamal Chandraprakash
> >  wrote:
> > >
> > > Hi,
> > >
> > > I would like to open voting for KIP-1075. I've addressed the review
> > > comments in the discussion thread. Please vote if the proposal looks
> > good.
> > >
> > >
> >
> https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=315494171#content/view/315494171
> > >
> > >
> > > Thanks,
> > > Kamal
> >
>

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[Andrew Schofield]

Thanks for the KIP.

+1 (non-binding)

Andrew

> On 27 Aug 2024, at 10:31, Federico Valeri  wrote:
>
> +1 non binding
>
> Should we also create a Jira to track future removal?
>
> On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai  wrote:
>>
>> +1 (binding)
>>
>> On 2024/08/27 06:15:57 TengYao Chi wrote:
>>> Hi everyone,
>>>
>>> The discussion
>>> <https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j> of
>>> KIP-1079
>>> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand>
>>> has
>>> been silent for a long time, I believe this KIP is now ready for a vote.
>>>
>>> Sincerely,
>>> TengYao
>>>

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[Federico Valeri]

+1 non binding

Should we also create a Jira to track future removal?

On Tue, Aug 27, 2024 at 11:02 AM Chia-Ping Tsai  wrote:
>
> +1 (binding)
>
> On 2024/08/27 06:15:57 TengYao Chi wrote:
> > Hi everyone,
> >
> > The discussion
> > <https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j> of
> > KIP-1079
> > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand>
> > has
> > been silent for a long time, I believe this KIP is now ready for a vote.
> >
> > Sincerely,
> > TengYao
> >

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[Chia-Ping Tsai]

+1 (binding)

On 2024/08/27 06:15:57 TengYao Chi wrote:
> Hi everyone,
> 
> The discussion
> <https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j> of
> KIP-1079
> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand>
> has
> been silent for a long time, I believe this KIP is now ready for a vote.
> 
> Sincerely,
> TengYao
> 

Re: [VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[吳岱儒]

Hi TengYao,

+1(non-bind)

BR,
TaiJuWu

On Tue, Aug 27, 2024 at 2:16 PM TengYao Chi  wrote:

> Hi everyone,
>
> The discussion
> <https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j> of
> KIP-1079
> <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand
> >
> has
> been silent for a long time, I believe this KIP is now ready for a vote.
>
> Sincerely,
> TengYao
>

[VOTE] KIP-1079: Deprecate `delete-config` of TopicCommand

[TengYao Chi]

Hi everyone,

The discussion
<https://lists.apache.org/thread/p4nz31zh6lokw4c1nld9dm0740oxw98j> of
KIP-1079
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-1079:+Deprecate+%60delete-config%60+of+TopicCommand>
has
been silent for a long time, I believe this KIP is now ready for a vote.

Sincerely,
TengYao

Re: [VOTE]: KIP-1050: Consistent error handling for Transactions

[Justine Olshan]

+1 from me

Thanks,

Justine

On Sun, Aug 25, 2024 at 11:54 PM Kaushik Raina 
wrote:

> Hi everyone,
> I would like to start a voting thread for KIP-1050: Consistent error
> handling for Transactions
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1050%3A+Consistent+error+handling+for+Transactions
>
>
> This KIP aims to improve error handling and messages for EoS and therefore
> improve developer experience.
>
> Thanks
> Kaushik Raina
>

Re: [VOTE] KIP-1077: Deprecate `ForeachProcessor` and move to internal package

[Chia-Ping Tsai]

thanks for completing this KIP, Kuan-Po !

Kuan Po Tseng  於 2024年8月26日 週一 下午9:47寫道：

> Hi everyone,
>
> I'm closing this vote with the KIP being accepted with 4 binding +1s from
> Chia-Ping, Lucas, Bruno, and Matthias, along with 2 non-binding +1s from
> TengYao and 黃竣陽.
>
> Thank you all for your participation!
>
> On 2024/08/22 04:09:06 "Matthias J. Sax" wrote:
> > +1 (binding)
> >
> > On 8/19/24 6:14 AM, 黃竣陽 wrote:
> > > Hi Bruno,
> > >
> > > Thanks for your reminder. Sorry for the wrong voting.
> > > I'm +1 (non-binding).
> > >
> > > Best regards,
> > > Jiunn Yang
> >
>

Re: [VOTE] KIP-1077: Deprecate `ForeachProcessor` and move to internal package

[Kuan Po Tseng]

Hi everyone,

I'm closing this vote with the KIP being accepted with 4 binding +1s from 
Chia-Ping, Lucas, Bruno, and Matthias, along with 2 non-binding +1s from 
TengYao and 黃竣陽.

Thank you all for your participation!

On 2024/08/22 04:09:06 "Matthias J. Sax" wrote:
> +1 (binding)
> 
> On 8/19/24 6:14 AM, 黃竣陽 wrote:
> > Hi Bruno,
> > 
> > Thanks for your reminder. Sorry for the wrong voting.
> > I'm +1 (non-binding).
> > 
> > Best regards,
> > Jiunn Yang
> 

Re: [VOTE] KIP-1078: Remove Leaking Getter Methods in Joined Helper Class

[Lucas Brutschy]

+1 (binding)

On Thu, Aug 22, 2024 at 11:27 PM Bill Bejeck  wrote:
>
> +1 (binding)
>
> On Thu, Aug 22, 2024 at 2:15 PM Matthias J. Sax  wrote:
>
> > +1 (binding)
> >
> > On 8/21/24 11:09 PM, 黃竣陽 wrote:
> > > +1 (non-binding)
> > >
> > > Best regard,
> > > Jiunn Yang
> > >
> >

[VOTE]: KIP-1050: Consistent error handling for Transactions

[Kaushik Raina]

Hi everyone,
I would like to start a voting thread for KIP-1050: Consistent error
handling for Transactions
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1050%3A+Consistent+error+handling+for+Transactions


This KIP aims to improve error handling and messages for EoS and therefore
improve developer experience.

Thanks
Kaushik Raina