Re: [ANNOUNCE] New committer: Divij Vaidya

[ziming deng]

Congratulations, Divij!
Well deserved!

--
Ziming

> On Jun 14, 2023, at 09:41, Luke Chen  wrote:
> 
> Congratulations, Divij!
> Well deserved!
> 
> Luke
> 
> On Wed, Jun 14, 2023 at 7:01 AM Viktor Somogyi-Vass
>  wrote:
> 
>> Congrats Divij!
>> 
>> On Tue, Jun 13, 2023, 20:27 Philip Nee  wrote:
>> 
>>> Congrats!
>>> 
>>> On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch  wrote:
>>> 
 Congratulations!
 
 On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax 
>>> wrote:
 
> Congrats!
> 
> On 6/13/23 10:24 AM, Satish Duggana wrote:
>> Congratulations Divij!!
>> 
>> On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
>>  wrote:
>>> 
>>> Congratulations Divij.
>>> 
>>> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna 
 wrote:
>>> 
 Hi all,
 
 The PMC of Apache Kafka is pleased to announce a new Kafka
>>> committer
 Divij Vaidya.
 
 Divij's major contributions are:
 
 GDPR compliance enforcement of kafka-site -
 https://issues.apache.org/jira/browse/KAFKA-13868
 
 Performance improvements:
 
 Improve performance of VarInt encoding and decoding -
 https://github.com/apache/kafka/pull/13312
 
 Reduce data copy & buffer allocation during decompression -
 https://github.com/apache/kafka/pull/13135
 
 He also was heavily involved in the migration to Mockito.
 
 Furthermore, Divij is very active on the mailing lists as well as
>>> in
 maintaining and reviewing pull requests.
 
 Congratulations, Divij!
 
 Thanks,
 
 Bruno (on behalf of the Apache Kafka PMC)
 
 
 --
>>> Manyanda Chitimbo.
> 
 
>>> 
>> 

[ANNOUNCE] New committer: Divij Vaidya

[hudeqi]

Congratulations! Divij!


> -原始邮件-
> 发件人: "Joobi S.B" 
> 发送时间: 2023-06-14 00:49:57 (星期三)
> 收件人: dev@kafka.apache.org
> 抄送: 
> 主题: Re: [ANNOUNCE] New committer: Divij Vaidya
> 

Re: [ANNOUNCE] New committer: Divij Vaidya

[Luke Chen]

Congratulations, Divij!
Well deserved!

Luke

On Wed, Jun 14, 2023 at 7:01 AM Viktor Somogyi-Vass
 wrote:

> Congrats Divij!
>
> On Tue, Jun 13, 2023, 20:27 Philip Nee  wrote:
>
> > Congrats!
> >
> > On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch  wrote:
> >
> > > Congratulations!
> > >
> > > On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax 
> > wrote:
> > >
> > > > Congrats!
> > > >
> > > > On 6/13/23 10:24 AM, Satish Duggana wrote:
> > > > > Congratulations Divij!!
> > > > >
> > > > > On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> > > > >  wrote:
> > > > >>
> > > > >> Congratulations Divij.
> > > > >>
> > > > >> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna 
> > > wrote:
> > > > >>
> > > > >>> Hi all,
> > > > >>>
> > > > >>> The PMC of Apache Kafka is pleased to announce a new Kafka
> > committer
> > > > >>> Divij Vaidya.
> > > > >>>
> > > > >>> Divij's major contributions are:
> > > > >>>
> > > > >>> GDPR compliance enforcement of kafka-site -
> > > > >>> https://issues.apache.org/jira/browse/KAFKA-13868
> > > > >>>
> > > > >>> Performance improvements:
> > > > >>>
> > > > >>> Improve performance of VarInt encoding and decoding -
> > > > >>> https://github.com/apache/kafka/pull/13312
> > > > >>>
> > > > >>> Reduce data copy & buffer allocation during decompression -
> > > > >>> https://github.com/apache/kafka/pull/13135
> > > > >>>
> > > > >>> He also was heavily involved in the migration to Mockito.
> > > > >>>
> > > > >>> Furthermore, Divij is very active on the mailing lists as well as
> > in
> > > > >>> maintaining and reviewing pull requests.
> > > > >>>
> > > > >>> Congratulations, Divij!
> > > > >>>
> > > > >>> Thanks,
> > > > >>>
> > > > >>> Bruno (on behalf of the Apache Kafka PMC)
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >> Manyanda Chitimbo.
> > > >
> > >
> >
>

Re: [ANNOUNCE] New committer: Divij Vaidya

[Viktor Somogyi-Vass]

Congrats Divij!

On Tue, Jun 13, 2023, 20:27 Philip Nee  wrote:

> Congrats!
>
> On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch  wrote:
>
> > Congratulations!
> >
> > On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax 
> wrote:
> >
> > > Congrats!
> > >
> > > On 6/13/23 10:24 AM, Satish Duggana wrote:
> > > > Congratulations Divij!!
> > > >
> > > > On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> > > >  wrote:
> > > >>
> > > >> Congratulations Divij.
> > > >>
> > > >> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna 
> > wrote:
> > > >>
> > > >>> Hi all,
> > > >>>
> > > >>> The PMC of Apache Kafka is pleased to announce a new Kafka
> committer
> > > >>> Divij Vaidya.
> > > >>>
> > > >>> Divij's major contributions are:
> > > >>>
> > > >>> GDPR compliance enforcement of kafka-site -
> > > >>> https://issues.apache.org/jira/browse/KAFKA-13868
> > > >>>
> > > >>> Performance improvements:
> > > >>>
> > > >>> Improve performance of VarInt encoding and decoding -
> > > >>> https://github.com/apache/kafka/pull/13312
> > > >>>
> > > >>> Reduce data copy & buffer allocation during decompression -
> > > >>> https://github.com/apache/kafka/pull/13135
> > > >>>
> > > >>> He also was heavily involved in the migration to Mockito.
> > > >>>
> > > >>> Furthermore, Divij is very active on the mailing lists as well as
> in
> > > >>> maintaining and reviewing pull requests.
> > > >>>
> > > >>> Congratulations, Divij!
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>> Bruno (on behalf of the Apache Kafka PMC)
> > > >>>
> > > >>>
> > > >>> --
> > > >> Manyanda Chitimbo.
> > >
> >
>

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #1921

[Apache Jenkins Server]

See 

Re: [ANNOUNCE] New committer: Divij Vaidya

[Philip Nee]

Congrats!

On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch  wrote:

> Congratulations!
>
> On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax  wrote:
>
> > Congrats!
> >
> > On 6/13/23 10:24 AM, Satish Duggana wrote:
> > > Congratulations Divij!!
> > >
> > > On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> > >  wrote:
> > >>
> > >> Congratulations Divij.
> > >>
> > >> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna 
> wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> The PMC of Apache Kafka is pleased to announce a new Kafka committer
> > >>> Divij Vaidya.
> > >>>
> > >>> Divij's major contributions are:
> > >>>
> > >>> GDPR compliance enforcement of kafka-site -
> > >>> https://issues.apache.org/jira/browse/KAFKA-13868
> > >>>
> > >>> Performance improvements:
> > >>>
> > >>> Improve performance of VarInt encoding and decoding -
> > >>> https://github.com/apache/kafka/pull/13312
> > >>>
> > >>> Reduce data copy & buffer allocation during decompression -
> > >>> https://github.com/apache/kafka/pull/13135
> > >>>
> > >>> He also was heavily involved in the migration to Mockito.
> > >>>
> > >>> Furthermore, Divij is very active on the mailing lists as well as in
> > >>> maintaining and reviewing pull requests.
> > >>>
> > >>> Congratulations, Divij!
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Bruno (on behalf of the Apache Kafka PMC)
> > >>>
> > >>>
> > >>> --
> > >> Manyanda Chitimbo.
> >
>

Re: [ANNOUNCE] New committer: Divij Vaidya

[Randall Hauch]

Congratulations!

On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax  wrote:

> Congrats!
>
> On 6/13/23 10:24 AM, Satish Duggana wrote:
> > Congratulations Divij!!
> >
> > On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> >  wrote:
> >>
> >> Congratulations Divij.
> >>
> >> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna  wrote:
> >>
> >>> Hi all,
> >>>
> >>> The PMC of Apache Kafka is pleased to announce a new Kafka committer
> >>> Divij Vaidya.
> >>>
> >>> Divij's major contributions are:
> >>>
> >>> GDPR compliance enforcement of kafka-site -
> >>> https://issues.apache.org/jira/browse/KAFKA-13868
> >>>
> >>> Performance improvements:
> >>>
> >>> Improve performance of VarInt encoding and decoding -
> >>> https://github.com/apache/kafka/pull/13312
> >>>
> >>> Reduce data copy & buffer allocation during decompression -
> >>> https://github.com/apache/kafka/pull/13135
> >>>
> >>> He also was heavily involved in the migration to Mockito.
> >>>
> >>> Furthermore, Divij is very active on the mailing lists as well as in
> >>> maintaining and reviewing pull requests.
> >>>
> >>> Congratulations, Divij!
> >>>
> >>> Thanks,
> >>>
> >>> Bruno (on behalf of the Apache Kafka PMC)
> >>>
> >>>
> >>> --
> >> Manyanda Chitimbo.
>

Re: First Contribution

[Lovish Madhu]

Looks good, but I am also a newbie.

However I feel like variables such as n = 10 as some meaningful variable
name as it is global constant.
Also you forgot to use n and instead used 10
here: refreshed_collaborators[:10]

On Tue, Jun 13, 2023 at 11:23 PM Steven Booke 
wrote:

> To whom this may concern,
>
> This is my first time contributing and I have just submitted my first PR. I
> have made changes to both apache/kafka-site and apache/kafka repos. I
> believe I have followed the detailed instructions for contributing a code
> change and am looking for feedback.
>
> Here are the PRs for reference: https://github.com/apache/kafka/pull/13842
> and https://github.com/apache/kafka-site/pull/521
>
> Here is the JIRA ticket for reference:
> https://issues.apache.org/jira/browse/KAFKA-14995
>
> --
> Regards
>
> Steven Booke
>

First Contribution

[Steven Booke]

To whom this may concern,

This is my first time contributing and I have just submitted my first PR. I
have made changes to both apache/kafka-site and apache/kafka repos. I
believe I have followed the detailed instructions for contributing a code
change and am looking for feedback.

Here are the PRs for reference: https://github.com/apache/kafka/pull/13842
 and https://github.com/apache/kafka-site/pull/521

Here is the JIRA ticket for reference:
https://issues.apache.org/jira/browse/KAFKA-14995

-- 
Regards

Steven Booke

First Contribution

[Steven Booke]

To whom this may concern,

This is my first time contributing and I have just submitted my first PR. I
have made changes to both apache/kafka-site and apache/kafka repos. I
believe I have followed the detailed instructions for contributing a code
change and am looking for feedback.

Here are the PRs for reference: https://github.com/apache/kafka/pull/13842
and https://github.com/apache/kafka-site/pull/521

Here is the JIRA ticket for reference:
https://issues.apache.org/jira/browse/KAFKA-14995

-- 
Regards

Steven Booke

Re: [ANNOUNCE] New committer: Divij Vaidya

[Matthias J. Sax]

Congrats!

On 6/13/23 10:24 AM, Satish Duggana wrote:

Congratulations Divij!!

On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
 wrote:


Congratulations Divij.

On Tue 13 Jun 2023 at 17:50, Bruno Cadonna  wrote:


Hi all,

The PMC of Apache Kafka is pleased to announce a new Kafka committer
Divij Vaidya.

Divij's major contributions are:

GDPR compliance enforcement of kafka-site -
https://issues.apache.org/jira/browse/KAFKA-13868

Performance improvements:

Improve performance of VarInt encoding and decoding -
https://github.com/apache/kafka/pull/13312

Reduce data copy & buffer allocation during decompression -
https://github.com/apache/kafka/pull/13135

He also was heavily involved in the migration to Mockito.

Furthermore, Divij is very active on the mailing lists as well as in
maintaining and reviewing pull requests.

Congratulations, Divij!

Thanks,

Bruno (on behalf of the Apache Kafka PMC)


--

Manyanda Chitimbo.

Re: [ANNOUNCE] New committer: Divij Vaidya

[Satish Duggana]

Congratulations Divij!!

On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
 wrote:
>
> Congratulations Divij.
>
> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna  wrote:
>
> > Hi all,
> >
> > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> > Divij Vaidya.
> >
> > Divij's major contributions are:
> >
> > GDPR compliance enforcement of kafka-site -
> > https://issues.apache.org/jira/browse/KAFKA-13868
> >
> > Performance improvements:
> >
> > Improve performance of VarInt encoding and decoding -
> > https://github.com/apache/kafka/pull/13312
> >
> > Reduce data copy & buffer allocation during decompression -
> > https://github.com/apache/kafka/pull/13135
> >
> > He also was heavily involved in the migration to Mockito.
> >
> > Furthermore, Divij is very active on the mailing lists as well as in
> > maintaining and reviewing pull requests.
> >
> > Congratulations, Divij!
> >
> > Thanks,
> >
> > Bruno (on behalf of the Apache Kafka PMC)
> >
> >
> > --
> Manyanda Chitimbo.

Re: [ANNOUNCE] New committer: Divij Vaidya

[Manyanda Chitimbo]

Congratulations Divij.

On Tue 13 Jun 2023 at 17:50, Bruno Cadonna  wrote:

> Hi all,
>
> The PMC of Apache Kafka is pleased to announce a new Kafka committer
> Divij Vaidya.
>
> Divij's major contributions are:
>
> GDPR compliance enforcement of kafka-site -
> https://issues.apache.org/jira/browse/KAFKA-13868
>
> Performance improvements:
>
> Improve performance of VarInt encoding and decoding -
> https://github.com/apache/kafka/pull/13312
>
> Reduce data copy & buffer allocation during decompression -
> https://github.com/apache/kafka/pull/13135
>
> He also was heavily involved in the migration to Mockito.
>
> Furthermore, Divij is very active on the mailing lists as well as in
> maintaining and reviewing pull requests.
>
> Congratulations, Divij!
>
> Thanks,
>
> Bruno (on behalf of the Apache Kafka PMC)
>
>
> --
Manyanda Chitimbo.

Re: [ANNOUNCE] New committer: Divij Vaidya

[Andrew Schofield]

Congratulations. Always good to see new committers.

> On 13 Jun 2023, at 17:15, Mickael Maison  wrote:
>
> Congratulations!
>
> On Tue, Jun 13, 2023 at 6:05 PM Yash Mayya  wrote:
>>
>> Congratulations Divij!
>>
>> On Tue, Jun 13, 2023 at 9:20 PM Bruno Cadonna  wrote:
>>
>>> Hi all,
>>>
>>> The PMC of Apache Kafka is pleased to announce a new Kafka committer
>>> Divij Vaidya.
>>>
>>> Divij's major contributions are:
>>>
>>> GDPR compliance enforcement of kafka-site -
>>> https://issues.apache.org/jira/browse/KAFKA-13868
>>>
>>> Performance improvements:
>>>
>>> Improve performance of VarInt encoding and decoding -
>>> https://github.com/apache/kafka/pull/13312
>>>
>>> Reduce data copy & buffer allocation during decompression -
>>> https://github.com/apache/kafka/pull/13135
>>>
>>> He also was heavily involved in the migration to Mockito.
>>>
>>> Furthermore, Divij is very active on the mailing lists as well as in
>>> maintaining and reviewing pull requests.
>>>
>>> Congratulations, Divij!
>>>
>>> Thanks,
>>>
>>> Bruno (on behalf of the Apache Kafka PMC)
>>>
>>>
>>>

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.5 #20

[Apache Jenkins Server]

See 

Re: [ANNOUNCE] New committer: Divij Vaidya

[Joobi S.B]

Congratulations !

On Tue, Jun 13, 2023 at 10:15 PM David Arthur
 wrote:

> Congrats Divij!
>
> On Tue, Jun 13, 2023 at 12:34 PM Igor Soarez  wrote:
>
> > Congratulations Divij!
> >
> > --
> > Igor
> >
>
>
> --
> -David
>

Re: [ANNOUNCE] New committer: Divij Vaidya

[John Roesler]

Congratulations, Divij!
-John

On Tue, Jun 13, 2023, at 09:44, David Arthur wrote:
> Congrats Divij!
>
> On Tue, Jun 13, 2023 at 12:34 PM Igor Soarez  wrote:
>
>> Congratulations Divij!
>>
>> --
>> Igor
>>
>
>
> -- 
> -David

Re: [ANNOUNCE] New committer: Divij Vaidya

[Chia-Ping Tsai]

Congratulations Divij :)

> David Arthur  於 2023年6月14日 上午12:44 寫道：
> 
> Congrats Divij!
> 
> On Tue, Jun 13, 2023 at 12:34 PM Igor Soarez  wrote:
> 
>> Congratulations Divij!
>> 
>> --
>> Igor
>> 
> 
> 
> -- 
> -David

Re: [ANNOUNCE] New committer: Divij Vaidya

[David Arthur]

Congrats Divij!

On Tue, Jun 13, 2023 at 12:34 PM Igor Soarez  wrote:

> Congratulations Divij!
>
> --
> Igor
>


-- 
-David

Re: Contributing to Kafka

[Joobi S.B]

Sure. Thank you !

On Tue, Jun 13, 2023 at 6:34 AM Luke Chen  wrote:

> Hi Joobi,
>
> Thanks for the interest in Apache Kafka.
> You can read the contributor guide here first:
> https://kafka.apache.org/contributing
> And find tickets you're interested from JIRA:
> https://issues.apache.org/jira/projects/KAFKA/
>
> Let us know if you have any questions.
> Thank you.
> Luke
>
> On Tue, Jun 13, 2023 at 1:26 AM Joobi S.B  wrote:
> >
> > Dear all,
> >
> > My name is Joobi and I am a software engineer with experience in working
> > with Kafka. I am reaching out to express my keen interest in contributing
> > to Kafka. Currently, I'm going through the source code and the official
> > documentation to better understand the project.
> >
> > I would greatly appreciate any guidance you can provide on how to get
> > started with contributing to the project.
> >
> > Best Regards,
> > Joobi
>

Re: [ANNOUNCE] New committer: Divij Vaidya

[Igor Soarez]

Congratulations Divij!

--
Igor

Re: [ANNOUNCE] New committer: Divij Vaidya

[Jorge Esteban Quilcate Otoya]

Awesome news! Congrats Divij!

On Tue 13. Jun 2023 at 19.30, Tom Bentley  wrote:

> Congratulations Divij!
>
> On Tue, 13 Jun 2023 at 17:21, Mickael Maison 
> wrote:
>
> > Congratulations!
> >
> > On Tue, Jun 13, 2023 at 6:05 PM Yash Mayya  wrote:
> > >
> > > Congratulations Divij!
> > >
> > > On Tue, Jun 13, 2023 at 9:20 PM Bruno Cadonna 
> > wrote:
> > >
> > > > Hi all,
> > > >
> > > > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> > > > Divij Vaidya.
> > > >
> > > > Divij's major contributions are:
> > > >
> > > > GDPR compliance enforcement of kafka-site -
> > > > https://issues.apache.org/jira/browse/KAFKA-13868
> > > >
> > > > Performance improvements:
> > > >
> > > > Improve performance of VarInt encoding and decoding -
> > > > https://github.com/apache/kafka/pull/13312
> > > >
> > > > Reduce data copy & buffer allocation during decompression -
> > > > https://github.com/apache/kafka/pull/13135
> > > >
> > > > He also was heavily involved in the migration to Mockito.
> > > >
> > > > Furthermore, Divij is very active on the mailing lists as well as in
> > > > maintaining and reviewing pull requests.
> > > >
> > > > Congratulations, Divij!
> > > >
> > > > Thanks,
> > > >
> > > > Bruno (on behalf of the Apache Kafka PMC)
> > > >
> > > >
> > > >
> >
> >
>

Re: [ANNOUNCE] New committer: Divij Vaidya

[Tom Bentley]

Congratulations Divij!

On Tue, 13 Jun 2023 at 17:21, Mickael Maison 
wrote:

> Congratulations!
>
> On Tue, Jun 13, 2023 at 6:05 PM Yash Mayya  wrote:
> >
> > Congratulations Divij!
> >
> > On Tue, Jun 13, 2023 at 9:20 PM Bruno Cadonna 
> wrote:
> >
> > > Hi all,
> > >
> > > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> > > Divij Vaidya.
> > >
> > > Divij's major contributions are:
> > >
> > > GDPR compliance enforcement of kafka-site -
> > > https://issues.apache.org/jira/browse/KAFKA-13868
> > >
> > > Performance improvements:
> > >
> > > Improve performance of VarInt encoding and decoding -
> > > https://github.com/apache/kafka/pull/13312
> > >
> > > Reduce data copy & buffer allocation during decompression -
> > > https://github.com/apache/kafka/pull/13135
> > >
> > > He also was heavily involved in the migration to Mockito.
> > >
> > > Furthermore, Divij is very active on the mailing lists as well as in
> > > maintaining and reviewing pull requests.
> > >
> > > Congratulations, Divij!
> > >
> > > Thanks,
> > >
> > > Bruno (on behalf of the Apache Kafka PMC)
> > >
> > >
> > >
>
>

Re: [ANNOUNCE] New committer: Divij Vaidya

[Kirk True]

Congrats Well deserved!

On Tue, Jun 13, 2023, at 9:22 AM, Greg Harris wrote:
> Congratulations!
> 
> On Tue, Jun 13, 2023 at 9:15 AM Mickael Maison  
> wrote:
> >
> > Congratulations!
> >
> > On Tue, Jun 13, 2023 at 6:05 PM Yash Mayya  wrote:
> > >
> > > Congratulations Divij!
> > >
> > > On Tue, Jun 13, 2023 at 9:20 PM Bruno Cadonna  wrote:
> > >
> > > > Hi all,
> > > >
> > > > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> > > > Divij Vaidya.
> > > >
> > > > Divij's major contributions are:
> > > >
> > > > GDPR compliance enforcement of kafka-site -
> > > > https://issues.apache.org/jira/browse/KAFKA-13868
> > > >
> > > > Performance improvements:
> > > >
> > > > Improve performance of VarInt encoding and decoding -
> > > > https://github.com/apache/kafka/pull/13312
> > > >
> > > > Reduce data copy & buffer allocation during decompression -
> > > > https://github.com/apache/kafka/pull/13135
> > > >
> > > > He also was heavily involved in the migration to Mockito.
> > > >
> > > > Furthermore, Divij is very active on the mailing lists as well as in
> > > > maintaining and reviewing pull requests.
> > > >
> > > > Congratulations, Divij!
> > > >
> > > > Thanks,
> > > >
> > > > Bruno (on behalf of the Apache Kafka PMC)
> > > >
> > > >
> > > >
> 

Re: [ANNOUNCE] New committer: Divij Vaidya

[Greg Harris]

Congratulations!

On Tue, Jun 13, 2023 at 9:15 AM Mickael Maison  wrote:
>
> Congratulations!
>
> On Tue, Jun 13, 2023 at 6:05 PM Yash Mayya  wrote:
> >
> > Congratulations Divij!
> >
> > On Tue, Jun 13, 2023 at 9:20 PM Bruno Cadonna  wrote:
> >
> > > Hi all,
> > >
> > > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> > > Divij Vaidya.
> > >
> > > Divij's major contributions are:
> > >
> > > GDPR compliance enforcement of kafka-site -
> > > https://issues.apache.org/jira/browse/KAFKA-13868
> > >
> > > Performance improvements:
> > >
> > > Improve performance of VarInt encoding and decoding -
> > > https://github.com/apache/kafka/pull/13312
> > >
> > > Reduce data copy & buffer allocation during decompression -
> > > https://github.com/apache/kafka/pull/13135
> > >
> > > He also was heavily involved in the migration to Mockito.
> > >
> > > Furthermore, Divij is very active on the mailing lists as well as in
> > > maintaining and reviewing pull requests.
> > >
> > > Congratulations, Divij!
> > >
> > > Thanks,
> > >
> > > Bruno (on behalf of the Apache Kafka PMC)
> > >
> > >
> > >

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #1920

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 470731 lines...]
[2023-06-13T10:43:10.947Z] 
[2023-06-13T10:43:10.947Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorManyStandbys STARTED
[2023-06-13T10:43:19.716Z] 
[2023-06-13T10:43:19.716Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorManyStandbys PASSED
[2023-06-13T10:43:19.716Z] 
[2023-06-13T10:43:19.716Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorManyThreadsPerClient STARTED
[2023-06-13T10:43:20.823Z] 
[2023-06-13T10:43:20.823Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorManyThreadsPerClient PASSED
[2023-06-13T10:43:20.823Z] 
[2023-06-13T10:43:20.823Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorManyThreadsPerClient STARTED
[2023-06-13T10:43:21.762Z] 
[2023-06-13T10:43:21.762Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorManyThreadsPerClient PASSED
[2023-06-13T10:43:21.762Z] 
[2023-06-13T10:43:21.762Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorLargePartitionCount STARTED
[2023-06-13T10:43:52.460Z] 
[2023-06-13T10:43:52.460Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorLargePartitionCount PASSED
[2023-06-13T10:43:52.460Z] 
[2023-06-13T10:43:52.460Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorLargePartitionCount STARTED
[2023-06-13T10:44:18.709Z] 
[2023-06-13T10:44:18.709Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorLargePartitionCount PASSED
[2023-06-13T10:44:18.709Z] 
[2023-06-13T10:44:18.709Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorManyStandbys STARTED
[2023-06-13T10:44:22.290Z] 
[2023-06-13T10:44:22.290Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorManyStandbys PASSED
[2023-06-13T10:44:22.290Z] 
[2023-06-13T10:44:22.290Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvailabilityTaskAssignorManyStandbys STARTED
[2023-06-13T10:44:41.806Z] 
[2023-06-13T10:44:41.806Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvailabilityTaskAssignorManyStandbys PASSED
[2023-06-13T10:44:41.806Z] 
[2023-06-13T10:44:41.806Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorLargeNumConsumers STARTED
[2023-06-13T10:44:42.914Z] 
[2023-06-13T10:44:42.914Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorLargeNumConsumers PASSED
[2023-06-13T10:44:42.914Z] 
[2023-06-13T10:44:42.914Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorLargeNumConsumers STARTED
[2023-06-13T10:44:45.548Z] 
[2023-06-13T10:44:45.548Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorLargeNumConsumers PASSED
[2023-06-13T10:44:45.548Z] 
[2023-06-13T10:44:45.548Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > EmitOnChangeIntegrationTest > 
shouldEmitSameRecordAfterFailover() STARTED
[2023-06-13T10:44:50.338Z] 
[2023-06-13T10:44:50.338Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > EmitOnChangeIntegrationTest > 
shouldEmitSameRecordAfterFailover() PASSED
[2023-06-13T10:44:51.277Z] 
[2023-06-13T10:44:51.277Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > HighAvailabilityTaskAssignorIntegrationTest > 
shouldScaleOutWithWarmupTasksAndPersistentStores(TestInfo) STARTED
[2023-06-13T10:46:11.105Z] 
[2023-06-13T10:46:11.105Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > HighAvailabilityTaskAssignorIntegrationTest > 
shouldScaleOutWithWarmupTasksAndPersistentStores(TestInfo) PASSED
[2023-06-13T10:46:11.105Z] 
[2023-06-13T10:46:11.105Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > HighAvailabilityTaskAssignorIntegrationTest > 
shouldScaleOutWithWarmupTasksAndInMemorySto

Re: [DISCUSS] Partial CI builds - Reducing flakiness with fewer tests

[Greg Harris]

David,

Thanks for finding that gradle plugin. The `changedModules` mode is
exactly what I had in mind for fairness to modules earlier in the
dependency graph.

> if we moved to a policy where PRs only need some of the tests to pass
> to merge, when would we run the full CI? On each trunk commit (i.e., PR
> merge)?

In a world where the PR runs includes only the changed modules and
their dependencies, the full suite should be run for each commit on
trunk and on release branches. I don't think that optimizing the trunk
build runtime is of great benefit, and the current behavior seems
reasonable to continue.

> How would we handle commits that break the integration tests? Would
> we revert commits on trunk, or fix-forward?

This is currently up to committer discretion, and I don't think that
would change if we were to re-tool the PR builds. In the presence of
flaky failures, we can't reliably blame failures on particular commits
without running much more expensive statistical tests.

One place that I often see flakiness present is in new tests, where
someone has chosen timeouts which work for them locally and in the PR
build. After some 10s or 100s of runs, the flakiness becomes evident
and someone looks into a fix-forward.
I don't necessarily think I would advocate for a hard revert of an
entire feature if one of the added tests is flaky, but that's my
discretion. We can adopt a project policy of reverting whatever we
can, but I don't think that's a more welcoming or productive project
than we have now.

Greg

On Tue, Jun 13, 2023 at 7:24 AM David Arthur  wrote:
>
> Hey folks, interesting discussion.
>
> I came across a Gradle plugin that calculates a DAG of modules based on the
> diff and can run only the affected module's tests or the affected +
> downstream tests.
>
> https://github.com/dropbox/AffectedModuleDetector
>
> I tested it out locally, and it seems to work as advertised.
>
> Greg, if we moved to a policy where PRs only need some of the tests to pass
> to merge, when would we run the full CI? On each trunk commit (i.e., PR
> merge)? How would we handle commits that break the integration tests? Would
> we revert commits on trunk, or fix-forward?
>
> -David
>
>
> On Thu, Jun 8, 2023 at 2:02 PM Greg Harris 
> wrote:
>
> > Gaurav,
> >
> > The target-determinator is certainly the "off-the-shelf" solution I
> > expected would be out there. If the project migrates to Bazel I think
> > that would make the partial builds much easier to implement.
> > I think we should look into the other benefits of migrating to bazel
> > to see if it is worth it even if the partial builds feature is decided
> > against, or after it is reverted.
> >
> > Chris,
> >
> > > Do you think we should aim to disable
> > > merges without a full suite of passing CI runs (allowing for
> > administrative
> > > override in an emergency)? If so, what would the path be from our current
> > > state to there? What can we do to ensure that we don't get stuck relying
> > on
> > > a once-temporary aid that becomes effectively permanent?
> >
> > Yes I think it would be nice to require a green build to merge,
> > without excessive merge-queue infrastructure that is more common in
> > high-volume monorepos.
> >
> > 1. We would decide on a sunset date on the partial build indicator, at
> > which point it will be disabled on trunk and all release branches. I
> > suspect that a sunset date could be set for 1-3 releases in the
> > future.
> > 2. We would enable partial builds. The merge-button would remain
> > as-is, with the partial build and full-suite indicators both being
> > visible.
> > 3. Communication would be sent out to explain that the partial build
> > indicators are a temporary flakiness reduction tool.
> > 4. Committers would continue to rely on the full-suite indicators, and
> > watch the partial build to get a sense of the level of flakiness in
> > each module.
> > 5. On new contributions which have failing partial builds, Committers
> > can ask that contributors investigate and follow-up on flaky failures
> > that appeared in their PR, explaining that they can help make that
> > indicator green for future contributions.
> > 6. After the sunset date passes, the partial build indicators will be
> > disabled.
> > 7. If the main trunk build is sufficiently reliable by some criteria
> > (e.g. 20 passes in a row) we can discuss requiring a green build for
> > the GitHub merge button.
> >
> > > We probably
> > > want to build awareness of this dependency graph into any partial CI
> > logic
> > > we add, but if we do opt for that, then this change would
> > > disproportionately benefit downstream modules (Streams, Connect, MM2),
> > and
> > > have little to no benefit for upstream ones (clients and at least some
> > core
> > > modules).
> >
> > I considered that, and I think it is more beneficial to provide
> > equitable partial builds than ones with perfect coverage. If you want
> > to know about cross-module failures, I think that the fu

Re: [ANNOUNCE] New committer: Divij Vaidya

[Mickael Maison]

Congratulations!

On Tue, Jun 13, 2023 at 6:05 PM Yash Mayya  wrote:
>
> Congratulations Divij!
>
> On Tue, Jun 13, 2023 at 9:20 PM Bruno Cadonna  wrote:
>
> > Hi all,
> >
> > The PMC of Apache Kafka is pleased to announce a new Kafka committer
> > Divij Vaidya.
> >
> > Divij's major contributions are:
> >
> > GDPR compliance enforcement of kafka-site -
> > https://issues.apache.org/jira/browse/KAFKA-13868
> >
> > Performance improvements:
> >
> > Improve performance of VarInt encoding and decoding -
> > https://github.com/apache/kafka/pull/13312
> >
> > Reduce data copy & buffer allocation during decompression -
> > https://github.com/apache/kafka/pull/13135
> >
> > He also was heavily involved in the migration to Mockito.
> >
> > Furthermore, Divij is very active on the mailing lists as well as in
> > maintaining and reviewing pull requests.
> >
> > Congratulations, Divij!
> >
> > Thanks,
> >
> > Bruno (on behalf of the Apache Kafka PMC)
> >
> >
> >

Re: [ANNOUNCE] New committer: Divij Vaidya

[Yash Mayya]

Congratulations Divij!

On Tue, Jun 13, 2023 at 9:20 PM Bruno Cadonna  wrote:

> Hi all,
>
> The PMC of Apache Kafka is pleased to announce a new Kafka committer
> Divij Vaidya.
>
> Divij's major contributions are:
>
> GDPR compliance enforcement of kafka-site -
> https://issues.apache.org/jira/browse/KAFKA-13868
>
> Performance improvements:
>
> Improve performance of VarInt encoding and decoding -
> https://github.com/apache/kafka/pull/13312
>
> Reduce data copy & buffer allocation during decompression -
> https://github.com/apache/kafka/pull/13135
>
> He also was heavily involved in the migration to Mockito.
>
> Furthermore, Divij is very active on the mailing lists as well as in
> maintaining and reviewing pull requests.
>
> Congratulations, Divij!
>
> Thanks,
>
> Bruno (on behalf of the Apache Kafka PMC)
>
>
>

[ANNOUNCE] New committer: Divij Vaidya

[Bruno Cadonna]

Hi all,

The PMC of Apache Kafka is pleased to announce a new Kafka committer 
Divij Vaidya.


Divij's major contributions are:

GDPR compliance enforcement of kafka-site -
https://issues.apache.org/jira/browse/KAFKA-13868

Performance improvements:

Improve performance of VarInt encoding and decoding -
https://github.com/apache/kafka/pull/13312

Reduce data copy & buffer allocation during decompression -
https://github.com/apache/kafka/pull/13135

He also was heavily involved in the migration to Mockito.

Furthermore, Divij is very active on the mailing lists as well as in 
maintaining and reviewing pull requests.


Congratulations, Divij!

Thanks,

Bruno (on behalf of the Apache Kafka PMC)

[DISCUSS] KIP-714: Client metrics and observability

[Andrew Schofield]

Hi,
I would like to start a new discussion thread on KIP-714: Client metrics and 
observability.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-714%3A+Client+metrics+and+observability

I have edited the proposal significantly to reduce the scope. The overall 
mechanism for client metric subscriptions is unchanged, but the
KIP is now based on the existing client metrics, rather than introducing new 
metrics. The purpose remains helping cluster operators
investigate performance problems experienced by clients without requiring 
changes to the client application code or configuration.

Thanks,
Andrew

[jira] [Created] (KAFKA-15084) Remove lock contention in RemoteIndexCache

[Divij Vaidya (Jira)]

Divij Vaidya created KAFKA-15084:


 Summary: Remove lock contention in RemoteIndexCache
 Key: KAFKA-15084
 URL: https://issues.apache.org/jira/browse/KAFKA-15084
 Project: Kafka
  Issue Type: Sub-task
  Components: core
Affects Versions: 3.6.0
Reporter: Divij Vaidya
Assignee: Divij Vaidya
 Fix For: 3.6.0


RemoteIndexCache cache is accessed from multiple threads concurrently in the 
fetch from consumer code path [1]. 

Currently, the RemoteIndexCache uses LinkedHashMap as the cache implementation 
internally. Since LinkedHashMap is not a thread safe data structure, we use 
coarse grained lock on the entire map/cache when writing to the cache.

This means that if a thread if fetching information from a particular segment 
from RemoteStorageManager, other threads who are trying to access a different 
segment from the cache will also wait for the former thread to complete. This 
is due to the usage of global lock in the cache.

This lock contentions leads to decrease in throughput for fetch from consumer 
for cases where RSM network call may take more time.

As a goal for this JIRA, we would like to ensure that the threads reading 
existing values in the cache do not get blocked when thread updating the cache 
is fetching data.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] Partial CI builds - Reducing flakiness with fewer tests

[David Arthur]

Hey folks, interesting discussion.

I came across a Gradle plugin that calculates a DAG of modules based on the
diff and can run only the affected module's tests or the affected +
downstream tests.

https://github.com/dropbox/AffectedModuleDetector

I tested it out locally, and it seems to work as advertised.

Greg, if we moved to a policy where PRs only need some of the tests to pass
to merge, when would we run the full CI? On each trunk commit (i.e., PR
merge)? How would we handle commits that break the integration tests? Would
we revert commits on trunk, or fix-forward?

-David


On Thu, Jun 8, 2023 at 2:02 PM Greg Harris 
wrote:

> Gaurav,
>
> The target-determinator is certainly the "off-the-shelf" solution I
> expected would be out there. If the project migrates to Bazel I think
> that would make the partial builds much easier to implement.
> I think we should look into the other benefits of migrating to bazel
> to see if it is worth it even if the partial builds feature is decided
> against, or after it is reverted.
>
> Chris,
>
> > Do you think we should aim to disable
> > merges without a full suite of passing CI runs (allowing for
> administrative
> > override in an emergency)? If so, what would the path be from our current
> > state to there? What can we do to ensure that we don't get stuck relying
> on
> > a once-temporary aid that becomes effectively permanent?
>
> Yes I think it would be nice to require a green build to merge,
> without excessive merge-queue infrastructure that is more common in
> high-volume monorepos.
>
> 1. We would decide on a sunset date on the partial build indicator, at
> which point it will be disabled on trunk and all release branches. I
> suspect that a sunset date could be set for 1-3 releases in the
> future.
> 2. We would enable partial builds. The merge-button would remain
> as-is, with the partial build and full-suite indicators both being
> visible.
> 3. Communication would be sent out to explain that the partial build
> indicators are a temporary flakiness reduction tool.
> 4. Committers would continue to rely on the full-suite indicators, and
> watch the partial build to get a sense of the level of flakiness in
> each module.
> 5. On new contributions which have failing partial builds, Committers
> can ask that contributors investigate and follow-up on flaky failures
> that appeared in their PR, explaining that they can help make that
> indicator green for future contributions.
> 6. After the sunset date passes, the partial build indicators will be
> disabled.
> 7. If the main trunk build is sufficiently reliable by some criteria
> (e.g. 20 passes in a row) we can discuss requiring a green build for
> the GitHub merge button.
>
> > We probably
> > want to build awareness of this dependency graph into any partial CI
> logic
> > we add, but if we do opt for that, then this change would
> > disproportionately benefit downstream modules (Streams, Connect, MM2),
> and
> > have little to no benefit for upstream ones (clients and at least some
> core
> > modules).
>
> I considered that, and I think it is more beneficial to provide
> equitable partial builds than ones with perfect coverage. If you want
> to know about cross-module failures, I think that the full suite is
> still the appropriate tool to detect those.
> From another perspective, if this change is only useful to `core`
> after all other dependent modules have addressed their flakiness, then
> it delays `core` contributors from the reward for addressing their
> flakiness.
> And if anything, making the partial build cover fewer failure modes
> and reminding people of that fact will keep the full-suite builds
> relevant.
>
> > but people should already be making
> > sure that tests are running locally before they push changes
>
> I agree, and I don't think that partial builds are in any danger of
> replacing local testing for fast synchronous iteration. I also agree
> that it is appropriate to give personal feedback to repeat
> contributors to improve the quality of their PRs.
> CI seems to be for enforcing the lowest-common-denominator on
> contributions, and benefiting (potentially first-time) contributors
> which do not have the familiarity, mindfulness, or resources to
> pre-test each of their contributions.
> It is in those situations that I think partial builds can be
> beneficial: if there is something mechanical that all contributors
> should be doing locally, why not have it done automatically on their
> behalf?
>
> > Finally, since there are a number of existing flaky tests on trunk, what
> > would the strategy be for handling those? Do we try to get to a green
> state
> > on a per-module basis (possibly with awareness of downstream modules) as
> > quickly as possible, and then selectively enable partial builds once we
> > feel confident that flakiness has been addressed?
>
> For modules which receive regular PRs, the partial builds would
> surface those flakes, incentivising fixing them. Once t

[jira] [Resolved] (KAFKA-15080) Fetcher's lag never set when partition is idle

[David Jacot (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jacot resolved KAFKA-15080.
-
Fix Version/s: 3.5.1
   3.6.0
   Resolution: Fixed

> Fetcher's lag never set when partition is idle
> --
>
> Key: KAFKA-15080
> URL: https://issues.apache.org/jira/browse/KAFKA-15080
> Project: Kafka
>  Issue Type: Bug
>Reporter: David Jacot
>Assignee: David Jacot
>Priority: Major
> Fix For: 3.5.1, 3.6.0
>
>
> The PartitionFetchState's lag field is set to None when the state is created 
> and it is updated when bytes are received for a partition. For idle 
> partitions (newly created or not), the lag is never updated because 
> `validBytes > 0` is never true. As a side effect, the partition is considered 
> out-of-sync and could be incorrectly throttled.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] KIP-917: Additional custom metadata for remote log segment

[Luke Chen]

Looks good. Thanks for the update.

On Tue, Jun 13, 2023 at 8:08 PM Ivan Yurchenko 
wrote:

> Hi all!
>
> Thank you for your votes.
>
> Based on the proposal of Satish in the discussion thread, I modified the
> KIP a little bit by lowering the default value of
> `remote.log.metadata.custom.metadata.max.size` from 10 KiB to 128 bytes. I
> hope this doesn't change your vote, but feel free to raise your concerns.
> Thank you!
>
> Best,
> Ivan
>
>
> On Tue, 13 Jun 2023 at 11:09, Josep Prat 
> wrote:
>
> > Hi Ivan,
> >
> > Thank you very much for this KIP. +1 (binding) from me.
> >
> > Best,
> >
> >
> > On Tue, Jun 13, 2023 at 10:03 AM Luke Chen  wrote:
> >
> > > +1 (binding) from me.
> > >
> > > Thanks.
> > > Luke
> > >
> > > On Tue, Jun 13, 2023 at 3:44 PM Matthew Benedict de Detrich
> > >  wrote:
> > > >
> > > > +1 (non binding). Thanks for KIP
> > > >
> > > > On Tue, Jun 13, 2023 at 3:38 AM Kamal Chandraprakash <
> > > > kamal.chandraprak...@gmail.com> wrote:
> > > >
> > > > > +1 (non-binding). Thanks for the KIP!
> > > > >
> > > > > On Mon, Jun 12, 2023, 21:23 Divij Vaidya 
> > > wrote:
> > > > >
> > > > > > I have reviewed the proposal and feel that it would be beneficial
> > to
> > > > > > implement.
> > > > > >
> > > > > > Vote +1 (non-binding)
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Divij Vaidya
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Jun 12, 2023 at 4:39 PM Ivan Yurchenko <
> > > ivan0yurche...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > Some interest in KIP-917 was expressed in the discussion thread
> > > [1].
> > > > > > After
> > > > > > > addressing all the comments there, I'm putting it up to a vote.
> > > > > > > Thanks!
> > > > > > >
> > > > > > > Best,
> > > > > > > Ivan
> > > > > > >
> > > > > > > [1]
> > > https://lists.apache.org/thread/qpccqd3jy5rzvbt5ngtzo3dg9pzp722y
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > *Aiven Deutschland GmbH*
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > >
> > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >
> > > > *m:* +491603708037
> > > >
> > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io
> > >
> >
> >
> > --
> > [image: Aiven] 
> >
> > *Josep Prat*
> > Open Source Engineering Director, *Aiven*
> > josep.p...@aiven.io   |   +491715557497
> > aiven.io    |   <
> https://www.facebook.com/aivencloud
> > >
> >      <
> > https://twitter.com/aiven_io>
> > *Aiven Deutschland GmbH*
> > Alexanderufer 3-7, 10117 Berlin
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
>

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.5 #19

[Apache Jenkins Server]

See 

Re: [VOTE] KIP-917: Additional custom metadata for remote log segment

[Ivan Yurchenko]

Hi all!

Thank you for your votes.

Based on the proposal of Satish in the discussion thread, I modified the
KIP a little bit by lowering the default value of
`remote.log.metadata.custom.metadata.max.size` from 10 KiB to 128 bytes. I
hope this doesn't change your vote, but feel free to raise your concerns.
Thank you!

Best,
Ivan


On Tue, 13 Jun 2023 at 11:09, Josep Prat 
wrote:

> Hi Ivan,
>
> Thank you very much for this KIP. +1 (binding) from me.
>
> Best,
>
>
> On Tue, Jun 13, 2023 at 10:03 AM Luke Chen  wrote:
>
> > +1 (binding) from me.
> >
> > Thanks.
> > Luke
> >
> > On Tue, Jun 13, 2023 at 3:44 PM Matthew Benedict de Detrich
> >  wrote:
> > >
> > > +1 (non binding). Thanks for KIP
> > >
> > > On Tue, Jun 13, 2023 at 3:38 AM Kamal Chandraprakash <
> > > kamal.chandraprak...@gmail.com> wrote:
> > >
> > > > +1 (non-binding). Thanks for the KIP!
> > > >
> > > > On Mon, Jun 12, 2023, 21:23 Divij Vaidya 
> > wrote:
> > > >
> > > > > I have reviewed the proposal and feel that it would be beneficial
> to
> > > > > implement.
> > > > >
> > > > > Vote +1 (non-binding)
> > > > >
> > > > >
> > > > > --
> > > > > Divij Vaidya
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Jun 12, 2023 at 4:39 PM Ivan Yurchenko <
> > ivan0yurche...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Some interest in KIP-917 was expressed in the discussion thread
> > [1].
> > > > > After
> > > > > > addressing all the comments there, I'm putting it up to a vote.
> > > > > > Thanks!
> > > > > >
> > > > > > Best,
> > > > > > Ivan
> > > > > >
> > > > > > [1]
> > https://lists.apache.org/thread/qpccqd3jy5rzvbt5ngtzo3dg9pzp722y
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io
> >
>
>
> --
> [image: Aiven] 
>
> *Josep Prat*
> Open Source Engineering Director, *Aiven*
> josep.p...@aiven.io   |   +491715557497
> aiven.io    |    >
>      <
> https://twitter.com/aiven_io>
> *Aiven Deutschland GmbH*
> Alexanderufer 3-7, 10117 Berlin
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> Amtsgericht Charlottenburg, HRB 209739 B
>

Re: [DISCUSS] KIP-917: Additional custom metadata for remote log segment

[Ivan Yurchenko]

Hi Satish,

I understand your point and I agree with it. TBH, I didn't take into
account the in-memory cache.
Surely, 10 KiB is a relatively arbitrary number. Lowering it to the
proposed 128 bytes won't probably change anything for most of the
implementations. Others could ask for an increase.
I've updated the KIP.
Thanks!

Ivan


On Tue, 13 Jun 2023 at 09:47, Satish Duggana 
wrote:

> Thanks Ivan for taking the feedback/suggestions into the KIP.
>
> 10kb limit as default is huge for each segment metadata. This should
> only be used for a few keys pointing to more values if needed from a
> different store. This is intended to be used for purposes like
> pointing to a specific cluster or a specific bucket etc. This is
> generally required for identifiers like uuid or other formats that can
> amount to a few 10s of bytes. So, I suggest having a default value of
> 128 bytes instead of 10kb. If it requires metadata with a few KBs then
> it is better to avoid keeping all of them inmemory with default topic
> based RLMM and have them in a cache with separate storage. In that
> case, it is better to think about why we need that large metadata with
> each segment.
>
> ~Satish.
>
>
> On Wed, 7 Jun 2023 at 23:38, Ivan Yurchenko 
> wrote:
> >
> > Hi Satish,
> >
> > Thank you for your feedback.
> >
> > I've nothing against going from Map to byte[].
> > Serialization should not be a problem for RSM implementations: `Struct`,
> > `Schema` and other useful serde classes are distributed as a part of the
> > kafka-clients library.
> >
> > Also a good idea to add the size limiting setting, some
> > `remote.log.metadata.custom.metadata.max.size`. A sensible default may be
> > 10 KB, which is enough to host a struct with 10 long (almost) 1K symbol
> > ASCII strings.
> >
> > If a piece of custom metadata exceeds the limit, the execution of
> > RLMTask.copyLogSegmentsToRemote should be interrupted with an error
> message.
> >
> > Does this sound good?
> > If so, I'll update the KIP accordingly. And I think it may be time for
> the
> > vote after that.
> >
> > Best,
> > Ivan
> >
> >
> >
> > On Sat, 3 Jun 2023 at 17:13, Satish Duggana 
> > wrote:
> >
> > > Hi Ivan,
> > > Thanks for the KIP.
> > >
> > > The motivation of the KIP looks reasonable to me. It requires a way
> > > for RSM providers to add custom metadata with the existing
> > > RemoteLogSegmentMetadata. I remember we wanted to introduce a very
> > > similar change in the earlier proposals called
> > > RemoteLogMetadataContext. But we dropped that as we did not feel a
> > > strong need at that time and we wanted to revisit it if needed. But I
> > > see there is a clear need for this kind of custom metadata to keep
> > > with RemoteLogSegmentMetadata.
> > >
> > > It is better to introduce a new class for this custom metadata in
> > > RemoteLogSegmentMetadata like below for any changes in the future.
> > > RemoteLogSegmentMetadata will have this as an optional value.
> > >
> > > public class RemoteLogSegmentMetadata {
> > > ...
> > > public static class CustomMetadata {
> > >  private final byte[] value;
> > > ...
> > > }
> > > ...
> > > }
> > >
> > > This is completely opaque and it is the RSM implementation provider's
> > > responsibility in serializing and deserializing the bytes. We can
> > > introduce a property to guard the size with a configurable property
> > > with a default value to avoid any unwanted large size values.
> > >
> > > Thanks,
> > > Satish.
> > >
> > > On Tue, 30 May 2023 at 10:59, Ivan Yurchenko  >
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I want to bring this to a conclusion (positive or negative), so if
> there
> > > > are no more questions in a couple of days, I'll put the KIP to the
> vote.
> > > >
> > > > Best,
> > > > Ivan
> > > >
> > > >
> > > > On Fri, 5 May 2023 at 18:42, Ivan Yurchenko <
> ivan0yurche...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Alexandre,
> > > > >
> > > > > > combining custom
> > > > > > metadata with rlmMetadata increases coupling between Kafka and
> the
> > > > > > plugin.
> > > > >
> > > > > This is true. However, (if I understand your concern correctly,)
> > > > > rlmMetadata in the current form may be independent from RSM
> plugins,
> > > but
> > > > > data they point to are accessible only via the particular plugin
> (the
> > > one
> > > > > that wrote the data or a compatible one). It seems, this coupling
> > > already
> > > > > exists, but it is implicit. To make my point more concrete,
> imagine an
> > > S3
> > > > > RSM which maps RemoteLogSegmentMetadata objects to S3 object keys.
> This
> > > > > mapping logic is a part of the RSM plugin and without it the
> metadata
> > > is
> > > > > useless. I think it will not get worse if (to follow the example)
> the
> > > > > plugin makes the said S3 object keys explicit by adding them to the
> > > > > metadata. From the high level point of view, moving the custom
> > > metadata to
> > > > > a separate topic doesn't change the picture: it's sti

[GitHub] [kafka-site] mimaison commented on pull request #522: MINOR: Default to 3.5 docs

[via GitHub]

mimaison commented on PR #522:
URL: https://github.com/apache/kafka-site/pull/522#issuecomment-1589098313

   Sorry @jlprat I was still making changes I should have kept the PR in draft 
mode. I think I've done all the necessary changes now.
   
   It looks like we missed a bunch of updates when we released 3.4 as the 3.3 
docs don't display the `You're viewing documentation for an older version of 
Kafka` banner.


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

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

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

[GitHub] [kafka-site] mimaison opened a new pull request, #522: MINOR: Default to 3.5 docs

[via GitHub]

mimaison opened a new pull request, #522:
URL: https://github.com/apache/kafka-site/pull/522

   (no comment)


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

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

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

[jira] [Created] (KAFKA-15083) Passing "remote.log.metadata.*" configs into RLMM

[Luke Chen (Jira)]

Luke Chen created KAFKA-15083:
-

 Summary: Passing "remote.log.metadata.*" configs into RLMM
 Key: KAFKA-15083
 URL: https://issues.apache.org/jira/browse/KAFKA-15083
 Project: Kafka
  Issue Type: Sub-task
Reporter: Luke Chen


Based on the 
[KIP-405|https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage#KIP405:KafkaTieredStorage-Configs]:
|_{color:#00}remote.log.metadata.*{color}_|{color:#00}Default RLMM 
implementation creates producer and consumer instances. Common client 
propoerties can be configured with `remote.log.metadata.common.client.` prefix. 
 User can also pass properties specific to 
{color}{color:#00}producer/consumer with `remote.log.metadata.producer.` 
and `remote.log.metadata.consumer.` prefixes. These will override properties 
with `remote.log.metadata.common.client.` prefix.{color}
{color:#00}Any other properties should be prefixed with 
"remote.log.metadata." and these will be passed to 
RemoteLogMetadataManager#configure(Map props).{color}
{color:#00}For ex: Security configuration to connect to the local broker 
for the listener name configured are passed with props.{color}|

 

This is missed from current implementation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] KIP-937 Improve Message Timestamp Validation

[Luke Chen]

Hi Mehari,

Thanks for the update.
The KIP LGTM now.

Luke

On Tue, Jun 13, 2023 at 12:20 AM Beyene, Mehari 
wrote:

> Hi Luke, Divij and All,
>
> I have updated the KIP to incorporate Luke's comment. We now have two new
> configurations for validating the message timestamp difference.  The
> existing configuration, "log.message.timestamp.difference.max.ms", will
> be deprecated. The "before" validation uses the same default value as "
> log.message.timestamp.difference.max.ms" to maintain backward
> compatibility. The "after" validation uses a one-hour default value.
>
> Thanks,
> Mehari
>
>
>

Re: [VOTE] 3.5.0 RC1

[Mickael Maison]

Hi,

I'm now closing the vote. The vote passes with
- 4 +1 bindings votes from Luke, John, Bill and David
- 4 +1 non-binding votes from Federico, Jakub, Josep and Satish
- 0 -1 votes

I'll go ahead and finish the release process.

Thanks,
Mickael


On Mon, Jun 12, 2023 at 8:05 PM David Arthur  wrote:
>
> Hey Mickael, thanks for running the release!
>
> I downloaded the 2.12 binary and did the following:
>
> * Verified signatures
> * Performed KRaft quickstart
> * Manually ran through a ZK to KRaft migration
>
> I notice we're missing the KRaft migration docs from
> https://kafka.apache.org/35/documentation.html#kraft, but I think we can
> fix this without building a new RC. I'll try to get that done this week.
>
> +1 binding
>
> Cheers,
> David
>
> On Mon, Jun 12, 2023 at 12:15 PM Bill Bejeck  wrote:
>
> > Hi Mickael,
> >
> > I verified the following:
> >
> >1. All signatures and checksums
> >2. Built from source
> >3. Ran all the unit tests
> >4. Ran the Kafka-Zookeeper, Kafka-KRaft, and the Kafka Streams
> >quickstarts
> >5. Spot-checked the docs
> >6. Spot-checked the JavaDocs
> >
> > It's a +1(binding) for me.
> > Thanks for running the release!
> >
> > Regards,
> > Bill
> >
> > On Sun, Jun 11, 2023 at 5:38 AM Mickael Maison 
> > wrote:
> >
> > > Hi,
> > >
> > > We've passed the deadline but we are still missing votes.
> > > So far we have have 2 binding votes (Luke and John) and 2 non-binding
> > > votes (Federico and Jakub).
> > >
> > > Please take time to test this release candidate and vote.
> > >
> > > Thanks,
> > > Mickael
> > >
> > > On Wed, Jun 7, 2023 at 6:26 PM John Roesler  wrote:
> > > >
> > > > Thanks for running this release, Mickael!
> > > >
> > > > I've verified:
> > > > * the signature
> > > > * that I can compile the project
> > > > * that I can run the tests. I saw one flaky test failure, but I don't
> > > think it should block us. Reported as
> > >
> > https://issues.apache.org/jira/browse/KAFKA-13531?focusedCommentId=17730190
> > > > * the Kafka, Consumer, and Streams quickstarts with ZK and KRaft
> > > >
> > > > I'm +1 (binding)
> > > >
> > > > Thanks,
> > > > -John
> > > >
> > > > On Wed, Jun 7, 2023, at 06:16, Josep Prat wrote:
> > > > > Hi MIckael,
> > > > >
> > > > > Apparently you did it in this PR already :) :
> > > > > https://github.com/apache/kafka/pull/13749 (this PR among other
> > things
> > > > > removes classgraph.
> > > > >
> > > > > Without being a lawyer, I think I agree with you as stating we depend
> > > on
> > > > > something we don't would be less problematic than the other way
> > around.
> > > > >
> > > > > Best,
> > > > >
> > > > > On Wed, Jun 7, 2023 at 12:14 PM Mickael Maison <
> > > mickael.mai...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hi Josep,
> > > > >>
> > > > >> Thanks for spotting this. If not already done, can you open a
> > > > >> ticket/PR to fix this on trunk? It looks like the last couple of
> > > > >> releases already had that issue. Since we're including a license
> > for a
> > > > >> dependency we don't ship, I think we can consider this non blocking.
> > > > >> The other way around (shipping a dependency without its license)
> > would
> > > > >> be blocking.
> > > > >>
> > > > >> Thanks,
> > > > >> Mickael
> > > > >>
> > > > >> On Tue, Jun 6, 2023 at 10:10 PM Jakub Scholz 
> > wrote:
> > > > >> >
> > > > >> > +1 (non-binding) ... I used the staged binaries with Scala 2.13
> > and
> > > > >> staged
> > > > >> > artifacts to run my tests. All seems to work fine.
> > > > >> >
> > > > >> > Thanks for running the release Mickael!
> > > > >> >
> > > > >> > Jakub
> > > > >> >
> > > > >> > On Mon, Jun 5, 2023 at 3:39 PM Mickael Maison <
> > mimai...@apache.org>
> > > > >> wrote:
> > > > >> >
> > > > >> > > Hello Kafka users, developers and client-developers,
> > > > >> > >
> > > > >> > > This is the second candidate for release of Apache Kafka 3.5.0.
> > > Some
> > > > >> > > of the major features include:
> > > > >> > > - KIP-710: Full support for distributed mode in dedicated
> > > MirrorMaker
> > > > >> > > 2.0 clusters
> > > > >> > > - KIP-881: Rack-aware Partition Assignment for Kafka Consumers
> > > > >> > > - KIP-887: Add ConfigProvider to make use of environment
> > variables
> > > > >> > > - KIP-889: Versioned State Stores
> > > > >> > > - KIP-894: Use incrementalAlterConfig for syncing topic
> > > configurations
> > > > >> > > - KIP-900: KRaft kafka-storage.sh API additions to support SCRAM
> > > for
> > > > >> > > Kafka Brokers
> > > > >> > >
> > > > >> > > Release notes for the 3.5.0 release:
> > > > >> > >
> > > https://home.apache.org/~mimaison/kafka-3.5.0-rc1/RELEASE_NOTES.html
> > > > >> > >
> > > > >> > > *** Please download, test and vote by Friday June 9, 5pm PT
> > > > >> > >
> > > > >> > > 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):

Re: [VOTE] KIP-917: Additional custom metadata for remote log segment

[Josep Prat]

Hi Ivan,

Thank you very much for this KIP. +1 (binding) from me.

Best,


On Tue, Jun 13, 2023 at 10:03 AM Luke Chen  wrote:

> +1 (binding) from me.
>
> Thanks.
> Luke
>
> On Tue, Jun 13, 2023 at 3:44 PM Matthew Benedict de Detrich
>  wrote:
> >
> > +1 (non binding). Thanks for KIP
> >
> > On Tue, Jun 13, 2023 at 3:38 AM Kamal Chandraprakash <
> > kamal.chandraprak...@gmail.com> wrote:
> >
> > > +1 (non-binding). Thanks for the KIP!
> > >
> > > On Mon, Jun 12, 2023, 21:23 Divij Vaidya 
> wrote:
> > >
> > > > I have reviewed the proposal and feel that it would be beneficial to
> > > > implement.
> > > >
> > > > Vote +1 (non-binding)
> > > >
> > > >
> > > > --
> > > > Divij Vaidya
> > > >
> > > >
> > > >
> > > > On Mon, Jun 12, 2023 at 4:39 PM Ivan Yurchenko <
> ivan0yurche...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Some interest in KIP-917 was expressed in the discussion thread
> [1].
> > > > After
> > > > > addressing all the comments there, I'm putting it up to a vote.
> > > > > Thanks!
> > > > >
> > > > > Best,
> > > > > Ivan
> > > > >
> > > > > [1]
> https://lists.apache.org/thread/qpccqd3jy5rzvbt5ngtzo3dg9pzp722y
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetr...@aiven.io
>


-- 
[image: Aiven] 

*Josep Prat*
Open Source Engineering Director, *Aiven*
josep.p...@aiven.io   |   +491715557497
aiven.io    |   
     
*Aiven Deutschland GmbH*
Alexanderufer 3-7, 10117 Berlin
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
Amtsgericht Charlottenburg, HRB 209739 B

Re: [VOTE] KIP-917: Additional custom metadata for remote log segment

[Luke Chen]

+1 (binding) from me.

Thanks.
Luke

On Tue, Jun 13, 2023 at 3:44 PM Matthew Benedict de Detrich
 wrote:
>
> +1 (non binding). Thanks for KIP
>
> On Tue, Jun 13, 2023 at 3:38 AM Kamal Chandraprakash <
> kamal.chandraprak...@gmail.com> wrote:
>
> > +1 (non-binding). Thanks for the KIP!
> >
> > On Mon, Jun 12, 2023, 21:23 Divij Vaidya  wrote:
> >
> > > I have reviewed the proposal and feel that it would be beneficial to
> > > implement.
> > >
> > > Vote +1 (non-binding)
> > >
> > >
> > > --
> > > Divij Vaidya
> > >
> > >
> > >
> > > On Mon, Jun 12, 2023 at 4:39 PM Ivan Yurchenko  > >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > Some interest in KIP-917 was expressed in the discussion thread [1].
> > > After
> > > > addressing all the comments there, I'm putting it up to a vote.
> > > > Thanks!
> > > >
> > > > Best,
> > > > Ivan
> > > >
> > > > [1] https://lists.apache.org/thread/qpccqd3jy5rzvbt5ngtzo3dg9pzp722y
> > > >
> > >
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetr...@aiven.io

Re: [VOTE] KIP-858: Handle JBOD broker disk failure in KRaft

[ziming deng]

Hi Igor, Thanks for this work.

+1(binding) from me

--
Best,
Ziming

> On Jun 12, 2023, at 18:07, Igor Soarez  wrote:
> 
> Hi everyone,
> 
> We're getting closer to dropping ZooKeeper support, and JBOD
> in KRaft mode is one of the outstanding big missing features.
> 
> It's been a while since there was new feedback on KIP-858 [1]
> which aims to address this gap, so I'm calling for a vote.
> 
> A huge thank you to everyone who has reviewed this KIP, and
> participated in the discussion thread! [2]
> 
> I'd also like to thank you in advance for taking the time to vote.
> 
> Best,
> 
> --
> Igor
> 
> [1] 
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-858%3A+Handle+JBOD+broker+disk+failure+in+KRaft
> [2] https://lists.apache.org/thread/8dqvfhzcyy87zyy12837pxx9lgsdhvft
> 

Re: [VOTE] KIP-917: Additional custom metadata for remote log segment

[Matthew Benedict de Detrich]

+1 (non binding). Thanks for KIP

On Tue, Jun 13, 2023 at 3:38 AM Kamal Chandraprakash <
kamal.chandraprak...@gmail.com> wrote:

> +1 (non-binding). Thanks for the KIP!
>
> On Mon, Jun 12, 2023, 21:23 Divij Vaidya  wrote:
>
> > I have reviewed the proposal and feel that it would be beneficial to
> > implement.
> >
> > Vote +1 (non-binding)
> >
> >
> > --
> > Divij Vaidya
> >
> >
> >
> > On Mon, Jun 12, 2023 at 4:39 PM Ivan Yurchenko  >
> > wrote:
> >
> > > Hello,
> > >
> > > Some interest in KIP-917 was expressed in the discussion thread [1].
> > After
> > > addressing all the comments there, I'm putting it up to a vote.
> > > Thanks!
> > >
> > > Best,
> > > Ivan
> > >
> > > [1] https://lists.apache.org/thread/qpccqd3jy5rzvbt5ngtzo3dg9pzp722y
> > >
> >
>


-- 

Matthew de Detrich

*Aiven Deutschland GmbH*

Immanuelkirchstraße 26, 10405 Berlin

Amtsgericht Charlottenburg, HRB 209739 B

Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen

*m:* +491603708037

*w:* aiven.io *e:* matthew.dedetr...@aiven.io

Re: Can't creare a Jira

[Bruno Cadonna]

Hi Assane,

I cannot find neither assane.diop nor adiop in the Kafka JIRA project. I 
also cannot find assane.diop in the Apache JIRA.


Are you sure you did not request an account in a different Apache 
project before?
I could not find your request on the Kafka private mailing list (since 
October 2022). Maybe your request is pending there somewhere.


I am afraid, I unable to help here. I am sorry!

Please try to contact us...@infra.apache.org as stated on 
https://selfserve.apache.org/jira-account.html


Best,
Bruno

On 12.06.23 17:58, Diop, Assane wrote:

Hi Bruno,
Thanks for your email!

When I try to create an account via the self serve, I tried couple username:
1. when I try "assane.diop" it says the user name is already taken but when I 
try to reset password I can't
2.  when I try "adiop", it says there is a pending Jira account associated with 
the email address. Please wait to be processed (see attached)

On the first try, it must be another developer with the same name as me holding 
that username, but I am not entirely sure.

How can I get the request accepted?

Assane




-Original Message-
From: Bruno Cadonna 
Sent: Sunday, June 11, 2023 6:24 AM
To: dev@kafka.apache.org
Subject: Re: Can't creare a Jira

Hi Assane,

I am sorry to hear that you are blocked!

Did you submit a request through
https://selfserve.apache.org/jira-account.html ?

If yes, did you select Kafka as the ASF project?

Where do you see that your request is pending?


Best,
Bruno

On 09.06.23 20:12, Diop, Assane wrote:

I am unable to complete my Jira account.
The request seems to be pending.
Can anyone help with this?

Assane