Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

releases: Update patch release schedule and add Release Manager info #27997

Merged
merged 9 commits into from
May 20, 2021
Merged

releases: Update patch release schedule and add Release Manager info #27997

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
5dee7af
OWNERS: Update SIG Release content reviewers/approvers
justaugustus May 15, 2021
8bdc23c
scripts: Allow SIG Release to approve changes to update-release-info
justaugustus May 15, 2021
39796d1
releases: Canonicalize patch release information on k/website
justaugustus May 15, 2021
a2c1fd7
releases: Canonicalize Release Managers page on k/website
justaugustus May 15, 2021
5da03f2
release-managers: Update personnel
justaugustus May 15, 2021
a0ef54f
release-managers: Link cleanup
justaugustus May 15, 2021
006fbf6
patch-releases: Update cycle after May releases and EOL 1.18
justaugustus May 15, 2021
5bcadad
release-managers: Add Security Release Team Slack contact methods
justaugustus May 19, 2021
2021ada
releases: Update script reference and front matter for release.md
justaugustus May 19, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions OWNERS_ALIASES
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -233,7 +233,13 @@ aliases:
- mrbobbytables
- nikhita
- parispittman
# authoritative source: git.k8s.io/release/OWNERS_ALIASES
# authoritative source: https://git.k8s.io/sig-release/OWNERS_ALIASES
sig-release-leads:
- hasheddan # SIG Technical Lead
- jeremyrickard # SIG Technical Lead
- justaugustus # SIG Chair
- LappleApple # SIG Program Manager
- saschagrunert # SIG Chair
release-engineering-approvers:
- cpanato # Release Manager
- hasheddan # subproject owner / Release Manager
Expand All @@ -244,9 +250,10 @@ aliases:
release-engineering-reviewers:
- ameukam # Release Manager Associate
- jimangel # Release Manager Associate
- markyjackson-taulia # Release Manager Associate
- mkorbi # Release Manager Associate
- palnabarun # Release Manager Associate
- onlydole # Release Manager Associate
- sethmccombs # Release Manager Associate
- thejoycekung # Release Manager Associate
- verolop # Release Manager Associate
- wilsonehusin # Release Manager Associate
- wilsonehusin # Release Manager Associate
4 changes: 3 additions & 1 deletion content/en/releases/OWNERS
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,9 @@ reviewers:

approvers:
- sig-docs-en-owners
- sig-release-leads
- release-engineering-approvers

labels:
- sig/release
- sig/release
- area/release-eng
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might need to add this label to the repo as well(?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR opened for the area/release-eng label here: kubernetes/test-infra#22272

63 changes: 16 additions & 47 deletions content/en/releases/patch-releases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,15 +1,7 @@
---
title: Patch Releases
type: docs
auto_generated: true
---
<!-- THIS CONTENT IS AUTO-GENERATED via ./scripts/update-release-info.sh in k/website -->

{{< warning >}}
This content is auto-generated and links may not function. The source of the document is located [here](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md).
{{< /warning >}}

# Kubernetes Patch Releases
Comment on lines -4 to -12
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume we deprecate https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md and link it into this location, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we edit https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md to mention deprecation or a link to the canonical page, we'll need to automate removing that deprecation text / link from the copy on https://kubernetes.io/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I'm fine with doing that, but it'd need to happen)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sftim @saschagrunert -- That's the plan! (mentioned in the PR description)

* releases: Canonicalize patch release information on k/website
* releases: Canonicalize Release Managers page on k/website

/hold for:

* [ ]  discussion
* [ ]  approval of future patch schedule
* [ ]  accompanying tombstones in k/sig-release

The script has already been updated in support of that (ref: 39796d1).
Tombstones to follow.


Schedule and team contact information for Kubernetes patch releases.

Expand All @@ -30,24 +22,24 @@ See the [Release Managers page][release-managers] for full contact details on th

Please give us a business day to respond - we may be in a different timezone!

In between releases the team is looking at incoming cherry-pick
In between releases the team is looking at incoming cherry pick
requests on a weekly basis. The team will get in touch with
submitters via GitHub PR, SIG channels in Slack, and direct messages
in Slack and [email](mailto:release-managers-private@kubernetes.io)
if there are questions on the PR.

## Cherry-Picks
## Cherry picks

Please follow the [cherry-pick process].
Please follow the [cherry pick process][cherry-picks].

Cherry-picks must be merge-ready in GitHub with proper labels (eg:
approved, lgtm, release note) and passing CI tests ahead of the
cherry-pick deadline. This is typically two days before the target
Cherry picks must be merge-ready in GitHub with proper labels (e.g.,
`approved`, `lgtm`, `release-note`) and passing CI tests ahead of the
cherry pick deadline. This is typically two days before the target
release, but may be more. Earlier PR readiness is better, as we
need time to get CI signal after merging your cherry-picks ahead
need time to get CI signal after merging your cherry picks ahead
of the actual release.

Cherry-pick PRs which miss merge criteria will be carried over and tracked
Cherry pick PRs which miss merge criteria will be carried over and tracked
for the next patch release.

## Support Period
Expand Down Expand Up @@ -86,9 +78,10 @@ releases may also occur in between these.

| Monthly Patch Release | Target date |
| --- | --- |
| May 2021 | 2021-05-12 |
| June 2021 | 2021-06-16 |
| July 2021 | 2021-07-14 |
| August 2021 | 2021-08-11 |
| September 2021 | 2021-09-15 |
Comment on lines +83 to +84
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have some rules that we're following for choosing the release day? I'm mostly wondering about August, since Wednesday after the 11th is the 18th, which seems like a reasonable release date as well. IIRC, we did releases on and around the 18th of the month in the past.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think those rules would be part of this PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think those rules would be part of this PR.

Agreed.
@xmudrii -- would you like to own discussing a policy as a follow-up action?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@justaugustus -- Sounds good. I'll take care of that.


## Detailed Release History for Active Branches

Expand All @@ -100,6 +93,7 @@ End of Life for **1.21** is **2022-06-28**

| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
|--- |--- |--- |
| 1.21.2 | 2021-06-12 | 2021-06-16 |
| 1.21.1 | 2021-05-07 | 2021-05-12 |

### 1.20
Expand All @@ -110,6 +104,7 @@ End of Life for **1.20** is **2022-02-28**

| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
|--- |--- |--- |
| 1.20.8 | 2021-06-12 | 2021-06-16 |
| 1.20.7 | 2021-05-07 | 2021-05-12 |
| 1.20.6 | 2021-04-09 | 2021-04-14 |
| 1.20.5 | 2021-03-12 | 2021-03-17 |
Expand All @@ -126,6 +121,7 @@ End of Life for **1.19** is **2021-10-28**

| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
|--- |--- |--- |
| 1.19.12 | 2021-06-12 | 2021-06-16 |
| 1.19.11 | 2021-05-07 | 2021-05-12 |
| 1.19.10 | 2021-04-09 | 2021-04-14 |
| 1.19.9 | 2021-03-12 | 2021-03-17 |
Expand All @@ -138,40 +134,13 @@ End of Life for **1.19** is **2021-10-28**
| 1.19.2 | 2020-09-11 | 2020-09-16 |
| 1.19.1 | 2020-09-04 | 2020-09-09 |

### 1.18

**1.18** enters maintenance mode on **2021-04-28**

End of Life for **1.18** is **2021-05-12**

| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
|--- |--- |--- |
| 1.18.19 | 2021-05-07 | 2021-05-12 |
| 1.18.18 | 2021-04-09 | 2021-04-14 |
| 1.18.17 | 2021-03-12 | 2021-03-17 |
| 1.18.16 | 2021-02-12 | 2021-02-17 |
| 1.18.15 | 2021-01-08 | 2021-01-13 |
| 1.18.14 | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | 2020-12-18 |
| 1.18.13 | 2020-12-04 | 2020-12-09 |
| 1.18.12 | N/A | 2020-11-12 |
| 1.18.11 | [No-op release](https://groups.google.com/g/kubernetes-dev/c/nJix1xLQvZE) | 2020-11-11 |
| 1.18.10 | 2020-10-09 | 2020-10-14 |
| 1.18.9 | 2020-09-11 | 2020-09-16 |
| 1.18.8 | N/A | 2020-08-13 |
| 1.18.7 | 2020-08-07 | 2020-08-12 |
| 1.18.6 | 2020-07-10 | 2020-07-15 |
| 1.18.5 | 2020-06-25 | 2020-06-26 |
| 1.18.4 | 2020-06-12 | 2020-06-17 |
| 1.18.3 | 2020-05-15 | 2020-05-20 |
| 1.18.2 | 2020-04-13 | 2020-04-16 |
| 1.18.1 | 2020-04-06 | 2020-04-08 |

## Non-Active Branch History

These releases are no longer supported.

| Minor Version | Final Patch Release | EOL date |
| --- | --- | --- |
| 1.18 | 1.18.19 | 2021-05-12 |
| 1.17 | 1.17.17 | 2021-01-13 |
| 1.16 | 1.16.15 | 2020-09-02 |
| 1.15 | 1.15.12 | 2020-05-06 |
Expand All @@ -189,7 +158,7 @@ These releases are no longer supported.
| 1.3 | 1.3.10 | 2016-11-01 |
| 1.2 | 1.2.7 | 2016-10-23 |

[cherry-pick process]: https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md
[cherry-picks]: https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md
[release-managers]: /release-managers.md
[release process description]: https://git.k8s.io/community/contributors/devel/sig-release/release.md
[release process description]: /release.md
[yearly-support]: https://git.k8s.io/enhancements/keps/sig-release/1498-kubernetes-yearly-support-period/README.md
213 changes: 213 additions & 0 deletions content/en/releases/release-managers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,213 @@
---
title: Release Managers
type: docs
---
Comment on lines +1 to +4
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this original documentation or duplicated from elsewhere? (It looks like it'd be a better fit for https://k8s.dev/)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sftim -- some of the other pages link out to the Release Managers contact info, so it feels right to keep them close.

The contact info also is needed by both contributors and external consumers, which makes it a better fit for k/website.


"Release Managers" is an umbrella term that encompasses the set of Kubernetes
contributors responsible for maintaining release branches, tagging releases,
and building/packaging Kubernetes.

The responsibilities of each role are described below.

- [Contact](#contact)
- [Handbooks](#handbooks)
- [Release Managers](#release-managers)
- [Becoming a Release Manager](#becoming-a-release-manager)
- [Release Manager Associates](#release-manager-associates)
- [Becoming a Release Manager Associate](#becoming-a-release-manager-associate)
- [Build Admins](#build-admins)
- [SIG Release Leads](#sig-release-leads)
- [Chairs](#chairs)
- [Technical Leads](#technical-leads)

## Contact

| Mailing List | Slack | Visibility | Usage | Membership |
| --- | --- | --- | --- | --- |
| [release-managers@kubernetes.io](mailto:release-managers@kubernetes.io) | [#release-management](https://kubernetes.slack.com/messages/CJH2GBF7Y) (channel) / @release-managers (user group) | Public | Public discussion for Release Managers | All Release Managers (including Associates, Build Admins, and SIG Chairs) |
| [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | N/A | Private | Private discussion for privileged Release Managers | Release Managers, SIG Release leadership |
| [security-release-team@kubernetes.io](mailto:security-release-team@kubernetes.io) | [#security-release-team](https://kubernetes.slack.com/archives/G0162T1RYHG) (channel) / @security-rel-team (user group) | Private | Security release coordination with the Product Security Committee | [security-discuss-private@kubernetes.io](mailto:security-discuss-private@kubernetes.io), [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) |

## Handbooks

**NOTE: The Patch Release Team and Branch Manager handbooks will be de-duplicated at a later date.**

- [Patch Release Team][handbook-patch-release]
- [Branch Managers][handbook-branch-mgmt]
- [Build Admins][handbook-packaging]

## Release Managers

**Note:** The documentation might refer to the Patch Release Team and the
Branch Management role. Those two roles were consolidated into the
Release Managers role.

Minimum requirements for Release Managers and Release Manager Associates are:

- Familiarity with basic Unix commands and able to debug shell scripts.
- Familiarity with branched source code workflows via `git` and associated
`git` command line invocations.
- General knowledge of Google Cloud (Cloud Build and Cloud Storage).
- Open to seeking help and communicating clearly.
- Kubernetes Community [membership][community-membership]

Release Managers are responsible for:

- Coordinating and cutting Kubernetes releases:
- Patch releases (`x.y.z`, where `z` > 0)
- Minor releases (`x.y.z`, where `z` = 0)
- Pre-releases (alpha, beta, and release candidates)
- Working with the [Release Team][release-team] through each
release cycle
- Setting the [schedule and cadence for patch releases][patches]
- Maintaining the release branches:
- Reviewing cherry picks
- Ensuring the release branch stays healthy and that no unintended patch
gets merged
- Mentoring the [Release Manager Associates](#associates) group
- Actively developing features and maintaining the code in k/release
- Supporting Release Manager Associates and contributors through actively
participating in the Buddy program
- Check in monthly with Associates and delegate tasks, empower them to cut
releases, and mentor
- Being available to support Associates in onboarding new contributors e.g.,
answering questions and suggesting appropriate work for them to do

This team at times works in close conjunction with the
[Product Security Committee][psc] and therefore should abide by the guidelines
set forth in the [Security Release Process][security-release-process].

GitHub Access Controls: [@kubernetes/release-managers](https://github.com/orgs/kubernetes/teams/release-managers)

GitHub Mentions: [@kubernetes/release-engineering](https://github.com/orgs/kubernetes/teams/release-engineering)

- Adolfo García Veytia ([@puerco](https://github.com/puerco))
- Carlos Panato ([@cpanato](https://github.com/cpanato))
- Daniel Mangum ([@hasheddan](https://github.com/hasheddan))
- Marko Mudrinić ([@xmudrii](https://github.com/xmudrii))
- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert))
- Stephen Augustus ([@justaugustus](https://github.com/justaugustus))

### Becoming a Release Manager

To become a Release Manager, one must first serve as a Release Manager
Associate. Associates graduate to Release Manager by actively working on
releases over several cycles and:

- demonstrating the willingness to lead
- tag-teaming with Release Managers on patches, to eventually cut a release
independently
- because releases have a limiting function, we also consider substantial
contributions to image promotion and other core Release Engineering tasks
- questioning how Associates work, suggesting improvements, gathering feedback,
and driving change
- being reliable and responsive
- leaning into advanced work that requires Release Manager-level access and
privileges to complete

## Release Manager Associates

Release Manager Associates are apprentices to the Release Managers, formerly
referred to as Release Manager shadows. They are responsible for:

- Patch release work, cherry pick review
- Contributing to k/release: updating dependencies and getting used to the
source codebase
- Contributing to the documentation: maintaining the handbooks, ensuring that
release processes are documented
- With help from a release manager: working with the Release Team during the
release cycle and cutting Kubernetes releases
- Seeking opportunities to help with prioritization and communication
- Sending out pre-announcements and updates about patch releases
- Updating the calendar, helping with the release dates and milestones from
the [release cycle timeline][k-sig-release-releases]
- Through the Buddy program, onboarding new contributors and pairing up with
them on tasks

GitHub Mentions: @kubernetes/release-engineering

- Arnaud Meukam ([@ameukam](https://github.com/ameukam))
- Jim Angel ([@jimangel](https://github.com/jimangel))
- Joyce Kung ([@thejoycekung](https://github.com/thejoycekung))
- Max Körbächer ([@mkorbi](https://github.com/mkorbi))
- Nabarun Pal ([@palnabarun](https://github.com/palnabarun))
- Seth McCombs ([@sethmccombs](https://github.com/sethmccombs))
- Taylor Dolezal ([@onlydole](https://github.com/onlydole))
- Verónica López ([@verolop](https://github.com/verolop))
- Wilson Husin ([@wilsonehusin](https://github.com/wilsonehusin))

### Becoming a Release Manager Associate

Contributors can become Associates by demonstrating the following:

- consistent participation, including 6-12 months of active release
engineering-related work
- experience fulfilling a technical lead role on the Release Team during a
release cycle
- this experience provides a solid baseline for understanding how SIG Release
works overall—including our expectations regarding technical skills,
communications/responsiveness, and reliability
- working on k/release items that improve our interactions with Testgrid,
cleaning up libraries, etc.
- these efforts require interacting and pairing with Release Managers and
Associates

## Build Admins

Build Admins are (currently) Google employees with the requisite access to
Google build systems/tooling to publish deb/rpm packages on behalf of the
Kubernetes project. They are responsible for:

- Building, signing, and publishing the deb/rpm packages
- Being the interlock with Release Managers (and Associates) on the final steps
of each minor (1.Y) and patch (1.Y.Z) release

GitHub team: [@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins)

- Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp))
- Amit Watve ([@amwat](https://github.com/amwat))
- Benjamin Elder ([@BenTheElder](https://github.com/BenTheElder))
- Grant McCloskey ([@MushuEE](https://github.com/MushuEE))

## SIG Release Leads

SIG Release Chairs and Technical Leads are responsible for:

- The governance of SIG Release
- Leading knowledge exchange sessions for Release Managers and Associates
- Coaching on leadership and prioritization

They are mentioned explicitly here as they are owners of the various
communications channels and permissions groups (GitHub teams, GCP access) for
each role. As such, they are highly privileged community members and privy to
some private communications, which can at times relate to Kubernetes security
disclosures.

GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/teams/sig-release-leads)

### Chairs

- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert))
- Stephen Augustus ([@justaugustus](https://github.com/justaugustus))

### Technical Leads

- Daniel Mangum ([@hasheddan](https://github.com/hasheddan))
- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard))

---

Past Branch Managers, can be found in the [releases directory][k-sig-release-releases]
of the kubernetes/sig-release repository within `release-x.y/release_team.md`.

Example: [1.15 Release Team](https://git.k8s.io/sig-release/releases/release-1.15/release_team.md)

[community-membership]: https://git.k8s.io/community/community-membership.md#member
[handbook-branch-mgmt]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/branch-manager.md
[handbook-packaging]: https://git.k8s.io/sig-release/release-engineering/packaging.md
[handbook-patch-release]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/patch-release-team.md
[k-sig-release-releases]: https://git.k8s.io/sig-release/releases
[patches]: /patch-releases.md
[psc]: https://git.k8s.io/community/committee-product-security/README.md
[release-team]: https://git.k8s.io/sig-release/release-team/README.md
[security-release-process]: https://git.k8s.io/security/security-release-process.md
Loading