RFC-0049：FIDL 調整程序演進

摘要

我們建議對 FTP 程序進行各種調整：

• 最重要的是將審查與決策分開；
• 推出作者撤銷 FTP 的方式。
• 提供有關需要 FTP 的規範；最後
• 說明其他貢獻 FIDL 的方式。

提振精神

我們在一年多前推出 FIDL 調整程序。綜合來說，這個流程成功改善了促使其誕生的三個動機和目標：仔細考量設計限制；每個決策背後的想法都公開透明，並記錄下來；最後，這個流程提供了一個討論構想 (有時會進行深入討論) 的論壇，同時也能讓討論告一段落。

最終結果是持續的變更速度，以及可重複執行的應對手冊。迄今已收到 48 份提案 (稱為「FTP」)，其中 25 份已接受，9 份遭拒 (皆已正確記錄拒絕原因)。

不過，就像所有事情一樣，這項功能仍有改進空間。具體來說，我們會檢查以下項目：

• 如何最佳地審查 FTP？
• 何時可以撤銷 FTP？
• 哪些變更需要使用 FTP？
• 還有哪些方式可以協助設計和改進 FIDL？

設計

查看 FTP

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

最常見的審查方式是親自開會。會議一開始，FTP 作者會簡報自己的設計。會議主持人 (通常是今天的 FIDL 負責人) 接著會處理設計文件中的意見，可能會先設定要討論的「未解決項目」簡短議程。

與「eng 審查程序」不同，在會議期間解決未解決的項目 (並記錄備忘錄，稍後納入 FTP)，以及由 FIDL 負責人結束會議並決定是否接受或拒絕 FTP，都是常見的做法。

會議結束前就做出決定的期望，以及 Fidl 主管同時擔任主持人和決策者的雙重角色，都造成了摩擦：在 FTP 會議中，參與者會感受到壓力，希望能表達自己的意見，並在最後一刻做出設計決策，以便迅速通過經修訂的 FTP。

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

此時，我們會審查 FTP 和所有未處理的評論。

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

[新增] 通常會在一次或多次「FTP 審查會議」的面對面會議中進行審查。如有需要，也可以使用非同步通訊進行審查)。

作者會在 FTP 審查會議一開始時介紹自己的設計。接著，主持人會處理 FTP 中的註解，要求在文件中留下註解的使用者提出意見回饋。

[新增] 理想情況下，主持人和講者應為不同人。協調員的目標是確保討論到設計的所有面向，並確保會議順利進行。理想情況下，主持人不會對結果有特別的利益關係，以免產生偏見的觀感，而講者則會對所提案的設計有隱含的利益關係。

[新增] 我們不一定需要在會議中針對每則意見回饋做出結論，或討論每則留言 (例如，如果有大量留言，或多則留言提到同一個潛在問題)。相反地，講師應盡量提供演講者廣泛的意見回饋，而非引導每個辯論重點得出結論。未解決的問題可能會在後續審查階段或決策期間解決。

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

首先，我們可能需要解決未解決的問題或取得意見回饋，才能做出決定。在這種情況下，FTP 會移回「註解」階段。

其次，提案可能會遭到拒絕，審查員會提供原因。

第三，可能會接受。

在「Review」步驟後新增「Decision making」步驟：

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

最終結果可能有三種。

首先，我們可能需要解決未解決的問題或取得意見回饋，才能做出決定。在這種情況下，FTP 會移回「註解」階段。

其次，提案可能會遭到拒絕，審查員會提供原因說明。

第三，可能會接受。

通常，決策地點會是會議形式。也可能是電子郵件執行緒，或在審查會議中發生。

撤銷 FTP

有時，FTP 作者會希望撤銷自己的 FTP。

在「Comment」步驟後方新增「Withdrawn」步驟：

撤銷的 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 管理
• 設計原則
• 語言文法
• 類型系統
• 通訊協定語意
• 線路格式
• 繫結規格

以下列舉幾個 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 和繫結中)。

除了 FTP 之外，也為 FIDL 提供貢獻

Fuchsia FIDL 團隊的目標是「促進 FIDL 相關的協同合作和包容性」，具體來說，就是要確保「Fuchsia 團隊整體能感受到，他們可以聽到有關粗糙邊緣的意見，且非 FIDL 團隊成員的貢獻能獲得適當的指導和支援，以便落實，或在早期以合理理由遭到拒絕」。

撰寫 RFC 通常需要大量工作，並瞭解解決方案空間，才能針對替代方案做出適當的特定設計選擇。FTP 程序也相當繁重，而且可能會讓人感到不悅。因此，FTP 程序本身並不會協助達成協作目標。

其他貢獻方式如下：

• 在 Fuchsia FIDL 團隊聊天室中討論用途和問題。團隊成員都會密切關注討論內容，而且這個論壇中的討論串經常會導致小幅或大幅變更，或改變優先順序。

• 參與 Fuchsia API 審查。這個場合是瞭解具體用途，以及評估各種 FIDL 功能如何結合以支援這些用途的關鍵。我們透過辨識 API 設計模式，推動了多項演進，這些模式可透過功能調整或全新功能加以強化。

• 向 Fuchsia FIDL 團隊回報錯誤。

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

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

• 設計其他方法的原型。

• 以「20% 時間」加入 FIDL 團隊，並處理 FIDL 團隊指派的專案。

所有這些做法都可能導致擷取清晰的問題陳述式、直接變更 FIDL 或轉換為 FTP。

導入策略

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

人體工學

沒有影響。

說明文件和範例

請參閱導入策略。

回溯相容性

沒有影響。

成效

沒有影響。

安全性

沒有影響。

測試

沒有影響。

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

雖然有許多方法可以修改程序，但我們認為建議的變更是溫和的迭代，預期可帶來淨效益。我們預期這項程序日後會有所演進。

既有技術與參考資料

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