Istio 0.8:橘色警告
原文地址: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 |