发布管理员
“发布管理员(Release Managers)” 是一个总称,通过使用 SIG Release 提供的工具, 负责维护发布分支、标记发行版本以及创建发行版本的贡献者。
每个角色的职责如下所述。
联系方式
邮件列表 | Slack | 可见范围 | 用法 | 会员资格 |
---|---|---|---|---|
release-managers@kubernetes.io | #release-management(频道)/@release-managers(用户组) | 公共 | 发布管理员公开讨论 | 所有发布管理员(包括助理、构建管理员和 SIG 主席) |
release-managers-private@kubernetes.io | 不适用 | 私人 | 拥有特权的发布管理员私人讨论 | 发布管理员,SIG Release 负责人 |
security-release-team@kubernetes.io | #security-release-team(频道)/@security-rel-team(用户组) | 私人 | 与安全响应委员会协调安全发布 | security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io |
安全禁运政策
发布的相关信息受到禁运,我们已经定义了有关如何设置这些禁运的政策。 更多信息请参考安全禁运政策。
手册
**注意:**补丁发布团队和分支管理员手册以后将会删除重复数据。
发布管理员
注意: 文档可能涉及补丁发布团队和分支管理角色。这两个角色被合并到发布管理员角色中。
发布管理员和发布管理员助理的最低要求是:
- 熟悉基本的 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)
- 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)
- Jeremy Rickard (@jeremyrickard)
- Jim Angel (@jimangel)
- Joseph Sandoval (@jrsapi)
- Joyce Kung (@thejoycekung)
- Max Körbächer (@mkorbi)
- Seth McCombs (@sethmccombs)
- Taylor Dolezal (@onlydole)
- Wilson Husin (@wilsonehusin)
成为发布管理员助理
贡献者可以通过展示以下内容成为助理:
- 持续参与,包括 6-12 个月的发布工程相关的积极工作
- 在发布周期内担任发布团队的技术负责人角色的经验
- 这种经验为理解 SIG Release 如何整体运作提供了坚实的基础——包括我们对技术技能、沟通、响应能力和可靠性的期望
- 致力于改进我们与 Testgrid 交互的 kubernetes/release 项目,清理仓库等。
- 这些工作需要与发布管理员和助理进行互动和合作
构建管理员
构建管理员(目前)是谷歌员工,他们拥有对谷歌构建系统/工具的必要访问权限,可以代表 Kubernetes 项目发布 deb/rpm 包。他们负责:
- 构建、签名和发布 deb/rpm 包
- 在每个次要 (1.Y) 和补丁 (1.Y.Z) 版本的最后步骤中与发布管理员(和助理)互锁
GitHub 团队:@kubernetes/build-admins
- Aaron Crickenberger (@spiffxp)
- Benjamin Elder (@BenTheElder)
- Grant McCloskey (@MushuEE)
- Juan Escobar (@juanfescobar)
SIG Release 负责人
SIG Release 主席和技术负责人负责:
- SIG Release 的治理
- 领导发布管理员和助理的知识交流会议
- 传授领导力和优先排序方法
之所以此处明确提及他们,是因为他们是每个角色的各种沟通渠道和权限组(GitHub 团队、GCP 访问)的所有者。 因此,他们是享有很高特权的社区成员,并参与了一些私人沟通,这些沟通有时可能与 Kubernetes 安全披露有关。
GitHub 团队:@kubernetes/sig-release-leads
主席
- Sascha Grunert (@saschagrunert)
- Stephen Augustus (@justaugustus)
技术负责人
- Adolfo García Veytia (@puerco)
- Carlos Panato (@cpanato)
- Jeremy Rickard (@jeremyrickard)
有关以往的分支管理员,可以在 release-x.y/release_team.md
中 kubernetes/sig-release 仓库的发布目录中找到。
例如:1.15 发布团队