Projecting next cycle's release schedule

[justaugustus]

As part of today's SIG leads meeting (non-recorded), we discussed the following thread requesting deadline changes in the v1.22 release cycle: https://groups.google.com/g/kubernetes-sig-release/c/8mn7HijIxlA

While we decided amongst @kubernetes/sig-release-leads and @kubernetes/release-team-leads that we will not be further altering the Enhancements Freeze date for v1.22, the leads discussion did bring us to an actionable request:

Can SIG Release endeavor to provide dates for the following release cycle ahead of time?

I think it's something we can definitely strive to do!

Here's an idea of workflow:

• SIG Release leads set a framework for devising the schedule: https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/2572-release-cadence#schedule-policy
• The current cycle's Release Team Lead shadows (+/- RT lead) and Emeritus Adviser present a notional schedule to SIG Release leads
• If approved, the notional schedule is then presented to the current Release Team for further feedback
• One of the schedule author's (RT Lead shadows or EA) open a schedule PR by foo date (which deadline should this align to?)
• Open wider community comment period to end by bar date (set lazy consensus; maybe Code Freeze?)
• Resolve feedback
• Merge
• Announce

Let's discuss!

[justaugustus]

Note sent to k-dev + leads + sig-release-leads: https://groups.google.com/g/kubernetes-dev/c/3_gamfTmUYQ

[jeremyrickard]

I'm very, very much in favor of planning and announcing these early, for a few reasons:

• as a previous RT lead, it was stressful to do the schedule in a short amount of time and iterate on it
• as someone now working on a KEP it would be good to know when I absolutely need it done for the 1.23 :)

Having worked through some permutations during the release cadence KEP, there is not a TON of wiggle room on things with the policy things we have laid out, so I think that we can forecast out pretty well.

I also think that EARLIER would be better for folks. Like the schedule for the next release should be up for review no later than code freeze, imo. Things get busy then, and we should really be able to identify dates much earlier and allow a much more inclusive feedback period. If we can land on more or less fixed durations for phases (our enhancement collection period was reduced for 1.22), then we should be able to forecast these out quite well. We should probably document what those durations are for reference and allow feedback/comment on those as part of this process as well.

We can, and should, be responsive to world events and be empathetic to contributors and adjust dates as needed (RT Lead + SIG Release Leads), but we should be able to provide those dates much more in advance than we do now to let folks plan better :)

Some context:

Notional dates from from the release cadence KEP.

2021.....

Year Week Number	Release Number	Release Week	Note
2	1	1 (January 11)
14	1	13 (April 8)
17	2	1 (April 26)
32	2	15 (August 02)	KubeCon EU Break (May 4-7)
35	3	1 (August 30)
50	3	15 (December 14)	Kubecon Break (Oct 12-15)

2022.....

Year Week Number	Release Number	Release Week	Note
1	1	1 (January 3)
15	1	15 (April 12)
17	2	1 (April 26)	Probably KubeCon EU
32	2	15 (August 09)
34	3	1 (August 22	Probably KubeCon NA
49	3	14 (December 06)

[tpepper]

I like this projection very much!

The one thing I'd like to see additionally is that we challenge our leaders to be thinking of how much of the coming year we can actually tentatively forecast and do so with an eye for our people and sustainability. There's always things we can't predict, but in past release cycles we definitely considered how beyond the current 12 (or now 14-15) week cycle a current choice might ripple out. We would look at KubeCon and Ramadan, Chinese New Year and US Fourth of July, Europe's August and a lot of people's December, US Thanksgiving and sometimes even Canada's Thanksgiving eh ;). Aside from KubeCon, these major events are known and impact big chunks of our community. Folks have focused on KubeCon this spring, but consideration was also given to Ramadan and both Eastern and Western Easters and COVID and home child care versus spring breaks. There was a lot going on and it meant no one choice was clearly optimal. Similarly it's an added need for leads to be thinking now about later this year if/when we hopefully are turning the corner on the human catastrophe still unfolding and maybe people just decide to do the equivalent of a normal "Europe August" and not a lot of engineering happens later in the year versus reuniting with family and friends. The sooner our teams' planning can identify conflict or pending overload/overcommit, the better. And realistically we should be able to see quite a bit of these looming through 2021.

In this context, might it make sense for SIG Release to be proposing the notional calendar for the year up front, and the outgoing release team to be affirming for the incoming release team what deviations from that are needed relative to then current knowledge? Knowledge of the schedule should also make it easier for incoming release team candidates to commit to the cycle, albeit at the cost of them being less involved in setting the schedule. The up front notional calendar and the fixing of the specific calendar start to represent institutional memory of future potential conflict avoided and steps that were taken to help the next team succeed.

[jeremyrickard]

I agree with this very much, thank you for the additional consideration points! I think we could do a better job of considering global holidays, which are very much predictable up front, and would very much fit with the international nature of the release team and community in general.

Realistically with the kubecon date known, we could plan through 1.25 with all of these in mind.

[jberkus]

+1, this would make everyone much happier I think, and it's really not like, pending another pandemic, we don't know when the releases need to fall and their related dates. As soon as we get Kubecon dates from the CNCF, we could set things, and only adjust if the release is actually more than a week late (which hasn't happend since 2017).

[saschagrunert]

Yes, planning earlier and refining continuously seems a valuable approach to me. Maybe we have to distinguish two aspects of the conversation:

1. Planning the next release cycle ahead of time.
2. Planning and refining the release cycles after the next one.

While I think 1. can be done with the workflow described in @justaugustus's initial post, I guess we have to make sure that 2. may change due to events we did not take into account. Having different planning granularities makes sense to me, whereas we could also state that, for example, we always plan 1 year into the future.

I'm supportive.

[soltysh]

👍 we should clearly mark proposed schedule vs final one at the top of the document, so it's obvious to the reader.

[divya-mohan0209]

👋 everyone, in addition to all of the amazing suggestions above I would like to add the following:

• When the RT Lead shadows + EA present the notional dates for the release, we should timebox it to (ideally) fall within the last month/month and a half of the current release. Code freeze would be a nice date to start with.
• This would mean we have sufficient time for a. Approvals from the SIG Release Leads b. Presenting it to the current RT + the wider audience for feedback.
• Not 100% sure if there are any pitfalls to opening up for discussions to both parties simultaneously - the RT + the wider audience. Doing so, however, would buy us more time for discussion as opposed to going step-by-step.
• I believe the retro would be the perfect avenue to call for any last thoughts on this matter, post which the next cycle Release lead can merge the schedule.
• Also given the situation we ran into with this release, I believe that we also need to ensure all relevant stakeholders are able to participate in this discussion and we are as inclusive/empathetic as possible. So maybe gentle reminders on different forums - slack, GitHub, monthly chair/leads call (perhaps?) would be helpful. I know it sounds a little too meticulous, but life happens & there's a possibility people miss out on some of the important notifications.

[jberkus]

I'll tag it in LWKD.