Add release-1.32 team and timeline

[fsmunoz]

Initial v1.32 release information:

• directory
• release-team
• timeline

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: fsmunoz
Once this PR has been reviewed and has the lgtm label, please assign justaugustus for approval. For more information see the Kubernetes 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:

• releases/OWNERS

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

[fsmunoz]

/retitle Add release-1.32 team and timeline

[katcosgrove]

Major Themes is now Release Highlights, as of #2600 (yay!)

[fsmunoz]

Thank you @katcosgrove !

[liggitt]

During 1.31 cut we discussed eliminating a distinct test freeze, and requiring stable test coverage be in place by code freeze. Fixes for test failures would still be accepted (just as they are today), but having a separate official test freeze date invites unstable or insufficient tests for code added before code freeze.

cc @johnbelamaric @BenTheElder @dims @thockin @Verolop @jeremyrickard @jpbetz @soltysh

[liggitt]

I think that would just mean dropping this line and making the existing code freeze date the "code and test freeze" (or moving the "code and test freeze" date to this line)

[BenTheElder]

cc @aojea @pohly

+1, I think in retrospect test freeze has not been a helpful concept, and test fixes should be treated the same as bug fixes post-freeze, but whole new tests should not be deferred and ideally implementation PRs should have tests to begin with.

Test-freeze encourages punting tests and we've even wound up with beta features that are not sufficiently tested due to deferred test work.

We could allow some additional time for code freeze into at least part of the test freeze window.

[jeremyrickard]

+1 to just dropping the line and rolling it into code freeze. @BenTheElder is your suggestion to delay the code freeze period (shorten it?)

[BenTheElder]

We can do one of:

1. drop the test freeze date and roll it into the code freeze date
2. drop the code freeze date and roll it into what was the test freeze date
3. something in-between

Jordan had raised some concerns about 2), roughly that it means we have less time focused on stabilization.
3) might make sense, which is what I attempted to bring up, but for this release we also have #2604 (comment) to consider (kubecon / freeze alignment ...)

[jeremyrickard]

I think for most releases I would land on #3. I think for this release (like often happens with the end of the year), the calendar will work against us.

So for this one, I would vote #1.

For 1.33 I would vote #3.

[soltysh]

👍 for dropping the test freeze

[liggitt]

This is ~2 business days after kubecon. Speaking for myself, time for code reviews the previous week will be extremely scarce. If we put code freeze immediately after kubecon like this, we have to communicate super well that PRs not merged by start of kubecon could be ~high risk of missing, depending on who the reviewers / implementers are.

[alculquicondor]

I would rather move the code freeze before Kubecon, than give false hopes to contributors.

[jeremyrickard]

I would also vote to move this to before KubeCon. It also looks like we have docs deadlines during KubeCon. I would suggest both of these be week of Nov 4th. Perhaps also move the beta back? That would be a week between the third alpha release and the beta release. I am not sure we need more than that based on how much feedback we typically get from them...but moving the beta back a week allows people to find issues that can be fixed ahead of code freeze.

[fsmunoz]

Thank you! Would something like this work:

• Begin Feature blog freeze: Oct 30 (w8)
• 1.32.0-beta.0 release: Nov 5 (w9)
• Begin Code Freeze & Test Freeze: Nov 8 (w9)
• Docs deadline - PRs ready for review: Nov 18 (w11)

KubeCon NA is Nov 12-15, so this would anticipate beta-0 1 week, and put the freeze before KubeCon. Docs deadline could be on Nov 8 as well: I've suggested here to delay it one week instead of anticipating it.

The distance between beta-0 and the freeze is shorter, and exception requests will appear on KubeCon week, but from what I've read here these are minor compared with the benefit of having the freeze before KubeCon.

[fsmunoz]

I've committed a new version that reflects this approach, essentially compressing things a bit more to put deadlines before KubeCon, plus merging Code and Test Freeze.

[jeremyrickard]

This is also a holiday week in the US, so we should work early to make sure we have review coverage outside the US in terms of release managers.

[fsmunoz]

Thanksgiving week is 25-29, the problem I see with delaying things is that it could move the release date to week 15, which is closer to Christmas (also typically a period where vacations/holidays are a concern), but it's doable e.g.:

• Move release date to Dec 18th
• Move Docs Freeze to Dec 3rd
• Move rc-1 to Dec 10

... and adjust the rest, giving more days for the "ready to review" ones.

Or we could just keep it as is and prepare for it, as you mentioned @jeremyrickard .

[jeremyrickard]

I don't think I would delay at all. My comment was more just that we should prepare and make sure folks are lined up, and informational for any potential release manager shadows.

[fsmunoz]

Understood, will make sure that that is properly relayed to everyone.

[mbianchidev]

The Release Highlights process is still unclear to me (respect to the former Major Themes) so I cannot validate this deadline yet.

[mbianchidev]

On week 6 I would add a (soft) deadline for blog opt-ins.

The rationale behind this is to minimize the number of reachouts to KEP owners that are not interested in writing a blog but end up saying so only later in the process.

I would even add two questions in the template PR
"Do you think that this feature requires a blog? If so, are you willing to write one?"

Just an idea, feel free to discard this if you think it's not feasible.

[fsmunoz]

We've had that discussion (at least partially) in the 1.26 retro - I remember it because I suggested something like that:

The deadlines for Feature Blogs are difficult to track and provide a status on: they are viewed as the day in which things need to be pushed, which makes it very hard to provide a status update since 80% of placeholder PRs arrive in the last 2 days. If we want to have realistic RAG (Red, Amber, Green) status for Comms, perhaps we should adopt a “soft” deadline and a “hard” one, or something else like a “rolling window” in which things get added at the end (we used this for 1 blog this release

The consensus was that "soft deadlines" do not exist, and every time they were used they were either perceived as "hard", or no deadline at all.

Interesting idea on adding the opt-in to the PR, would like to hear more opinions on it (I'm not sure if it's doable for this release from a practical perspective).

[mbianchidev]

So my idea would be to have those questions directly here: https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/enhancement.yaml

Since the enhancement tracking is done mainly for release purposes, adding a box with these questions seems reasonable. It would save an entire cycle of reachouts for whoever says directly "no, this enhancement won't have a blog" from the start. Wdyt?

I'm also ok with adding a hard deadline for the opt in on the 6th week but conscious that it probably won't be treated as such due to the nature of blogging/content creation in general.