| 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 的安全性。
- 可能会导致旧系统无法更新到较新系统版本或需要过渡版本。这一点很重要，因为过渡版本会产生长期成本。当设备首次设置或在长时间断开连接后重新连接时，必须通过每个过渡版本进行更新，这会给最终用户带来额外的时间和网络流量成本。过渡版本中的 bug 可能会影响通过该版本升级的设备的安全性和可用性，即使在原始版本发布数年后也是如此，这意味着过渡版本必须经过测试，并且维护时间要比常规版本长得多。
- 会大幅增加资源用量的更改。无论是内存、磁盘、CPU、网络等。这有助于更全面地了解共享设备资源使用情况的变化。
- 隐私权政策或其执行情况的修改。这一点很重要，因为这些更改可能会影响 Fuchsia 为用户提供的隐私保护。目前，我们在代码库中处理 PII 的能力有限，但如果我们将来想这样做，则应通过 RFC 进行。
示例：过去进行的更改，现在需要 RFC
- OTA 后备；对 OTA 流程的更改。
- OTA 后健康检查；对 OTA 流程的更改。
- 软件包格式的更改，例如
meta/contents大修。 - 迁移到 vbmeta 中的渠道；更改了 OTA 流程和 OTA 要求。
示例：过去不需要 RFC 的更改
- CFv2 迁移；它们由其他制品涵盖。
- Blob 下载恢复；可选功能，在软件包解析器之外不可观测，风险已在代码审核流程中得到缓解。
- 对 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 流程，我们就应该修改此列表。