| RFC-0018：FTP 流程：一个适度的提案 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | FIDL 调整提案 (FTP) 流程旨在为更改 FIDL 语言、绑定和工具提供统一且有记录的路径。 |
| 作者 | |
| 提交日期（年-月-日） | 2018-07-17 |
| 审核日期（年-月-日） | 2018-08-01 |
摘要
FIDL 调整提案 (FTP) 流程旨在为更改 FIDL 语言、绑定和工具提供统一且有记录的路径。
设计初衷
创建此类 FTP 系统有几个设计初衷。
FIDL（Fuchsia IPC 系统）受到许多设计 限制。这些限制包括性能、安全性和人机工程学。这些限制往往相互冲突，并且需要在各种目标语言中支持 IPC 绑定，这增加了进一步的权衡。FTP 提案系统提供了一种方法来解决和记录有关这些权衡的决策。
记录决策很有价值，原因如下：首先，它提供了一种方法，可以防止在没有任何变化的情况下反复重新审视相同的决策，同时仍然允许在基本假设实际发生变化时重新审视决策。其次，它为新团队成员或 Fuchsia 的新客户提供了一些背景信息，让他们了解 FIDL 的发展历程以及做出某些决策的原因。
最后，FIDL 作为一种编程语言，会引发大规模的“自行车棚效应” ，只有 Wadler 定律才能实现这种效应。这为发生此类事情提供了一个场所，而不是一个包含数百人的邮箱名单。
设计
FTP（FIDL 调整提案）会经历几个阶段。这些阶段与模板标题的“状态”字段相对应。
草稿
一人或多人对某项更改感到兴奋！他们制作了调整模板的副本，并开始编写和设计。提案应解决模板中的每个部分标题，即使只是说“不适用”也是如此。
在此阶段，他们可能会开始向受影响方征求有关草稿的反馈。
评论
在此阶段，FTP 会正式分发给 Fuchsia 工程组织以供评论。提案的作者应向那些特别容易受到提案影响的人征求反馈。
目前，提案应至少保留一周以供评论，具体时间由审核人员自行决定。对于争议较少的 FTP，时间可能会较短；对于需要等待特定人员或群组的反馈，时间可能会较长。
任何人都可以对 FTP 发表阻止性评论。阻止性评论不会阻止审核流程产生特定的接受或拒绝结果，但审核人员必须在最终 FTP 中确认评论中给出的反馈。
查看
此时，FTP 以及所有未完成的评论都会接受审核。
提案由 Fuchsia FIDL 团队（非正式名称为 luthiers）的成员以及他们认为适合参与或委托参与该流程的任何人进行审核。例如，在决定该语言的绑定时，他们可能会邀请特定的语言专家参与。如有必要，有争议的决策可以像 Fuchsia 中的任何其他技术决策一样升级。
审核最终可能会产生三种结果。
首先，可能存在未解决的问题或需要反馈才能做出决定。在这种情况下，FTP 会移回“评论”阶段。
其次，提案可能会被拒绝，审核人员会提供拒绝理由。
第三，提案可能会被接受。
已拒绝
被拒绝的 FTP 是工程决策的宝贵记录。被拒绝后，应将拒绝理由添加到 FTP 中。然后，FTP 将被复制到所有 FTP 的公共记录中，以供后人参考。
给定的理由应在以下两个方面具有可操作性。
首先，如果接受此提案，世界会发生哪些变化？
其次，理由应解决“评论”期间提出的任何阻止性评论。
已接受
已接受的 FTP 在审核后也会附加一个理由部分，并会收到跟踪 bug。
接受理由与拒绝理由适用相同的限制。特别是，需要解决任何阻止性评论。
然后，就可以开始实施更改了。
已实施
在此阶段，提案已落地。所有代码都已更改。教程已更新。bug 已标记为完成。FIDL 处于更完美的调整状态。
该流程的最后一步是将 FTP 的 Markdown 版本落地到 Fuchsia 树中。无论提案是否被接受，此步骤都适用，因为能够指出已考虑但被拒绝的提案是此流程价值的重要组成部分。
文档和示例
本文档 (FTP-001) 是此流程的第一个此类示例。
理想情况下，模板加上此提案的最终版本就足以作为该流程的文档。
向后兼容性
不适用
性能
不适用
安全
我相信，此计划将带来适度的益处，即为安全审核提供一个场所。目前，对 FIDL 的所有更改都是通过聊天或代码审核进行讨论的。在 FTP 流程之前，没有书面记录。
测试
与谈论此计划的测试相比，谈论成功似乎更容易。
此流程的直接成功标准将是，更改 FIDL 的几个未完成的想法是否顺利通过该流程，而不会过于繁琐。
一个长期成功指标是，旧 FTP 是否经常被提及。
缺点、替代方案和未知因素
通过略微正式的流程将对 FIDL 的更改序列化会产生少量成本。我相信，与实施任何更改（尤其是随着 ABI 的硬化和重大更改变得更加困难）所需的工程工作相比，以及与记录这些决策的回报相比，该成本实际上很小。
我考虑过的最大的替代方案是更开放的版本。目前，评论和审核流程目前仅对 Google 员工可见或开放。我相信，这是目前正确的决定，并着眼于未来重新评估。
我还想知道，是否有比 Google 文档更好的方式来捕获评论，尤其是在将 FTP“冻结”为接受或拒绝状态时。
我怀疑我们可能需要一个版本，用于捕获在此流程采用之前做出的有关 FIDL 的决策。
最后，我想知道接受或拒绝标准应该有多正式。我相信，如果需要，借助早期 FTP 的决策理由，这可以随着时间的推移演变成更正式的东西。
在先技术和参考文档
有几种开源编程语言具有增强提案或 RFC 机制。
特别是，在起草本文档时，我大量参考了 Python PEP 流程和 Rust RFC 流程。