Improvement tasks for v1.5 release cycle

[joekr]

NOTE: To be clear, this is a list of potential improvements and is meant as a backlog.
The idea is not that we have to implement all of those within the v1.5 release cycle.
It's also an umbrella issue, please create separate issues for the individual sub-tasks.
Some issues will be pull from the previous release improvement list as well #7524
Some issues came from the v1.4 release retro docs

CI Signal/Bug Triage/Automation Manager/Team

• Automate release branch and tag creation: Automate release branch and tag creation #7128
• Security Self-Assessment: [STRIDE-TAMPER-1] Produce a SBoM #6153 (depends on upstream implementation) (@furkatgofurov7)
• cc release team on image promotion PRs: 🌱 cc @cluster-api-release-team when auto-opening the PR to promote images from staging to prod #7487
• cc release team on cherry-pick PRs (@nawazkh)
  • Best way to do it, is probably by extending the cherrypicker in test-infra
  • Alternative or temporary solution could be a GitHub action in the cluster-api repo
• Theoretically we can use k8s-triage to generate bug reports for flaky tests via "file bug" (link). Unfortunately the issues are always filed against k/k so we have to manually copy&paste the issue text to a Cluster API repo. Let's see if we can improve k8s-triage to be able to create issues in the Cluster API repo. (@aniruddha2000)
• Consider implementing a tool to generate our ProwJob YAMLs to make the jobs easier to manage (@sbueringer)
  • also check if there is already something like that
• Improve the Homebrew publish process (@alexander-demicev)
  • Context: Homebrew publish on release does not work #6613
• Improve the Netlify access model. Right now only limit people have access to the Netlify and for doing any thing regarding Netlify the people with access have to do some manual work. There is scope to improve this, either through more automation or more shared access.
• Setup a periodic (weekly?) hack session to look at flaky tests

Communications/Docs/Release Notes Manager/Team

• Define details of "Communicate key dates to the community"
• Consider adding expandable auto-generated release notes for beta and RC (non-GA) releases
• Ensure we have documentation on how to consume beta / RC releases (for users)
• Potential improvements to generating release notes that automatically have the clusterctl: or E2E: or KCP: against the PR titles. Currently this process is done manually. May be we can improve this my looking at the area/xxx label of the PR or even consider some kind of PR title validation to make sure that users provide the prefix (kind of like how they currently provide ✨ , 🌱 , etc)
• Document how to consume nightly Cluster API releases with clusterctl and with the test framework
• Update documentation to build release notes tool from main before generating notes. We don't want to use go run anymore. Setup make target and ensuring the same binary is run on each release branch
• Can we add a line to somewhere in the release notes task to clean these up and mention the MISSING / MULTIPLE keys? This is new in this cycle but will be really useful for the upcoming release team.

Misc

• automate updates to specific versions of https://doc.crds.dev/github.com/kubernetes-sigs/cluster-api after release is cut
• start using github project boards to track release improvements

• Having a team alias in the OWNER/OWNER_ALIASES file so that it could be potentially used as a single source of truth where we need to know the list of release team members - could be used in some kind of automation.
  • Example: To tag members of the release team on PR (may be auto generated) on repos outside of the kuberetens-sigs org, like kubernetes/test-infra repo.
  • Context: 🌱 cc @cluster-api-release-team when auto-opening the PR to promote images from staging to prod #7487 (comment)

• Clearly define the CI team’s scope.
• Explore the idea of “an issue triage team” - a team that is responsible for triaging issues that come into the repo.
• The release team should review documentation at the beginning of the cycle to become aware of the existing process and tools.
• Consider expanding the team even during the release cycle to handle no-shows.
  • Setup guidelines for off-boarding.
  • Have a check-point to re-confirm with members of the release team about commitment for the rest of the release cycle.
• Doc improvement (task for onboarding/first weeks): The release team should review documentation at the beginning of the cycle to become aware of the existing process and tools.
• Doc improvement (add a note about checkpoint): Consider expanding the team even during the release cycle to handle no-shows.
  • Setup guidelines for off-boarding.
  • Have a check-point to re-confirm with members of the release team about commitment for the rest of the release cycle.
• Doc improvement (add a recommendation to leads tasks):Communicate and set clear expectations between the leads and the shadows about timeline and rotation.
  • Clearly communicate that we will aim for rotation of ownership.
• Doc improvement: communication guidelines
  • Public should be default - it gives visibility on the work being done, it is inclusive, it is a track of record -
  • Group DM as a safe space, but not for the actual work
• Doc improvement: consider “public release session”
  • Suggestion: Start a zoom meeting and make it public. Let’s kick start the process in the zoom meeting. If there is time to just wait for some process to complete, use the time to discuss any issues/questions or just hop back on when ready to continue.

[joekr]

/assign @joekr

This is a place holder until after the 1.4 retrospective. Then I'll pull the open issues over.

[killianmuldoon]

/triage accepted

[joekr]

I'm going to slowly start moving these long running release tasks into a release project https://github.com/orgs/kubernetes-sigs/projects/37/views/1. This way we can hand over outstanding issues instead of creating a new tracking issue for each release. This will also allow folks to update tasks. Then once they are ready to work them or need to open a discussion we can convert to issues easier than a single issue owner.

[killianmuldoon]

Setup a periodic (weekly?) hack session to look at flaky tests

We're currently doing this - I'll open a PR to add this to the CI team's tasks and we can close that one off.

[killianmuldoon]

PR for the hacking session: #8787

[furkatgofurov7]

@joekr perhaps we need to rename the issue title to v1.6 release cycle now?

Edit: I created a new one to track 1.6 and this can be closed now.

[joekr]

Closing issue as a v1.6 issue has been created.

[sbueringer]

Creating a separate one per release sounds also better to me.