| 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 已標示化版本進入 Fuchsia 樹狀結構。無論提案是否被接受 (因為該提案能夠指出，遭到拒絕的提案是此程序價值的一大部分)，無論提案是否獲得接受都一樣。
說明文件與範例
本文件 (FTP-001) 是這個程序的第一個範例。
在理想情況下，範本和本提案的最終版本就足以進行這項程序。
回溯相容性
不適用
效能
不適用
安全性
我認為這項計畫對於提供安全性審查的空間來說可大有助益。目前，所有對 FIDL 的變更都會透過即時通訊或程式碼審查進行討論。在 FTP 處理之前沒有紙本資料軌跡。
測試
比起針對這個計畫進行測試，我們可以更輕鬆地討論成功。
此程序的立即成功標準將是變更 FIDL 的幾項傑出構想是否能順利完成程序，而不受干擾。
其中一個長期成功指標是是否定期指定舊的 FTP。
缺點、替代方案和未知
透過稍微正式的程序對 FIDL 進行序列化會產生少許費用。我認為成本其實相當有限，相較於導入任何變更所需的工程工作 (尤其 ABI 更加困難和破壞性變更會更加困難)，並且可收獲記錄這些決定的回報。
我考慮的最佳替代方案是較開放的版本目前，只有 Google 員工可以查看或開放留言和審核程序。我認為這是目前正確的決定，並應在未來重新評估。
我也想知道，擷取註解的方法是否比 Google 文件更好，尤其是在「凍結」FTP 進入已接受或遭拒狀態時。
我認為我們可能需要某個版本，能擷取在採用此程序之前對 FIDL 做出的決策。
最後，我想知道接受或拒絕標準該如何正式開始。在早期 FTP 的決策原因的協助下，這個過程隨著時間推進，可以變得更加正式。
先前的圖片和參考資料
一些開放原始碼程式設計語言都有強化提案或 RFC 機制。
具體來說，我在草擬本文件時仔細探討了 Python PEP 程序和 Rust RFC 程序，