| RFC-0103：软件交付 RFC 标准 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | RFC 流程附录，针对会影响软件交付代码库或政策的更改。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 |
|
| 提交日期（年-月-日） | 2021-05-19 |
| 审核日期（年-月-日） | 2021-06-10 |
总结
“软件交付”区域要求使用 RFC 的变更的标准。
设计初衷
软件交付 (SWD) 系统涉及多个系统行为，包括无线下载 (OTA) 系统更新、开发和测试流程、设备安全，以及最终在没有系统更新的情况下打包更新。对 SWD 堆栈的更改以细微的方式修改系统的行为，并导致 Fuchsia 程序产生费用。为了最好地遵循适用于整个紫红色的 RFC 流程，我们通过提出一套明确的标准，力求消除那些对 SWD 领域具有“广泛影响”的变更的歧义。这些标准旨在试图在执行速度与适当的利益相关方沟通和审批流程之间取得平衡。
设计
需要 RFC 的更改
- 更改了系统更新流程，会向 OTA 进程添加限制或关口，或添加新的错误情况。例如，在完成 OTA 之前添加其他检查，或对 OTA 降级进行更严格的检查。这一点非常重要，因为这些更改可能会降低 OTA 流程的可靠性。
- 我们使用软件包代码库的方式或我们预期的软件包代码库结构的变更。我们希望内部和外部开发者可以创建或托管自己的 TUF 服务器，因此对于预期格式的更改，我们应提供适当的通知。
- Fuchsia 软件包格式的变更。对 Fuchsia 软件包架构或 Fuchsia Archive 格式进行任何修改。这一点非常重要，因为许多不同的工具都会与软件包格式交互，而我们应就变更提供适当的通知。
- 添加或移除针对产品或 build 类型的要求，以支持 OTA 系统更新。例如，成功要求从 vbmeta 升级到 OTA，或者移除对 vbmeta 的要求。这一点非常重要，因为这些更改可能会给产品开发者带来成本。
- 针对安全政策的执行所做的修改。例如，更改可执行限制策略。这一点非常重要，因为这些变化可能会影响 Fuchsia 的安全性。
- 可能导致旧系统无法更新到较新系统版本的更改，或需要进行踏步构建。这一点很重要，因为踏步发布会产生长期成本。首次设置设备时或在很长一段时间后重新连接设备时，设备必须在每次跳跃式版本发布时进行更新，从而增加最终用户的时间和网络流量。跳跃版本中的 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 附录的形式进行更新。
如果贡献者希望通过 RFC 与 SWD 团队合作，他们可以随时与 pkg-dev@fuchsia.dev 联系，我们会为他们分配一个指定联系人。
性能
无影响，仅处理更改。
工效学设计
如果我们发现正在发生的更改更适合由 RFC 传达，或者发现需要通过其他方式修改这些标准，我们将重新考虑这些标准。无论标准如何，我们都需要在执行速度和通信之间取得平衡。
向后兼容性
无影响。
安全注意事项
对修改安全策略的 SWD 区域进行更改将需要根据这些条件提供 RFC。
隐私注意事项
如果对 SWD 区域进行更改，这会修改隐私权注意事项，则根据这些条件，您需要提供 RFC。
测试
无影响。
文档
如果此 RFC 被接受，我们将更新当前 RFC 流程文档。
缺点、替代方案和未知情况
我们可以使用很多备选条件。如果我们发现有太多“小”变更需要基于此标准进行 RFC 的变更，或者发现没有足够多的“大型”变更需要通过 RFC 流程完成，我们应该修改此列表。