FIDL Tuning Proposal 001

英文原文快照

  • 状态：已接受
  • 作者：kulakowski@google.com
  • 原始日期：2018-07-17
  • 最后更新：2018-08-01
  • Bug追踪：FIDL-228

普通的提案

摘要

FIDL修改提案（FTP）流程旨在为修改FIDL、语言绑定和工具，提供统一和记录的路径。

动机

创建这样的FTP系统来自以下几个动机。

FIDL（Fuchsia的IPC系统）的设计受到许多目标的约束。 其中包括性能、安全性和人体工程学等。 这些目标通常彼此不一致，并且对各种语言的IPC绑定支持的需求进一步增加了彼此权衡的需要。 因此，FTP提案系统提供了调解和记录这些权衡的方法。

由于以下多种原因，记录决策是很有价值的。 首先，它提供了一种方法，可以防止在没有任何变化时重复相同的决策，同时仍然允许在基础假设发生变化时重新审视决策。 其次，它为新的团队成员或Fuchsia的新客户提供了FIDL如何演化以及做出某些决策的原因的上下文。

最后，FIDL作为一种编程语言，遵循Wadler定律的规模大小会带来帕金森琐碎（译者注：原文中的bikeshedding，又称为帕金森琐碎定理，用来说明大型组织会花费大量时间在讨论无关紧要的琐事，但是真正重大的决议反而可以轻松过关这种现象）的问题。 FTP为这样的决策提供了一个不是只能容纳几百人的邮件列表的地方。

设计

FTP（FIDL Tuning Proposal）需经历了几个阶段，这些阶段分别对应于其状态（Status）：即模板的标题字段。

注意：该模板目前仅对Google内部开发。

草案(Draft)

一个或多个人对进行修改感到兴奋！ 他们制作了修改模板的副本，并开始撰写和设计。 该提案应该修改模板中的每个章节的标题，即使仅仅是说明“不适用”也需要写出。

在这个阶段，他们可能会征求相关受影响方对草案的反馈意见。

评论(Comment)

在此阶段，FTP正式分发给Fuchsia工程组织进行评论。 该提案的作者应征求反馈意见，特别时可能受该提案的影响者的意见。

目前，建议保留至少一周的时间用于评论，但需评审人员酌情决定。 对于争议较少的FTP而言，缩短时间可能是合理的，等待来自特定个人或团体的反馈则需要增长时间。

任何人都可以在FTP上发表评论。 阻止性评论不会阻止评审过程中接受或拒绝的特定结果，但评审人员需要确认评论中给出的反馈作为最终FTP的一部分。

评审(Review)

在本阶段，将审查FTP以及所有未解决的的评论。

该提案由Fuchsia的FIDL团队成员（非正式地称其为制琴师）以及他们认为任何适合在此过程中包括在内的或委派的人进行审核。 例如，在决定特定语言的绑定时，他们可以包括该语言的专家。 如有必要，有争议的决定可以像Fuchsia中的任何其他技术决定一样逐步升级。

评审最终可以有三个结果。

首先，可能存在做出决定所需的悬而未决的问题或反馈。 在这种情况下，FTP将返回评论(Comment)阶段。

其次，该提案可能会被拒绝(Rejected)，评审人需提供理由来解释原因。

第三，它被接受(Accepted)。

拒绝(Rejected)

被拒绝的FTP是工程决策中宝贵记录。 FTP被拒绝时，评审人应将拒绝的依据添加到FTP中。 然后将FTP复制到FTP的所有公共记录中以供后来者使用。

给出的依据应该在以下两个意义上是可诉讼的。

首先，如果要接受这个提议，有什么是必须修改的？

其次，依据应解决评论阶段提出的所有阻止性意见。

已接受(Accepted)

已接受的FTP在评审后还会附加一个依据部分，并会收到Bug跟踪。

拒绝时依据的约束条件同样适用于接受时的依据，特别是任何阻止性意见都需要被处理掉。

然后，FTP将进入实现修改的赛道。

已实现(Implemented)

在这个阶段，该提案已落地完成。 所有代码都已更改，教程（英文原文）已更新，该bug也标记为已完成。 FIDL完成了一次趋于更完美的调整。

该过程的最后一步是将Markdown版本的FTP提交到Fuchsia源码树中，并且无论提案是否被接受都需如此，因为能够引用已经评估过但被最终拒绝的提案是该流程价值的重要组成部分。

文档和示例

本文档(FTP-001)是此流程的首个范例。

理想情况下，模板以及此本提案的最终版本是说明该流程的足够充分的文档。

向后兼容性

n/a

性能

n/a

安全性

我相信该计划将为安全审查带来适当的好处。 目前，FIDL的所有更改都是通过聊天或代码评审进行的，所以在FTP计划提出之前没有决策的纸质记录。

测试

谈论计划成功总是比谈论测试该计划更容易。

这个流程成功的直接标准是，是否通过这个流程来处理改变FIDL的几个未解决的想法，而且没有把事情搞得很麻烦。

从长期看来，一个成功的指标是旧的FTP是否经常被引用。

缺点，替代方案和未知事件

通过稍微正式的流程来系列化对FIDL的更改只需要很少的成本。 我认为，与实现任何更改所需的工程工作（特别是当我们的ABI固定下来，以及破坏性的更改变得更加困难时）和记录这些决策的回报相比，该成本实际上是很小的。

我考虑过的最大替代方案是一个更开放的版本。 目前，评论和审核流程仅对Google员工可见或开放。 我相信这是目前看来正确的决定，同时我们也着眼于在未来进行重新评估。

我还想知道是否有更好的方式来获取评论而不是通过Google Docs，特别是在将FTP“冻结”为接受或拒绝状态时。

因此，我猜想在采用这个流程之前，我们可能想要一个这样的版本来获取做出的关于FIDL的决定。

最后，我想知道关于接受或拒绝的标准的正式性。 我相信，在早期FTP的决策依据的帮助下，如果需要的化，FTP可以演变得更加正式。

现有技术和参考文献

一些开源编程语言已有的增强性提议或RFC机制。

特别是，在起草本文档时我已对Python PEP流程和Rust RFC流程进行了大量的研究。