Hi all,

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

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

Best,
Stanislav

On Thu, Oct 26, 2023 at 12:15 AM Sophie Blee-Goldman <sop...@responsive.dev>
wrote:

> Thanks for the response and explanations -- I think the main question for
> me
> was whether we intended to permanently increase the KF -- FF gap from the
> historical 1 week to 3 weeks? Maybe this was a conscious decision and I
> just
>  missed the memo, hopefully someone else can chime in here. I'm all for
> additional though. And looking around at some of the recent releases, it
> seems like we haven't been consistently following the "usual" schedule
> since
> the 2.x releases.
>
> Anyways, my main concern was making sure to leave a full 2 weeks between
> feature freeze and code freeze, so I'm generally happy with the new
> proposal.
> Although I would still prefer to have the KIP freeze fall on a Wednesday --
> Ismael actually brought up the same thing during the 3.5.0 release
> planning,
> so I'll just refer to his explanation for this:
>
> We typically choose a Wednesday for the various freeze dates - there are
> > often 1-2 day slips and it's better if that doesn't require people
> > working through the weekend.
> >
>
> (From this mailing list thread
> <https://lists.apache.org/thread/dv1rym2jkf0141sfsbkws8ckkzw7st5h>)
>
> Thanks for driving the release!
> Sophie
>
> On Wed, Oct 25, 2023 at 8:13 AM Stanislav Kozlovski
> <stanis...@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 <
> > sop...@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 <
> > sop...@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
> > > > <stanis...@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 <
> > fearthecel...@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
> > > >> > <stanis...@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 <
> cado...@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.p...@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.p...@aiven.io
> > > >> > > > >>
> > > >> > > > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton <
> > > >> fearthecel...@gmail.com>
> > > >> > > > wrote:
> > > >> > > > >>
> > > >> > > > >>> +1, thanks Stanislav!
> > > >> > > > >>>
> > > >> > > > >>> On Mon, Oct 9, 2023, 14:02 Bill Bejeck <bbej...@gmail.com
> >
> > > >> wrote:
> > > >> > > > >>>
> > > >> > > > >>>> +1
> > > >> > > > >>>>
> > > >> > > > >>>> Thanks, Stanislav!
> > > >> > > > >>>>
> > > >> > > > >>>> -Bill
> > > >> > > > >>>>
> > > >> > > > >>>> On Mon, Oct 9, 2023 at 1:59 PM Ismael Juma <
> > > m...@ismaeljuma.com>
> > > >> > > wrote:
> > > >> > > > >>>>
> > > >> > > > >>>>> Thanks for volunteering Stanislav!
> > > >> > > > >>>>>
> > > >> > > > >>>>> Ismael
> > > >> > > > >>>>>
> > > >> > > > >>>>> On Mon, Oct 9, 2023 at 10:51 AM Stanislav Kozlovski
> > > >> > > > >>>>> <stanis...@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

Reply via email to