ECO

工程变更单

这最好理解为对 SUSE Linux Enterprise 的后期功能请求的批准，因此也适用于大约 4000/~12000 个 openSUSE Leap 包。 通过采纳以下提案 Portal:Leap/FAQ/ClosingTheLeapGap，这一点变得更加明显和重要。

后期功能意味着请求计划在给定版本的后期开发阶段执行/实现，包括维护更新。 给定功能的预期里程碑，将被视为后期功能请求，例如公开 Beta、发布候选版、GMC、GM、维护更新。

为什么

SUSE Linux Enterprise 向客户承诺稳定性与可预测性，即在服务包的生命周期内，ABI、API 或配置不会发生变化……因此在应用更新时“不会有意外”。

任何偏离稳定性的行为都需要经过变更管理流程，例如 ECO 流程，明确确定需求、风险以及变更方式。

如何操作

当前的流程实现发生在内部 SUSE JIRA。

它本质上是来自所有利益相关者（工程、L3、安全、维护、QA（实际上主要是维护 QA）、文档和法律团队）的批准请求。

除非获得上述所有利益相关者的批准，否则功能请求将不会在给定的服务包中实现。 如果请求在开发阶段早期提交，通常可以避免 ECO 流程。 这对于所有功能来说都是首选方案，因为在发布后期引入功能会带来一些风险。

拒绝 ECO 并不意味着功能本身被拒绝，它只是意味着该功能不会作为给定服务包中的后期功能请求实现。

社区参与

此变更流程也可用于 来自 Leap 的功能，但在此情况下需要 SUSE 内部的项目管理赞助者。 请联系 Leap 的发布经理（Lubos）寻求帮助。