版本发布经理

“版本发布经理”是一个统称，涵盖了负责维护发布分支并使用 SIG Release 提供的工具创建版本的 Kubernetes 贡献者。

下面描述了每个角色的职责。

• 联系方式
  • 安全禁令策略
• 手册
• 版本发布经理
  • 成为版本发布经理
• 版本发布经理助理
  • 成为版本发布经理助理
• SIG Release 负责人
  • 主席
  • 技术负责人

联系方式

安全禁令策略

一些关于版本的信息需要保密，我们已经制定了关于如何设置这些禁令的策略。请参阅安全禁令策略了解更多信息。

手册

注意：补丁版本团队和分支经理手册将在以后合并。

• 补丁版本团队
• 分支经理

版本发布经理

**注意：**文档中可能会提到补丁版本团队和分支管理角色。这两个角色已合并到版本发布经理角色中。

版本发布经理和版本发布经理助理的最低要求是

• 熟悉基本的 Unix 命令并能够调试 shell 脚本。
• 熟悉通过 `git` 和相关的 `git` 命令行调用进行的分支源代码工作流。
• 掌握 Google Cloud（Cloud Build 和 Cloud Storage）的一般知识。
• 乐于寻求帮助并清晰地沟通。
• Kubernetes 社区成员资格

版本发布经理负责

• 协调和发布 Kubernetes 版本
  • 补丁版本（`x.y.z`，其中 `z` > 0）
  • 次要版本（`x.y.z`，其中 `z` = 0）
  • 预发布版本（alpha、beta 和候选版本）
  • 在每个发布周期中与发布团队合作
  • 设置补丁版本的计划和节奏
• 维护发布分支
  • 审查挑选的提交
  • 确保发布分支保持健康，并且没有意外的补丁被合并
• 指导版本发布经理助理小组
• 积极开发功能并维护 k/release 中的代码
• 通过积极参与伙伴计划来支持版本发布经理助理和贡献者
  • 每月与助理沟通，委派任务，授权他们发布版本并进行指导
  • 随时帮助助理加入新贡献者，例如回答问题并为他们建议合适的工作

该团队有时与安全响应委员会紧密合作，因此应遵守安全发布流程中规定的准则。

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

GitHub 提及：@kubernetes/release-engineering

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

成为版本发布经理

要成为一名版本发布经理，必须首先担任版本发布经理助理。助理通过积极参与多个发布周期并达到以下条件晋升为版本发布经理：

• 展现出领导意愿
• 与版本发布经理合作处理补丁，最终能够独立发布版本
  • 由于发布具有限制性功能，我们也考量对镜像升级和其他核心发布工程任务的重大贡献
• 质疑助理的工作方式，提出改进建议，收集反馈并推动变革
• 可靠且响应迅速
• 倾向于从事需要版本发布经理级别访问权限和特权才能完成的高级工作

版本发布经理助理

版本发布经理助理是版本发布经理的学徒，以前被称为版本发布经理的影子。他们负责

• 补丁版本工作，挑选提交审查
• 贡献 k/release：更新依赖项并熟悉源代码库
• 贡献文档：维护手册，确保发布流程有文档记录
• 在版本发布经理的帮助下：在发布周期中与发布团队合作并发布 Kubernetes 版本
• 寻找机会帮助确定优先级和沟通
  • 发送关于补丁版本的预告和更新
  • 更新日历，根据发布周期时间表确定发布日期和里程碑
• 通过伙伴计划，引导新贡献者并与他们结对完成任务

GitHub 提及： @kubernetes/release-engineering

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

成为版本发布经理助理

贡献者可以通过以下方式成为助理

• 持续参与，包括 6-12 个月的积极发布工程相关工作
• 在发布周期中担任发布团队技术负责人的经验
  • 此经验为了解 SIG Release 的整体运作方式（包括我们对技术技能、沟通/响应能力和可靠性的期望）奠定了坚实的基础
• 处理 k/release 项目，改进我们与 Testgrid 的交互，清理库等
  • 这些工作需要与版本发布经理和助理互动和配对

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)

过去的分支经理，可以在 kubernetes/sig-release 仓库的releases 目录下的 `release-x.y/release_team.md` 文件中找到。

示例：1.15 发布团队