为什么我们在 OpenStack 中进行功能冻结

几周前，我们进入了 Icehouse 开发周期 功能冻结期。但随着 OpenStack 开发社区的惊人增长（过去 30 天内有 508 位不同的贡献者，其中包括 101 位新贡献者！），我听到了很多关于它的问题。我过去曾在各种论坛上解释过，但我想写一些更明确的东西也无妨。

为什么要冻结功能？

这些都是合理的问题。为什么要冻结功能？这听起来非常反敏捷。难道我们以测试为中心的开发模型不应该保护我们免受回归的影响吗？让我们从功能冻结不是什么开始说起。功能冻结应该只影响集成的 OpenStack 版本。如果你不发布（即，如果你不在开发中的某些时刻进行特殊处理），那么功能冻结就没什么意义。它也不是惩罚那些未能赶上截止日期的人的一种方式。某个功能会错过截止日期有很多原因，而其中大多数原因都不是该功能的原始作者的错。我们进行基于时间的发布，因此某些功能和某些开发人员必然会在某个时候被挡在栅栏的错误一侧，需要等待下一班船。这是开放创新项目的产物。

功能冻结（也称为“FF”）显然是关于停止添加新功能。你可能会认为这人为地阻止了你的进度，但这会对其他人产生不同的影响

• 正如 Icehouse 周期所证明的那样，优秀的代码审查员是一种稀缺资源。功能冻结的第一个效果是，它限制了代码审查的数量，并使所有审查都围绕错误修复展开。这让审查员可以专注于在“发布”之前尽可能多地进行错误修复。它还有助于开发人员花时间进行错误修复。只要他们可以开发功能，他们的自然倾向（或雇主的要求）可能会与项目在这个周期中的利益相冲突，即在我们称为“发布”的那个时间点尽可能减少错误。

• 从 QA 的角度来看，停止添加功能意味着你可以花费有用的时间在“现实生活中”测试 OpenStack 的行为。我们的自动化测试只能捕获这么多。而且，花费时间测试在你面前不断变化的软件是非常令人沮丧的。

• QA 不是唯一需要赶上的团队。对于文档团队、I18N 团队来说，功能冻结至关重要。如果你不知道最终产品中会包含什么，就很难编写文档。翻译第二天就被删除或更改的字符串令人沮丧。

• 然后，你有所有发布的下游消费者，他们可以利用时间来准备发布。打包人员需要不会不断变化和添加依赖项的软件，以便他们可以为尽可能接近我们发布日期的 OpenStack 项目准备软件包。市场营销团队需要时间来研究周期内产生的内容，并将其安排在关键信息中，以便在发布时与外界沟通。

• 最后，对于发布管理而言，功能冻结是降低风险的工具。最终目标是避免在发布前引入令人尴尬的回归。通过逐步限制我们接受到发布分支中的内容的影响（使用功能冻结，但也使用接下来要进行的 RC 舞步），我们尽最大努力防止这种情况发生。

功能冻结的例外情况

对于所有这些团队来说，至关重要的是，我们要尽早停止添加功能、更改行为、添加新的配置选项或更改可翻译的字符串。当然，这是一种权衡。可能有些事情对于发布的成功至关重要，或者有些事情的风险显然是有限的。这就是我们设立例外流程的原因：功能冻结例外（“FFE”）。

功能冻结例外可以由 PTL 批准（并获得发布管理团队友好但有力的建议）。其想法是权衡将该功能纳入发布版本的原始好处，以及所引入代码的复杂性、其导致回归的风险以及我们已经深入功能冻结的程度。一个自包含的更改，在功能冻结后几天即可准备好合并，比关键层的重构更有可能获得例外，而关键层的重构仍然需要一些重要的工作才能完成。这也取决于该项目已经批准了多少例外，因为在某个时候添加任何更多内容只会造成太大的破坏。

这是一个艰难的决定，发布管理团队在这里帮助 PTL 做出决定。如果你的功能被拒绝，请不要放在心上。正如你所看到的，其中涉及大量因素。我们的共同目标是提高最终发布的质量，而我们批准的每一个功能冻结例外都是远离这个目标的一步。我们不能后退太多步，仍然保证我们能赢得比赛。

最初发布于 Seeing the fnords。经与作者协商，以 Creative Commons 许可重新发布。