Sig-release: [Umbrella] Release cycle improvements for v1.22

[saschagrunert]

This is a placeholder issue to collect possible enhancements for the next upcoming release cycle. The outcome of the v1.21 retrospective as well general thoughts can be collected here before creating the next cycle.

_Baseline is the v1.21 schedule: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.21#timeline_

• Merge Docs deadline with Code Freeze
  Coupling code and documentation tighter to reduce the pressure on the docs team.
  See https://github.com/kubernetes/sig-release/issues/1496#issuecomment-800486488

• Reduce time between Code Freeze and Test Freeze to 1 week
  Right now we have 2 weeks. The idea is to reduce that time to only 1 week to save some time for development.

• Move enhancements freeze to an earlier date
  The idea is to move enhancements freeze to an earlier date within the cycle to start development faster.

• Add an explicit break at the end of each release:
  We already have a break of 2 weeks between each release. The idea is to make this explicit.

Happy to get any input from y'all! :blush:

[palnabarun]

/priority important-soon
/area release-team

[justaugustus]

/assign @saschagrunert @palnabarun
cc: @kubernetes/sig-release

[annajung]

Merge Docs deadline with Code Freeze
Coupling code and documentation tighter to reduce the pressure on the docs team.

In discussion with Sig Docs & current Docs lead @reylejano, we agreed that we have seen better responses for a placeholder deadline when the deadline comes after the code freeze. Instead of merging the deadline with code freeze, we should schedule the placeholder docs deadline a week after the code freeze.

[saschagrunert]

Instead of merging the deadline with code freeze, we should schedule the placeholder docs deadline a week after the code freeze.

This looks like the same schedule as we have it today, right? Changed my initial comment to reflect that.

[annajung]

right, we actually changed it for the current release. We used to have the placeholder deadline before the code freeze but wanted to try out to see if it would work better if it came after code freeze. & looks like 1.21 proves that it does :)

So, I think we should make it permanent.

[spiffxp]

Reduce time between Code Freeze and Test Freeze to 1 week
Right now we have 2 weeks. The idea is to reduce that time to only 1 week to save some time for development.

My interpretation of this statement as written is less about time between code and test freeze, and more about reduction of overall freeze time. Down from ~4 weeks prior to release to 3.

I am all for less time in freeze, it feels really draconian. But, is it necessary? I am curious what data we have on things stabilizing during freeze from previous release cycles.

FWIW Test Freeze as a concept was first introduced in v1.20, it was effectively 1.5 weeks. We also had ~4 weeks of some kind of freeze in total for v1.20. That said kubecon impacted the bandwidth we had for test freeze,and holidays impacted our full freeze bandwidth.

[ehashman]

Move enhancements freeze to an earlier date

I initially proposed this at the Chairs and Leads meeting, seeking feedback. I also sought feedback from PRR. Consensus is that this would generally be a good idea (perhaps freezing in week 2). See also: https://kubernetes.slack.com/archives/C2C40FMNF/p1616699414092100

[saschagrunert]

I guess this is done
/close

[k8s-ci-robot]

@saschagrunert: Closing this issue.

In response to this:

I guess this is done
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.