| RFC-0018：FTP 流程：普通提案 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | FIDL 调整提案 (FTP) 流程旨在提供统一的记录路径，以便更改 FIDL 语言、绑定和工具。 |
| 作者 | |
| 提交日期（年-月-日） | 2018-07-17 |
| 审核日期（年-月-日） | 2018-08-01 |
总结
FIDL 调整提案 (FTP) 流程旨在提供统一且记录下来的路径，以便于更改 FIDL 语言、绑定和工具。
设计初衷
我们之所以创建此类 FTP 系统，是出于多种原因。
FIDL (Fuchsia IPC 系统) 受许多设计限制的约束。其中包括性能、安全性和人体工程学。这两种语言往往互不对应，而且由于需要以各种目标语言支持 IPC 绑定，需要进一步权衡各种因素。FTP 提案系统提供了一种方式来提起诉讼并记录有关这些权衡的决策。
录音的决定很有价值，原因有很多。首先，它提供了一种方式，可以防止在没有发生任何变化时反复重新考虑相同的决策，同时仍然允许在基础假设实际发生变化时重新做出决策。其次，本文为新团队成员或 Fuchsia 的新客户提供了一些背景信息，帮助他们了解 FIDL 的发展过程以及做出某些决策的原因。
最后，FIDL 作为一种编程语言，可以邀请只有瓦德勒定律才能规模化的放电场次。这并不是一个拥有数百人电子邮件名单的收件人，可用来举办此类活动。
设计
FTP（FIDL 调整提案）需要经历几个阶段。这些阶段对应于模板标题的“Status:”字段。
草稿
有一位或多位用户对某项更改感到期待！他们复制调优模板，然后开始编写和设计。提案中应列出模板中的每个部分标题，即使只是显示“不适用”也是如此。
在此阶段，他们可能会开始向受影响的各方征求对草稿的反馈。
备注
在此阶段，FTP 会被正式传播给紫红色工程组织以添加注释。提案的作者应征求特别可能受到提案影响的用户的反馈。
目前，提案应至少留出一周时间来进行评论，由审核人员自行决定。对于争议性较少的 FTP，建议选择简短一点，而等待特定人员或群组提供反馈可能是合理的。
任何人都可以在 FTP 上发表禁止评论。屏蔽评论不会阻止审核流程中的特定接受或拒绝结果，但审核者必须在最终 FTP 中确认评论中给出的反馈。
查看
此时，我们正在审核 FTP 以及所有出色的评论。
该提案由 Fuchsia FIDL 团队（非正式知道为 Luthier 团队）的成员以及他们认为适合在流程中纳入或委托的人员进行审核。例如，在决定特定语言的绑定时，他们可能会添加特定语言专家。如有必要，像 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 流程。