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
