发布经理
“发布经理”是一个统称,涵盖了负责维护发布分支并使用 SIG Release 提供的工具创建版本的 Kubernetes 贡献者。
以下描述了每个角色的职责。
联系方式
邮件列表 | Slack | 可见性 | 用途 | 成员 |
---|---|---|---|---|
[email protected] | #release-management(频道)/ @release-managers(用户组) | 公开 | 发布经理的公开讨论 | 所有发布经理(包括助理和 SIG 主席) |
[email protected] | 不适用 | 私密 | 特权发布经理的私密讨论 | 发布经理、SIG Release 领导层 |
[email protected] | #security-release-team(频道)/ @security-rel-team(用户组) | 私密 | 与安全响应委员会协调安全发布 | [email protected],[email protected] |
安全封锁策略
有关发布的一些信息需要遵守封锁规定,我们已经制定了有关如何设置这些封锁的策略。有关详细信息,请参阅安全封锁策略。
手册
注意:补丁版本团队和分支经理手册将在以后的日期进行重复数据删除。
发布经理
**注意:**文档中可能会提到补丁版本团队和分支管理角色。这两个角色已合并到发布经理角色中。
发布经理和发布经理助理的最低要求是
- 熟悉基本的 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 中的代码
- 通过积极参与 Buddy 计划来支持发布经理助理和贡献者
- 每月与助理核对,委派任务,授权他们发布版本,并进行指导
- 能够在引导新贡献者方面为助理提供支持,例如回答问题并为他们建议适当的工作
该团队有时与安全响应委员会密切合作,因此应遵守安全发布流程中规定的准则。
GitHub 访问控制:@kubernetes/release-managers
GitHub 提及:@kubernetes/release-engineering
- Adolfo García Veytia (@puerco)
- 黄茜茜 (@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 版本
- 寻找机会帮助确定优先级和沟通
- 发送有关补丁版本的预先公告和更新
- 更新日历,帮助确定发布周期时间表中的发布日期和里程碑
- 通过 Buddy 计划,引导新贡献者并与他们在任务上进行配对
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)
技术负责人
过去的版本经理,可以在 kubernetes/sig-release 仓库的releases 目录中的release-x.y/release_team.md
中找到。
例如:1.15 发布团队
上次修改时间:2023 年 10 月 10 日下午 2:43 PST:删除构建管理员的 rapture 引用 (f833be44e4)