| RFC-0103：软件交付 RFC 标准 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | RFC 流程的附录，适用于影响软件交付代码库或政策的更改。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-05-19 |
| 审核日期（年-月-日） | 2021-06-10 |
摘要
软件交付领域中需要 RFC 的更改的条件。
设计初衷
软件分发 (SWD) 系统对系统行为具有广泛的控制范围，包括无线下载 (OTA) 系统更新、开发和测试流程、设备安全性，以及最终在不更新系统的情况下进行软件包更新。对 SWD 堆栈所做的更改可能会以细微的方式修改系统行为，并给 Fuchsia 程序带来开销。为了尽可能遵循 Fuchsia 范围内的 RFC 流程，我们希望通过提出一组明确的标准来消除对 SWD 领域中具有“广泛影响”的更改的歧义。这些标准旨在在执行速度与适当的利益相关方沟通和审批流程之间取得平衡。
设计
需要 RFC 的更改
- 对系统更新流程所做的更改，这些更改会向 OTA 流程添加限制或门限，或添加新的错误条件。例如，在完成 OTA 之前添加其他检查，或更严格地进行 OTA 降级检查。这一点很重要，因为这些更改可能会降低 OTA 流程的可靠性。
- 我们使用软件包仓库的方式或我们预期的软件包仓库结构发生变化。我们预计内部和外部开发者都可以创建或托管自己的 TUF 服务器，并且我们应在预期格式发生变化时提供适当的通知。
- Fuchsia 软件包格式变更。修改 Fuchsia 软件包的架构或 Fuchsia 归档格式的任何操作。这一点非常重要，因为许多不同的工具都会与软件包格式交互，因此我们应提供适当的更改通知。
- 为产品或 build 类型添加或移除支持 OTA 系统更新的要求。例如，要求 vbmeta 成功 OTA，或移除对 vbmeta 的要求。这一点很重要，因为这些更改可能会给产品开发者带来费用。
- 对安全政策强制执行方式的修改。例如，更改可执行性限制策略。这一点很重要，因为这些更改可能会影响 Fuchsia 的安全性。
- 可能会导致旧系统无法更新到较新系统版本或需要使用过渡 build 的更改。这一点很重要，因为采用过渡版本会产生长期费用。当设备首次设置或在很长一段时间后重新连接时，必须通过每个分阶段版本进行更新，这会给最终用户带来额外的时间和网络流量开销。过渡版本中的 bug 可能会影响通过该版本升级的设备的安全性或可用性，即使在原始版本发布多年后也是如此，这意味着过渡版本的测试和维护时间要比常规版本长得多。
- 会大幅增加资源用量的更改。无论是内存、磁盘、CPU、网络等。这样，您可以更全面地了解共用设备资源使用情况的变化。
- 隐私权政策的修改或违规处置。这一点很重要，因为这些更改可能会影响 Fuchsia 为用户提供的隐私保护。目前，我们在代码库中处理个人身份信息的能力有限，但如果将来有需要，我们应该会通过 RFC 来处理。
示例：现在需要 RFC 的过往更改
- OTA 回退；OTA 流程变更。
- OTA 后健康检查；OTA 流程的更改。
- 软件包格式的更改，例如
meta/contents的全面改进。 - 向 vbmeta 中的频道迁移；OTA 流程和 OTA 要求的变更。
示例：过去的更改，仍无需 RFC
- CFv2 迁移；其他工件已涵盖这些迁移。
- 恢复 blob 下载；可选功能在 pkg-resolver 之外不可观察，风险已在代码审核过程中得到缓解。
- 更改了 SWD 堆栈发出的指标或检查。
- 为商品添加了渠道。
- 可靠性改进，例如使
fx ota适合内核开发者使用。如果回归风险较小，PSA 就足够了。 - 废弃了
amberctl，并将开发者迁移到了pkgctl。这应该由 LSC 流程处理，因为这两种工具的工作流和目标几乎完全相同。
实现
对于已通过其他流程获得设计审批且正在实施的持续性工作，无需提交追溯性 RFC 即可继续进行。不过，对于软件交付堆栈中具有足够方向性且在其他地方文档不足的部分，我们应提交具有追溯性的 RFC。我们将逐个项目评估正在进行或即将完成的工作，以确定是否应为其编写具有追溯性的 RFC。
尚未过设计阶段的作品必须遵守这些准则。
这些准则自 RFC 发布之日起生效，我们会将其添加到 RFC 文档中的当前流程页面。如果我们更新这些准则，将会在后续 CL 中以此 RFC 的附录的形式进行更新。
如果贡献者希望与 SWD 团队就 RFC 进行合作，可以随时与 pkg-dev@fuchsia.dev 联系，我们会为他们指定专门的联系人。
性能
无影响，仅更改了流程。
工效学设计
如果我们发现正在进行的更改本应通过 RFC 更好地传达，或者我们发现需要以其他方式修改这些标准，我们会重新审视这些标准。无论采用哪种标准，我们都需要在执行速度和沟通之间取得平衡。
向后兼容性
无影响。
安全注意事项
根据这些条件，对 SWD 区域进行的更改如果会修改安全策略，则需要提交 RFC。
隐私注意事项
根据这些标准，对 SWD 区域进行的更改如果会修改隐私权注意事项，则需要提交 RFC。
测试
无影响。
文档
如果此 RFC 被接受，我们会更新当前 RFC 流程文档。
缺点、替代方案和未知情况
我们可以使用许多替代条件。如果我们发现根据此标准，有太多“小”更改需要 RFC，或者发现通过 RFC 流程的“大”更改数量不足，则应修改此列表。