Skip to content

Commit

Permalink
Remove "Maintainer" role related notes and document responsibilities …
Browse files Browse the repository at this point in the history
…in the release process

Signed-off-by: Furkat Gofurov <furkat.gofurov@suse.com>
  • Loading branch information
furkatgofurov7 committed Nov 28, 2023
1 parent 916eff9 commit 311ab50
Show file tree
Hide file tree
Showing 4 changed files with 16 additions and 40 deletions.
2 changes: 1 addition & 1 deletion .github/ISSUE_TEMPLATE/release_tracking.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,8 +52,8 @@ Week 15:
* KubeCon idle week

Week 16:
* [ ] [Release Lead] [Create the release-1.6 release branch](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md#create-a-release-branch)
* [ ] [Release Lead] [Cut the v1.6.0-rc.0 release](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md#repeatedly-cut-a-release)
* [ ] [Release Lead] [Update milestone applier and GitHub Actions](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md#update-milestone-applier-and-github-actions)
* [ ] [CI Manager] [Setup jobs and dashboards for the release-1.6 release branch](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md#setup-jobs-and-dashboards-for-a-new-release-branch)
* [ ] [Communications Manager] [Ensure the book for the new release is available](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md#ensure-the-book-for-the-new-release-is-available)

Expand Down
48 changes: 13 additions & 35 deletions docs/release/release-tasks.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ This document details the responsibilities and tasks for each role in the releas
- [[Track] Bump dependencies](#track-bump-dependencies)
- [Set a tentative release date for the next minor release](#set-a-tentative-release-date-for-the-next-minor-release)
- [Assemble next release team](#assemble-next-release-team)
- [Create a release branch](#create-a-release-branch)
- [Update milestone applier and GitHub Actions](#update-milestone-applier-and-github-actions)
- [[Continuously] Maintain the GitHub release milestone](#continuously-maintain-the-github-release-milestone)
- [[Continuously] Bump the Go version](#continuously-bump-the-go-version)
- [[Repeatedly] Cut a release](#repeatedly-cut-a-release)
Expand All @@ -37,6 +37,7 @@ This document details the responsibilities and tasks for each role in the releas
- [Add docs to collect release notes for users and migration notes for provider implementers](#add-docs-to-collect-release-notes-for-users-and-migration-notes-for-provider-implementers)
- [Update supported versions](#update-supported-versions)
- [Ensure the book for the new release is available](#ensure-the-book-for-the-new-release-is-available)
- [Generate weekly PR updates to post in Slack](#generate-weekly-pr-updates-to-post-in-slack)
- [Create PR for release notes](#create-pr-for-release-notes)
- [Change production branch in Netlify to the new release branch](#change-production-branch-in-netlify-to-the-new-release-branch)
- [Update clusterctl links in the quickstart](#update-clusterctl-links-in-the-quickstart)
Expand All @@ -49,10 +50,6 @@ This document details the responsibilities and tasks for each role in the releas
- [[Continuously] Monitor CI signal](#continuously-monitor-ci-signal)
- [[Continuously] Reduce the amount of flaky tests](#continuously-reduce-the-amount-of-flaky-tests)
- [[Continuously] Bug triage](#continuously-bug-triage)
- [Maintainer](#maintainer)
- [Responsibilities](#responsibilities-3)
- [Tasks](#tasks-3)
- [[Repeatedly] Publish the release](#repeatedly-publish-the-release)

<!-- END doctoc generated TOC please keep comment here to allow auto update -->

Expand All @@ -66,7 +63,7 @@ This document details the responsibilities and tasks for each role in the releas
* Create and maintain the GitHub release milestone
* Track tasks needed to add support for new Kubernetes versions in upcoming releases
* Ensure a retrospective happens
* Ensure a maintainer is available when a release needs to be cut.
* Ensure one of the [maintainers](https://github.com/kubernetes-sigs/cluster-api/blob/main/OWNERS_ALIASES) is available when a release needs to be cut.
* Staffing:
* Assemble the release team for the next release cycle
* Ensure a release lead for the next release cycle is selected and trained
Expand Down Expand Up @@ -162,17 +159,16 @@ We should take a look at the following dependencies:
There is currently no formalized process to assemble the release team.
As of now we ask for volunteers in Slack and office hours.

#### Create a release branch
#### Update milestone applier and GitHub Actions

The goal of this task is to ensure we have a release branch and the milestone applier applies milestones accordingly.
Once release branch is created by GitHub Automation, the goal of this task would be to ensure we have the milestone
applier that applies milestones accordingly and to update GitHub actions to work with new release version.
From this point forward changes which should land in the release have to be cherry-picked into the release branch.

1. Ask the [Maintainer](#maintainer) to create a new release branch.

2. Update the [milestone applier config](https://github.com/kubernetes/test-infra/blob/0b17ef5ffd6c7aa7d8ca1372d837acfb85f7bec6/config/prow/plugins.yaml#L371) accordingly (e.g. `release-1.4: v1.4` and `main: v1.5`)
1. Update the [milestone applier config](https://github.com/kubernetes/test-infra/blob/0b17ef5ffd6c7aa7d8ca1372d837acfb85f7bec6/config/prow/plugins.yaml#L371) accordingly (e.g. `release-1.4: v1.4` and `main: v1.5`)
<br>Prior art: [cluster-api: update milestone applier config for v1.3](https://github.com/kubernetes/test-infra/pull/26631)

3. Update the GitHub Actions to work with the new release version.
2. Update the GitHub Actions to work with the new release version.
<br>Prior art: [Update actions for 1.5 and make names consistent](https://github.com/kubernetes-sigs/cluster-api/pull/9115)

#### [Continuously] Maintain the GitHub release milestone
Expand Down Expand Up @@ -232,7 +228,10 @@ to a newer Go minor version according to our [backport policy](./../../CONTRIBUT
```
4. Publish the release in GitHub:
1. Ask the [Maintainer](#maintainer) to publish the release in GitHub.
1. Reach out to one of the maintainers over the Slack to publish the release in GitHub.
* **NOTE:** clusterctl will have issues installing providers between the time the release tag is cut and the Github release is published. See [issue 7889](https://github.com/kubernetes-sigs/cluster-api/issues/7889) for more details.
* The draft release should be automatically created via the [Create Release GitHub Action](https://github.com/kubernetes-sigs/cluster-api/actions/workflows/release.yaml) with release notes previously committed to the repo by the release team. Ensure by reminding the maintainer that release is flagged as `pre-release` for all `beta` and `rc` releases or `latest` for a new release in the most recent release branch.
5. Publish `clusterctl` to Homebrew by bumping the version in [clusterctl.rb](https://github.com/Homebrew/homebrew-core/blob/master/Formula/c/clusterctl.rb).
<br>**Notes**:
* This is only done for new latest stable releases, not for beta / RC releases and not for previous release branches.
Expand Down Expand Up @@ -543,25 +542,4 @@ The goal of bug triage is to triage incoming issues and if necessary flag them w
and add them to the milestone of the current release.
We probably have to figure out some details about the overlap between the bug triage task here, release leads
and Cluster API maintainers.
## Maintainer
The Maintainer must be a person with write access to the Cluster API repo. They can hold another role in the release team. The Maintainer need only be involved in the release as required on days when releases are cut. They are not expected to take part in release team meetings or other activities, but should feel free to do so.
### Responsibilities
* Be available on release day in case the release team needs help with tag creation.
* Publish the release.
* Ensure a substitute is nominated if they are not available.
### Tasks
#### [Repeatedly] Publish the release
**NOTE:** clusterctl will have issues installing providers between the time the release tag is cut and the Github release is published. See [issue 7889](https://github.com/kubernetes-sigs/cluster-api/issues/7889) for more details
Publish the release.
1. The draft release should be automatically created via the [Create Release GitHub Action](https://github.com/kubernetes-sigs/cluster-api/actions/workflows/release.yml) with release notes previously committed to the repo by the release team.
2. Publish the release. Ensure release is flagged as `pre-release` for all `beta` and `rc` releases or `latest` for a new release in the most recent release branch.
and Cluster API maintainers.
3 changes: 1 addition & 2 deletions docs/release/release-team.md
Original file line number Diff line number Diff line change
Expand Up @@ -71,8 +71,7 @@ As noted above, making changes to the CAPI release cadence is out of scope for
- **Communications/Docs/Release Notes Manager**: Responsible for communicating key dates to the community, improving release process documentation, and polishing release notes. Also responsible for ensuring the user-facing Netlify book and provider upgrade documentation are up to date.
- **CI Signal/Bug Triage/Automation Manager**: Assumes the responsibility of the quality gate for the release and makes sure blocking issues and bugs are triaged and dealt with in a timely fashion. Helps improve release automation and tools.
- **Team member**: Any Release Team lead or manager may select one or more additional members to help with their tasks. These team members will help fulfill future Release Team staffing requirements and continue to grow the CAPI community in general.
- **Maintainer**: Responsible for tasks which require write access to the Cluster API repo including creating release tags and creating a release branch. This role must be filled by someone on the [`cluster-api-maintainers` list](https://github.com/kubernetes-sigs/cluster-api/blob/main/OWNERS_ALIASES).
*Note*: This is also documented in [Release tasks](./release-tasks.md) together with a mapping to specific tasks.
*Note*: This is also documented in [Release tasks](./release-tasks.md) together with a mapping to specific tasks.

## Team repo permissions
- Release notes (`CHANGELOG` folder)
Expand Down
3 changes: 1 addition & 2 deletions docs/release/releases/release-1.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,5 +32,4 @@ After the `.0` release monthly patch release will be created.
|-------------------------------------------|-------------------------------------------------------------------------------------------|----------------------------------------|
| Release Lead | TBD | TBD |
| Communications/Docs/Release Notes Manager | TBD | TBD |
| CI Signal/Bug Triage/Automation Manager | TBD | TBD |
| Maintainer | TBD | TBD |
| CI Signal/Bug Triage/Automation Manager | TBD | TBD |

0 comments on commit 311ab50

Please sign in to comment.