| 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 中确认评论中提供的反馈。
查看
此时，系统会审核 FTP 以及所有未解决的评论。
该提案由 Fuchsia FIDL 团队（非正式名称为“luthier”）的成员以及他们认为适合纳入或委托的任何人进行审核。例如，在决定相应语言的绑定时，他们可能会咨询特定语言专家。如有必要，有争议的决定可以像 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 流程。