| 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 调整提案）会经历几个阶段。这些阶段与模板标题的“Status:”（状态）字段相对应。
草稿
一人或多人对某项变更感到兴奋！他们复制了调整模板，然后开始编写和设计。提案应针对模板中的每个部分标题进行说明，即使只是说“不适用”也行。
在此阶段，他们可能会开始向受影响的各方征求对草稿的反馈。
Comment
在此阶段，FTP 会正式分发给 Fuchsia 工程组织，以供其提供意见。提案作者应征求那些特别可能受到提案影响的人员的反馈。
目前，提案应至少公开一周，以供评论，具体取决于审核员的决定。对于争议较少的 FTP，等待时间可以缩短；对于需要等待特定个人或群组提供反馈的 FTP，等待时间可以延长。
任何人都可以对 FTP 文件发表屏蔽评论。屏蔽评论不会阻止审核流程做出接受或拒绝的特定结果，但审核员必须在最终的 FTP 中确认评论中提供的反馈。
查看
此时，我们会审核 FTP 以及所有未处理的评论。
该提案将由 Fuchsia FIDL 团队的成员（非正式称为“制琴师”）以及他们认为适合参与或委托参与该流程的任何人进行审核。例如，在决定某种语言的绑定时，他们可能会包含特定语言专家。如有必要，我们可以将有争议的决策上报给 Fuchsia 团队，就像处理 Fuchsia 中的任何其他技术决策一样。
审核最终可能有以下三种结果。
首先，我们可能需要解决一些未解决的问题或收集一些反馈，才能做出决定。在这种情况下，FTP 会移回“评论”阶段。
第二，提案可能会被拒绝，审核员会提供拒绝原因。
第三种情况是，我们可能会接受。
已拒绝
被拒绝的 FTP 是工程决策的重要记录。被拒绝后，应将拒绝原因添加到 FTP 中。然后，系统会将 FTP 复制到所有 FTP 的公开记录中，以供日后参考。
所提供的理由应具有以下两种意义上的可操作性。
首先，世界需要发生哪些变化才能接受这一提议？
其次，理由应针对在意见征求期内提出的所有被屏蔽的评论进行说明。
已接受
在审核通过后，已接受的 FTP 还会附加一个理由部分，并会收到一个跟踪 bug。
接受理由和拒绝理由适用相同的限制。特别是，需要解决所有屏蔽评论的问题。
然后，就可以开始实施更改了。
已实施
在此阶段，提案已完成。所有代码都已更改。教程已更新。bug 已标记为已完成。FIDL 的调谐更加完善。
该流程的最后一步是将 Markdown 格式的 FTP 版本提交到 Fuchsia 树中。无论提案是否被接受，这都适用，因为能够指明已考虑但被拒绝的提案是此流程的重要价值之一。
文档和示例
本文档 (FTP-001) 是此流程的第一个此类示例。
理想情况下，模板以及此提案的最终版本就足以对该流程进行充分的文档说明。
向后兼容性
不适用
性能
不适用
安全
我认为，此方案有一点好处，就是提供了一个进行安全审核的场所。目前，对 FIDL 的所有更改都通过聊天或代码审核进行讨论。在 FTP 流程之前，没有任何纸质记录。
测试
与测试此方案相比，谈论成功似乎更容易。
此流程的直接成功标准将是，是否有几个关于更改 FIDL 的出色想法能够顺利完成该流程。
一个长期成效指标是是否定期指向旧 FTP。
缺点、替代方案和未知情况
通过稍微正式的流程对 FIDL 进行序列化会产生一些开销。我认为，与实现任何更改所需的工程工作（尤其是随着我们的 ABI 变得更为严格，更改变得更难）以及记录这些决策的好处相比，这种成本实际上很小。
我考虑的最大替代方案是采用更开放的版本。目前，只有 Google 员工可以看到或参与评论和审核流程。我认为，目前这是正确的决定，我们日后会重新评估。
我还想知道，是否有比 Google 文档更好的方式来捕获评论，尤其是在将 FTP 冻结为已接受或已拒绝状态时。
我怀疑我们可能需要一个版本，用于记录在采用此流程之前针对 FIDL 做出的决策。
最后，我想知道接受或拒绝标准的正式程度。我相信，随着时间的推移，在早期 FTP 的决策依据的帮助下，这可能会演变为更正式的形式（如果需要）。
在先技术和参考文档
一些开源编程语言具有增强提案或 RFC 机制。
在起草本文件时，我仔细研究了 Python PEP 流程和 Rust RFC 流程。