# Improvement tasks for v1.6 release cycle

**Recordings:**
- Part1: https://youtu.be/-QMgC7LYcio
- Part2: https://youtu.be/z-Gae9FUVv0

## Labels

- priority/awaiting-more-evidence - Lowest priority. Possibly useful, but not yet enough support to actually get it done.
- priority/backlog - Higher priority than priority/awaiting-more-evidence.
- priority/important-longterm - Important over the long term, but may not be staffed and/or may need multiple releases to complete.
- priority/important-soon - Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
- priority/critical-urgent - Highest priority. Must be actively worked on as someone's top priority right now.

## CI Signal/Bug Triage/Automation Manager/Team

* [x] Automate release branch and tag creation **(@CecileRobertMichon)**
- Issue: #7128
- PR: https://github.com/kubernetes-sigs/cluster-api/pull/9111
* [ ] Create SBoM of all the Cluster API components and verify checksum as a post build action ( **@anurag** )
- Issue: https://github.com/kubernetes-sigs/cluster-api/issues/6153
- **priority**: priority/backlog
* [x] ❌ 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. **(@furkatgofurov7)**
* Example: To tag members of the release team on PR (may be auto generated) on repos outside of the kubernetes-sigs org, like kubernetes/test-infra repo on image promotion PRs
* Context: https://github.com/kubernetes-sigs/cluster-api/pull/7487#discussion_r1013480624
* Based on the slack [discussion](https://kubernetes.slack.com/archives/C8TSNPY4T/p1692087219381359), marking this as `won't do/cancelled` since anyways there is no point of cc ng RT members who themselves will be creating image promotion PR on the release cutting call.
* [x] ❌ cc release team on cherry-pick PRs **(@cahillsf)**
* 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
* Issue: https://github.com/kubernetes-sigs/cluster-api/issues/9212
* Based on the issue discussion, marking this as won't do/cancelled.
* [ ] Theoretically we can use k8s-triage to generate bug reports for flaky tests via "file bug" ([link](https://storage.googleapis.com/k8s-triage/index.html?job=periodic-cluster-api-e2e-main)). 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. ( **@sunnat** )
- **priority**:[cecile/stefan/furkat] priority/backlog
* [ ] Consider implementing a tool to generate our ProwJob YAMLs to make the jobs easier to manage **(@killianmuldoon)**
* also check if there is already something like that
* Issue: https://github.com/kubernetes-sigs/cluster-api/issues/9257
* **priority**: [killian/stefan] priority/important-soon
* [x] ❌ Improve the Homebrew publish process
* Context: https://github.com/kubernetes-sigs/cluster-api/issues/6613
* **priority**: not to do
* [ ] 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.( @nawazkh )
* **priority**: [killian] priority/important-soon
* we need to document it better
* [ ] Clearly define the CI team's scope **(moved from Misc section)** ( @nawazkh )
* **priority**: [nawaz] priority/important-soon
* [ ] Resolve release series labels in e2e config Refer to CAPI [#5008](https://github.com/kubernetes-sigs/cluster-api/issues/5008) ( **@adil** )
* **priority**: [nawaz] priority/important-soon

## Communications/Docs/Release Notes Manager/Team (prioritized by the team Lead)

- [ ] Create a checklist that enumerates all the manual edits necessary in the release notes so it can followed on each release day.**(@g-gaston)**
* **priority**: priority/important-soon
- [ ] Add missing "info blocks" to the release notes tool output (supported k8s versions, etc.). Even if the content is not automated, output a "template" with placeholders. **(@mjlshen)**
- Issue: https://github.com/kubernetes-sigs/cluster-api/issues/9248
- PR: https://github.com/kubernetes-sigs/cluster-api/pull/9247
- [ ] Deduplicate prefixes in release notes. Where the PR title already contains a prefix which is the same as its area, e.g. #8953. The prefix should be deduplicated. **(@Dhairya-Arora01)**
- [ ] Tracking issue: https://github.com/kubernetes-sigs/cluster-api/issues/9190
- [ ] PR: https://github.com/kubernetes-sigs/cluster-api/pull/9186
- [ ] Create announcement templates to help specify all the comms needed and have a pre-established format to make it easier on the team. This includes slack messages and emails for releases, weekly updates, etc. **(@willie-yao)**
* **priority**: priority/important-soon**
- [ ] 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.
- **priority**: priority/important-soon
- [cecile] reach out to cecile to know the details
- [ ] Ensure we have documentation on how to consume beta / RC releases (for users)
- **priority**: priority/important-soon
- [ ] Document how to consume nightly Cluster API releases with clusterctl and with the test framework.
- **priority**: priority/important-soon
- [ ] Consider adding expandable auto-generated release notes for beta and RC (non-GA) releases **(@nprokopic)**
* **priority**: priority/backlog
- [ ] Automate parts of the release notes that are "constant" through a minor release by reading from some file to populate the data. For example, the supported kubernetes versions can be maintained in a file on each release branch independently.
- **priority**: [killian] priority/backlog
- [ ] Doc improvement: communication guidelines **(moved from Misc section)**
- 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
- **priority**: priority/backlog
- [ ] Format dependencies to exclude multiple bumps in the same set of release notes. For Go dependencies there's a discussion in this thread: https://kubernetes.slack.com/archives/C8TSNPY4T/p1686045243091189. For Github actions and other dependencies an alternative solution will have to be found.
- **priority**: [stefan] priority/backlog
- [stefan]: we need to look into upstream k/k or other projects
- [ ] Define details of "Communicate key dates to the community"
- **priority**: [killian] priority/backlog
- [ ] Release note tool should not ignore squashed PRs
- Issue: https://github.com/kubernetes-sigs/cluster-api/issues/9249
- **priority**: priority/important-longterm
- take a look at https://github.com/kubernetes-sigs/cluster-api/issues/8051 before taking an action, actual issue https://github.com/kubernetes-sigs/cluster-api/issues/8292
- [x] 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)
- PRs:
- https://github.com/kubernetes-sigs/cluster-api/pull/8780
- https://github.com/kubernetes-sigs/cluster-api/pull/8928
- https://github.com/kubernetes-sigs/cluster-api/pull/8826
- https://github.com/kubernetes-sigs/cluster-api/pull/9071

## Misc

- [ ] start using github project boards to track release improvements **(@furkatgofurov7)**
- [furkat] test board: https://github.com/orgs/kubernetes-sigs/projects/55
- [ ] Explore the idea of "an issue triage team" - a team that is responsible for triaging issues that come into the repo. **(@furkatgofurov7)**
- [furkat] Upstream k8s release team used to have it until last release cycle (v1.28) and starting from v1.29 the plan is to merge CI + Bug Triage teams into a single team (Release Signal Team), xref: https://github.com/kubernetes/sig-release/issues/2209
- [ ] automate updates to specific versions of https://doc.crds.dev/github.com/kubernetes-sigs/cluster-api after release is cut
- the link: https://doc.crds.dev/github.com/kubernetes-sigs/cluster-api@latest needs to be called at least once before it's cached as the base page for the repo. The idea is to automate that update - we could initially document checking that page as a task during the release process manually. Automation can also be considered, i.e the same way how it is done in https://github.com/oracle/cluster-api-provider-oci/blob/main/.github/workflows/release.yaml#L28-L31
- [ ] Doc improvement (add a note about checkpoint): Consider expanding the team even during the release cycle to handle no-shows.**(@furkatgofurov7)**
- 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 recommendation to leads tasks):Communicate and set clear expectations between the leads and the shadows about timeline and rotation. **(@Prajyot-Parab )**
- Clearly communicate that we will aim for rotation of ownership.
- Issue: https://github.com/kubernetes-sigs/cluster-api/issues/9216
- [x] Doc improvement: consider "public release session" **(@Prajyot-Parab )**
- 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.
- Issue: https://github.com/kubernetes-sigs/cluster-api/issues/9216
- PR: https://github.com/kubernetes-sigs/cluster-api/pull/9232
- [ ] Document in the RL release tasks about removing unsupported release version of CAPI while working on preparing main branch PR (remove v1.3 while working on v1.6) **(@chiukapoor)**
- [ ] Document in the RL release tasks about making sure to update the GitHub actions to work with the new v1.6 release during week 15. Maybe make check lists tasks for future releases. **(@chiukapoor)**