|
| 1 | +--- |
| 2 | +title: 发布管理员 |
| 3 | +type: docs |
| 4 | +--- |
| 5 | +<!-- |
| 6 | +title: Release Managers |
| 7 | +type: docs |
| 8 | +--> |
| 9 | + |
| 10 | +<!-- |
| 11 | +"Release Managers" is an umbrella term that encompasses the set of Kubernetes |
| 12 | +contributors responsible for maintaining release branches, tagging releases, |
| 13 | +and building/packaging Kubernetes. |
| 14 | +
|
| 15 | +The responsibilities of each role are described below. |
| 16 | +--> |
| 17 | +“发布管理员(Release Managers)”是一个总称,包括一批负责维护发布分支、标记发行版本以及构建/打包 |
| 18 | +Kubernetes 的 Kubernetes 贡献者。 |
| 19 | + |
| 20 | +每个角色的职责如下所述。 |
| 21 | + |
| 22 | +<!-- |
| 23 | +- [Contact](#contact) |
| 24 | + - [Security Embargo Policy](#security-embargo-policy) |
| 25 | +- [Handbooks](#handbooks) |
| 26 | +- [Release Managers](#release-managers) |
| 27 | + - [Becoming a Release Manager](#becoming-a-release-manager) |
| 28 | +- [Release Manager Associates](#release-manager-associates) |
| 29 | + - [Becoming a Release Manager Associate](#becoming-a-release-manager-associate) |
| 30 | +- [Build Admins](#build-admins) |
| 31 | +- [SIG Release Leads](#sig-release-leads) |
| 32 | + - [Chairs](#chairs) |
| 33 | + - [Technical Leads](#technical-leads) |
| 34 | +--> |
| 35 | +- [联系方式](#contact) |
| 36 | + - [安全禁运政策](#security-embargo-policy) |
| 37 | +- [手册](#handbooks) |
| 38 | +- [发布管理员](#release-managers) |
| 39 | + - [成为发布管理员](#becoming-a-release-manager) |
| 40 | +- [发布管理员助理](#release-manager-associates) |
| 41 | + - [成为发布管理员助理](#becoming-a-release-manager-associate) |
| 42 | +- [构建管理员](#build-admins) |
| 43 | +- [SIG 发布负责人](#sig-release-leads) |
| 44 | + - [首席](#chairs) |
| 45 | + - [技术负责人](#technical-leads) |
| 46 | + |
| 47 | +<!-- |
| 48 | +## Contact |
| 49 | +
|
| 50 | +| Mailing List | Slack | Visibility | Usage | Membership | |
| 51 | +| --- | --- | --- | --- | --- | |
| 52 | +| [[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) | |
| 53 | +| [[email protected]](mailto:[email protected]) | N/A | Private | Private discussion for privileged Release Managers | Release Managers, SIG Release leadership | |
| 54 | +| [[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 Security Response Committee | [[email protected]](mailto:[email protected]), [[email protected]](mailto:[email protected]) | |
| 55 | +--> |
| 56 | +## 联系方式 #{contact} |
| 57 | + |
| 58 | +| 邮件列表 | Slack | 可见 | 用法 | 会员资格 | |
| 59 | +| --- | --- | --- | --- | --- | |
| 60 | +| [[email protected]](mailto:[email protected]) | [#release-management ](https://kubernetes.slack.com/messages/CJH2GBF7Y)(频道)/ @release-managers(用户组) | 公共 | 发布管理员的公开讨论 | 所有发布管理员(包括助理、构建管理员和 SIG 主席) | |
| 61 | +| [[email protected]](mailto:[email protected]) | 不适用 | 私人 | 拥有特权的发布管理员私人讨论 | 发布管理员,SIG Release 负责人 | |
| 62 | +| [[email protected]](mailto:[email protected]) | [#security-release-team ](https://kubernetes.slack.com/archives/G0162T1RYHG)(频道)/ @security-rel-team(用户组) | 私人 | 与安全响应委员会协调的安全发布 | [[email protected]](mailto:[email protected]), [[email protected]](mailto:[email protected]) | |
| 63 | + |
| 64 | +<!-- |
| 65 | +### Security Embargo Policy |
| 66 | +
|
| 67 | +Some information about releases is subject to embargo and we have defined policy about how those embargoes are set. Please refer to the [Security Embargo Policy](https://github.com/kubernetes/committee-security-response/blob/main/private-distributors-list.md#embargo-policy) for more information. |
| 68 | +--> |
| 69 | +### 安全禁运政策 {#security-embargo-policy} |
| 70 | + |
| 71 | +发布的相关信息受到禁运,我们已经定义了有关如何设置这些禁运的政策。 |
| 72 | +更多信息请参考[安全禁运政策](https://github.com/kubernetes/committee-security-response/blob/main/private-distributors-list.md#embargo-policy)。 |
| 73 | + |
| 74 | +<!-- |
| 75 | +## Handbooks |
| 76 | +
|
| 77 | +**NOTE: The Patch Release Team and Branch Manager handbooks will be de-duplicated at a later date.** |
| 78 | +
|
| 79 | +- [Patch Release Team][handbook-patch-release] |
| 80 | +- [Branch Managers][handbook-branch-mgmt] |
| 81 | +- [Build Admins][handbook-packaging] |
| 82 | +--> |
| 83 | +## 手册 {#handbooks} |
| 84 | + |
| 85 | +**注意:补丁发布团队和分支管理员手册以后将会删除重复数据。** |
| 86 | + |
| 87 | +- [补丁发布团队][handbook-patch-release] |
| 88 | +- [分支管理员][handbook-branch-mgmt] |
| 89 | +- [构建管理员][handbook-packaging] |
| 90 | + |
| 91 | +<!-- |
| 92 | +## Release Managers |
| 93 | +
|
| 94 | +**Note:** The documentation might refer to the Patch Release Team and the |
| 95 | +Branch Management role. Those two roles were consolidated into the |
| 96 | +Release Managers role. |
| 97 | +
|
| 98 | +Minimum requirements for Release Managers and Release Manager Associates are: |
| 99 | +
|
| 100 | +- Familiarity with basic Unix commands and able to debug shell scripts. |
| 101 | +- Familiarity with branched source code workflows via `git` and associated |
| 102 | + `git` command line invocations. |
| 103 | +- General knowledge of Google Cloud (Cloud Build and Cloud Storage). |
| 104 | +- Open to seeking help and communicating clearly. |
| 105 | +- Kubernetes Community [membership][community-membership] |
| 106 | +--> |
| 107 | +## 发布管理员 {#release-managers} |
| 108 | + |
| 109 | +**注意:** 文档可能涉及补丁发布团队和分支管理角色。这两个角色被合并到发布管理员角色中。 |
| 110 | + |
| 111 | +发布管理员和发布管理员助理的最低要求是: |
| 112 | + |
| 113 | +- 熟悉基本的 Unix 命令并能够调试 shell 脚本。 |
| 114 | +- 熟悉通过 `git` 和 `git` 相关的命令行触发的分支源代码工作流。 |
| 115 | +- 谷歌云的常识(云构建和云存储)。 |
| 116 | +- 乐于寻求帮助和清晰地沟通。 |
| 117 | +- Kubernetes 社区 [会员资格][community-membership] |
| 118 | + |
| 119 | +<!-- |
| 120 | +Release Managers are responsible for: |
| 121 | +
|
| 122 | +- Coordinating and cutting Kubernetes releases: |
| 123 | + - Patch releases (`x.y.z`, where `z` > 0) |
| 124 | + - Minor releases (`x.y.z`, where `z` = 0) |
| 125 | + - Pre-releases (alpha, beta, and release candidates) |
| 126 | + - Working with the [Release Team][release-team] through each |
| 127 | + release cycle |
| 128 | + - Setting the [schedule and cadence for patch releases][patches] |
| 129 | +- Maintaining the release branches: |
| 130 | + - Reviewing cherry picks |
| 131 | + - Ensuring the release branch stays healthy and that no unintended patch |
| 132 | + gets merged |
| 133 | +- Mentoring the [Release Manager Associates](#associates) group |
| 134 | +- Actively developing features and maintaining the code in k/release |
| 135 | +- Supporting Release Manager Associates and contributors through actively |
| 136 | + participating in the Buddy program |
| 137 | + - Check in monthly with Associates and delegate tasks, empower them to cut |
| 138 | + releases, and mentor |
| 139 | + - Being available to support Associates in onboarding new contributors e.g., |
| 140 | + answering questions and suggesting appropriate work for them to do |
| 141 | +--> |
| 142 | +发布管理员负责: |
| 143 | + |
| 144 | +- 协调和确定 Kubernetes 发行版本: |
| 145 | + - 补丁发布(`x.y.z`,其中 `z` > 0) |
| 146 | + - 次要版本(`x.y.z`,其中 `z` = 0) |
| 147 | + - 预发布(alpha、beta 和候选发布) |
| 148 | + - 通过每个发布周期与[发布小组][release-team]合作 |
| 149 | + - 设置[补丁发布的时间表和节奏][patches] |
| 150 | +- 维护发布分支: |
| 151 | + - 审查 Cherry Pick |
| 152 | + - 确保发布分支保持健康并且没有合并意外的补丁 |
| 153 | +- 指导[发布管理员助理](#associates)小组 |
| 154 | +- 积极开发功能并维护 k/release 中的代码 |
| 155 | +- 通过积极参与 Buddy 计划来支持发布管理员助理和贡献者 |
| 156 | + - 每月与助理核对并委派任务,授权他们生成发行版本并指导工作 |
| 157 | + - 支持助理小组加入新的贡献者,例如回答问题并建议他们做适当的工作 |
| 158 | + |
| 159 | +<!-- |
| 160 | +This team at times works in close conjunction with the |
| 161 | +[Security Response Committee][src] and therefore should abide by the guidelines |
| 162 | +set forth in the [Security Release Process][security-release-process]. |
| 163 | +
|
| 164 | +GitHub Access Controls: [@kubernetes/release-managers](https://github.com/orgs/kubernetes/teams/release-managers) |
| 165 | +
|
| 166 | +GitHub Mentions: [@kubernetes/release-engineering](https://github.com/orgs/kubernetes/teams/release-engineering) |
| 167 | +--> |
| 168 | +该团队有时与[安全响应委员会][src]密切合作,因此应遵守[安全发布流程][security-release-process]中规定的指导方针。 |
| 169 | + |
| 170 | +GitHub 访问控制:[@kubernetes/release-managers](https://github.com/orgs/kubernetes/teams/release-managers) |
| 171 | + |
| 172 | +GitHub 提及:[@kubernetes/release-engineering](https://github.com/orgs/kubernetes/teams/release-engineering) |
| 173 | + |
| 174 | +- Adolfo García Veytia ([@puerco](https://github.com/puerco)) |
| 175 | +- Carlos Panato ([@cpanato](https://github.com/cpanato)) |
| 176 | +- Marko Mudrinić ([@xmudrii](https://github.com/xmudrii)) |
| 177 | +- Nabarun Pal ([@palnabarun](https://github.com/palnabarun)) |
| 178 | +- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert)) |
| 179 | +- Stephen Augustus ([@justaugustus](https://github.com/justaugustus)) |
| 180 | +- Verónica López ([@verolop](https://github.com/verolop)) |
| 181 | + |
| 182 | +<!-- |
| 183 | +### Becoming a Release Manager |
| 184 | +
|
| 185 | +To become a Release Manager, one must first serve as a Release Manager |
| 186 | +Associate. Associates graduate to Release Manager by actively working on |
| 187 | +releases over several cycles and: |
| 188 | +
|
| 189 | +- demonstrating the willingness to lead |
| 190 | +- tag-teaming with Release Managers on patches, to eventually cut a release |
| 191 | + independently |
| 192 | + - because releases have a limiting function, we also consider substantial |
| 193 | + contributions to image promotion and other core Release Engineering tasks |
| 194 | +- questioning how Associates work, suggesting improvements, gathering feedback, |
| 195 | + and driving change |
| 196 | +- being reliable and responsive |
| 197 | +- leaning into advanced work that requires Release Manager-level access and |
| 198 | + privileges to complete |
| 199 | +--> |
| 200 | +### 成为发布管理员 {#becoming-a-release-manager} |
| 201 | + |
| 202 | +要成为发布管理员,首先必须担任发布管理员助理。助理通过在多个周期内积极处理发布,从而毕业成为发布管理员,并且: |
| 203 | + |
| 204 | +- 表现出带头的意愿 |
| 205 | +- 与发布管理员合作,为补丁打标记,最终独立制作发行版本 |
| 206 | + - 因为发布具有限制功能,我们还考虑对镜像推广和其他核心发布工程任务的实质性贡献 |
| 207 | +- 质疑助理的工作方式、提出改进建议、收集反馈并推动变革 |
| 208 | +- 可靠且反应迅速 |
| 209 | +- 专注于需要发布管理员级别访问和权限才能完成的高级工作 |
| 210 | + |
| 211 | +<!-- |
| 212 | +## Release Manager Associates |
| 213 | +
|
| 214 | +Release Manager Associates are apprentices to the Release Managers, formerly |
| 215 | +referred to as Release Manager shadows. They are responsible for: |
| 216 | +
|
| 217 | +- Patch release work, cherry pick review |
| 218 | +- Contributing to k/release: updating dependencies and getting used to the |
| 219 | + source codebase |
| 220 | +- Contributing to the documentation: maintaining the handbooks, ensuring that |
| 221 | + release processes are documented |
| 222 | +- With help from a release manager: working with the Release Team during the |
| 223 | + release cycle and cutting Kubernetes releases |
| 224 | +- Seeking opportunities to help with prioritization and communication |
| 225 | + - Sending out pre-announcements and updates about patch releases |
| 226 | + - Updating the calendar, helping with the release dates and milestones from |
| 227 | + the [release cycle timeline][k-sig-release-releases] |
| 228 | +- Through the Buddy program, onboarding new contributors and pairing up with |
| 229 | + them on tasks |
| 230 | +
|
| 231 | +GitHub Mentions: @kubernetes/release-engineering |
| 232 | +--> |
| 233 | +## 发布管理员助理 {#release-manager-associates} |
| 234 | + |
| 235 | +发布管理员助理是发布管理员的学徒,以前称为发布管理员影子。他们负责: |
| 236 | + |
| 237 | +- 补丁发布工作,Cherry Pick 审查 |
| 238 | +- 为 k/release 做贡献:更新依赖并习惯源代码库 |
| 239 | +- 为文档做贡献:维护手册,确保发布过程记录在案 |
| 240 | +- 在发布管理员的帮助下:在发布周期中与发布团队合作并减少 Kubernetes 发型版本 |
| 241 | +- 寻求机会帮助确定优先级和沟通 |
| 242 | + - 发送有关补丁发布的预告和更新 |
| 243 | + - 更新日历,帮助确定[发布周期时间线][k-sig-release-releases]中的发布日期和里程碑 |
| 244 | +- 通过 Buddy 计划,加入新的贡献者并与他们合作完成任务 |
| 245 | + |
| 246 | +GitHub 提及:@kubernetes/release-engineering |
| 247 | + |
| 248 | +- Arnaud Meukam ([@ameukam](https://github.com/ameukam)) |
| 249 | +- Jim Angel ([@jimangel](https://github.com/jimangel)) |
| 250 | +- Joyce Kung ([@thejoycekung](https://github.com/thejoycekung)) |
| 251 | +- Max Körbächer ([@mkorbi](https://github.com/mkorbi)) |
| 252 | +- Seth McCombs ([@sethmccombs](https://github.com/sethmccombs)) |
| 253 | +- Taylor Dolezal ([@onlydole](https://github.com/onlydole)) |
| 254 | +- Wilson Husin ([@wilsonehusin](https://github.com/wilsonehusin)) |
| 255 | + |
| 256 | +<!-- |
| 257 | +### Becoming a Release Manager Associate |
| 258 | +
|
| 259 | +Contributors can become Associates by demonstrating the following: |
| 260 | +
|
| 261 | +- consistent participation, including 6-12 months of active release |
| 262 | + engineering-related work |
| 263 | +- experience fulfilling a technical lead role on the Release Team during a |
| 264 | + release cycle |
| 265 | + - this experience provides a solid baseline for understanding how SIG Release |
| 266 | + works overall—including our expectations regarding technical skills, |
| 267 | + communications/responsiveness, and reliability |
| 268 | +- working on k/release items that improve our interactions with Testgrid, |
| 269 | + cleaning up libraries, etc. |
| 270 | + - these efforts require interacting and pairing with Release Managers and |
| 271 | + Associates |
| 272 | +--> |
| 273 | +### 成为发布管理员助理 {#becoming-a-release-manager-associate} |
| 274 | + |
| 275 | +贡献者可以通过展示以下内容成为助理: |
| 276 | + |
| 277 | +- 持续参与,包括 6-12 个月的发布工程相关的积极工作 |
| 278 | +- 在发布周期内担任发布团队的技术负责人角色的经验 |
| 279 | + - 这种经验为理解 SIG Release 如何整体运作提供了坚实的基础——包括我们对技术技能、沟通、响应能力和可靠性的期望 |
| 280 | +- 致力于改进我们与 Testgrid 交互的 k/release 项目,清理仓库等。 |
| 281 | + - 这些工作需要与发布管理员和助理进行互动和合作 |
| 282 | + |
| 283 | +<!-- |
| 284 | +## Build Admins |
| 285 | +
|
| 286 | +Build Admins are (currently) Google employees with the requisite access to |
| 287 | +Google build systems/tooling to publish deb/rpm packages on behalf of the |
| 288 | +Kubernetes project. They are responsible for: |
| 289 | +
|
| 290 | +- Building, signing, and publishing the deb/rpm packages |
| 291 | +- Being the interlock with Release Managers (and Associates) on the final steps |
| 292 | +of each minor (1.Y) and patch (1.Y.Z) release |
| 293 | +
|
| 294 | +GitHub team: [@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins) |
| 295 | +--> |
| 296 | +## 构建管理员 {#build-admins} |
| 297 | + |
| 298 | +构建管理员(目前)是谷歌员工,他们拥有对谷歌构建系统/工具的必要访问权限,可以代表 Kubernetes 项目发布 deb/rpm 包。他们负责: |
| 299 | + |
| 300 | +- 构建、签名和发布 deb/rpm 包 |
| 301 | +- 在每个次要 (1.Y) 和补丁 (1.Y.Z) 版本的最后步骤中与发布管理员(和助理)互锁 |
| 302 | + |
| 303 | +GitHub 团队:[@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins) |
| 304 | + |
| 305 | +- Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp)) |
| 306 | +- Benjamin Elder ([@BenTheElder](https://github.com/BenTheElder)) |
| 307 | +- Grant McCloskey ([@MushuEE](https://github.com/MushuEE)) |
| 308 | +- Juan Escobar ([@juanfescobar](https://github.com/juanfescobar)) |
| 309 | + |
| 310 | +<!-- |
| 311 | +## SIG Release Leads |
| 312 | +
|
| 313 | +SIG Release Chairs and Technical Leads are responsible for: |
| 314 | +
|
| 315 | +- The governance of SIG Release |
| 316 | +- Leading knowledge exchange sessions for Release Managers and Associates |
| 317 | +- Coaching on leadership and prioritization |
| 318 | +
|
| 319 | +They are mentioned explicitly here as they are owners of the various |
| 320 | +communications channels and permissions groups (GitHub teams, GCP access) for |
| 321 | +each role. As such, they are highly privileged community members and privy to |
| 322 | +some private communications, which can at times relate to Kubernetes security |
| 323 | +disclosures. |
| 324 | +
|
| 325 | +GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/teams/sig-release-leads) |
| 326 | +--> |
| 327 | +## SIG Release 负责人 {#sig-release-leads} |
| 328 | + |
| 329 | +SIG Release 主席和技术负责人负责: |
| 330 | + |
| 331 | +- SIG Release 的治理 |
| 332 | +- 领导发布管理员和助理的知识交流会议 |
| 333 | +- 传授领导力和优先排序方法 |
| 334 | + |
| 335 | +此处明确提及他们,因为他们是每个角色的各种沟通渠道和权限组(GitHub 团队、GCP 访问)的所有者。 |
| 336 | +因此,他们是享有很高特权的社区成员,并参与了一些私人沟通,这些沟通有时可能与 Kubernetes 安全披露有关。 |
| 337 | + |
| 338 | +GitHub 团队:[@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/teams/sig-release-leads) |
| 339 | + |
| 340 | +<!-- |
| 341 | +### Chairs |
| 342 | +--> |
| 343 | +### 主席 {#chairs} |
| 344 | + |
| 345 | +- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert)) |
| 346 | +- Stephen Augustus ([@justaugustus](https://github.com/justaugustus)) |
| 347 | + |
| 348 | +<!-- |
| 349 | +### Technical Leads |
| 350 | +--> |
| 351 | +### 技术负责人 {#technical-leads} |
| 352 | + |
| 353 | +- Adolfo García Veytia ([@puerco](https://github.com/puerco)) |
| 354 | +- Carlos Panato ([@cpanato](https://github.com/cpanato)) |
| 355 | +- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard)) |
| 356 | + |
| 357 | +--- |
| 358 | + |
| 359 | +<!-- |
| 360 | +Past Branch Managers, can be found in the [releases directory][k-sig-release-releases] |
| 361 | +of the kubernetes/sig-release repository within `release-x.y/release_team.md`. |
| 362 | +
|
| 363 | +Example: [1.15 Release Team](https://git.k8s.io/sig-release/releases/release-1.15/release_team.md) |
| 364 | +--> |
| 365 | +过去的分支管理员,可以在 `release-x.y/release_team.md` |
| 366 | +中 kubernetes/sig-release 仓库的[发布目录][k-sig-release-releases]中找到。 |
| 367 | + |
| 368 | +例如:[1.15 发布团队](https://git.k8s.io/sig-release/releases/release-1.15/release_team.md) |
| 369 | + |
| 370 | +[community-membership]: https://git.k8s.io/community/community-membership.md#member |
| 371 | +[handbook-branch-mgmt]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/branch-manager.md |
| 372 | +[handbook-packaging]: https://git.k8s.io/sig-release/release-engineering/packaging.md |
| 373 | +[handbook-patch-release]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/patch-release-team.md |
| 374 | +[k-sig-release-releases]: https://git.k8s.io/sig-release/releases |
| 375 | +[patches]: /patch-releases.md |
| 376 | +[src]: https://git.k8s.io/community/committee-security-response/README.md |
| 377 | +[release-team]: https://git.k8s.io/sig-release/release-team/README.md |
| 378 | +[security-release-process]: https://git.k8s.io/security/security-release-process.md |
0 commit comments