Create v1.34 release directory

[Vyom-Yadav]

What type of PR is this:

/kind documentation

What this PR does / why we need it:

Creates the v1.34 release directory as per #2779

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

None

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Vyom-Yadav
Once this PR has been reviewed and has the lgtm label, please assign jeremyrickard for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Vyom-Yadav]

There is active conversation going on to replace the bit.ly links. These are kept as a placeholder and the links would be replaced with internal redirects (k8s.dev/go.k8s.io,TBD) by the time the release cycle starts.

[Vyom-Yadav]

The PR is open: https://kubernetes.slack.com/archives/C2C40FMNF/p1747315846937199, kubernetes/k8s.io#8109

[Vyom-Yadav]

everytimezone is behaving weirdly (some bug maybe). See the attached screenshot:

The pop up card shows deadline as 21st June however, in the background the actual timeline and the selector point to 20th June.

(Also, I only realized later it would show link created by me, so let me know if I have to replace that with anonymized link)

[wendy-ha18]

I couldn't find any note for everytimezone links but in the past, for your reference purpose, everytime the links being included, it was always anonymous, for i.e: v1.33, v1.30, v1.28.

Sometime, a few Release Directory didn't include everytimezone links, they just noted the timezone and that's it :)

[Vyom-Yadav]

Yeah, I noticed that too. But it's fine imo, I'll change it if this is CoC violation or some other violation.

[Vyom-Yadav]

I have shifted all the release cuts from Tuesday to Wednesday for two reasons (which were brought up in the retro):

1. Tuesdays are for patch releases, so having the main cut after it makes sense and reduced workload (on people/tooling/infra)
2. Having the cut on Tuesday doesn't leave much for an issue fix if it was discovered Friday eod, this gives somewhat more flexibility. (However, it was mentioned that we can always delay the cut for this particular point).

[xmudrii]

I strongly agree on the first point, i.e. decoupling the patch releases from the prereleases, these shouldn't be scheduled for the same day. Especially given that some part of the release process are not concurrent (the image promotion part).

I initially thought about doing the prereleases on Tuesday, and the patch releases on Wednesday, but that would be some more work to get it adopted. So let's try with the preleases on Wednsday, and the patch releases on Tuesday (as @Vyom-Yadav proposed here).

[Vyom-Yadav]

In the last cycle, this deadline was on Tuesday, but I've shifted it to eow. Let me know if the reasoning behind having those deadlines in the middle of the week was to get things in place by eow (as these are soft deadlines and historically, folks go over it and we don't ask them to file an enhancement).

It's explicitly giving more time v/s implicitly giving more time.

[chanieljdan]

For the Docs ready-for-review deadline, it was to ensure that sig-docs had enough time to review docs PRs between the ready-for-review deadline and docs freeze. We should set at least a week between the PR ready for review deadline and docs freeze, I'm thinking Tuesday July 29th. Most usually observe the docs deadlines, especially when we involve the SIG leads for engagement/enforcement.

[bridgetkromhout]

Hi @Vyom-Yadav I worry about setting Friday deadlines because depending on which timezone things are happening in, that would be a problem for some weekends and some religious observances. If we can wrap up any community deadlines no later than a Thursday anywhere on earth, we can avoid these clashes.

(When a holiday is on Thursday, then I would suggest we wrap up the deadlines for the week on Wednesday.)

[Vyom-Yadav]

@chanieljdan Good point, I've moved the docs ready for review deadline on Tuesday 29th. I've also moved the deadline for Release Highlights (cc @aibarbetta, ptal if these deadlines look good).

[Vyom-Yadav]

@bridgetkromhout Historically, the deadlines have been 02:00 UTC Friday / 19:00 PST Thursday i.e eod PST timezone. Tracking holidays globally is not something we do, but we can track a few major ones. There is some discussion to move the enhancements freeze: #2780 (comment) that we're considering.

[aibarbetta]

This would put the Release Highlights deadline immediately after the mid-cycle blog publication and the Feature blogs ready-for-review outreach, but I agree it's best to avoid Fridays. I wouldn't push the Release Highlights deadline either, since it is a prerequisite to start writing the Release blog.
I believe I can work with this, I'll make sure to prepare for these ahead so we don't have too much to do at the same time.

[Vyom-Yadav]

Feature blogs ready to review deadline is two days after the docs freeze - as discussed in the v1.33 retro.
Also, I've moved Release blog ready to review deadline to the next week to not overburden the comms team.

[rytswd]

Thanks!
For the Release Announcement blog, this is more to complete the write-up and start engaging with SIG Docs Blog team for their review, so no strict deadline is needed. This timeline gives us 12 days before the release day, which is probably sufficient time in most cases. Ideally we would like to have 14 days or longer, and this could be arranged with some internal draft shared for early review by Release Lead + SIG Docs Blog team.

For the Feature Blogs, we would want to have the deadline time defined for the Feature Blogs, so that it is clear for KEP authors. The actual blog review focus will be on the Release Announcement, and once that's in review, the Comms team should have some more time on reviewing the Feature Blogs. We want to ensure every blog authors have it done earlier than later, and thus "ready for review" deadline could happen on the same day in fact. I think the current timeline is fine as is, though.

[aibarbetta]

lgtm

[natasha41575]

Not sure if you have already considered this, but Thursday 19th June is a public holiday and a nonworking day for many people in the US

[Vyom-Yadav]

I'm not sure if we want to move this deadline for one holiday, but if we do how about we shift this deadline to: 21:00 UTC Friday 20th June 2025 / 14:00 PST Friday 20th June 2025?

[natasha41575]

sgtm. Up to you and the release team of course (I don't mean to create a big fuss), just wanted to flag it

[jenshu]

21:00 UTC Friday 20th June 2025 / 14:00 PST Friday 20th June 2025

this time sounds good to me

[bridgetkromhout]

I agree with avoiding public holidays where we can. If we can move it to the day before (so Wednesday in this case), we might capture more attention from people who may end up taking Thursday-Friday-Saturday-Sunday as a four-day weekend. (Friday in this case avoids the Thursday holiday in the US but puts the deadline on the weekend for much of the rest of the world, so that worries me a bit.)

[jenshu]

good point about the weekend. would it work if we shift to the day before, keeping the original times?
02:00 UTC Thursday 19th June 2025 / 19:00 PST Wednesday 18th June 2025

and in that case, should the PRR freeze also be shifted a day before, to give a full week before enhancements freeze? (or does the one day difference not matter too much?)

[Vyom-Yadav]

Yeah, I'm concerned about shortening the deadline for a single day holiday in the US. I think it's fairly fine to assume that if we keep it on Friday, KEP owners can get their SIGs to review it till Wednesday, if the reviewers won't be available. Shortening it for the rest of the world worries me as well.

[Vyom-Yadav]

I have moved it to 21:00 UTC Friday 20th June 2025 / 14:00 PST Friday 20th June 2025 to accommodate for the US holiday.

[Vyom-Yadav]

KubeCon India is Aug 6 -7. I don't think we need to pause the release team activities during that and we have enough diversity in team to support the functioning during that phase. cc @Rajalakshmi-Girish

[wendy-ha18]

It may worth to note down for other KubeCon as well:

• KubeCon China: 10-11 June:
  With this calendar, everyone should be awared for 1.34.0-alpha.1 released (Wednesday 11th June 2025) --> This will depends on timezone of Branch Manager.

• KubeCon Japan: 16-17 June, and note from Natasha above for US public 19 June:
  This will potentially affect Enhancements Freeze, cc Enhancement Lead @jenshu

• KubeCon India: 6-7 August:
  It will around 1.34.0-rc.0 released cut (Wednesday 6th August 2025) --> This will depends on timezone of Branch Manager .
  However, the rc.0 cut is a bit longer than other cuts, cause BM needs to prepare to publish 1.34-blocking and 1.34-informing dashboards as well.

[Vyom-Yadav]

Yes, thanks for that @wendy-ha18, but I think we should pick flexible team to not get affected by 2 day KubeCon. The week KubeCons are the one which get into the timeline. Thanks for mentioning these KubeCons and affected teams.

[rytswd]

Sorry for late review, left a few comments.

[rytswd]

Docs deadline above on week 7 mentions "Open placeholder PRs", which is accurate and clear for anyone. I'd suggest adopting the same here.

CC @aibarbetta for your info

[aibarbetta]

I agree, wording it as a deadline to open placeholder PRs would be clearer

[Vyom-Yadav]

Agreed, updated the wording.

[rytswd]

I personally found this phrase confusing. This is about reminding the Feature Blog authors for completing most of the write-up before the review deadline, which is "Feature blogs ready to review" on Week 12.

We could potentially rephrase to something like Feature Blog deadline - Send reminders about review schedule.

Regarding the timing, I think it would be most effective if we start right after Docs deadline is passed. That would give KEP owners a clearer view of what they are reminded about.

Having said all of the above, though, I'm also fine taking this out from the schedule here, as it is quite specific for Comms. As I don't see a similar entry for Docs or Enhancements, this could be tracked separately under a Comms specific progress tracking.

[Vyom-Yadav]

Yeah, this is comms specific and should not be in the release timeline as other teams also have begin outreach timings, which should be tracked by the subteam lead.

[rytswd]

Thanks!
For the Release Announcement blog, this is more to complete the write-up and start engaging with SIG Docs Blog team for their review, so no strict deadline is needed. This timeline gives us 12 days before the release day, which is probably sufficient time in most cases. Ideally we would like to have 14 days or longer, and this could be arranged with some internal draft shared for early review by Release Lead + SIG Docs Blog team.

For the Feature Blogs, we would want to have the deadline time defined for the Feature Blogs, so that it is clear for KEP authors. The actual blog review focus will be on the Release Announcement, and once that's in review, the Comms team should have some more time on reviewing the Feature Blogs. We want to ensure every blog authors have it done earlier than later, and thus "ready for review" deadline could happen on the same day in fact. I think the current timeline is fine as is, though.

[rytswd]

Can you add an extra entry one day after the release for Feature Blog publication start?

[Vyom-Yadav]

Added, thanks.

[rytswd]

Perhaps it's worth adding a line before this to mention the shadow application form closes on 18th?

[Vyom-Yadav]

This PR usually gets merged after the shadow application close, so I'm not sure about if this is consumable information for contributors. If we're adding closing date, we should also mention opening data, it would be something like:

| [Shadow] Application Opens | Subproject Lead  | Monday 5th May 2025  | week -2  |                                                                         
| [Shadow] Application Closes  | Subproject Lead | Sunday 18th May 2025 | week 0   |                                                                          

I think shadow program is more of a sig-release activity than being related to the release timeline. The release timeline imo serves contributors who are looking to get their changes merged in this release cycle. Still, if this feels like something that should be added, happy to discuss this further on Slack group chat.

[Vyom-Yadav]

@mbianchidev As you asked, added you as the BM and @jimangel as the shadow. Although it feels weird with Jim as a shadow given how many times he has been the lead. (But I'll let rel-mgmt figure out the structure)

[xmudrii]

@Vyom-Yadav I think putting Jim as an shadow is kind of wrong, Jim is more in the "Branch Manager Advisor" role (and the Release Manager role), so I'd leave shadows empty for now and we figure it out this week.

[Vyom-Yadav]

Yeah, I had the same feeling, I've removed Jim from the shadow section.

[mbianchidev]

LGTM from the branch management perspective schedule-wise.

One minor issue I have on a single date (11th of June) but I will ask another BM to take over if I find myself completely not available on that day.