RFC-0220：樹狀結構中的未來產品

RFC-0220：樹狀結構內產品的未來
狀態	已接受
區域	一般 軟體組裝
說明	提案：簡化開放原始碼 //products 目錄中的產品設定組合。
問題	121898
Gerrit 變更	831920
作者	wittrock@google.com hjfreyer@google.com
審查人員	aaronwood@google.com abarth@google.com amathes@google.com ddorwin@google.com dworsham@google.com fmeawad@google.com hjfreyer@google.com jasoncampbell@google.com neelsa@google.com nicoh@google.com
提交日期 (年-月-日)	2022-04-06
審查日期 (年-月-日)	2022-06-13

摘要

這項提案旨在簡化開放原始碼 //products 目錄中的產品設定組合。

提振精神

//products 目前包含十個產品定義。自這些產品定義建立以來，Fuchsia 已大幅進化，且這些產品的使用者也變得分散。有些產品只有幾位使用者或用途，或是具有獨特功能，例如僅存在於該產品中的 UI 堆疊。如要變更跨切面功能 (例如產品組合、建構系統或圖形/網路堆疊)，就必須考量每項產品及其差異。這會耗費開發人員的時間和心力，並拖慢平台的演進速度。

//products 目錄也沒有明確的路線圖或目的聲明。README 無法清楚說明目錄中產品的存在原因、產品適用對象或維護者。由志願者組成的臨時性群組負責維護產品定義並提供動態饋給，但沒有明確的職責。

與平台來源樹狀結構中具有特定用途的產品相比，Fuchsia 應偏好較少數量的嚴格範圍產品定義，這些定義可提供參考實作項目和範例，說明如何在樹狀結構外建立產品 (OOT)。

是時候為 //products 目錄設定路線圖，並大幅減少 Fuchsia 產品定義的使用者群分散現象。

利害關係人

• 基礎設施
• Fuchsia 工程委員會
• 產品管理
• 我們建議修改或移除的產品使用者
  • 工作站
  • 終端機
  • Core
• 軟體組裝
• 建構

協助人員： rlb@google.com

審查者：

依字母順序排列

• aaronwood@google.com
• abarth@google.com
• amathes@google.com
• ddorwin@google.com
• dworsham@google.com
• fmeawad@google.com
• hjfreyer@google.com
• jasoncampbell@google.com
• neelsa@google.com
• nicoh@google.com

諮詢：

列出應審查 RFC 但不需要核准的人員。

• 軟體組裝團隊
• 建立團隊
• 成效團隊
• Chromium 團隊
• 驅動程式開發團隊
• 啟動團隊

社會化：

這份 RFC 以文件形式在內部與許多組織成員進行交流，包括列為「諮詢對象」的團隊，以及 Fuchsia 工程委員會。

詞彙解釋

系統

一個系統是一組影像（茲比edit，維基百科edit以及可選的自由體積edit) 指定用於目標上的單一啟動槽。這代表可開機的 Fuchsia 映像檔，但不包含我們想在實際環境中刷入目標的所有內容 (例如復原映像檔)。

如要進一步瞭解開機磁碟和可刷新的映像檔，請參閱 RFC-0115。

產品

根據現有文件的說明：「產品定義了建構作業產生的軟體設定。最重要的是，產品通常會定義提供的使用者體驗類型，例如使用者可能會看到哪種圖形殼、是否包含多媒體支援等等。」

在產品組合程序的輸出內容中，產品會定義一或多個系統的組合 (在 A、B 和/或 R 槽中)，這些系統可用於指定目標。舉例來說，產品映像檔可能包含核心映像檔、FVM、vbmeta、復原映像檔、復原 vbmeta 和系統啟動載入程式映像檔。

主機板

根據現有文件的說明：「板定義了版本產生的架構，以及版本要執行的裝置主要功能。這項設定會影響所納入的驅動程式，也可能影響裝置專屬的核心參數。」

Fuchsia 建構參數會由 (產品、電路板) 元組指定。這組參數完整說明建構系統必須完成的工作，才能產生可刷新的產品映像檔。

目標

• 盡量減少 Fuchsia 團隊必須支援的產品定義數量，以便盡量減少開發人員和基礎架構的負載

• 盡量減少現有產品定義現有使用者的遷移工作量，讓這些產品的現有使用者能輕鬆遷移至 core 和 terminal

• 移除不再代表 Fuchsia 平台預期用途的產品定義，或使用已淘汰的設定

• 簡化產品定義，方便維護

• 對於保留的產品定義 (bringup 除外)，請實作建構類型，以便實際產品在實作自身版本時，能參照適當的建構類型

• 定義新產品定義的使用方式、新增時間，以及新增全新產品定義的條件

• 請勿從根本上變更產品的定義方式，或 (如有可能) 變更板塊的定義方式。讓中期範圍可行

需求條件

• 我們必須支援核心和新電路板開發作業，而無須定義自訂產品

• 所有產品都必須在基礎架構中自動測試

• //products 中的所有產品都應以 SDK 隨附映像檔的形式發行，並且在樹狀結構內外都能正常運作

• 避免需要測試才能將內容新增至平台，以便在產品上執行。測試應可將其依附元件納入自己的套件中，做為子套件。舉例來說，//bundles/buildbot:foo 應只包含測試，且不得在產品或平台定義中新增任何內容。

非目標

• 重新調整或重新定義板、建構類型和產品的互動方式。這個 RFC 應盡可能著重於 //products 的內容和用途。

• 除了變更產品定義，還能變更開發工作流程。本 RFC 只涉及產品定義的內容。

設計

本文件中的關鍵字「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」應依 IETF RFC 2119 所述進行解讀。

目前 //products 中有十個產品定義。我們會隨著時間移除其中八個產品定義，保留兩個 (minimal、bringup)，並新增一個：workbench。我們目前只會建立 minimal 和 workbench 的 _eng 建構類型，但如果有需要，我們可能會在日後新增 _user 和 _userdebug 建構類型。

許多現有的定義都是為了支援測試流程，並包含其特定套件和設定，因為測試會直接仰賴系統映像檔中包含的服務，而不是在自己的套件中提供相關依附元件。

我們打算讓大多數 Fuchsia 測試在 minimal_eng 上執行，因為大多數 Fuchsia 測試都應與所有相關元件一起密封封裝。

如果特定測試需要執行時，同時依賴系統直接提供的服務 (而非在其專屬套件中執行的版本)，則應避免建立通用的樹狀結構內產品來測試。該測試應在要測試功能的產品上執行，或者應定義要執行的私人樹狀結構外產品定義。我們將不再建立及維護通用的「測試產品」，以便測試所有可能的功能。我們建議您不要使用僅供測試的產品，而是在對客戶或開發人員更有用的產品中加入測試支援功能。

也就是說，根據預設，並非 fuchsia.git 中的所有功能都會存在於樹狀結構內產品的基本設定中。我們應該盡量建立可在現有產品上密封執行的整合和單元測試，而非將所有功能新增至平台支援的產品，並永久支援該產品。

要保留的產品定義

bringup.gni

目前大多由核心開發人員使用。bringup 可用於測試核心和核心驅動程式，並在新的電路板上進行開發。

我們打算將 bringup 的用途和內容維持原樣，但會將其移至產品組合中使用。我們不再將 bringup 設為所有已定義產品的「基礎類別」，因為啟動具有某些功能，並非適用於所有產品。

要新增或重新用途的產品定義

//products 中其餘的產品定義將由 Fuchsia 架構和軟體組合團隊共同擁有。日常維護工作將由 Software Assembly 執行。

minimal - keep, make really minimal

意圖是「我們仍稱為 Fuchsia 的最小東西」。根據定義，我們仍稱為 Fuchsia 的最小項目是可執行以下操作的系統：

• 啟動至使用者空間
• 執行元件管理服務和元件
• 使用無線下載更新系統更新自身
  • 這表示儲存空間和網路功能運作正常，且驅動程式由主機板提供

這項產品在 Fuchsia 專案中的用途主要是執行含有所有依附元件的密封封裝測試。它也可以做為系統測試的基礎，這些測試並非密封的，但只依賴其中包含的一小組 Fuchsia 服務。

我們會將 minimal 定義為 _eng 建構類型，目前不會建立 _user 或 _userdebug 版本的 minimal。產品組合中的所有產品定義都必須是 _eng、_userdebug 或 _user 之一。因此，本文件其餘部分中所有 minimal_eng 和 minimal 的參照皆相同。

minimal 將支援下列項目：

• 元件
• 套件和無線更新系統的功能
• 透過 Fastboot 刷新系統
• 驅動程式架構和極少數的驅動程式 (理想情況為零；我們應盡量在板子定義中新增驅動程式，而不是在產品定義中新增，除非這些驅動程式在 所有 Fuchsia 產品中皆為必要)
• 記錄
• 網路 (如果主機板沒有其他網路能力，可能會包括 USB CDC 乙太網路)
• 儲存空間
• 支援工作階段，但未指定工作階段
  • 系統會在 eng 版本上使用 ffx session launch 在執行階段新增工作階段。
• 上述功能的大小限制支援

minimal_eng 是建議的設定，可用於執行測試，且由於是 _eng 設定，因此會包含以下項目 (但不全數列出)：

• SSH 支援
• 支援遠端控制服務
• 測試管理員

我們不打算納入下列內容：

• 透過 zedboot 提供鋪面支援 (不過，分區映像檔安裝工具 服務需要在執行中的 Fuchsia 映像檔上運作，才能啟用 OTA)
• 圖形支援
• 音訊支援
• 輸入支援
• 虛擬化支援
• WLAN 支援
• 藍牙支援

注意：雖然 minimal 不會在基礎層級提供這些功能的支援，但仍可在密封封裝的測試中測試 minimal_eng 版本，因為所有 _eng 產品版本都包含測試支援功能。舉例來說，圖形測試可以將 Fuchsia UI 子系統和硬體假裝項目 (由 test_ui_stack 提供) 做為子包，並在 minimal_eng 上執行，即使畫面上不會顯示任何圖形也一樣。我們建議您在可行情況下，將所有測試都執行在 minimal_eng 上，而非 workbench，因為 minimal_eng 較小，因此建構時間較短，且更容易進行偵錯。

何時應將平台元件新增至 minimal？

平台開發人員應在 minimal 支援 minimal 產品的核心目標時，將元件新增至 minimal 中包含的組合式輸入內容。舉例來說，Fuchsia 的新預設檔案系統應新增至 minimal，因為 OTA 更新需要檔案系統，而 minimal 應使用預設的 Fuchsia 檔案系統。如果新驅動程式庫架構適用於所有 Fuchsia 產品，應將其新增至 minimal。新的顯示卡驅動程式庫或控制系統不應新增至 minimal，因為並非所有 Fuchsia 系統都需要顯示卡才能啟動或更新系統。

我們有兩種壓力測試，可確切判斷應將特定元件納入 minimal_eng 的情況：

1. 該元件是否應包含在 _eng 建構類型的所有 Fuchsia 產品中？
2. 沒有 minimal 是否無法使用？

如果平台元件不應納入最小化，可能仍適合 workbench。

minimal地區的駕駛人

如果在所有電路板上支援 OTA 或執行元件管理員至關重要，我們應在 minimal 的平台設定中納入驅動程式庫堆疊支援功能。也就是說，即使執行 minimal 的電路板支援藍牙，我們也不應在產生的設定中加入該驅動程式庫堆疊，因為產品不需要該堆疊。

這表示在最終映像檔中包含的驅動程式組合，是產品要求的功能與主機板硬體支援功能的交集。這項交集功能目前由軟體組裝團隊開發中。

工作檯

workbench 將是本機開發作業的產品設定，可執行無法或不應密封包裝的大型測試，並使用 minimal 支援的 Fuchsia 平台的更多部分。它就像是字面上的「工作台」，可支援開發工具，並讓開發人員對系統進行探索和變更。這並非提供給使用者的產品，也不是這些產品的基礎。

除了 minimal 包含的功能外，workbench 還會提供圖形、音訊和輸入支援 (觸控、滑鼠和鍵盤)。這麼做可啟用完整的系統驗證測試，模擬圖形產品 (硬體加速影片解碼器和 DRM/受保護記憶體除外)。

如果為建構作業設定的板卡支援 WLAN 和藍牙，我們也會在 workbench 建構作業中加入這兩項功能的支援。

這項產品可滿足目前 workstation 和 terminal 產品的大部分用途，但維護成本會大幅降低。舉例來說，目前在 core 上執行的許多測試都需要在 workbench 上執行，因此 workbench 就能使用 --with //bundles/buildbot:core 的等效項目進行建構，以便建立可用測試的套件存放區。

workbench 會從 tiles-session 調整預設工作階段，但預設不會啟動任何元素。這可讓您對各種圖形元素 (例如圖形示範或終端機) 進行互動式測試和偵錯。需要在預設情況下不啟動工作階段的軟體或測試，可以使用執行階段設定來停用啟動作業。

workbench 不會將任何 Flutter 或 Chrome 等執行階段做為基本套件，但可根據需求從套件伺服器載入，以利開發。

workbench 會使用與 minimal 相同的組裝平台定義，但會加入其他內容。不會繼承 minimal 的整個產品設定。

我們會將 workbench 定義為 _eng 建構類型，目前不會建立 _user 或 _userdebug 版本的 workbench。產品組合中的所有產品定義都必須是 _eng、_userdebug 或 _user 之一。因此，本文件其餘部分中所有 workbench_eng 和 workbench 的參照皆相同。

何時應將平台元件新增至 workbench？

如果預期元件會在所有支援圖形和音訊的 Fuchsia 產品中使用，或是大多數樹狀結構內的 Fuchsia 開發人員會在測試流程或日常開發作業中加入元件，我們就應將元件加入 workbench。

例如：

• 我們在 minimal 中新增的所有內容也應加入 workbench
• 我們應該在預設設定中新增圖形、音訊和一般 Fuchsia 開發工具和元件
• 我們不應新增僅適用於少數 Fuchsia 產品的元件。舉例來說，我們不應在 workbench 中新增相機實作項目，因為只有部分 Fuchsia 產品會配備相機。

產品提供的平台通訊協定實作項目 (例如 fuchsia.web)

fuchsia.web 等部分 FIDL 通訊協定是由平台定義，實作則由平台外提供。由於這些實作方式可能會變更，且平台通常不包含實作這些通訊協定的元件，因此我們需要在元件拓撲中提供位置，讓產品可在實作這些通訊協定的元件中插入。

具體來說，我們應在 workbench 元件拓撲中保留一個位置，用於實作 fuchsia.web，但不提供樹狀結構內產品定義中的實作項目。如要納入 fuchsia.web 的實作項目，產品擁有者或開發人員可以在建構期間使用 --with-base，將實作項目放入 Fuchsia 套件伺服器，以便在執行階段載入，或者我們也可以在產品組合組裝設定中直接新增支援項目，指定產品提供的實作項目。

要移除的產品定義

我們會隨著時間將使用者從每個產品定義中移除，然後刪除定義。

core.gni

根據此 RFC，core 及其所有子定義都已淘汰。

廣泛用於 Fuchsia 基礎架構，並由 Fuchsia 開發人員在辦公桌上使用。這比「我們稱為 Fuchsia 的最小東西」大得多，其中包括 藍牙工具、WLAN 工具、驅動程式遊樂場、音訊、Starnix 管理員、測試管理員、模糊處理支援、虛擬化支援、SSH 支援、用於管理短期可變儲存空間的工具，以及其他並非所有產品都需要的東西。

我們認為 core 在某些情況下是實用的產品，但其中包含太多與產品應包含內容相關的主觀選項，因此不適合做為 所有 Fuchsia 產品的基礎。

我們預計隨著時間推移，將基礎架構和開發人員從 core 移至 minimal 和 workbench，並最終刪除 core。我們將透過子套件、密封整合測試等技術，以及使用軟體提交工具在執行階段輕鬆新增軟體等方式，實現這項目標。

core.x64 建構工具在 Fuchsia 基礎架構中執行超過 1000 項測試，因此如果沒有可簡化轉換程序的技術，刪除這項產品將是一項重大任務。

我們目前的所有測試都應繼續在 minimal_eng 或 workbench_eng 上執行，且我們必須繼續支援 //:tests 慣用法，讓開發人員可將測試放入頂層 GN 標籤，並確保測試會在基礎架構的某處執行。

以下是測試應放置的位置指南：

1. 如果測試是密封的 (也就是無法解析自身套件以外的套件或服務)，或是測試規格明確標示為與 minimal_eng 相容，則我們建議在 minimal_eng 建構工具上執行測試
2. 如果測試不是密封的，或我們沒有針對該測試進行密封性分析，則應在 workbench_eng 上執行，這是與目前 core 圖像最相似的類比

我們可能會使用 //:tests 目標的程式輔助分析，判斷是否為密封式，進而決定要執行哪個圖像的特定測試。

core_size_limits.gni

基礎架構會使用這項屬性，針對平台程式碼執行大小檢查。這反過來可在核心平台元件納入發布產品前，對其進行大小增加的偵錯作業，並讓大小檢查結果公開顯示。

我們打算隨著時間的推移，將這些檢查項目遷移至 minimal_eng，後者應具有內建大小限制。core_size_limits 之所以存在，是因為在建構期間修改 core 映像檔的方式太多 (例如使用 GN 引數)，因此在主要核心映像檔上設定大小限制並不切實際。minimal 的部分用途是在建構期間無法修改，且只提供一個設定，因此大小限制應是 minimal 設定的必要部分。

注意：我們建議尺寸檢查功能不要依賴特定產品定義。舉例來說，如果我們能夠追蹤平台元件群組的大小，且不依賴特定產品設定，那就太好了。不過，這項能力目前尚未推出，因此我們建議您目前針對 minimal_eng 進行大小檢查。因此，開發人員工具等非正式版套件會影響回報的整體圖片大小，但正式版套件的大小也會顯示。

core_with_netstack3.gni

可供 netstack3 開發人員使用，用於基礎架構中的自動化測試。我們應該在 netstack3 完成時，為了測試目的而將 netstack2 納入 workbench，並提供建構時的切換器，透過新產品定義 (例如修改 workbench 的 core_with_netstack3) 或基礎架構食譜中定義的 GN 或 Bazel 建構作業的引數，啟用 netstack3。

terminal.gni

根據本 RFC，terminal 已淘汰。

說明文件中將其描述為「具有簡單圖形使用者介面和指令列終端機的系統」。目前由多位 OOT 客戶使用，用於針對含有圖像系統的產品執行測試。我們打算將這些使用者遷移至 minimal 產品 (如果他們真的無法捨棄系統依附元件，則遷移至 workbench)，然後刪除 terminal 產品。

CI 中的終端機建構工具會執行一些基準測試和多項重要測試。這些項目可能會在短期內遷移至 core 建構工具，或是長期遷移至 minimal。

更重要的是，我們需要瞭解如何停止在 SDK 中發布 terminal 圖片。Chromium 和 Flutter 基礎架構會大量使用 terminal 映像檔做為測試主機。本 RFC 的實作部分說明瞭將 Chromium 測試遷移至 workbench 的計畫。

workstation.gni

自本 RFC 起，工作站已淘汰。

我們希望將工作站的大部分用途都改為 workbench。

workstation 有幾種用途，我們需要為這些用途尋找替代方案：

• 使用圖形堆疊進行系統驗證測試的測試設定
  • 我們需要將這些遷移至 workbench。
• 虛擬化
  • 我們目前沒有虛擬化路線圖 (正在進行中)，但我們可能會將虛擬化測試和開發作業遷移至 minimal 或 OOT 產品存放區。
• Wayland 橋接開發
  • 我們不再提供這項支援。我們不會提供替換品。
• Starnix 開發
  • 我們會在 //vendor/google 中將第一方 Starnix 開發的主要開發目標，替換為內部產品，但仍可使用套件伺服器在 workbench 上執行 Starnix 程式。

workstation_eng.gni

請參閱上文的 workstation 部分。我們會刪除這項設定。

workstation_eng_dfv2.gni

這項工具曾做為 Driver Framework 2 版的開發目標。驅動程式架構團隊已完成遷移作業，因此會刪除該檔案。

workstation_eng_paused.gni

做為系統驗證測試的基礎。我們會將這些測試遷移至 workbench，但目前沒有任何測試正在執行。

開發工作流程變更

驅動程式開發

驅動程式開發人員目前的工作大多是針對 core 和 bringup 產品進行。其中有些會修改板卡設定以納入其驅動程式，有些會使用 --devs_boot_labels 或 board_driver_package_labels 做為其 fx set 或 args.gn 的引數，有些則會使用暫時性驅動程式庫載入作業 (仍處於實驗階段)。

我們正在投入樹狀結構外驅動程式庫開發工作流程，目的是讓驅動程式庫開發人員不必完全重新組合產品來測試驅動程式庫，除非該驅動程式庫在網路可用之前就已必要。截至本文撰寫時，暫時性驅動程式庫載入功能適用於部分驅動程式，但目前無法針對需要在裝置網路連線前執行的驅動程式使用暫時性載入功能。

此 RFC 的目的並非變更驅動程式庫開發工作流程，而是變更其指定產品設定的預設內容。產品通常不應將驅動程式當作依附元件，而是將其留給電路板設定。

產品組合和 Fuchsia 的開發人員流程即將進行變更，這會導致組合。我們會將這些流程留給後續的 RFC 和文件，並說明我們打算保留在指令列或透過 args.gn 等檔案，在組合中加入驅動程式的能力。

實作

新增產品定義

極簡

• 確認 minimal 沒有舊版組合包 (這不是阻斷因素，但可大幅降低維護成本)
• 確保 minimal 可在 NUC、VIM3、FEMU 和 QEMU 上順利執行

工作檯

• 定義不依據 GN 繼承的 (因為我們不會使用 GN 定義產品，請參閱 RFC-0186) 方法，在 minimal 的平台定義上方組合 workbench，確保兩個產品不會分歧。
• 確認 workbench 可在 NUC、VIM3、Google Compute Engine 和 FEMU 上順利運作。
• 讓系統驗證測試順利執行
• 為希望在執行階段將元素新增至 tiles-session 以執行圖形終端機等項目的開發人員提供支援和文件。

遷移使用者並移除已淘汰的產品定義

第一步：改善子套件支援功能，並透過 SDK 發布套件

這些遷移作業大多需要支援在樹狀結構外建立的子包，並且需要我們的工作流程，才能支援樹狀結構內外的完整密封整合測試。我們必須實作這項功能，才能大量遷移資料。

我們也必須能夠將套件從樹狀結構中發布，這在 RFC-0208 中已有說明。

其餘工作流程則可同時執行。

core 和 core_size_limits

這個產品定義可能最難讓使用者轉移，因為它在樹狀結構內外都有最多使用者。

由於先前對測試的密封性規定過於寬鬆，許多測試現在都會依附 core 產品定義的特定部分。舉例來說，測試可能會解析已知位於 core 中基本集合的套件。在將 core 從測試產品移除的過程中，我們應避免再次出現 Hyrum 法則的情況。具體來說，我們應該：

• 為測試提供解析器，讓其只能存取專屬的測試套件及其子套件，藉此避免測試解析套件所在的測試領域以外的套件。這項功能目前適用於在測試管理員下以密封測試領域執行的測試，但我們仍需要將舊測試移植至新架構。
• 在測試中更廣泛地使用子套件 - 如果測試目前依賴個別套件，則日後應將其納入子套件。

所有密封封裝的測試 (與服務相關的密封測試) 都可以針對 minimal 執行，無須修改。我們應該盡可能將樹狀結構內的測試盡快移至 minimal 執行，並為可在 core 中執行的測試建立許可清單，以免更多測試依附於 core 的設定。

一旦我們為 core 的使用者建立許可清單，就會與這些測試的擁有者互動，按照上述最佳做法將測試遷移至 minimal 或 workbench。

樹狀結構外的使用者會是另一個挑戰，因為我們無法輕易列舉這些使用者或他們的測試。我們會與各個花瓣擁有者個別合作，判斷他們使用 core 的情況，以及是否可以改用 minimal 或 workbench。如果必須變更這些產品才能遷移，我們可以進行變更，或是依據流失率政策，為這些花瓣的測試專門建立樹狀結構外產品。

終端機

terminal 可能是我們最複雜的移除作業，因為除了 workstation 以外，它是我們所處理過最複雜的開放原始碼產品，而且使用者眾多。本 RFC 並未聲稱擁有 terminal 的完整遷移計畫，但 Fuchsia 團隊確實會在客戶遷移期間提供支援，方法包括使用子套件實作 OOT 密封測試、新增 OOT 產品進行測試，或是為 workbench 新增依附元件 (大致依優先順序)。

以下是實施計畫的草圖：

• 判斷依附元件。已知的依附元件：
  • 平台樹狀結構中的效能測試
  • Fuchsia 上的 Chromium
  • Fuchsia 上的 Flutter
  • 蟻螫築巢者
• 這些依附元件可能會使用 terminal，因為它們需要圖形支援，因此大多數依附元件可能需要遷移至 workbench。
• 針對每個依附元件，開始擷取 workbench，並針對該元件執行測試。並行執行測試以確保相等性，然後在滿足條件時關閉以 terminal 為基礎的測試。
• 在這些遷移作業中，請將可遷移至密封測試的測試，連同子包中的依附元件一併遷移。

Chromium 測試遷移

Chromium 的公開 CI 測試 web_engine 使用 terminal。這些測試會依賴許多功能和服務，這些功能和服務是終端機直接從基礎映像檔公開，例如圖形。此外，它會依賴測試/假造元件，例如 fuchsia-pkg://fuchsia.com/flatland-scene-manager-test-ui-stack#meta/test-ui-stack.cm。

為了不影響測試結果，這些測試需要提供這些服務和其他服務的環境。我們不應阻擋重構 Chromium 測試的工作，因此需要提供這類環境。我們可以將 Chromium 測試移至其依附元件的子集，或是提供套件存放區，以便在執行階段解析套件。

workstation 和子產品

workstation 將與此文章並行從 Fuchsia 的 CI 中刪除。但仍會在 SDK 中提供。

• 針對每位 workstation SDK 客戶，判斷他們是否需要遷移至 minimal、workbench 或完全不同的產品定義 (可能不在樹狀結構中) 進行測試
• 所有測試都完成遷移後，請停止在 SDK 中提供 workstation 圖片

成效

我們移除的產品並未在實際工作環境中執行，因此不會影響效能。

目前使用終端機圖片執行效能測試。我們認為將這些測試移至 workbench 不會對成效造成太大影響。

Ergonomics

我們不打算透過此 RFC 變更開發流程或產品的指定方式。我們打算變更可用產品組合，這會影響開發人員在樹狀結構中執行測試或使用 SDK 時的目標。我們也可能會協助將部分測試遷移至不同的樣式 (如前所述，以密封方式封裝，並將相關依附元件做為子包)，做為實作作業的一部分。

回溯相容性

這些產品定義變更大多與舊版相容，因為我們會透過新產品提供大多數使用者需要的服務。對於正在更名或變更內容的產品，我們會提供緩衝期和通知期。我們也會按照 Fuchsia 流失政策，自行完成大部分的遷移作業。

安全性考量

我們不打算或預期這項 RFC 實作會造成重大安全性變更。我們維持的產品設定越少，安全性應會越高。

我們不應將任何新產品提供給使用者或用於實際工作環境。這些產品應盡可能實作安全的 Fuchsia 設定。_eng 變化版本會自然允許新增套件存放區的作業，而目前的產品 (例如 core 和 terminal) 在預設情況下已允許這類作業。

隱私權注意事項

我們不應將任何新產品提供給使用者，也不應將新產品用於實際生產或用於任何個人資訊。我們認為這些新產品不會造成隱私權疑慮。

測試

測試此 RFC 的實作方式非常簡單：目前我們在樹狀結構內外都有的所有測試都應該會通過。部分測試可能需要遷移，以便依賴不同的服務實作、模擬或假資料。不過，我們應該要達到目前的測試涵蓋率，且不應為了達成此 RFC 的目標而停用測試套件。

說明文件

我們會更新 //products 目錄中的說明文件，說明每項產品的用途。我們會為希望針對特定產品增加測試涵蓋率的開發人員，提供相關說明文件，說明如何使用這些產品。

我們會在移除 workstation 和其他產品時，移除或修改 fuchsia.dev 上的相關說明文件。我們會在變更過程中更新含有已移除或重新命名產品的教學課程或程式碼研究室。

我們會更新 RFC-0095，指出這項 RFC 取代了先前的 RFC，且我們目前不會在樹狀結構外建構 workstation 或其後繼 workbench。

缺點、替代方案和未知因素

缺點：暫時增加基礎架構的工作負載

從 terminal 和 core 轉換至新的產品定義，意味著我們需要在停用舊版產品定義的同時，讓新版產品建構工具運作。這會增加基礎架構負載，直到我們刪除舊產品定義的建構工具為止。這可能會導致開發人員在轉換期間流失。

替代做法：不採取任何行動

這個 RFC 的主要替代方案，就是簡單地減少操作。我們可以移除 workstation，並保留 core、minimal、terminal 及其所有變化版本，不做任何變更。

這表示我們仍需維護這些產品設定，並執行相關工作，例如將核心領域合理化，或將產品遷移至以 Bazel 為基礎的組合，這些工作都需要在更多支援的產品中複製。隨著時間推移，產品設定數量減少，對於負責維護產品設定、組合和建構作業的團隊來說，將會變得更加簡單。

由於我們已重新調整工作站的優先順序，因此目前使用這些產品的許多客戶需求也減少了，現在是簡化支援設定的最佳時機。

替代做法：建立樹狀結構外的 Workbench

我們可以在樹狀結構外部存放區中建立 workbench (類似於 RFC-0095 中的提案)，因為許多測試可以密封封裝並在 minimal 上執行。不過，許多測試和用途都需要圖形或音訊，或者不想拉入其他 OOT 依附元件，因此我們需要樹狀結構內執行圖形和音訊測試。我們會在樹狀圖的某處中檢查 workbench 等設定。最好還是直接在 //products 目錄中維護。

既有技術與參考資料

在文件中相關的部分連結。