（译）Istio 的橘色警告

Posted 2021-04-13 伪架构师

背景

2017 年 9 月发布 0.2 之后，我们再没有一个稳定的版本了。之前我们认为 0.7 可以作为 LTS 版本，然而他不够成熟，所以我们把希望放在了 0.8 的头上。我们过去计划在 4 月中旬发布 0.8 版本。然而直到今天（4 月 27 日），我们还是有很多的关键 BUG 需要解决，看起来这个月内是无法完成了。

简单说，我们不仅无法发布 LTS 版本，甚至连月度版本都无法按时发布。因此，Istio 项目进入橘色状态（根据 release process 定义）。

根据上面的发布过程定义：Release 的稳定是 Istio 开发者的首要任务，… 可以声明代码冻结，组织 SWAT 团队协助发布过程进入正轨。”。我们需要 TOC 的帮助来实现上述操作。

问题

1. 我们不知道我们的无知在哪里。最大最亟待解决的问题就是，我们要需要知道到底要解决什么问题。虽然经过多次沟通，构成发布障碍的 Issue 仍然没有被正确的识别和标记。这个问题在之前的 0.7 发布的时候已经发作过，现在影响到了 0.8。

2. 我们没有清楚的人员来定义发布障碍。因此就很难对现状进行评估，解决时间也就无从预测。我们需要给每个条目确定责任人。

3. 我们本来想 3 月份发布 LTS 版本，后来延迟到四月中旬，现在，我们计划是五月的某个时间。这成了一个移动目标，并且我们还是没有一个明确的评估。

• 多数团队都准备参加下周的 Kubecon，这很明显会影响生产力。

• 目前为止，还有一些优秀劳动力投放在和发布障碍无关的工作上。

• 计划了对 0.8 RC 的测试工作，但是我们还没有可用的 RC。

4. 发布分支访问量很低，有些很明显是 0.8 相关的内容，只被合并到了 Master 分支。

计划

Action Items	Owner	状态
联系所有工作组长，确认全部的 0.8 障碍被正确的识别、标记、跟踪和分配	Andy 和各组长	邮件已经发送
短期锁定 Master 分支，确认多数开发者都能正确的向 Release 分支合并，只有 TOC 成员批准才允许向 Master 进行合并	Shriram	Done
比对 0.8 和 Master，如果多数变更是针对 0.8 的，那么就撤回 1.0 的专属 PR，然后从 master rebase 或者 rebranch 0.8	Sven、Andy 和 Costin	Done: Rebase 所有发布分支。
所有障碍问题的责任人需要尽快解决手上的问题	Issue owners
计划一个 30 分钟以内的日常站会，来跟踪障碍问题的进度，以此计划发布日期。 1. 从 4 月 30 日起，到 0.8.0 发布为止。 2. 所有未解决问题的责任人必须提供更新信息。如果任何 issue 有产生障碍的可能，Andy 和 Jasmine 有权增加开发者进行协助，以加快进度。所有其他工作的优先级都需要降低，直到橘色警告解除	每周一三五 11 点的会议
Istio oncall 监视发布分支的状态，并且修复和分析可能解决的任何问题，发布分支的问题是最高优先的问题，一旦发现发布障碍，必须加入 0.8 障碍 Issue 列表。	Oncall
一旦有 RC 可用（例如第一阶段的问题已解决之后发布的下一个 Build），应该尽快启动社区测试。一旦发现发布障碍，应该加入 0.8 障碍 Issue 列表	Jasmine
0.8 稳定之后，把所有 Commit 合并回 Master	Andy
和所有开发者沟通这一计划	Sven	Done
0.8 发布之后，启动一个事后会，来改进未来的发布过程。	Andy, Jasmine, TOC