FIDL 语言调整提案 (FTP)

处理

FIDL 调整提案 (FTP) 流程旨在提供统一且记录下来的路径,以便于更改 FIDL 语言、绑定和工具。

要求 FTP 的条件

在以下任一情况下,更改必须通过 FTP 流程完成:

  1. 解决方案空间很大,也就是说,更改是许多可能有用的其他解决方案之一,并且需要在设计方面做出艰难的权衡;

  2. 这项变更的影响很大,也就是说,这项变更以重大方式修改 FIDL 的行为,可能会给多名或多名 FIDL 用户带来风险;

  3. 变更的影响范围较大,也就是说,变更涉及的 FIDL 足够多,因此需要仔细关注,以确定它是否可能会导致较大影响。

例如,对以下部分所做的更改可能需要 FTP:

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

如需了解其他详细信息,请参阅 RFC-0049: FIDL Tuning Process Evolution

设计

FTP(FIDL 调整提案)需要经历几个阶段。这些阶段对应于模板标题的 Status: 字段。

草稿

有一位或多位用户对某项更改感到期待!他们复制调优模板,然后开始编写和设计。提案中应列出模板中的每个部分标题,即使只是显示“不适用”也是如此。

在这个阶段,他们可能会开始向受影响的相关方征求对草稿的反馈。

备注

在此阶段,FTP 会被正式传播给紫红色工程组织以添加注释。提案的作者应征求特别可能受到提案影响的用户的反馈。

目前,提案应至少留出一周时间来进行评论,由审核人员自行决定。对于争议性较少的 FTP,建议选择简短一点,而等待特定人员或群组提供反馈可能是合理的。

任何人都可以在 FTP 上发表禁止评论。屏蔽评论不会阻止审核流程中的特定接受或拒绝结果,但审核者必须在最终 FTP 中确认评论中给出的反馈。

正在撤回

已撤销的 FTP 是工程构思的宝贵记录。当作者撤销其 FTP 时,必须将撤销理由添加到 FTP 中。然后,系统会将 FTP 复制到所有 FTP 的公开记录中以供日后使用。

撤销理由由 FTP 作者以及 Fuchsia FIDL 团队的成员共同撰写。

调查理由应能通过以下两种方式采取行动。

作者通过 FTP 流程了解到了什么,促使他们提出了一种替代设计?

还有哪些方案可以替代已撤销的 FTP,且颇具潜力?

查看

目前,我们正在审核 FTP 以及所有未解决的评论。

此提案将由 Fuchsia FIDL 团队(由 fuchsia.git 代码库中的 OWNERS 文件定义,非官方名称为 Luthiers 文件)以及他们认为适合在流程中纳入或委托的任何人进行审核。例如,在决定特定语言的绑定时,他们可能会添加特定语言专家。如有必要,像 Fuchsia 中的其他技术决策一样,有争议的决策也会上报。

通常,审核会在一次或多次线下会议(即“FTP 审核会议”)中进行。如果需要,还可以通过异步通信方式进行审核。

FTP 审核会议首先由作者展示自己的设计。然后,教员将在 FTP 中处理评论,请曾在文档中发表评论的人提供反馈。

理想情况下,教员和演示者是不同的人。教员的目标是确保设计的所有方面都得到处理,并确保会议顺利进行。理想情况下,为了避免让人产生偏见,教员对结果没有特定的利益,演示者也隐含了他们所演示的设计。

我们不一定需要在会议期间结束每条反馈,也不一定需要讨论每条最后一条评论(例如,如果有大量评论或多条评论都是针对同一根本问题)。相反,教员应进行优化,以为演示者提供广泛的反馈,而不是推动每个论点得出结论。待处理的待解决问题可能会在后续审核会议中或在决策过程中解决。

决策

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

该决定最终会产生三个结果。

首先,在做出决策之前,您可能需要提出未解决的问题或提供反馈。在这种情况下,FTP 会移回“评论”阶段。

其次,提案可能会被拒绝,审核人员会说明拒绝原因。

第三,其可能被接受。

通常,决策会采用会议形式。这也可能是电子邮件会话,或在审核会议期间发生。

已拒绝

被拒的 FTP 是工程决策的宝贵记录。被拒后,应将拒绝的原因添加到 FTP 中。然后,系统会将 FTP 复制到所有 FTP 的公开记录中以供日后使用。

给定理由应具有切实可行性,体现在以下两个方面。

首先,全世界必须做出哪些改变才能接受此提案?

其次,发布理由应解决在评论期间出现的任何阻止评论的问题。

已接受

已接受的 FTP 在审核后还会附加一个理由部分,并且会收到跟踪 bug。

接受理由与拒绝理由具有相同的限制。特别是,需要解决所有阻塞评论的问题。

然后就开始实施更改了。

已实施

在此阶段,提案将进入“成功”阶段。所有代码都已更改。教程已更新。该 bug 会被标记为已完成。FIDL 进行了更完美的调优。

该流程的最后一步是将 Markdown 版本的 FTP 提交到 Fuchsia 树。无论提案是否被接受,这都适用,因为能够指向已经考虑过但被拒绝的提案是此流程价值的重要组成部分。