RFC-0049：FIDL 調整程序演進

RFC-0049：FIDL 調整程序演進
狀態	已接受
區域	FIDL
說明	我們建議對 FTP 程序進行多項演變，包括將審查與決策制定程序分開、讓作者撤回 FTP、提供需要 FTP 的指南，以及說明其他對 FIDL 做出貢獻的方式。
作者	pascallouis@google.com
提交日期 (年-月-日)	2019-11-20
審查日期 (年-月-日)	2019-12-19

摘要

我們建議對 FTP 程序進行多項演變：

• 最重要的是將審查與決策程序分開；
• 提供作者撤回 FTP 的方式；
• 提供需要 FTP 的內容指引；最後
• 說明其他貢獻 FIDL 的管道。

提振精神

FIDL 調整程序已推出一年多。就各方面而言，這個程序已成功改善促成其建立的三個動機和目標：仔細考量設計限制；每項決策背後的思維都公開透明，並記錄在案；最後，這個程序提供討論想法的論壇 (有時會深入討論)，同時也提供結論。

最終結果是持續快速地進行變更，並反覆運用應對手冊。截至目前為止，我們已收到 48 項提案 (稱為「FTP」)，其中 25 項已獲准，9 項遭拒 (所有拒絕理由都已妥善記錄)。

但就像所有事物一樣，仍有進步空間。具體來說，我們會查看：

• 如何有效審查 FTP？
• 何時可以撤銷 FTP？
• 哪些變更需要進行 FTP？
• 還有哪些方式可以協助設計及演進 FIDL？

設計

查看 FTP

目前程序並未說明應如何審查 FTP，僅指出「提案由 Fuchsia FIDL 團隊成員 (非正式稱為製琴師) 審查，以及他們認為適合納入或委派給程序的任何人」。

最常見的 FTP 審查論壇是實體會議。會議開始時，FTP 作者會介紹設計。會議主持人 (通常是目前的 FIDL 負責人) 接著會處理設計文件中的註解，可能從設定要討論的「待處理事項」快速議程開始。

與「工程審查程序」不同，會議期間通常會解決未完成事項 (並記錄下來，稍後納入 FTP)，且會議結束時，FIDL 負責人會決定接受或拒絕 FTP。

會議結束前必須做出決策，加上 FIDL 領導人同時擔任主持人與決策者，造成了摩擦：FTP 會議期間的匆忙感、參與者感受到必須發聲的壓力，以及為了快速修訂 FTP 而在最後一刻做出粗略的設計決策。

為解決這個動態不佳的問題，我們修改了「審查」步驟，並新增明確的「決策」步驟。部分用語借用自英文審查程序。 「檢查」步驟變更如下：

此時會審查 FTP 和所有未完成的評論。

提案會由 Fuchsia FIDL 團隊成員審查 (由 fuchsia.git 存放區中的 OWNERS 檔案定義，非正式名稱為 luthiers)，以及他們認為適合納入或委派的任何人。舉例來說，在決定該語言的繫結時，他們可能會納入特定語言專家。如有必要，爭議性決策可以像 Fuchsia 中的任何其他技術決策一樣升級。

[ADD] 最常見的情況是，審查會在一次或多次面談中進行，也就是「FTP 審查會議」。(如果合適，審查也可以透過非同步通訊進行)。

FTP 審查會議開始時，作者會先介紹設計。然後，主持人會逐一查看 FTP 中的註解，並請在文件中留下註解的人員說明意見回饋。

[ADD] 理想情況下，主持人與簡報者應為不同人。主持人負責確保設計的各個層面都獲得討論，並維持會議流程。理想上，主持人不應對結果有任何利害關係，以免產生偏見，而簡報者則對自己提出的設計有隱含的利害關係。

[ADD] We don't necessarily need to come to closure on every piece of feedback during the meeting or discuss every last comment (e.g., if there are a large number of comments or several comments are getting at the same underlying issue). 主持人應盡量提供各種意見回饋給講者，而非針對每個爭議點得出結論。待處理的開放式問題可能會在後續審查階段或決策期間解決。

審查結果最終會有三種可能。

首先，您可能還有問題或意見需要解決，才能做出決定。在本例中，FTP 會移回「註解」階段。

第二，提案可能會遭到拒絕，審查人員會提供拒絕原因。

第三，可能獲得核准。

「決策」步驟會新增在「審查」步驟之後：

Fuchsia FIDL 團隊成員 (由「Owners」檔案定義，最終決策者為 Fuchsia FIDL 團隊負責人) 會在五 (5) 個工作天內決定審查結果。

最終可能會有三種結果。

首先，您可能還有問題或意見需要解決，才能做出決定。在本例中，FTP 會移回「註解」階段。

第二，提案可能會遭到拒絕，審查人員會說明原因。

第三，可能獲得核准。

通常決策會以會議形式進行。也可能是電子郵件執行緒，或是在審查會議期間發生。

撤回 FTP

有時，FTP 的作者會想撤回 FTP。

「已撤銷」步驟會新增在「註解」步驟之後：

已撤銷的 FTP 是工程發想的寶貴記錄。作者撤回 FTP 時，必須在 FTP 中加入撤回理由。FTP 隨後會複製到所有 FTP 的公開記錄，以供後代參考。

撤銷理由由 FTP 作者撰寫，可能與 Fuchsia FIDL 團隊成員共同撰寫。

理由應可透過下列兩種方式採取行動。

作者在 FTP 過程中學到什麼，因而提議採用替代設計？

有哪些替代方案可取代已停用的 FTP？

需要 FTP 的條件

我們瞭解並非所有「FIDL」變更都需要 FTP。如果只是在 fidlc 中進行小規模重構，應該不需要設計文件。另一方面，導入新的訊息版面配置或變更線路格式，絕對需要 FTP。

我們認為變更超過多少門檻時，就需要 FTP？我們遵循的一般規則如下：

如有下列情況，變更內容「必須」經過 FTP 程序：

1. 解決方案空間很大，也就是說，變更只是許多可能不錯的其他解決方案之一，而且很難做出設計取捨；

2. 變更影響重大，也就是說，變更大幅修改 FIDL 的行為，可能對許多或所有 FIDL 使用者造成風險；

3. 變更範圍廣泛，也就是說，變更會影響足夠數量的 FIDL，因此需要仔細判斷是否可能造成重大影響。

舉例來說，變更下列區域時可能需要 FTP：

• FIDL 管理
• 設計原則
• 語言文法
• 字型系統
• 通訊協定語意
• Wire 格式
• 繫結規格

以下列舉幾個 FTP 異動範例，以及異動的區域：

• RFC-0047：表格：
  型別系統) 推出新的記錄式資料表示方式，首次使用信封。
  線路格式) 表格和信封的新線路格式。
  繫結規格) 建議遵循的繫結 API。

• RFC-0023：通訊協定的組合模型：
  語言文法) 取代介面語法，使用通訊協定語法。
  通訊協定語意) 明確說明通訊協定組合的語意，包括支援缺少「is-a」關係。
  繫結規格) 禁止繫結利用多型來模擬組合。
  

• RFC-0027：使用多少，就付多少：
  設計原則) 導入新的設計原則。
  FIDL 治理) 明確要求將新推出的設計
  原則納入 FTP 程序。

• RFC-0024：強制來源相容性：
  FIDL 管理) 修改 FTP 範本，加入來源相容性附註。
  繫結規格) 繫結的自舉來源相容性需求。
  

• RFC-0049：FIDL 調整程序演進，即這項變更：
  FIDL 管理) 旨在為 FTP 程序提供額外指引，
  並認可貢獻 FIDL 的替代方式。

相較之下，以下列舉的變更並未達到 FTP 標準：

• 建立新的 FIDL 繫結 (例如 LLCPP 繫結)：
  FIDL 的設計宗旨是支援多種相互互動的實作方式。
  建立新繫結是預期行為，且不需要 Fuchsia FIDL 團隊的任何批准。
  

• 明確參照列舉成員¹：
  變更前支援 my.library.MY_ENUM_MEMBER，但現在已改用明確語法 my.library.MyEnum.MY_ENUM_MEMBER。儘管變更了語言文法，但這項變更實際上是修正先前存在的功能錯誤。如果程式庫同時有列舉成員 CLASHING_NAME 和常數 CLASHING_NAME，則參照任一者都會造成模稜兩可的情況，而 fidlc 會採用不穩定的型別解析規則來打破僵局。成員的範圍規則維持不變，成員的範圍仍為其宣告，且 fidlc 和所有繫結都會遵守這項規則。

• 實作意圖：將類型建構作業從原始轉換延後至扁平轉換：
  雖然類型系統的實作方式經過重新設計，但沒有任何可觀察到的變更。這是重構作業。

• 實作意圖：變更「訊息」的表示方式： 雖然 JSON IR 會受到這項變更影響，但這項表示方式變更會讓先前需要繫結 (標頭形狀) 隱含瞭解的特定概念，現在明確瞭解。同樣地，沒有可觀察到的變化，且除了程式碼結構 (在 fidlc 和繫結中) 之外，沒有任何影響。

貢獻 FIDL 相關內容 (不限於 FTP)

Fuchsia FIDL 團隊的目標是「促進 FIDL 相關的協作和包容性」，具體來說，就是要確保「Fuchsia 團隊整體都能暢所欲言，並適當引導和支援非 FIDL 團隊成員的貢獻，以便順利完成，或在早期就因故遭到拒絕，並附上理由」。

撰寫 RFC 通常需要大量工作，且必須瞭解解決方案空間，才能適當說明相較於替代方案，為何選擇特定設計。FTP 程序也相當繁重，本身就可能令人不悅。因此，FTP 程序本身無法協助達成協作目標。

其他貢獻方式包括：

• 在 Fuchsia FIDL 團隊聊天室討論用途和問題。團隊所有成員都會密切關注對話，而且論壇中的討論串經常會促成大小變更，或是優先順序的轉移。

• 參與 Fuchsia API 審查。這個場所是瞭解具體使用案例，以及評估各種 FIDL 功能組合支援這些案例的成效時，不可或缺的要素。我們發現 API 設計模式可透過功能調整或全新功能來強化，因此推動了多項演進。

• 向 Fuchsia FIDL 團隊回報錯誤。

• 描述問題陳述，並與 Fuchsia FIDL 團隊和整個 Fuchsia 團隊合作，探索可能的解決方案。

• 說明可能的解決方案，並與 Fuchsia FIDL 團隊和整個 Fuchsia 團隊合作評估。

• 設計替代做法的原型。

• 加入 FIDL 團隊，成為「20% 員工」，並負責 FIDL 團隊指派的專案。

這些都有助於清楚掌握問題陳述、直接變更 FIDL，或轉為 FTP。

導入策略

更新 FIDL 調整提案頁面。廣泛宣傳這項異動。進行審查時，請落實變更。

人體工學

沒有影響。

說明文件和範例

請參閱導入策略。

回溯相容性

沒有影響。

效能

沒有影響。

安全性

沒有影響。

測試

沒有影響。

缺點、替代方案和未知事項

雖然有許多方法可以修正程序，但我們認為提議的變更只是小幅迭代，預計能帶來淨效益。預計未來會持續演進。

既有技術和參考資料

許多。其中一個是 Fuchsia 採用的「工程審查」程序。