| 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 的調校更為完美。
流程的最後一個步驟，是將 Markdown 版的 FTP 部署到 Fuchsia 樹狀結構中。無論提案是否已獲接受，這項規定都適用，因為能夠指出已考慮但遭拒的提案，是這個程序價值的重要部分。
說明文件和範例
這份文件 (FTP-001) 就是這個程序的第一個例子。
理想情況下，範本加上這份提案的最終版本，就足以提供足夠的程序文件。
回溯相容性
不適用
成效
不適用
安全性
我認為這項計畫將帶來一些好處，因為它提供了一個安全性審查的場所。目前，我們會透過即時通訊或程式碼審查來討論 FIDL 的所有變更。在 FTP 程序之前，沒有任何紙本記錄。
測試
討論這項計畫的成功情況，比討論測試情況更容易。
這個程序的立即成功標準，將是變更 FIDL 的幾個優異想法是否能順利通過程序，而不會造成負擔。
長期成效指標之一，就是是否定期指向舊 FTP。
缺點、替代方案和未知事項
透過稍微正式的程序將變更序列化為 FIDL，會產生一些成本。我認為，與實施任何變更所需的工程工作 (尤其是當 ABI 變得更嚴格，且變更會造成重大影響時) 相比，以及記錄這些決策所帶來的效益相比，這項成本其實很低。
我考慮的最大替代方案是更開放的版本。目前只有 Google 員工可查看或使用留言和審查程序。我認為這是目前正確的決定，並且會在日後重新評估。
我也想知道，除了 Google 文件之外，還有沒有更好的方式來擷取評論，尤其是在將 FTP 設為已接受或拒絕狀態的「凍結」時。
我認為我們可能需要一個版本，用於擷取採用這項程序前，針對 FIDL 所做的決策。
最後，我想知道接受或拒絕條件的正式程度。我相信，在初期 FTP 的決策理由協助下，這項功能可以隨時間演進，變得更加正式。
既有技術與參考資料
幾種開放原始碼程式設計語言都有增強提案或 RFC 機制。
在起草本文件時，我特別參考了 Python PEP 程序和 Rust RFC 程序。