版本经理

“版本经理”是一个总括性术语，涵盖了负责维护发布分支并使用 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 和候选发布版本）
  • 在每个发布周期内与 版本团队 合作
  • 设定 补丁版本的发布时间和节奏
• 维护发布分支
  • 审查 cherry pick
  • 确保发布分支保持健康，并且没有意外的补丁被合并。
• 指导 版本经理助理 组
• 积极开发 k/release 中的功能和维护代码
• 通过积极参与 Buddy program 支持版本经理助理和贡献者
  • 每月与助理们沟通并委派任务，授权他们进行发布，并进行指导。
  • 随时准备支持助理们引导新贡献者，例如，回答问题并建议适合他们的工作。

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

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)

如何成为版本经理

要成为版本经理，必须首先担任版本经理助理。助理通过在多个发布周期中积极参与发布工作来晋升为版本经理，并

• 展示领导意愿
• 与版本经理协作处理补丁，最终能够独立发布版本
  • 由于发布工作具有限制性，我们还会考虑在镜像推广和其他核心发布工程任务方面的重大贡献
• 质疑助理们的工作方式，提出改进建议，收集反馈，并推动变革
• 可靠且响应迅速
• 主动承担需要版本经理级别访问权限和特权的进阶工作

版本经理助理

版本经理助理是版本经理的学徒，之前被称为版本经理影子 (shadows)。他们负责

• 补丁发布工作，cherry pick 审查
• 为 k/release 做贡献：更新依赖并熟悉源代码库
• 为文档做贡献：维护手册，确保发布流程有文档记录
• 在版本经理的帮助下：在发布周期内与 Release Team 合作并发布 Kubernetes 版本
• 寻找机会协助优先级排序和沟通
  • 发送补丁版本的预告和更新
  • 更新日历，协助处理 发布周期时间表 中的发布日期和里程碑
• 通过 Buddy program，引导新贡献者并与他们在任务上结对合作

GitHub 提及：@kubernetes/release-engineering

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

如何成为版本经理助理

贡献者可以通过展示以下几点来成为助理：

• 持续参与，包括 6-12 个月积极的发布工程相关工作
• 在一个发布周期内担任 Release Team 技术负责人的经验
  • 这些经验为理解 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 Release Team