原文地址：Google Doc
背景
2017 年 9 月发布 0.2 之后，我们再没有一个稳定的版本了。之前我们认为 0.7 可以作为 LTS 版本，然而他不够成熟，所以我们把希望放在了 0.8 的头上。我们过去计划在 4 月中旬发布 0.8 版本。然而直到今天（4 月 27 日），我们还是有很多的关键 BUG 需要解决，看起来这个月内是无法完成了。
简单说，我们不仅无法发布 LTS 版本，甚至连月度版本都无法按时发布。因此，Istio 项目进入橘色状态（根据 release process 定义）。
根据上面的发布过程定义：Release 的稳定是 Istio 开发者的首要任务，… 可以声明代码冻结，组织 SWAT 团队协助发布过程进入正轨。”。我们需要 TOC 的帮助来实现上述操作。
问题
- 我们不知道我们的无知在哪里。最大最亟待解决的问题就是，我们要需要知道到底要解决什么问题。虽然经过多次沟通，构成发布障碍的 Issue 仍然没有被正确的识别和标记。这个问题在之前的 0.7 发布的时候已经发作过，现在影响到了 0.8。
- 我们没有清楚的人员来定义发布障碍。因此就很难对现状进行评估，解决时间也就无从预测。我们需要给每个条目确定责任人。
- 我们本来想 3 月份发布 LTS 版本，后来延迟到四月中旬，现在，我们计划是五月的某个时间。这成了一个移动目标，并且我们还是没有一个明确的评估。
- 多数团队都准备参加下周的 Kubecon，这很明显会影响生产力。
- 目前为止，还有一些优秀劳动力投放在和发布障碍无关的工作上。
- 计划了对 0.8 RC 的测试工作，但是我们还没有可用的 RC。
- 发布分支访问量很低，有些很明显是 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 |
文章来源于互联网:Istio 0.8：橘色警告
