发布管理员

“发布管理员（Release Managers）” 是一个总称，通过使用 SIG Release 提供的工具， 负责维护发布分支、标记发行版本以及创建发行版本的贡献者。

每个角色的职责如下所述。

• 联系方式
  • 安全禁运政策
• 手册
• 发布管理员
  • 成为发布管理员
• 发布管理员助理
  • 成为发布管理员助理
• 构建管理员
• SIG 发布负责人
  • 首席
  • 技术负责人

联系方式

安全禁运政策

发布的相关信息受到禁运，我们已经定义了有关如何设置这些禁运的政策。 更多信息请参考安全禁运政策。

手册

注意：补丁发布团队和分支管理员手册以后将会删除重复数据。

• 补丁发布团队
• 分支管理员
• 构建管理员

发布管理员

注意： 文档可能涉及补丁发布团队和分支管理角色。这两个角色被合并到发布管理员角色中。

发布管理员和发布管理员助理的最低要求是：

• 熟悉基本的 Unix 命令并能够调试 shell 脚本。
• 熟悉通过 git 和 git 相关命令行触发的分支源代码工作流。
• 谷歌云的常识（云构建和云存储）。
• 乐于寻求帮助和清晰地沟通。
• Kubernetes 社区会员资格

发布管理员负责：

• 协调和确定 Kubernetes 发行版本：
  • 补丁发布（x.y.z，其中 z > 0）
  • 次要版本（x.y.z，其中 z = 0）
  • 预发布（alpha、beta 和候选发布）
  • 通过每个发布周期与发布团队合作
  • 设置补丁发布的时间表和节奏
• 维护发布分支：
  • 审查 Cherry Pick
  • 确保发布分支保持健康并且没有合并意外的补丁
• 指导发布管理员助理小组
• 积极开发功能并维护 kubernetes/release 中的代码
• 通过积极参与 Buddy 计划来支持发布管理员助理和贡献者
  • 每月与助理核对并委派任务，授权他们生成发行版本并指导工作
  • 支持助理小组加入新的贡献者，例如回答问题并建议他们做适当的工作

该团队有时与安全响应委员会密切合作，因此应遵守安全发布流程中规定的指导方针。

GitHub 访问控制：@kubernetes/release-managers

GitHub 提及：@kubernetes/release-engineering

• Adolfo García Veytia (@puerco)
• Carlos Panato (@cpanato)
• Jeremy Rickard (@jeremyrickard)
• Marko Mudrinić (@xmudrii)
• Nabarun Pal (@palnabarun)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)
• Verónica López (@verolop)

成为发布管理员

要成为发布管理员，须先担任发布管理员助理。助理通过在多个周期内积极处理发布，从而毕业成为发布管理员，并且：

• 表现出带头的意愿
• 与发布管理员合作，为补丁打标记，最终独立制作发行版本
  • 因为发布具有限制功能，我们还考虑对镜像推广和其他核心发布工程任务的实质性贡献
• 质疑助理的工作方式、提出改进建议、收集反馈并推动变革
• 可靠且反应迅速
• 专注于需要发布管理员级别访问和权限才能完成的高级工作

发布管理员助理

发布管理员助理是发布管理员的学徒，以前称为发布管理员影子。他们负责：

• 补丁发布工作，Cherry Pick 审查
• 为 kubernetes/release 做贡献：更新依赖并习惯源代码库
• 为文档做贡献：维护手册，确保发布过程记录在案
• 在发布管理员的帮助下：在发布周期中与发布团队合作并减少 Kubernetes 发型版本
• 寻求机会帮助确定优先级和沟通
  • 发送有关补丁发布的预告和更新
  • 更新日历，帮助确定发布周期时间线中的发布日期和里程碑
• 通过 Buddy 计划，加入新的贡献者并与他们合作完成任务

GitHub 提及：@kubernetes/release-engineering

• Arnaud Meukam (@ameukam)
• Cici Huang (@cici37)
• Jim Angel (@jimangel)
• Joseph Sandoval (@jrsapi)
• Xander Grzywinski(@salaxander)

成为发布管理员助理

贡献者可以通过展示以下内容成为助理：

• 持续参与，包括 6-12 个月的发布工程相关的积极工作
• 在发布周期内担任发布团队的技术负责人角色的经验
  • 这种经验为理解 SIG Release 如何整体运作提供了坚实的基础——包括我们对技术技能、沟通、响应能力和可靠性的期望
• 致力于改进我们与 Testgrid 交互的 kubernetes/release 项目，清理仓库等。
  • 这些工作需要与发布管理员和助理进行互动和合作

构建管理员

构建管理员（目前）是谷歌员工，他们拥有对谷歌构建系统/工具的必要访问权限，可以代表 Kubernetes 项目发布 deb/rpm 包。他们负责：

• 构建、签名和发布 deb/rpm 包
• 在每个次要 (1.Y) 和补丁 (1.Y.Z) 版本的最后步骤中与发布管理员（和助理）互锁

GitHub 团队：@kubernetes/build-admins

• Aaron Crickenberger (@spiffxp)
• Ben Kazemi (@BenjaminKazemi)
• Grant McCloskey (@MushuEE)

SIG Release 负责人

SIG Release 主席和技术负责人负责：

• SIG Release 的治理
• 领导发布管理员和助理的知识交流会议
• 传授领导力和优先排序方法

之所以此处明确提及他们，是因为他们是每个角色的各种沟通渠道和权限组（GitHub 团队、GCP 访问）的所有者。 因此，他们是享有很高特权的社区成员，并参与了一些私人沟通，这些沟通有时可能与 Kubernetes 安全披露有关。

GitHub 团队：@kubernetes/sig-release-leads

主席

• Jeremy Rickard (@jeremyrickard)
• Sascha Grunert (@saschagrunert)
• Stephen Augustus (@justaugustus)

技术负责人

• Adolfo García Veytia (@puerco)
• Carlos Panato (@cpanato)
• Verónica López (@verolop)

有关以往的分支管理员，可以在 release-x.y/release_team.md 中 kubernetes/sig-release 仓库的发布目录中找到。

例如：1.15 发布团队