Re: Apache Kafka 3.7.0 Release

[Mayank Shekhar Narula]

Stanislav


this *doesn't* seem like a blocker to me given the complexity,
> public API changes and

Fair enough, since it only has been seen for very high partition counts.
The PR  in trunk is under
active review, i will cherry-pick it for 3.7.1.


> the fact that it's for high partition counts (a
> definition here would help though)

This is hard to give, but only so far seen with high values of partitions
i.e. 36k.


On Mon, Feb 12, 2024 at 10:26 AM Stanislav Kozlovski
 wrote:

> Hey Divij, that is a good point regarding KIP-848.
>
> David, as the author of the KIP, would you be able to drive this?
>
> Similarly, would anybody be willing to drive such an EA Release Note for
> the JBOD feature?
>
> Mayank, this *doesn't* seem like a blocker to me given the complexity,
> public API changes and the fact that it's for high partition counts (a
> definition here would help though)
>
> Reminder - RC4 is out for vote right now.
>
> Best,
> Stanislav
>
> On Tue, Feb 6, 2024 at 5:25 PM Mayank Shekhar Narula <
> mayanks.nar...@gmail.com> wrote:
>
> > Hi Folks
> >
> > KIP-951 was delivered fully in AK 3.7. Its 1st optimisation was delivered
> > in 3.6.1, to skip backoff period for a produce batch being retried to new
> > leader i.e. KAFKA-15415.
> >
> > KAFKA-15415 current implementation introduced a performance regression,
> by
> > increasing synchronization on the produce path, especially for high
> > partition counts. The description section of
> > https://issues.apache.org/jira/browse/KAFKA-16226 goes more into details
> > of
> > the regression.
> >
> > I have put up a fix https://github.com/apache/kafka/pull/15323, which
> > removes this synchronization. The fix adds a new public method to
> > Cluster.java, and a public constructor to PartitionInfo.java.
> >
> > Is this a blocker for v3.7.0?
> >
> > PS - Posted in KIP-951's voting thread as well
> > .
> >
> >
> > On Fri, Feb 2, 2024 at 3:58 PM Divij Vaidya 
> > wrote:
> >
> > > Hey folks
> > >
> > > The release plan for 3.7.0 [1] calls out KIP 848 as "Targeting a
> Preview
> > in
> > > 3.7".
> > >
> > > Is that still true? If yes, then we should perhaps add that in the
> blog,
> > > call it out in the release notes and prepare a preview document similar
> > to
> > > what we did for Tiered Storage Early Access release[2]
> > >
> > > If not true, then we should update the release notes to reflect the
> > current
> > > state of the KIP.
> > >
> > > (I think the same is true for other KIPs like KIP-963)
> > >
> > > [1]
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> > > [2]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes
> > >
> > >
> > > --
> > > Divij Vaidya
> > >
> > >
> > >
> > > On Thu, Jan 11, 2024 at 1:03 PM Luke Chen  wrote:
> > >
> > > > Hi all,
> > > >
> > > > There is a bug KAFKA-16101
> > > >  reporting that
> > > "Kafka
> > > > cluster will be unavailable during KRaft migration rollback".
> > > > The impact for this issue is that if brokers try to rollback to ZK
> mode
> > > > during KRaft migration process, there will be a period of time the
> > > cluster
> > > > is unavailable.
> > > > Since ZK migrating to KRaft feature is a production ready feature, I
> > > think
> > > > this should be addressed soon.
> > > > Do you think this is a blocker for v3.7.0?
> > > >
> > > > Thanks.
> > > > Luke
> > > >
> > > > On Thu, Jan 11, 2024 at 6:11 AM Stanislav Kozlovski
> > > >  wrote:
> > > >
> > > > > Thanks Colin,
> > > > >
> > > > > With that, I believe we are out of blockers. I was traveling today
> > and
> > > > > couldn't build an RC - expect one to be published tomorrow (barring
> > any
> > > > > problems).
> > > > >
> > > > > In the meanwhile - here is a PR for the 3.7 blog post -
> > > > > https://github.com/apache/kafka-site/pull/578
> > > > >
> > > > > Best,
> > > > > Stan
> > > > >
> > > > > On Wed, Jan 10, 2024 at 12:06 AM Colin McCabe 
> > > > wrote:
> > > > >
> > > > > > KAFKA-16094 has been fixed and backported to 3.7.
> > > > > >
> > > > > > Colin
> > > > > >
> > > > > >
> > > > > > On Mon, Jan 8, 2024, at 14:52, Colin McCabe wrote:
> > > > > > > On an unrelated note, I found a blocker bug related to upgrades
> > > from
> > > > > > > 3.6 (and earlier) to 3.7.
> > > > > > >
> > > > > > > The JIRA is here:
> > > > > > >   https://issues.apache.org/jira/browse/KAFKA-16094
> > > > > > >
> > > > > > > Fix here:
> > > > > > >   https://github.com/apache/kafka/pull/15153
> > > > > > >
> > > > > > > best,
> > > > > > > Colin
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote:
> > > > > > >> Hi Ismael,
> > > > > > >>
> > > > > > >> I wasn't aware of that. If we are required to publish all
> > modules,
> > > > > then
> > > > > > >> this is working as intended.
> > 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Hey Divij, that is a good point regarding KIP-848.

David, as the author of the KIP, would you be able to drive this?

Similarly, would anybody be willing to drive such an EA Release Note for
the JBOD feature?

Mayank, this *doesn't* seem like a blocker to me given the complexity,
public API changes and the fact that it's for high partition counts (a
definition here would help though)

Reminder - RC4 is out for vote right now.

Best,
Stanislav

On Tue, Feb 6, 2024 at 5:25 PM Mayank Shekhar Narula <
mayanks.nar...@gmail.com> wrote:

> Hi Folks
>
> KIP-951 was delivered fully in AK 3.7. Its 1st optimisation was delivered
> in 3.6.1, to skip backoff period for a produce batch being retried to new
> leader i.e. KAFKA-15415.
>
> KAFKA-15415 current implementation introduced a performance regression, by
> increasing synchronization on the produce path, especially for high
> partition counts. The description section of
> https://issues.apache.org/jira/browse/KAFKA-16226 goes more into details
> of
> the regression.
>
> I have put up a fix https://github.com/apache/kafka/pull/15323, which
> removes this synchronization. The fix adds a new public method to
> Cluster.java, and a public constructor to PartitionInfo.java.
>
> Is this a blocker for v3.7.0?
>
> PS - Posted in KIP-951's voting thread as well
> .
>
>
> On Fri, Feb 2, 2024 at 3:58 PM Divij Vaidya 
> wrote:
>
> > Hey folks
> >
> > The release plan for 3.7.0 [1] calls out KIP 848 as "Targeting a Preview
> in
> > 3.7".
> >
> > Is that still true? If yes, then we should perhaps add that in the blog,
> > call it out in the release notes and prepare a preview document similar
> to
> > what we did for Tiered Storage Early Access release[2]
> >
> > If not true, then we should update the release notes to reflect the
> current
> > state of the KIP.
> >
> > (I think the same is true for other KIPs like KIP-963)
> >
> > [1] https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes
> >
> >
> > --
> > Divij Vaidya
> >
> >
> >
> > On Thu, Jan 11, 2024 at 1:03 PM Luke Chen  wrote:
> >
> > > Hi all,
> > >
> > > There is a bug KAFKA-16101
> > >  reporting that
> > "Kafka
> > > cluster will be unavailable during KRaft migration rollback".
> > > The impact for this issue is that if brokers try to rollback to ZK mode
> > > during KRaft migration process, there will be a period of time the
> > cluster
> > > is unavailable.
> > > Since ZK migrating to KRaft feature is a production ready feature, I
> > think
> > > this should be addressed soon.
> > > Do you think this is a blocker for v3.7.0?
> > >
> > > Thanks.
> > > Luke
> > >
> > > On Thu, Jan 11, 2024 at 6:11 AM Stanislav Kozlovski
> > >  wrote:
> > >
> > > > Thanks Colin,
> > > >
> > > > With that, I believe we are out of blockers. I was traveling today
> and
> > > > couldn't build an RC - expect one to be published tomorrow (barring
> any
> > > > problems).
> > > >
> > > > In the meanwhile - here is a PR for the 3.7 blog post -
> > > > https://github.com/apache/kafka-site/pull/578
> > > >
> > > > Best,
> > > > Stan
> > > >
> > > > On Wed, Jan 10, 2024 at 12:06 AM Colin McCabe 
> > > wrote:
> > > >
> > > > > KAFKA-16094 has been fixed and backported to 3.7.
> > > > >
> > > > > Colin
> > > > >
> > > > >
> > > > > On Mon, Jan 8, 2024, at 14:52, Colin McCabe wrote:
> > > > > > On an unrelated note, I found a blocker bug related to upgrades
> > from
> > > > > > 3.6 (and earlier) to 3.7.
> > > > > >
> > > > > > The JIRA is here:
> > > > > >   https://issues.apache.org/jira/browse/KAFKA-16094
> > > > > >
> > > > > > Fix here:
> > > > > >   https://github.com/apache/kafka/pull/15153
> > > > > >
> > > > > > best,
> > > > > > Colin
> > > > > >
> > > > > >
> > > > > > On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote:
> > > > > >> Hi Ismael,
> > > > > >>
> > > > > >> I wasn't aware of that. If we are required to publish all
> modules,
> > > > then
> > > > > >> this is working as intended.
> > > > > >>
> > > > > >> I am a bit curious if we've discussed why we need to publish the
> > > > server
> > > > > >> modules to Sonatype. Is there a discussion about the pros and
> cons
> > > of
> > > > > >> this somewhere?
> > > > > >>
> > > > > >> regards,
> > > > > >> Colin
> > > > > >>
> > > > > >> On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote:
> > > > > >>> All modules are published to Sonatype - that's a requirement.
> You
> > > may
> > > > > be
> > > > > >>> missing the fact that `core` is published as `kafka_2.13` and
> > > > > `kafka_2.12`.
> > > > > >>>
> > > > > >>> Ismael
> > > > > >>>
> > > > > >>> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe <
> cmcc...@apache.org
> > >
> > > > > wrote:
> > > > > >>>
> > > > >  Hi Ismael,
> > > > > 
> > > > >  It seems like both the metadata 

Re: Apache Kafka 3.7.0 Release

[Mayank Shekhar Narula]

Hi Folks

KIP-951 was delivered fully in AK 3.7. Its 1st optimisation was delivered
in 3.6.1, to skip backoff period for a produce batch being retried to new
leader i.e. KAFKA-15415.

KAFKA-15415 current implementation introduced a performance regression, by
increasing synchronization on the produce path, especially for high
partition counts. The description section of
https://issues.apache.org/jira/browse/KAFKA-16226 goes more into details of
the regression.

I have put up a fix https://github.com/apache/kafka/pull/15323, which
removes this synchronization. The fix adds a new public method to
Cluster.java, and a public constructor to PartitionInfo.java.

Is this a blocker for v3.7.0?

PS - Posted in KIP-951's voting thread as well
.


On Fri, Feb 2, 2024 at 3:58 PM Divij Vaidya  wrote:

> Hey folks
>
> The release plan for 3.7.0 [1] calls out KIP 848 as "Targeting a Preview in
> 3.7".
>
> Is that still true? If yes, then we should perhaps add that in the blog,
> call it out in the release notes and prepare a preview document similar to
> what we did for Tiered Storage Early Access release[2]
>
> If not true, then we should update the release notes to reflect the current
> state of the KIP.
>
> (I think the same is true for other KIPs like KIP-963)
>
> [1] https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> [2]
>
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes
>
>
> --
> Divij Vaidya
>
>
>
> On Thu, Jan 11, 2024 at 1:03 PM Luke Chen  wrote:
>
> > Hi all,
> >
> > There is a bug KAFKA-16101
> >  reporting that
> "Kafka
> > cluster will be unavailable during KRaft migration rollback".
> > The impact for this issue is that if brokers try to rollback to ZK mode
> > during KRaft migration process, there will be a period of time the
> cluster
> > is unavailable.
> > Since ZK migrating to KRaft feature is a production ready feature, I
> think
> > this should be addressed soon.
> > Do you think this is a blocker for v3.7.0?
> >
> > Thanks.
> > Luke
> >
> > On Thu, Jan 11, 2024 at 6:11 AM Stanislav Kozlovski
> >  wrote:
> >
> > > Thanks Colin,
> > >
> > > With that, I believe we are out of blockers. I was traveling today and
> > > couldn't build an RC - expect one to be published tomorrow (barring any
> > > problems).
> > >
> > > In the meanwhile - here is a PR for the 3.7 blog post -
> > > https://github.com/apache/kafka-site/pull/578
> > >
> > > Best,
> > > Stan
> > >
> > > On Wed, Jan 10, 2024 at 12:06 AM Colin McCabe 
> > wrote:
> > >
> > > > KAFKA-16094 has been fixed and backported to 3.7.
> > > >
> > > > Colin
> > > >
> > > >
> > > > On Mon, Jan 8, 2024, at 14:52, Colin McCabe wrote:
> > > > > On an unrelated note, I found a blocker bug related to upgrades
> from
> > > > > 3.6 (and earlier) to 3.7.
> > > > >
> > > > > The JIRA is here:
> > > > >   https://issues.apache.org/jira/browse/KAFKA-16094
> > > > >
> > > > > Fix here:
> > > > >   https://github.com/apache/kafka/pull/15153
> > > > >
> > > > > best,
> > > > > Colin
> > > > >
> > > > >
> > > > > On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote:
> > > > >> Hi Ismael,
> > > > >>
> > > > >> I wasn't aware of that. If we are required to publish all modules,
> > > then
> > > > >> this is working as intended.
> > > > >>
> > > > >> I am a bit curious if we've discussed why we need to publish the
> > > server
> > > > >> modules to Sonatype. Is there a discussion about the pros and cons
> > of
> > > > >> this somewhere?
> > > > >>
> > > > >> regards,
> > > > >> Colin
> > > > >>
> > > > >> On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote:
> > > > >>> All modules are published to Sonatype - that's a requirement. You
> > may
> > > > be
> > > > >>> missing the fact that `core` is published as `kafka_2.13` and
> > > > `kafka_2.12`.
> > > > >>>
> > > > >>> Ismael
> > > > >>>
> > > > >>> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe  >
> > > > wrote:
> > > > >>>
> > > >  Hi Ismael,
> > > > 
> > > >  It seems like both the metadata gradle module and the
> > server-common
> > > > module
> > > >  are getting published to Sonatype as separate artifacts, unless
> > I'm
> > > >  misunderstanding something. Example:
> > > > 
> > > >  https://central.sonatype.com/search?q=kafka-server-common
> > > > 
> > > >  I don't see kafka-core getting published, but maybe other
> private
> > > >  server-side gradle modules are getting published.
> > > > 
> > > >  This seems bad. Is there a reason to publish modules that are
> only
> > > > used by
> > > >  the server on Sonatype?
> > > > 
> > > >  best,
> > > >  Colin
> > > > 
> > > > 
> > > >  On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote:
> > > >  > Hi Colin,
> > > >  >
> > > >  > I think you may have misunderstood what they mean by gradle
> > > > metadata -
> > > 

Re: Apache Kafka 3.7.0 Release

[Divij Vaidya]

Hey folks

The release plan for 3.7.0 [1] calls out KIP 848 as "Targeting a Preview in
3.7".

Is that still true? If yes, then we should perhaps add that in the blog,
call it out in the release notes and prepare a preview document similar to
what we did for Tiered Storage Early Access release[2]

If not true, then we should update the release notes to reflect the current
state of the KIP.

(I think the same is true for other KIPs like KIP-963)

[1] https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
[2]
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes


--
Divij Vaidya



On Thu, Jan 11, 2024 at 1:03 PM Luke Chen  wrote:

> Hi all,
>
> There is a bug KAFKA-16101
>  reporting that "Kafka
> cluster will be unavailable during KRaft migration rollback".
> The impact for this issue is that if brokers try to rollback to ZK mode
> during KRaft migration process, there will be a period of time the cluster
> is unavailable.
> Since ZK migrating to KRaft feature is a production ready feature, I think
> this should be addressed soon.
> Do you think this is a blocker for v3.7.0?
>
> Thanks.
> Luke
>
> On Thu, Jan 11, 2024 at 6:11 AM Stanislav Kozlovski
>  wrote:
>
> > Thanks Colin,
> >
> > With that, I believe we are out of blockers. I was traveling today and
> > couldn't build an RC - expect one to be published tomorrow (barring any
> > problems).
> >
> > In the meanwhile - here is a PR for the 3.7 blog post -
> > https://github.com/apache/kafka-site/pull/578
> >
> > Best,
> > Stan
> >
> > On Wed, Jan 10, 2024 at 12:06 AM Colin McCabe 
> wrote:
> >
> > > KAFKA-16094 has been fixed and backported to 3.7.
> > >
> > > Colin
> > >
> > >
> > > On Mon, Jan 8, 2024, at 14:52, Colin McCabe wrote:
> > > > On an unrelated note, I found a blocker bug related to upgrades from
> > > > 3.6 (and earlier) to 3.7.
> > > >
> > > > The JIRA is here:
> > > >   https://issues.apache.org/jira/browse/KAFKA-16094
> > > >
> > > > Fix here:
> > > >   https://github.com/apache/kafka/pull/15153
> > > >
> > > > best,
> > > > Colin
> > > >
> > > >
> > > > On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote:
> > > >> Hi Ismael,
> > > >>
> > > >> I wasn't aware of that. If we are required to publish all modules,
> > then
> > > >> this is working as intended.
> > > >>
> > > >> I am a bit curious if we've discussed why we need to publish the
> > server
> > > >> modules to Sonatype. Is there a discussion about the pros and cons
> of
> > > >> this somewhere?
> > > >>
> > > >> regards,
> > > >> Colin
> > > >>
> > > >> On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote:
> > > >>> All modules are published to Sonatype - that's a requirement. You
> may
> > > be
> > > >>> missing the fact that `core` is published as `kafka_2.13` and
> > > `kafka_2.12`.
> > > >>>
> > > >>> Ismael
> > > >>>
> > > >>> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe 
> > > wrote:
> > > >>>
> > >  Hi Ismael,
> > > 
> > >  It seems like both the metadata gradle module and the
> server-common
> > > module
> > >  are getting published to Sonatype as separate artifacts, unless
> I'm
> > >  misunderstanding something. Example:
> > > 
> > >  https://central.sonatype.com/search?q=kafka-server-common
> > > 
> > >  I don't see kafka-core getting published, but maybe other private
> > >  server-side gradle modules are getting published.
> > > 
> > >  This seems bad. Is there a reason to publish modules that are only
> > > used by
> > >  the server on Sonatype?
> > > 
> > >  best,
> > >  Colin
> > > 
> > > 
> > >  On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote:
> > >  > Hi Colin,
> > >  >
> > >  > I think you may have misunderstood what they mean by gradle
> > > metadata -
> > >  it's
> > >  > not the Kafka metadata module.
> > >  >
> > >  > Ismael
> > >  >
> > >  > On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe  >
> > > wrote:
> > >  >
> > >  >> Oops, hit send too soon. I see that #15127 was already merged.
> So
> > > we
> > >  >> should no longer be publishing :metadata as part of the clients
> > >  artifacts,
> > >  >> right?
> > >  >>
> > >  >> thanks,
> > >  >> Colin
> > >  >>
> > >  >>
> > >  >> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
> > >  >> > Hi Apporv,
> > >  >> >
> > >  >> > Please remove the metadata module from any artifacts
> published
> > > for
> > >  >> > clients. It is only used by the server.
> > >  >> >
> > >  >> > best,
> > >  >> > Colin
> > >  >> >
> > >  >> >
> > >  >> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
> > >  >> >> Hi Colin,
> > >  >> >> Thanks for the response. The only reason for asking the
> > > question of
> > >  >> >> publishing the metadata is because that's present in
> previous
> > > client
> > >  >> >> releases. 

Re: Apache Kafka 3.7.0 Release

[Luke Chen]

Hi all,

There is a bug KAFKA-16101
 reporting that "Kafka
cluster will be unavailable during KRaft migration rollback".
The impact for this issue is that if brokers try to rollback to ZK mode
during KRaft migration process, there will be a period of time the cluster
is unavailable.
Since ZK migrating to KRaft feature is a production ready feature, I think
this should be addressed soon.
Do you think this is a blocker for v3.7.0?

Thanks.
Luke

On Thu, Jan 11, 2024 at 6:11 AM Stanislav Kozlovski
 wrote:

> Thanks Colin,
>
> With that, I believe we are out of blockers. I was traveling today and
> couldn't build an RC - expect one to be published tomorrow (barring any
> problems).
>
> In the meanwhile - here is a PR for the 3.7 blog post -
> https://github.com/apache/kafka-site/pull/578
>
> Best,
> Stan
>
> On Wed, Jan 10, 2024 at 12:06 AM Colin McCabe  wrote:
>
> > KAFKA-16094 has been fixed and backported to 3.7.
> >
> > Colin
> >
> >
> > On Mon, Jan 8, 2024, at 14:52, Colin McCabe wrote:
> > > On an unrelated note, I found a blocker bug related to upgrades from
> > > 3.6 (and earlier) to 3.7.
> > >
> > > The JIRA is here:
> > >   https://issues.apache.org/jira/browse/KAFKA-16094
> > >
> > > Fix here:
> > >   https://github.com/apache/kafka/pull/15153
> > >
> > > best,
> > > Colin
> > >
> > >
> > > On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote:
> > >> Hi Ismael,
> > >>
> > >> I wasn't aware of that. If we are required to publish all modules,
> then
> > >> this is working as intended.
> > >>
> > >> I am a bit curious if we've discussed why we need to publish the
> server
> > >> modules to Sonatype. Is there a discussion about the pros and cons of
> > >> this somewhere?
> > >>
> > >> regards,
> > >> Colin
> > >>
> > >> On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote:
> > >>> All modules are published to Sonatype - that's a requirement. You may
> > be
> > >>> missing the fact that `core` is published as `kafka_2.13` and
> > `kafka_2.12`.
> > >>>
> > >>> Ismael
> > >>>
> > >>> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe 
> > wrote:
> > >>>
> >  Hi Ismael,
> > 
> >  It seems like both the metadata gradle module and the server-common
> > module
> >  are getting published to Sonatype as separate artifacts, unless I'm
> >  misunderstanding something. Example:
> > 
> >  https://central.sonatype.com/search?q=kafka-server-common
> > 
> >  I don't see kafka-core getting published, but maybe other private
> >  server-side gradle modules are getting published.
> > 
> >  This seems bad. Is there a reason to publish modules that are only
> > used by
> >  the server on Sonatype?
> > 
> >  best,
> >  Colin
> > 
> > 
> >  On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote:
> >  > Hi Colin,
> >  >
> >  > I think you may have misunderstood what they mean by gradle
> > metadata -
> >  it's
> >  > not the Kafka metadata module.
> >  >
> >  > Ismael
> >  >
> >  > On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe 
> > wrote:
> >  >
> >  >> Oops, hit send too soon. I see that #15127 was already merged. So
> > we
> >  >> should no longer be publishing :metadata as part of the clients
> >  artifacts,
> >  >> right?
> >  >>
> >  >> thanks,
> >  >> Colin
> >  >>
> >  >>
> >  >> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
> >  >> > Hi Apporv,
> >  >> >
> >  >> > Please remove the metadata module from any artifacts published
> > for
> >  >> > clients. It is only used by the server.
> >  >> >
> >  >> > best,
> >  >> > Colin
> >  >> >
> >  >> >
> >  >> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
> >  >> >> Hi Colin,
> >  >> >> Thanks for the response. The only reason for asking the
> > question of
> >  >> >> publishing the metadata is because that's present in previous
> > client
> >  >> >> releases. For more context, the description of PR
> >  >> >>  holds the
> details
> > and
> >  >> waiting
> >  >> >> for the confirmation there prior to the merge.
> >  >> >>
> >  >> >> Regards,
> >  >> >> Apoorv Mittal
> >  >> >> +44 7721681581
> >  >> >>
> >  >> >>
> >  >> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe <
> > cmcc...@apache.org>
> >  >> wrote:
> >  >> >>
> >  >> >>> metadata is an internal gradle module. It is not used by
> > clients.
> >  So I
> >  >> >>> don't see why you would want to publish it (unless I'm
> >  misunderstanding
> >  >> >>> something).
> >  >> >>>
> >  >> >>> best,
> >  >> >>> Colin
> >  >> >>>
> >  >> >>>
> >  >> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
> >  >> >>> > Thanks for reporting the blockers, folks. Good job finding.
> >  >> >>> >
> >  >> >>> > I have one ask - can 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Thanks Colin,

With that, I believe we are out of blockers. I was traveling today and
couldn't build an RC - expect one to be published tomorrow (barring any
problems).

In the meanwhile - here is a PR for the 3.7 blog post -
https://github.com/apache/kafka-site/pull/578

Best,
Stan

On Wed, Jan 10, 2024 at 12:06 AM Colin McCabe  wrote:

> KAFKA-16094 has been fixed and backported to 3.7.
>
> Colin
>
>
> On Mon, Jan 8, 2024, at 14:52, Colin McCabe wrote:
> > On an unrelated note, I found a blocker bug related to upgrades from
> > 3.6 (and earlier) to 3.7.
> >
> > The JIRA is here:
> >   https://issues.apache.org/jira/browse/KAFKA-16094
> >
> > Fix here:
> >   https://github.com/apache/kafka/pull/15153
> >
> > best,
> > Colin
> >
> >
> > On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote:
> >> Hi Ismael,
> >>
> >> I wasn't aware of that. If we are required to publish all modules, then
> >> this is working as intended.
> >>
> >> I am a bit curious if we've discussed why we need to publish the server
> >> modules to Sonatype. Is there a discussion about the pros and cons of
> >> this somewhere?
> >>
> >> regards,
> >> Colin
> >>
> >> On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote:
> >>> All modules are published to Sonatype - that's a requirement. You may
> be
> >>> missing the fact that `core` is published as `kafka_2.13` and
> `kafka_2.12`.
> >>>
> >>> Ismael
> >>>
> >>> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe 
> wrote:
> >>>
>  Hi Ismael,
> 
>  It seems like both the metadata gradle module and the server-common
> module
>  are getting published to Sonatype as separate artifacts, unless I'm
>  misunderstanding something. Example:
> 
>  https://central.sonatype.com/search?q=kafka-server-common
> 
>  I don't see kafka-core getting published, but maybe other private
>  server-side gradle modules are getting published.
> 
>  This seems bad. Is there a reason to publish modules that are only
> used by
>  the server on Sonatype?
> 
>  best,
>  Colin
> 
> 
>  On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote:
>  > Hi Colin,
>  >
>  > I think you may have misunderstood what they mean by gradle
> metadata -
>  it's
>  > not the Kafka metadata module.
>  >
>  > Ismael
>  >
>  > On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe 
> wrote:
>  >
>  >> Oops, hit send too soon. I see that #15127 was already merged. So
> we
>  >> should no longer be publishing :metadata as part of the clients
>  artifacts,
>  >> right?
>  >>
>  >> thanks,
>  >> Colin
>  >>
>  >>
>  >> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
>  >> > Hi Apporv,
>  >> >
>  >> > Please remove the metadata module from any artifacts published
> for
>  >> > clients. It is only used by the server.
>  >> >
>  >> > best,
>  >> > Colin
>  >> >
>  >> >
>  >> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
>  >> >> Hi Colin,
>  >> >> Thanks for the response. The only reason for asking the
> question of
>  >> >> publishing the metadata is because that's present in previous
> client
>  >> >> releases. For more context, the description of PR
>  >> >>  holds the details
> and
>  >> waiting
>  >> >> for the confirmation there prior to the merge.
>  >> >>
>  >> >> Regards,
>  >> >> Apoorv Mittal
>  >> >> +44 7721681581
>  >> >>
>  >> >>
>  >> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe <
> cmcc...@apache.org>
>  >> wrote:
>  >> >>
>  >> >>> metadata is an internal gradle module. It is not used by
> clients.
>  So I
>  >> >>> don't see why you would want to publish it (unless I'm
>  misunderstanding
>  >> >>> something).
>  >> >>>
>  >> >>> best,
>  >> >>> Colin
>  >> >>>
>  >> >>>
>  >> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
>  >> >>> > Thanks for reporting the blockers, folks. Good job finding.
>  >> >>> >
>  >> >>> > I have one ask - can anybody with Gradle expertise help
> review
>  this
>  >> small
>  >> >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
>  >> >>> > In particular, we are wondering whether we need to publish
> module
>  >> >>> metadata
>  >> >>> > as part of the gradle publishing process.
>  >> >>> >
>  >> >>> >
>  >> >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
>  >> >>> >  wrote:
>  >> >>> >
>  >> >>> >> We have potentially one more blocker
>  >> >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which
> might
>  >> cause a
>  >> >>> data
>  >> >>> >> loss scenario with JBOD in KRaft.
>  >> >>> >> Initial analysis thought this is a problem and further
> review
>  looks
>  >> >>> like it
>  >> >>> >> isn't but we are continuing to dig into the issue to 

Re: Apache Kafka 3.7.0 Release

[Colin McCabe]

KAFKA-16094 has been fixed and backported to 3.7.

Colin


On Mon, Jan 8, 2024, at 14:52, Colin McCabe wrote:
> On an unrelated note, I found a blocker bug related to upgrades from 
> 3.6 (and earlier) to 3.7.
>
> The JIRA is here: 
>   https://issues.apache.org/jira/browse/KAFKA-16094
>
> Fix here:
>   https://github.com/apache/kafka/pull/15153
>
> best,
> Colin
>
>
> On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote:
>> Hi Ismael,
>>
>> I wasn't aware of that. If we are required to publish all modules, then 
>> this is working as intended.
>>
>> I am a bit curious if we've discussed why we need to publish the server 
>> modules to Sonatype. Is there a discussion about the pros and cons of 
>> this somewhere?
>>
>> regards,
>> Colin
>>
>> On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote:
>>> All modules are published to Sonatype - that's a requirement. You may be
>>> missing the fact that `core` is published as `kafka_2.13` and `kafka_2.12`.
>>>
>>> Ismael
>>>
>>> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe  wrote:
>>>
 Hi Ismael,

 It seems like both the metadata gradle module and the server-common module
 are getting published to Sonatype as separate artifacts, unless I'm
 misunderstanding something. Example:

 https://central.sonatype.com/search?q=kafka-server-common

 I don't see kafka-core getting published, but maybe other private
 server-side gradle modules are getting published.

 This seems bad. Is there a reason to publish modules that are only used by
 the server on Sonatype?

 best,
 Colin


 On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote:
 > Hi Colin,
 >
 > I think you may have misunderstood what they mean by gradle metadata -
 it's
 > not the Kafka metadata module.
 >
 > Ismael
 >
 > On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe  wrote:
 >
 >> Oops, hit send too soon. I see that #15127 was already merged. So we
 >> should no longer be publishing :metadata as part of the clients
 artifacts,
 >> right?
 >>
 >> thanks,
 >> Colin
 >>
 >>
 >> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
 >> > Hi Apporv,
 >> >
 >> > Please remove the metadata module from any artifacts published for
 >> > clients. It is only used by the server.
 >> >
 >> > best,
 >> > Colin
 >> >
 >> >
 >> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
 >> >> Hi Colin,
 >> >> Thanks for the response. The only reason for asking the question of
 >> >> publishing the metadata is because that's present in previous client
 >> >> releases. For more context, the description of PR
 >> >>  holds the details and
 >> waiting
 >> >> for the confirmation there prior to the merge.
 >> >>
 >> >> Regards,
 >> >> Apoorv Mittal
 >> >> +44 7721681581
 >> >>
 >> >>
 >> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe 
 >> wrote:
 >> >>
 >> >>> metadata is an internal gradle module. It is not used by clients.
 So I
 >> >>> don't see why you would want to publish it (unless I'm
 misunderstanding
 >> >>> something).
 >> >>>
 >> >>> best,
 >> >>> Colin
 >> >>>
 >> >>>
 >> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
 >> >>> > Thanks for reporting the blockers, folks. Good job finding.
 >> >>> >
 >> >>> > I have one ask - can anybody with Gradle expertise help review
 this
 >> small
 >> >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
 >> >>> > In particular, we are wondering whether we need to publish module
 >> >>> metadata
 >> >>> > as part of the gradle publishing process.
 >> >>> >
 >> >>> >
 >> >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
 >> >>> >  wrote:
 >> >>> >
 >> >>> >> We have potentially one more blocker
 >> >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might
 >> cause a
 >> >>> data
 >> >>> >> loss scenario with JBOD in KRaft.
 >> >>> >> Initial analysis thought this is a problem and further review
 looks
 >> >>> like it
 >> >>> >> isn't but we are continuing to dig into the issue to ensure that
 it
 >> >>> isn't.
 >> >>> >> We would request feedback on the bug from anyone who is familiar
 >> with
 >> >>> this
 >> >>> >> code.
 >> >>> >>
 >> >>> >> --Proven
 >> >>> >>
 >> >>> >
 >> >>> >
 >> >>> > --
 >> >>> > Best,
 >> >>> > Stanislav
 >> >>>
 >>

Re: Apache Kafka 3.7.0 Release

[Colin McCabe]

On an unrelated note, I found a blocker bug related to upgrades from 3.6 (and 
earlier) to 3.7.

The JIRA is here: 
  https://issues.apache.org/jira/browse/KAFKA-16094

Fix here:
  https://github.com/apache/kafka/pull/15153

best,
Colin


On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote:
> Hi Ismael,
>
> I wasn't aware of that. If we are required to publish all modules, then 
> this is working as intended.
>
> I am a bit curious if we've discussed why we need to publish the server 
> modules to Sonatype. Is there a discussion about the pros and cons of 
> this somewhere?
>
> regards,
> Colin
>
> On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote:
>> All modules are published to Sonatype - that's a requirement. You may be
>> missing the fact that `core` is published as `kafka_2.13` and `kafka_2.12`.
>>
>> Ismael
>>
>> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe  wrote:
>>
>>> Hi Ismael,
>>>
>>> It seems like both the metadata gradle module and the server-common module
>>> are getting published to Sonatype as separate artifacts, unless I'm
>>> misunderstanding something. Example:
>>>
>>> https://central.sonatype.com/search?q=kafka-server-common
>>>
>>> I don't see kafka-core getting published, but maybe other private
>>> server-side gradle modules are getting published.
>>>
>>> This seems bad. Is there a reason to publish modules that are only used by
>>> the server on Sonatype?
>>>
>>> best,
>>> Colin
>>>
>>>
>>> On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote:
>>> > Hi Colin,
>>> >
>>> > I think you may have misunderstood what they mean by gradle metadata -
>>> it's
>>> > not the Kafka metadata module.
>>> >
>>> > Ismael
>>> >
>>> > On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe  wrote:
>>> >
>>> >> Oops, hit send too soon. I see that #15127 was already merged. So we
>>> >> should no longer be publishing :metadata as part of the clients
>>> artifacts,
>>> >> right?
>>> >>
>>> >> thanks,
>>> >> Colin
>>> >>
>>> >>
>>> >> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
>>> >> > Hi Apporv,
>>> >> >
>>> >> > Please remove the metadata module from any artifacts published for
>>> >> > clients. It is only used by the server.
>>> >> >
>>> >> > best,
>>> >> > Colin
>>> >> >
>>> >> >
>>> >> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
>>> >> >> Hi Colin,
>>> >> >> Thanks for the response. The only reason for asking the question of
>>> >> >> publishing the metadata is because that's present in previous client
>>> >> >> releases. For more context, the description of PR
>>> >> >>  holds the details and
>>> >> waiting
>>> >> >> for the confirmation there prior to the merge.
>>> >> >>
>>> >> >> Regards,
>>> >> >> Apoorv Mittal
>>> >> >> +44 7721681581
>>> >> >>
>>> >> >>
>>> >> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe 
>>> >> wrote:
>>> >> >>
>>> >> >>> metadata is an internal gradle module. It is not used by clients.
>>> So I
>>> >> >>> don't see why you would want to publish it (unless I'm
>>> misunderstanding
>>> >> >>> something).
>>> >> >>>
>>> >> >>> best,
>>> >> >>> Colin
>>> >> >>>
>>> >> >>>
>>> >> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
>>> >> >>> > Thanks for reporting the blockers, folks. Good job finding.
>>> >> >>> >
>>> >> >>> > I have one ask - can anybody with Gradle expertise help review
>>> this
>>> >> small
>>> >> >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
>>> >> >>> > In particular, we are wondering whether we need to publish module
>>> >> >>> metadata
>>> >> >>> > as part of the gradle publishing process.
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
>>> >> >>> >  wrote:
>>> >> >>> >
>>> >> >>> >> We have potentially one more blocker
>>> >> >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might
>>> >> cause a
>>> >> >>> data
>>> >> >>> >> loss scenario with JBOD in KRaft.
>>> >> >>> >> Initial analysis thought this is a problem and further review
>>> looks
>>> >> >>> like it
>>> >> >>> >> isn't but we are continuing to dig into the issue to ensure that
>>> it
>>> >> >>> isn't.
>>> >> >>> >> We would request feedback on the bug from anyone who is familiar
>>> >> with
>>> >> >>> this
>>> >> >>> >> code.
>>> >> >>> >>
>>> >> >>> >> --Proven
>>> >> >>> >>
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > --
>>> >> >>> > Best,
>>> >> >>> > Stanislav
>>> >> >>>
>>> >>
>>>

Re: Apache Kafka 3.7.0 Release

[Colin McCabe]

Hi Ismael,

I wasn't aware of that. If we are required to publish all modules, then this is 
working as intended.

I am a bit curious if we've discussed why we need to publish the server modules 
to Sonatype. Is there a discussion about the pros and cons of this somewhere?

regards,
Colin

On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote:
> All modules are published to Sonatype - that's a requirement. You may be
> missing the fact that `core` is published as `kafka_2.13` and `kafka_2.12`.
>
> Ismael
>
> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe  wrote:
>
>> Hi Ismael,
>>
>> It seems like both the metadata gradle module and the server-common module
>> are getting published to Sonatype as separate artifacts, unless I'm
>> misunderstanding something. Example:
>>
>> https://central.sonatype.com/search?q=kafka-server-common
>>
>> I don't see kafka-core getting published, but maybe other private
>> server-side gradle modules are getting published.
>>
>> This seems bad. Is there a reason to publish modules that are only used by
>> the server on Sonatype?
>>
>> best,
>> Colin
>>
>>
>> On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote:
>> > Hi Colin,
>> >
>> > I think you may have misunderstood what they mean by gradle metadata -
>> it's
>> > not the Kafka metadata module.
>> >
>> > Ismael
>> >
>> > On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe  wrote:
>> >
>> >> Oops, hit send too soon. I see that #15127 was already merged. So we
>> >> should no longer be publishing :metadata as part of the clients
>> artifacts,
>> >> right?
>> >>
>> >> thanks,
>> >> Colin
>> >>
>> >>
>> >> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
>> >> > Hi Apporv,
>> >> >
>> >> > Please remove the metadata module from any artifacts published for
>> >> > clients. It is only used by the server.
>> >> >
>> >> > best,
>> >> > Colin
>> >> >
>> >> >
>> >> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
>> >> >> Hi Colin,
>> >> >> Thanks for the response. The only reason for asking the question of
>> >> >> publishing the metadata is because that's present in previous client
>> >> >> releases. For more context, the description of PR
>> >> >>  holds the details and
>> >> waiting
>> >> >> for the confirmation there prior to the merge.
>> >> >>
>> >> >> Regards,
>> >> >> Apoorv Mittal
>> >> >> +44 7721681581
>> >> >>
>> >> >>
>> >> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe 
>> >> wrote:
>> >> >>
>> >> >>> metadata is an internal gradle module. It is not used by clients.
>> So I
>> >> >>> don't see why you would want to publish it (unless I'm
>> misunderstanding
>> >> >>> something).
>> >> >>>
>> >> >>> best,
>> >> >>> Colin
>> >> >>>
>> >> >>>
>> >> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
>> >> >>> > Thanks for reporting the blockers, folks. Good job finding.
>> >> >>> >
>> >> >>> > I have one ask - can anybody with Gradle expertise help review
>> this
>> >> small
>> >> >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
>> >> >>> > In particular, we are wondering whether we need to publish module
>> >> >>> metadata
>> >> >>> > as part of the gradle publishing process.
>> >> >>> >
>> >> >>> >
>> >> >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
>> >> >>> >  wrote:
>> >> >>> >
>> >> >>> >> We have potentially one more blocker
>> >> >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might
>> >> cause a
>> >> >>> data
>> >> >>> >> loss scenario with JBOD in KRaft.
>> >> >>> >> Initial analysis thought this is a problem and further review
>> looks
>> >> >>> like it
>> >> >>> >> isn't but we are continuing to dig into the issue to ensure that
>> it
>> >> >>> isn't.
>> >> >>> >> We would request feedback on the bug from anyone who is familiar
>> >> with
>> >> >>> this
>> >> >>> >> code.
>> >> >>> >>
>> >> >>> >> --Proven
>> >> >>> >>
>> >> >>> >
>> >> >>> >
>> >> >>> > --
>> >> >>> > Best,
>> >> >>> > Stanislav
>> >> >>>
>> >>
>>

Re: Apache Kafka 3.7.0 Release

[Ismael Juma]

All modules are published to Sonatype - that's a requirement. You may be
missing the fact that `core` is published as `kafka_2.13` and `kafka_2.12`.

Ismael

On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe  wrote:

> Hi Ismael,
>
> It seems like both the metadata gradle module and the server-common module
> are getting published to Sonatype as separate artifacts, unless I'm
> misunderstanding something. Example:
>
> https://central.sonatype.com/search?q=kafka-server-common
>
> I don't see kafka-core getting published, but maybe other private
> server-side gradle modules are getting published.
>
> This seems bad. Is there a reason to publish modules that are only used by
> the server on Sonatype?
>
> best,
> Colin
>
>
> On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote:
> > Hi Colin,
> >
> > I think you may have misunderstood what they mean by gradle metadata -
> it's
> > not the Kafka metadata module.
> >
> > Ismael
> >
> > On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe  wrote:
> >
> >> Oops, hit send too soon. I see that #15127 was already merged. So we
> >> should no longer be publishing :metadata as part of the clients
> artifacts,
> >> right?
> >>
> >> thanks,
> >> Colin
> >>
> >>
> >> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
> >> > Hi Apporv,
> >> >
> >> > Please remove the metadata module from any artifacts published for
> >> > clients. It is only used by the server.
> >> >
> >> > best,
> >> > Colin
> >> >
> >> >
> >> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
> >> >> Hi Colin,
> >> >> Thanks for the response. The only reason for asking the question of
> >> >> publishing the metadata is because that's present in previous client
> >> >> releases. For more context, the description of PR
> >> >>  holds the details and
> >> waiting
> >> >> for the confirmation there prior to the merge.
> >> >>
> >> >> Regards,
> >> >> Apoorv Mittal
> >> >> +44 7721681581
> >> >>
> >> >>
> >> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe 
> >> wrote:
> >> >>
> >> >>> metadata is an internal gradle module. It is not used by clients.
> So I
> >> >>> don't see why you would want to publish it (unless I'm
> misunderstanding
> >> >>> something).
> >> >>>
> >> >>> best,
> >> >>> Colin
> >> >>>
> >> >>>
> >> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
> >> >>> > Thanks for reporting the blockers, folks. Good job finding.
> >> >>> >
> >> >>> > I have one ask - can anybody with Gradle expertise help review
> this
> >> small
> >> >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
> >> >>> > In particular, we are wondering whether we need to publish module
> >> >>> metadata
> >> >>> > as part of the gradle publishing process.
> >> >>> >
> >> >>> >
> >> >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
> >> >>> >  wrote:
> >> >>> >
> >> >>> >> We have potentially one more blocker
> >> >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might
> >> cause a
> >> >>> data
> >> >>> >> loss scenario with JBOD in KRaft.
> >> >>> >> Initial analysis thought this is a problem and further review
> looks
> >> >>> like it
> >> >>> >> isn't but we are continuing to dig into the issue to ensure that
> it
> >> >>> isn't.
> >> >>> >> We would request feedback on the bug from anyone who is familiar
> >> with
> >> >>> this
> >> >>> >> code.
> >> >>> >>
> >> >>> >> --Proven
> >> >>> >>
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Best,
> >> >>> > Stanislav
> >> >>>
> >>
>

Re: Apache Kafka 3.7.0 Release

[Colin McCabe]

Hi Ismael,

It seems like both the metadata gradle module and the server-common module are 
getting published to Sonatype as separate artifacts, unless I'm 
misunderstanding something. Example:

https://central.sonatype.com/search?q=kafka-server-common

I don't see kafka-core getting published, but maybe other private server-side 
gradle modules are getting published.

This seems bad. Is there a reason to publish modules that are only used by the 
server on Sonatype?

best,
Colin


On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote:
> Hi Colin,
>
> I think you may have misunderstood what they mean by gradle metadata - it's
> not the Kafka metadata module.
>
> Ismael
>
> On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe  wrote:
>
>> Oops, hit send too soon. I see that #15127 was already merged. So we
>> should no longer be publishing :metadata as part of the clients artifacts,
>> right?
>>
>> thanks,
>> Colin
>>
>>
>> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
>> > Hi Apporv,
>> >
>> > Please remove the metadata module from any artifacts published for
>> > clients. It is only used by the server.
>> >
>> > best,
>> > Colin
>> >
>> >
>> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
>> >> Hi Colin,
>> >> Thanks for the response. The only reason for asking the question of
>> >> publishing the metadata is because that's present in previous client
>> >> releases. For more context, the description of PR
>> >>  holds the details and
>> waiting
>> >> for the confirmation there prior to the merge.
>> >>
>> >> Regards,
>> >> Apoorv Mittal
>> >> +44 7721681581
>> >>
>> >>
>> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe 
>> wrote:
>> >>
>> >>> metadata is an internal gradle module. It is not used by clients. So I
>> >>> don't see why you would want to publish it (unless I'm misunderstanding
>> >>> something).
>> >>>
>> >>> best,
>> >>> Colin
>> >>>
>> >>>
>> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
>> >>> > Thanks for reporting the blockers, folks. Good job finding.
>> >>> >
>> >>> > I have one ask - can anybody with Gradle expertise help review this
>> small
>> >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
>> >>> > In particular, we are wondering whether we need to publish module
>> >>> metadata
>> >>> > as part of the gradle publishing process.
>> >>> >
>> >>> >
>> >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
>> >>> >  wrote:
>> >>> >
>> >>> >> We have potentially one more blocker
>> >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might
>> cause a
>> >>> data
>> >>> >> loss scenario with JBOD in KRaft.
>> >>> >> Initial analysis thought this is a problem and further review looks
>> >>> like it
>> >>> >> isn't but we are continuing to dig into the issue to ensure that it
>> >>> isn't.
>> >>> >> We would request feedback on the bug from anyone who is familiar
>> with
>> >>> this
>> >>> >> code.
>> >>> >>
>> >>> >> --Proven
>> >>> >>
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Best,
>> >>> > Stanislav
>> >>>
>>

Re: Apache Kafka 3.7.0 Release

[David Jacot]

Hi all,

Are you talking about publishing the artefacts to maven central? Looking at
the history [1], it seems that the metadata module has been published since
we have it. I also see other internal modules there too.

[1]
https://central.sonatype.com/artifact/org.apache.kafka/kafka-metadata/versions

Best,
David

Le lun. 8 janv. 2024 à 21:51, Ismael Juma  a écrit :

> Hi Colin,
>
> I think you may have misunderstood what they mean by gradle metadata - it's
> not the Kafka metadata module.
>
> Ismael
>
> On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe  wrote:
>
> > Oops, hit send too soon. I see that #15127 was already merged. So we
> > should no longer be publishing :metadata as part of the clients
> artifacts,
> > right?
> >
> > thanks,
> > Colin
> >
> >
> > On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
> > > Hi Apporv,
> > >
> > > Please remove the metadata module from any artifacts published for
> > > clients. It is only used by the server.
> > >
> > > best,
> > > Colin
> > >
> > >
> > > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
> > >> Hi Colin,
> > >> Thanks for the response. The only reason for asking the question of
> > >> publishing the metadata is because that's present in previous client
> > >> releases. For more context, the description of PR
> > >>  holds the details and
> > waiting
> > >> for the confirmation there prior to the merge.
> > >>
> > >> Regards,
> > >> Apoorv Mittal
> > >> +44 7721681581
> > >>
> > >>
> > >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe 
> > wrote:
> > >>
> > >>> metadata is an internal gradle module. It is not used by clients. So
> I
> > >>> don't see why you would want to publish it (unless I'm
> misunderstanding
> > >>> something).
> > >>>
> > >>> best,
> > >>> Colin
> > >>>
> > >>>
> > >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
> > >>> > Thanks for reporting the blockers, folks. Good job finding.
> > >>> >
> > >>> > I have one ask - can anybody with Gradle expertise help review this
> > small
> > >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
> > >>> > In particular, we are wondering whether we need to publish module
> > >>> metadata
> > >>> > as part of the gradle publishing process.
> > >>> >
> > >>> >
> > >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
> > >>> >  wrote:
> > >>> >
> > >>> >> We have potentially one more blocker
> > >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might
> > cause a
> > >>> data
> > >>> >> loss scenario with JBOD in KRaft.
> > >>> >> Initial analysis thought this is a problem and further review
> looks
> > >>> like it
> > >>> >> isn't but we are continuing to dig into the issue to ensure that
> it
> > >>> isn't.
> > >>> >> We would request feedback on the bug from anyone who is familiar
> > with
> > >>> this
> > >>> >> code.
> > >>> >>
> > >>> >> --Proven
> > >>> >>
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Best,
> > >>> > Stanislav
> > >>>
> >
>

Re: Apache Kafka 3.7.0 Release

[Ismael Juma]

Hi Colin,

I think you may have misunderstood what they mean by gradle metadata - it's
not the Kafka metadata module.

Ismael

On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe  wrote:

> Oops, hit send too soon. I see that #15127 was already merged. So we
> should no longer be publishing :metadata as part of the clients artifacts,
> right?
>
> thanks,
> Colin
>
>
> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
> > Hi Apporv,
> >
> > Please remove the metadata module from any artifacts published for
> > clients. It is only used by the server.
> >
> > best,
> > Colin
> >
> >
> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
> >> Hi Colin,
> >> Thanks for the response. The only reason for asking the question of
> >> publishing the metadata is because that's present in previous client
> >> releases. For more context, the description of PR
> >>  holds the details and
> waiting
> >> for the confirmation there prior to the merge.
> >>
> >> Regards,
> >> Apoorv Mittal
> >> +44 7721681581
> >>
> >>
> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe 
> wrote:
> >>
> >>> metadata is an internal gradle module. It is not used by clients. So I
> >>> don't see why you would want to publish it (unless I'm misunderstanding
> >>> something).
> >>>
> >>> best,
> >>> Colin
> >>>
> >>>
> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
> >>> > Thanks for reporting the blockers, folks. Good job finding.
> >>> >
> >>> > I have one ask - can anybody with Gradle expertise help review this
> small
> >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
> >>> > In particular, we are wondering whether we need to publish module
> >>> metadata
> >>> > as part of the gradle publishing process.
> >>> >
> >>> >
> >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
> >>> >  wrote:
> >>> >
> >>> >> We have potentially one more blocker
> >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might
> cause a
> >>> data
> >>> >> loss scenario with JBOD in KRaft.
> >>> >> Initial analysis thought this is a problem and further review looks
> >>> like it
> >>> >> isn't but we are continuing to dig into the issue to ensure that it
> >>> isn't.
> >>> >> We would request feedback on the bug from anyone who is familiar
> with
> >>> this
> >>> >> code.
> >>> >>
> >>> >> --Proven
> >>> >>
> >>> >
> >>> >
> >>> > --
> >>> > Best,
> >>> > Stanislav
> >>>
>

Re: Apache Kafka 3.7.0 Release

[Colin McCabe]

Oops, hit send too soon. I see that #15127 was already merged. So we should no 
longer be publishing :metadata as part of the clients artifacts, right?

thanks,
Colin


On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote:
> Hi Apporv,
>
> Please remove the metadata module from any artifacts published for 
> clients. It is only used by the server.
>
> best,
> Colin
>
>
> On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
>> Hi Colin,
>> Thanks for the response. The only reason for asking the question of
>> publishing the metadata is because that's present in previous client
>> releases. For more context, the description of PR
>>  holds the details and waiting
>> for the confirmation there prior to the merge.
>>
>> Regards,
>> Apoorv Mittal
>> +44 7721681581
>>
>>
>> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe  wrote:
>>
>>> metadata is an internal gradle module. It is not used by clients. So I
>>> don't see why you would want to publish it (unless I'm misunderstanding
>>> something).
>>>
>>> best,
>>> Colin
>>>
>>>
>>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
>>> > Thanks for reporting the blockers, folks. Good job finding.
>>> >
>>> > I have one ask - can anybody with Gradle expertise help review this small
>>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
>>> > In particular, we are wondering whether we need to publish module
>>> metadata
>>> > as part of the gradle publishing process.
>>> >
>>> >
>>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
>>> >  wrote:
>>> >
>>> >> We have potentially one more blocker
>>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might cause a
>>> data
>>> >> loss scenario with JBOD in KRaft.
>>> >> Initial analysis thought this is a problem and further review looks
>>> like it
>>> >> isn't but we are continuing to dig into the issue to ensure that it
>>> isn't.
>>> >> We would request feedback on the bug from anyone who is familiar with
>>> this
>>> >> code.
>>> >>
>>> >> --Proven
>>> >>
>>> >
>>> >
>>> > --
>>> > Best,
>>> > Stanislav
>>>

Re: Apache Kafka 3.7.0 Release

[Colin McCabe]

Hi Apporv,

Please remove the metadata module from any artifacts published for clients. It 
is only used by the server.

best,
Colin


On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote:
> Hi Colin,
> Thanks for the response. The only reason for asking the question of
> publishing the metadata is because that's present in previous client
> releases. For more context, the description of PR
>  holds the details and waiting
> for the confirmation there prior to the merge.
>
> Regards,
> Apoorv Mittal
> +44 7721681581
>
>
> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe  wrote:
>
>> metadata is an internal gradle module. It is not used by clients. So I
>> don't see why you would want to publish it (unless I'm misunderstanding
>> something).
>>
>> best,
>> Colin
>>
>>
>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
>> > Thanks for reporting the blockers, folks. Good job finding.
>> >
>> > I have one ask - can anybody with Gradle expertise help review this small
>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
>> > In particular, we are wondering whether we need to publish module
>> metadata
>> > as part of the gradle publishing process.
>> >
>> >
>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
>> >  wrote:
>> >
>> >> We have potentially one more blocker
>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might cause a
>> data
>> >> loss scenario with JBOD in KRaft.
>> >> Initial analysis thought this is a problem and further review looks
>> like it
>> >> isn't but we are continuing to dig into the issue to ensure that it
>> isn't.
>> >> We would request feedback on the bug from anyone who is familiar with
>> this
>> >> code.
>> >>
>> >> --Proven
>> >>
>> >
>> >
>> > --
>> > Best,
>> > Stanislav
>>

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

I've almost got an RC candidate out to test. I just need a. review on the
kafka-site repo to update the website with the appropriate 3.7 subpages -
https://github.com/apache/kafka-site/pull/576/

On Mon, Jan 8, 2024 at 10:05 AM Lucas Brutschy
 wrote:

> Hi,
>
> we have fixed one memory leak in Kafka Streams, but there is still at
> least one missing in the code. I created
> https://issues.apache.org/jira/browse/KAFKA-16089 which is a blocker.
>
> Cheers,
> Lucas
>
> On Sun, Jan 7, 2024 at 12:05 PM Apoorv Mittal 
> wrote:
> >
> > Hi Colin,
> > Thanks for the response. The only reason for asking the question of
> > publishing the metadata is because that's present in previous client
> > releases. For more context, the description of PR
> >  holds the details and
> waiting
> > for the confirmation there prior to the merge.
> >
> > Regards,
> > Apoorv Mittal
> > +44 7721681581
> >
> >
> > On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe  wrote:
> >
> > > metadata is an internal gradle module. It is not used by clients. So I
> > > don't see why you would want to publish it (unless I'm misunderstanding
> > > something).
> > >
> > > best,
> > > Colin
> > >
> > >
> > > On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
> > > > Thanks for reporting the blockers, folks. Good job finding.
> > > >
> > > > I have one ask - can anybody with Gradle expertise help review this
> small
> > > > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
> > > > In particular, we are wondering whether we need to publish module
> > > metadata
> > > > as part of the gradle publishing process.
> > > >
> > > >
> > > > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
> > > >  wrote:
> > > >
> > > >> We have potentially one more blocker
> > > >> https://issues.apache.org/jira/browse/KAFKA-16082 which might
> cause a
> > > data
> > > >> loss scenario with JBOD in KRaft.
> > > >> Initial analysis thought this is a problem and further review looks
> > > like it
> > > >> isn't but we are continuing to dig into the issue to ensure that it
> > > isn't.
> > > >> We would request feedback on the bug from anyone who is familiar
> with
> > > this
> > > >> code.
> > > >>
> > > >> --Proven
> > > >>
> > > >
> > > >
> > > > --
> > > > Best,
> > > > Stanislav
> > >
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Lucas Brutschy]

Hi,

we have fixed one memory leak in Kafka Streams, but there is still at
least one missing in the code. I created
https://issues.apache.org/jira/browse/KAFKA-16089 which is a blocker.

Cheers,
Lucas

On Sun, Jan 7, 2024 at 12:05 PM Apoorv Mittal  wrote:
>
> Hi Colin,
> Thanks for the response. The only reason for asking the question of
> publishing the metadata is because that's present in previous client
> releases. For more context, the description of PR
>  holds the details and waiting
> for the confirmation there prior to the merge.
>
> Regards,
> Apoorv Mittal
> +44 7721681581
>
>
> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe  wrote:
>
> > metadata is an internal gradle module. It is not used by clients. So I
> > don't see why you would want to publish it (unless I'm misunderstanding
> > something).
> >
> > best,
> > Colin
> >
> >
> > On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
> > > Thanks for reporting the blockers, folks. Good job finding.
> > >
> > > I have one ask - can anybody with Gradle expertise help review this small
> > > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
> > > In particular, we are wondering whether we need to publish module
> > metadata
> > > as part of the gradle publishing process.
> > >
> > >
> > > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
> > >  wrote:
> > >
> > >> We have potentially one more blocker
> > >> https://issues.apache.org/jira/browse/KAFKA-16082 which might cause a
> > data
> > >> loss scenario with JBOD in KRaft.
> > >> Initial analysis thought this is a problem and further review looks
> > like it
> > >> isn't but we are continuing to dig into the issue to ensure that it
> > isn't.
> > >> We would request feedback on the bug from anyone who is familiar with
> > this
> > >> code.
> > >>
> > >> --Proven
> > >>
> > >
> > >
> > > --
> > > Best,
> > > Stanislav
> >

Re: Apache Kafka 3.7.0 Release

[Apoorv Mittal]

Hi Colin,
Thanks for the response. The only reason for asking the question of
publishing the metadata is because that's present in previous client
releases. For more context, the description of PR
 holds the details and waiting
for the confirmation there prior to the merge.

Regards,
Apoorv Mittal
+44 7721681581


On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe  wrote:

> metadata is an internal gradle module. It is not used by clients. So I
> don't see why you would want to publish it (unless I'm misunderstanding
> something).
>
> best,
> Colin
>
>
> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
> > Thanks for reporting the blockers, folks. Good job finding.
> >
> > I have one ask - can anybody with Gradle expertise help review this small
> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
> > In particular, we are wondering whether we need to publish module
> metadata
> > as part of the gradle publishing process.
> >
> >
> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
> >  wrote:
> >
> >> We have potentially one more blocker
> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might cause a
> data
> >> loss scenario with JBOD in KRaft.
> >> Initial analysis thought this is a problem and further review looks
> like it
> >> isn't but we are continuing to dig into the issue to ensure that it
> isn't.
> >> We would request feedback on the bug from anyone who is familiar with
> this
> >> code.
> >>
> >> --Proven
> >>
> >
> >
> > --
> > Best,
> > Stanislav
>

Re: Apache Kafka 3.7.0 Release

[Colin McCabe]

metadata is an internal gradle module. It is not used by clients. So I don't 
see why you would want to publish it (unless I'm misunderstanding something).

best,
Colin


On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote:
> Thanks for reporting the blockers, folks. Good job finding.
>
> I have one ask - can anybody with Gradle expertise help review this small
> PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
> In particular, we are wondering whether we need to publish module metadata
> as part of the gradle publishing process.
>
>
> On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
>  wrote:
>
>> We have potentially one more blocker
>> https://issues.apache.org/jira/browse/KAFKA-16082 which might cause a data
>> loss scenario with JBOD in KRaft.
>> Initial analysis thought this is a problem and further review looks like it
>> isn't but we are continuing to dig into the issue to ensure that it isn't.
>> We would request feedback on the bug from anyone who is familiar with this
>> code.
>>
>> --Proven
>>
>
>
> -- 
> Best,
> Stanislav

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Thanks for reporting the blockers, folks. Good job finding.

I have one ask - can anybody with Gradle expertise help review this small
PR? https://github.com/apache/kafka/pull/15127 (+1, -1)
In particular, we are wondering whether we need to publish module metadata
as part of the gradle publishing process.


On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano
 wrote:

> We have potentially one more blocker
> https://issues.apache.org/jira/browse/KAFKA-16082 which might cause a data
> loss scenario with JBOD in KRaft.
> Initial analysis thought this is a problem and further review looks like it
> isn't but we are continuing to dig into the issue to ensure that it isn't.
> We would request feedback on the bug from anyone who is familiar with this
> code.
>
> --Proven
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Proven Provenzano]

We have potentially one more blocker
https://issues.apache.org/jira/browse/KAFKA-16082 which might cause a data
loss scenario with JBOD in KRaft.
Initial analysis thought this is a problem and further review looks like it
isn't but we are continuing to dig into the issue to ensure that it isn't.
We would request feedback on the bug from anyone who is familiar with this
code.

--Proven

Re: Apache Kafka 3.7.0 Release

[Matthias J. Sax]

One more blocker (memory leak) for 3.7: 
https://issues.apache.org/jira/browse/KAFKA-16086



-Matthias

On 1/4/24 9:53 PM, Stanislav Kozlovski wrote:

Thanks Apoorv, I was going to update the mailing thread as well.

Major kudos to Apoorv for the thorough work debugging and getting to the
bottom of this tricky publishing issue, a subtle regression from the work
he did in making the kafka-clients jar shadowed.

On Thu, Jan 4, 2024 at 5:09 PM Apoorv Mittal 
wrote:


Hi Stan,
I have opened the minor PR: https://github.com/apache/kafka/pull/15127 to
fix publishing the dependency. Once discussed and merged in trunk, I'll
update the 3.7 branch as well.

Regards,
Apoorv Mittal
+44 7721681581


On Thu, Jan 4, 2024 at 12:49 PM Matthias J. Sax  wrote:


We found a blocker for 3.7:
https://issues.apache.org/jira/browse/KAFKA-16077

Already having a PR under review to fix it.


-Matthias

On 1/3/24 10:43 AM, Stanislav Kozlovski wrote:

Hey all, happy new year.

Thanks for the heads up Almog. Makes sense.

To give an update - I haven't been able to resolve the gradlewAll

publish

failure, and as such haven't been able to release an RC.
As a minor barrier, I have to also update the year in the NOTICE file,
otherwise the release script won't let me continue -
https://github.com/apache/kafka/pull/15111

Me and Apoorv synced offline and ran a few tests to debug the issue
regarding the clients build. I successfully executed `publish` when
pointing toward a custom jfrog repo with both JDK 8 and 17. Inspecting

the

debug logs, the task that previously failed
`:clients:publishMavenJavaPublicationToMavenRepository'` passed
successfully. Here's a sample of the logs -




https://gist.github.com/stanislavkozlovski/841060cb467ec1d179cc9f293c8702e7


Having read the release.py script a few times, I am not able to see

what

is

different in the setup there. It simply clones the repo anew, gets the

3.7

branch and runs the same command.

At this point, I am contemplating pushing a commit to 3.7 that modifies

the

release.py file that enables debug on the command:
diff --git a/release.py b/release.py
index 43c5809861..e299e10e74 100755
--- a/release.py
+++ b/release.py
@@ -675,7 +675,7 @@ with
open(os.path.expanduser("~/.gradle/gradle.properties")) as f:
   contents = f.read()
   if not user_ok("Going to build and upload mvn artifacts based on

these

settings:\n" + contents + '\nOK (y/n)?: '):
   fail("Retry again later")
-cmd("Building and uploading archives", "./gradlewAll publish",
cwd=kafka_dir, env=jdk8_env, shell=True)
+cmd("Building and uploading archives", "./gradlewAll publish --debug",
cwd=kafka_dir, env=jdk8_env, shell=True)
   cmd("Building and uploading archives", "mvn deploy -Pgpg-signing",
cwd=streams_quickstart_dir, env=jdk8_env, shell=True)

   release_notification_props = { 'release_version': release_version,
(END)

and continuing to debug through that.

Since the release.py script grabs a new copy of origin, we have to

modify

upstream. An alternative is for me to use my local github Kafka repo,

but

that may result in the script pushing a build of that into the remote
servers.

On Tue, Jan 2, 2024 at 8:17 PM Almog Gavra 

wrote:



Hello Stan,

I wanted to give you a heads up that
https://github.com/apache/kafka/pull/15073 (
https://issues.apache.org/jira/browse/KAFKA-16046) was identified as

a

blocker regression and should be merged to trunk by EOD.

Cheers,
Almog

On Tue, Jan 2, 2024 at 4:20 AM Stanislav Kozlovski
 wrote:


Hi Apoorv,

Thanks for taking ownership and looking into this! One more caveat is

that

I believe this first publish is ran with JDK 8, as the release.py

runs

with

both JDK 8 and (if I recall correctly) 17 versions. This seems to

fail

on

the first one - so JDK 8.
Not sure if that is related in any way. And I'm also not sure if it

should

be kafka-clients or just clients.

On Sat, Dec 30, 2023 at 10:48 AM Apoorv Mittal <

apoorvmitta...@gmail.com


wrote:


Hi Stan,
Thanks for looking into the release. I worked with `./gradlewAll
publishToMavenLocal` which generates the respective

`kafka-clients.jar`

and deploys to maven local, I believed that `./gradlewAll publish`

should

just publish the artifacts to remote repository and hence should

always

work as jars successfully gets deployed to local maven.

Though now I set up the remote private maven repository for myself

(on

jfrog) and tried `./gradlewAll publish` on the 3.7 branch and
successfully completed the build with all artifacts uploaded to the

remote

repository. What seems strange to me is the error you mentioned in

the

previous email regarding the reference of the clients jar. I suppose

the

reference should be to `kafka-clients.jar` rather than

`clients.jar`,

I

might be missing if something else gets triggered in the release

pipeline.

Do you think I should set up the remote repository as per the

instructions

in `release.py` and try running `./release.py` as that might do

something

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Thanks Apoorv, I was going to update the mailing thread as well.

Major kudos to Apoorv for the thorough work debugging and getting to the
bottom of this tricky publishing issue, a subtle regression from the work
he did in making the kafka-clients jar shadowed.

On Thu, Jan 4, 2024 at 5:09 PM Apoorv Mittal 
wrote:

> Hi Stan,
> I have opened the minor PR: https://github.com/apache/kafka/pull/15127 to
> fix publishing the dependency. Once discussed and merged in trunk, I'll
> update the 3.7 branch as well.
>
> Regards,
> Apoorv Mittal
> +44 7721681581
>
>
> On Thu, Jan 4, 2024 at 12:49 PM Matthias J. Sax  wrote:
>
> > We found a blocker for 3.7:
> > https://issues.apache.org/jira/browse/KAFKA-16077
> >
> > Already having a PR under review to fix it.
> >
> >
> > -Matthias
> >
> > On 1/3/24 10:43 AM, Stanislav Kozlovski wrote:
> > > Hey all, happy new year.
> > >
> > > Thanks for the heads up Almog. Makes sense.
> > >
> > > To give an update - I haven't been able to resolve the gradlewAll
> publish
> > > failure, and as such haven't been able to release an RC.
> > > As a minor barrier, I have to also update the year in the NOTICE file,
> > > otherwise the release script won't let me continue -
> > > https://github.com/apache/kafka/pull/15111
> > >
> > > Me and Apoorv synced offline and ran a few tests to debug the issue
> > > regarding the clients build. I successfully executed `publish` when
> > > pointing toward a custom jfrog repo with both JDK 8 and 17. Inspecting
> > the
> > > debug logs, the task that previously failed
> > > `:clients:publishMavenJavaPublicationToMavenRepository'` passed
> > > successfully. Here's a sample of the logs -
> > >
> >
> https://gist.github.com/stanislavkozlovski/841060cb467ec1d179cc9f293c8702e7
> > >
> > > Having read the release.py script a few times, I am not able to see
> what
> > is
> > > different in the setup there. It simply clones the repo anew, gets the
> > 3.7
> > > branch and runs the same command.
> > >
> > > At this point, I am contemplating pushing a commit to 3.7 that modifies
> > the
> > > release.py file that enables debug on the command:
> > > diff --git a/release.py b/release.py
> > > index 43c5809861..e299e10e74 100755
> > > --- a/release.py
> > > +++ b/release.py
> > > @@ -675,7 +675,7 @@ with
> > > open(os.path.expanduser("~/.gradle/gradle.properties")) as f:
> > >   contents = f.read()
> > >   if not user_ok("Going to build and upload mvn artifacts based on
> these
> > > settings:\n" + contents + '\nOK (y/n)?: '):
> > >   fail("Retry again later")
> > > -cmd("Building and uploading archives", "./gradlewAll publish",
> > > cwd=kafka_dir, env=jdk8_env, shell=True)
> > > +cmd("Building and uploading archives", "./gradlewAll publish --debug",
> > > cwd=kafka_dir, env=jdk8_env, shell=True)
> > >   cmd("Building and uploading archives", "mvn deploy -Pgpg-signing",
> > > cwd=streams_quickstart_dir, env=jdk8_env, shell=True)
> > >
> > >   release_notification_props = { 'release_version': release_version,
> > > (END)
> > >
> > > and continuing to debug through that.
> > >
> > > Since the release.py script grabs a new copy of origin, we have to
> modify
> > > upstream. An alternative is for me to use my local github Kafka repo,
> but
> > > that may result in the script pushing a build of that into the remote
> > > servers.
> > >
> > > On Tue, Jan 2, 2024 at 8:17 PM Almog Gavra 
> > wrote:
> > >
> > >> Hello Stan,
> > >>
> > >> I wanted to give you a heads up that
> > >> https://github.com/apache/kafka/pull/15073 (
> > >> https://issues.apache.org/jira/browse/KAFKA-16046) was identified as
> a
> > >> blocker regression and should be merged to trunk by EOD.
> > >>
> > >> Cheers,
> > >> Almog
> > >>
> > >> On Tue, Jan 2, 2024 at 4:20 AM Stanislav Kozlovski
> > >>  wrote:
> > >>
> > >>> Hi Apoorv,
> > >>>
> > >>> Thanks for taking ownership and looking into this! One more caveat is
> > >> that
> > >>> I believe this first publish is ran with JDK 8, as the release.py
> runs
> > >> with
> > >>> both JDK 8 and (if I recall correctly) 17 versions. This seems to
> fail
> > on
> > >>> the first one - so JDK 8.
> > >>> Not sure if that is related in any way. And I'm also not sure if it
> > >> should
> > >>> be kafka-clients or just clients.
> > >>>
> > >>> On Sat, Dec 30, 2023 at 10:48 AM Apoorv Mittal <
> > apoorvmitta...@gmail.com
> > >>>
> > >>> wrote:
> > >>>
> >  Hi Stan,
> >  Thanks for looking into the release. I worked with `./gradlewAll
> >  publishToMavenLocal` which generates the respective
> > `kafka-clients.jar`
> >  and deploys to maven local, I believed that `./gradlewAll publish`
> > >> should
> >  just publish the artifacts to remote repository and hence should
> > always
> >  work as jars successfully gets deployed to local maven.
> > 
> >  Though now I set up the remote private maven repository for myself
> (on
> >  jfrog) and tried `./gradlewAll publish` on the 3.7 branch and
> >  successfully completed 

Re: Apache Kafka 3.7.0 Release

[Apoorv Mittal]

Hi Stan,
I have opened the minor PR: https://github.com/apache/kafka/pull/15127 to
fix publishing the dependency. Once discussed and merged in trunk, I'll
update the 3.7 branch as well.

Regards,
Apoorv Mittal
+44 7721681581


On Thu, Jan 4, 2024 at 12:49 PM Matthias J. Sax  wrote:

> We found a blocker for 3.7:
> https://issues.apache.org/jira/browse/KAFKA-16077
>
> Already having a PR under review to fix it.
>
>
> -Matthias
>
> On 1/3/24 10:43 AM, Stanislav Kozlovski wrote:
> > Hey all, happy new year.
> >
> > Thanks for the heads up Almog. Makes sense.
> >
> > To give an update - I haven't been able to resolve the gradlewAll publish
> > failure, and as such haven't been able to release an RC.
> > As a minor barrier, I have to also update the year in the NOTICE file,
> > otherwise the release script won't let me continue -
> > https://github.com/apache/kafka/pull/15111
> >
> > Me and Apoorv synced offline and ran a few tests to debug the issue
> > regarding the clients build. I successfully executed `publish` when
> > pointing toward a custom jfrog repo with both JDK 8 and 17. Inspecting
> the
> > debug logs, the task that previously failed
> > `:clients:publishMavenJavaPublicationToMavenRepository'` passed
> > successfully. Here's a sample of the logs -
> >
> https://gist.github.com/stanislavkozlovski/841060cb467ec1d179cc9f293c8702e7
> >
> > Having read the release.py script a few times, I am not able to see what
> is
> > different in the setup there. It simply clones the repo anew, gets the
> 3.7
> > branch and runs the same command.
> >
> > At this point, I am contemplating pushing a commit to 3.7 that modifies
> the
> > release.py file that enables debug on the command:
> > diff --git a/release.py b/release.py
> > index 43c5809861..e299e10e74 100755
> > --- a/release.py
> > +++ b/release.py
> > @@ -675,7 +675,7 @@ with
> > open(os.path.expanduser("~/.gradle/gradle.properties")) as f:
> >   contents = f.read()
> >   if not user_ok("Going to build and upload mvn artifacts based on these
> > settings:\n" + contents + '\nOK (y/n)?: '):
> >   fail("Retry again later")
> > -cmd("Building and uploading archives", "./gradlewAll publish",
> > cwd=kafka_dir, env=jdk8_env, shell=True)
> > +cmd("Building and uploading archives", "./gradlewAll publish --debug",
> > cwd=kafka_dir, env=jdk8_env, shell=True)
> >   cmd("Building and uploading archives", "mvn deploy -Pgpg-signing",
> > cwd=streams_quickstart_dir, env=jdk8_env, shell=True)
> >
> >   release_notification_props = { 'release_version': release_version,
> > (END)
> >
> > and continuing to debug through that.
> >
> > Since the release.py script grabs a new copy of origin, we have to modify
> > upstream. An alternative is for me to use my local github Kafka repo, but
> > that may result in the script pushing a build of that into the remote
> > servers.
> >
> > On Tue, Jan 2, 2024 at 8:17 PM Almog Gavra 
> wrote:
> >
> >> Hello Stan,
> >>
> >> I wanted to give you a heads up that
> >> https://github.com/apache/kafka/pull/15073 (
> >> https://issues.apache.org/jira/browse/KAFKA-16046) was identified as a
> >> blocker regression and should be merged to trunk by EOD.
> >>
> >> Cheers,
> >> Almog
> >>
> >> On Tue, Jan 2, 2024 at 4:20 AM Stanislav Kozlovski
> >>  wrote:
> >>
> >>> Hi Apoorv,
> >>>
> >>> Thanks for taking ownership and looking into this! One more caveat is
> >> that
> >>> I believe this first publish is ran with JDK 8, as the release.py runs
> >> with
> >>> both JDK 8 and (if I recall correctly) 17 versions. This seems to fail
> on
> >>> the first one - so JDK 8.
> >>> Not sure if that is related in any way. And I'm also not sure if it
> >> should
> >>> be kafka-clients or just clients.
> >>>
> >>> On Sat, Dec 30, 2023 at 10:48 AM Apoorv Mittal <
> apoorvmitta...@gmail.com
> >>>
> >>> wrote:
> >>>
>  Hi Stan,
>  Thanks for looking into the release. I worked with `./gradlewAll
>  publishToMavenLocal` which generates the respective
> `kafka-clients.jar`
>  and deploys to maven local, I believed that `./gradlewAll publish`
> >> should
>  just publish the artifacts to remote repository and hence should
> always
>  work as jars successfully gets deployed to local maven.
> 
>  Though now I set up the remote private maven repository for myself (on
>  jfrog) and tried `./gradlewAll publish` on the 3.7 branch and
>  successfully completed the build with all artifacts uploaded to the
> >>> remote
>  repository. What seems strange to me is the error you mentioned in the
>  previous email regarding the reference of the clients jar. I suppose
> >> the
>  reference should be to `kafka-clients.jar` rather than `clients.jar`,
> I
>  might be missing if something else gets triggered in the release
> >>> pipeline.
>  Do you think I should set up the remote repository as per the
> >>> instructions
>  in `release.py` and try running `./release.py` as that might do
> >> something
>  different, 

Re: Apache Kafka 3.7.0 Release

[Matthias J. Sax]

We found a blocker for 3.7: 
https://issues.apache.org/jira/browse/KAFKA-16077


Already having a PR under review to fix it.


-Matthias

On 1/3/24 10:43 AM, Stanislav Kozlovski wrote:

Hey all, happy new year.

Thanks for the heads up Almog. Makes sense.

To give an update - I haven't been able to resolve the gradlewAll publish
failure, and as such haven't been able to release an RC.
As a minor barrier, I have to also update the year in the NOTICE file,
otherwise the release script won't let me continue -
https://github.com/apache/kafka/pull/15111

Me and Apoorv synced offline and ran a few tests to debug the issue
regarding the clients build. I successfully executed `publish` when
pointing toward a custom jfrog repo with both JDK 8 and 17. Inspecting the
debug logs, the task that previously failed
`:clients:publishMavenJavaPublicationToMavenRepository'` passed
successfully. Here's a sample of the logs -
https://gist.github.com/stanislavkozlovski/841060cb467ec1d179cc9f293c8702e7

Having read the release.py script a few times, I am not able to see what is
different in the setup there. It simply clones the repo anew, gets the 3.7
branch and runs the same command.

At this point, I am contemplating pushing a commit to 3.7 that modifies the
release.py file that enables debug on the command:
diff --git a/release.py b/release.py
index 43c5809861..e299e10e74 100755
--- a/release.py
+++ b/release.py
@@ -675,7 +675,7 @@ with
open(os.path.expanduser("~/.gradle/gradle.properties")) as f:
  contents = f.read()
  if not user_ok("Going to build and upload mvn artifacts based on these
settings:\n" + contents + '\nOK (y/n)?: '):
  fail("Retry again later")
-cmd("Building and uploading archives", "./gradlewAll publish",
cwd=kafka_dir, env=jdk8_env, shell=True)
+cmd("Building and uploading archives", "./gradlewAll publish --debug",
cwd=kafka_dir, env=jdk8_env, shell=True)
  cmd("Building and uploading archives", "mvn deploy -Pgpg-signing",
cwd=streams_quickstart_dir, env=jdk8_env, shell=True)

  release_notification_props = { 'release_version': release_version,
(END)

and continuing to debug through that.

Since the release.py script grabs a new copy of origin, we have to modify
upstream. An alternative is for me to use my local github Kafka repo, but
that may result in the script pushing a build of that into the remote
servers.

On Tue, Jan 2, 2024 at 8:17 PM Almog Gavra  wrote:


Hello Stan,

I wanted to give you a heads up that
https://github.com/apache/kafka/pull/15073 (
https://issues.apache.org/jira/browse/KAFKA-16046) was identified as a
blocker regression and should be merged to trunk by EOD.

Cheers,
Almog

On Tue, Jan 2, 2024 at 4:20 AM Stanislav Kozlovski
 wrote:


Hi Apoorv,

Thanks for taking ownership and looking into this! One more caveat is

that

I believe this first publish is ran with JDK 8, as the release.py runs

with

both JDK 8 and (if I recall correctly) 17 versions. This seems to fail on
the first one - so JDK 8.
Not sure if that is related in any way. And I'm also not sure if it

should

be kafka-clients or just clients.

On Sat, Dec 30, 2023 at 10:48 AM Apoorv Mittal 
Hi Stan,
Thanks for looking into the release. I worked with `./gradlewAll
publishToMavenLocal` which generates the respective `kafka-clients.jar`
and deploys to maven local, I believed that `./gradlewAll publish`

should

just publish the artifacts to remote repository and hence should always
work as jars successfully gets deployed to local maven.

Though now I set up the remote private maven repository for myself (on
jfrog) and tried `./gradlewAll publish` on the 3.7 branch and
successfully completed the build with all artifacts uploaded to the

remote

repository. What seems strange to me is the error you mentioned in the
previous email regarding the reference of the clients jar. I suppose

the

reference should be to `kafka-clients.jar` rather than `clients.jar`, I
might be missing if something else gets triggered in the release

pipeline.

Do you think I should set up the remote repository as per the

instructions

in `release.py` and try running `./release.py` as that might do

something

different, though I suspect that it should?

[image: Screenshot 2023-12-30 at 9.33.42 AM.png]


Regards,
Apoorv Mittal


On Fri, Dec 29, 2023 at 2:13 AM Colin McCabe 

wrote:



Just to update this thread, everything in KAFKA-14127 is done now. A

few

tasks got moved to a separate umbrella JIRA.

Some folks are going to do more testing, both manual and automated, in
the next week or two. I think this will give us a good indicator of
stability and what we need to fix.

Right now I'm leaning towards just making it GA since that's how most
features work. It's kind of rare for us to do a multi-step rollout for

new

features.

best,
Colin


On Wed, Dec 20, 2023, at 03:43, Mickael Maison wrote:

Hi,

With the current timeline for 3.7, I tend to agree with Viktor that
JBOD support in KRaft is unlikely to receive the extensive testing
this 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Hey all, happy new year.

Thanks for the heads up Almog. Makes sense.

To give an update - I haven't been able to resolve the gradlewAll publish
failure, and as such haven't been able to release an RC.
As a minor barrier, I have to also update the year in the NOTICE file,
otherwise the release script won't let me continue -
https://github.com/apache/kafka/pull/15111

Me and Apoorv synced offline and ran a few tests to debug the issue
regarding the clients build. I successfully executed `publish` when
pointing toward a custom jfrog repo with both JDK 8 and 17. Inspecting the
debug logs, the task that previously failed
`:clients:publishMavenJavaPublicationToMavenRepository'` passed
successfully. Here's a sample of the logs -
https://gist.github.com/stanislavkozlovski/841060cb467ec1d179cc9f293c8702e7

Having read the release.py script a few times, I am not able to see what is
different in the setup there. It simply clones the repo anew, gets the 3.7
branch and runs the same command.

At this point, I am contemplating pushing a commit to 3.7 that modifies the
release.py file that enables debug on the command:
diff --git a/release.py b/release.py
index 43c5809861..e299e10e74 100755
--- a/release.py
+++ b/release.py
@@ -675,7 +675,7 @@ with
open(os.path.expanduser("~/.gradle/gradle.properties")) as f:
 contents = f.read()
 if not user_ok("Going to build and upload mvn artifacts based on these
settings:\n" + contents + '\nOK (y/n)?: '):
 fail("Retry again later")
-cmd("Building and uploading archives", "./gradlewAll publish",
cwd=kafka_dir, env=jdk8_env, shell=True)
+cmd("Building and uploading archives", "./gradlewAll publish --debug",
cwd=kafka_dir, env=jdk8_env, shell=True)
 cmd("Building and uploading archives", "mvn deploy -Pgpg-signing",
cwd=streams_quickstart_dir, env=jdk8_env, shell=True)

 release_notification_props = { 'release_version': release_version,
(END)

and continuing to debug through that.

Since the release.py script grabs a new copy of origin, we have to modify
upstream. An alternative is for me to use my local github Kafka repo, but
that may result in the script pushing a build of that into the remote
servers.

On Tue, Jan 2, 2024 at 8:17 PM Almog Gavra  wrote:

> Hello Stan,
>
> I wanted to give you a heads up that
> https://github.com/apache/kafka/pull/15073 (
> https://issues.apache.org/jira/browse/KAFKA-16046) was identified as a
> blocker regression and should be merged to trunk by EOD.
>
> Cheers,
> Almog
>
> On Tue, Jan 2, 2024 at 4:20 AM Stanislav Kozlovski
>  wrote:
>
> > Hi Apoorv,
> >
> > Thanks for taking ownership and looking into this! One more caveat is
> that
> > I believe this first publish is ran with JDK 8, as the release.py runs
> with
> > both JDK 8 and (if I recall correctly) 17 versions. This seems to fail on
> > the first one - so JDK 8.
> > Not sure if that is related in any way. And I'm also not sure if it
> should
> > be kafka-clients or just clients.
> >
> > On Sat, Dec 30, 2023 at 10:48 AM Apoorv Mittal  >
> > wrote:
> >
> > > Hi Stan,
> > > Thanks for looking into the release. I worked with `./gradlewAll
> > > publishToMavenLocal` which generates the respective `kafka-clients.jar`
> > > and deploys to maven local, I believed that `./gradlewAll publish`
> should
> > > just publish the artifacts to remote repository and hence should always
> > > work as jars successfully gets deployed to local maven.
> > >
> > > Though now I set up the remote private maven repository for myself (on
> > > jfrog) and tried `./gradlewAll publish` on the 3.7 branch and
> > > successfully completed the build with all artifacts uploaded to the
> > remote
> > > repository. What seems strange to me is the error you mentioned in the
> > > previous email regarding the reference of the clients jar. I suppose
> the
> > > reference should be to `kafka-clients.jar` rather than `clients.jar`, I
> > > might be missing if something else gets triggered in the release
> > pipeline.
> > > Do you think I should set up the remote repository as per the
> > instructions
> > > in `release.py` and try running `./release.py` as that might do
> something
> > > different, though I suspect that it should?
> > >
> > > [image: Screenshot 2023-12-30 at 9.33.42 AM.png]
> > >
> > >
> > > Regards,
> > > Apoorv Mittal
> > >
> > >
> > > On Fri, Dec 29, 2023 at 2:13 AM Colin McCabe 
> wrote:
> > >
> > >> Just to update this thread, everything in KAFKA-14127 is done now. A
> few
> > >> tasks got moved to a separate umbrella JIRA.
> > >>
> > >> Some folks are going to do more testing, both manual and automated, in
> > >> the next week or two. I think this will give us a good indicator of
> > >> stability and what we need to fix.
> > >>
> > >> Right now I'm leaning towards just making it GA since that's how most
> > >> features work. It's kind of rare for us to do a multi-step rollout for
> > new
> > >> features.
> > >>
> > >> best,
> > >> Colin
> > >>
> > >>
> > >> On Wed, Dec 20, 2023, at 03:43, Mickael Maison 

Re: Apache Kafka 3.7.0 Release

[Almog Gavra]

Hello Stan,

I wanted to give you a heads up that
https://github.com/apache/kafka/pull/15073 (
https://issues.apache.org/jira/browse/KAFKA-16046) was identified as a
blocker regression and should be merged to trunk by EOD.

Cheers,
Almog

On Tue, Jan 2, 2024 at 4:20 AM Stanislav Kozlovski
 wrote:

> Hi Apoorv,
>
> Thanks for taking ownership and looking into this! One more caveat is that
> I believe this first publish is ran with JDK 8, as the release.py runs with
> both JDK 8 and (if I recall correctly) 17 versions. This seems to fail on
> the first one - so JDK 8.
> Not sure if that is related in any way. And I'm also not sure if it should
> be kafka-clients or just clients.
>
> On Sat, Dec 30, 2023 at 10:48 AM Apoorv Mittal 
> wrote:
>
> > Hi Stan,
> > Thanks for looking into the release. I worked with `./gradlewAll
> > publishToMavenLocal` which generates the respective `kafka-clients.jar`
> > and deploys to maven local, I believed that `./gradlewAll publish` should
> > just publish the artifacts to remote repository and hence should always
> > work as jars successfully gets deployed to local maven.
> >
> > Though now I set up the remote private maven repository for myself (on
> > jfrog) and tried `./gradlewAll publish` on the 3.7 branch and
> > successfully completed the build with all artifacts uploaded to the
> remote
> > repository. What seems strange to me is the error you mentioned in the
> > previous email regarding the reference of the clients jar. I suppose the
> > reference should be to `kafka-clients.jar` rather than `clients.jar`, I
> > might be missing if something else gets triggered in the release
> pipeline.
> > Do you think I should set up the remote repository as per the
> instructions
> > in `release.py` and try running `./release.py` as that might do something
> > different, though I suspect that it should?
> >
> > [image: Screenshot 2023-12-30 at 9.33.42 AM.png]
> >
> >
> > Regards,
> > Apoorv Mittal
> >
> >
> > On Fri, Dec 29, 2023 at 2:13 AM Colin McCabe  wrote:
> >
> >> Just to update this thread, everything in KAFKA-14127 is done now. A few
> >> tasks got moved to a separate umbrella JIRA.
> >>
> >> Some folks are going to do more testing, both manual and automated, in
> >> the next week or two. I think this will give us a good indicator of
> >> stability and what we need to fix.
> >>
> >> Right now I'm leaning towards just making it GA since that's how most
> >> features work. It's kind of rare for us to do a multi-step rollout for
> new
> >> features.
> >>
> >> best,
> >> Colin
> >>
> >>
> >> On Wed, Dec 20, 2023, at 03:43, Mickael Maison wrote:
> >> > Hi,
> >> >
> >> > With the current timeline for 3.7, I tend to agree with Viktor that
> >> > JBOD support in KRaft is unlikely to receive the extensive testing
> >> > this feature needs before releasing. And that's not counting the
> >> > testing tasks left to do in
> >> > https://issues.apache.org/jira/browse/KAFKA-14127.
> >> >
> >> > I'm fine sticking to the current 3.7 timeline but I'd err on the safe
> >> > side and mark JBOD as early access to avoid major issues. Kafka is
> >> > known for its robustness and resiliency and we certainly don't want to
> >> > lose the trust we gained over years.
> >> >
> >> > Thanks,
> >> > Mickael
> >> >
> >> > On Wed, Dec 20, 2023 at 12:24 AM Ismael Juma 
> wrote:
> >> >>
> >> >> Hi Viktor,
> >> >>
> >> >> Extending the code freeze doesn't help stabilize things. If we have
> >> >> important bugs for JBOD, we should mark those as blockers and we'll
> >> wait
> >> >> until they are fixed if the fixes won't take too long (as usual).
> >> >>
> >> >> Ismael
> >> >>
> >> >> On Tue, Dec 19, 2023 at 11:58 AM Viktor Somogyi-Vass
> >> >>  wrote:
> >> >>
> >> >> > Hi all,
> >> >> >
> >> >> > I was wondering what people think about extending the code freeze
> >> date to
> >> >> > early January?
> >> >> > The reason I'm asking is that there are still a couple of testing
> >> gaps in
> >> >> > JBOD (https://issues.apache.org/jira/browse/KAFKA-14127) which I
> >> think is
> >> >> > very important to finish to ensure a high quality release (after
> all
> >> this
> >> >> > supposed to be the last 3.x) and secondly the year end holidays for
> >> many
> >> >> > people are coming fast, which means we'll likely have less people
> >> working
> >> >> > on testing and validation. In my opinion it would strengthen the
> >> release if
> >> >> > we could spend a week in January to really finish off JBOD and do a
> >> 2 week
> >> >> > stabilization.
> >> >> >
> >> >> > What do you all think?
> >> >> >
> >> >> > Best,
> >> >> > Viktor
> >> >> >
> >> >> > On Tue, Dec 12, 2023 at 2:59 PM Stanislav Kozlovski
> >> >> >  wrote:
> >> >> >
> >> >> > > Hey!
> >> >> > >
> >> >> > > Just notifying everybody on this thread that I have cut the 3.7
> >> branch
> >> >> > and
> >> >> > > sent a new email thread titled "New Release Branch 3.7" to the
> >> mailing
> >> >> > list
> >> >> > > <
> 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Hi Apoorv,

Thanks for taking ownership and looking into this! One more caveat is that
I believe this first publish is ran with JDK 8, as the release.py runs with
both JDK 8 and (if I recall correctly) 17 versions. This seems to fail on
the first one - so JDK 8.
Not sure if that is related in any way. And I'm also not sure if it should
be kafka-clients or just clients.

On Sat, Dec 30, 2023 at 10:48 AM Apoorv Mittal 
wrote:

> Hi Stan,
> Thanks for looking into the release. I worked with `./gradlewAll
> publishToMavenLocal` which generates the respective `kafka-clients.jar`
> and deploys to maven local, I believed that `./gradlewAll publish` should
> just publish the artifacts to remote repository and hence should always
> work as jars successfully gets deployed to local maven.
>
> Though now I set up the remote private maven repository for myself (on
> jfrog) and tried `./gradlewAll publish` on the 3.7 branch and
> successfully completed the build with all artifacts uploaded to the remote
> repository. What seems strange to me is the error you mentioned in the
> previous email regarding the reference of the clients jar. I suppose the
> reference should be to `kafka-clients.jar` rather than `clients.jar`, I
> might be missing if something else gets triggered in the release pipeline.
> Do you think I should set up the remote repository as per the instructions
> in `release.py` and try running `./release.py` as that might do something
> different, though I suspect that it should?
>
> [image: Screenshot 2023-12-30 at 9.33.42 AM.png]
>
>
> Regards,
> Apoorv Mittal
>
>
> On Fri, Dec 29, 2023 at 2:13 AM Colin McCabe  wrote:
>
>> Just to update this thread, everything in KAFKA-14127 is done now. A few
>> tasks got moved to a separate umbrella JIRA.
>>
>> Some folks are going to do more testing, both manual and automated, in
>> the next week or two. I think this will give us a good indicator of
>> stability and what we need to fix.
>>
>> Right now I'm leaning towards just making it GA since that's how most
>> features work. It's kind of rare for us to do a multi-step rollout for new
>> features.
>>
>> best,
>> Colin
>>
>>
>> On Wed, Dec 20, 2023, at 03:43, Mickael Maison wrote:
>> > Hi,
>> >
>> > With the current timeline for 3.7, I tend to agree with Viktor that
>> > JBOD support in KRaft is unlikely to receive the extensive testing
>> > this feature needs before releasing. And that's not counting the
>> > testing tasks left to do in
>> > https://issues.apache.org/jira/browse/KAFKA-14127.
>> >
>> > I'm fine sticking to the current 3.7 timeline but I'd err on the safe
>> > side and mark JBOD as early access to avoid major issues. Kafka is
>> > known for its robustness and resiliency and we certainly don't want to
>> > lose the trust we gained over years.
>> >
>> > Thanks,
>> > Mickael
>> >
>> > On Wed, Dec 20, 2023 at 12:24 AM Ismael Juma  wrote:
>> >>
>> >> Hi Viktor,
>> >>
>> >> Extending the code freeze doesn't help stabilize things. If we have
>> >> important bugs for JBOD, we should mark those as blockers and we'll
>> wait
>> >> until they are fixed if the fixes won't take too long (as usual).
>> >>
>> >> Ismael
>> >>
>> >> On Tue, Dec 19, 2023 at 11:58 AM Viktor Somogyi-Vass
>> >>  wrote:
>> >>
>> >> > Hi all,
>> >> >
>> >> > I was wondering what people think about extending the code freeze
>> date to
>> >> > early January?
>> >> > The reason I'm asking is that there are still a couple of testing
>> gaps in
>> >> > JBOD (https://issues.apache.org/jira/browse/KAFKA-14127) which I
>> think is
>> >> > very important to finish to ensure a high quality release (after all
>> this
>> >> > supposed to be the last 3.x) and secondly the year end holidays for
>> many
>> >> > people are coming fast, which means we'll likely have less people
>> working
>> >> > on testing and validation. In my opinion it would strengthen the
>> release if
>> >> > we could spend a week in January to really finish off JBOD and do a
>> 2 week
>> >> > stabilization.
>> >> >
>> >> > What do you all think?
>> >> >
>> >> > Best,
>> >> > Viktor
>> >> >
>> >> > On Tue, Dec 12, 2023 at 2:59 PM Stanislav Kozlovski
>> >> >  wrote:
>> >> >
>> >> > > Hey!
>> >> > >
>> >> > > Just notifying everybody on this thread that I have cut the 3.7
>> branch
>> >> > and
>> >> > > sent a new email thread titled "New Release Branch 3.7" to the
>> mailing
>> >> > list
>> >> > > > >.
>> >> > >
>> >> > > Best,
>> >> > > Stanislav
>> >> > >
>> >> > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
>> >> > > stanis...@confluent.io>
>> >> > > wrote:
>> >> > >
>> >> > > > Hello again,
>> >> > > >
>> >> > > > Time is flying by! It is feature freeze day!
>> >> > > >
>> >> > > > By today, we expect to have major features merged and to begin
>> working
>> >> > on
>> >> > > > their stabilisation. Minor features should have PRs.
>> >> > > >
>> >> > > > I am planning to cut the release branch soon - on 

Re: Apache Kafka 3.7.0 Release

[Colin McCabe]

Just to update this thread, everything in KAFKA-14127 is done now. A few tasks 
got moved to a separate umbrella JIRA.

Some folks are going to do more testing, both manual and automated, in the next 
week or two. I think this will give us a good indicator of stability and what 
we need to fix.

Right now I'm leaning towards just making it GA since that's how most features 
work. It's kind of rare for us to do a multi-step rollout for new features.

best,
Colin


On Wed, Dec 20, 2023, at 03:43, Mickael Maison wrote:
> Hi,
>
> With the current timeline for 3.7, I tend to agree with Viktor that
> JBOD support in KRaft is unlikely to receive the extensive testing
> this feature needs before releasing. And that's not counting the
> testing tasks left to do in
> https://issues.apache.org/jira/browse/KAFKA-14127.
>
> I'm fine sticking to the current 3.7 timeline but I'd err on the safe
> side and mark JBOD as early access to avoid major issues. Kafka is
> known for its robustness and resiliency and we certainly don't want to
> lose the trust we gained over years.
>
> Thanks,
> Mickael
>
> On Wed, Dec 20, 2023 at 12:24 AM Ismael Juma  wrote:
>>
>> Hi Viktor,
>>
>> Extending the code freeze doesn't help stabilize things. If we have
>> important bugs for JBOD, we should mark those as blockers and we'll wait
>> until they are fixed if the fixes won't take too long (as usual).
>>
>> Ismael
>>
>> On Tue, Dec 19, 2023 at 11:58 AM Viktor Somogyi-Vass
>>  wrote:
>>
>> > Hi all,
>> >
>> > I was wondering what people think about extending the code freeze date to
>> > early January?
>> > The reason I'm asking is that there are still a couple of testing gaps in
>> > JBOD (https://issues.apache.org/jira/browse/KAFKA-14127) which I think is
>> > very important to finish to ensure a high quality release (after all this
>> > supposed to be the last 3.x) and secondly the year end holidays for many
>> > people are coming fast, which means we'll likely have less people working
>> > on testing and validation. In my opinion it would strengthen the release if
>> > we could spend a week in January to really finish off JBOD and do a 2 week
>> > stabilization.
>> >
>> > What do you all think?
>> >
>> > Best,
>> > Viktor
>> >
>> > On Tue, Dec 12, 2023 at 2:59 PM Stanislav Kozlovski
>> >  wrote:
>> >
>> > > Hey!
>> > >
>> > > Just notifying everybody on this thread that I have cut the 3.7 branch
>> > and
>> > > sent a new email thread titled "New Release Branch 3.7" to the mailing
>> > list
>> > > .
>> > >
>> > > Best,
>> > > Stanislav
>> > >
>> > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
>> > > stanis...@confluent.io>
>> > > wrote:
>> > >
>> > > > Hello again,
>> > > >
>> > > > Time is flying by! It is feature freeze day!
>> > > >
>> > > > By today, we expect to have major features merged and to begin working
>> > on
>> > > > their stabilisation. Minor features should have PRs.
>> > > >
>> > > > I am planning to cut the release branch soon - on Monday EU daytime.
>> > When
>> > > > I do that, I will create a new e-mail thread titled "New release branch
>> > > > 3.7.0" to notify you, so be on the lookout for that. I will also notify
>> > > > this thread.
>> > > >
>> > > > Thank you for your contributions. Let's get this release shipped!
>> > > >
>> > > > Best,
>> > > > Stanislav
>> > > >
>> > > >
>> > > > On Fri, Nov 24, 2023 at 6:11 PM Stanislav Kozlovski <
>> > > > stanis...@confluent.io> wrote:
>> > > >
>> > > >> Hey all,
>> > > >>
>> > > >> The KIP Freeze has passed. I count 31 KIPs that will be going into the
>> > > >> 3.7 Release. Thank you all for your hard work!
>> > > >>
>> > > >> They are the following (some of these were accepted in previous
>> > releases
>> > > >> and have minor parts going out, some targeting a Preview release and
>> > the
>> > > >> rest being fully released as regular.):
>> > > >>  - KIP-1000: List Client Metrics Configuration Resources
>> > > >>  - KIP-1001: Add CurrentControllerId Metric
>> > > >>  - KIP-405: Kafka Tiered Storage
>> > > >>  - KIP-580: Exponential Backoff for Kafka Clients
>> > > >>  - KIP-714: Client metrics and observability
>> > > >>  - KIP-770: Replace "buffered.records.per.partition" &
>> > > >> "cache.max.bytes.buffering" with
>> > > >> "{statestore.cache}/{input.buffer}.max.bytes"
>> > > >>  - KIP-848: The Next Generation of the Consumer Rebalance Protocol
>> > > >>  - KIP-858: Handle JBOD broker disk failure in KRaft
>> > > >>  - KIP-890: Transactions Server-Side Defense
>> > > >>  - KIP-892: Transactional StateStores
>> > > >>  - KIP-896: Remove old client protocol API versions in Kafka 4.0 -
>> > > >> metrics/request log changes to identify deprecated apis
>> > > >>  - KIP-925: Rack aware task assignment in Kafka Streams
>> > > >>  - KIP-938: Add more metrics for measuring KRaft performance
>> > > >>  - KIP-951 - Leader discovery optimizations for the client
>> > > >>  - KIP-954: expand default DSL 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Hey all,

Code Freeze has been over for some time, and I have been trying to build an
RC. I have hit a problem trying to build it, hence am reaching out for some
help.

The error I'm getting while running release.py is:

./gradlewAll publish
...
> * What went wrong:
> Execution failed for task 
> ':clients:publishMavenJavaPublicationToMavenRepository'.
> > Failed to publish publication 'mavenJava' to repository 'maven'
>> Invalid publication 'mavenJava': artifact file does not exist: 
> '/Users/stanislav/Documents/code/kafka-release/.release_work_dir/kafka/clients/build/libs/clients-3.7.0-all.jar'

I think it might be related to https://github.com/apache/kafka/pull/14618
I inspected the gradle file thoroughly and even tried debugging locally,
but to no success. The release script itself also creates a clean copy of
the repo, so changing stuff locally doesn't really apply to it (and
probably isn't a good idea)

I spoke to Xavier Leaute a bit and he suggested that we probably need to
have an "afterEvaluate" block which assigns the project's name to the
archivesBaseName, saying that we need that because the shadow plugin
doesn't honor the "kafka-clients" archivesBaseName override.
I could raise a PR that does this if others agree it's the right solution.
I won't lie - this is above my head - so I'm not certain about it. (and a
quick search doesn't show much)

PS: I realize I'm building an RC to run tests against, but it occurred to
me that I haven't inspected any of the integration tests or system tests
for actual failures. I ack integration tests would usually block the CI
build and therefore be caught - but don't we look at the system tests prior
to creating an RC? Or is this something that's done with the RC?

Best,
Stan

On Wed, Dec 20, 2023 at 12:44 PM Mickael Maison 
wrote:

> Hi,
>
> With the current timeline for 3.7, I tend to agree with Viktor that
> JBOD support in KRaft is unlikely to receive the extensive testing
> this feature needs before releasing. And that's not counting the
> testing tasks left to do in
> https://issues.apache.org/jira/browse/KAFKA-14127.
>
> I'm fine sticking to the current 3.7 timeline but I'd err on the safe
> side and mark JBOD as early access to avoid major issues. Kafka is
> known for its robustness and resiliency and we certainly don't want to
> lose the trust we gained over years.
>
> Thanks,
> Mickael
>
> On Wed, Dec 20, 2023 at 12:24 AM Ismael Juma  wrote:
> >
> > Hi Viktor,
> >
> > Extending the code freeze doesn't help stabilize things. If we have
> > important bugs for JBOD, we should mark those as blockers and we'll wait
> > until they are fixed if the fixes won't take too long (as usual).
> >
> > Ismael
> >
> > On Tue, Dec 19, 2023 at 11:58 AM Viktor Somogyi-Vass
> >  wrote:
> >
> > > Hi all,
> > >
> > > I was wondering what people think about extending the code freeze date
> to
> > > early January?
> > > The reason I'm asking is that there are still a couple of testing gaps
> in
> > > JBOD (https://issues.apache.org/jira/browse/KAFKA-14127) which I
> think is
> > > very important to finish to ensure a high quality release (after all
> this
> > > supposed to be the last 3.x) and secondly the year end holidays for
> many
> > > people are coming fast, which means we'll likely have less people
> working
> > > on testing and validation. In my opinion it would strengthen the
> release if
> > > we could spend a week in January to really finish off JBOD and do a 2
> week
> > > stabilization.
> > >
> > > What do you all think?
> > >
> > > Best,
> > > Viktor
> > >
> > > On Tue, Dec 12, 2023 at 2:59 PM Stanislav Kozlovski
> > >  wrote:
> > >
> > > > Hey!
> > > >
> > > > Just notifying everybody on this thread that I have cut the 3.7
> branch
> > > and
> > > > sent a new email thread titled "New Release Branch 3.7" to the
> mailing
> > > list
> > > > .
> > > >
> > > > Best,
> > > > Stanislav
> > > >
> > > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> > > > stanis...@confluent.io>
> > > > wrote:
> > > >
> > > > > Hello again,
> > > > >
> > > > > Time is flying by! It is feature freeze day!
> > > > >
> > > > > By today, we expect to have major features merged and to begin
> working
> > > on
> > > > > their stabilisation. Minor features should have PRs.
> > > > >
> > > > > I am planning to cut the release branch soon - on Monday EU
> daytime.
> > > When
> > > > > I do that, I will create a new e-mail thread titled "New release
> branch
> > > > > 3.7.0" to notify you, so be on the lookout for that. I will also
> notify
> > > > > this thread.
> > > > >
> > > > > Thank you for your contributions. Let's get this release shipped!
> > > > >
> > > > > Best,
> > > > > Stanislav
> > > > >
> > > > >
> > > > > On Fri, Nov 24, 2023 at 6:11 PM Stanislav Kozlovski <
> > > > > stanis...@confluent.io> wrote:
> > > > >
> > > > >> Hey all,
> > > > >>
> > > > >> The KIP Freeze has passed. I count 31 KIPs that 

Re: Apache Kafka 3.7.0 Release

[Mickael Maison]

Hi,

With the current timeline for 3.7, I tend to agree with Viktor that
JBOD support in KRaft is unlikely to receive the extensive testing
this feature needs before releasing. And that's not counting the
testing tasks left to do in
https://issues.apache.org/jira/browse/KAFKA-14127.

I'm fine sticking to the current 3.7 timeline but I'd err on the safe
side and mark JBOD as early access to avoid major issues. Kafka is
known for its robustness and resiliency and we certainly don't want to
lose the trust we gained over years.

Thanks,
Mickael

On Wed, Dec 20, 2023 at 12:24 AM Ismael Juma  wrote:
>
> Hi Viktor,
>
> Extending the code freeze doesn't help stabilize things. If we have
> important bugs for JBOD, we should mark those as blockers and we'll wait
> until they are fixed if the fixes won't take too long (as usual).
>
> Ismael
>
> On Tue, Dec 19, 2023 at 11:58 AM Viktor Somogyi-Vass
>  wrote:
>
> > Hi all,
> >
> > I was wondering what people think about extending the code freeze date to
> > early January?
> > The reason I'm asking is that there are still a couple of testing gaps in
> > JBOD (https://issues.apache.org/jira/browse/KAFKA-14127) which I think is
> > very important to finish to ensure a high quality release (after all this
> > supposed to be the last 3.x) and secondly the year end holidays for many
> > people are coming fast, which means we'll likely have less people working
> > on testing and validation. In my opinion it would strengthen the release if
> > we could spend a week in January to really finish off JBOD and do a 2 week
> > stabilization.
> >
> > What do you all think?
> >
> > Best,
> > Viktor
> >
> > On Tue, Dec 12, 2023 at 2:59 PM Stanislav Kozlovski
> >  wrote:
> >
> > > Hey!
> > >
> > > Just notifying everybody on this thread that I have cut the 3.7 branch
> > and
> > > sent a new email thread titled "New Release Branch 3.7" to the mailing
> > list
> > > .
> > >
> > > Best,
> > > Stanislav
> > >
> > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> > > stanis...@confluent.io>
> > > wrote:
> > >
> > > > Hello again,
> > > >
> > > > Time is flying by! It is feature freeze day!
> > > >
> > > > By today, we expect to have major features merged and to begin working
> > on
> > > > their stabilisation. Minor features should have PRs.
> > > >
> > > > I am planning to cut the release branch soon - on Monday EU daytime.
> > When
> > > > I do that, I will create a new e-mail thread titled "New release branch
> > > > 3.7.0" to notify you, so be on the lookout for that. I will also notify
> > > > this thread.
> > > >
> > > > Thank you for your contributions. Let's get this release shipped!
> > > >
> > > > Best,
> > > > Stanislav
> > > >
> > > >
> > > > On Fri, Nov 24, 2023 at 6:11 PM Stanislav Kozlovski <
> > > > stanis...@confluent.io> wrote:
> > > >
> > > >> Hey all,
> > > >>
> > > >> The KIP Freeze has passed. I count 31 KIPs that will be going into the
> > > >> 3.7 Release. Thank you all for your hard work!
> > > >>
> > > >> They are the following (some of these were accepted in previous
> > releases
> > > >> and have minor parts going out, some targeting a Preview release and
> > the
> > > >> rest being fully released as regular.):
> > > >>  - KIP-1000: List Client Metrics Configuration Resources
> > > >>  - KIP-1001: Add CurrentControllerId Metric
> > > >>  - KIP-405: Kafka Tiered Storage
> > > >>  - KIP-580: Exponential Backoff for Kafka Clients
> > > >>  - KIP-714: Client metrics and observability
> > > >>  - KIP-770: Replace "buffered.records.per.partition" &
> > > >> "cache.max.bytes.buffering" with
> > > >> "{statestore.cache}/{input.buffer}.max.bytes"
> > > >>  - KIP-848: The Next Generation of the Consumer Rebalance Protocol
> > > >>  - KIP-858: Handle JBOD broker disk failure in KRaft
> > > >>  - KIP-890: Transactions Server-Side Defense
> > > >>  - KIP-892: Transactional StateStores
> > > >>  - KIP-896: Remove old client protocol API versions in Kafka 4.0 -
> > > >> metrics/request log changes to identify deprecated apis
> > > >>  - KIP-925: Rack aware task assignment in Kafka Streams
> > > >>  - KIP-938: Add more metrics for measuring KRaft performance
> > > >>  - KIP-951 - Leader discovery optimizations for the client
> > > >>  - KIP-954: expand default DSL store configuration to custom types
> > > >>  - KIP-959: Add BooleanConverter to Kafka Connect
> > > >>  - KIP-960: Single-key single-timestamp IQv2 for state stores
> > > >>  - KIP-963: Additional metrics in Tiered Storage
> > > >>  - KIP-968: Support single-key_multi-timestamp Interactive Queries
> > > (IQv2)
> > > >> for Versioned State Stores
> > > >>  - KIP-970: Deprecate and remove Connect's redundant task
> > configurations
> > > >> endpoint
> > > >>  - KIP-975: Docker Image for Apache Kafka
> > > >>  - KIP-976: Cluster-wide dynamic log adjustment for Kafka Connect
> > > >>  - KIP-978: Allow dynamic reloading of certificates with different 

Re: Apache Kafka 3.7.0 Release

[Ismael Juma]

Hi Viktor,

Extending the code freeze doesn't help stabilize things. If we have
important bugs for JBOD, we should mark those as blockers and we'll wait
until they are fixed if the fixes won't take too long (as usual).

Ismael

On Tue, Dec 19, 2023 at 11:58 AM Viktor Somogyi-Vass
 wrote:

> Hi all,
>
> I was wondering what people think about extending the code freeze date to
> early January?
> The reason I'm asking is that there are still a couple of testing gaps in
> JBOD (https://issues.apache.org/jira/browse/KAFKA-14127) which I think is
> very important to finish to ensure a high quality release (after all this
> supposed to be the last 3.x) and secondly the year end holidays for many
> people are coming fast, which means we'll likely have less people working
> on testing and validation. In my opinion it would strengthen the release if
> we could spend a week in January to really finish off JBOD and do a 2 week
> stabilization.
>
> What do you all think?
>
> Best,
> Viktor
>
> On Tue, Dec 12, 2023 at 2:59 PM Stanislav Kozlovski
>  wrote:
>
> > Hey!
> >
> > Just notifying everybody on this thread that I have cut the 3.7 branch
> and
> > sent a new email thread titled "New Release Branch 3.7" to the mailing
> list
> > .
> >
> > Best,
> > Stanislav
> >
> > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> > stanis...@confluent.io>
> > wrote:
> >
> > > Hello again,
> > >
> > > Time is flying by! It is feature freeze day!
> > >
> > > By today, we expect to have major features merged and to begin working
> on
> > > their stabilisation. Minor features should have PRs.
> > >
> > > I am planning to cut the release branch soon - on Monday EU daytime.
> When
> > > I do that, I will create a new e-mail thread titled "New release branch
> > > 3.7.0" to notify you, so be on the lookout for that. I will also notify
> > > this thread.
> > >
> > > Thank you for your contributions. Let's get this release shipped!
> > >
> > > Best,
> > > Stanislav
> > >
> > >
> > > On Fri, Nov 24, 2023 at 6:11 PM Stanislav Kozlovski <
> > > stanis...@confluent.io> wrote:
> > >
> > >> Hey all,
> > >>
> > >> The KIP Freeze has passed. I count 31 KIPs that will be going into the
> > >> 3.7 Release. Thank you all for your hard work!
> > >>
> > >> They are the following (some of these were accepted in previous
> releases
> > >> and have minor parts going out, some targeting a Preview release and
> the
> > >> rest being fully released as regular.):
> > >>  - KIP-1000: List Client Metrics Configuration Resources
> > >>  - KIP-1001: Add CurrentControllerId Metric
> > >>  - KIP-405: Kafka Tiered Storage
> > >>  - KIP-580: Exponential Backoff for Kafka Clients
> > >>  - KIP-714: Client metrics and observability
> > >>  - KIP-770: Replace "buffered.records.per.partition" &
> > >> "cache.max.bytes.buffering" with
> > >> "{statestore.cache}/{input.buffer}.max.bytes"
> > >>  - KIP-848: The Next Generation of the Consumer Rebalance Protocol
> > >>  - KIP-858: Handle JBOD broker disk failure in KRaft
> > >>  - KIP-890: Transactions Server-Side Defense
> > >>  - KIP-892: Transactional StateStores
> > >>  - KIP-896: Remove old client protocol API versions in Kafka 4.0 -
> > >> metrics/request log changes to identify deprecated apis
> > >>  - KIP-925: Rack aware task assignment in Kafka Streams
> > >>  - KIP-938: Add more metrics for measuring KRaft performance
> > >>  - KIP-951 - Leader discovery optimizations for the client
> > >>  - KIP-954: expand default DSL store configuration to custom types
> > >>  - KIP-959: Add BooleanConverter to Kafka Connect
> > >>  - KIP-960: Single-key single-timestamp IQv2 for state stores
> > >>  - KIP-963: Additional metrics in Tiered Storage
> > >>  - KIP-968: Support single-key_multi-timestamp Interactive Queries
> > (IQv2)
> > >> for Versioned State Stores
> > >>  - KIP-970: Deprecate and remove Connect's redundant task
> configurations
> > >> endpoint
> > >>  - KIP-975: Docker Image for Apache Kafka
> > >>  - KIP-976: Cluster-wide dynamic log adjustment for Kafka Connect
> > >>  - KIP-978: Allow dynamic reloading of certificates with different DN
> /
> > >> SANs
> > >>  - KIP-979: Allow independently stop KRaft processes
> > >>  - KIP-980: Allow creating connectors in a stopped state
> > >>  - KIP-985: Add reverseRange and reverseAll query over kv-store in
> IQv2
> > >>  - KIP-988: Streams Standby Update Listener
> > >>  - KIP-992: Proposal to introduce IQv2 Query Types:
> TimestampedKeyQuery
> > >> and TimestampedRangeQuery
> > >>  - KIP-998: Give ProducerConfig(props, doLog) constructor protected
> > access
> > >>
> > >> Notable KIPs that didn't make the Freeze were KIP-977 - it only got
> 2/3
> > >> votes.
> > >>
> > >> For the full list and latest source of truth, refer to the Release
> Plan
> > >> 3.7.0 Document
> > >>  >.
> > >>
> > >> Thanks for your contributions once 

Re: Apache Kafka 3.7.0 Release

[Viktor Somogyi-Vass]

Hi all,

I was wondering what people think about extending the code freeze date to
early January?
The reason I'm asking is that there are still a couple of testing gaps in
JBOD (https://issues.apache.org/jira/browse/KAFKA-14127) which I think is
very important to finish to ensure a high quality release (after all this
supposed to be the last 3.x) and secondly the year end holidays for many
people are coming fast, which means we'll likely have less people working
on testing and validation. In my opinion it would strengthen the release if
we could spend a week in January to really finish off JBOD and do a 2 week
stabilization.

What do you all think?

Best,
Viktor

On Tue, Dec 12, 2023 at 2:59 PM Stanislav Kozlovski
 wrote:

> Hey!
>
> Just notifying everybody on this thread that I have cut the 3.7 branch and
> sent a new email thread titled "New Release Branch 3.7" to the mailing list
> .
>
> Best,
> Stanislav
>
> On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> stanis...@confluent.io>
> wrote:
>
> > Hello again,
> >
> > Time is flying by! It is feature freeze day!
> >
> > By today, we expect to have major features merged and to begin working on
> > their stabilisation. Minor features should have PRs.
> >
> > I am planning to cut the release branch soon - on Monday EU daytime. When
> > I do that, I will create a new e-mail thread titled "New release branch
> > 3.7.0" to notify you, so be on the lookout for that. I will also notify
> > this thread.
> >
> > Thank you for your contributions. Let's get this release shipped!
> >
> > Best,
> > Stanislav
> >
> >
> > On Fri, Nov 24, 2023 at 6:11 PM Stanislav Kozlovski <
> > stanis...@confluent.io> wrote:
> >
> >> Hey all,
> >>
> >> The KIP Freeze has passed. I count 31 KIPs that will be going into the
> >> 3.7 Release. Thank you all for your hard work!
> >>
> >> They are the following (some of these were accepted in previous releases
> >> and have minor parts going out, some targeting a Preview release and the
> >> rest being fully released as regular.):
> >>  - KIP-1000: List Client Metrics Configuration Resources
> >>  - KIP-1001: Add CurrentControllerId Metric
> >>  - KIP-405: Kafka Tiered Storage
> >>  - KIP-580: Exponential Backoff for Kafka Clients
> >>  - KIP-714: Client metrics and observability
> >>  - KIP-770: Replace "buffered.records.per.partition" &
> >> "cache.max.bytes.buffering" with
> >> "{statestore.cache}/{input.buffer}.max.bytes"
> >>  - KIP-848: The Next Generation of the Consumer Rebalance Protocol
> >>  - KIP-858: Handle JBOD broker disk failure in KRaft
> >>  - KIP-890: Transactions Server-Side Defense
> >>  - KIP-892: Transactional StateStores
> >>  - KIP-896: Remove old client protocol API versions in Kafka 4.0 -
> >> metrics/request log changes to identify deprecated apis
> >>  - KIP-925: Rack aware task assignment in Kafka Streams
> >>  - KIP-938: Add more metrics for measuring KRaft performance
> >>  - KIP-951 - Leader discovery optimizations for the client
> >>  - KIP-954: expand default DSL store configuration to custom types
> >>  - KIP-959: Add BooleanConverter to Kafka Connect
> >>  - KIP-960: Single-key single-timestamp IQv2 for state stores
> >>  - KIP-963: Additional metrics in Tiered Storage
> >>  - KIP-968: Support single-key_multi-timestamp Interactive Queries
> (IQv2)
> >> for Versioned State Stores
> >>  - KIP-970: Deprecate and remove Connect's redundant task configurations
> >> endpoint
> >>  - KIP-975: Docker Image for Apache Kafka
> >>  - KIP-976: Cluster-wide dynamic log adjustment for Kafka Connect
> >>  - KIP-978: Allow dynamic reloading of certificates with different DN /
> >> SANs
> >>  - KIP-979: Allow independently stop KRaft processes
> >>  - KIP-980: Allow creating connectors in a stopped state
> >>  - KIP-985: Add reverseRange and reverseAll query over kv-store in IQv2
> >>  - KIP-988: Streams Standby Update Listener
> >>  - KIP-992: Proposal to introduce IQv2 Query Types: TimestampedKeyQuery
> >> and TimestampedRangeQuery
> >>  - KIP-998: Give ProducerConfig(props, doLog) constructor protected
> access
> >>
> >> Notable KIPs that didn't make the Freeze were KIP-977 - it only got 2/3
> >> votes.
> >>
> >> For the full list and latest source of truth, refer to the Release Plan
> >> 3.7.0 Document
> >> .
> >>
> >> Thanks for your contributions once again!
> >> Best,
> >> Stan
> >>
> >>
> >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford 
> >> wrote:
> >>
> >>> Hi Stan,
> >>>
> >>> I'd like to propose including KIP-892 in the 3.7 release. The KIP has
> >>> been
> >>> accepted and I'm just working on rebasing the implementation against
> >>> trunk
> >>> before I open a PR.
> >>>
> >>> Regards,
> >>> Nick
> >>>
> >>> On Tue, 21 Nov 2023 at 11:27, Mayank Shekhar Narula <
> >>> mayanks.nar...@gmail.com> wrote:
> >>>
> >>> > Hi Stan
> >>> >
> >>> > Can you include KIP-951 to the 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Hey!

Just notifying everybody on this thread that I have cut the 3.7 branch and
sent a new email thread titled "New Release Branch 3.7" to the mailing list
.

Best,
Stanislav

On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski 
wrote:

> Hello again,
>
> Time is flying by! It is feature freeze day!
>
> By today, we expect to have major features merged and to begin working on
> their stabilisation. Minor features should have PRs.
>
> I am planning to cut the release branch soon - on Monday EU daytime. When
> I do that, I will create a new e-mail thread titled "New release branch
> 3.7.0" to notify you, so be on the lookout for that. I will also notify
> this thread.
>
> Thank you for your contributions. Let's get this release shipped!
>
> Best,
> Stanislav
>
>
> On Fri, Nov 24, 2023 at 6:11 PM Stanislav Kozlovski <
> stanis...@confluent.io> wrote:
>
>> Hey all,
>>
>> The KIP Freeze has passed. I count 31 KIPs that will be going into the
>> 3.7 Release. Thank you all for your hard work!
>>
>> They are the following (some of these were accepted in previous releases
>> and have minor parts going out, some targeting a Preview release and the
>> rest being fully released as regular.):
>>  - KIP-1000: List Client Metrics Configuration Resources
>>  - KIP-1001: Add CurrentControllerId Metric
>>  - KIP-405: Kafka Tiered Storage
>>  - KIP-580: Exponential Backoff for Kafka Clients
>>  - KIP-714: Client metrics and observability
>>  - KIP-770: Replace "buffered.records.per.partition" &
>> "cache.max.bytes.buffering" with
>> "{statestore.cache}/{input.buffer}.max.bytes"
>>  - KIP-848: The Next Generation of the Consumer Rebalance Protocol
>>  - KIP-858: Handle JBOD broker disk failure in KRaft
>>  - KIP-890: Transactions Server-Side Defense
>>  - KIP-892: Transactional StateStores
>>  - KIP-896: Remove old client protocol API versions in Kafka 4.0 -
>> metrics/request log changes to identify deprecated apis
>>  - KIP-925: Rack aware task assignment in Kafka Streams
>>  - KIP-938: Add more metrics for measuring KRaft performance
>>  - KIP-951 - Leader discovery optimizations for the client
>>  - KIP-954: expand default DSL store configuration to custom types
>>  - KIP-959: Add BooleanConverter to Kafka Connect
>>  - KIP-960: Single-key single-timestamp IQv2 for state stores
>>  - KIP-963: Additional metrics in Tiered Storage
>>  - KIP-968: Support single-key_multi-timestamp Interactive Queries (IQv2)
>> for Versioned State Stores
>>  - KIP-970: Deprecate and remove Connect's redundant task configurations
>> endpoint
>>  - KIP-975: Docker Image for Apache Kafka
>>  - KIP-976: Cluster-wide dynamic log adjustment for Kafka Connect
>>  - KIP-978: Allow dynamic reloading of certificates with different DN /
>> SANs
>>  - KIP-979: Allow independently stop KRaft processes
>>  - KIP-980: Allow creating connectors in a stopped state
>>  - KIP-985: Add reverseRange and reverseAll query over kv-store in IQv2
>>  - KIP-988: Streams Standby Update Listener
>>  - KIP-992: Proposal to introduce IQv2 Query Types: TimestampedKeyQuery
>> and TimestampedRangeQuery
>>  - KIP-998: Give ProducerConfig(props, doLog) constructor protected access
>>
>> Notable KIPs that didn't make the Freeze were KIP-977 - it only got 2/3
>> votes.
>>
>> For the full list and latest source of truth, refer to the Release Plan
>> 3.7.0 Document
>> .
>>
>> Thanks for your contributions once again!
>> Best,
>> Stan
>>
>>
>> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford 
>> wrote:
>>
>>> Hi Stan,
>>>
>>> I'd like to propose including KIP-892 in the 3.7 release. The KIP has
>>> been
>>> accepted and I'm just working on rebasing the implementation against
>>> trunk
>>> before I open a PR.
>>>
>>> Regards,
>>> Nick
>>>
>>> On Tue, 21 Nov 2023 at 11:27, Mayank Shekhar Narula <
>>> mayanks.nar...@gmail.com> wrote:
>>>
>>> > Hi Stan
>>> >
>>> > Can you include KIP-951 to the 3.7 release plan? All PRs are merged in
>>> the
>>> > trunk.
>>> >
>>> > On Wed, Nov 15, 2023 at 4:05 PM Stanislav Kozlovski
>>> >  wrote:
>>> >
>>> > > Friendly reminder to everybody that the KIP Freeze is *exactly 7 days
>>> > away*
>>> > > - November 22.
>>> > >
>>> > > A KIP must be accepted by this date in order to be considered for
>>> this
>>> > > release. Note, any KIP that may not be implemented in time, or
>>> otherwise
>>> > > risks heavily destabilizing the release, should be deferred.
>>> > >
>>> > > Best,
>>> > > Stan
>>> > >
>>> > > On Fri, Nov 3, 2023 at 6:03 AM Sophie Blee-Goldman <
>>> > sop...@responsive.dev>
>>> > > wrote:
>>> > >
>>> > > > Looks great, thank you! +1
>>> > > >
>>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
>>> > >> > > >
>>> > > > wrote:
>>> > > >
>>> > > > > +1 from me as well. Thanks, Stan!
>>> > > > >
>>> > > > > David
>>> > > > >
>>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma 
>>> > wrote:
>>> > > > >
>>> > > 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Hello again,

Time is flying by! It is feature freeze day!

By today, we expect to have major features merged and to begin working on
their stabilisation. Minor features should have PRs.

I am planning to cut the release branch soon - on Monday EU daytime. When I
do that, I will create a new e-mail thread titled "New release branch
3.7.0" to notify you, so be on the lookout for that. I will also notify
this thread.

Thank you for your contributions. Let's get this release shipped!

Best,
Stanislav


On Fri, Nov 24, 2023 at 6:11 PM Stanislav Kozlovski 
wrote:

> Hey all,
>
> The KIP Freeze has passed. I count 31 KIPs that will be going into the 3.7
> Release. Thank you all for your hard work!
>
> They are the following (some of these were accepted in previous releases
> and have minor parts going out, some targeting a Preview release and the
> rest being fully released as regular.):
>  - KIP-1000: List Client Metrics Configuration Resources
>  - KIP-1001: Add CurrentControllerId Metric
>  - KIP-405: Kafka Tiered Storage
>  - KIP-580: Exponential Backoff for Kafka Clients
>  - KIP-714: Client metrics and observability
>  - KIP-770: Replace "buffered.records.per.partition" &
> "cache.max.bytes.buffering" with
> "{statestore.cache}/{input.buffer}.max.bytes"
>  - KIP-848: The Next Generation of the Consumer Rebalance Protocol
>  - KIP-858: Handle JBOD broker disk failure in KRaft
>  - KIP-890: Transactions Server-Side Defense
>  - KIP-892: Transactional StateStores
>  - KIP-896: Remove old client protocol API versions in Kafka 4.0 -
> metrics/request log changes to identify deprecated apis
>  - KIP-925: Rack aware task assignment in Kafka Streams
>  - KIP-938: Add more metrics for measuring KRaft performance
>  - KIP-951 - Leader discovery optimizations for the client
>  - KIP-954: expand default DSL store configuration to custom types
>  - KIP-959: Add BooleanConverter to Kafka Connect
>  - KIP-960: Single-key single-timestamp IQv2 for state stores
>  - KIP-963: Additional metrics in Tiered Storage
>  - KIP-968: Support single-key_multi-timestamp Interactive Queries (IQv2)
> for Versioned State Stores
>  - KIP-970: Deprecate and remove Connect's redundant task configurations
> endpoint
>  - KIP-975: Docker Image for Apache Kafka
>  - KIP-976: Cluster-wide dynamic log adjustment for Kafka Connect
>  - KIP-978: Allow dynamic reloading of certificates with different DN /
> SANs
>  - KIP-979: Allow independently stop KRaft processes
>  - KIP-980: Allow creating connectors in a stopped state
>  - KIP-985: Add reverseRange and reverseAll query over kv-store in IQv2
>  - KIP-988: Streams Standby Update Listener
>  - KIP-992: Proposal to introduce IQv2 Query Types: TimestampedKeyQuery
> and TimestampedRangeQuery
>  - KIP-998: Give ProducerConfig(props, doLog) constructor protected access
>
> Notable KIPs that didn't make the Freeze were KIP-977 - it only got 2/3
> votes.
>
> For the full list and latest source of truth, refer to the Release Plan
> 3.7.0 Document
> .
>
> Thanks for your contributions once again!
> Best,
> Stan
>
>
> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford 
> wrote:
>
>> Hi Stan,
>>
>> I'd like to propose including KIP-892 in the 3.7 release. The KIP has been
>> accepted and I'm just working on rebasing the implementation against trunk
>> before I open a PR.
>>
>> Regards,
>> Nick
>>
>> On Tue, 21 Nov 2023 at 11:27, Mayank Shekhar Narula <
>> mayanks.nar...@gmail.com> wrote:
>>
>> > Hi Stan
>> >
>> > Can you include KIP-951 to the 3.7 release plan? All PRs are merged in
>> the
>> > trunk.
>> >
>> > On Wed, Nov 15, 2023 at 4:05 PM Stanislav Kozlovski
>> >  wrote:
>> >
>> > > Friendly reminder to everybody that the KIP Freeze is *exactly 7 days
>> > away*
>> > > - November 22.
>> > >
>> > > A KIP must be accepted by this date in order to be considered for this
>> > > release. Note, any KIP that may not be implemented in time, or
>> otherwise
>> > > risks heavily destabilizing the release, should be deferred.
>> > >
>> > > Best,
>> > > Stan
>> > >
>> > > On Fri, Nov 3, 2023 at 6:03 AM Sophie Blee-Goldman <
>> > sop...@responsive.dev>
>> > > wrote:
>> > >
>> > > > Looks great, thank you! +1
>> > > >
>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
>> > > > > >
>> > > > wrote:
>> > > >
>> > > > > +1 from me as well. Thanks, Stan!
>> > > > >
>> > > > > David
>> > > > >
>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma 
>> > wrote:
>> > > > >
>> > > > > > Thanks Stanislav, +1
>> > > > > >
>> > > > > > Ismael
>> > > > > >
>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
>> > > > > >  wrote:
>> > > > > >
>> > > > > > > Hi all,
>> > > > > > >
>> > > > > > > Given the discussion here and the lack of any pushback, I have
>> > > > changed
>> > > > > > the
>> > > > > > > dates of the release:
>> > > > > > > - KIP Freeze - *November 22 *(moved 4 days later)
>> > > > > > > - Feature Freeze - *December 6 *(moved 2 days 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Hey all,

The KIP Freeze has passed. I count 31 KIPs that will be going into the 3.7
Release. Thank you all for your hard work!

They are the following (some of these were accepted in previous releases
and have minor parts going out, some targeting a Preview release and the
rest being fully released as regular.):
 - KIP-1000: List Client Metrics Configuration Resources
 - KIP-1001: Add CurrentControllerId Metric
 - KIP-405: Kafka Tiered Storage
 - KIP-580: Exponential Backoff for Kafka Clients
 - KIP-714: Client metrics and observability
 - KIP-770: Replace "buffered.records.per.partition" &
"cache.max.bytes.buffering" with
"{statestore.cache}/{input.buffer}.max.bytes"
 - KIP-848: The Next Generation of the Consumer Rebalance Protocol
 - KIP-858: Handle JBOD broker disk failure in KRaft
 - KIP-890: Transactions Server-Side Defense
 - KIP-892: Transactional StateStores
 - KIP-896: Remove old client protocol API versions in Kafka 4.0 -
metrics/request log changes to identify deprecated apis
 - KIP-925: Rack aware task assignment in Kafka Streams
 - KIP-938: Add more metrics for measuring KRaft performance
 - KIP-951 - Leader discovery optimizations for the client
 - KIP-954: expand default DSL store configuration to custom types
 - KIP-959: Add BooleanConverter to Kafka Connect
 - KIP-960: Single-key single-timestamp IQv2 for state stores
 - KIP-963: Additional metrics in Tiered Storage
 - KIP-968: Support single-key_multi-timestamp Interactive Queries (IQv2)
for Versioned State Stores
 - KIP-970: Deprecate and remove Connect's redundant task configurations
endpoint
 - KIP-975: Docker Image for Apache Kafka
 - KIP-976: Cluster-wide dynamic log adjustment for Kafka Connect
 - KIP-978: Allow dynamic reloading of certificates with different DN / SANs
 - KIP-979: Allow independently stop KRaft processes
 - KIP-980: Allow creating connectors in a stopped state
 - KIP-985: Add reverseRange and reverseAll query over kv-store in IQv2
 - KIP-988: Streams Standby Update Listener
 - KIP-992: Proposal to introduce IQv2 Query Types: TimestampedKeyQuery and
TimestampedRangeQuery
 - KIP-998: Give ProducerConfig(props, doLog) constructor protected access

Notable KIPs that didn't make the Freeze were KIP-977 - it only got 2/3
votes.

For the full list and latest source of truth, refer to the Release Plan
3.7.0 Document
.

Thanks for your contributions once again!
Best,
Stan


On Thu, Nov 23, 2023 at 2:27 PM Nick Telford  wrote:

> Hi Stan,
>
> I'd like to propose including KIP-892 in the 3.7 release. The KIP has been
> accepted and I'm just working on rebasing the implementation against trunk
> before I open a PR.
>
> Regards,
> Nick
>
> On Tue, 21 Nov 2023 at 11:27, Mayank Shekhar Narula <
> mayanks.nar...@gmail.com> wrote:
>
> > Hi Stan
> >
> > Can you include KIP-951 to the 3.7 release plan? All PRs are merged in
> the
> > trunk.
> >
> > On Wed, Nov 15, 2023 at 4:05 PM Stanislav Kozlovski
> >  wrote:
> >
> > > Friendly reminder to everybody that the KIP Freeze is *exactly 7 days
> > away*
> > > - November 22.
> > >
> > > A KIP must be accepted by this date in order to be considered for this
> > > release. Note, any KIP that may not be implemented in time, or
> otherwise
> > > risks heavily destabilizing the release, should be deferred.
> > >
> > > Best,
> > > Stan
> > >
> > > On Fri, Nov 3, 2023 at 6:03 AM Sophie Blee-Goldman <
> > sop...@responsive.dev>
> > > wrote:
> > >
> > > > Looks great, thank you! +1
> > > >
> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> >  > > >
> > > > wrote:
> > > >
> > > > > +1 from me as well. Thanks, Stan!
> > > > >
> > > > > David
> > > > >
> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma 
> > wrote:
> > > > >
> > > > > > Thanks Stanislav, +1
> > > > > >
> > > > > > Ismael
> > > > > >
> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > > > > >  wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Given the discussion here and the lack of any pushback, I have
> > > > changed
> > > > > > the
> > > > > > > dates of the release:
> > > > > > > - KIP Freeze - *November 22 *(moved 4 days later)
> > > > > > > - Feature Freeze - *December 6 *(moved 2 days earlier)
> > > > > > > - Code Freeze - *December 20*
> > > > > > >
> > > > > > > If anyone has any thoughts against this proposal - please let
> me
> > > > know!
> > > > > It
> > > > > > > would be good to settle on this early. These will be the dates
> > > we're
> > > > > > going
> > > > > > > with
> > > > > > >
> > > > > > > Best,
> > > > > > > Stanislav
> > > > > > >
> > > > > > > On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman <
> > > > > > > sop...@responsive.dev>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Thanks for the response and explanations -- I think the main
> > > > question
> > > > > > for
> > > > > > > > me
> > > > > > > > was whether we intended to permanently increase the KF -- FF
> > gap
> > > > from
> > > 

Re: Apache Kafka 3.7.0 Release

[Nick Telford]

Hi Stan,

I'd like to propose including KIP-892 in the 3.7 release. The KIP has been
accepted and I'm just working on rebasing the implementation against trunk
before I open a PR.

Regards,
Nick

On Tue, 21 Nov 2023 at 11:27, Mayank Shekhar Narula <
mayanks.nar...@gmail.com> wrote:

> Hi Stan
>
> Can you include KIP-951 to the 3.7 release plan? All PRs are merged in the
> trunk.
>
> On Wed, Nov 15, 2023 at 4:05 PM Stanislav Kozlovski
>  wrote:
>
> > Friendly reminder to everybody that the KIP Freeze is *exactly 7 days
> away*
> > - November 22.
> >
> > A KIP must be accepted by this date in order to be considered for this
> > release. Note, any KIP that may not be implemented in time, or otherwise
> > risks heavily destabilizing the release, should be deferred.
> >
> > Best,
> > Stan
> >
> > On Fri, Nov 3, 2023 at 6:03 AM Sophie Blee-Goldman <
> sop...@responsive.dev>
> > wrote:
> >
> > > Looks great, thank you! +1
> > >
> > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
>  > >
> > > wrote:
> > >
> > > > +1 from me as well. Thanks, Stan!
> > > >
> > > > David
> > > >
> > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma 
> wrote:
> > > >
> > > > > Thanks Stanislav, +1
> > > > >
> > > > > Ismael
> > > > >
> > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > > > >  wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Given the discussion here and the lack of any pushback, I have
> > > changed
> > > > > the
> > > > > > dates of the release:
> > > > > > - KIP Freeze - *November 22 *(moved 4 days later)
> > > > > > - Feature Freeze - *December 6 *(moved 2 days earlier)
> > > > > > - Code Freeze - *December 20*
> > > > > >
> > > > > > If anyone has any thoughts against this proposal - please let me
> > > know!
> > > > It
> > > > > > would be good to settle on this early. These will be the dates
> > we're
> > > > > going
> > > > > > with
> > > > > >
> > > > > > Best,
> > > > > > Stanislav
> > > > > >
> > > > > > On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman <
> > > > > > sop...@responsive.dev>
> > > > > > wrote:
> > > > > >
> > > > > > > Thanks for the response and explanations -- I think the main
> > > question
> > > > > for
> > > > > > > me
> > > > > > > was whether we intended to permanently increase the KF -- FF
> gap
> > > from
> > > > > the
> > > > > > > historical 1 week to 3 weeks? Maybe this was a conscious
> decision
> > > > and I
> > > > > > > just
> > > > > > >  missed the memo, hopefully someone else can chime in here. I'm
> > all
> > > > for
> > > > > > > additional though. And looking around at some of the recent
> > > releases,
> > > > > it
> > > > > > > seems like we haven't been consistently following the "usual"
> > > > schedule
> > > > > > > since
> > > > > > > the 2.x releases.
> > > > > > >
> > > > > > > Anyways, my main concern was making sure to leave a full 2
> weeks
> > > > > between
> > > > > > > feature freeze and code freeze, so I'm generally happy with the
> > new
> > > > > > > proposal.
> > > > > > > Although I would still prefer to have the KIP freeze fall on a
> > > > > Wednesday
> > > > > > --
> > > > > > > Ismael actually brought up the same thing during the 3.5.0
> > release
> > > > > > > planning,
> > > > > > > so I'll just refer to his explanation for this:
> > > > > > >
> > > > > > > We typically choose a Wednesday for the various freeze dates -
> > > there
> > > > > are
> > > > > > > > often 1-2 day slips and it's better if that doesn't require
> > > people
> > > > > > > > working through the weekend.
> > > > > > > >
> > > > > > >
> > > > > > > (From this mailing list thread
> > > > > > > <
> > https://lists.apache.org/thread/dv1rym2jkf0141sfsbkws8ckkzw7st5h
> > > >)
> > > > > > >
> > > > > > > Thanks for driving the release!
> > > > > > > Sophie
> > > > > > >
> > > > > > > On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
> > > > > > >  wrote:
> > > > > > >
> > > > > > > > Thanks for the thorough response, Sophie.
> > > > > > > >
> > > > > > > > - Added to the "Future Release Plan"
> > > > > > > >
> > > > > > > > > 1. Why is the KIP freeze deadline on a Saturday?
> > > > > > > >
> > > > > > > > It was simply added as a starting point - around 30 days from
> > the
> > > > > > > > announcement. We can move it earlier to the 15th of November,
> > but
> > > > my
> > > > > > > > thinking is later is better with these things - it's already
> > > > > aggressive
> > > > > > > > enough. e.g given the choice of Nov 15 vs Nov 18, I don't
> > > > necessarily
> > > > > > > see a
> > > > > > > > strong reason to choose 15.
> > > > > > > >
> > > > > > > > If people feel strongly about this, to make up for this, we
> can
> > > eat
> > > > > > into
> > > > > > > > the KF-FF time as I'll touch upon later, and move FF a few
> days
> > > > > earlier
> > > > > > > to
> > > > > > > > land on a Wednesday.
> > > > > > > >
> > > > > > > > This reduces the time one has to get their feature complete
> > after
> > > > KF,
> > > > > > but
> > > > > > > > allows for longer 

Re: Apache Kafka 3.7.0 Release

[Mayank Shekhar Narula]

Hi Stan

Can you include KIP-951 to the 3.7 release plan? All PRs are merged in the
trunk.

On Wed, Nov 15, 2023 at 4:05 PM Stanislav Kozlovski
 wrote:

> Friendly reminder to everybody that the KIP Freeze is *exactly 7 days away*
> - November 22.
>
> A KIP must be accepted by this date in order to be considered for this
> release. Note, any KIP that may not be implemented in time, or otherwise
> risks heavily destabilizing the release, should be deferred.
>
> Best,
> Stan
>
> On Fri, Nov 3, 2023 at 6:03 AM Sophie Blee-Goldman 
> wrote:
>
> > Looks great, thank you! +1
> >
> > On Thu, Nov 2, 2023 at 10:21 AM David Jacot  >
> > wrote:
> >
> > > +1 from me as well. Thanks, Stan!
> > >
> > > David
> > >
> > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma  wrote:
> > >
> > > > Thanks Stanislav, +1
> > > >
> > > > Ismael
> > > >
> > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > > >  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Given the discussion here and the lack of any pushback, I have
> > changed
> > > > the
> > > > > dates of the release:
> > > > > - KIP Freeze - *November 22 *(moved 4 days later)
> > > > > - Feature Freeze - *December 6 *(moved 2 days earlier)
> > > > > - Code Freeze - *December 20*
> > > > >
> > > > > If anyone has any thoughts against this proposal - please let me
> > know!
> > > It
> > > > > would be good to settle on this early. These will be the dates
> we're
> > > > going
> > > > > with
> > > > >
> > > > > Best,
> > > > > Stanislav
> > > > >
> > > > > On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman <
> > > > > sop...@responsive.dev>
> > > > > wrote:
> > > > >
> > > > > > Thanks for the response and explanations -- I think the main
> > question
> > > > for
> > > > > > me
> > > > > > was whether we intended to permanently increase the KF -- FF gap
> > from
> > > > the
> > > > > > historical 1 week to 3 weeks? Maybe this was a conscious decision
> > > and I
> > > > > > just
> > > > > >  missed the memo, hopefully someone else can chime in here. I'm
> all
> > > for
> > > > > > additional though. And looking around at some of the recent
> > releases,
> > > > it
> > > > > > seems like we haven't been consistently following the "usual"
> > > schedule
> > > > > > since
> > > > > > the 2.x releases.
> > > > > >
> > > > > > Anyways, my main concern was making sure to leave a full 2 weeks
> > > > between
> > > > > > feature freeze and code freeze, so I'm generally happy with the
> new
> > > > > > proposal.
> > > > > > Although I would still prefer to have the KIP freeze fall on a
> > > > Wednesday
> > > > > --
> > > > > > Ismael actually brought up the same thing during the 3.5.0
> release
> > > > > > planning,
> > > > > > so I'll just refer to his explanation for this:
> > > > > >
> > > > > > We typically choose a Wednesday for the various freeze dates -
> > there
> > > > are
> > > > > > > often 1-2 day slips and it's better if that doesn't require
> > people
> > > > > > > working through the weekend.
> > > > > > >
> > > > > >
> > > > > > (From this mailing list thread
> > > > > > <
> https://lists.apache.org/thread/dv1rym2jkf0141sfsbkws8ckkzw7st5h
> > >)
> > > > > >
> > > > > > Thanks for driving the release!
> > > > > > Sophie
> > > > > >
> > > > > > On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
> > > > > >  wrote:
> > > > > >
> > > > > > > Thanks for the thorough response, Sophie.
> > > > > > >
> > > > > > > - Added to the "Future Release Plan"
> > > > > > >
> > > > > > > > 1. Why is the KIP freeze deadline on a Saturday?
> > > > > > >
> > > > > > > It was simply added as a starting point - around 30 days from
> the
> > > > > > > announcement. We can move it earlier to the 15th of November,
> but
> > > my
> > > > > > > thinking is later is better with these things - it's already
> > > > aggressive
> > > > > > > enough. e.g given the choice of Nov 15 vs Nov 18, I don't
> > > necessarily
> > > > > > see a
> > > > > > > strong reason to choose 15.
> > > > > > >
> > > > > > > If people feel strongly about this, to make up for this, we can
> > eat
> > > > > into
> > > > > > > the KF-FF time as I'll touch upon later, and move FF a few days
> > > > earlier
> > > > > > to
> > > > > > > land on a Wednesday.
> > > > > > >
> > > > > > > This reduces the time one has to get their feature complete
> after
> > > KF,
> > > > > but
> > > > > > > allows for longer time to a KIP accepted, so the KF-FF gap can
> be
> > > > made
> > > > > up
> > > > > > > when developing the feature in parallel.
> > > > > > >
> > > > > > > > , this makes it easy for everyone to remember when the next
> > > > deadline
> > > > > is
> > > > > > > so they can make sure to get everything in on time. I worry
> that
> > > > > varying
> > > > > > > this will catch people off guard.
> > > > > > >
> > > > > > > I don't see much value in optimizing the dates for ease of
> > memory -
> > > > > > besides
> > > > > > > the KIP Freeze (which is the base date), there are only two
> more
> > > > dates
> > > > > 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Friendly reminder to everybody that the KIP Freeze is *exactly 7 days away*
- November 22.

A KIP must be accepted by this date in order to be considered for this
release. Note, any KIP that may not be implemented in time, or otherwise
risks heavily destabilizing the release, should be deferred.

Best,
Stan

On Fri, Nov 3, 2023 at 6:03 AM Sophie Blee-Goldman 
wrote:

> Looks great, thank you! +1
>
> On Thu, Nov 2, 2023 at 10:21 AM David Jacot 
> wrote:
>
> > +1 from me as well. Thanks, Stan!
> >
> > David
> >
> > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma  wrote:
> >
> > > Thanks Stanislav, +1
> > >
> > > Ismael
> > >
> > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > >  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Given the discussion here and the lack of any pushback, I have
> changed
> > > the
> > > > dates of the release:
> > > > - KIP Freeze - *November 22 *(moved 4 days later)
> > > > - Feature Freeze - *December 6 *(moved 2 days earlier)
> > > > - Code Freeze - *December 20*
> > > >
> > > > If anyone has any thoughts against this proposal - please let me
> know!
> > It
> > > > would be good to settle on this early. These will be the dates we're
> > > going
> > > > with
> > > >
> > > > Best,
> > > > Stanislav
> > > >
> > > > On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman <
> > > > sop...@responsive.dev>
> > > > wrote:
> > > >
> > > > > Thanks for the response and explanations -- I think the main
> question
> > > for
> > > > > me
> > > > > was whether we intended to permanently increase the KF -- FF gap
> from
> > > the
> > > > > historical 1 week to 3 weeks? Maybe this was a conscious decision
> > and I
> > > > > just
> > > > >  missed the memo, hopefully someone else can chime in here. I'm all
> > for
> > > > > additional though. And looking around at some of the recent
> releases,
> > > it
> > > > > seems like we haven't been consistently following the "usual"
> > schedule
> > > > > since
> > > > > the 2.x releases.
> > > > >
> > > > > Anyways, my main concern was making sure to leave a full 2 weeks
> > > between
> > > > > feature freeze and code freeze, so I'm generally happy with the new
> > > > > proposal.
> > > > > Although I would still prefer to have the KIP freeze fall on a
> > > Wednesday
> > > > --
> > > > > Ismael actually brought up the same thing during the 3.5.0 release
> > > > > planning,
> > > > > so I'll just refer to his explanation for this:
> > > > >
> > > > > We typically choose a Wednesday for the various freeze dates -
> there
> > > are
> > > > > > often 1-2 day slips and it's better if that doesn't require
> people
> > > > > > working through the weekend.
> > > > > >
> > > > >
> > > > > (From this mailing list thread
> > > > >  >)
> > > > >
> > > > > Thanks for driving the release!
> > > > > Sophie
> > > > >
> > > > > On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
> > > > >  wrote:
> > > > >
> > > > > > Thanks for the thorough response, Sophie.
> > > > > >
> > > > > > - Added to the "Future Release Plan"
> > > > > >
> > > > > > > 1. Why is the KIP freeze deadline on a Saturday?
> > > > > >
> > > > > > It was simply added as a starting point - around 30 days from the
> > > > > > announcement. We can move it earlier to the 15th of November, but
> > my
> > > > > > thinking is later is better with these things - it's already
> > > aggressive
> > > > > > enough. e.g given the choice of Nov 15 vs Nov 18, I don't
> > necessarily
> > > > > see a
> > > > > > strong reason to choose 15.
> > > > > >
> > > > > > If people feel strongly about this, to make up for this, we can
> eat
> > > > into
> > > > > > the KF-FF time as I'll touch upon later, and move FF a few days
> > > earlier
> > > > > to
> > > > > > land on a Wednesday.
> > > > > >
> > > > > > This reduces the time one has to get their feature complete after
> > KF,
> > > > but
> > > > > > allows for longer time to a KIP accepted, so the KF-FF gap can be
> > > made
> > > > up
> > > > > > when developing the feature in parallel.
> > > > > >
> > > > > > > , this makes it easy for everyone to remember when the next
> > > deadline
> > > > is
> > > > > > so they can make sure to get everything in on time. I worry that
> > > > varying
> > > > > > this will catch people off guard.
> > > > > >
> > > > > > I don't see much value in optimizing the dates for ease of
> memory -
> > > > > besides
> > > > > > the KIP Freeze (which is the base date), there are only two more
> > > dates
> > > > to
> > > > > > remember that are on the wiki. More importantly, we have a
> plethora
> > > of
> > > > > > tools that can be used to set up reminders - so a contributor
> > doesn't
> > > > > > necessarily need to remember anything if they're serious about
> > > getting
> > > > > > their feature in.
> > > > > >
> > > > > > > 3. Is there a particular reason for having the feature freeze
> > > almost
> > > > a
> > > > > > full 3 weeks from the KIP freeze? ... having 3 

Re: Apache Kafka 3.7.0 Release

[Sophie Blee-Goldman]

Looks great, thank you! +1

On Thu, Nov 2, 2023 at 10:21 AM David Jacot 
wrote:

> +1 from me as well. Thanks, Stan!
>
> David
>
> On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma  wrote:
>
> > Thanks Stanislav, +1
> >
> > Ismael
> >
> > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> >  wrote:
> >
> > > Hi all,
> > >
> > > Given the discussion here and the lack of any pushback, I have changed
> > the
> > > dates of the release:
> > > - KIP Freeze - *November 22 *(moved 4 days later)
> > > - Feature Freeze - *December 6 *(moved 2 days earlier)
> > > - Code Freeze - *December 20*
> > >
> > > If anyone has any thoughts against this proposal - please let me know!
> It
> > > would be good to settle on this early. These will be the dates we're
> > going
> > > with
> > >
> > > Best,
> > > Stanislav
> > >
> > > On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman <
> > > sop...@responsive.dev>
> > > wrote:
> > >
> > > > Thanks for the response and explanations -- I think the main question
> > for
> > > > me
> > > > was whether we intended to permanently increase the KF -- FF gap from
> > the
> > > > historical 1 week to 3 weeks? Maybe this was a conscious decision
> and I
> > > > just
> > > >  missed the memo, hopefully someone else can chime in here. I'm all
> for
> > > > additional though. And looking around at some of the recent releases,
> > it
> > > > seems like we haven't been consistently following the "usual"
> schedule
> > > > since
> > > > the 2.x releases.
> > > >
> > > > Anyways, my main concern was making sure to leave a full 2 weeks
> > between
> > > > feature freeze and code freeze, so I'm generally happy with the new
> > > > proposal.
> > > > Although I would still prefer to have the KIP freeze fall on a
> > Wednesday
> > > --
> > > > Ismael actually brought up the same thing during the 3.5.0 release
> > > > planning,
> > > > so I'll just refer to his explanation for this:
> > > >
> > > > We typically choose a Wednesday for the various freeze dates - there
> > are
> > > > > often 1-2 day slips and it's better if that doesn't require people
> > > > > working through the weekend.
> > > > >
> > > >
> > > > (From this mailing list thread
> > > > )
> > > >
> > > > Thanks for driving the release!
> > > > Sophie
> > > >
> > > > On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
> > > >  wrote:
> > > >
> > > > > Thanks for the thorough response, Sophie.
> > > > >
> > > > > - Added to the "Future Release Plan"
> > > > >
> > > > > > 1. Why is the KIP freeze deadline on a Saturday?
> > > > >
> > > > > It was simply added as a starting point - around 30 days from the
> > > > > announcement. We can move it earlier to the 15th of November, but
> my
> > > > > thinking is later is better with these things - it's already
> > aggressive
> > > > > enough. e.g given the choice of Nov 15 vs Nov 18, I don't
> necessarily
> > > > see a
> > > > > strong reason to choose 15.
> > > > >
> > > > > If people feel strongly about this, to make up for this, we can eat
> > > into
> > > > > the KF-FF time as I'll touch upon later, and move FF a few days
> > earlier
> > > > to
> > > > > land on a Wednesday.
> > > > >
> > > > > This reduces the time one has to get their feature complete after
> KF,
> > > but
> > > > > allows for longer time to a KIP accepted, so the KF-FF gap can be
> > made
> > > up
> > > > > when developing the feature in parallel.
> > > > >
> > > > > > , this makes it easy for everyone to remember when the next
> > deadline
> > > is
> > > > > so they can make sure to get everything in on time. I worry that
> > > varying
> > > > > this will catch people off guard.
> > > > >
> > > > > I don't see much value in optimizing the dates for ease of memory -
> > > > besides
> > > > > the KIP Freeze (which is the base date), there are only two more
> > dates
> > > to
> > > > > remember that are on the wiki. More importantly, we have a plethora
> > of
> > > > > tools that can be used to set up reminders - so a contributor
> doesn't
> > > > > necessarily need to remember anything if they're serious about
> > getting
> > > > > their feature in.
> > > > >
> > > > > > 3. Is there a particular reason for having the feature freeze
> > almost
> > > a
> > > > > full 3 weeks from the KIP freeze? ... having 3 weeks between the
> KIP
> > > and
> > > > > feature freeze (which are
> > > > > usually separated by just a single week)?
> > > > >
> > > > > I was going off the last two releases, which had *20 days* (~3
> weeks)
> > > in
> > > > > between KF & FF. Here are their dates:
> > > > >
> > > > > - AK 3.5
> > > > >   - KF: 22 March
> > > > >   - FF: 12 April
> > > > > - (20 days after)
> > > > >   - CF: 26 April
> > > > > - (14 days after)
> > > > >   - Release: 15 June
> > > > >  - 50 days after CF
> > > > > - AK 3.6
> > > > >   - KF: 26 July
> > > > >   - FF: 16 Aug
> > > > > - (20 days after)
> > > > >   - CF: 30 Aug
> > > > > - (14 days after)
> 

Re: Apache Kafka 3.7.0 Release

[Justine Olshan]

This makes sense to me. Thanks for following up, Stan.

On Thu, Nov 2, 2023 at 7:02 AM Stanislav Kozlovski
 wrote:

> Hi all,
>
> Given the discussion here and the lack of any pushback, I have changed the
> dates of the release:
> - KIP Freeze - *November 22 *(moved 4 days later)
> - Feature Freeze - *December 6 *(moved 2 days earlier)
> - Code Freeze - *December 20*
>
> If anyone has any thoughts against this proposal - please let me know! It
> would be good to settle on this early. These will be the dates we're going
> with
>
> Best,
> Stanislav
>
> On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman <
> sop...@responsive.dev>
> wrote:
>
> > Thanks for the response and explanations -- I think the main question for
> > me
> > was whether we intended to permanently increase the KF -- FF gap from the
> > historical 1 week to 3 weeks? Maybe this was a conscious decision and I
> > just
> >  missed the memo, hopefully someone else can chime in here. I'm all for
> > additional though. And looking around at some of the recent releases, it
> > seems like we haven't been consistently following the "usual" schedule
> > since
> > the 2.x releases.
> >
> > Anyways, my main concern was making sure to leave a full 2 weeks between
> > feature freeze and code freeze, so I'm generally happy with the new
> > proposal.
> > Although I would still prefer to have the KIP freeze fall on a Wednesday
> --
> > Ismael actually brought up the same thing during the 3.5.0 release
> > planning,
> > so I'll just refer to his explanation for this:
> >
> > We typically choose a Wednesday for the various freeze dates - there are
> > > often 1-2 day slips and it's better if that doesn't require people
> > > working through the weekend.
> > >
> >
> > (From this mailing list thread
> > )
> >
> > Thanks for driving the release!
> > Sophie
> >
> > On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
> >  wrote:
> >
> > > Thanks for the thorough response, Sophie.
> > >
> > > - Added to the "Future Release Plan"
> > >
> > > > 1. Why is the KIP freeze deadline on a Saturday?
> > >
> > > It was simply added as a starting point - around 30 days from the
> > > announcement. We can move it earlier to the 15th of November, but my
> > > thinking is later is better with these things - it's already aggressive
> > > enough. e.g given the choice of Nov 15 vs Nov 18, I don't necessarily
> > see a
> > > strong reason to choose 15.
> > >
> > > If people feel strongly about this, to make up for this, we can eat
> into
> > > the KF-FF time as I'll touch upon later, and move FF a few days earlier
> > to
> > > land on a Wednesday.
> > >
> > > This reduces the time one has to get their feature complete after KF,
> but
> > > allows for longer time to a KIP accepted, so the KF-FF gap can be made
> up
> > > when developing the feature in parallel.
> > >
> > > > , this makes it easy for everyone to remember when the next deadline
> is
> > > so they can make sure to get everything in on time. I worry that
> varying
> > > this will catch people off guard.
> > >
> > > I don't see much value in optimizing the dates for ease of memory -
> > besides
> > > the KIP Freeze (which is the base date), there are only two more dates
> to
> > > remember that are on the wiki. More importantly, we have a plethora of
> > > tools that can be used to set up reminders - so a contributor doesn't
> > > necessarily need to remember anything if they're serious about getting
> > > their feature in.
> > >
> > > > 3. Is there a particular reason for having the feature freeze almost
> a
> > > full 3 weeks from the KIP freeze? ... having 3 weeks between the KIP
> and
> > > feature freeze (which are
> > > usually separated by just a single week)?
> > >
> > > I was going off the last two releases, which had *20 days* (~3 weeks)
> in
> > > between KF & FF. Here are their dates:
> > >
> > > - AK 3.5
> > >   - KF: 22 March
> > >   - FF: 12 April
> > > - (20 days after)
> > >   - CF: 26 April
> > > - (14 days after)
> > >   - Release: 15 June
> > >  - 50 days after CF
> > > - AK 3.6
> > >   - KF: 26 July
> > >   - FF: 16 Aug
> > > - (20 days after)
> > >   - CF: 30 Aug
> > > - (14 days after)
> > >   - Release: 11 October
> > > - 42 days after CF
> > >
> > > I don't know the precise reasoning for extending the time, nor what is
> > the
> > > most appropriate time - but having talked offline to some folks prior
> to
> > > this discussion, it seemed reasonable.
> > >
> > > Your proposal uses an aggressive 1-week gap between both, which is
> quite
> > > the jump from the previous 3 weeks.
> > >
> > > Perhaps someone with more direct experience in the recent can chime in
> > > here. Both for the reasoning for the extension from 1w to 3w in the
> last
> > 2
> > > releases, and how they feel about reducing this range.
> > >
> > > > 4. On the other hand, we usually have a full two weeks from the
> feature
> > > freeze 

Re: Apache Kafka 3.7.0 Release

[David Jacot]

+1 from me as well. Thanks, Stan!

David

On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma  wrote:

> Thanks Stanislav, +1
>
> Ismael
>
> On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
>  wrote:
>
> > Hi all,
> >
> > Given the discussion here and the lack of any pushback, I have changed
> the
> > dates of the release:
> > - KIP Freeze - *November 22 *(moved 4 days later)
> > - Feature Freeze - *December 6 *(moved 2 days earlier)
> > - Code Freeze - *December 20*
> >
> > If anyone has any thoughts against this proposal - please let me know! It
> > would be good to settle on this early. These will be the dates we're
> going
> > with
> >
> > Best,
> > Stanislav
> >
> > On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman <
> > sop...@responsive.dev>
> > wrote:
> >
> > > Thanks for the response and explanations -- I think the main question
> for
> > > me
> > > was whether we intended to permanently increase the KF -- FF gap from
> the
> > > historical 1 week to 3 weeks? Maybe this was a conscious decision and I
> > > just
> > >  missed the memo, hopefully someone else can chime in here. I'm all for
> > > additional though. And looking around at some of the recent releases,
> it
> > > seems like we haven't been consistently following the "usual" schedule
> > > since
> > > the 2.x releases.
> > >
> > > Anyways, my main concern was making sure to leave a full 2 weeks
> between
> > > feature freeze and code freeze, so I'm generally happy with the new
> > > proposal.
> > > Although I would still prefer to have the KIP freeze fall on a
> Wednesday
> > --
> > > Ismael actually brought up the same thing during the 3.5.0 release
> > > planning,
> > > so I'll just refer to his explanation for this:
> > >
> > > We typically choose a Wednesday for the various freeze dates - there
> are
> > > > often 1-2 day slips and it's better if that doesn't require people
> > > > working through the weekend.
> > > >
> > >
> > > (From this mailing list thread
> > > )
> > >
> > > Thanks for driving the release!
> > > Sophie
> > >
> > > On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
> > >  wrote:
> > >
> > > > Thanks for the thorough response, Sophie.
> > > >
> > > > - Added to the "Future Release Plan"
> > > >
> > > > > 1. Why is the KIP freeze deadline on a Saturday?
> > > >
> > > > It was simply added as a starting point - around 30 days from the
> > > > announcement. We can move it earlier to the 15th of November, but my
> > > > thinking is later is better with these things - it's already
> aggressive
> > > > enough. e.g given the choice of Nov 15 vs Nov 18, I don't necessarily
> > > see a
> > > > strong reason to choose 15.
> > > >
> > > > If people feel strongly about this, to make up for this, we can eat
> > into
> > > > the KF-FF time as I'll touch upon later, and move FF a few days
> earlier
> > > to
> > > > land on a Wednesday.
> > > >
> > > > This reduces the time one has to get their feature complete after KF,
> > but
> > > > allows for longer time to a KIP accepted, so the KF-FF gap can be
> made
> > up
> > > > when developing the feature in parallel.
> > > >
> > > > > , this makes it easy for everyone to remember when the next
> deadline
> > is
> > > > so they can make sure to get everything in on time. I worry that
> > varying
> > > > this will catch people off guard.
> > > >
> > > > I don't see much value in optimizing the dates for ease of memory -
> > > besides
> > > > the KIP Freeze (which is the base date), there are only two more
> dates
> > to
> > > > remember that are on the wiki. More importantly, we have a plethora
> of
> > > > tools that can be used to set up reminders - so a contributor doesn't
> > > > necessarily need to remember anything if they're serious about
> getting
> > > > their feature in.
> > > >
> > > > > 3. Is there a particular reason for having the feature freeze
> almost
> > a
> > > > full 3 weeks from the KIP freeze? ... having 3 weeks between the KIP
> > and
> > > > feature freeze (which are
> > > > usually separated by just a single week)?
> > > >
> > > > I was going off the last two releases, which had *20 days* (~3 weeks)
> > in
> > > > between KF & FF. Here are their dates:
> > > >
> > > > - AK 3.5
> > > >   - KF: 22 March
> > > >   - FF: 12 April
> > > > - (20 days after)
> > > >   - CF: 26 April
> > > > - (14 days after)
> > > >   - Release: 15 June
> > > >  - 50 days after CF
> > > > - AK 3.6
> > > >   - KF: 26 July
> > > >   - FF: 16 Aug
> > > > - (20 days after)
> > > >   - CF: 30 Aug
> > > > - (14 days after)
> > > >   - Release: 11 October
> > > > - 42 days after CF
> > > >
> > > > I don't know the precise reasoning for extending the time, nor what
> is
> > > the
> > > > most appropriate time - but having talked offline to some folks prior
> > to
> > > > this discussion, it seemed reasonable.
> > > >
> > > > Your proposal uses an aggressive 1-week gap between both, which is
> > quite
> > > 

Re: Apache Kafka 3.7.0 Release

[Ismael Juma]

Thanks Stanislav, +1

Ismael

On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
 wrote:

> Hi all,
>
> Given the discussion here and the lack of any pushback, I have changed the
> dates of the release:
> - KIP Freeze - *November 22 *(moved 4 days later)
> - Feature Freeze - *December 6 *(moved 2 days earlier)
> - Code Freeze - *December 20*
>
> If anyone has any thoughts against this proposal - please let me know! It
> would be good to settle on this early. These will be the dates we're going
> with
>
> Best,
> Stanislav
>
> On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman <
> sop...@responsive.dev>
> wrote:
>
> > Thanks for the response and explanations -- I think the main question for
> > me
> > was whether we intended to permanently increase the KF -- FF gap from the
> > historical 1 week to 3 weeks? Maybe this was a conscious decision and I
> > just
> >  missed the memo, hopefully someone else can chime in here. I'm all for
> > additional though. And looking around at some of the recent releases, it
> > seems like we haven't been consistently following the "usual" schedule
> > since
> > the 2.x releases.
> >
> > Anyways, my main concern was making sure to leave a full 2 weeks between
> > feature freeze and code freeze, so I'm generally happy with the new
> > proposal.
> > Although I would still prefer to have the KIP freeze fall on a Wednesday
> --
> > Ismael actually brought up the same thing during the 3.5.0 release
> > planning,
> > so I'll just refer to his explanation for this:
> >
> > We typically choose a Wednesday for the various freeze dates - there are
> > > often 1-2 day slips and it's better if that doesn't require people
> > > working through the weekend.
> > >
> >
> > (From this mailing list thread
> > )
> >
> > Thanks for driving the release!
> > Sophie
> >
> > On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
> >  wrote:
> >
> > > Thanks for the thorough response, Sophie.
> > >
> > > - Added to the "Future Release Plan"
> > >
> > > > 1. Why is the KIP freeze deadline on a Saturday?
> > >
> > > It was simply added as a starting point - around 30 days from the
> > > announcement. We can move it earlier to the 15th of November, but my
> > > thinking is later is better with these things - it's already aggressive
> > > enough. e.g given the choice of Nov 15 vs Nov 18, I don't necessarily
> > see a
> > > strong reason to choose 15.
> > >
> > > If people feel strongly about this, to make up for this, we can eat
> into
> > > the KF-FF time as I'll touch upon later, and move FF a few days earlier
> > to
> > > land on a Wednesday.
> > >
> > > This reduces the time one has to get their feature complete after KF,
> but
> > > allows for longer time to a KIP accepted, so the KF-FF gap can be made
> up
> > > when developing the feature in parallel.
> > >
> > > > , this makes it easy for everyone to remember when the next deadline
> is
> > > so they can make sure to get everything in on time. I worry that
> varying
> > > this will catch people off guard.
> > >
> > > I don't see much value in optimizing the dates for ease of memory -
> > besides
> > > the KIP Freeze (which is the base date), there are only two more dates
> to
> > > remember that are on the wiki. More importantly, we have a plethora of
> > > tools that can be used to set up reminders - so a contributor doesn't
> > > necessarily need to remember anything if they're serious about getting
> > > their feature in.
> > >
> > > > 3. Is there a particular reason for having the feature freeze almost
> a
> > > full 3 weeks from the KIP freeze? ... having 3 weeks between the KIP
> and
> > > feature freeze (which are
> > > usually separated by just a single week)?
> > >
> > > I was going off the last two releases, which had *20 days* (~3 weeks)
> in
> > > between KF & FF. Here are their dates:
> > >
> > > - AK 3.5
> > >   - KF: 22 March
> > >   - FF: 12 April
> > > - (20 days after)
> > >   - CF: 26 April
> > > - (14 days after)
> > >   - Release: 15 June
> > >  - 50 days after CF
> > > - AK 3.6
> > >   - KF: 26 July
> > >   - FF: 16 Aug
> > > - (20 days after)
> > >   - CF: 30 Aug
> > > - (14 days after)
> > >   - Release: 11 October
> > > - 42 days after CF
> > >
> > > I don't know the precise reasoning for extending the time, nor what is
> > the
> > > most appropriate time - but having talked offline to some folks prior
> to
> > > this discussion, it seemed reasonable.
> > >
> > > Your proposal uses an aggressive 1-week gap between both, which is
> quite
> > > the jump from the previous 3 weeks.
> > >
> > > Perhaps someone with more direct experience in the recent can chime in
> > > here. Both for the reasoning for the extension from 1w to 3w in the
> last
> > 2
> > > releases, and how they feel about reducing this range.
> > >
> > > > 4. On the other hand, we usually have a full two weeks from the
> feature
> > > freeze deadline to the code freeze 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Hi all,

Given the discussion here and the lack of any pushback, I have changed the
dates of the release:
- KIP Freeze - *November 22 *(moved 4 days later)
- Feature Freeze - *December 6 *(moved 2 days earlier)
- Code Freeze - *December 20*

If anyone has any thoughts against this proposal - please let me know! It
would be good to settle on this early. These will be the dates we're going
with

Best,
Stanislav

On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman 
wrote:

> Thanks for the response and explanations -- I think the main question for
> me
> was whether we intended to permanently increase the KF -- FF gap from the
> historical 1 week to 3 weeks? Maybe this was a conscious decision and I
> just
>  missed the memo, hopefully someone else can chime in here. I'm all for
> additional though. And looking around at some of the recent releases, it
> seems like we haven't been consistently following the "usual" schedule
> since
> the 2.x releases.
>
> Anyways, my main concern was making sure to leave a full 2 weeks between
> feature freeze and code freeze, so I'm generally happy with the new
> proposal.
> Although I would still prefer to have the KIP freeze fall on a Wednesday --
> Ismael actually brought up the same thing during the 3.5.0 release
> planning,
> so I'll just refer to his explanation for this:
>
> We typically choose a Wednesday for the various freeze dates - there are
> > often 1-2 day slips and it's better if that doesn't require people
> > working through the weekend.
> >
>
> (From this mailing list thread
> )
>
> Thanks for driving the release!
> Sophie
>
> On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
>  wrote:
>
> > Thanks for the thorough response, Sophie.
> >
> > - Added to the "Future Release Plan"
> >
> > > 1. Why is the KIP freeze deadline on a Saturday?
> >
> > It was simply added as a starting point - around 30 days from the
> > announcement. We can move it earlier to the 15th of November, but my
> > thinking is later is better with these things - it's already aggressive
> > enough. e.g given the choice of Nov 15 vs Nov 18, I don't necessarily
> see a
> > strong reason to choose 15.
> >
> > If people feel strongly about this, to make up for this, we can eat into
> > the KF-FF time as I'll touch upon later, and move FF a few days earlier
> to
> > land on a Wednesday.
> >
> > This reduces the time one has to get their feature complete after KF, but
> > allows for longer time to a KIP accepted, so the KF-FF gap can be made up
> > when developing the feature in parallel.
> >
> > > , this makes it easy for everyone to remember when the next deadline is
> > so they can make sure to get everything in on time. I worry that varying
> > this will catch people off guard.
> >
> > I don't see much value in optimizing the dates for ease of memory -
> besides
> > the KIP Freeze (which is the base date), there are only two more dates to
> > remember that are on the wiki. More importantly, we have a plethora of
> > tools that can be used to set up reminders - so a contributor doesn't
> > necessarily need to remember anything if they're serious about getting
> > their feature in.
> >
> > > 3. Is there a particular reason for having the feature freeze almost a
> > full 3 weeks from the KIP freeze? ... having 3 weeks between the KIP and
> > feature freeze (which are
> > usually separated by just a single week)?
> >
> > I was going off the last two releases, which had *20 days* (~3 weeks) in
> > between KF & FF. Here are their dates:
> >
> > - AK 3.5
> >   - KF: 22 March
> >   - FF: 12 April
> > - (20 days after)
> >   - CF: 26 April
> > - (14 days after)
> >   - Release: 15 June
> >  - 50 days after CF
> > - AK 3.6
> >   - KF: 26 July
> >   - FF: 16 Aug
> > - (20 days after)
> >   - CF: 30 Aug
> > - (14 days after)
> >   - Release: 11 October
> > - 42 days after CF
> >
> > I don't know the precise reasoning for extending the time, nor what is
> the
> > most appropriate time - but having talked offline to some folks prior to
> > this discussion, it seemed reasonable.
> >
> > Your proposal uses an aggressive 1-week gap between both, which is quite
> > the jump from the previous 3 weeks.
> >
> > Perhaps someone with more direct experience in the recent can chime in
> > here. Both for the reasoning for the extension from 1w to 3w in the last
> 2
> > releases, and how they feel about reducing this range.
> >
> > > 4. On the other hand, we usually have a full two weeks from the feature
> > freeze deadline to the code freeze but with the given schedule there
> would
> > only be a week and a half. Given how important this period is for testing
> > and stabilizing the release, and how vital this is for uncovering
> blockers
> > that would have delayed the release deadline, I really think we should
> > maintain the two-week gap (at a minimum)
> >
> > This is a fair point. At the end of the day, we have to take 

Re: Apache Kafka 3.7.0 Release

[Sophie Blee-Goldman]

Thanks for the response and explanations -- I think the main question for me
was whether we intended to permanently increase the KF -- FF gap from the
historical 1 week to 3 weeks? Maybe this was a conscious decision and I just
 missed the memo, hopefully someone else can chime in here. I'm all for
additional though. And looking around at some of the recent releases, it
seems like we haven't been consistently following the "usual" schedule
since
the 2.x releases.

Anyways, my main concern was making sure to leave a full 2 weeks between
feature freeze and code freeze, so I'm generally happy with the new
proposal.
Although I would still prefer to have the KIP freeze fall on a Wednesday --
Ismael actually brought up the same thing during the 3.5.0 release planning,
so I'll just refer to his explanation for this:

We typically choose a Wednesday for the various freeze dates - there are
> often 1-2 day slips and it's better if that doesn't require people
> working through the weekend.
>

(From this mailing list thread
)

Thanks for driving the release!
Sophie

On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
 wrote:

> Thanks for the thorough response, Sophie.
>
> - Added to the "Future Release Plan"
>
> > 1. Why is the KIP freeze deadline on a Saturday?
>
> It was simply added as a starting point - around 30 days from the
> announcement. We can move it earlier to the 15th of November, but my
> thinking is later is better with these things - it's already aggressive
> enough. e.g given the choice of Nov 15 vs Nov 18, I don't necessarily see a
> strong reason to choose 15.
>
> If people feel strongly about this, to make up for this, we can eat into
> the KF-FF time as I'll touch upon later, and move FF a few days earlier to
> land on a Wednesday.
>
> This reduces the time one has to get their feature complete after KF, but
> allows for longer time to a KIP accepted, so the KF-FF gap can be made up
> when developing the feature in parallel.
>
> > , this makes it easy for everyone to remember when the next deadline is
> so they can make sure to get everything in on time. I worry that varying
> this will catch people off guard.
>
> I don't see much value in optimizing the dates for ease of memory - besides
> the KIP Freeze (which is the base date), there are only two more dates to
> remember that are on the wiki. More importantly, we have a plethora of
> tools that can be used to set up reminders - so a contributor doesn't
> necessarily need to remember anything if they're serious about getting
> their feature in.
>
> > 3. Is there a particular reason for having the feature freeze almost a
> full 3 weeks from the KIP freeze? ... having 3 weeks between the KIP and
> feature freeze (which are
> usually separated by just a single week)?
>
> I was going off the last two releases, which had *20 days* (~3 weeks) in
> between KF & FF. Here are their dates:
>
> - AK 3.5
>   - KF: 22 March
>   - FF: 12 April
> - (20 days after)
>   - CF: 26 April
> - (14 days after)
>   - Release: 15 June
>  - 50 days after CF
> - AK 3.6
>   - KF: 26 July
>   - FF: 16 Aug
> - (20 days after)
>   - CF: 30 Aug
> - (14 days after)
>   - Release: 11 October
> - 42 days after CF
>
> I don't know the precise reasoning for extending the time, nor what is the
> most appropriate time - but having talked offline to some folks prior to
> this discussion, it seemed reasonable.
>
> Your proposal uses an aggressive 1-week gap between both, which is quite
> the jump from the previous 3 weeks.
>
> Perhaps someone with more direct experience in the recent can chime in
> here. Both for the reasoning for the extension from 1w to 3w in the last 2
> releases, and how they feel about reducing this range.
>
> > 4. On the other hand, we usually have a full two weeks from the feature
> freeze deadline to the code freeze but with the given schedule there would
> only be a week and a half. Given how important this period is for testing
> and stabilizing the release, and how vital this is for uncovering blockers
> that would have delayed the release deadline, I really think we should
> maintain the two-week gap (at a minimum)
>
> This is a fair point. At the end of the day, we have to take time out of
> either one of the 3 ranges (now - KF; KF-FF; FF-CF;)
> *It sounds fair to me to take out half a week from KF-FF and add it to
> FF-CF*. e.g:
> - KF=Nov 18 (Sat)
> - FF=Dec 6 (Wed) 2.5w after
> - CF=Dec 20 (Wed) 2w after
>
> How do others feel about this?
>
> > Just to throw a suggestion out there, if we want to avoid running into
> the winter holidays while still making up for slipping of recent releases,
> what about something like this: ...
>
> Looking at the last 2 releases, they both had a full month between KIP
> Freeze and Code Freeze to finish contributions. Your proposal goes back to
> a more aggressive 3 weeks e2e time. All else equal, if the release date is
> to be 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Thanks for the thorough response, Sophie.

- Added to the "Future Release Plan"

> 1. Why is the KIP freeze deadline on a Saturday?

It was simply added as a starting point - around 30 days from the
announcement. We can move it earlier to the 15th of November, but my
thinking is later is better with these things - it's already aggressive
enough. e.g given the choice of Nov 15 vs Nov 18, I don't necessarily see a
strong reason to choose 15.

If people feel strongly about this, to make up for this, we can eat into
the KF-FF time as I'll touch upon later, and move FF a few days earlier to
land on a Wednesday.

This reduces the time one has to get their feature complete after KF, but
allows for longer time to a KIP accepted, so the KF-FF gap can be made up
when developing the feature in parallel.

> , this makes it easy for everyone to remember when the next deadline is
so they can make sure to get everything in on time. I worry that varying
this will catch people off guard.

I don't see much value in optimizing the dates for ease of memory - besides
the KIP Freeze (which is the base date), there are only two more dates to
remember that are on the wiki. More importantly, we have a plethora of
tools that can be used to set up reminders - so a contributor doesn't
necessarily need to remember anything if they're serious about getting
their feature in.

> 3. Is there a particular reason for having the feature freeze almost a
full 3 weeks from the KIP freeze? ... having 3 weeks between the KIP and
feature freeze (which are
usually separated by just a single week)?

I was going off the last two releases, which had *20 days* (~3 weeks) in
between KF & FF. Here are their dates:

- AK 3.5
  - KF: 22 March
  - FF: 12 April
- (20 days after)
  - CF: 26 April
- (14 days after)
  - Release: 15 June
 - 50 days after CF
- AK 3.6
  - KF: 26 July
  - FF: 16 Aug
- (20 days after)
  - CF: 30 Aug
- (14 days after)
  - Release: 11 October
- 42 days after CF

I don't know the precise reasoning for extending the time, nor what is the
most appropriate time - but having talked offline to some folks prior to
this discussion, it seemed reasonable.

Your proposal uses an aggressive 1-week gap between both, which is quite
the jump from the previous 3 weeks.

Perhaps someone with more direct experience in the recent can chime in
here. Both for the reasoning for the extension from 1w to 3w in the last 2
releases, and how they feel about reducing this range.

> 4. On the other hand, we usually have a full two weeks from the feature
freeze deadline to the code freeze but with the given schedule there would
only be a week and a half. Given how important this period is for testing
and stabilizing the release, and how vital this is for uncovering blockers
that would have delayed the release deadline, I really think we should
maintain the two-week gap (at a minimum)

This is a fair point. At the end of the day, we have to take time out of
either one of the 3 ranges (now - KF; KF-FF; FF-CF;)
*It sounds fair to me to take out half a week from KF-FF and add it to
FF-CF*. e.g:
- KF=Nov 18 (Sat)
- FF=Dec 6 (Wed) 2.5w after
- CF=Dec 20 (Wed) 2w after

How do others feel about this?

> Just to throw a suggestion out there, if we want to avoid running into
the winter holidays while still making up for slipping of recent releases,
what about something like this: ...

Looking at the last 2 releases, they both had a full month between KIP
Freeze and Code Freeze to finish contributions. Your proposal goes back to
a more aggressive 3 weeks e2e time. All else equal, if the release date is
to be kept as early January, I would prefer to opt for the more
accommodative 4-week period.

> Note that historically, we have set all the deadlines on a Wednesday and
when in doubt erred on the side of an earlier deadline ... We can, and
often have, allowed things to come in late between the Wednesday freeze
deadline and the following Friday, but only on a case-by-case basis.

This makes sense to me. The proposal I put above puts the two critical
dates (FF & CF) on Wed to allow for this flexibility in case it's needed.

Best,
Stanislav


On Tue, Oct 24, 2023 at 12:40 AM Sophie Blee-Goldman 
wrote:

> Actually I have a few questions about the schedule:
>
> 1. Why is the KIP freeze deadline on a Saturday? Traditionally this has
> been on a Wednesday, which is nice because it gives people until Monday to
> kick off the vote and give people a full 3 working days to review and vote
> on it. Also,
> 2. Why are the subsequent deadlines on different days of the week? Usually
> we aim to have the freeze deadlines separated by an integer number of
> weeks. Besides just being a consequence of the typical 1/2 week separation
> between freeze dates, this makes it easy for everyone to remember when the
> next deadline is so they can make sure to get everything in on time. I
> worry that varying this will catch people off guard.
> 3. Is there a particular reason 

Re: Apache Kafka 3.7.0 Release

[Sophie Blee-Goldman]

Actually I have a few questions about the schedule:

1. Why is the KIP freeze deadline on a Saturday? Traditionally this has
been on a Wednesday, which is nice because it gives people until Monday to
kick off the vote and give people a full 3 working days to review and vote
on it. Also,
2. Why are the subsequent deadlines on different days of the week? Usually
we aim to have the freeze deadlines separated by an integer number of
weeks. Besides just being a consequence of the typical 1/2 week separation
between freeze dates, this makes it easy for everyone to remember when the
next deadline is so they can make sure to get everything in on time. I
worry that varying this will catch people off guard.
3. Is there a particular reason for having the feature freeze almost a full
3 weeks from the KIP freeze? I understand moving the KIP freeze deadline up
to account for recent release delays, but aren't we wasting some of that
gained time by having 3 weeks between the KIP and feature freeze (which are
usually separated by just a single week)?
4. On the other hand, we usually have a full two weeks from the feature
freeze deadline to the code freeze but with the given schedule there would
only be a week and a half. Given how important this period is for testing
and stabilizing the release, and how vital this is for uncovering blockers
that would have delayed the release deadline, I really think we should
maintain the two-week gap (at a minimum)

Note that historically, we have set all the deadlines on a Wednesday and
when in doubt erred on the side of an earlier deadline, to encourage folks
to get their work completed and stabilized as soon as possible. We can, and
often have, allowed things to come in late between the Wednesday freeze
deadline and the following Friday, but only on a case-by-case basis. This
way the RM has the flexibility to determine what to allow and when, if need
be, while still having everyone aim for the established deadlines.

Just to throw a suggestion out there, if we want to avoid running into the
winter holidays while still making up for slipping of recent releases, what
about something like this:

KIP Freeze: Nov 22nd
Feature Freeze: Nov 29th
Code Freeze: Dec 13th

We can keep the release target as Jan 3rd or move it up to Dec 27th.
Personally, I would just aim to have it as Dec 27th but keep the stated
target as Jan 3rd, to account for unexpected blockers/delays and time away
during the winter holidays

Thoughts?

On Mon, Oct 23, 2023 at 3:14 PM Sophie Blee-Goldman 
wrote:

> Can you add the 3.7 plan to the release schedule page?
>
> (this -->
> https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan)
>
> Thanks!
>
> On Sun, Oct 15, 2023 at 2:27 AM Stanislav Kozlovski
>  wrote:
>
>> Hey Chris,
>>
>> Thanks for the catch! It was indeed copied and I wasn't sure what to make
>> of the bullet point, so I kept it. What you say makes sense - I removed
>> it.
>>
>> I also added KIP-976!
>>
>> Cheers!
>>
>> On Sat, Oct 14, 2023 at 9:35 PM Chris Egerton 
>> wrote:
>>
>> > Hi Stanislav,
>> >
>> > Thanks for putting this together! I think the "Ensure that release
>> > candidates include artifacts for the new Connect test-plugins module"
>> > section (which I'm guessing was copied over from the 3.6.0 release
>> plan?)
>> > can be removed; we made sure that those artifacts were present for
>> 3.6.0,
>> > and I don't anticipate any changes that would make them likelier to be
>> > accidentally dropped in subsequent releases than any other Maven
>> artifacts
>> > that we publish.
>> >
>> > Also, can we add KIP-976 (
>> >
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-976%3A+Cluster-wide+dynamic+log+adjustment+for+Kafka+Connect
>> > )
>> > to the release plan? The vote thread for it passed last week and I've
>> > published a complete PR (https://github.com/apache/kafka/pull/14538),
>> so
>> > it
>> > shouldn't be too difficult to get things merged in time for 3.7.0.
>> >
>> > Cheers,
>> >
>> > Chris
>> >
>> > On Sat, Oct 14, 2023 at 3:26 PM Stanislav Kozlovski
>> >  wrote:
>> >
>> > > Thanks for letting me drive it, folks.
>> > >
>> > > I've created the 3.7.0 release page here:
>> > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
>> > > It outlines the key milestones and important dates for the release.
>> > >
>> > > In particular, since the last two releases slipped their originally
>> > > targeted release date by taking an average of 46 days after code
>> freeze
>> > (as
>> > > opposed to the minimum which is 14 days), I pulled the dates forward
>> to
>> > try
>> > > and catch up with the original release schedule.
>> > > You can refer to the last release during the Christmas holiday season
>> -
>> > > Apache
>> > > Kafka 3.4
>> > > 
>> -
>> > > to
>> > > see sample dates.
>> > >
>> > > The currently proposed dates are:
>> > >
>> > > *KIP Freeze - 18th November *(Saturday)
>> > > 

Re: Apache Kafka 3.7.0 Release

[Sophie Blee-Goldman]

Can you add the 3.7 plan to the release schedule page?

(this -->
https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan)

Thanks!

On Sun, Oct 15, 2023 at 2:27 AM Stanislav Kozlovski
 wrote:

> Hey Chris,
>
> Thanks for the catch! It was indeed copied and I wasn't sure what to make
> of the bullet point, so I kept it. What you say makes sense - I removed it.
>
> I also added KIP-976!
>
> Cheers!
>
> On Sat, Oct 14, 2023 at 9:35 PM Chris Egerton 
> wrote:
>
> > Hi Stanislav,
> >
> > Thanks for putting this together! I think the "Ensure that release
> > candidates include artifacts for the new Connect test-plugins module"
> > section (which I'm guessing was copied over from the 3.6.0 release plan?)
> > can be removed; we made sure that those artifacts were present for 3.6.0,
> > and I don't anticipate any changes that would make them likelier to be
> > accidentally dropped in subsequent releases than any other Maven
> artifacts
> > that we publish.
> >
> > Also, can we add KIP-976 (
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-976%3A+Cluster-wide+dynamic+log+adjustment+for+Kafka+Connect
> > )
> > to the release plan? The vote thread for it passed last week and I've
> > published a complete PR (https://github.com/apache/kafka/pull/14538), so
> > it
> > shouldn't be too difficult to get things merged in time for 3.7.0.
> >
> > Cheers,
> >
> > Chris
> >
> > On Sat, Oct 14, 2023 at 3:26 PM Stanislav Kozlovski
> >  wrote:
> >
> > > Thanks for letting me drive it, folks.
> > >
> > > I've created the 3.7.0 release page here:
> > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> > > It outlines the key milestones and important dates for the release.
> > >
> > > In particular, since the last two releases slipped their originally
> > > targeted release date by taking an average of 46 days after code freeze
> > (as
> > > opposed to the minimum which is 14 days), I pulled the dates forward to
> > try
> > > and catch up with the original release schedule.
> > > You can refer to the last release during the Christmas holiday season -
> > > Apache
> > > Kafka 3.4
> > > 
> -
> > > to
> > > see sample dates.
> > >
> > > The currently proposed dates are:
> > >
> > > *KIP Freeze - 18th November *(Saturday)
> > > *This is 1 month and four days from now - rather short - but I'm afraid
> > is
> > > the only lever that's easy to pull forward.*
> > > As usual, a KIP must be accepted by this date in order to be considered
> > for
> > > this release. Note, any KIP that may not be implemented in a week, or
> > that
> > > might destabilize the release, should be deferred.
> > >
> > > *Feature Freeze - 8th December* (Friday)
> > > *This follows 3 weeks after the KIP Freeze, as has been the case in our
> > > latest releases.*
> > > By this point, we want all major features to be merged & us to be
> working
> > > on stabilisation. Minor features should have PRs, the release branch
> > should
> > > be cut; anything not in this state will be automatically moved to the
> > next
> > > release in JIRA
> > >
> > > *Code Freeze - 20th December* (Wednesday)
> > >
> > > *Critically, this is before the holiday season and ends in the middle
> of
> > > the week, to give contributors more time and flexibility to address any
> > > last-minute without eating into the time people usually take holidays.
> It
> > > comes 12 days after the Feature Freeze.This is two days shorter than
> the
> > > usual code freeze window. I don't have a strong opinion and am open to
> > > extend it to Friday, or trade off a day/two with the KF<->FF date
> range.*
> > >
> > > *Release -* *after January 3rd*.
> > > *It comes after a minimum of two weeks of stabilization, so the
> earliest
> > we
> > > can start releasing is January 3rd. We will move as fast as we can and
> > aim
> > > completing it as early in January as possible.*
> > >
> > > As for the initially-populated KIPs in the release plan, I did the
> > > following:
> > >
> > > I kept 4 KIPs that were mentioned in 3.6, saying they would have minor
> > > parts finished in 3.7 (as the major ones went out in 3.6)
> > > - KIP-405 Tiered Storage mentioned a major part went out with 3.6 and
> the
> > > remainder will come with 3.7
> > > - KIP-890 mentioned Part 1 shipped in 3.6. I am assuming the remainder
> > will
> > > come in 3.7, and have contacted the author to confirm.
> > > - KIP-926 was partially implemented in 3.6. I am assuming the remainder
> > > will come in 3.7, and have contacted the author to confirm.
> > > - KIP-938 mentioned that the majority was completed and a small
> remainder
> > > re: ForwardingManager metrics will come in 3.7. I have contacted the
> > author
> > > to confirm.
> > >
> > > I then went through the JIRA filter which looks at open issues with a
> Fix
> > > Version of 3.7 and added KIP-770, KIP-858, and KIP-980.
> > > I also found a fair amount of JIRAs that were 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Hey Chris,

Thanks for the catch! It was indeed copied and I wasn't sure what to make
of the bullet point, so I kept it. What you say makes sense - I removed it.

I also added KIP-976!

Cheers!

On Sat, Oct 14, 2023 at 9:35 PM Chris Egerton 
wrote:

> Hi Stanislav,
>
> Thanks for putting this together! I think the "Ensure that release
> candidates include artifacts for the new Connect test-plugins module"
> section (which I'm guessing was copied over from the 3.6.0 release plan?)
> can be removed; we made sure that those artifacts were present for 3.6.0,
> and I don't anticipate any changes that would make them likelier to be
> accidentally dropped in subsequent releases than any other Maven artifacts
> that we publish.
>
> Also, can we add KIP-976 (
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-976%3A+Cluster-wide+dynamic+log+adjustment+for+Kafka+Connect
> )
> to the release plan? The vote thread for it passed last week and I've
> published a complete PR (https://github.com/apache/kafka/pull/14538), so
> it
> shouldn't be too difficult to get things merged in time for 3.7.0.
>
> Cheers,
>
> Chris
>
> On Sat, Oct 14, 2023 at 3:26 PM Stanislav Kozlovski
>  wrote:
>
> > Thanks for letting me drive it, folks.
> >
> > I've created the 3.7.0 release page here:
> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> > It outlines the key milestones and important dates for the release.
> >
> > In particular, since the last two releases slipped their originally
> > targeted release date by taking an average of 46 days after code freeze
> (as
> > opposed to the minimum which is 14 days), I pulled the dates forward to
> try
> > and catch up with the original release schedule.
> > You can refer to the last release during the Christmas holiday season -
> > Apache
> > Kafka 3.4
> >  -
> > to
> > see sample dates.
> >
> > The currently proposed dates are:
> >
> > *KIP Freeze - 18th November *(Saturday)
> > *This is 1 month and four days from now - rather short - but I'm afraid
> is
> > the only lever that's easy to pull forward.*
> > As usual, a KIP must be accepted by this date in order to be considered
> for
> > this release. Note, any KIP that may not be implemented in a week, or
> that
> > might destabilize the release, should be deferred.
> >
> > *Feature Freeze - 8th December* (Friday)
> > *This follows 3 weeks after the KIP Freeze, as has been the case in our
> > latest releases.*
> > By this point, we want all major features to be merged & us to be working
> > on stabilisation. Minor features should have PRs, the release branch
> should
> > be cut; anything not in this state will be automatically moved to the
> next
> > release in JIRA
> >
> > *Code Freeze - 20th December* (Wednesday)
> >
> > *Critically, this is before the holiday season and ends in the middle of
> > the week, to give contributors more time and flexibility to address any
> > last-minute without eating into the time people usually take holidays. It
> > comes 12 days after the Feature Freeze.This is two days shorter than the
> > usual code freeze window. I don't have a strong opinion and am open to
> > extend it to Friday, or trade off a day/two with the KF<->FF date range.*
> >
> > *Release -* *after January 3rd*.
> > *It comes after a minimum of two weeks of stabilization, so the earliest
> we
> > can start releasing is January 3rd. We will move as fast as we can and
> aim
> > completing it as early in January as possible.*
> >
> > As for the initially-populated KIPs in the release plan, I did the
> > following:
> >
> > I kept 4 KIPs that were mentioned in 3.6, saying they would have minor
> > parts finished in 3.7 (as the major ones went out in 3.6)
> > - KIP-405 Tiered Storage mentioned a major part went out with 3.6 and the
> > remainder will come with 3.7
> > - KIP-890 mentioned Part 1 shipped in 3.6. I am assuming the remainder
> will
> > come in 3.7, and have contacted the author to confirm.
> > - KIP-926 was partially implemented in 3.6. I am assuming the remainder
> > will come in 3.7, and have contacted the author to confirm.
> > - KIP-938 mentioned that the majority was completed and a small remainder
> > re: ForwardingManager metrics will come in 3.7. I have contacted the
> author
> > to confirm.
> >
> > I then went through the JIRA filter which looks at open issues with a Fix
> > Version of 3.7 and added KIP-770, KIP-858, and KIP-980.
> > I also found a fair amount of JIRAs that were targeting the 3.7 release
> but
> > consecutively had no activity on them for the past few releases. For most
> > of those, I pinged the author and explicitly asked if it's going to aim
> to
> > make it to 3.7. I have not included those here and will not until I hear
> > confirmation.
> >
> > Please review the plan and provide any additional information or updates
> > regarding KIPs that target this release version (3.7).
> > If you have authored any 

Re: Apache Kafka 3.7.0 Release

[Chris Egerton]

Hi Stanislav,

Thanks for putting this together! I think the "Ensure that release
candidates include artifacts for the new Connect test-plugins module"
section (which I'm guessing was copied over from the 3.6.0 release plan?)
can be removed; we made sure that those artifacts were present for 3.6.0,
and I don't anticipate any changes that would make them likelier to be
accidentally dropped in subsequent releases than any other Maven artifacts
that we publish.

Also, can we add KIP-976 (
https://cwiki.apache.org/confluence/display/KAFKA/KIP-976%3A+Cluster-wide+dynamic+log+adjustment+for+Kafka+Connect)
to the release plan? The vote thread for it passed last week and I've
published a complete PR (https://github.com/apache/kafka/pull/14538), so it
shouldn't be too difficult to get things merged in time for 3.7.0.

Cheers,

Chris

On Sat, Oct 14, 2023 at 3:26 PM Stanislav Kozlovski
 wrote:

> Thanks for letting me drive it, folks.
>
> I've created the 3.7.0 release page here:
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> It outlines the key milestones and important dates for the release.
>
> In particular, since the last two releases slipped their originally
> targeted release date by taking an average of 46 days after code freeze (as
> opposed to the minimum which is 14 days), I pulled the dates forward to try
> and catch up with the original release schedule.
> You can refer to the last release during the Christmas holiday season -
> Apache
> Kafka 3.4
>  -
> to
> see sample dates.
>
> The currently proposed dates are:
>
> *KIP Freeze - 18th November *(Saturday)
> *This is 1 month and four days from now - rather short - but I'm afraid is
> the only lever that's easy to pull forward.*
> As usual, a KIP must be accepted by this date in order to be considered for
> this release. Note, any KIP that may not be implemented in a week, or that
> might destabilize the release, should be deferred.
>
> *Feature Freeze - 8th December* (Friday)
> *This follows 3 weeks after the KIP Freeze, as has been the case in our
> latest releases.*
> By this point, we want all major features to be merged & us to be working
> on stabilisation. Minor features should have PRs, the release branch should
> be cut; anything not in this state will be automatically moved to the next
> release in JIRA
>
> *Code Freeze - 20th December* (Wednesday)
>
> *Critically, this is before the holiday season and ends in the middle of
> the week, to give contributors more time and flexibility to address any
> last-minute without eating into the time people usually take holidays. It
> comes 12 days after the Feature Freeze.This is two days shorter than the
> usual code freeze window. I don't have a strong opinion and am open to
> extend it to Friday, or trade off a day/two with the KF<->FF date range.*
>
> *Release -* *after January 3rd*.
> *It comes after a minimum of two weeks of stabilization, so the earliest we
> can start releasing is January 3rd. We will move as fast as we can and aim
> completing it as early in January as possible.*
>
> As for the initially-populated KIPs in the release plan, I did the
> following:
>
> I kept 4 KIPs that were mentioned in 3.6, saying they would have minor
> parts finished in 3.7 (as the major ones went out in 3.6)
> - KIP-405 Tiered Storage mentioned a major part went out with 3.6 and the
> remainder will come with 3.7
> - KIP-890 mentioned Part 1 shipped in 3.6. I am assuming the remainder will
> come in 3.7, and have contacted the author to confirm.
> - KIP-926 was partially implemented in 3.6. I am assuming the remainder
> will come in 3.7, and have contacted the author to confirm.
> - KIP-938 mentioned that the majority was completed and a small remainder
> re: ForwardingManager metrics will come in 3.7. I have contacted the author
> to confirm.
>
> I then went through the JIRA filter which looks at open issues with a Fix
> Version of 3.7 and added KIP-770, KIP-858, and KIP-980.
> I also found a fair amount of JIRAs that were targeting the 3.7 release but
> consecutively had no activity on them for the past few releases. For most
> of those, I pinged the author and explicitly asked if it's going to aim to
> make it to 3.7. I have not included those here and will not until I hear
> confirmation.
>
> Please review the plan and provide any additional information or updates
> regarding KIPs that target this release version (3.7).
> If you have authored any KIPs that have an inaccurate status in the list,
> or are not in the list and should be, or are in the list and should not be
> - please inform me in this thread so that I can keep the document accurate
> and up to date.
>
> Excited to get this release going!
>
> All the best,
> Stanislav
>
> On Tue, Oct 10, 2023 at 9:12 AM Bruno Cadonna  wrote:
>
> > Thanks Stan!
> >
> > +1
> >
> > Best,
> > Bruno
> >
> > On 10/10/23 7:24 AM, Luke Chen wrote:
> > > Thanks Stanislav!
> 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski]

Thanks for letting me drive it, folks.

I've created the 3.7.0 release page here:
https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
It outlines the key milestones and important dates for the release.

In particular, since the last two releases slipped their originally
targeted release date by taking an average of 46 days after code freeze (as
opposed to the minimum which is 14 days), I pulled the dates forward to try
and catch up with the original release schedule.
You can refer to the last release during the Christmas holiday season - Apache
Kafka 3.4
 - to
see sample dates.

The currently proposed dates are:

*KIP Freeze - 18th November *(Saturday)
*This is 1 month and four days from now - rather short - but I'm afraid is
the only lever that's easy to pull forward.*
As usual, a KIP must be accepted by this date in order to be considered for
this release. Note, any KIP that may not be implemented in a week, or that
might destabilize the release, should be deferred.

*Feature Freeze - 8th December* (Friday)
*This follows 3 weeks after the KIP Freeze, as has been the case in our
latest releases.*
By this point, we want all major features to be merged & us to be working
on stabilisation. Minor features should have PRs, the release branch should
be cut; anything not in this state will be automatically moved to the next
release in JIRA

*Code Freeze - 20th December* (Wednesday)

*Critically, this is before the holiday season and ends in the middle of
the week, to give contributors more time and flexibility to address any
last-minute without eating into the time people usually take holidays. It
comes 12 days after the Feature Freeze.This is two days shorter than the
usual code freeze window. I don't have a strong opinion and am open to
extend it to Friday, or trade off a day/two with the KF<->FF date range.*

*Release -* *after January 3rd*.
*It comes after a minimum of two weeks of stabilization, so the earliest we
can start releasing is January 3rd. We will move as fast as we can and aim
completing it as early in January as possible.*

As for the initially-populated KIPs in the release plan, I did the
following:

I kept 4 KIPs that were mentioned in 3.6, saying they would have minor
parts finished in 3.7 (as the major ones went out in 3.6)
- KIP-405 Tiered Storage mentioned a major part went out with 3.6 and the
remainder will come with 3.7
- KIP-890 mentioned Part 1 shipped in 3.6. I am assuming the remainder will
come in 3.7, and have contacted the author to confirm.
- KIP-926 was partially implemented in 3.6. I am assuming the remainder
will come in 3.7, and have contacted the author to confirm.
- KIP-938 mentioned that the majority was completed and a small remainder
re: ForwardingManager metrics will come in 3.7. I have contacted the author
to confirm.

I then went through the JIRA filter which looks at open issues with a Fix
Version of 3.7 and added KIP-770, KIP-858, and KIP-980.
I also found a fair amount of JIRAs that were targeting the 3.7 release but
consecutively had no activity on them for the past few releases. For most
of those, I pinged the author and explicitly asked if it's going to aim to
make it to 3.7. I have not included those here and will not until I hear
confirmation.

Please review the plan and provide any additional information or updates
regarding KIPs that target this release version (3.7).
If you have authored any KIPs that have an inaccurate status in the list,
or are not in the list and should be, or are in the list and should not be
- please inform me in this thread so that I can keep the document accurate
and up to date.

Excited to get this release going!

All the best,
Stanislav

On Tue, Oct 10, 2023 at 9:12 AM Bruno Cadonna  wrote:

> Thanks Stan!
>
> +1
>
> Best,
> Bruno
>
> On 10/10/23 7:24 AM, Luke Chen wrote:
> > Thanks Stanislav!
> >
> > On Tue, Oct 10, 2023 at 3:05 AM Josep Prat 
> > wrote:
> >
> >> Thanks Stanislav!
> >>
> >> ———
> >> Josep Prat
> >>
> >> Aiven Deutschland GmbH
> >>
> >> Alexanderufer 3-7, 10117 Berlin
> >>
> >> Amtsgericht Charlottenburg, HRB 209739 B
> >>
> >> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >>
> >> m: +491715557497
> >>
> >> w: aiven.io
> >>
> >> e: josep.p...@aiven.io
> >>
> >> On Mon, Oct 9, 2023, 20:05 Chris Egerton 
> wrote:
> >>
> >>> +1, thanks Stanislav!
> >>>
> >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck  wrote:
> >>>
>  +1
> 
>  Thanks, Stanislav!
> 
>  -Bill
> 
>  On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma  wrote:
> 
> > Thanks for volunteering Stanislav!
> >
> > Ismael
> >
> > On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> >  wrote:
> >
> >> Hey all!
> >>
> >> I would like to volunteer to be the release manager driving the
> >> next
> >> release - Apache Kafka *3.7.0*.
> >>
> >> If there are no objections, I will start and share a release 

Re: Apache Kafka 3.7.0 Release

[Bruno Cadonna]

Thanks Stan!

+1

Best,
Bruno

On 10/10/23 7:24 AM, Luke Chen wrote:

Thanks Stanislav!

On Tue, Oct 10, 2023 at 3:05 AM Josep Prat 
wrote:


Thanks Stanislav!

———
Josep Prat

Aiven Deutschland GmbH

Alexanderufer 3-7, 10117 Berlin

Amtsgericht Charlottenburg, HRB 209739 B

Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen

m: +491715557497

w: aiven.io

e: josep.p...@aiven.io

On Mon, Oct 9, 2023, 20:05 Chris Egerton  wrote:


+1, thanks Stanislav!

On Mon, Oct 9, 2023, 14:02 Bill Bejeck  wrote:


+1

Thanks, Stanislav!

-Bill

On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma  wrote:


Thanks for volunteering Stanislav!

Ismael

On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
 wrote:


Hey all!

I would like to volunteer to be the release manager driving the

next

release - Apache Kafka *3.7.0*.

If there are no objections, I will start and share a release plan

soon

enough!

Cheers,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Luke Chen]

Thanks Stanislav!

On Tue, Oct 10, 2023 at 3:05 AM Josep Prat 
wrote:

> Thanks Stanislav!
>
> ———
> Josep Prat
>
> Aiven Deutschland GmbH
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> m: +491715557497
>
> w: aiven.io
>
> e: josep.p...@aiven.io
>
> On Mon, Oct 9, 2023, 20:05 Chris Egerton  wrote:
>
> > +1, thanks Stanislav!
> >
> > On Mon, Oct 9, 2023, 14:02 Bill Bejeck  wrote:
> >
> > > +1
> > >
> > > Thanks, Stanislav!
> > >
> > > -Bill
> > >
> > > On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma  wrote:
> > >
> > > > Thanks for volunteering Stanislav!
> > > >
> > > > Ismael
> > > >
> > > > On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > >  wrote:
> > > >
> > > > > Hey all!
> > > > >
> > > > > I would like to volunteer to be the release manager driving the
> next
> > > > > release - Apache Kafka *3.7.0*.
> > > > >
> > > > > If there are no objections, I will start and share a release plan
> > soon
> > > > > enough!
> > > > >
> > > > > Cheers,
> > > > > Stanislav
> > > > >
> > > >
> > >
> >
>

Re: Apache Kafka 3.7.0 Release

[Josep Prat]

Thanks Stanislav!

———
Josep Prat

Aiven Deutschland GmbH

Alexanderufer 3-7, 10117 Berlin

Amtsgericht Charlottenburg, HRB 209739 B

Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen

m: +491715557497

w: aiven.io

e: josep.p...@aiven.io

On Mon, Oct 9, 2023, 20:05 Chris Egerton  wrote:

> +1, thanks Stanislav!
>
> On Mon, Oct 9, 2023, 14:02 Bill Bejeck  wrote:
>
> > +1
> >
> > Thanks, Stanislav!
> >
> > -Bill
> >
> > On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma  wrote:
> >
> > > Thanks for volunteering Stanislav!
> > >
> > > Ismael
> > >
> > > On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > >  wrote:
> > >
> > > > Hey all!
> > > >
> > > > I would like to volunteer to be the release manager driving the next
> > > > release - Apache Kafka *3.7.0*.
> > > >
> > > > If there are no objections, I will start and share a release plan
> soon
> > > > enough!
> > > >
> > > > Cheers,
> > > > Stanislav
> > > >
> > >
> >
>

Re: Apache Kafka 3.7.0 Release

[Chris Egerton]

+1, thanks Stanislav!

On Mon, Oct 9, 2023, 14:02 Bill Bejeck  wrote:

> +1
>
> Thanks, Stanislav!
>
> -Bill
>
> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma  wrote:
>
> > Thanks for volunteering Stanislav!
> >
> > Ismael
> >
> > On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> >  wrote:
> >
> > > Hey all!
> > >
> > > I would like to volunteer to be the release manager driving the next
> > > release - Apache Kafka *3.7.0*.
> > >
> > > If there are no objections, I will start and share a release plan soon
> > > enough!
> > >
> > > Cheers,
> > > Stanislav
> > >
> >
>

Re: Apache Kafka 3.7.0 Release

[Bill Bejeck]

+1

Thanks, Stanislav!

-Bill

On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma  wrote:

> Thanks for volunteering Stanislav!
>
> Ismael
>
> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
>  wrote:
>
> > Hey all!
> >
> > I would like to volunteer to be the release manager driving the next
> > release - Apache Kafka *3.7.0*.
> >
> > If there are no objections, I will start and share a release plan soon
> > enough!
> >
> > Cheers,
> > Stanislav
> >
>

Re: Apache Kafka 3.7.0 Release

[Ismael Juma]

Thanks for volunteering Stanislav!

Ismael

On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
 wrote:

> Hey all!
>
> I would like to volunteer to be the release manager driving the next
> release - Apache Kafka *3.7.0*.
>
> If there are no objections, I will start and share a release plan soon
> enough!
>
> Cheers,
> Stanislav
>