openstack 功能_为什么我们在OpenStack中冻结功能

openstack 功能

几周前，我们进入了Icehouse开发周期冻结功能。但是随着OpenStack开发社区的惊人增长（过去30天内有508个不同的参与者，包括101个新的参与者！），我听到了很多有关它的问题。过去，我已经在各种论坛上对此进行了解释，但是我认为编写一些更具权威性的内容并没有什么坏处。

为什么要冻结功能？

这些是有效的问题。为什么要冻结功能？听起来很敏捷。难道我们的以测试为中心的开发模型不应该保护我们免受回归吗？让我们从冻结什么还没有开始。功能冻结应该只影响集成的OpenStack版本。如果您不发布（即，如果您不对开发中的某些特定时刻进行特殊处理），那么冻结功能就毫无意义。这也不是惩罚未能按时完成任务的人的方法。给定功能部件将错过最后期限的原因有多种，其中大多数不是该功能部件的原始作者的错。我们进行基于时间的发布，因此某些功能和某些开发人员在某些时候必然会陷入困境，并需要等待下一次发布。这是开放式创新项目的产物。

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

正如Icehouse周期所证明的那样，优秀的代码审阅者是稀缺资源。功能冻结的第一个效果是它限制了代码审阅的数量，并使它们全部与错误修正有关。这使审阅者可以集中精力在“发行”之前获得尽可能多的错误修正。它还可以帮助开发人员将时间花费在错误修正上。只要他们可以使用功能，他们的自然倾向（或他们的雇主订单）就可能在周期中的这个时候与项目利益发生冲突，这就是说，我们称“发布”为无错误，因为可能。

从质量检查的角度来看，停止添加功能意味着您可以花费宝贵的时间“实时”测试OpenStack的行为。我们的自动化测试只有这么多内容。花时间测试不断变化的软件非常令人沮丧。

质量检查不是唯一需要跟进的小组。对于I18N团队的文档团队来说，冻结功能至关重要。如果您不知道最终产品将是什么，那么很难编写文档。翻译第二天删除或更改的字符串令人沮丧。

然后，您便拥有了该发行版的所有下游使用者，可以花一些时间来准备它。 打包人员需要的软件不会经常变化并添加依赖项，以便他们可以为OpenStack项目准备尽可能接近我们发布日期发布的软件包。 市场营销团队需要时间来调查整个周期内生产的产品，并将其安排在关键消息中，以便在发布时与外界进行交流。

最后，对于版本管理 ，功能冻结是降低风险的工具。最终目标是避免在发布之前引入尴尬的回归。通过逐渐限制发布分支中接受的内容的影响（使用功能冻结，还使用接下来的RC舞动），我们将尽力防止这种情况的发生。

功能冻结的例外

对于所有这些组，至关重要的是我们必须尽早停止添加功能，更改行为，添加新的配置选项或更改可翻译字符串。当然，这是一个权衡。某些事情对于发布的成功至关重要，或者显然受到风险的限制。这就是为什么我们要有一个例外流程：Feature Freeze例外（“ FFE”）。

PTL可以授予功能冻结例外（在发布管理团队的友好但有力的建议下）。想法是权衡在发行版中具有该功能的原始利益，引入的代码的复杂性，其引起回归的风险以及我们对功能冻结的深度。在要素冻结后几天准备合并的自包含更改，与重构仍需要大量工作才能完成的关键层相比，很有可能会产生异常。这也取决于该项目已授予多少例外，因为在某个时候添加更多内容只会导致过多的中断。

这是一个艰巨的任务，发布管理团队将在这里帮助PTL实现它。如果您的功能被拒绝，请不要个人使用。如您所见，其中涉及许多因素。我们的共同目标是提高最终版本的质量，而我们授予的每个功能冻结例外都离此一步。我们只是不能退后一步，仍然保证我们会赢得比赛。

最初发表在Seeing the fnords 。 与作者协商，重新发布为知识共享许可。

翻译自: https://opensource.com/business/14/3/why-feature-freeze-openstack

openstack 功能