|
| 1 | +--- |
| 2 | +title: Release Managers |
| 3 | +type: docs |
| 4 | +--- |
| 5 | + |
| 6 | +"Release Managers" is an umbrella term that encompasses the set of Kubernetes |
| 7 | +contributors responsible for maintaining release branches, tagging releases, |
| 8 | +and building/packaging Kubernetes. |
| 9 | + |
| 10 | +The responsibilities of each role are described below. |
| 11 | + |
| 12 | +- [Contact](#contact) |
| 13 | +- [Handbooks](#handbooks) |
| 14 | +- [Release Managers](#release-managers) |
| 15 | + - [Becoming a Release Manager](#becoming-a-release-manager) |
| 16 | +- [Release Manager Associates](#release-manager-associates) |
| 17 | + - [Becoming a Release Manager Associate](#becoming-a-release-manager-associate) |
| 18 | +- [Build Admins](#build-admins) |
| 19 | +- [SIG Release Leads](#sig-release-leads) |
| 20 | + - [Chairs](#chairs) |
| 21 | + - [Technical Leads](#technical-leads) |
| 22 | + |
| 23 | +## Contact |
| 24 | + |
| 25 | +| Mailing List | Slack | Visibility | Usage | Membership | |
| 26 | +| --- | --- | --- | --- | --- | |
| 27 | +| [[email protected]](mailto:[email protected]) | [#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) | |
| 28 | +| [[email protected]](mailto:[email protected]) | N/A | Private | Private discussion for privileged Release Managers | Release Managers, SIG Release leadership | |
| 29 | +| [[email protected]](mailto:[email protected]) | [#security-release-team ](https://kubernetes.slack.com/archives/G0162T1RYHG) (channel) / @security-rel-team (user group) | Private | Security release coordination with the Product Security Committee | [[email protected]](mailto:[email protected]), [[email protected]](mailto:[email protected]) | |
| 30 | + |
| 31 | +## Handbooks |
| 32 | + |
| 33 | +**NOTE: The Patch Release Team and Branch Manager handbooks will be de-duplicated at a later date.** |
| 34 | + |
| 35 | +- [Patch Release Team][handbook-patch-release] |
| 36 | +- [Branch Managers][handbook-branch-mgmt] |
| 37 | +- [Build Admins][handbook-packaging] |
| 38 | + |
| 39 | +## Release Managers |
| 40 | + |
| 41 | +**Note:** The documentation might refer to the Patch Release Team and the |
| 42 | +Branch Management role. Those two roles were consolidated into the |
| 43 | +Release Managers role. |
| 44 | + |
| 45 | +Minimum requirements for Release Managers and Release Manager Associates are: |
| 46 | + |
| 47 | +- Familiarity with basic Unix commands and able to debug shell scripts. |
| 48 | +- Familiarity with branched source code workflows via `git` and associated |
| 49 | + `git` command line invocations. |
| 50 | +- General knowledge of Google Cloud (Cloud Build and Cloud Storage). |
| 51 | +- Open to seeking help and communicating clearly. |
| 52 | +- Kubernetes Community [membership][community-membership] |
| 53 | + |
| 54 | +Release Managers are responsible for: |
| 55 | + |
| 56 | +- Coordinating and cutting Kubernetes releases: |
| 57 | + - Patch releases (`x.y.z`, where `z` > 0) |
| 58 | + - Minor releases (`x.y.z`, where `z` = 0) |
| 59 | + - Pre-releases (alpha, beta, and release candidates) |
| 60 | + - Working with the [Release Team][release-team] through each |
| 61 | + release cycle |
| 62 | + - Setting the [schedule and cadence for patch releases][patches] |
| 63 | +- Maintaining the release branches: |
| 64 | + - Reviewing cherry picks |
| 65 | + - Ensuring the release branch stays healthy and that no unintended patch |
| 66 | + gets merged |
| 67 | +- Mentoring the [Release Manager Associates](#associates) group |
| 68 | +- Actively developing features and maintaining the code in k/release |
| 69 | +- Supporting Release Manager Associates and contributors through actively |
| 70 | + participating in the Buddy program |
| 71 | + - Check in monthly with Associates and delegate tasks, empower them to cut |
| 72 | + releases, and mentor |
| 73 | + - Being available to support Associates in onboarding new contributors e.g., |
| 74 | + answering questions and suggesting appropriate work for them to do |
| 75 | + |
| 76 | +This team at times works in close conjunction with the |
| 77 | +[Product Security Committee][psc] and therefore should abide by the guidelines |
| 78 | +set forth in the [Security Release Process][security-release-process]. |
| 79 | + |
| 80 | +GitHub Access Controls: [@kubernetes/release-managers](https://github.com/orgs/kubernetes/teams/release-managers) |
| 81 | + |
| 82 | +GitHub Mentions: [@kubernetes/release-engineering](https://github.com/orgs/kubernetes/teams/release-engineering) |
| 83 | + |
| 84 | +- Adolfo García Veytia ([@puerco](https://github.com/puerco)) |
| 85 | +- Carlos Panato ([@cpanato](https://github.com/cpanato)) |
| 86 | +- Daniel Mangum ([@hasheddan](https://github.com/hasheddan)) |
| 87 | +- Marko Mudrinić ([@xmudrii](https://github.com/xmudrii)) |
| 88 | +- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert)) |
| 89 | +- Stephen Augustus ([@justaugustus](https://github.com/justaugustus)) |
| 90 | + |
| 91 | +### Becoming a Release Manager |
| 92 | + |
| 93 | +To become a Release Manager, one must first serve as a Release Manager |
| 94 | +Associate. Associates graduate to Release Manager by actively working on |
| 95 | +releases over several cycles and: |
| 96 | + |
| 97 | +- demonstrating the willingness to lead |
| 98 | +- tag-teaming with Release Managers on patches, to eventually cut a release |
| 99 | + independently |
| 100 | + - because releases have a limiting function, we also consider substantial |
| 101 | + contributions to image promotion and other core Release Engineering tasks |
| 102 | +- questioning how Associates work, suggesting improvements, gathering feedback, |
| 103 | + and driving change |
| 104 | +- being reliable and responsive |
| 105 | +- leaning into advanced work that requires Release Manager-level access and |
| 106 | + privileges to complete |
| 107 | + |
| 108 | +## Release Manager Associates |
| 109 | + |
| 110 | +Release Manager Associates are apprentices to the Release Managers, formerly |
| 111 | +referred to as Release Manager shadows. They are responsible for: |
| 112 | + |
| 113 | +- Patch release work, cherry pick review |
| 114 | +- Contributing to k/release: updating dependencies and getting used to the |
| 115 | + source codebase |
| 116 | +- Contributing to the documentation: maintaining the handbooks, ensuring that |
| 117 | + release processes are documented |
| 118 | +- With help from a release manager: working with the Release Team during the |
| 119 | + release cycle and cutting Kubernetes releases |
| 120 | +- Seeking opportunities to help with prioritization and communication |
| 121 | + - Sending out pre-announcements and updates about patch releases |
| 122 | + - Updating the calendar, helping with the release dates and milestones from |
| 123 | + the [release cycle timeline][k-sig-release-releases] |
| 124 | +- Through the Buddy program, onboarding new contributors and pairing up with |
| 125 | + them on tasks |
| 126 | + |
| 127 | +GitHub Mentions: @kubernetes/release-engineering |
| 128 | + |
| 129 | +- Arnaud Meukam ([@ameukam](https://github.com/ameukam)) |
| 130 | +- Jim Angel ([@jimangel](https://github.com/jimangel)) |
| 131 | +- Joyce Kung ([@thejoycekung](https://github.com/thejoycekung)) |
| 132 | +- Max Körbächer ([@mkorbi](https://github.com/mkorbi)) |
| 133 | +- Nabarun Pal ([@palnabarun](https://github.com/palnabarun)) |
| 134 | +- Seth McCombs ([@sethmccombs](https://github.com/sethmccombs)) |
| 135 | +- Taylor Dolezal ([@onlydole](https://github.com/onlydole)) |
| 136 | +- Verónica López ([@verolop](https://github.com/verolop)) |
| 137 | +- Wilson Husin ([@wilsonehusin](https://github.com/wilsonehusin)) |
| 138 | + |
| 139 | +### Becoming a Release Manager Associate |
| 140 | + |
| 141 | +Contributors can become Associates by demonstrating the following: |
| 142 | + |
| 143 | +- consistent participation, including 6-12 months of active release |
| 144 | + engineering-related work |
| 145 | +- experience fulfilling a technical lead role on the Release Team during a |
| 146 | + release cycle |
| 147 | + - this experience provides a solid baseline for understanding how SIG Release |
| 148 | + works overall—including our expectations regarding technical skills, |
| 149 | + communications/responsiveness, and reliability |
| 150 | +- working on k/release items that improve our interactions with Testgrid, |
| 151 | + cleaning up libraries, etc. |
| 152 | + - these efforts require interacting and pairing with Release Managers and |
| 153 | + Associates |
| 154 | + |
| 155 | +## Build Admins |
| 156 | + |
| 157 | +Build Admins are (currently) Google employees with the requisite access to |
| 158 | +Google build systems/tooling to publish deb/rpm packages on behalf of the |
| 159 | +Kubernetes project. They are responsible for: |
| 160 | + |
| 161 | +- Building, signing, and publishing the deb/rpm packages |
| 162 | +- Being the interlock with Release Managers (and Associates) on the final steps |
| 163 | +of each minor (1.Y) and patch (1.Y.Z) release |
| 164 | + |
| 165 | +GitHub team: [@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins) |
| 166 | + |
| 167 | +- Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp)) |
| 168 | +- Amit Watve ([@amwat](https://github.com/amwat)) |
| 169 | +- Benjamin Elder ([@BenTheElder](https://github.com/BenTheElder)) |
| 170 | +- Grant McCloskey ([@MushuEE](https://github.com/MushuEE)) |
| 171 | + |
| 172 | +## SIG Release Leads |
| 173 | + |
| 174 | +SIG Release Chairs and Technical Leads are responsible for: |
| 175 | + |
| 176 | +- The governance of SIG Release |
| 177 | +- Leading knowledge exchange sessions for Release Managers and Associates |
| 178 | +- Coaching on leadership and prioritization |
| 179 | + |
| 180 | +They are mentioned explicitly here as they are owners of the various |
| 181 | +communications channels and permissions groups (GitHub teams, GCP access) for |
| 182 | +each role. As such, they are highly privileged community members and privy to |
| 183 | +some private communications, which can at times relate to Kubernetes security |
| 184 | +disclosures. |
| 185 | + |
| 186 | +GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/teams/sig-release-leads) |
| 187 | + |
| 188 | +### Chairs |
| 189 | + |
| 190 | +- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert)) |
| 191 | +- Stephen Augustus ([@justaugustus](https://github.com/justaugustus)) |
| 192 | + |
| 193 | +### Technical Leads |
| 194 | + |
| 195 | +- Daniel Mangum ([@hasheddan](https://github.com/hasheddan)) |
| 196 | +- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard)) |
| 197 | + |
| 198 | +--- |
| 199 | + |
| 200 | +Past Branch Managers, can be found in the [releases directory][k-sig-release-releases] |
| 201 | +of the kubernetes/sig-release repository within `release-x.y/release_team.md`. |
| 202 | + |
| 203 | +Example: [1.15 Release Team](https://git.k8s.io/sig-release/releases/release-1.15/release_team.md) |
| 204 | + |
| 205 | +[community-membership]: https://git.k8s.io/community/community-membership.md#member |
| 206 | +[handbook-branch-mgmt]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/branch-manager.md |
| 207 | +[handbook-packaging]: https://git.k8s.io/sig-release/release-engineering/packaging.md |
| 208 | +[handbook-patch-release]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/patch-release-team.md |
| 209 | +[k-sig-release-releases]: https://git.k8s.io/sig-release/releases |
| 210 | +[patches]: /patch-releases.md |
| 211 | +[psc]: https://git.k8s.io/community/committee-product-security/README.md |
| 212 | +[release-team]: https://git.k8s.io/sig-release/release-team/README.md |
| 213 | +[security-release-process]: https://git.k8s.io/security/security-release-process.md |
0 commit comments