RFC-0049：FIDL 微调过程的演变

RFC-0049：FIDL 调优流程演变
状态	已接受
区域	FIDL
说明	我们建议对 FTP 流程进行各种改进，包括将审核与决策分开、引入作者撤回 FTP 的方式、提供有关哪些内容需要 FTP 的指南，最后介绍贡献 FIDL 的其他途径。
作者	pascallouis@google.com
提交日期（年-月-日）	2019-11-20
审核日期（年-月-日）	2019-12-19

摘要

我们提出了 FTP 流程的各种改进方案：

• 最重要的是将审核与决策分开；
• 引入一种供作者撤回其 FTP 的方式；
• 提供需要 FTP 的内容的相关准则；最后
• 描述贡献 FIDL 的其他途径。

设计初衷

FIDL 调优流程已推出一年多。从各方面来看，此流程成功实现了其创建背后的三个动机和目标：仔细考虑设计限制；每项决策背后的思路都是透明的、有记录的且公开的；最后，此流程还提供了一个讨论想法（有时会进行长时间讨论）的论坛，同时还可达成最终结论。

最终结果是，我们能够持续快速地进行更改，并制定了迭代策略。迄今为止，已提交 48 项提案（称为“FTP”），其中 25 项已获接受，9 项已遭拒绝（所有拒绝均有妥善记录的拒绝理由）。

不过，与所有事物一样，它也有改进的空间。具体而言，我们会考虑以下因素：

• 如何最好地查看 FTP？
• 何时可以撤回 FTP？
• 哪些更改需要通过 FTP 进行？
• 还有哪些其他方式可以为 FIDL 的设计和发展做出贡献？

设计

查看 FTP

目前，该流程并未明确规定应如何审核 FTP，仅指出“提案由 Fuchsia FIDL 团队（非正式名称为 luthiers）的成员审核，以及他们认为适合纳入或委托给流程中的任何人审核。”

最常见的 FTP 审核方式是面对面会议。会议开始时，FTP 作者会介绍其设计。会议主持人（通常是今天的 FIDL 负责人）随后会处理设计文档中的评论，可能会先快速制定一个应讨论的“未解决问题”议程。

与“工程审核流程”不同的是，在会议期间解决未完成的问题（记录笔记，稍后将其纳入 FTP）是很常见的做法，并且会议结束时 FIDL 负责人会决定接受还是拒绝 FTP。

会议结束时做出决定的预期，以及 FIDL 负责人同时扮演协调员和决策者的双重角色，造成了摩擦：FTP 会议期间的匆忙感、参与者感受到必须让自己的声音被听到的压力，以及为了批准快速修订的 FTP 而在最后一刻做出的临时设计决策。

为了解决这种不良动态，我们修改了“审核”步骤，并添加了明确的“决策”步骤。部分文字借鉴自英文审核流程。 “检查”步骤的变更如下：

此时，系统会审核 FTP 以及所有未解决的评论。

该提案由 Fuchsia FIDL 团队的成员（由 fuchsia.git 代码库中的 OWNERS 文件定义，非正式名称为“luthiers”）以及他们认为适合纳入或委托的任何人进行审核。例如，在决定相应语言的绑定时，他们可能会咨询特定的语言专家。如有必要，有争议的决策可以像 Fuchsia 中的任何其他技术决策一样上报。

[添加] 最常见的情况是，在一次或多次面对面会议（即“FTP 审核会议”）期间进行审核。如果合适，也可以使用异步通信进行审核）。

FTP 审核会议开始时，作者会先介绍自己的设计。然后，主持人将浏览 FTP 中的评论，并请在文档中留下评论的人员介绍自己的反馈。

[添加] 主持人和演示者最好是不同的人。主持人的目标是确保设计的所有方面都得到解决，并保持会议顺利进行。理想情况下，主持人不应与结果有任何利害关系，以免给人留下偏见的印象；而演示者则会隐式地与他们所演示的设计有某种利害关系。

[添加] 我们不一定需要在会议期间就每条反馈意见达成结论，也不一定需要讨论每条评论（例如，如果评论数量众多，或者多条评论都指向同一个根本问题）。相反，主持人应侧重于为演示者提供广泛的反馈，而不是推动每个辩论点得出结论。待解决的未决问题可能会在后续审核会话或决策过程中得到解决。

审核最终可能会有三种结果。

首先，可能存在需要解答的问题或需要反馈才能做出决定。在这种情况下，FTP 会移回“评论”阶段。

其次，提案可能会被拒绝，审核人员会提供拒绝理由。

第三，可能被接受。

在“审核”步骤之后添加“决策”步骤：

在五 (5) 个工作日内，Fuchsia FIDL 团队（由 Owners 文件定义）的成员（最终决策者为 Fuchsia FIDL 团队负责人）将决定审核结果。

最终，该决定可能会有三种结果。

首先，可能存在需要解答的问题或需要反馈才能做出决定。在这种情况下，FTP 会移回“评论”阶段。

其次，提案可能会被拒绝，审核人员会说明拒绝理由。

第三，可能被接受。

通常，决策场所将以会议的形式呈现。也可能是电子邮件会话串，或者发生在审核会议期间。

撤回 FTP

有时，FTP 的作者希望撤回其 FTP。

在“评论”步骤之后添加“已撤回”步骤：

已撤消的 FTP 是宝贵的工程创意记录。当作者撤回其 FTP 时，必须将撤回理由添加到 FTP 中。然后，该 FTP 将被复制到所有 FTP 的公开记录中，以供后代参考。

撤回理由由 FTP 作者撰写，可能与 Fuchsia FIDL 团队的成员共同撰写。

推理应以以下两种方式可操作。

作者在 FTP 流程中了解到了什么，以至于提出了替代设计？

有哪些有前景的替代 FTP 的方案？

需要 FTP 的条件

我们知道，并非所有对“FIDL”的更改都需要 FTP。没有人会要求为 fidlc 中的小型重构编写设计文档。另一方面，引入新的消息布局或更改线格式绝对需要 FTP。

我们认为，当变化超过哪个阈值时，就需要进行 FTP？ 我们遵循的一般规则是：

在以下任一情况下，更改必须通过 FTP 流程：

1. 解空间较大，即更改是许多可能不错的其他解决方案之一，并且需要做出艰难的设计权衡；

2. 更改影响较大，即更改以实质性方式修改了 FIDL 的行为，可能会给 FIDL 的许多用户或所有用户带来风险；

3. 变更范围较大，即变更涉及足够多的 FIDL 部分，需要仔细注意才能确定它是否会产生重大影响。

例如，对以下方面所做的更改可能需要进行 FTP：

• FIDL 治理
• 设计原则
• 语言语法
• 类型系统
• 协议语义
• Wire 格式
• 绑定规范

以下是一些 FTP 示例，以及它们更改的区域：

• RFC-0047：表格：
  （类型系统）引入了一种表示类似记录的数据的新方式，首次使用信封。
  线上传输格式）表格和信封的新线上传输格式。
  （绑定规范）一些 API 建议，供绑定遵循。

• RFC-0023：协议的组合模型：
  （语言语法）将接口语法替换为协议语法。
  （协议语义）明确了协议组合的语义，包括支持不存在“is-a”关系的情况。
  （绑定规范）禁止绑定利用多态性进行模型组合。
  

• RFC-0027：您只需要按照实际用量付费：
  （设计原则）引入了一项新的设计原则。
  FIDL Governance）明确要求将新引入的设计
  原则纳入 FTP 流程。

• RFC-0024：强制性来源兼容性：
  （FIDL 管理）修改了 FTP 模板，以添加有关来源
  兼容性的注释。 绑定规范）
  绑定上的自举源兼容性要求。

• RFC-0049：FIDL 调整流程演变，即此变更：
  FIDL 管理）旨在为 FTP 流程提供更多指导，
  并认可贡献 FIDL 的替代方式。

相比之下，以下是一些未达到 FTP 标准的更改示例：

• 创建新的 FIDL 绑定（例如 LLCPP 绑定）：
  FIDL 旨在支持多种实现相互交互。
  创建新绑定是预期行为，无需 Fuchsia FIDL 团队的任何批准即可完成。
  

• 明确引用枚举成员¹：
  在支持 my.library.MY_ENUM_MEMBER 之前，它被显式语法 my.library.MyEnum.MY_ENUM_MEMBER 取代。尽管更改了语言语法，但此更改是对之前存在的功能的 bug 修复。如果某个库同时具有枚举成员 CLASHING_NAME 和常量 CLASHING_NAME，那么引用任一者都会造成歧义，并且 fidlc 会采用一些不太正规的类型解析规则来打破这种僵局。成员的作用域规则未发生变化，成员的作用域限定为声明，并且 fidlc 和所有绑定都遵循该规则。

• 实现意向：延迟从原始到扁平转换后的类型构造：
  虽然对类型系统的实现进行了重做，但没有进行可观测到的更改。这是一项重构工作。

• 实现意图：更改“消息”的表示方式：虽然 JSON IR 会受到此更改的影响，但此表示方式更改会使之前需要由绑定隐式了解的某些概念（标头形状）变为显式了解。同样，没有可观测到的变化，并且除了代码结构（在 fidlc 中和绑定中）之外，没有其他影响。

为 FIDL 贡献力量（不仅限于 FTP）

Fuchsia FIDL 团队的目标是“围绕 FIDL 促进协作和包容性”，具体而言，要确保“整个 Fuchsia 团队都认为他们可以就粗略的边缘情况提出意见，并且非 FIDL 团队成员的贡献会得到适当的指导和支持，以便最终实现，或者在早期就被拒绝并给出合理理由。”

撰写 RFC 通常需要大量工作，并且需要了解解决方案空间，才能充分说明所做出的特定设计选择相对于替代方案的合理性。FTP 流程本身也相当繁琐，可能会令人不悦。因此，FTP 流程本身无助于实现协作目标。

您还可以通过以下方式做出贡献：

• 在 Fuchsia FIDL 团队聊天室中讨论用例和问题。团队的所有成员都会密切关注对话，并且此论坛中的帖子经常会促成大小不一的更改或优先顺序的调整。

• 参与 Fuchsia API 审核。此活动是了解具体用例并衡量各种 FIDL 功能如何组合以支持这些用例的关键。通过识别可通过调整功能或完全添加新功能来增强的 API 设计模式，我们实现了多次演变。

• 针对 Fuchsia FIDL 团队提交 bug。

• 描述问题陈述，并与 Fuchsia FIDL 团队和整个 Fuchsia 团队合作，探索可能的解决方案。

• 描述可能的解决方案，并与 Fuchsia FIDL 团队和整个 Fuchsia 团队合作评估该解决方案。

• 设计替代方法原型。

• 以“20%-er”身份加入 FIDL 团队，并负责 FIDL 团队分配的项目。

所有这些都可能导致捕获清晰的问题陈述、直接更改 FIDL 或转为 FTP。

实施策略

更新了 FIDL 调优提案页面。广泛宣传此项变更。在进行审核时，跟进更改。

工效学设计

无影响。

文档和示例

请参阅“实施策略”。

向后兼容性

无影响。

性能

无影响。

安全

无影响。

测试

无影响。

缺点、替代方案和未知因素

虽然有很多方法可以修改流程，但我们认为，拟议的变更是一项适度的迭代，预计会带来净收益。预计未来流程会不断改进。

在先技术和参考资料

许多。一种是 Fuchsia 采用的“工程审核”流程。

bug_report code edit

---

1. CL fxr/299869、 fxr/301089、 fxr/300672、 fxr/302294、 fxr/302728。 ↩