📖 doc: add release cycle doc

[sbueringer]

Signed-off-by: Stefan Büringer [email protected]

What this PR does / why we need it:
Hey folks,
this is the follow-up from the discussion during the office hours today.

The dates are preliminary but I think it it's good to have some specific dates already that we can move +/- a day or two if necessary.

The timeline is inspired by the Kubernetes timeline here (https://github.com/kubernetes/sig-release/blob/master/releases/release-1.26/README.md). They have a lot more dates in their timeline, but I think we should start small and then the first release team can add more dates (e.g. for things like writing release notes). But I think we also don't have to over-formalize it for now and define dates for everything

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Part of #7389

[alexander-demicev]

great description of the release cycle!

[enxebre]

Thanks for putting this together Stefan

[sbueringer]

Thx for the reviews everyone!

Fixed some findings, answered on others.

[fabriziopandini]

@sbueringer thanks for pushing this forward, really appreciated.
I have added a couple of comments/suggestions trying to clarify some points about what happens on main vs what happens on the release branch, but this is a great start!

[sbueringer]

Thx for the feedback!

Pushed another version

[sbueringer]

Hey folks,
just a general PSA, we would aim to merge this document until end of next week (before KubeCon) if no blocking issues are coming up. Just to have the dates finalized.
(as discussed in the office hours)

[sbueringer]

/retest

[furkatgofurov7]

Thanks for putting this together @sbueringer! Some nits inline:

[furkatgofurov7]

One question I forgot to mention earlier: Looking through the k8s timeline doc, noticed they had a weekly meeting minutes (and a separate google doc) dedicated to the release team. Are we also planning to have one as well and if so, does it worth mentioning it in this document?

[sbueringer]

And pushed another version :)

One question I forgot to mention earlier: Looking through the k8s timeline doc, noticed they had a weekly meeting minutes (and a separate google doc) dedicated to the release team. Are we also planning to have one as well and if so, does it worth mentioning it in this document?

I think if we choose to have one as well it would be great to have it here. Essentially to have this as a landing page like they have it in upstream (~ https://github.com/kubernetes/sig-release/tree/master/releases/release-1.26). If this page gets to big we can also split it up in one per-release.

As we didn't discuss/decide yet how the release team organizes itself I would wait for that and then the page can be adjusted accordingly. I'll make a note in the umbrella issue that we have to figure out how the release team coordinates itself / the working model of the release team.

[VibhorChinda]

Thanks @sbueringer for putting this together :))
The document content looks good to me.

One thought should we go into more modular approach like done for the Kubernetes release repository link

Something I tried to sketch out, please have a look.

The thought behind this approach was to keep process smoother in later releases because like adding timelines for all cycles in one document like above will keep increasing the document too much I feel.

Open for everyone's suggestion :))

[sbueringer]

@VibhorChinda I think you're suggestion is fine. I just wanted to keep it in one doc for the start and we can split it up later when we add more.

As of today we just don't have the same complexity as Kubernetes has and I would want to wait and see if we actually get to that or even need it. (just looking at all the docs they have...)

[VibhorChinda]

@VibhorChinda I think you're suggestion is fine. I just wanted to keep it in one doc for the start and we can split it up later when we add more.

As of today we just don't have the same complexity as Kubernetes has and I would want to wait and see if we actually get to that or even need it. (just looking at all the docs they have...)

Understood 👍🏻 :))

[ykakarap]

The document is great!

Thank you for doing this :)

[fabriziopandini]

One last nit from my side, otherwise lgtm
This is a great start!

[sbueringer]

And another version :)

[fabriziopandini]

/lgtm

[CecileRobertMichon]

/lgtm

[sbueringer]

(just updated the v1.2.x releases now that we did an additional v1.2.4 bug-fix release)

[fabriziopandini]

/lgtm

[sbueringer]

Squashed

[sbueringer]

@CecileRobertMichon @fabriziopandini I would merge on Friday? (not EOD :))

[fabriziopandini]

/lgtm
+1 to merge Friday if no short stoppers pops up

[vincepri]

/approve
/hold
until Friday Oct 21st to merge, pending last minute comments

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vincepri

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vincepri]

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

[sbueringer]

/hold cancel