Documentation for rc0 tasks

[mbianchidev]

This pull request introduces significant updates to the Kubernetes release engineering docs, focusing on post-release candidate (rc.0) tasks and branch management.

The changes I made aim to streamline the release workflow, improve clarity around the process and consolidate relevant documentation into a single SRE-handbook style source.

Similar to the work done for the release cut handbook.

What type of PR is this:

/kind documentation

What this PR does / why we need it:

We need to document the post rc.0 release tasks, currently fragmentally documented in multiple repos and in a format that is not easy to understand.

Which issue(s) this PR fixes:

Fixes #2776
Fixes #2826

Special notes for your reviewer:

I also tried my best to de-duplicate content.
The milestone rules applier is all done in Code Freeze/Thaw, so I removed also that bit.

Some considerations on alpha releases have been moved to the "new" release cut handbook, too.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

• OWNERS

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

[mbianchidev]

/priority important-soon

[Vyom-Yadav]

/cc @Vyom-Yadav

[wendy-ha18]

Thanks a lot for this comprehensive doco @mbianchidev 🙏, I couldn't be able to review in details the full post-rc0-release-task but just left a few comments based on my personal thoughts.

[wendy-ha18]

Tbh I'm little confused by the current organization and structure of the release-engineering docs when I review this PR and navigating back and forth a few linked pages inside it 😿, so I just wanted to suggest a revised structure that I think might make things a bit clearer. Would love to hear your thoughts, does the structure below make sense to you?

release-engineering/
├── README.md  # overview of the team, communication channels, responsibilities, etc.
├── release-cut/  # Shared resources for both Branch Managers (X.Y.0) and Patch Release Managers (X.Y.Z)
│   ├── k8s-release-cut.md
│   ├── go.md
│   └── ......  
├── branch-manager-role/  # Tasks and guides specific to major (X.Y.0) release cycles – for Branch Manager role
│   ├── branch-manager-handbook.md
│   ├── post-rc0-release-task.md
│   └── ......  
└── patch-release-role/  # Tasks and guides specific to patch (X.Y.Z) releases – for Patch Release Manager role
    ├── patch-release-handbook.md
    └── ......  

[mbianchidev]

Tbh I'm little confused by the current organization and structure of the release-engineering docs when I review this PR and navigating back and forth a few linked pages inside it 😿, so I just wanted to suggest a revised structure that I think might make things a bit clearer. Would love to hear your thoughts, does the structure below make sense to you?

release-engineering/
├── README.md  # overview of the team, communication channels, responsibilities, etc.
├── release-cut/  # Shared resources for both Branch Managers (X.Y.0) and Patch Release Managers (X.Y.Z)
│   ├── k8s-release-cut.md
│   ├── go.md
│   └── ......  
├── branch-manager-role/  # Tasks and guides specific to major (X.Y.0) release cycles – for Branch Manager role
│   ├── branch-manager-handbook.md
│   ├── post-rc0-release-task.md
│   └── ......  
└── patch-release-role/  # Tasks and guides specific to patch (X.Y.Z) releases – for Patch Release Manager role
    ├── patch-release-handbook.md
    └── ......  

This is kinda similar to the bigger picture change I have in mind for these docs.
Still seeking consensus from the rest of the team on that.

My structure idea as mentioned above, it's more byte sized and designed SRE style, while there should still be an index.md that makes everything easier to navigate.
BUT not really based on the patch release and branch manager roles as they do overlap quite a bit, we want to have people that can do most things in releng rather than specialize in (1) task like branch management during release periods.
At least this is what was discussed in various occasions with different folks, I think it makes more sense overall.

Can you post your comment here? #2797 (just edited to include a reorg of general content in the task itself)
I think your comment it's very valuable but out of scope of this PR, thanks!

Thanks a lot for the review, great work 🙏

EDIT

so it would be something like

release-engineering/
├── README.md  # overview of the team, communication channels, responsibilities, etc.
├── handbooks/  # Shared resources for both Branch Managers (X.Y.0) and Patch Release Managers (X.Y.Z)
    ├── k8s-release-cut.md
    ├── go.md
    ├── post-rc0-release-task.md
    ├── patch-releases.md
    ├── cherry-picks.md
    ├── cve-patch.md
    ├── ....
   └── README.md # explaining everything contained in the hadnbooks and grouping them a bit based on (maybe even roles, but more situations, things to do)

[drewhagen]

A few comments to start as I continue to review

[xmudrii]

Some initial comments on the checklist

[mbianchidev]

/hold

Do not merge until the RC.0 cut is done so we can validate these docs and fix the last few things.

Will still create an issue using the latest template

[Vyom-Yadav]

Thanks for working on this Matteo 💙

[Vyom-Yadav]

Linking to examples, maybe: kubernetes/test-infra#34651. I know examples can go obsolete, but having some context helps (and examples can be updated if config management changes) (edit - same above example comment)

[xmudrii]

@mbianchidev We should consider adding a table of contents if possible to all new handbooks.

[xmudrii]

@mbianchidev Please also fix do-not-merge/contains-merge-commits so that we can merge this PR once comments are addressed

[mbianchidev]

@mbianchidev Please also fix do-not-merge/contains-merge-commits so that we can merge this PR once comments are addressed

Solved!