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

RFC-0220：樹狀結構內產品的未來
狀態已接受
區域
  • 一般
  • 軟體組裝
說明

提案：簡化開放原始碼 //products 目錄中的產品設定集。
問題
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2022-04-06
審查日期 (年-月-日)2022-06-13

編輯這份 RFC

編輯 RFC 中繼資料

摘要

建議簡化開放原始碼 //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 團隊
  • 驅動程式開發團隊
  • Bringup 團隊

社交：

這項 RFC 以文件形式在組織內部廣為流傳，包括「諮詢」一節中列出的團隊和 Fuchsia 工程委員會。

詞彙解釋

系統

系統是一組映像檔 (zbi、vbmeta 和 fvm)，適用於目標裝置上的單一開機插槽。這代表可啟動的 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。目前我們只會建立 _eng 建構類型的 minimal 和 workbench，但日後如有需要，可能會新增 _user 和 _userdebug 建構類型。

目前許多定義都是為了支援測試流程，且包含特定套件和設定，因為測試直接依附於系統映像檔中包含的服務，而不是在自己的套件中加入依附元件。

我們希望大多數 Fuchsia 測試都能在中期內於 minimal_eng 上執行，因為大多數 Fuchsia 測試都應以密封方式封裝所有依附元件。

如果特定測試需要依賴系統直接提供的服務 (而非從自有套件執行的版本)，則應避免建立一般樹狀結構內產品來測試。該測試應在要測試功能所屬的產品上執行，或定義自己的私有樹狀結構外產品定義，以便執行測試。我們不會再為所有可能的功能測試建立及維護一般「測試產品」。我們應優先在對消費者或開發人員更有用的產品中加入測試支援，而非使用僅供測試的產品。

也就是說，根據預設，樹狀結構內產品的基本設定不會包含 fuchsia.git 中的所有功能。我們應優先建立整合和單元測試，以便在現有產品上以密封方式執行，而不是將所有功能新增至平台支援的產品，並永久支援該產品。

要保留的產品定義

bringup.gni

目前主要由核心開發人員使用。bringup 用於練習核心和核心驅動程式，以及在新的開發板上進行開發。

就用途和內容而言，我們打算維持 bringup 不變，但會改用產品組合。我們不再打算將 bringup 做為所有已定義產品的「基底類別」，因為啟動程序有某些功能不適用於所有產品。

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

//products 中的其餘產品定義將由 Fuchsia 架構和軟體組裝團隊共同擁有。日常維護作業將由軟體組裝團隊負責。

極簡 - 保留，盡量極簡

目標是「我們仍會稱為 Fuchsia 的最小事物」。根據定義，我們仍會將 Fuchsia 稱為系統，因為它具備以下功能：

  • 啟動進入使用者空間
  • 執行元件管理服務和元件
  • 透過我們的無線下載更新系統自行更新
    • 這表示儲存空間和網路運作正常，且主機板提供驅動程式

Fuchsia 專案主要會使用這項產品執行密封封裝的測試，其中包含所有依附元件。此外，這項測試也可做為系統測試的基礎，這類測試並非密封，但只會依附於其中一小組 Fuchsia 服務。

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

minimal 將支援下列項目：

  • 元件
  • 套件，以及透過 OTA 更新系統的功能
  • 透過快速啟動模式刷入系統
  • 驅動程式架構和極少數的驅動程式 (理想情況下為零；除非這些驅動程式是所有 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 上執行，我們會鼓勵您這麼做，因為 minimal_eng 的建構時間較短，且體積較小，因此更易於偵錯。workbench

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

平台開發人員應在minimal支援minimal產品核心目標時，將元件新增至隨附的組件輸入套裝組合。舉例來說，Fuchsia 的新預設檔案系統應新增至 minimal，因為 OTA 更新需要檔案系統，而 minimal 應使用預設的 Fuchsia 檔案系統。如果新驅動程式庫架構要加入所有 Fuchsia 產品，就應該新增至 minimal。新的圖形驅動程式庫或控制系統「不應」新增至 minimal，因為並非所有 Fuchsia 系統都需要圖形才能啟動或更新系統。

我們有兩項壓力測試，可判斷特定元件是否應納入 minimal_eng：

  1. 該元件是否應位於 _eng 建構類型中的所有紫紅色產品？
  2. 沒有 minimal 就無法使用嗎？

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

minimal地區的司機

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

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

工作台

workbench 是用於本機開發的產品設定，可執行較大型的測試 (這些測試無法或不應以密封方式封裝)，並運用比 minimal 支援的 Fuchsia 平台更大範圍的部分。這個工具的用意是提供類似實體工作台的環境，支援開發工具，並讓開發人員探究系統及進行變更。這項技術並非要成為可運送給使用者的產品，也不會是這類產品的基礎。

我們希望 workbench 除了 minimal 包含的功能外，還能支援圖形、音訊和輸入 (觸控、滑鼠和鍵盤)。這項功能可啟用完整系統驗證測試，模擬圖形產品 (硬體加速視訊解碼器和 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)

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

具體來說，我們應在 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 圖片的方法非常多 (例如使用 GN 引數)，因此對主要核心圖片設定大小限制並不實際，這就是 core_size_limits 的存在原因。minimal 的重點之一是在建構時無法修改，且只能採用一種設定，因此大小限制應是 minimal 設定不可或缺的一部分。

注意：我們希望大小檢查作業不要依賴特定產品定義。舉例來說，如果我們能追蹤一段時間內平台元件群組的大小，而不必依賴特定產品設定，那就太好了。不過，目前沒有這項能力，因此我們建議暫時針對 minimal_eng 進行大小檢查。因此，回報的整體圖片大小會受到非正式版套件 (例如開發人員工具) 影響，但系統也會提供正式版套件的大小。

core_with_netstack3.gni

可做為 netstack3 開發人員的便利產品，以及基礎架構中的自動測試。我們應在 netstack3 完成時納入 netstack2，以利測試，並提供建構時間切換，透過修改 workbench 的新產品定義 (例如 core_with_netstack3)，或透過基礎架構配方中定義的 GN 或 Bazel 建構引數，啟用 netstack3。workbench

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 版的開發目標。Driver Framework 團隊即將完成遷移作業，因此要刪除這個檔案。

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_size_limits

這個產品定義可能最難讓使用者改用其他產品，因為樹狀結構內外都有大量使用者。

由於先前對測試的密封性要求寬鬆，許多測試現在都依附於core產品定義的特定層面。舉例來說，測試可能會解析已知位於 core 基本集中的套件。在從 core 遷移的過程中，我們應避免再次發生海勒姆定律。具體來說，我們應該：

  • 為測試提供只能存取自身測試套件及其子套件的解析器，防止測試解析自身測試領域外的套件。目前在測試管理工具的密封測試領域中執行的測試，都已採用這項功能，但我們仍需將舊測試移植到這個新架構。
  • 在測試中更廣泛地使用子套件 - 如果測試目前依賴個別套件，未來可能應將其子套件化至測試中。

所有密封封裝的測試 (服務方面也密封) 都可以針對 minimal 執行，不必修改。我們應盡快將盡可能多的樹狀結構內測試移至 minimal 執行，並建立允許在 core 中執行的測試許可清單，防止更多測試依附於 core 的設定。

我們建立 core 使用者許可清單後，會與這些測試的擁有者聯絡，並按照上述最佳做法，將測試遷移至 minimal 或 workbench。

樹狀結構外的使用者也會是另一項挑戰，因為我們無法輕易列舉這些使用者或他們的測試。我們會與各個 Petal 擁有者個別合作，判斷他們使用 core 的情況，以及是否可以改用 minimal 或 workbench。如果這些產品未經變更就無法移動，我們可以按照流失政策進行變更，或專為這些花瓣測試建立樹狀結構外的產品。

終端機

terminal可能是最複雜的移除作業，因為除了 workstation 之外，它是最複雜的開放原始碼產品，而且有許多使用者。這項 RFC 並未聲稱擁有完美的遷移計畫，但 Fuchsia 組織承諾會支援客戶遷移，方法包括實作含子套件的 OOT 密封測試、新增 OOT 產品以供測試，或將依附元件新增至 workbench (優先順序大致如上)。terminal

以下是實作計畫的草圖：

  • 判斷附屬項目。已知依附元件：
    • 平台樹狀結構中的效能測試
    • 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 後，成效不會受到顯著影響。

人體工學

我們無意透過這份 RFC 變更開發流程，或指定產品的方式。我們打算變更可用的產品組合，這會影響開發人員在樹狀結構中或使用 SDK 執行測試時的目標。在實作過程中，我們也可能會協助將部分測試遷移至其他樣式 (如先前所述，以子套件的形式與依附元件密封封裝)。

回溯相容性

這些產品定義異動大多可向後相容，因為我們將從新產品提供大多數使用者需要的服務。如果產品名稱或內容有異動，我們會提供緩慢的轉換期和通知期。我們也會根據 Fuchsia Churn Policy，自行完成大部分的遷移作業。

安全性考量

我們不打算或預期因實作這項 RFC 而進行重大安全性變更。此外，由於維護的產品設定較少，我們的安全防護機制應該會有所提升。

請勿將任何新產品提供給使用者，或用於生產。這些產品應盡可能採用安全的 Fuchsia 設定。_eng 變體自然會允許新增套件存放區等作業，而 core 和 terminal 等現有產品預設已允許這類作業。terminalcore

隱私權注意事項

不得將任何新產品提供給使用者、用於生產或處理任何個人資訊。我們認為這些新產品不會造成隱私權疑慮。

測試

測試這項 RFC 的實作方式很簡單：我們目前在樹狀結構內外進行的所有測試都應仍會通過。部分可能需要遷移，改用不同的服務實作項目、模擬或虛擬項目。不過，我們應達到目前的測試涵蓋範圍，且不應停用測試套件來達成這項 RFC 的目標。

說明文件

我們會在 //products 目錄中更新說明文件，說明各項產品的用途。我們將為開發人員新增說明文件，說明要測試的產品，以及如何使用這些產品新增測試涵蓋範圍。

我們將移除或修改 fuchsia.dev 上與 workstation 和其他要移除產品相關的文件。如果教學課程或程式碼研究室包含已移除或重新命名的產品，我們會在變更時一併更新。

我們會更新 RFC-0095，說明這項 RFC 取代了該 RFC，且目前不會在樹狀結構中建構 workstation 或其後繼項目 workbench。

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

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

從 terminal 和 core 轉換至新產品定義時，我們需要執行新的產品建構工具，同時停用舊工具。在我們刪除舊產品定義的建構工具之前，這會增加基礎架構負載。在轉換期間，這可能會導致開發人員體驗流失。

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

這項 RFC 的主要替代方案是簡化作業。我們可以移除 workstation，並保留 core、minimal、terminal 和所有變體不變。

這表示我們仍需維護這些產品設定，且我們在合理化核心領域或將產品遷移至以 Bazel 為基礎的組件時所做的作業，也必須複製到更多支援的產品。隨著時間推移，產品設定數量減少，維護產品設定、組裝和建構核心層面的團隊工作將大幅簡化。

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

替代方案：在樹狀結構外建立工作台

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

既有技術和參考資料

連結會顯示在文件中的相關位置。