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

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

這項提案旨在簡化開放原始碼 //products 目錄中的產品設定組合。
問題
毛皮變化
作者
審查人員
提交日期 (年-月-日)2022-04-06
審查日期 (年-月-日)2022-06-13

編輯此 RFC

編輯 RFC 中繼資料

摘要

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

提振精神

「//products」目前包含 10 項產品定義。自從建立產品定義以來， Fuchsia 就有顯著的發展，且這些產品的使用者也變得零碎。有些產品只會出現少數使用者或用途，或是有類似功能 (例如 UI 堆疊) 僅存在於該產品中。如要變更跨切割功能 (例如產品組合、建構系統，或是圖形或網路堆疊)，必須考量個別產品及其差異。這不但會耗費開發人員的時間和人力，並拖慢平台的演進。

//products 目錄也沒有明確的藍圖或目的說明。我們無法從 README 看出為何該目錄中有產品，以及這些產品的擁有者或維護者。有一組特殊的志工負責關注產品定義並為其提供，且沒有明確的強制性要求。

相較於有特定用途的平台來源樹狀結構中大量產品，Fchsia 不如採用範圍較小的產品定義，選擇數量有限的產品定義，並提供參考實作項目和範例，說明如何利用樹狀結構 (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 Engineering Council 的團隊。

詞彙解釋

系統

這代表一個可開機的 Fuchsia 映像檔，但是沒有我們希望刷新至實際工作環境中的目標 (例如復原映像檔) 的所有內容。

如要進一步瞭解啟動運算單元和可刷新映像檔，請參閱 RFC-0115。

產品

在現有說明文件中：「產品定義建構將產生的軟體設定。最重要的是，產品通常會定義要提供的使用者體驗類型，例如使用者可能觀察到的圖形殼層類型、是否包含多媒體支援等。

在產品組合程序的輸出內容中，產品定義了一或多個系統的組合 (在版位 A、B 和/或 R 中)，並用於放置於目標上。例如，產品映像檔可能包含核心映像檔、FVM、vbmeta、復原映像檔、復原 vbmeta 和系統啟動載入程式映像檔。

主機板

在現有說明文件中，「看板」定義了建構針對該版本產生的架構，以及要執行版本的裝置主要功能。這項設定會影響內含的驅動程式，可能也會影響裝置專用的核心參數。

Fuchsia 建構參數是由 (產品、board) 元組來指定。這組參數會完全說明建構系統製作可刷新產品映像檔時，必須完成的工作。

目標

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

  • 盡可能讓現有產品定義的現有使用者遷移工作量降到最低；選擇停用 core 和 terminal 應該盡可能讓這些產品的現有使用者能輕鬆完成遷移

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

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

  • 針對其餘 (bringup 除外) 的產品定義，請實作建構類型，以便在實作自己的版本時參照適當的建構類型。

  • 定義使用新產品定義的方式、加入時機，以及新增產品定義的條件

  • 如果可以，請勿大幅變更產品的定義方式或董事會的定義。讓範圍維持在中等期

必要條件

  • 我們必須支援核心和新的開發板開發工作，無需使用自訂產品定義

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

  • //products 中的所有產品都應該以 SDK 附屬圖片發布，且在樹狀結構中及外的運作方式均相同

  • 您無須進行測試，也不必在平台上新增要用來執行產品的內容。測試應能以「子套件」的形式將依附元件帶入其專屬套件。舉例來說，//bundles/buildbot:foo 只能包含測試，不應在產品或平台定義中加入任何項目。

非目標

  • 調整主機板、建構類型和產品的互動方式，或是重新定義互動方式。這個 RFC 應盡可能將重點放在 //products 的內容及其用途。

  • 變更開發工作流程，而不替換產品定義。這個 RFC 僅涉及產品定義的內容。

設計

這份文件中的下列關鍵字：「必須」、「不得」、「必要」、「應」、「不應」、「應」、「不應」、「建議」、「可能」和「選用」等關鍵詞均如 IETF RFC 2119 所述。

今天的「//products」有 10 項產品定義，我們陸續會移除八項產品定義、保留兩個 (minimal 和 bringup)，接著再新增一個：workbench。目前我們只會建立 minimal 和 workbench 的 _eng 建構類型，但日後可能會視需要新增 _user 和 _userdebug 建構類型。

現有的許多定義可用於支援測試流程，並包含其特定套件和設定，因為測試會直接依附於系統映像檔中的服務，而不是將依附元件納入其專屬套件中。

我們希望「大部分」Fchsia 測試應在中期的 minimal_eng 上執行，因為大部分的 Fuchsia 測試都應以純粹的方式封裝及所有依附元件。

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

這表示在預設情況下，並非所有 fuchsia.git 的功能都會出現在樹狀結構內的產品的基礎設定中。我們建議您不要建立能在現有產品上執行整合和單元測試的整合和單元測試，而不是將所有功能新增至平台支援產品，並永遠支援這一點。

要保留的產品定義

bringup.gni

目前主要由核心開發人員使用。bringup 是用來執行核心和核心驅動程式，並在新面板上進行開發作業。

我們打算保留 bringup，以符合其用途和內容的目的，但將其移至使用產品組合。我們不再希望 bringup 成為所有已定義產品的「基礎類別」，因為啟動具有某些不適用於所有產品的功能。

要新增或調整的產品定義

//products 中其餘的產品定義會由 Fuchsia Architecture and Software Assembly 團隊共同擁有。且需要由軟體組裝完成日常維護

最小 - 保留，盡量減少

預期為「我們還是所謂的 Fuchsia。」基本上，我們所稱的 Fuchsia 系統最小，它具有以下功能：

  • 啟動進入使用者空間
  • 執行元件管理服務和元件
  • 使用無線更新系統自行更新應用程式。
    • 這表示儲存空間和網路正常運作 與董事會提供的驅動程式

這項產品用於 Fuchsia 專案的主要用途將是執行密封封裝測試，其中包含所有依附元件。此外，生成式 AI 也能做為系統測試的基礎，即使這些測試不是語意，只須仰賴其中包含的少數 Fuchsia 服務。

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

「minimal」將支援：

  • 元件
  • 套件，以及 OTA 系統功能
  • 透過 Fastboot 刷新系統
  • 驅動程式架構和數量確實為零的驅動程式 (最好是零；我們應該在董事會定義中加入驅動程式，而非產品定義，除非「所有」 Fuchsia 產品需要使用這些驅動程式)
  • 記錄
  • 網路 (如果主機沒有其他網路能力，可能包括 USB CDC 乙太網路)
  • 儲存空間
  • 支援工作階段，但未指定工作階段
    • 系統會在執行階段使用 ffx session launch 上的 eng 版本新增工作階段。
  • 支援上述功能的大小上限

建議使用 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 預設檔案系統，因為 OTA 更新需要檔案系統，minimal 應使用預設的 Fuchsia 檔案系統。如果用於所有 Fuchsia 產品，應將新的驅動程式庫架構新增至 minimal。建議不要在 minimal 中新增圖形驅動程式庫或控制系統，因為某些 Fuchsia 系統不需要使用圖形來啟動或更新系統。

我們會進行兩項壓力測試，真實地判斷是否應將特定元件納入 minimal_eng 中：

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

如果平台元件不應最小化，可能仍適用於 workbench。

minimal司機

如果必須支援 OTA 或在所有主機板上執行元件管理員，我們應在 minimal 的平台設定中加入驅動程式庫堆疊的支援。這表示即使執行 minimal 的主機針對藍牙提供支援 (例如藍牙)，我們仍不應將該驅動程式庫程式堆疊納入產生的設定中，因為產品不需要。

這表示最終映像檔包含的驅動程式組合是產品要求的功能和開發板硬體支援的交集。此交集功能仍在與軟體組合團隊合作開發中。

Workbench

workbench 是本機開發的產品設定，會執行無法或不應封裝的大型測試，以及對 Fuchsia 平台中比 minimal 支援的大部分部分執行。這的目的在於是一種常值工作台，它支援開發工具，並允許開發人員對系統發出呼叫並進行變更。並不是產品運送給使用者，亦不是產品的基礎。

除了 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 建構類型，目前不會建立 workbench 的 _user 或 _userdebug 版本。產品組合中的所有產品定義都必須是 _eng、_userdebug 或 _user 的其中一個。因此，在本文件其餘部分中，所有 workbench_eng 和 workbench 的參照都相同。

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

如果預期元件會在支援圖像和音訊的所有 Fuchsia 產品中使用，或對大部分的 Fuchsia 系列產品使用，則應該在 workbench 中新增元件。

舉例來說：

  • 我們新增至 minimal 的一切內容也會加入 workbench
  • 建議您在預設設定中加入新的圖形、音訊，以及一般 Fuchsia 開發工具和元件
  • 我們不應新增僅適用於小部分 Fusia 產品的元件。舉例來說，我們不應在 workbench 中新增攝影機實作項目，因為只有部分 Fuchsia 產品會有相機。
由產品提供的平台通訊協定實作 (例如 fuchsia.web)

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

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

要移除的產品定義

我們會陸續將使用者移出這些產品定義，然後刪除定義。

core.gni

自 RFC 起，core 及其所有子定義都已淘汰。

廣泛用於 Fuchsia 的基礎架構，以及由 Fuchsia 開發人員在桌面上使用。這遠遠大於「我們所稱的 Fuchsia 最小的產品，」包含藍牙工具、WLAN 工具、驅動程式遊樂場、音訊、Starnix Manager、測試管理員、測試管理員、測試與所有其他的虛擬儲存空間、可協助處理虛擬化作業、其他所有不支援的虛擬儲存空間等項目。藍牙工具、WLAN 工具、音訊

我們認為 core 是適用於特定情況的產品，但針對某項產品應包含多少意見，這是「所有」Fchsia 產品的基礎。

我們計劃逐步將基礎架構和開發人員從 core 轉移至 minimal 和 workbench，最終刪除 core。我們將運用子套件和隱密整合測試等技術實現這一點，並在執行階段使用 Software Delivery 工具輕鬆新增軟體。

core.x64 建構工具在 Fuchsia 基礎架構中執行超過 1, 000 次測試，因此在缺乏技術可簡化轉換的情況下，刪除這項產品會是重要的工作。

目前所有測試應繼續在 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 完成時進行測試，我們應該在 workbench 中加入 netstack2，並提供建構時間切換功能，透過修改 workbench 的新產品定義 (例如修改 workbench)，或透過基礎架構方案中定義的 GN 或 Bazel 建構作業引數來啟用 netstack3。core_with_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 Bridge 開發
    • 我們不再支援這項功能。我們不會提供更換方案。
  • Starnix 開發技術
    • 我們將使用 //vendor/google 中的內部產品，取代第一方 Starnix 開發作業的主要開發目標，但仍可使用套件伺服器在 workbench 上執行 Starnix 程式。

workstation_eng.gni

請參閱上方的 workstation 一節。我們會刪除這項設定。

workstation_eng_dfv2.gni

這做為驅動程式架構第 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 上運作良好

Workbench

  • 定義不以 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
    • Antlion 建構工具
  • 這些相依項目可能使用 terminal，因為它們需要圖形支援，因此大部分可能需要遷移至 workbench。
  • 針對每個相依項目，開始提取 workbench 並對其執行測試。同時執行測試以確保一致性，然後在滿足後關閉以 terminal 為基礎的測試。
  • 遷移作業過程中，請將測試移至含依附元件子套件的密封測試中。
Chromium 測試遷移

Chromium 的公開 CI 測試使用 terminal web_engine。他們的測試仰賴許多終端機直接從基本映像檔公開的功能和服務，例如圖像。此外，它也需要測試/假的元件，例如 fuchsia-pkg://fuchsia.com/flatland-scene-manager-test-ui-stack#meta/test-ui-stack.cm。

因此，他們的測試需要提供這些服務等項目的環境，才能順暢運作。我們不應在重構 Chromium 測試時阻斷這類工作，因此需要提供這類環境。我們可以將 Chromium 測試移至其依附元件的子套件，或提供套件存放區，在執行階段解析套件。

workstation 和子產品

正在與上述寫入作業同時刪除 Fuchsia 的 CI 中的「workstation」。 但 SDK 仍會提供此屬性。

  • 請針對 workstation 的每個 SDK 客戶，判斷是否需要遷移至 minimal、workbench，或完全不同的產品定義 (可能從樹狀結構外) 進行測試
  • 所有測試都遷移後，請停止在 SDK 中傳送 workstation 映像檔

效能

沒有任何要移除的產品會在實際工作環境中執行，因此應該不會對效能產生影響。

終端機映像檔目前用於執行效能測試。只要將這些測試移至 workbench，就能避免對效能產生重大影響。

人體工學

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

回溯相容性

這些產品定義的變更大多可回溯相容，因為我們現在提供了大多數使用者從新產品所需的服務。針對已重新命名或變更內容的產品客戶，我們會提供柔性轉換和通知期。我們也將根據 Fuchsia Churn 政策執行許多遷移工作。

安全性考量

因為這項 RFC 的執行方式，我們本來就無意或預期發生重大安全性變更。如果發現任何項目，我們會維持較少的產品設定，因此安全性狀態應有所提升。

請勿向使用者提供或用於實際工作環境的新產品。這些產品應盡可能採用安全的 Fuchsia 設定。_eng 變數將自然允許執行多項作業，例如新增 core 和 terminal 等目前已預設允許的套件存放區。

隱私權注意事項

我們的新產品不得提供給使用者、用於實際工作環境，也不得用於任何個人資訊。我們不認為這些新產品有隱私權疑慮

測試

測試這個 RFC 的實作方式相當簡單：我們目前正在進行的所有測試，無論在樹狀結構中還是退出，都應通過測試。有些則可能需要遷移，才能依賴不同的服務實作、模擬或假功能。不過，我們應該會達成目前相同的測試涵蓋範圍，而且不會為了達成此 RFC 目標而停用測試套件。

說明文件

我們會更新 //products 目錄中的說明文件，說明每個產品的用途。我們會新增說明文件，協助開發人員新增測試涵蓋範圍，判斷應針對測試所指定的產品以及使用方式。

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

我們將會更新 RFC-0095，以標註此 RFC 會取代該 RFC，而且我們目前不會從樹狀結構建構 workstation 或其後續 workbench。

缺點、替代方案和未知

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

從 terminal 和 core 轉換至新的產品定義，代表在替換舊版產品時，我們必須執行新的產品建構工具。這會增加基礎架構負載，直到我們刪除舊產品定義的建構工具為止。隨著系統轉換，這可能會導致開發人員體驗流失。

替代做法：不執行任何動作

這個 RFC 的主要替代方法就是減少工作量我們可以移除 workstation，保留 core、minimal、terminal 及其所有變化版本。

這表示我們仍需保留這些產品設定，並繼續努力，例如合理化核心領域，或將產品遷移至 Terraform 組合，就需要在大量支援的產品中複製。對於維護產品設定、組合和建構核心層面的團隊來說，在一段時間內建立少量的產品設定會變得簡單許多。

在我們調整工作站的優先順序之後，許多客戶購買這些產品的需求較少，因此現在是簡化支援設定的最佳時間。

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

我們可以在樹狀結構外存放區中建立 workbench (類似於 RFC-0095 中的提案)，因為許多測試都能以自動包裝的方式封裝並在 minimal 上執行。不過，許多測試和用途都依賴圖像或音訊，或者不想提取其他 OOT 依附元件，因此無論如何，我們也需要要執行樹狀結構內圖形和音訊測試。最終，我們會將類似 workbench 的設定放入樹狀結構「其他位置」。我們建議直接在 //products 目錄中進行維護。

既有藝術品和參考資料

在文件的相關時間點提供連結。