Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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

[Justine Olshan <jo...@confluent.io.INVALID>]

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

On Thu, Nov 2, 2023 at 7:02 AM Stanislav Kozlovski
<st...@confluent.io.invalid> 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 <
> sophie@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
> > <st...@confluent.io.invalid> 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 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 <
> > > sophie@responsive.dev>
> > > 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 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 <
> > > sophie@responsive.dev
> > > > >
> > > > 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
> > > > > <st...@confluent.io.invalid> 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 <
> > > fearthecellos@gmail.com>
> > > > >> 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
> > > > >> > <st...@confluent.io.invalid> 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
> > > > >> > > <
> > > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> >
> > > > >> -
> > > > >> > > 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 <
> > cadonna@apache.org
> > > >
> > > > >> > 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
> > > > >> > <josep.prat@aiven.io.invalid
> > > > >> > > >
> > > > >> > > > > 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.prat@aiven.io
> > > > >> > > > >>
> > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > > >> fearthecellos@gmail.com>
> > > > >> > > > wrote:
> > > > >> > > > >>
> > > > >> > > > >>> +1, thanks Stanislav!
> > > > >> > > > >>>
> > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
> bbejeck@gmail.com
> > >
> > > > >> wrote:
> > > > >> > > > >>>
> > > > >> > > > >>>> +1
> > > > >> > > > >>>>
> > > > >> > > > >>>> Thanks, Stanislav!
> > > > >> > > > >>>>
> > > > >> > > > >>>> -Bill
> > > > >> > > > >>>>
> > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > > > me@ismaeljuma.com>
> > > > >> > > wrote:
> > > > >> > > > >>>>
> > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > > >> > > > >>>>>
> > > > >> > > > >>>>> Ismael
> > > > >> > > > >>>>>
> > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > > > >> > > > >>>>>>
> > > > >> > > > >>>>>
> > > > >> > > > >>>>
> > > > >> > > > >>>
> > > > >> > > > >>
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> > > --
> > > > >> > > Best,
> > > > >> > > Stanislav
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Best,
> > > > >> Stanislav
> > > > >>
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best,
> > > Stanislav
> > >
> >
>
>
> --
> Best,
> Stanislav
>

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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
<lb...@confluent.io.invalid> 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 <ap...@gmail.com>
> 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
> > <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
> > > > <pp...@confluent.io.invalid> 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 <lb...@confluent.io.INVALID>]

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 <ap...@gmail.com> 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
> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
> > > <pp...@confluent.io.invalid> 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 <da...@gmail.com>]

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 <me...@ismaeljuma.com> 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 <cm...@apache.org> 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
> > >> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
> > >>> > <pp...@confluent.io.invalid> 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

[Mayank Shekhar Narula <ma...@gmail.com>]

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 <https://github.com/apache/kafka/pull/15323> 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
<st...@confluent.io.invalid> 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.narula@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
> > <https://lists.apache.org/thread/otxt5wr7cj4qx4v3zg05gclry0vrdvh8>.
> >
> >
> > On Fri, Feb 2, 2024 at 3:58 PM Divij Vaidya <di...@gmail.com>
> > 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 <sh...@gmail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > There is a bug KAFKA-16101
> > > > <https://issues.apache.org/jira/browse/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
> > > > <st...@confluent.io.invalid> 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 <cm...@apache.org>
> > > > 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 <
> > cmccabe@apache.org
> > > >
> > > > > > 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 <
> > > cmccabe@apache.org
> > > > >
> > > > > > 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
> > > > > > >>>> >> >> <https://github.com/apache/kafka/pull/15127> 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 <
> > > > > > cmccabe@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
> > > > > > >>>> >> >>> > <pp...@confluent.io.invalid> 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
> > > > >
> > > >
> > >
> >
> >
> > --
> > Regards,
> > Mayank Shekhar Narula
> >
>
>
> --
> Best,
> Stanislav
>


-- 
Regards,
Mayank Shekhar Narula

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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.narula@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
> <https://lists.apache.org/thread/otxt5wr7cj4qx4v3zg05gclry0vrdvh8>.
>
>
> On Fri, Feb 2, 2024 at 3:58 PM Divij Vaidya <di...@gmail.com>
> 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 <sh...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > There is a bug KAFKA-16101
> > > <https://issues.apache.org/jira/browse/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
> > > <st...@confluent.io.invalid> 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 <cm...@apache.org>
> > > 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 <
> cmccabe@apache.org
> > >
> > > > > 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 <
> > cmccabe@apache.org
> > > >
> > > > > 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
> > > > > >>>> >> >> <https://github.com/apache/kafka/pull/15127> 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 <
> > > > > cmccabe@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
> > > > > >>>> >> >>> > <pp...@confluent.io.invalid> 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
> > > >
> > >
> >
>
>
> --
> Regards,
> Mayank Shekhar Narula
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Mayank Shekhar Narula <ma...@gmail.com>]

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
<https://lists.apache.org/thread/otxt5wr7cj4qx4v3zg05gclry0vrdvh8>.


On Fri, Feb 2, 2024 at 3:58 PM Divij Vaidya <di...@gmail.com> 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 <sh...@gmail.com> wrote:
>
> > Hi all,
> >
> > There is a bug KAFKA-16101
> > <https://issues.apache.org/jira/browse/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
> > <st...@confluent.io.invalid> 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 <cm...@apache.org>
> > 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 <cmccabe@apache.org
> >
> > > > 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 <
> cmccabe@apache.org
> > >
> > > > 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
> > > > >>>> >> >> <https://github.com/apache/kafka/pull/15127> 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 <
> > > > cmccabe@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
> > > > >>>> >> >>> > <pp...@confluent.io.invalid> 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
> > >
> >
>


-- 
Regards,
Mayank Shekhar Narula

Re: Apache Kafka 3.7.0 Release

[Divij Vaidya <di...@gmail.com>]

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 <sh...@gmail.com> wrote:

> Hi all,
>
> There is a bug KAFKA-16101
> <https://issues.apache.org/jira/browse/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
> <st...@confluent.io.invalid> 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 <cm...@apache.org>
> 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 <cm...@apache.org>
> > > 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 <cmccabe@apache.org
> >
> > > 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
> > > >>>> >> >> <https://github.com/apache/kafka/pull/15127> 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 <
> > > cmccabe@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
> > > >>>> >> >>> > <pp...@confluent.io.invalid> 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

[Luke Chen <sh...@gmail.com>]

Hi all,

There is a bug KAFKA-16101
<https://issues.apache.org/jira/browse/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
<st...@confluent.io.invalid> 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 <cm...@apache.org> 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 <cm...@apache.org>
> > 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 <cm...@apache.org>
> > 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
> > >>>> >> >> <https://github.com/apache/kafka/pull/15127> 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 <
> > cmccabe@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
> > >>>> >> >>> > <pp...@confluent.io.invalid> 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

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <cm...@apache.org> 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 <cm...@apache.org>
> 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 <cm...@apache.org>
> 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
> >>>> >> >> <https://github.com/apache/kafka/pull/15127> 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 <
> cmccabe@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
> >>>> >> >>> > <pp...@confluent.io.invalid> 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

[Colin McCabe <cm...@apache.org>]

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 <cm...@apache.org> 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 <cm...@apache.org> 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
>>>> >> >> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
>>>> >> >>> > <pp...@confluent.io.invalid> 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 <cm...@apache.org>]

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 <cm...@apache.org> 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 <cm...@apache.org> 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
>>> >> >> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
>>> >> >>> > <pp...@confluent.io.invalid> 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 <cm...@apache.org>]

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 <cm...@apache.org> 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 <cm...@apache.org> 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
>> >> >> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
>> >> >>> > <pp...@confluent.io.invalid> 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 <me...@ismaeljuma.com>]

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 <cm...@apache.org> 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 <cm...@apache.org> 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
> >> >> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
> >> >>> > <pp...@confluent.io.invalid> 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 <cm...@apache.org>]

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 <cm...@apache.org> 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
>> >> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
>> >>> > <pp...@confluent.io.invalid> 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 <me...@ismaeljuma.com>]

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 <cm...@apache.org> 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
> >> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
> >>> > <pp...@confluent.io.invalid> 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 <cm...@apache.org>]

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
>> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
>>> > <pp...@confluent.io.invalid> 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 <cm...@apache.org>]

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
> <https://github.com/apache/kafka/pull/15127> 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 <cm...@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
>> > <pp...@confluent.io.invalid> 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 <ap...@gmail.com>]

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
<https://github.com/apache/kafka/pull/15127> 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 <cm...@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
> > <pp...@confluent.io.invalid> 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 <cm...@apache.org>]

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
> <pp...@confluent.io.invalid> 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 <st...@confluent.io.INVALID>]

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
<pp...@confluent.io.invalid> 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 <pp...@confluent.io.INVALID>]

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" <mj...@apache.org>]

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 <ap...@gmail.com>
> 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 <mj...@apache.org> 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 <al...@gmail.com>
>>> 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
>>>>> <st...@confluent.io.invalid> 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 <
>>> apoorvmittal10@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, 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 <cm...@apache.org>
>>>>> 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 <me...@ismaeljuma.com>
>>>>>> 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
>>>>>>>>>> <vi...@cloudera.com.invalid> 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
>>>>>>>>>>> <st...@confluent.io.invalid> 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
>>>>>>>>>>>> <
>>>>>> https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh
>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
>>>>>>>>>>>> stanislav@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 <
>>>>>>>>>>>>> stanislav@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
>>>>>>>>>>>>>> <
>>>>>>>>
>> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
>>>>>>>>>>>> .
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for your contributions once again!
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>> Stan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
>>>>>>>> nick.telford@gmail.com>
>>>>>>>>>>>>>> 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.narula@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
>>>>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 <
>>>>>>>>>>>>>>>> sophie@responsive.dev>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Looks great, thank you! +1
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 10:21 AM David Jacot
>>>>>>>>>>>>>>>> <djacot@confluent.io.invalid
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> +1 from me as well. Thanks, Stan!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
>>>>>>>>>>> me@ismaeljuma.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks Stanislav, +1
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ismael
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 7:01 AM Stanislav
>>>>> Kozlovski
>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 <
>>>>>>>>>>>>>>>>>>>>> sophie@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
>>>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 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
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>> sophie@responsive.dev>
>>>>>>>>>>>>>>>>>>>>>>> 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 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 <
>>>>>>>>>>>>>>>>>>>>>>> sophie@responsive.dev
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid>
>>>>> 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 <
>>>>>>>>>>>>>>>>>>>>>>> fearthecellos@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid>
>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>> cadonna@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>> <josep.prat@aiven.io.invalid
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.prat@aiven.io
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023, 20:05
>>>>>> Chris
>>>>>>>>>>> Egerton
>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>> fearthecellos@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1, thanks Stanislav!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023, 14:02
>>>>>> Bill
>>>>>>>>>>> Bejeck <
>>>>>>>>>>>>>>>>>>>>> bbejeck@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, Stanislav!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at
>>>>>> 1:59 PM
>>>>>>>> Ismael
>>>>>>>>>>>>>>> Juma <
>>>>>>>>>>>>>>>>>>>>>>>> me@ismaeljuma.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for volunteering
>>>>>>>> Stanislav!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ismael
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at
>>>>>>>> 10:51 AM
>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>> Kozlovski
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <stanislav@confluent.io
>>>>>>>> .invalid>
>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Mayank Shekhar Narula
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best,
>>>>>> Stanislav
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
> 
> 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <ap...@gmail.com>
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 <mj...@apache.org> 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 <al...@gmail.com>
> > 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
> > >> <st...@confluent.io.invalid> 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 <
> > apoorvmittal10@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, 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 <cm...@apache.org>
> > >> 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 <me...@ismaeljuma.com>
> > >>> 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
> > >>>>>>> <vi...@cloudera.com.invalid> 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
> > >>>>>>>> <st...@confluent.io.invalid> 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
> > >>>>>>>>> <
> > >>> https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh
> > >>>>>> .
> > >>>>>>>>>
> > >>>>>>>>> Best,
> > >>>>>>>>> Stanislav
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> > >>>>>>>>> stanislav@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 <
> > >>>>>>>>>> stanislav@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
> > >>>>>>>>>>> <
> > >>>>>
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> > >>>>>>>>> .
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks for your contributions once again!
> > >>>>>>>>>>> Best,
> > >>>>>>>>>>> Stan
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
> > >>>>> nick.telford@gmail.com>
> > >>>>>>>>>>> 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.narula@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
> > >>>>>>>>>>>>> <st...@confluent.io.invalid> 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 <
> > >>>>>>>>>>>>> sophie@responsive.dev>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Looks great, thank you! +1
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> > >>>>>>>>>>>>> <djacot@confluent.io.invalid
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> +1 from me as well. Thanks, Stan!
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> David
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
> > >>>>>>>> me@ismaeljuma.com>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Thanks Stanislav, +1
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Ismael
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 7:01 AM Stanislav
> > >> Kozlovski
> > >>>>>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 <
> > >>>>>>>>>>>>>>>>>> sophie@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
> > >>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 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
> > >>>>>>>> <
> > >>>>>>>>>>>>>>>>>>>> sophie@responsive.dev>
> > >>>>>>>>>>>>>>>>>>>> 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 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 <
> > >>>>>>>>>>>>>>>>>>>> sophie@responsive.dev
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid>
> > >> 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 <
> > >>>>>>>>>>>>>>>>>>>> fearthecellos@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid>
> > >>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>>> <
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>
> > >>> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> -
> > >>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>> <
> > >>>>>>>>>>>>>>>>>>> cadonna@apache.org
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>> <josep.prat@aiven.io.invalid
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> 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.prat@aiven.io
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023, 20:05
> > >>> Chris
> > >>>>>>>> Egerton
> > >>>>>>>>> <
> > >>>>>>>>>>>>>>>>>>>>>>> fearthecellos@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1, thanks Stanislav!
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023, 14:02
> > >>> Bill
> > >>>>>>>> Bejeck <
> > >>>>>>>>>>>>>>>>>> bbejeck@gmail.com
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, Stanislav!
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Bill
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at
> > >>> 1:59 PM
> > >>>>> Ismael
> > >>>>>>>>>>>> Juma <
> > >>>>>>>>>>>>>>>>>>>>> me@ismaeljuma.com>
> > >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for volunteering
> > >>>>> Stanislav!
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ismael
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at
> > >>>>> 10:51 AM
> > >>>>>>>>>>>> Stanislav
> > >>>>>>>>>>>>>>>> Kozlovski
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <stanislav@confluent.io
> > >>>>> .invalid>
> > >>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>>>>>>>>>>>>> Stanislav
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>>>>>>>>>>> Stanislav
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>>>>>>>> Stanislav
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>>>>>> Stanislav
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>> Best,
> > >>>>>>>>>>>>>> Stanislav
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> --
> > >>>>>>>>>>>>> Regards,
> > >>>>>>>>>>>>> Mayank Shekhar Narula
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> --
> > >>>>>>>>>>> Best,
> > >>>>>>>>>>> Stanislav
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> Best,
> > >>>>>>>>>> Stanislav
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Best,
> > >>>>>>>>> Stanislav
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>> --
> > >>> Best,
> > >>> Stanislav
> > >>>
> > >>
> > >
> > >
> >
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Apoorv Mittal <ap...@gmail.com>]

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 <mj...@apache.org> 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 <al...@gmail.com>
> 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
> >> <st...@confluent.io.invalid> 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 <
> apoorvmittal10@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, 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 <cm...@apache.org>
> >> 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 <me...@ismaeljuma.com>
> >>> 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
> >>>>>>> <vi...@cloudera.com.invalid> 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
> >>>>>>>> <st...@confluent.io.invalid> 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
> >>>>>>>>> <
> >>> https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh
> >>>>>> .
> >>>>>>>>>
> >>>>>>>>> Best,
> >>>>>>>>> Stanislav
> >>>>>>>>>
> >>>>>>>>> On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> >>>>>>>>> stanislav@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 <
> >>>>>>>>>> stanislav@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
> >>>>>>>>>>> <
> >>>>> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> >>>>>>>>> .
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for your contributions once again!
> >>>>>>>>>>> Best,
> >>>>>>>>>>> Stan
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
> >>>>> nick.telford@gmail.com>
> >>>>>>>>>>> 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.narula@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
> >>>>>>>>>>>>> <st...@confluent.io.invalid> 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 <
> >>>>>>>>>>>>> sophie@responsive.dev>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Looks great, thank you! +1
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> >>>>>>>>>>>>> <djacot@confluent.io.invalid
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> +1 from me as well. Thanks, Stan!
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> David
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
> >>>>>>>> me@ismaeljuma.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thanks Stanislav, +1
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Ismael
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 7:01 AM Stanislav
> >> Kozlovski
> >>>>>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 <
> >>>>>>>>>>>>>>>>>> sophie@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
> >>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 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
> >>>>>>>> <
> >>>>>>>>>>>>>>>>>>>> sophie@responsive.dev>
> >>>>>>>>>>>>>>>>>>>> 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 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 <
> >>>>>>>>>>>>>>>>>>>> sophie@responsive.dev
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid>
> >> 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 <
> >>>>>>>>>>>>>>>>>>>> fearthecellos@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid>
> >>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>> <
> >>>>>>>>>>>>>>>>>>> cadonna@apache.org
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>> <josep.prat@aiven.io.invalid
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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.prat@aiven.io
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023, 20:05
> >>> Chris
> >>>>>>>> Egerton
> >>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>> fearthecellos@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1, thanks Stanislav!
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023, 14:02
> >>> Bill
> >>>>>>>> Bejeck <
> >>>>>>>>>>>>>>>>>> bbejeck@gmail.com
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, Stanislav!
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Bill
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at
> >>> 1:59 PM
> >>>>> Ismael
> >>>>>>>>>>>> Juma <
> >>>>>>>>>>>>>>>>>>>>> me@ismaeljuma.com>
> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for volunteering
> >>>>> Stanislav!
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ismael
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at
> >>>>> 10:51 AM
> >>>>>>>>>>>> Stanislav
> >>>>>>>>>>>>>>>> Kozlovski
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <stanislav@confluent.io
> >>>>> .invalid>
> >>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>>>>>>>>>> Stanislav
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>>>>>>>> Stanislav
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>>>>> Stanislav
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>>> Stanislav
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>> Stanislav
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>> Mayank Shekhar Narula
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Best,
> >>>>>>>>>>> Stanislav
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Best,
> >>>>>>>>>> Stanislav
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Best,
> >>>>>>>>> Stanislav
> >>>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>
> >>>
> >>> --
> >>> Best,
> >>> Stanislav
> >>>
> >>
> >
> >
>

Re: Apache Kafka 3.7.0 Release

["Matthias J. Sax" <mj...@apache.org>]

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 <al...@gmail.com> 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
>> <st...@confluent.io.invalid> 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 <apoorvmittal10@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, 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 <cm...@apache.org>
>> 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 <me...@ismaeljuma.com>
>>> 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
>>>>>>> <vi...@cloudera.com.invalid> 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
>>>>>>>> <st...@confluent.io.invalid> 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
>>>>>>>>> <
>>> https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh
>>>>>> .
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Stanislav
>>>>>>>>>
>>>>>>>>> On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
>>>>>>>>> stanislav@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 <
>>>>>>>>>> stanislav@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
>>>>>>>>>>> <
>>>>> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your contributions once again!
>>>>>>>>>>> Best,
>>>>>>>>>>> Stan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
>>>>> nick.telford@gmail.com>
>>>>>>>>>>> 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.narula@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
>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 <
>>>>>>>>>>>>> sophie@responsive.dev>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Looks great, thank you! +1
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 10:21 AM David Jacot
>>>>>>>>>>>>> <djacot@confluent.io.invalid
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> +1 from me as well. Thanks, Stan!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
>>>>>>>> me@ismaeljuma.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks Stanislav, +1
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ismael
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Nov 2, 2023 at 7:01 AM Stanislav
>> Kozlovski
>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 <
>>>>>>>>>>>>>>>>>> sophie@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
>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid> 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 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
>>>>>>>> <
>>>>>>>>>>>>>>>>>>>> sophie@responsive.dev>
>>>>>>>>>>>>>>>>>>>> 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 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 <
>>>>>>>>>>>>>>>>>>>> sophie@responsive.dev
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid>
>> 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 <
>>>>>>>>>>>>>>>>>>>> fearthecellos@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>> <st...@confluent.io.invalid>
>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>
>>> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>> <
>>>>>>>>>>>>>>>>>>> cadonna@apache.org
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>> <josep.prat@aiven.io.invalid
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.prat@aiven.io
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023, 20:05
>>> Chris
>>>>>>>> Egerton
>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>> fearthecellos@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1, thanks Stanislav!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023, 14:02
>>> Bill
>>>>>>>> Bejeck <
>>>>>>>>>>>>>>>>>> bbejeck@gmail.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, Stanislav!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Bill
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at
>>> 1:59 PM
>>>>> Ismael
>>>>>>>>>>>> Juma <
>>>>>>>>>>>>>>>>>>>>> me@ismaeljuma.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for volunteering
>>>>> Stanislav!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ismael
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 9, 2023 at
>>>>> 10:51 AM
>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>> Kozlovski
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <stanislav@confluent.io
>>>>> .invalid>
>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>> Stanislav
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Mayank Shekhar Narula
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Best,
>>>>>>>>>>> Stanislav
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Best,
>>>>>>>>>> Stanislav
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best,
>>>>>>>>> Stanislav
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Best,
>>> Stanislav
>>>
>>
> 
> 

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <al...@gmail.com> 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
> <st...@confluent.io.invalid> 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 <apoorvmittal10@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, 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 <cm...@apache.org>
> 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 <me...@ismaeljuma.com>
> > 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
> > >> >> <vi...@cloudera.com.invalid> 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
> > >> >> > <st...@confluent.io.invalid> 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
> > >> >> > > <
> > https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh
> > >> >.
> > >> >> > >
> > >> >> > > Best,
> > >> >> > > Stanislav
> > >> >> > >
> > >> >> > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> > >> >> > > stanislav@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 <
> > >> >> > > > stanislav@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
> > >> >> > > >> <
> > >> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> > >> >> > >.
> > >> >> > > >>
> > >> >> > > >> Thanks for your contributions once again!
> > >> >> > > >> Best,
> > >> >> > > >> Stan
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
> > >> nick.telford@gmail.com>
> > >> >> > > >> 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.narula@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
> > >> >> > > >>> > <st...@confluent.io.invalid> 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 <
> > >> >> > > >>> > sophie@responsive.dev>
> > >> >> > > >>> > > wrote:
> > >> >> > > >>> > >
> > >> >> > > >>> > > > Looks great, thank you! +1
> > >> >> > > >>> > > >
> > >> >> > > >>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> > >> >> > > >>> > <djacot@confluent.io.invalid
> > >> >> > > >>> > > >
> > >> >> > > >>> > > > wrote:
> > >> >> > > >>> > > >
> > >> >> > > >>> > > > > +1 from me as well. Thanks, Stan!
> > >> >> > > >>> > > > >
> > >> >> > > >>> > > > > David
> > >> >> > > >>> > > > >
> > >> >> > > >>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
> > >> >> > me@ismaeljuma.com>
> > >> >> > > >>> > wrote:
> > >> >> > > >>> > > > >
> > >> >> > > >>> > > > > > Thanks Stanislav, +1
> > >> >> > > >>> > > > > >
> > >> >> > > >>> > > > > > Ismael
> > >> >> > > >>> > > > > >
> > >> >> > > >>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav
> Kozlovski
> > >> >> > > >>> > > > > > <st...@confluent.io.invalid> 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 <
> > >> >> > > >>> > > > > > > sophie@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
> > >> >> > > >>> > > > > > > > <st...@confluent.io.invalid> 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 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
> > >> >> > <
> > >> >> > > >>> > > > > > > > > sophie@responsive.dev>
> > >> >> > > >>> > > > > > > > > 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 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 <
> > >> >> > > >>> > > > > > > > > sophie@responsive.dev
> > >> >> > > >>> > > > > > > > > > >
> > >> >> > > >>> > > > > > > > > > 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
> > >> >> > > >>> > > > > > > > > > > <st...@confluent.io.invalid>
> 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 <
> > >> >> > > >>> > > > > > > > > fearthecellos@gmail.com>
> > >> >> > > >>> > > > > > > > > > >> 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
> > >> >> > > >>> > > > > > > > > > >> > <st...@confluent.io.invalid>
> > 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
> > >> >> > > >>> > > > > > > > > > >> > > <
> > >> >> > > >>> > > > > > > > > >
> > >> >> > > >>> > > > > >
> > >> >> > > >>> >
> > >> >> >
> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > >> >> > > >>> > > > > > > >
> > >> >> > > >>> > > > > > > > > > >> -
> > >> >> > > >>> > > > > > > > > > >> > > 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
> > >> >> > > <
> > >> >> > > >>> > > > > > > > cadonna@apache.org
> > >> >> > > >>> > > > > > > > > >
> > >> >> > > >>> > > > > > > > > > >> > 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
> > >> >> > > >>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
> > >> >> > > >>> > > > > > > > > > >> > > >
> > >> >> > > >>> > > > > > > > > > >> > > > > 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.prat@aiven.io
> > >> >> > > >>> > > > > > > > > > >> > > > >>
> > >> >> > > >>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05
> > Chris
> > >> >> > Egerton
> > >> >> > > <
> > >> >> > > >>> > > > > > > > > > >> fearthecellos@gmail.com>
> > >> >> > > >>> > > > > > > > > > >> > > > wrote:
> > >> >> > > >>> > > > > > > > > > >> > > > >>
> > >> >> > > >>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
> > >> >> > > >>> > > > > > > > > > >> > > > >>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02
> > Bill
> > >> >> > Bejeck <
> > >> >> > > >>> > > > > > > bbejeck@gmail.com
> > >> >> > > >>> > > > > > > > >
> > >> >> > > >>> > > > > > > > > > >> wrote:
> > >> >> > > >>> > > > > > > > > > >> > > > >>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>> +1
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>> -Bill
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at
> > 1:59 PM
> > >> Ismael
> > >> >> > > >>> Juma <
> > >> >> > > >>> > > > > > > > > > me@ismaeljuma.com>
> > >> >> > > >>> > > > > > > > > > >> > > wrote:
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering
> > >> Stanislav!
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>> Ismael
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at
> > >> 10:51 AM
> > >> >> > > >>> Stanislav
> > >> >> > > >>> > > > > Kozlovski
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>> <stanislav@confluent.io
> > >> .invalid>
> > >> >> > > 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
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>>
> > >> >> > > >>> > > > > > > > > > >> > > > >>
> > >> >> > > >>> > > > > > > > > > >> > > > >
> > >> >> > > >>> > > > > > > > > > >> > > >
> > >> >> > > >>> > > > > > > > > > >> > >
> > >> >> > > >>> > > > > > > > > > >> > >
> > >> >> > > >>> > > > > > > > > > >> > > --
> > >> >> > > >>> > > > > > > > > > >> > > Best,
> > >> >> > > >>> > > > > > > > > > >> > > Stanislav
> > >> >> > > >>> > > > > > > > > > >> > >
> > >> >> > > >>> > > > > > > > > > >> >
> > >> >> > > >>> > > > > > > > > > >>
> > >> >> > > >>> > > > > > > > > > >>
> > >> >> > > >>> > > > > > > > > > >> --
> > >> >> > > >>> > > > > > > > > > >> Best,
> > >> >> > > >>> > > > > > > > > > >> Stanislav
> > >> >> > > >>> > > > > > > > > > >>
> > >> >> > > >>> > > > > > > > > > >
> > >> >> > > >>> > > > > > > > > >
> > >> >> > > >>> > > > > > > > >
> > >> >> > > >>> > > > > > > > >
> > >> >> > > >>> > > > > > > > > --
> > >> >> > > >>> > > > > > > > > Best,
> > >> >> > > >>> > > > > > > > > Stanislav
> > >> >> > > >>> > > > > > > > >
> > >> >> > > >>> > > > > > > >
> > >> >> > > >>> > > > > > >
> > >> >> > > >>> > > > > > >
> > >> >> > > >>> > > > > > > --
> > >> >> > > >>> > > > > > > Best,
> > >> >> > > >>> > > > > > > Stanislav
> > >> >> > > >>> > > > > > >
> > >> >> > > >>> > > > > >
> > >> >> > > >>> > > > >
> > >> >> > > >>> > > >
> > >> >> > > >>> > >
> > >> >> > > >>> > >
> > >> >> > > >>> > > --
> > >> >> > > >>> > > Best,
> > >> >> > > >>> > > Stanislav
> > >> >> > > >>> > >
> > >> >> > > >>> >
> > >> >> > > >>> >
> > >> >> > > >>> > --
> > >> >> > > >>> > Regards,
> > >> >> > > >>> > Mayank Shekhar Narula
> > >> >> > > >>> >
> > >> >> > > >>>
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >> --
> > >> >> > > >> Best,
> > >> >> > > >> Stanislav
> > >> >> > > >>
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > --
> > >> >> > > > Best,
> > >> >> > > > Stanislav
> > >> >> > > >
> > >> >> > >
> > >> >> > >
> > >> >> > > --
> > >> >> > > Best,
> > >> >> > > Stanislav
> > >> >> > >
> > >> >> >
> > >>
> > >
> >
> > --
> > Best,
> > Stanislav
> >
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Almog Gavra <al...@gmail.com>]

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
<st...@confluent.io.invalid> 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 <ap...@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, 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 <cm...@apache.org> 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 <me...@ismaeljuma.com>
> 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
> >> >> <vi...@cloudera.com.invalid> 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
> >> >> > <st...@confluent.io.invalid> 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
> >> >> > > <
> https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh
> >> >.
> >> >> > >
> >> >> > > Best,
> >> >> > > Stanislav
> >> >> > >
> >> >> > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> >> >> > > stanislav@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 <
> >> >> > > > stanislav@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
> >> >> > > >> <
> >> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> >> >> > >.
> >> >> > > >>
> >> >> > > >> Thanks for your contributions once again!
> >> >> > > >> Best,
> >> >> > > >> Stan
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
> >> nick.telford@gmail.com>
> >> >> > > >> 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.narula@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
> >> >> > > >>> > <st...@confluent.io.invalid> 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 <
> >> >> > > >>> > sophie@responsive.dev>
> >> >> > > >>> > > wrote:
> >> >> > > >>> > >
> >> >> > > >>> > > > Looks great, thank you! +1
> >> >> > > >>> > > >
> >> >> > > >>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> >> >> > > >>> > <djacot@confluent.io.invalid
> >> >> > > >>> > > >
> >> >> > > >>> > > > wrote:
> >> >> > > >>> > > >
> >> >> > > >>> > > > > +1 from me as well. Thanks, Stan!
> >> >> > > >>> > > > >
> >> >> > > >>> > > > > David
> >> >> > > >>> > > > >
> >> >> > > >>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
> >> >> > me@ismaeljuma.com>
> >> >> > > >>> > wrote:
> >> >> > > >>> > > > >
> >> >> > > >>> > > > > > Thanks Stanislav, +1
> >> >> > > >>> > > > > >
> >> >> > > >>> > > > > > Ismael
> >> >> > > >>> > > > > >
> >> >> > > >>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> >> >> > > >>> > > > > > <st...@confluent.io.invalid> 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 <
> >> >> > > >>> > > > > > > sophie@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
> >> >> > > >>> > > > > > > > <st...@confluent.io.invalid> 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 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
> >> >> > <
> >> >> > > >>> > > > > > > > > sophie@responsive.dev>
> >> >> > > >>> > > > > > > > > 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 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 <
> >> >> > > >>> > > > > > > > > sophie@responsive.dev
> >> >> > > >>> > > > > > > > > > >
> >> >> > > >>> > > > > > > > > > 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
> >> >> > > >>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
> >> >> > > >>> > > > > > > > > fearthecellos@gmail.com>
> >> >> > > >>> > > > > > > > > > >> 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
> >> >> > > >>> > > > > > > > > > >> > <st...@confluent.io.invalid>
> 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
> >> >> > > >>> > > > > > > > > > >> > > <
> >> >> > > >>> > > > > > > > > >
> >> >> > > >>> > > > > >
> >> >> > > >>> >
> >> >> >
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> >> >> > > >>> > > > > > > >
> >> >> > > >>> > > > > > > > > > >> -
> >> >> > > >>> > > > > > > > > > >> > > 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
> >> >> > > <
> >> >> > > >>> > > > > > > > cadonna@apache.org
> >> >> > > >>> > > > > > > > > >
> >> >> > > >>> > > > > > > > > > >> > 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
> >> >> > > >>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
> >> >> > > >>> > > > > > > > > > >> > > >
> >> >> > > >>> > > > > > > > > > >> > > > > 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.prat@aiven.io
> >> >> > > >>> > > > > > > > > > >> > > > >>
> >> >> > > >>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05
> Chris
> >> >> > Egerton
> >> >> > > <
> >> >> > > >>> > > > > > > > > > >> fearthecellos@gmail.com>
> >> >> > > >>> > > > > > > > > > >> > > > wrote:
> >> >> > > >>> > > > > > > > > > >> > > > >>
> >> >> > > >>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
> >> >> > > >>> > > > > > > > > > >> > > > >>>
> >> >> > > >>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02
> Bill
> >> >> > Bejeck <
> >> >> > > >>> > > > > > > bbejeck@gmail.com
> >> >> > > >>> > > > > > > > >
> >> >> > > >>> > > > > > > > > > >> wrote:
> >> >> > > >>> > > > > > > > > > >> > > > >>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>> +1
> >> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
> >> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>> -Bill
> >> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at
> 1:59 PM
> >> Ismael
> >> >> > > >>> Juma <
> >> >> > > >>> > > > > > > > > > me@ismaeljuma.com>
> >> >> > > >>> > > > > > > > > > >> > > wrote:
> >> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering
> >> Stanislav!
> >> >> > > >>> > > > > > > > > > >> > > > >>>>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>>> Ismael
> >> >> > > >>> > > > > > > > > > >> > > > >>>>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at
> >> 10:51 AM
> >> >> > > >>> Stanislav
> >> >> > > >>> > > > > Kozlovski
> >> >> > > >>> > > > > > > > > > >> > > > >>>>> <stanislav@confluent.io
> >> .invalid>
> >> >> > > 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
> >> >> > > >>> > > > > > > > > > >> > > > >>>>>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> >> > > >>> > > > > > > > > > >> > > > >>>
> >> >> > > >>> > > > > > > > > > >> > > > >>
> >> >> > > >>> > > > > > > > > > >> > > > >
> >> >> > > >>> > > > > > > > > > >> > > >
> >> >> > > >>> > > > > > > > > > >> > >
> >> >> > > >>> > > > > > > > > > >> > >
> >> >> > > >>> > > > > > > > > > >> > > --
> >> >> > > >>> > > > > > > > > > >> > > Best,
> >> >> > > >>> > > > > > > > > > >> > > Stanislav
> >> >> > > >>> > > > > > > > > > >> > >
> >> >> > > >>> > > > > > > > > > >> >
> >> >> > > >>> > > > > > > > > > >>
> >> >> > > >>> > > > > > > > > > >>
> >> >> > > >>> > > > > > > > > > >> --
> >> >> > > >>> > > > > > > > > > >> Best,
> >> >> > > >>> > > > > > > > > > >> Stanislav
> >> >> > > >>> > > > > > > > > > >>
> >> >> > > >>> > > > > > > > > > >
> >> >> > > >>> > > > > > > > > >
> >> >> > > >>> > > > > > > > >
> >> >> > > >>> > > > > > > > >
> >> >> > > >>> > > > > > > > > --
> >> >> > > >>> > > > > > > > > Best,
> >> >> > > >>> > > > > > > > > Stanislav
> >> >> > > >>> > > > > > > > >
> >> >> > > >>> > > > > > > >
> >> >> > > >>> > > > > > >
> >> >> > > >>> > > > > > >
> >> >> > > >>> > > > > > > --
> >> >> > > >>> > > > > > > Best,
> >> >> > > >>> > > > > > > Stanislav
> >> >> > > >>> > > > > > >
> >> >> > > >>> > > > > >
> >> >> > > >>> > > > >
> >> >> > > >>> > > >
> >> >> > > >>> > >
> >> >> > > >>> > >
> >> >> > > >>> > > --
> >> >> > > >>> > > Best,
> >> >> > > >>> > > Stanislav
> >> >> > > >>> > >
> >> >> > > >>> >
> >> >> > > >>> >
> >> >> > > >>> > --
> >> >> > > >>> > Regards,
> >> >> > > >>> > Mayank Shekhar Narula
> >> >> > > >>> >
> >> >> > > >>>
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> --
> >> >> > > >> Best,
> >> >> > > >> Stanislav
> >> >> > > >>
> >> >> > > >
> >> >> > > >
> >> >> > > > --
> >> >> > > > Best,
> >> >> > > > Stanislav
> >> >> > > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Best,
> >> >> > > Stanislav
> >> >> > >
> >> >> >
> >>
> >
>
> --
> Best,
> Stanislav
>

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <ap...@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, 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 <cm...@apache.org> 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 <me...@ismaeljuma.com> 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
>> >> <vi...@cloudera.com.invalid> 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
>> >> > <st...@confluent.io.invalid> 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
>> >> > > <https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh
>> >.
>> >> > >
>> >> > > Best,
>> >> > > Stanislav
>> >> > >
>> >> > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
>> >> > > stanislav@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 <
>> >> > > > stanislav@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
>> >> > > >> <
>> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
>> >> > >.
>> >> > > >>
>> >> > > >> Thanks for your contributions once again!
>> >> > > >> Best,
>> >> > > >> Stan
>> >> > > >>
>> >> > > >>
>> >> > > >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
>> nick.telford@gmail.com>
>> >> > > >> 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.narula@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
>> >> > > >>> > <st...@confluent.io.invalid> 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 <
>> >> > > >>> > sophie@responsive.dev>
>> >> > > >>> > > wrote:
>> >> > > >>> > >
>> >> > > >>> > > > Looks great, thank you! +1
>> >> > > >>> > > >
>> >> > > >>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
>> >> > > >>> > <djacot@confluent.io.invalid
>> >> > > >>> > > >
>> >> > > >>> > > > wrote:
>> >> > > >>> > > >
>> >> > > >>> > > > > +1 from me as well. Thanks, Stan!
>> >> > > >>> > > > >
>> >> > > >>> > > > > David
>> >> > > >>> > > > >
>> >> > > >>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
>> >> > me@ismaeljuma.com>
>> >> > > >>> > wrote:
>> >> > > >>> > > > >
>> >> > > >>> > > > > > Thanks Stanislav, +1
>> >> > > >>> > > > > >
>> >> > > >>> > > > > > Ismael
>> >> > > >>> > > > > >
>> >> > > >>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
>> >> > > >>> > > > > > <st...@confluent.io.invalid> 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 <
>> >> > > >>> > > > > > > sophie@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
>> >> > > >>> > > > > > > > <st...@confluent.io.invalid> 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 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
>> >> > <
>> >> > > >>> > > > > > > > > sophie@responsive.dev>
>> >> > > >>> > > > > > > > > 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 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 <
>> >> > > >>> > > > > > > > > sophie@responsive.dev
>> >> > > >>> > > > > > > > > > >
>> >> > > >>> > > > > > > > > > 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
>> >> > > >>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
>> >> > > >>> > > > > > > > > fearthecellos@gmail.com>
>> >> > > >>> > > > > > > > > > >> 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
>> >> > > >>> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
>> >> > > >>> > > > > > > > > > >> > > <
>> >> > > >>> > > > > > > > > >
>> >> > > >>> > > > > >
>> >> > > >>> >
>> >> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
>> >> > > >>> > > > > > > >
>> >> > > >>> > > > > > > > > > >> -
>> >> > > >>> > > > > > > > > > >> > > 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
>> >> > > <
>> >> > > >>> > > > > > > > cadonna@apache.org
>> >> > > >>> > > > > > > > > >
>> >> > > >>> > > > > > > > > > >> > 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
>> >> > > >>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
>> >> > > >>> > > > > > > > > > >> > > >
>> >> > > >>> > > > > > > > > > >> > > > > 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.prat@aiven.io
>> >> > > >>> > > > > > > > > > >> > > > >>
>> >> > > >>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris
>> >> > Egerton
>> >> > > <
>> >> > > >>> > > > > > > > > > >> fearthecellos@gmail.com>
>> >> > > >>> > > > > > > > > > >> > > > wrote:
>> >> > > >>> > > > > > > > > > >> > > > >>
>> >> > > >>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
>> >> > > >>> > > > > > > > > > >> > > > >>>
>> >> > > >>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill
>> >> > Bejeck <
>> >> > > >>> > > > > > > bbejeck@gmail.com
>> >> > > >>> > > > > > > > >
>> >> > > >>> > > > > > > > > > >> wrote:
>> >> > > >>> > > > > > > > > > >> > > > >>>
>> >> > > >>> > > > > > > > > > >> > > > >>>> +1
>> >> > > >>> > > > > > > > > > >> > > > >>>>
>> >> > > >>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
>> >> > > >>> > > > > > > > > > >> > > > >>>>
>> >> > > >>> > > > > > > > > > >> > > > >>>> -Bill
>> >> > > >>> > > > > > > > > > >> > > > >>>>
>> >> > > >>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM
>> Ismael
>> >> > > >>> Juma <
>> >> > > >>> > > > > > > > > > me@ismaeljuma.com>
>> >> > > >>> > > > > > > > > > >> > > wrote:
>> >> > > >>> > > > > > > > > > >> > > > >>>>
>> >> > > >>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering
>> Stanislav!
>> >> > > >>> > > > > > > > > > >> > > > >>>>>
>> >> > > >>> > > > > > > > > > >> > > > >>>>> Ismael
>> >> > > >>> > > > > > > > > > >> > > > >>>>>
>> >> > > >>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at
>> 10:51 AM
>> >> > > >>> Stanislav
>> >> > > >>> > > > > Kozlovski
>> >> > > >>> > > > > > > > > > >> > > > >>>>> <stanislav@confluent.io
>> .invalid>
>> >> > > 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
>> >> > > >>> > > > > > > > > > >> > > > >>>>>>
>> >> > > >>> > > > > > > > > > >> > > > >>>>>
>> >> > > >>> > > > > > > > > > >> > > > >>>>
>> >> > > >>> > > > > > > > > > >> > > > >>>
>> >> > > >>> > > > > > > > > > >> > > > >>
>> >> > > >>> > > > > > > > > > >> > > > >
>> >> > > >>> > > > > > > > > > >> > > >
>> >> > > >>> > > > > > > > > > >> > >
>> >> > > >>> > > > > > > > > > >> > >
>> >> > > >>> > > > > > > > > > >> > > --
>> >> > > >>> > > > > > > > > > >> > > Best,
>> >> > > >>> > > > > > > > > > >> > > Stanislav
>> >> > > >>> > > > > > > > > > >> > >
>> >> > > >>> > > > > > > > > > >> >
>> >> > > >>> > > > > > > > > > >>
>> >> > > >>> > > > > > > > > > >>
>> >> > > >>> > > > > > > > > > >> --
>> >> > > >>> > > > > > > > > > >> Best,
>> >> > > >>> > > > > > > > > > >> Stanislav
>> >> > > >>> > > > > > > > > > >>
>> >> > > >>> > > > > > > > > > >
>> >> > > >>> > > > > > > > > >
>> >> > > >>> > > > > > > > >
>> >> > > >>> > > > > > > > >
>> >> > > >>> > > > > > > > > --
>> >> > > >>> > > > > > > > > Best,
>> >> > > >>> > > > > > > > > Stanislav
>> >> > > >>> > > > > > > > >
>> >> > > >>> > > > > > > >
>> >> > > >>> > > > > > >
>> >> > > >>> > > > > > >
>> >> > > >>> > > > > > > --
>> >> > > >>> > > > > > > Best,
>> >> > > >>> > > > > > > Stanislav
>> >> > > >>> > > > > > >
>> >> > > >>> > > > > >
>> >> > > >>> > > > >
>> >> > > >>> > > >
>> >> > > >>> > >
>> >> > > >>> > >
>> >> > > >>> > > --
>> >> > > >>> > > Best,
>> >> > > >>> > > Stanislav
>> >> > > >>> > >
>> >> > > >>> >
>> >> > > >>> >
>> >> > > >>> > --
>> >> > > >>> > Regards,
>> >> > > >>> > Mayank Shekhar Narula
>> >> > > >>> >
>> >> > > >>>
>> >> > > >>
>> >> > > >>
>> >> > > >> --
>> >> > > >> Best,
>> >> > > >> Stanislav
>> >> > > >>
>> >> > > >
>> >> > > >
>> >> > > > --
>> >> > > > Best,
>> >> > > > Stanislav
>> >> > > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Best,
>> >> > > Stanislav
>> >> > >
>> >> >
>>
>

-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Apoorv Mittal <ap...@gmail.com>]

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 <cm...@apache.org> 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 <me...@ismaeljuma.com> 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
> >> <vi...@cloudera.com.invalid> 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
> >> > <st...@confluent.io.invalid> 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
> >> > > <https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh>.
> >> > >
> >> > > Best,
> >> > > Stanislav
> >> > >
> >> > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> >> > > stanislav@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 <
> >> > > > stanislav@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
> >> > > >> <
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> >> > >.
> >> > > >>
> >> > > >> Thanks for your contributions once again!
> >> > > >> Best,
> >> > > >> Stan
> >> > > >>
> >> > > >>
> >> > > >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
> nick.telford@gmail.com>
> >> > > >> 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.narula@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
> >> > > >>> > <st...@confluent.io.invalid> 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 <
> >> > > >>> > sophie@responsive.dev>
> >> > > >>> > > wrote:
> >> > > >>> > >
> >> > > >>> > > > Looks great, thank you! +1
> >> > > >>> > > >
> >> > > >>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> >> > > >>> > <djacot@confluent.io.invalid
> >> > > >>> > > >
> >> > > >>> > > > wrote:
> >> > > >>> > > >
> >> > > >>> > > > > +1 from me as well. Thanks, Stan!
> >> > > >>> > > > >
> >> > > >>> > > > > David
> >> > > >>> > > > >
> >> > > >>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
> >> > me@ismaeljuma.com>
> >> > > >>> > wrote:
> >> > > >>> > > > >
> >> > > >>> > > > > > Thanks Stanislav, +1
> >> > > >>> > > > > >
> >> > > >>> > > > > > Ismael
> >> > > >>> > > > > >
> >> > > >>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> >> > > >>> > > > > > <st...@confluent.io.invalid> 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 <
> >> > > >>> > > > > > > sophie@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
> >> > > >>> > > > > > > > <st...@confluent.io.invalid> 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 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
> >> > <
> >> > > >>> > > > > > > > > sophie@responsive.dev>
> >> > > >>> > > > > > > > > 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 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 <
> >> > > >>> > > > > > > > > sophie@responsive.dev
> >> > > >>> > > > > > > > > > >
> >> > > >>> > > > > > > > > > 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
> >> > > >>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
> >> > > >>> > > > > > > > > fearthecellos@gmail.com>
> >> > > >>> > > > > > > > > > >> 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
> >> > > >>> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
> >> > > >>> > > > > > > > > > >> > > <
> >> > > >>> > > > > > > > > >
> >> > > >>> > > > > >
> >> > > >>> >
> >> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> >> > > >>> > > > > > > >
> >> > > >>> > > > > > > > > > >> -
> >> > > >>> > > > > > > > > > >> > > 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
> >> > > <
> >> > > >>> > > > > > > > cadonna@apache.org
> >> > > >>> > > > > > > > > >
> >> > > >>> > > > > > > > > > >> > 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
> >> > > >>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
> >> > > >>> > > > > > > > > > >> > > >
> >> > > >>> > > > > > > > > > >> > > > > 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.prat@aiven.io
> >> > > >>> > > > > > > > > > >> > > > >>
> >> > > >>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris
> >> > Egerton
> >> > > <
> >> > > >>> > > > > > > > > > >> fearthecellos@gmail.com>
> >> > > >>> > > > > > > > > > >> > > > wrote:
> >> > > >>> > > > > > > > > > >> > > > >>
> >> > > >>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
> >> > > >>> > > > > > > > > > >> > > > >>>
> >> > > >>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill
> >> > Bejeck <
> >> > > >>> > > > > > > bbejeck@gmail.com
> >> > > >>> > > > > > > > >
> >> > > >>> > > > > > > > > > >> wrote:
> >> > > >>> > > > > > > > > > >> > > > >>>
> >> > > >>> > > > > > > > > > >> > > > >>>> +1
> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> > > >>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> > > >>> > > > > > > > > > >> > > > >>>> -Bill
> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> > > >>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM
> Ismael
> >> > > >>> Juma <
> >> > > >>> > > > > > > > > > me@ismaeljuma.com>
> >> > > >>> > > > > > > > > > >> > > wrote:
> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> > > >>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering
> Stanislav!
> >> > > >>> > > > > > > > > > >> > > > >>>>>
> >> > > >>> > > > > > > > > > >> > > > >>>>> Ismael
> >> > > >>> > > > > > > > > > >> > > > >>>>>
> >> > > >>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM
> >> > > >>> Stanislav
> >> > > >>> > > > > Kozlovski
> >> > > >>> > > > > > > > > > >> > > > >>>>> <stanislav@confluent.io
> .invalid>
> >> > > 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
> >> > > >>> > > > > > > > > > >> > > > >>>>>>
> >> > > >>> > > > > > > > > > >> > > > >>>>>
> >> > > >>> > > > > > > > > > >> > > > >>>>
> >> > > >>> > > > > > > > > > >> > > > >>>
> >> > > >>> > > > > > > > > > >> > > > >>
> >> > > >>> > > > > > > > > > >> > > > >
> >> > > >>> > > > > > > > > > >> > > >
> >> > > >>> > > > > > > > > > >> > >
> >> > > >>> > > > > > > > > > >> > >
> >> > > >>> > > > > > > > > > >> > > --
> >> > > >>> > > > > > > > > > >> > > Best,
> >> > > >>> > > > > > > > > > >> > > Stanislav
> >> > > >>> > > > > > > > > > >> > >
> >> > > >>> > > > > > > > > > >> >
> >> > > >>> > > > > > > > > > >>
> >> > > >>> > > > > > > > > > >>
> >> > > >>> > > > > > > > > > >> --
> >> > > >>> > > > > > > > > > >> Best,
> >> > > >>> > > > > > > > > > >> Stanislav
> >> > > >>> > > > > > > > > > >>
> >> > > >>> > > > > > > > > > >
> >> > > >>> > > > > > > > > >
> >> > > >>> > > > > > > > >
> >> > > >>> > > > > > > > >
> >> > > >>> > > > > > > > > --
> >> > > >>> > > > > > > > > Best,
> >> > > >>> > > > > > > > > Stanislav
> >> > > >>> > > > > > > > >
> >> > > >>> > > > > > > >
> >> > > >>> > > > > > >
> >> > > >>> > > > > > >
> >> > > >>> > > > > > > --
> >> > > >>> > > > > > > Best,
> >> > > >>> > > > > > > Stanislav
> >> > > >>> > > > > > >
> >> > > >>> > > > > >
> >> > > >>> > > > >
> >> > > >>> > > >
> >> > > >>> > >
> >> > > >>> > >
> >> > > >>> > > --
> >> > > >>> > > Best,
> >> > > >>> > > Stanislav
> >> > > >>> > >
> >> > > >>> >
> >> > > >>> >
> >> > > >>> > --
> >> > > >>> > Regards,
> >> > > >>> > Mayank Shekhar Narula
> >> > > >>> >
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> Best,
> >> > > >> Stanislav
> >> > > >>
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Best,
> >> > > > Stanislav
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > Best,
> >> > > Stanislav
> >> > >
> >> >
>

Re: Apache Kafka 3.7.0 Release

[Colin McCabe <cm...@apache.org>]

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 <me...@ismaeljuma.com> 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
>> <vi...@cloudera.com.invalid> 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
>> > <st...@confluent.io.invalid> 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
>> > > <https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh>.
>> > >
>> > > Best,
>> > > Stanislav
>> > >
>> > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
>> > > stanislav@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 <
>> > > > stanislav@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
>> > > >> <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
>> > >.
>> > > >>
>> > > >> Thanks for your contributions once again!
>> > > >> Best,
>> > > >> Stan
>> > > >>
>> > > >>
>> > > >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <ni...@gmail.com>
>> > > >> 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.narula@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
>> > > >>> > <st...@confluent.io.invalid> 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 <
>> > > >>> > sophie@responsive.dev>
>> > > >>> > > wrote:
>> > > >>> > >
>> > > >>> > > > Looks great, thank you! +1
>> > > >>> > > >
>> > > >>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
>> > > >>> > <djacot@confluent.io.invalid
>> > > >>> > > >
>> > > >>> > > > wrote:
>> > > >>> > > >
>> > > >>> > > > > +1 from me as well. Thanks, Stan!
>> > > >>> > > > >
>> > > >>> > > > > David
>> > > >>> > > > >
>> > > >>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
>> > me@ismaeljuma.com>
>> > > >>> > wrote:
>> > > >>> > > > >
>> > > >>> > > > > > Thanks Stanislav, +1
>> > > >>> > > > > >
>> > > >>> > > > > > Ismael
>> > > >>> > > > > >
>> > > >>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
>> > > >>> > > > > > <st...@confluent.io.invalid> 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 <
>> > > >>> > > > > > > sophie@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
>> > > >>> > > > > > > > <st...@confluent.io.invalid> 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 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
>> > <
>> > > >>> > > > > > > > > sophie@responsive.dev>
>> > > >>> > > > > > > > > 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 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 <
>> > > >>> > > > > > > > > sophie@responsive.dev
>> > > >>> > > > > > > > > > >
>> > > >>> > > > > > > > > > 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
>> > > >>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
>> > > >>> > > > > > > > > fearthecellos@gmail.com>
>> > > >>> > > > > > > > > > >> 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
>> > > >>> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
>> > > >>> > > > > > > > > > >> > > <
>> > > >>> > > > > > > > > >
>> > > >>> > > > > >
>> > > >>> >
>> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
>> > > >>> > > > > > > >
>> > > >>> > > > > > > > > > >> -
>> > > >>> > > > > > > > > > >> > > 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
>> > > <
>> > > >>> > > > > > > > cadonna@apache.org
>> > > >>> > > > > > > > > >
>> > > >>> > > > > > > > > > >> > 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
>> > > >>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
>> > > >>> > > > > > > > > > >> > > >
>> > > >>> > > > > > > > > > >> > > > > 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.prat@aiven.io
>> > > >>> > > > > > > > > > >> > > > >>
>> > > >>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris
>> > Egerton
>> > > <
>> > > >>> > > > > > > > > > >> fearthecellos@gmail.com>
>> > > >>> > > > > > > > > > >> > > > wrote:
>> > > >>> > > > > > > > > > >> > > > >>
>> > > >>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
>> > > >>> > > > > > > > > > >> > > > >>>
>> > > >>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill
>> > Bejeck <
>> > > >>> > > > > > > bbejeck@gmail.com
>> > > >>> > > > > > > > >
>> > > >>> > > > > > > > > > >> wrote:
>> > > >>> > > > > > > > > > >> > > > >>>
>> > > >>> > > > > > > > > > >> > > > >>>> +1
>> > > >>> > > > > > > > > > >> > > > >>>>
>> > > >>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
>> > > >>> > > > > > > > > > >> > > > >>>>
>> > > >>> > > > > > > > > > >> > > > >>>> -Bill
>> > > >>> > > > > > > > > > >> > > > >>>>
>> > > >>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael
>> > > >>> Juma <
>> > > >>> > > > > > > > > > me@ismaeljuma.com>
>> > > >>> > > > > > > > > > >> > > wrote:
>> > > >>> > > > > > > > > > >> > > > >>>>
>> > > >>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
>> > > >>> > > > > > > > > > >> > > > >>>>>
>> > > >>> > > > > > > > > > >> > > > >>>>> Ismael
>> > > >>> > > > > > > > > > >> > > > >>>>>
>> > > >>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM
>> > > >>> Stanislav
>> > > >>> > > > > Kozlovski
>> > > >>> > > > > > > > > > >> > > > >>>>> <st...@confluent.io.invalid>
>> > > 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
>> > > >>> > > > > > > > > > >> > > > >>>>>>
>> > > >>> > > > > > > > > > >> > > > >>>>>
>> > > >>> > > > > > > > > > >> > > > >>>>
>> > > >>> > > > > > > > > > >> > > > >>>
>> > > >>> > > > > > > > > > >> > > > >>
>> > > >>> > > > > > > > > > >> > > > >
>> > > >>> > > > > > > > > > >> > > >
>> > > >>> > > > > > > > > > >> > >
>> > > >>> > > > > > > > > > >> > >
>> > > >>> > > > > > > > > > >> > > --
>> > > >>> > > > > > > > > > >> > > Best,
>> > > >>> > > > > > > > > > >> > > Stanislav
>> > > >>> > > > > > > > > > >> > >
>> > > >>> > > > > > > > > > >> >
>> > > >>> > > > > > > > > > >>
>> > > >>> > > > > > > > > > >>
>> > > >>> > > > > > > > > > >> --
>> > > >>> > > > > > > > > > >> Best,
>> > > >>> > > > > > > > > > >> Stanislav
>> > > >>> > > > > > > > > > >>
>> > > >>> > > > > > > > > > >
>> > > >>> > > > > > > > > >
>> > > >>> > > > > > > > >
>> > > >>> > > > > > > > >
>> > > >>> > > > > > > > > --
>> > > >>> > > > > > > > > Best,
>> > > >>> > > > > > > > > Stanislav
>> > > >>> > > > > > > > >
>> > > >>> > > > > > > >
>> > > >>> > > > > > >
>> > > >>> > > > > > >
>> > > >>> > > > > > > --
>> > > >>> > > > > > > Best,
>> > > >>> > > > > > > Stanislav
>> > > >>> > > > > > >
>> > > >>> > > > > >
>> > > >>> > > > >
>> > > >>> > > >
>> > > >>> > >
>> > > >>> > >
>> > > >>> > > --
>> > > >>> > > Best,
>> > > >>> > > Stanislav
>> > > >>> > >
>> > > >>> >
>> > > >>> >
>> > > >>> > --
>> > > >>> > Regards,
>> > > >>> > Mayank Shekhar Narula
>> > > >>> >
>> > > >>>
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Best,
>> > > >> Stanislav
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > Best,
>> > > > Stanislav
>> > > >
>> > >
>> > >
>> > > --
>> > > Best,
>> > > Stanislav
>> > >
>> >

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <mi...@gmail.com>
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 <me...@ismaeljuma.com> 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
> > <vi...@cloudera.com.invalid> 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
> > > <st...@confluent.io.invalid> 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
> > > > <https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh>.
> > > >
> > > > Best,
> > > > Stanislav
> > > >
> > > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> > > > stanislav@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 <
> > > > > stanislav@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
> > > > >> <
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> > > >.
> > > > >>
> > > > >> Thanks for your contributions once again!
> > > > >> Best,
> > > > >> Stan
> > > > >>
> > > > >>
> > > > >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
> nick.telford@gmail.com>
> > > > >> 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.narula@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
> > > > >>> > <st...@confluent.io.invalid> 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 <
> > > > >>> > sophie@responsive.dev>
> > > > >>> > > wrote:
> > > > >>> > >
> > > > >>> > > > Looks great, thank you! +1
> > > > >>> > > >
> > > > >>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> > > > >>> > <djacot@confluent.io.invalid
> > > > >>> > > >
> > > > >>> > > > wrote:
> > > > >>> > > >
> > > > >>> > > > > +1 from me as well. Thanks, Stan!
> > > > >>> > > > >
> > > > >>> > > > > David
> > > > >>> > > > >
> > > > >>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
> > > me@ismaeljuma.com>
> > > > >>> > wrote:
> > > > >>> > > > >
> > > > >>> > > > > > Thanks Stanislav, +1
> > > > >>> > > > > >
> > > > >>> > > > > > Ismael
> > > > >>> > > > > >
> > > > >>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > > > >>> > > > > > <st...@confluent.io.invalid> 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
> <
> > > > >>> > > > > > > sophie@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
> > > > >>> > > > > > > > <st...@confluent.io.invalid> 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 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
> > > <
> > > > >>> > > > > > > > > sophie@responsive.dev>
> > > > >>> > > > > > > > > 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 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 <
> > > > >>> > > > > > > > > sophie@responsive.dev
> > > > >>> > > > > > > > > > >
> > > > >>> > > > > > > > > > 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
> > > > >>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
> > > > >>> > > > > > > > > fearthecellos@gmail.com>
> > > > >>> > > > > > > > > > >> 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
> > > > >>> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
> > > > >>> > > > > > > > > > >> > > <
> > > > >>> > > > > > > > > >
> > > > >>> > > > > >
> > > > >>> >
> > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > > > >>> > > > > > > >
> > > > >>> > > > > > > > > > >> -
> > > > >>> > > > > > > > > > >> > > 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
> > > > <
> > > > >>> > > > > > > > cadonna@apache.org
> > > > >>> > > > > > > > > >
> > > > >>> > > > > > > > > > >> > 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
> > > > >>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
> > > > >>> > > > > > > > > > >> > > >
> > > > >>> > > > > > > > > > >> > > > > 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.prat@aiven.io
> > > > >>> > > > > > > > > > >> > > > >>
> > > > >>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris
> > > Egerton
> > > > <
> > > > >>> > > > > > > > > > >> fearthecellos@gmail.com>
> > > > >>> > > > > > > > > > >> > > > wrote:
> > > > >>> > > > > > > > > > >> > > > >>
> > > > >>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
> > > > >>> > > > > > > > > > >> > > > >>>
> > > > >>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill
> > > Bejeck <
> > > > >>> > > > > > > bbejeck@gmail.com
> > > > >>> > > > > > > > >
> > > > >>> > > > > > > > > > >> wrote:
> > > > >>> > > > > > > > > > >> > > > >>>
> > > > >>> > > > > > > > > > >> > > > >>>> +1
> > > > >>> > > > > > > > > > >> > > > >>>>
> > > > >>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
> > > > >>> > > > > > > > > > >> > > > >>>>
> > > > >>> > > > > > > > > > >> > > > >>>> -Bill
> > > > >>> > > > > > > > > > >> > > > >>>>
> > > > >>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM
> Ismael
> > > > >>> Juma <
> > > > >>> > > > > > > > > > me@ismaeljuma.com>
> > > > >>> > > > > > > > > > >> > > wrote:
> > > > >>> > > > > > > > > > >> > > > >>>>
> > > > >>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering
> Stanislav!
> > > > >>> > > > > > > > > > >> > > > >>>>>
> > > > >>> > > > > > > > > > >> > > > >>>>> Ismael
> > > > >>> > > > > > > > > > >> > > > >>>>>
> > > > >>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM
> > > > >>> Stanislav
> > > > >>> > > > > Kozlovski
> > > > >>> > > > > > > > > > >> > > > >>>>> <stanislav@confluent.io
> .invalid>
> > > > 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
> > > > >>> > > > > > > > > > >> > > > >>>>>>
> > > > >>> > > > > > > > > > >> > > > >>>>>
> > > > >>> > > > > > > > > > >> > > > >>>>
> > > > >>> > > > > > > > > > >> > > > >>>
> > > > >>> > > > > > > > > > >> > > > >>
> > > > >>> > > > > > > > > > >> > > > >
> > > > >>> > > > > > > > > > >> > > >
> > > > >>> > > > > > > > > > >> > >
> > > > >>> > > > > > > > > > >> > >
> > > > >>> > > > > > > > > > >> > > --
> > > > >>> > > > > > > > > > >> > > Best,
> > > > >>> > > > > > > > > > >> > > Stanislav
> > > > >>> > > > > > > > > > >> > >
> > > > >>> > > > > > > > > > >> >
> > > > >>> > > > > > > > > > >>
> > > > >>> > > > > > > > > > >>
> > > > >>> > > > > > > > > > >> --
> > > > >>> > > > > > > > > > >> Best,
> > > > >>> > > > > > > > > > >> Stanislav
> > > > >>> > > > > > > > > > >>
> > > > >>> > > > > > > > > > >
> > > > >>> > > > > > > > > >
> > > > >>> > > > > > > > >
> > > > >>> > > > > > > > >
> > > > >>> > > > > > > > > --
> > > > >>> > > > > > > > > Best,
> > > > >>> > > > > > > > > Stanislav
> > > > >>> > > > > > > > >
> > > > >>> > > > > > > >
> > > > >>> > > > > > >
> > > > >>> > > > > > >
> > > > >>> > > > > > > --
> > > > >>> > > > > > > Best,
> > > > >>> > > > > > > Stanislav
> > > > >>> > > > > > >
> > > > >>> > > > > >
> > > > >>> > > > >
> > > > >>> > > >
> > > > >>> > >
> > > > >>> > >
> > > > >>> > > --
> > > > >>> > > Best,
> > > > >>> > > Stanislav
> > > > >>> > >
> > > > >>> >
> > > > >>> >
> > > > >>> > --
> > > > >>> > Regards,
> > > > >>> > Mayank Shekhar Narula
> > > > >>> >
> > > > >>>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Best,
> > > > >> Stanislav
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Best,
> > > > > Stanislav
> > > > >
> > > >
> > > >
> > > > --
> > > > Best,
> > > > Stanislav
> > > >
> > >
>
>

-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Mickael Maison <mi...@gmail.com>]

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 <me...@ismaeljuma.com> 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
> <vi...@cloudera.com.invalid> 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
> > <st...@confluent.io.invalid> 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
> > > <https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh>.
> > >
> > > Best,
> > > Stanislav
> > >
> > > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> > > stanislav@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 <
> > > > stanislav@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
> > > >> <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> > >.
> > > >>
> > > >> Thanks for your contributions once again!
> > > >> Best,
> > > >> Stan
> > > >>
> > > >>
> > > >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <ni...@gmail.com>
> > > >> 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.narula@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
> > > >>> > <st...@confluent.io.invalid> 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 <
> > > >>> > sophie@responsive.dev>
> > > >>> > > wrote:
> > > >>> > >
> > > >>> > > > Looks great, thank you! +1
> > > >>> > > >
> > > >>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> > > >>> > <djacot@confluent.io.invalid
> > > >>> > > >
> > > >>> > > > wrote:
> > > >>> > > >
> > > >>> > > > > +1 from me as well. Thanks, Stan!
> > > >>> > > > >
> > > >>> > > > > David
> > > >>> > > > >
> > > >>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
> > me@ismaeljuma.com>
> > > >>> > wrote:
> > > >>> > > > >
> > > >>> > > > > > Thanks Stanislav, +1
> > > >>> > > > > >
> > > >>> > > > > > Ismael
> > > >>> > > > > >
> > > >>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > > >>> > > > > > <st...@confluent.io.invalid> 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 <
> > > >>> > > > > > > sophie@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
> > > >>> > > > > > > > <st...@confluent.io.invalid> 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 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
> > <
> > > >>> > > > > > > > > sophie@responsive.dev>
> > > >>> > > > > > > > > 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 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 <
> > > >>> > > > > > > > > sophie@responsive.dev
> > > >>> > > > > > > > > > >
> > > >>> > > > > > > > > > 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
> > > >>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
> > > >>> > > > > > > > > fearthecellos@gmail.com>
> > > >>> > > > > > > > > > >> 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
> > > >>> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
> > > >>> > > > > > > > > > >> > > <
> > > >>> > > > > > > > > >
> > > >>> > > > > >
> > > >>> >
> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > > >>> > > > > > > >
> > > >>> > > > > > > > > > >> -
> > > >>> > > > > > > > > > >> > > 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
> > > <
> > > >>> > > > > > > > cadonna@apache.org
> > > >>> > > > > > > > > >
> > > >>> > > > > > > > > > >> > 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
> > > >>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
> > > >>> > > > > > > > > > >> > > >
> > > >>> > > > > > > > > > >> > > > > 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.prat@aiven.io
> > > >>> > > > > > > > > > >> > > > >>
> > > >>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris
> > Egerton
> > > <
> > > >>> > > > > > > > > > >> fearthecellos@gmail.com>
> > > >>> > > > > > > > > > >> > > > wrote:
> > > >>> > > > > > > > > > >> > > > >>
> > > >>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
> > > >>> > > > > > > > > > >> > > > >>>
> > > >>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill
> > Bejeck <
> > > >>> > > > > > > bbejeck@gmail.com
> > > >>> > > > > > > > >
> > > >>> > > > > > > > > > >> wrote:
> > > >>> > > > > > > > > > >> > > > >>>
> > > >>> > > > > > > > > > >> > > > >>>> +1
> > > >>> > > > > > > > > > >> > > > >>>>
> > > >>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
> > > >>> > > > > > > > > > >> > > > >>>>
> > > >>> > > > > > > > > > >> > > > >>>> -Bill
> > > >>> > > > > > > > > > >> > > > >>>>
> > > >>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael
> > > >>> Juma <
> > > >>> > > > > > > > > > me@ismaeljuma.com>
> > > >>> > > > > > > > > > >> > > wrote:
> > > >>> > > > > > > > > > >> > > > >>>>
> > > >>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > >>> > > > > > > > > > >> > > > >>>>>
> > > >>> > > > > > > > > > >> > > > >>>>> Ismael
> > > >>> > > > > > > > > > >> > > > >>>>>
> > > >>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM
> > > >>> Stanislav
> > > >>> > > > > Kozlovski
> > > >>> > > > > > > > > > >> > > > >>>>> <st...@confluent.io.invalid>
> > > 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
> > > >>> > > > > > > > > > >> > > > >>>>>>
> > > >>> > > > > > > > > > >> > > > >>>>>
> > > >>> > > > > > > > > > >> > > > >>>>
> > > >>> > > > > > > > > > >> > > > >>>
> > > >>> > > > > > > > > > >> > > > >>
> > > >>> > > > > > > > > > >> > > > >
> > > >>> > > > > > > > > > >> > > >
> > > >>> > > > > > > > > > >> > >
> > > >>> > > > > > > > > > >> > >
> > > >>> > > > > > > > > > >> > > --
> > > >>> > > > > > > > > > >> > > Best,
> > > >>> > > > > > > > > > >> > > Stanislav
> > > >>> > > > > > > > > > >> > >
> > > >>> > > > > > > > > > >> >
> > > >>> > > > > > > > > > >>
> > > >>> > > > > > > > > > >>
> > > >>> > > > > > > > > > >> --
> > > >>> > > > > > > > > > >> Best,
> > > >>> > > > > > > > > > >> Stanislav
> > > >>> > > > > > > > > > >>
> > > >>> > > > > > > > > > >
> > > >>> > > > > > > > > >
> > > >>> > > > > > > > >
> > > >>> > > > > > > > >
> > > >>> > > > > > > > > --
> > > >>> > > > > > > > > Best,
> > > >>> > > > > > > > > Stanislav
> > > >>> > > > > > > > >
> > > >>> > > > > > > >
> > > >>> > > > > > >
> > > >>> > > > > > >
> > > >>> > > > > > > --
> > > >>> > > > > > > Best,
> > > >>> > > > > > > Stanislav
> > > >>> > > > > > >
> > > >>> > > > > >
> > > >>> > > > >
> > > >>> > > >
> > > >>> > >
> > > >>> > >
> > > >>> > > --
> > > >>> > > Best,
> > > >>> > > Stanislav
> > > >>> > >
> > > >>> >
> > > >>> >
> > > >>> > --
> > > >>> > Regards,
> > > >>> > Mayank Shekhar Narula
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Best,
> > > >> Stanislav
> > > >>
> > > >
> > > >
> > > > --
> > > > Best,
> > > > Stanislav
> > > >
> > >
> > >
> > > --
> > > Best,
> > > Stanislav
> > >
> >

Re: Apache Kafka 3.7.0 Release

[Ismael Juma <me...@ismaeljuma.com>]

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
<vi...@cloudera.com.invalid> 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
> <st...@confluent.io.invalid> 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
> > <https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh>.
> >
> > Best,
> > Stanislav
> >
> > On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> > stanislav@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 <
> > > stanislav@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
> > >> <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
> >.
> > >>
> > >> Thanks for your contributions once again!
> > >> Best,
> > >> Stan
> > >>
> > >>
> > >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <ni...@gmail.com>
> > >> 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.narula@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
> > >>> > <st...@confluent.io.invalid> 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 <
> > >>> > sophie@responsive.dev>
> > >>> > > wrote:
> > >>> > >
> > >>> > > > Looks great, thank you! +1
> > >>> > > >
> > >>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> > >>> > <djacot@confluent.io.invalid
> > >>> > > >
> > >>> > > > wrote:
> > >>> > > >
> > >>> > > > > +1 from me as well. Thanks, Stan!
> > >>> > > > >
> > >>> > > > > David
> > >>> > > > >
> > >>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
> me@ismaeljuma.com>
> > >>> > wrote:
> > >>> > > > >
> > >>> > > > > > Thanks Stanislav, +1
> > >>> > > > > >
> > >>> > > > > > Ismael
> > >>> > > > > >
> > >>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > >>> > > > > > <st...@confluent.io.invalid> 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 <
> > >>> > > > > > > sophie@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
> > >>> > > > > > > > <st...@confluent.io.invalid> 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 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
> <
> > >>> > > > > > > > > sophie@responsive.dev>
> > >>> > > > > > > > > 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 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 <
> > >>> > > > > > > > > sophie@responsive.dev
> > >>> > > > > > > > > > >
> > >>> > > > > > > > > > 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
> > >>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
> > >>> > > > > > > > > fearthecellos@gmail.com>
> > >>> > > > > > > > > > >> 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
> > >>> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
> > >>> > > > > > > > > > >> > > <
> > >>> > > > > > > > > >
> > >>> > > > > >
> > >>> >
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > >>> > > > > > > >
> > >>> > > > > > > > > > >> -
> > >>> > > > > > > > > > >> > > 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
> > <
> > >>> > > > > > > > cadonna@apache.org
> > >>> > > > > > > > > >
> > >>> > > > > > > > > > >> > 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
> > >>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
> > >>> > > > > > > > > > >> > > >
> > >>> > > > > > > > > > >> > > > > 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.prat@aiven.io
> > >>> > > > > > > > > > >> > > > >>
> > >>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris
> Egerton
> > <
> > >>> > > > > > > > > > >> fearthecellos@gmail.com>
> > >>> > > > > > > > > > >> > > > wrote:
> > >>> > > > > > > > > > >> > > > >>
> > >>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
> > >>> > > > > > > > > > >> > > > >>>
> > >>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill
> Bejeck <
> > >>> > > > > > > bbejeck@gmail.com
> > >>> > > > > > > > >
> > >>> > > > > > > > > > >> wrote:
> > >>> > > > > > > > > > >> > > > >>>
> > >>> > > > > > > > > > >> > > > >>>> +1
> > >>> > > > > > > > > > >> > > > >>>>
> > >>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
> > >>> > > > > > > > > > >> > > > >>>>
> > >>> > > > > > > > > > >> > > > >>>> -Bill
> > >>> > > > > > > > > > >> > > > >>>>
> > >>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael
> > >>> Juma <
> > >>> > > > > > > > > > me@ismaeljuma.com>
> > >>> > > > > > > > > > >> > > wrote:
> > >>> > > > > > > > > > >> > > > >>>>
> > >>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > >>> > > > > > > > > > >> > > > >>>>>
> > >>> > > > > > > > > > >> > > > >>>>> Ismael
> > >>> > > > > > > > > > >> > > > >>>>>
> > >>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM
> > >>> Stanislav
> > >>> > > > > Kozlovski
> > >>> > > > > > > > > > >> > > > >>>>> <st...@confluent.io.invalid>
> > 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
> > >>> > > > > > > > > > >> > > > >>>>>>
> > >>> > > > > > > > > > >> > > > >>>>>
> > >>> > > > > > > > > > >> > > > >>>>
> > >>> > > > > > > > > > >> > > > >>>
> > >>> > > > > > > > > > >> > > > >>
> > >>> > > > > > > > > > >> > > > >
> > >>> > > > > > > > > > >> > > >
> > >>> > > > > > > > > > >> > >
> > >>> > > > > > > > > > >> > >
> > >>> > > > > > > > > > >> > > --
> > >>> > > > > > > > > > >> > > Best,
> > >>> > > > > > > > > > >> > > Stanislav
> > >>> > > > > > > > > > >> > >
> > >>> > > > > > > > > > >> >
> > >>> > > > > > > > > > >>
> > >>> > > > > > > > > > >>
> > >>> > > > > > > > > > >> --
> > >>> > > > > > > > > > >> Best,
> > >>> > > > > > > > > > >> Stanislav
> > >>> > > > > > > > > > >>
> > >>> > > > > > > > > > >
> > >>> > > > > > > > > >
> > >>> > > > > > > > >
> > >>> > > > > > > > >
> > >>> > > > > > > > > --
> > >>> > > > > > > > > Best,
> > >>> > > > > > > > > Stanislav
> > >>> > > > > > > > >
> > >>> > > > > > > >
> > >>> > > > > > >
> > >>> > > > > > >
> > >>> > > > > > > --
> > >>> > > > > > > Best,
> > >>> > > > > > > Stanislav
> > >>> > > > > > >
> > >>> > > > > >
> > >>> > > > >
> > >>> > > >
> > >>> > >
> > >>> > >
> > >>> > > --
> > >>> > > Best,
> > >>> > > Stanislav
> > >>> > >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Regards,
> > >>> > Mayank Shekhar Narula
> > >>> >
> > >>>
> > >>
> > >>
> > >> --
> > >> Best,
> > >> Stanislav
> > >>
> > >
> > >
> > > --
> > > Best,
> > > Stanislav
> > >
> >
> >
> > --
> > Best,
> > Stanislav
> >
>

Re: Apache Kafka 3.7.0 Release

[Viktor Somogyi-Vass <vi...@cloudera.com.INVALID>]

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
<st...@confluent.io.invalid> 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
> <https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh>.
>
> Best,
> Stanislav
>
> On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
> stanislav@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 <
> > stanislav@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
> >> <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0>.
> >>
> >> Thanks for your contributions once again!
> >> Best,
> >> Stan
> >>
> >>
> >> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <ni...@gmail.com>
> >> 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.narula@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
> >>> > <st...@confluent.io.invalid> 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 <
> >>> > sophie@responsive.dev>
> >>> > > wrote:
> >>> > >
> >>> > > > Looks great, thank you! +1
> >>> > > >
> >>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> >>> > <djacot@confluent.io.invalid
> >>> > > >
> >>> > > > wrote:
> >>> > > >
> >>> > > > > +1 from me as well. Thanks, Stan!
> >>> > > > >
> >>> > > > > David
> >>> > > > >
> >>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <me...@ismaeljuma.com>
> >>> > wrote:
> >>> > > > >
> >>> > > > > > Thanks Stanislav, +1
> >>> > > > > >
> >>> > > > > > Ismael
> >>> > > > > >
> >>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> >>> > > > > > <st...@confluent.io.invalid> 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 <
> >>> > > > > > > sophie@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
> >>> > > > > > > > <st...@confluent.io.invalid> 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 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 <
> >>> > > > > > > > > sophie@responsive.dev>
> >>> > > > > > > > > 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 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 <
> >>> > > > > > > > > sophie@responsive.dev
> >>> > > > > > > > > > >
> >>> > > > > > > > > > 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
> >>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
> >>> > > > > > > > > fearthecellos@gmail.com>
> >>> > > > > > > > > > >> 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
> >>> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
> >>> > > > > > > > > > >> > > <
> >>> > > > > > > > > >
> >>> > > > > >
> >>> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> >>> > > > > > > >
> >>> > > > > > > > > > >> -
> >>> > > > > > > > > > >> > > 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
> <
> >>> > > > > > > > cadonna@apache.org
> >>> > > > > > > > > >
> >>> > > > > > > > > > >> > 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
> >>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
> >>> > > > > > > > > > >> > > >
> >>> > > > > > > > > > >> > > > > 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.prat@aiven.io
> >>> > > > > > > > > > >> > > > >>
> >>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton
> <
> >>> > > > > > > > > > >> fearthecellos@gmail.com>
> >>> > > > > > > > > > >> > > > wrote:
> >>> > > > > > > > > > >> > > > >>
> >>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
> >>> > > > > > > > > > >> > > > >>>
> >>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
> >>> > > > > > > bbejeck@gmail.com
> >>> > > > > > > > >
> >>> > > > > > > > > > >> wrote:
> >>> > > > > > > > > > >> > > > >>>
> >>> > > > > > > > > > >> > > > >>>> +1
> >>> > > > > > > > > > >> > > > >>>>
> >>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
> >>> > > > > > > > > > >> > > > >>>>
> >>> > > > > > > > > > >> > > > >>>> -Bill
> >>> > > > > > > > > > >> > > > >>>>
> >>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael
> >>> Juma <
> >>> > > > > > > > > > me@ismaeljuma.com>
> >>> > > > > > > > > > >> > > wrote:
> >>> > > > > > > > > > >> > > > >>>>
> >>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> >>> > > > > > > > > > >> > > > >>>>>
> >>> > > > > > > > > > >> > > > >>>>> Ismael
> >>> > > > > > > > > > >> > > > >>>>>
> >>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM
> >>> Stanislav
> >>> > > > > Kozlovski
> >>> > > > > > > > > > >> > > > >>>>> <st...@confluent.io.invalid>
> 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
> >>> > > > > > > > > > >> > > > >>>>>>
> >>> > > > > > > > > > >> > > > >>>>>
> >>> > > > > > > > > > >> > > > >>>>
> >>> > > > > > > > > > >> > > > >>>
> >>> > > > > > > > > > >> > > > >>
> >>> > > > > > > > > > >> > > > >
> >>> > > > > > > > > > >> > > >
> >>> > > > > > > > > > >> > >
> >>> > > > > > > > > > >> > >
> >>> > > > > > > > > > >> > > --
> >>> > > > > > > > > > >> > > Best,
> >>> > > > > > > > > > >> > > Stanislav
> >>> > > > > > > > > > >> > >
> >>> > > > > > > > > > >> >
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >> --
> >>> > > > > > > > > > >> Best,
> >>> > > > > > > > > > >> Stanislav
> >>> > > > > > > > > > >>
> >>> > > > > > > > > > >
> >>> > > > > > > > > >
> >>> > > > > > > > >
> >>> > > > > > > > >
> >>> > > > > > > > > --
> >>> > > > > > > > > Best,
> >>> > > > > > > > > Stanislav
> >>> > > > > > > > >
> >>> > > > > > > >
> >>> > > > > > >
> >>> > > > > > >
> >>> > > > > > > --
> >>> > > > > > > Best,
> >>> > > > > > > Stanislav
> >>> > > > > > >
> >>> > > > > >
> >>> > > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> > > --
> >>> > > Best,
> >>> > > Stanislav
> >>> > >
> >>> >
> >>> >
> >>> > --
> >>> > Regards,
> >>> > Mayank Shekhar Narula
> >>> >
> >>>
> >>
> >>
> >> --
> >> Best,
> >> Stanislav
> >>
> >
> >
> > --
> > Best,
> > Stanislav
> >
>
>
> --
> Best,
> Stanislav
>

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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
<https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh>.

Best,
Stanislav

On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <st...@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 <
> stanislav@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
>> <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0>.
>>
>> Thanks for your contributions once again!
>> Best,
>> Stan
>>
>>
>> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <ni...@gmail.com>
>> 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.narula@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
>>> > <st...@confluent.io.invalid> 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 <
>>> > sophie@responsive.dev>
>>> > > wrote:
>>> > >
>>> > > > Looks great, thank you! +1
>>> > > >
>>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
>>> > <djacot@confluent.io.invalid
>>> > > >
>>> > > > wrote:
>>> > > >
>>> > > > > +1 from me as well. Thanks, Stan!
>>> > > > >
>>> > > > > David
>>> > > > >
>>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <me...@ismaeljuma.com>
>>> > wrote:
>>> > > > >
>>> > > > > > Thanks Stanislav, +1
>>> > > > > >
>>> > > > > > Ismael
>>> > > > > >
>>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
>>> > > > > > <st...@confluent.io.invalid> 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 <
>>> > > > > > > sophie@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
>>> > > > > > > > <st...@confluent.io.invalid> 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 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 <
>>> > > > > > > > > sophie@responsive.dev>
>>> > > > > > > > > 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 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 <
>>> > > > > > > > > sophie@responsive.dev
>>> > > > > > > > > > >
>>> > > > > > > > > > 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
>>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
>>> > > > > > > > > fearthecellos@gmail.com>
>>> > > > > > > > > > >> 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
>>> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
>>> > > > > > > > > > >> > > <
>>> > > > > > > > > >
>>> > > > > >
>>> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
>>> > > > > > > >
>>> > > > > > > > > > >> -
>>> > > > > > > > > > >> > > 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 <
>>> > > > > > > > cadonna@apache.org
>>> > > > > > > > > >
>>> > > > > > > > > > >> > 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
>>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
>>> > > > > > > > > > >> > > >
>>> > > > > > > > > > >> > > > > 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.prat@aiven.io
>>> > > > > > > > > > >> > > > >>
>>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
>>> > > > > > > > > > >> fearthecellos@gmail.com>
>>> > > > > > > > > > >> > > > wrote:
>>> > > > > > > > > > >> > > > >>
>>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
>>> > > > > > > > > > >> > > > >>>
>>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
>>> > > > > > > bbejeck@gmail.com
>>> > > > > > > > >
>>> > > > > > > > > > >> wrote:
>>> > > > > > > > > > >> > > > >>>
>>> > > > > > > > > > >> > > > >>>> +1
>>> > > > > > > > > > >> > > > >>>>
>>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
>>> > > > > > > > > > >> > > > >>>>
>>> > > > > > > > > > >> > > > >>>> -Bill
>>> > > > > > > > > > >> > > > >>>>
>>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael
>>> Juma <
>>> > > > > > > > > > me@ismaeljuma.com>
>>> > > > > > > > > > >> > > wrote:
>>> > > > > > > > > > >> > > > >>>>
>>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
>>> > > > > > > > > > >> > > > >>>>>
>>> > > > > > > > > > >> > > > >>>>> Ismael
>>> > > > > > > > > > >> > > > >>>>>
>>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM
>>> Stanislav
>>> > > > > Kozlovski
>>> > > > > > > > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
>>> > > > > > > > > > >> > > > >>>>>>
>>> > > > > > > > > > >> > > > >>>>>
>>> > > > > > > > > > >> > > > >>>>
>>> > > > > > > > > > >> > > > >>>
>>> > > > > > > > > > >> > > > >>
>>> > > > > > > > > > >> > > > >
>>> > > > > > > > > > >> > > >
>>> > > > > > > > > > >> > >
>>> > > > > > > > > > >> > >
>>> > > > > > > > > > >> > > --
>>> > > > > > > > > > >> > > Best,
>>> > > > > > > > > > >> > > Stanislav
>>> > > > > > > > > > >> > >
>>> > > > > > > > > > >> >
>>> > > > > > > > > > >>
>>> > > > > > > > > > >>
>>> > > > > > > > > > >> --
>>> > > > > > > > > > >> Best,
>>> > > > > > > > > > >> Stanislav
>>> > > > > > > > > > >>
>>> > > > > > > > > > >
>>> > > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > > > --
>>> > > > > > > > > Best,
>>> > > > > > > > > Stanislav
>>> > > > > > > > >
>>> > > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > --
>>> > > > > > > Best,
>>> > > > > > > Stanislav
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> > >
>>> > > --
>>> > > Best,
>>> > > Stanislav
>>> > >
>>> >
>>> >
>>> > --
>>> > Regards,
>>> > Mayank Shekhar Narula
>>> >
>>>
>>
>>
>> --
>> Best,
>> Stanislav
>>
>
>
> --
> Best,
> Stanislav
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <st...@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
> <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0>.
>
> Thanks for your contributions once again!
> Best,
> Stan
>
>
> On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <ni...@gmail.com>
> 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.narula@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
>> > <st...@confluent.io.invalid> 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 <
>> > sophie@responsive.dev>
>> > > wrote:
>> > >
>> > > > Looks great, thank you! +1
>> > > >
>> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
>> > <djacot@confluent.io.invalid
>> > > >
>> > > > wrote:
>> > > >
>> > > > > +1 from me as well. Thanks, Stan!
>> > > > >
>> > > > > David
>> > > > >
>> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <me...@ismaeljuma.com>
>> > wrote:
>> > > > >
>> > > > > > Thanks Stanislav, +1
>> > > > > >
>> > > > > > Ismael
>> > > > > >
>> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
>> > > > > > <st...@confluent.io.invalid> 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 <
>> > > > > > > sophie@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
>> > > > > > > > <st...@confluent.io.invalid> 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 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 <
>> > > > > > > > > sophie@responsive.dev>
>> > > > > > > > > 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 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 <
>> > > > > > > > > sophie@responsive.dev
>> > > > > > > > > > >
>> > > > > > > > > > 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
>> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
>> > > > > > > > > fearthecellos@gmail.com>
>> > > > > > > > > > >> 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
>> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
>> > > > > > > > > > >> > > <
>> > > > > > > > > >
>> > > > > >
>> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
>> > > > > > > >
>> > > > > > > > > > >> -
>> > > > > > > > > > >> > > 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 <
>> > > > > > > > cadonna@apache.org
>> > > > > > > > > >
>> > > > > > > > > > >> > 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
>> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
>> > > > > > > > > > >> > > >
>> > > > > > > > > > >> > > > > 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.prat@aiven.io
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
>> > > > > > > > > > >> fearthecellos@gmail.com>
>> > > > > > > > > > >> > > > wrote:
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
>> > > > > > > > > > >> > > > >>>
>> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
>> > > > > > > bbejeck@gmail.com
>> > > > > > > > >
>> > > > > > > > > > >> wrote:
>> > > > > > > > > > >> > > > >>>
>> > > > > > > > > > >> > > > >>>> +1
>> > > > > > > > > > >> > > > >>>>
>> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
>> > > > > > > > > > >> > > > >>>>
>> > > > > > > > > > >> > > > >>>> -Bill
>> > > > > > > > > > >> > > > >>>>
>> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael
>> Juma <
>> > > > > > > > > > me@ismaeljuma.com>
>> > > > > > > > > > >> > > wrote:
>> > > > > > > > > > >> > > > >>>>
>> > > > > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
>> > > > > > > > > > >> > > > >>>>>
>> > > > > > > > > > >> > > > >>>>> Ismael
>> > > > > > > > > > >> > > > >>>>>
>> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav
>> > > > > Kozlovski
>> > > > > > > > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
>> > > > > > > > > > >> > > > >>>>>>
>> > > > > > > > > > >> > > > >>>>>
>> > > > > > > > > > >> > > > >>>>
>> > > > > > > > > > >> > > > >>>
>> > > > > > > > > > >> > > > >>
>> > > > > > > > > > >> > > > >
>> > > > > > > > > > >> > > >
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > > --
>> > > > > > > > > > >> > > Best,
>> > > > > > > > > > >> > > Stanislav
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> >
>> > > > > > > > > > >>
>> > > > > > > > > > >>
>> > > > > > > > > > >> --
>> > > > > > > > > > >> Best,
>> > > > > > > > > > >> Stanislav
>> > > > > > > > > > >>
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > --
>> > > > > > > > > Best,
>> > > > > > > > > Stanislav
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Best,
>> > > > > > > Stanislav
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Best,
>> > > Stanislav
>> > >
>> >
>> >
>> > --
>> > Regards,
>> > Mayank Shekhar Narula
>> >
>>
>
>
> --
> Best,
> Stanislav
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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
<https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0>.

Thanks for your contributions once again!
Best,
Stan


On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <ni...@gmail.com> 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.narula@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
> > <st...@confluent.io.invalid> 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 <
> > sophie@responsive.dev>
> > > wrote:
> > >
> > > > Looks great, thank you! +1
> > > >
> > > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> > <djacot@confluent.io.invalid
> > > >
> > > > wrote:
> > > >
> > > > > +1 from me as well. Thanks, Stan!
> > > > >
> > > > > David
> > > > >
> > > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <me...@ismaeljuma.com>
> > wrote:
> > > > >
> > > > > > Thanks Stanislav, +1
> > > > > >
> > > > > > Ismael
> > > > > >
> > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > > > > > <st...@confluent.io.invalid> 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 <
> > > > > > > sophie@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
> > > > > > > > <st...@confluent.io.invalid> 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 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 <
> > > > > > > > > sophie@responsive.dev>
> > > > > > > > > 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 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 <
> > > > > > > > > sophie@responsive.dev
> > > > > > > > > > >
> > > > > > > > > > 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
> > > > > > > > > > > <st...@confluent.io.invalid> 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 <
> > > > > > > > > fearthecellos@gmail.com>
> > > > > > > > > > >> 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
> > > > > > > > > > >> > <st...@confluent.io.invalid> 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
> > > > > > > > > > >> > > <
> > > > > > > > > >
> > > > > >
> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > > > > > > >
> > > > > > > > > > >> -
> > > > > > > > > > >> > > 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 <
> > > > > > > > cadonna@apache.org
> > > > > > > > > >
> > > > > > > > > > >> > 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
> > > > > > > > > > >> > <josep.prat@aiven.io.invalid
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > > 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.prat@aiven.io
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > > > > > > > > >> fearthecellos@gmail.com>
> > > > > > > > > > >> > > > wrote:
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >>> +1, thanks Stanislav!
> > > > > > > > > > >> > > > >>>
> > > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
> > > > > > > bbejeck@gmail.com
> > > > > > > > >
> > > > > > > > > > >> wrote:
> > > > > > > > > > >> > > > >>>
> > > > > > > > > > >> > > > >>>> +1
> > > > > > > > > > >> > > > >>>>
> > > > > > > > > > >> > > > >>>> Thanks, Stanislav!
> > > > > > > > > > >> > > > >>>>
> > > > > > > > > > >> > > > >>>> -Bill
> > > > > > > > > > >> > > > >>>>
> > > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma
> <
> > > > > > > > > > me@ismaeljuma.com>
> > > > > > > > > > >> > > wrote:
> > > > > > > > > > >> > > > >>>>
> > > > > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > > > > > > > > >> > > > >>>>>
> > > > > > > > > > >> > > > >>>>> Ismael
> > > > > > > > > > >> > > > >>>>>
> > > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav
> > > > > Kozlovski
> > > > > > > > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > > > > > > > > > >> > > > >>>>>>
> > > > > > > > > > >> > > > >>>>>
> > > > > > > > > > >> > > > >>>>
> > > > > > > > > > >> > > > >>>
> > > > > > > > > > >> > > > >>
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > --
> > > > > > > > > > >> > > Best,
> > > > > > > > > > >> > > Stanislav
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> --
> > > > > > > > > > >> Best,
> > > > > > > > > > >> Stanislav
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best,
> > > > > > > > > Stanislav
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best,
> > > > > > > Stanislav
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best,
> > > Stanislav
> > >
> >
> >
> > --
> > Regards,
> > Mayank Shekhar Narula
> >
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Nick Telford <ni...@gmail.com>]

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.narula@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
> <st...@confluent.io.invalid> 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 <
> sophie@responsive.dev>
> > wrote:
> >
> > > Looks great, thank you! +1
> > >
> > > On Thu, Nov 2, 2023 at 10:21 AM David Jacot
> <djacot@confluent.io.invalid
> > >
> > > wrote:
> > >
> > > > +1 from me as well. Thanks, Stan!
> > > >
> > > > David
> > > >
> > > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <me...@ismaeljuma.com>
> wrote:
> > > >
> > > > > Thanks Stanislav, +1
> > > > >
> > > > > Ismael
> > > > >
> > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > > > > <st...@confluent.io.invalid> 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 <
> > > > > > sophie@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
> > > > > > > <st...@confluent.io.invalid> 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 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 <
> > > > > > > > sophie@responsive.dev>
> > > > > > > > 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 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 <
> > > > > > > > sophie@responsive.dev
> > > > > > > > > >
> > > > > > > > > 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
> > > > > > > > > > <st...@confluent.io.invalid> 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 <
> > > > > > > > fearthecellos@gmail.com>
> > > > > > > > > >> 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
> > > > > > > > > >> > <st...@confluent.io.invalid> 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
> > > > > > > > > >> > > <
> > > > > > > > >
> > > > >
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > > > > > >
> > > > > > > > > >> -
> > > > > > > > > >> > > 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 <
> > > > > > > cadonna@apache.org
> > > > > > > > >
> > > > > > > > > >> > 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
> > > > > > > > > >> > <josep.prat@aiven.io.invalid
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > > 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.prat@aiven.io
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > > > > > > > >> fearthecellos@gmail.com>
> > > > > > > > > >> > > > wrote:
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >>> +1, thanks Stanislav!
> > > > > > > > > >> > > > >>>
> > > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
> > > > > > bbejeck@gmail.com
> > > > > > > >
> > > > > > > > > >> wrote:
> > > > > > > > > >> > > > >>>
> > > > > > > > > >> > > > >>>> +1
> > > > > > > > > >> > > > >>>>
> > > > > > > > > >> > > > >>>> Thanks, Stanislav!
> > > > > > > > > >> > > > >>>>
> > > > > > > > > >> > > > >>>> -Bill
> > > > > > > > > >> > > > >>>>
> > > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > > > > > > > > me@ismaeljuma.com>
> > > > > > > > > >> > > wrote:
> > > > > > > > > >> > > > >>>>
> > > > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > > > > > > > >> > > > >>>>>
> > > > > > > > > >> > > > >>>>> Ismael
> > > > > > > > > >> > > > >>>>>
> > > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav
> > > > Kozlovski
> > > > > > > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > > > > > > > > >> > > > >>>>>>
> > > > > > > > > >> > > > >>>>>
> > > > > > > > > >> > > > >>>>
> > > > > > > > > >> > > > >>>
> > > > > > > > > >> > > > >>
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> > >
> > > > > > > > > >> > > --
> > > > > > > > > >> > > Best,
> > > > > > > > > >> > > Stanislav
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> --
> > > > > > > > > >> Best,
> > > > > > > > > >> Stanislav
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best,
> > > > > > > > Stanislav
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best,
> > > > > > Stanislav
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Best,
> > Stanislav
> >
>
>
> --
> Regards,
> Mayank Shekhar Narula
>

Re: Apache Kafka 3.7.0 Release

[Mayank Shekhar Narula <ma...@gmail.com>]

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
<st...@confluent.io.invalid> 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 <so...@responsive.dev>
> wrote:
>
> > Looks great, thank you! +1
> >
> > On Thu, Nov 2, 2023 at 10:21 AM David Jacot <djacot@confluent.io.invalid
> >
> > wrote:
> >
> > > +1 from me as well. Thanks, Stan!
> > >
> > > David
> > >
> > > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <me...@ismaeljuma.com> wrote:
> > >
> > > > Thanks Stanislav, +1
> > > >
> > > > Ismael
> > > >
> > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > > > <st...@confluent.io.invalid> 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 <
> > > > > sophie@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
> > > > > > <st...@confluent.io.invalid> 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 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 <
> > > > > > > sophie@responsive.dev>
> > > > > > > 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 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 <
> > > > > > > sophie@responsive.dev
> > > > > > > > >
> > > > > > > > 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
> > > > > > > > > <st...@confluent.io.invalid> 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 <
> > > > > > > fearthecellos@gmail.com>
> > > > > > > > >> 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
> > > > > > > > >> > <st...@confluent.io.invalid> 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
> > > > > > > > >> > > <
> > > > > > > >
> > > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > > > > >
> > > > > > > > >> -
> > > > > > > > >> > > 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 <
> > > > > > cadonna@apache.org
> > > > > > > >
> > > > > > > > >> > 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
> > > > > > > > >> > <josep.prat@aiven.io.invalid
> > > > > > > > >> > > >
> > > > > > > > >> > > > > 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.prat@aiven.io
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > > > > > > >> fearthecellos@gmail.com>
> > > > > > > > >> > > > wrote:
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >>> +1, thanks Stanislav!
> > > > > > > > >> > > > >>>
> > > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
> > > > > bbejeck@gmail.com
> > > > > > >
> > > > > > > > >> wrote:
> > > > > > > > >> > > > >>>
> > > > > > > > >> > > > >>>> +1
> > > > > > > > >> > > > >>>>
> > > > > > > > >> > > > >>>> Thanks, Stanislav!
> > > > > > > > >> > > > >>>>
> > > > > > > > >> > > > >>>> -Bill
> > > > > > > > >> > > > >>>>
> > > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > > > > > > > me@ismaeljuma.com>
> > > > > > > > >> > > wrote:
> > > > > > > > >> > > > >>>>
> > > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > > > > > > >> > > > >>>>>
> > > > > > > > >> > > > >>>>> Ismael
> > > > > > > > >> > > > >>>>>
> > > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav
> > > Kozlovski
> > > > > > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > > > > > > > >> > > > >>>>>>
> > > > > > > > >> > > > >>>>>
> > > > > > > > >> > > > >>>>
> > > > > > > > >> > > > >>>
> > > > > > > > >> > > > >>
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > > > > > >> > > --
> > > > > > > > >> > > Best,
> > > > > > > > >> > > Stanislav
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> Best,
> > > > > > > > >> Stanislav
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best,
> > > > > > > Stanislav
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best,
> > > > > Stanislav
> > > > >
> > > >
> > >
> >
>
>
> --
> Best,
> Stanislav
>


-- 
Regards,
Mayank Shekhar Narula

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <so...@responsive.dev>
wrote:

> Looks great, thank you! +1
>
> On Thu, Nov 2, 2023 at 10:21 AM David Jacot <dj...@confluent.io.invalid>
> wrote:
>
> > +1 from me as well. Thanks, Stan!
> >
> > David
> >
> > On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <me...@ismaeljuma.com> wrote:
> >
> > > Thanks Stanislav, +1
> > >
> > > Ismael
> > >
> > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > > <st...@confluent.io.invalid> 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 <
> > > > sophie@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
> > > > > <st...@confluent.io.invalid> 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 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 <
> > > > > > sophie@responsive.dev>
> > > > > > 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 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 <
> > > > > > sophie@responsive.dev
> > > > > > > >
> > > > > > > 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
> > > > > > > > <st...@confluent.io.invalid> 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 <
> > > > > > fearthecellos@gmail.com>
> > > > > > > >> 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
> > > > > > > >> > <st...@confluent.io.invalid> 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
> > > > > > > >> > > <
> > > > > > >
> > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > > > >
> > > > > > > >> -
> > > > > > > >> > > 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 <
> > > > > cadonna@apache.org
> > > > > > >
> > > > > > > >> > 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
> > > > > > > >> > <josep.prat@aiven.io.invalid
> > > > > > > >> > > >
> > > > > > > >> > > > > 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.prat@aiven.io
> > > > > > > >> > > > >>
> > > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > > > > > >> fearthecellos@gmail.com>
> > > > > > > >> > > > wrote:
> > > > > > > >> > > > >>
> > > > > > > >> > > > >>> +1, thanks Stanislav!
> > > > > > > >> > > > >>>
> > > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
> > > > bbejeck@gmail.com
> > > > > >
> > > > > > > >> wrote:
> > > > > > > >> > > > >>>
> > > > > > > >> > > > >>>> +1
> > > > > > > >> > > > >>>>
> > > > > > > >> > > > >>>> Thanks, Stanislav!
> > > > > > > >> > > > >>>>
> > > > > > > >> > > > >>>> -Bill
> > > > > > > >> > > > >>>>
> > > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > > > > > > me@ismaeljuma.com>
> > > > > > > >> > > wrote:
> > > > > > > >> > > > >>>>
> > > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > > > > > >> > > > >>>>>
> > > > > > > >> > > > >>>>> Ismael
> > > > > > > >> > > > >>>>>
> > > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav
> > Kozlovski
> > > > > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > > > > > > >> > > > >>>>>>
> > > > > > > >> > > > >>>>>
> > > > > > > >> > > > >>>>
> > > > > > > >> > > > >>>
> > > > > > > >> > > > >>
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > --
> > > > > > > >> > > Best,
> > > > > > > >> > > Stanislav
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Best,
> > > > > > > >> Stanislav
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best,
> > > > > > Stanislav
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best,
> > > > Stanislav
> > > >
> > >
> >
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Sophie Blee-Goldman <so...@responsive.dev>]

Looks great, thank you! +1

On Thu, Nov 2, 2023 at 10:21 AM David Jacot <dj...@confluent.io.invalid>
wrote:

> +1 from me as well. Thanks, Stan!
>
> David
>
> On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <me...@ismaeljuma.com> wrote:
>
> > Thanks Stanislav, +1
> >
> > Ismael
> >
> > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> > <st...@confluent.io.invalid> 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 <
> > > sophie@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
> > > > <st...@confluent.io.invalid> 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 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 <
> > > > > sophie@responsive.dev>
> > > > > 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 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 <
> > > > > sophie@responsive.dev
> > > > > > >
> > > > > > 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
> > > > > > > <st...@confluent.io.invalid> 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 <
> > > > > fearthecellos@gmail.com>
> > > > > > >> 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
> > > > > > >> > <st...@confluent.io.invalid> 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
> > > > > > >> > > <
> > > > > >
> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > > >
> > > > > > >> -
> > > > > > >> > > 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 <
> > > > cadonna@apache.org
> > > > > >
> > > > > > >> > 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
> > > > > > >> > <josep.prat@aiven.io.invalid
> > > > > > >> > > >
> > > > > > >> > > > > 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.prat@aiven.io
> > > > > > >> > > > >>
> > > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > > > > >> fearthecellos@gmail.com>
> > > > > > >> > > > wrote:
> > > > > > >> > > > >>
> > > > > > >> > > > >>> +1, thanks Stanislav!
> > > > > > >> > > > >>>
> > > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
> > > bbejeck@gmail.com
> > > > >
> > > > > > >> wrote:
> > > > > > >> > > > >>>
> > > > > > >> > > > >>>> +1
> > > > > > >> > > > >>>>
> > > > > > >> > > > >>>> Thanks, Stanislav!
> > > > > > >> > > > >>>>
> > > > > > >> > > > >>>> -Bill
> > > > > > >> > > > >>>>
> > > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > > > > > me@ismaeljuma.com>
> > > > > > >> > > wrote:
> > > > > > >> > > > >>>>
> > > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > > > > >> > > > >>>>>
> > > > > > >> > > > >>>>> Ismael
> > > > > > >> > > > >>>>>
> > > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav
> Kozlovski
> > > > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > > > > > >> > > > >>>>>>
> > > > > > >> > > > >>>>>
> > > > > > >> > > > >>>>
> > > > > > >> > > > >>>
> > > > > > >> > > > >>
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > --
> > > > > > >> > > Best,
> > > > > > >> > > Stanislav
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Best,
> > > > > > >> Stanislav
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best,
> > > > > Stanislav
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best,
> > > Stanislav
> > >
> >
>

Re: Apache Kafka 3.7.0 Release

[David Jacot <dj...@confluent.io.INVALID>]

+1 from me as well. Thanks, Stan!

David

On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <me...@ismaeljuma.com> wrote:

> Thanks Stanislav, +1
>
> Ismael
>
> On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
> <st...@confluent.io.invalid> 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 <
> > sophie@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
> > > <st...@confluent.io.invalid> 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 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 <
> > > > sophie@responsive.dev>
> > > > 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 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 <
> > > > sophie@responsive.dev
> > > > > >
> > > > > 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
> > > > > > <st...@confluent.io.invalid> 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 <
> > > > fearthecellos@gmail.com>
> > > > > >> 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
> > > > > >> > <st...@confluent.io.invalid> 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
> > > > > >> > > <
> > > > >
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> > >
> > > > > >> -
> > > > > >> > > 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 <
> > > cadonna@apache.org
> > > > >
> > > > > >> > 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
> > > > > >> > <josep.prat@aiven.io.invalid
> > > > > >> > > >
> > > > > >> > > > > 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.prat@aiven.io
> > > > > >> > > > >>
> > > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > > > >> fearthecellos@gmail.com>
> > > > > >> > > > wrote:
> > > > > >> > > > >>
> > > > > >> > > > >>> +1, thanks Stanislav!
> > > > > >> > > > >>>
> > > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
> > bbejeck@gmail.com
> > > >
> > > > > >> wrote:
> > > > > >> > > > >>>
> > > > > >> > > > >>>> +1
> > > > > >> > > > >>>>
> > > > > >> > > > >>>> Thanks, Stanislav!
> > > > > >> > > > >>>>
> > > > > >> > > > >>>> -Bill
> > > > > >> > > > >>>>
> > > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > > > > me@ismaeljuma.com>
> > > > > >> > > wrote:
> > > > > >> > > > >>>>
> > > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > > > >> > > > >>>>>
> > > > > >> > > > >>>>> Ismael
> > > > > >> > > > >>>>>
> > > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > > > > >> > > > >>>>>>
> > > > > >> > > > >>>>>
> > > > > >> > > > >>>>
> > > > > >> > > > >>>
> > > > > >> > > > >>
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > > Best,
> > > > > >> > > Stanislav
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Best,
> > > > > >> Stanislav
> > > > > >>
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best,
> > > > Stanislav
> > > >
> > >
> >
> >
> > --
> > Best,
> > Stanislav
> >
>

Re: Apache Kafka 3.7.0 Release

[Ismael Juma <me...@ismaeljuma.com>]

Thanks Stanislav, +1

Ismael

On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski
<st...@confluent.io.invalid> 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 <
> sophie@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
> > <st...@confluent.io.invalid> 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 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 <
> > > sophie@responsive.dev>
> > > 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 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 <
> > > sophie@responsive.dev
> > > > >
> > > > 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
> > > > > <st...@confluent.io.invalid> 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 <
> > > fearthecellos@gmail.com>
> > > > >> 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
> > > > >> > <st...@confluent.io.invalid> 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
> > > > >> > > <
> > > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
> >
> > > > >> -
> > > > >> > > 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 <
> > cadonna@apache.org
> > > >
> > > > >> > 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
> > > > >> > <josep.prat@aiven.io.invalid
> > > > >> > > >
> > > > >> > > > > 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.prat@aiven.io
> > > > >> > > > >>
> > > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > > >> fearthecellos@gmail.com>
> > > > >> > > > wrote:
> > > > >> > > > >>
> > > > >> > > > >>> +1, thanks Stanislav!
> > > > >> > > > >>>
> > > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <
> bbejeck@gmail.com
> > >
> > > > >> wrote:
> > > > >> > > > >>>
> > > > >> > > > >>>> +1
> > > > >> > > > >>>>
> > > > >> > > > >>>> Thanks, Stanislav!
> > > > >> > > > >>>>
> > > > >> > > > >>>> -Bill
> > > > >> > > > >>>>
> > > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > > > me@ismaeljuma.com>
> > > > >> > > wrote:
> > > > >> > > > >>>>
> > > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > > >> > > > >>>>>
> > > > >> > > > >>>>> Ismael
> > > > >> > > > >>>>>
> > > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > > > >> > > > >>>>>>
> > > > >> > > > >>>>>
> > > > >> > > > >>>>
> > > > >> > > > >>>
> > > > >> > > > >>
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> > > --
> > > > >> > > Best,
> > > > >> > > Stanislav
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Best,
> > > > >> Stanislav
> > > > >>
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best,
> > > Stanislav
> > >
> >
>
>
> --
> Best,
> Stanislav
>

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <so...@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
> <st...@confluent.io.invalid> 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 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 <
> > sophie@responsive.dev>
> > 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 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 <
> > sophie@responsive.dev
> > > >
> > > 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
> > > > <st...@confluent.io.invalid> 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 <
> > fearthecellos@gmail.com>
> > > >> 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
> > > >> > <st...@confluent.io.invalid> 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
> > > >> > > <
> > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0>
> > > >> -
> > > >> > > 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 <
> cadonna@apache.org
> > >
> > > >> > 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
> > > >> > <josep.prat@aiven.io.invalid
> > > >> > > >
> > > >> > > > > 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.prat@aiven.io
> > > >> > > > >>
> > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > >> fearthecellos@gmail.com>
> > > >> > > > wrote:
> > > >> > > > >>
> > > >> > > > >>> +1, thanks Stanislav!
> > > >> > > > >>>
> > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bbejeck@gmail.com
> >
> > > >> wrote:
> > > >> > > > >>>
> > > >> > > > >>>> +1
> > > >> > > > >>>>
> > > >> > > > >>>> Thanks, Stanislav!
> > > >> > > > >>>>
> > > >> > > > >>>> -Bill
> > > >> > > > >>>>
> > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > > me@ismaeljuma.com>
> > > >> > > wrote:
> > > >> > > > >>>>
> > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > >> > > > >>>>>
> > > >> > > > >>>>> Ismael
> > > >> > > > >>>>>
> > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > > >> > > > >>>>>>
> > > >> > > > >>>>>
> > > >> > > > >>>>
> > > >> > > > >>>
> > > >> > > > >>
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Best,
> > > >> > > Stanislav
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Best,
> > > >> Stanislav
> > > >>
> > > >
> > >
> >
> >
> > --
> > Best,
> > Stanislav
> >
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Sophie Blee-Goldman <so...@responsive.dev>]

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
<st...@confluent.io.invalid> 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 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 <
> sophie@responsive.dev>
> 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 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 <
> sophie@responsive.dev
> > >
> > 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
> > > <st...@confluent.io.invalid> 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 <
> fearthecellos@gmail.com>
> > >> 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
> > >> > <st...@confluent.io.invalid> 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
> > >> > > <
> > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0>
> > >> -
> > >> > > 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 <cadonna@apache.org
> >
> > >> > 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
> > >> > <josep.prat@aiven.io.invalid
> > >> > > >
> > >> > > > > 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.prat@aiven.io
> > >> > > > >>
> > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > >> fearthecellos@gmail.com>
> > >> > > > wrote:
> > >> > > > >>
> > >> > > > >>> +1, thanks Stanislav!
> > >> > > > >>>
> > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com>
> > >> wrote:
> > >> > > > >>>
> > >> > > > >>>> +1
> > >> > > > >>>>
> > >> > > > >>>> Thanks, Stanislav!
> > >> > > > >>>>
> > >> > > > >>>> -Bill
> > >> > > > >>>>
> > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > me@ismaeljuma.com>
> > >> > > wrote:
> > >> > > > >>>>
> > >> > > > >>>>> Thanks for volunteering Stanislav!
> > >> > > > >>>>>
> > >> > > > >>>>> Ismael
> > >> > > > >>>>>
> > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > >> > > > >>>>> <st...@confluent.io.invalid> 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
> > >> > > > >>>>>>
> > >> > > > >>>>>
> > >> > > > >>>>
> > >> > > > >>>
> > >> > > > >>
> > >> > > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Best,
> > >> > > Stanislav
> > >> > >
> > >> >
> > >>
> > >>
> > >> --
> > >> Best,
> > >> Stanislav
> > >>
> > >
> >
>
>
> --
> Best,
> Stanislav
>

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <so...@responsive.dev>
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 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 <sophie@responsive.dev
> >
> 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
> > <st...@confluent.io.invalid> 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 <fe...@gmail.com>
> >> 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
> >> > <st...@confluent.io.invalid> 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
> >> > > <
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0>
> >> -
> >> > > 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 <ca...@apache.org>
> >> > 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
> >> > <josep.prat@aiven.io.invalid
> >> > > >
> >> > > > > 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.prat@aiven.io
> >> > > > >>
> >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> >> fearthecellos@gmail.com>
> >> > > > wrote:
> >> > > > >>
> >> > > > >>> +1, thanks Stanislav!
> >> > > > >>>
> >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com>
> >> wrote:
> >> > > > >>>
> >> > > > >>>> +1
> >> > > > >>>>
> >> > > > >>>> Thanks, Stanislav!
> >> > > > >>>>
> >> > > > >>>> -Bill
> >> > > > >>>>
> >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> me@ismaeljuma.com>
> >> > > wrote:
> >> > > > >>>>
> >> > > > >>>>> Thanks for volunteering Stanislav!
> >> > > > >>>>>
> >> > > > >>>>> Ismael
> >> > > > >>>>>
> >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> >> > > > >>>>> <st...@confluent.io.invalid> 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
> >> > > > >>>>>>
> >> > > > >>>>>
> >> > > > >>>>
> >> > > > >>>
> >> > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > Best,
> >> > > Stanislav
> >> > >
> >> >
> >>
> >>
> >> --
> >> Best,
> >> Stanislav
> >>
> >
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Sophie Blee-Goldman <so...@responsive.dev>]

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 <so...@responsive.dev>
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
> <st...@confluent.io.invalid> 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 <fe...@gmail.com>
>> 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
>> > <st...@confluent.io.invalid> 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
>> > > <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0>
>> -
>> > > 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 <ca...@apache.org>
>> > 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
>> > <josep.prat@aiven.io.invalid
>> > > >
>> > > > > 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.prat@aiven.io
>> > > > >>
>> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
>> fearthecellos@gmail.com>
>> > > > wrote:
>> > > > >>
>> > > > >>> +1, thanks Stanislav!
>> > > > >>>
>> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com>
>> wrote:
>> > > > >>>
>> > > > >>>> +1
>> > > > >>>>
>> > > > >>>> Thanks, Stanislav!
>> > > > >>>>
>> > > > >>>> -Bill
>> > > > >>>>
>> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com>
>> > > wrote:
>> > > > >>>>
>> > > > >>>>> Thanks for volunteering Stanislav!
>> > > > >>>>>
>> > > > >>>>> Ismael
>> > > > >>>>>
>> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
>> > > > >>>>> <st...@confluent.io.invalid> 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
>> > > > >>>>>>
>> > > > >>>>>
>> > > > >>>>
>> > > > >>>
>> > > > >>
>> > > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Best,
>> > > Stanislav
>> > >
>> >
>>
>>
>> --
>> Best,
>> Stanislav
>>
>

Re: Apache Kafka 3.7.0 Release

[Sophie Blee-Goldman <so...@responsive.dev>]

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
<st...@confluent.io.invalid> 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 <fe...@gmail.com>
> 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
> > <st...@confluent.io.invalid> 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
> > > <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0>
> -
> > > 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 <ca...@apache.org>
> > 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
> > <josep.prat@aiven.io.invalid
> > > >
> > > > > 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.prat@aiven.io
> > > > >>
> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <fearthecellos@gmail.com
> >
> > > > wrote:
> > > > >>
> > > > >>> +1, thanks Stanislav!
> > > > >>>
> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com>
> wrote:
> > > > >>>
> > > > >>>> +1
> > > > >>>>
> > > > >>>> Thanks, Stanislav!
> > > > >>>>
> > > > >>>> -Bill
> > > > >>>>
> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com>
> > > wrote:
> > > > >>>>
> > > > >>>>> Thanks for volunteering Stanislav!
> > > > >>>>>
> > > > >>>>> Ismael
> > > > >>>>>
> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > > >>>>> <st...@confluent.io.invalid> 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
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best,
> > > Stanislav
> > >
> >
>
>
> --
> Best,
> Stanislav
>

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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 <fe...@gmail.com>
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
> <st...@confluent.io.invalid> 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
> > <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0> -
> > 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 <ca...@apache.org>
> 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
> <josep.prat@aiven.io.invalid
> > >
> > > > 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.prat@aiven.io
> > > >>
> > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <fe...@gmail.com>
> > > wrote:
> > > >>
> > > >>> +1, thanks Stanislav!
> > > >>>
> > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com> wrote:
> > > >>>
> > > >>>> +1
> > > >>>>
> > > >>>> Thanks, Stanislav!
> > > >>>>
> > > >>>> -Bill
> > > >>>>
> > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com>
> > wrote:
> > > >>>>
> > > >>>>> Thanks for volunteering Stanislav!
> > > >>>>>
> > > >>>>> Ismael
> > > >>>>>
> > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > >>>>> <st...@confluent.io.invalid> 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
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
> >
> >
> > --
> > Best,
> > Stanislav
> >
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Chris Egerton <fe...@gmail.com>]

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
<st...@confluent.io.invalid> 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
> <https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0> -
> 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 <ca...@apache.org> 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 <josep.prat@aiven.io.invalid
> >
> > > 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.prat@aiven.io
> > >>
> > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <fe...@gmail.com>
> > wrote:
> > >>
> > >>> +1, thanks Stanislav!
> > >>>
> > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com> wrote:
> > >>>
> > >>>> +1
> > >>>>
> > >>>> Thanks, Stanislav!
> > >>>>
> > >>>> -Bill
> > >>>>
> > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com>
> wrote:
> > >>>>
> > >>>>> Thanks for volunteering Stanislav!
> > >>>>>
> > >>>>> Ismael
> > >>>>>
> > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > >>>>> <st...@confluent.io.invalid> 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
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>
>
> --
> Best,
> Stanislav
>

Re: Apache Kafka 3.7.0 Release

[Stanislav Kozlovski <st...@confluent.io.INVALID>]

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
<https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0> - 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 <ca...@apache.org> 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 <jo...@aiven.io.invalid>
> > 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.prat@aiven.io
> >>
> >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <fe...@gmail.com>
> wrote:
> >>
> >>> +1, thanks Stanislav!
> >>>
> >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com> wrote:
> >>>
> >>>> +1
> >>>>
> >>>> Thanks, Stanislav!
> >>>>
> >>>> -Bill
> >>>>
> >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com> wrote:
> >>>>
> >>>>> Thanks for volunteering Stanislav!
> >>>>>
> >>>>> Ismael
> >>>>>
> >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> >>>>> <st...@confluent.io.invalid> 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
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>


-- 
Best,
Stanislav

Re: Apache Kafka 3.7.0 Release

[Bruno Cadonna <ca...@apache.org>]

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 <jo...@aiven.io.invalid>
> 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.prat@aiven.io
>>
>> On Mon, Oct 9, 2023, 20:05 Chris Egerton <fe...@gmail.com> wrote:
>>
>>> +1, thanks Stanislav!
>>>
>>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com> wrote:
>>>
>>>> +1
>>>>
>>>> Thanks, Stanislav!
>>>>
>>>> -Bill
>>>>
>>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com> wrote:
>>>>
>>>>> Thanks for volunteering Stanislav!
>>>>>
>>>>> Ismael
>>>>>
>>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
>>>>> <st...@confluent.io.invalid> 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 <sh...@gmail.com>]

Thanks Stanislav!

On Tue, Oct 10, 2023 at 3:05 AM Josep Prat <jo...@aiven.io.invalid>
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.prat@aiven.io
>
> On Mon, Oct 9, 2023, 20:05 Chris Egerton <fe...@gmail.com> wrote:
>
> > +1, thanks Stanislav!
> >
> > On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com> wrote:
> >
> > > +1
> > >
> > > Thanks, Stanislav!
> > >
> > > -Bill
> > >
> > > On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com> wrote:
> > >
> > > > Thanks for volunteering Stanislav!
> > > >
> > > > Ismael
> > > >
> > > > On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > > <st...@confluent.io.invalid> 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 <jo...@aiven.io.INVALID>]

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.prat@aiven.io

On Mon, Oct 9, 2023, 20:05 Chris Egerton <fe...@gmail.com> wrote:

> +1, thanks Stanislav!
>
> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com> wrote:
>
> > +1
> >
> > Thanks, Stanislav!
> >
> > -Bill
> >
> > On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com> wrote:
> >
> > > Thanks for volunteering Stanislav!
> > >
> > > Ismael
> > >
> > > On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > <st...@confluent.io.invalid> 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 <fe...@gmail.com>]

+1, thanks Stanislav!

On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bb...@gmail.com> wrote:

> +1
>
> Thanks, Stanislav!
>
> -Bill
>
> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com> wrote:
>
> > Thanks for volunteering Stanislav!
> >
> > Ismael
> >
> > On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > <st...@confluent.io.invalid> 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 <bb...@gmail.com>]

+1

Thanks, Stanislav!

-Bill

On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <me...@ismaeljuma.com> wrote:

> Thanks for volunteering Stanislav!
>
> Ismael
>
> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> <st...@confluent.io.invalid> 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 <me...@ismaeljuma.com>]

Thanks for volunteering Stanislav!

Ismael

On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
<st...@confluent.io.invalid> 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
>