When is the optimal start of Enhancements Freeze in a release cycle?

[reylejano]

In Kubernetes 1.22, Enhancements Freeze was moved 2 weeks earlier to week 3 of the release cycle.
Starting in Kubernetes 1.23, Enhancements Freeze is now coupled with the requirement of having a Production Readiness Review questionnaire to be filled out 1 week before the start of Enhancements Freeze (ref: communication email).

For reference:

• Kubernetes 1.20, Enhancements Freeze started on week 4 of the release cycle
• Kubernetes 1.21, Enhancements Freeze started on week 5 of the release cycle
• Kubernetes 1.22, Enhancements Freeze started on week 3 of the release cycle
• Currently Kubernetes 1.23, Enhancements Freeze is scheduled to start on week 3 of the release cycle

When is the ideal start of Enhancements Freeze in a release cycle?

[reylejano]

/area release-team

[reylejano]

A few of the reasons/benefits to move the Enhancements Freeze earlier are (captured from meeting notes):

• An earlier Enhancements Freeze gets contributors to work on enhancements and feature development earlier in the cycle
• Provides more time for part-time contributors

[nikhita]

IMHO it might help to have a longer enhancement period and moving the Enhancement Freeze date ahead by 1-2 weeks.

It's unclear to me why having a longer enhancement period would be undesirable because this does not imply a shorter coding period. Pushing it ahead by a week would still allow sufficient time for development of the opted-in features and give enough time for planning as well.

Provides more time for part-time contributors

I think it might actually benefit part-time contributors if we have a longer enhancement period to have sufficient time for planning, building consensus and getting a KEP merged.

What are the concrete negative implications of pushing the enhancement freeze ahead by a week?

[xing-yang]

In SIG-Storage, we have been migrating in-tree volume plugins to out-of-tree CSI drivers. CSI is an integral part of SIG-Storage. After a Kubernetes release, we’ll usually spend a week or two updating and releasing all the Kubernetes CSI sidecars. So that means we only have about 2 weeks left to focus on KEP reviews after wrapping up the work from the previous release (given that there is only 4 weeks between the previous release date and the KEP freeze deadline). Having a longer enhancement period will definitely help. I’d prefer having two more weeks in the enhancement period.

Regarding the point about part-time contributors, I think a longer enhancement period will definitely help as that gives part-time contributors more time to work on the KEP and get the KEP reviewed and approved by the deadline.

For the part-time contributors who are working on implementing an enhancement, I found that a shorter enhancement period does not lead to an earlier start time because they are planning on when to work on a task based on their current workload and the code freeze deadline.

[JamesLaverack]

I'm broadly in-favour of keeping the week three enhancements freeze as it was in 1.22.

• I'd like to avoid changing stuff this visible to contributors every cycle.
• I don't think that one release is enough of a data point to draw many conclusions about how effective/ineffective the change was. I'd like to see us keep with it for at least another release to get a better idea of how it works when we're settled into it.

[mkorbi]

+1 for keeping week 3
I think we had many changes the past 2-3 releases and we should bring in some consistency and stability

[reylejano]

Data points from releases:

Release	week of Enhancements Freeze	week of Code Freeze	# of weeks in release cycle	# of enhancements opted-in at Enhancements Freeze	# of Enhancements Freeze exception requests	# of Code Freeze exception requests	Final # of enhancements
1.16	5	9	12	51	3	1	31
1.17	4	8	12	51	3	1	22
1.18	4	9	12	51	7	0	38
1.19	6	13	20	44	5	1	34
1.20	4	9	13	53	8	8	42
1.21	5	9	13	74	2	10	51
1.22	3	11	15	77	9	8	53
1.23	3	13	16	52	7	4	47

[liggitt]

do we also have code-freeze exception requests? my feeling is that the ones that had later enhancements freeze (and therefore less time between design finalization and code freeze) had more exception requests at the end of the cycle, but data would be useful

[reylejano]

We do have code freeze exception requests, I'll add the code freeze exception requests to the table

[JamesLaverack]

My current draft of the schedule for 1.24 puts enhancements freeze in week 3, as it has been for 1.22 and 1.23. Open to discussion on the point though. :)

[ehashman]

I proposed moving enhancements back to week 3 assuming a 3-month development cycle to ensure we had 8 full weeks before code freeze. With an extra month in the release cycle, having the enhancements freeze on week 3 last release felt like a rush at the beginning of the release followed by very little activity given 10 weeks before code freeze.

I think we can spare the extra week to give reviewers/approvers a bit more breathing room, and as an approver I'd really appreciate the extra time. I think many of the SIGs I'm involved with have been pushing their planning earlier to better use the full enhancements planning period, ensuring things aren't a big surprise one week before the deadline.