| 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 和所有未完成的評論。
提案會由 Fuchsia FIDL 團隊成員 (非正式稱為製琴師) 審查，以及他們認為適合納入或委派的任何人。舉例來說，在決定該語言的繫結時，他們可能會納入特定語言專家。如有必要，爭議性決策可像 Fuchsia 中的任何其他技術決策一樣升級。
審查結果最終會有三種可能。
首先，我們可能需要您提供未解決的問題或意見回饋，才能做出決定。在本例中，FTP 會移回「註解」階段。
其次，提案可能會遭到拒絕，審查人員會說明拒絕原因。
第三種是「已接受」。
已遭拒
遭拒的 FTP 是工程決策的寶貴記錄。如果遭到拒絕，請在 FTP 中加入拒絕原因。FTP 隨後會複製到所有 FTP 的公開記錄，以供後代參考。
所提供的理由應可採取行動，具備以下兩種意義。
首先，世界必須做出哪些改變，才能接受這項提案？
其次，理由應說明在意見徵詢期間提出的任何阻礙性意見。
已接受
通過審查的 FTP 也會附上理由，並收到追蹤錯誤。
接受理由與拒絕理由適用相同的限制。請特別注意，必須解決任何會造成封鎖的註解。
接著，您就可以開始實作變更。
已實行
此時提案已完成。所有程式碼都已變更。教學課程已更新，錯誤標示為「已完成」。FIDL 的調整更臻完美。
最後一個步驟是將 FTP 的 Markdown 版本放入 Fuchsia 樹狀結構。無論提案是否獲得接受，這項規定都適用，因為能夠指出已考慮但遭拒的提案，是這項程序價值的重要部分。
說明文件和範例
這份文件 (FTP-001) 是這個程序的第一個例子。
理想情況下，範本加上這項提案的最終版本，就足以做為程序的說明文件。
回溯相容性
不適用
效能
不適用
安全性
我相信這項計畫能提供安全審查的場所，帶來些許好處。目前，所有 FIDL 變更都會透過即時通訊或程式碼審查討論。在 FTP 程序之前，沒有任何紙本記錄。
測試
相較於測試這項計畫，談論成功似乎更容易。
這項程序的立即成功條件是，多項待處理的 FIDL 變更提案是否能順利完成程序，且不會造成負擔。
長期成效指標之一是舊 FTP 是否定期指向。
缺點、替代方案和未知事項
透過稍微正式的程序將變更內容序列化至 FIDL，會產生少量費用。我相信相較於實作任何變更所需的工程工作 (尤其是當我們的 ABI 強化且重大變更變得更加困難時)，以及記錄這些決策所帶來的效益，成本實際上很小。
我考慮過的最大替代方案是更開放的版本。目前只有 Google 員工可以查看或參與評論和審查程序。我相信這是目前正確的決定，但日後會重新評估。
此外，我還想知道是否有比 Google 文件更好的方式來擷取註解，特別是在將 FTP「凍結」為接受或拒絕狀態時。
我懷疑我們可能需要一個版本，記錄採用這個程序前對 FIDL 做出的決策。
最後，我想知道接受或拒絕條件的正式程度。我相信在早期 FTP 的決策原理協助下，這項機制日後可視需要發展成更正式的程序。
既有技術和參考資料
許多開放原始碼程式設計語言都有強化提案或 RFC 機制。
撰寫這份文件時，我特別參考了 Python PEP 程序和 Rust RFC 程序。