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

RFC-0220：樹狀結構內產品的未來發展
狀態	已接受
區域	一般 軟體組件
說明	簡化開放原始碼 //產品目錄中產品設定組合的提案。
問題	(121898 年)
變更	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 目前包含十項產品定義。自從這些產品定義建立以來，Fuchsia 就已大幅發展，而且這些產品的使用者相當分散。某些產品只有少數使用者或用途，或者有 UI 堆疊等特許功能，只有該產品中有。變更交叉剪裁的功能 (例如產品組合、建構系統、圖形或網路堆疊) 時，需要考量個別產品及其差異。這會耗費開發人員時間和心力，並拖慢平台的演進速度。

//products 目錄也沒有清楚的發展藍圖或用途陳述。README 不清楚該目錄中的產品為何存在、製造商或維護者。一組臨時志工負責搜尋並動態饋給產品定義，沒有明確的要求。

與其使用平台來源樹狀結構中具有特定用途的大量產品，Fuchsia 應偏好使用較少範圍限定的產品定義，以提供參考實作及範例，以便瞭解如何使用樹狀圖 (OOT) 建立產品。

該是設定 //products 目錄的藍圖，並大幅減少 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 Team

社群媒體化：

這個 RFC 於內部以文件形式進行，與許多機構成員合作，包括列為諮詢團隊的團隊和 Fuchsia 工程委員會。

詞彙解釋

系統

editeditedit這代表一個可開機的 Fuchsia 映像檔，但不需要所有要刷新至實際工作環境中目標 (例如復原映像檔) 的元件。

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

產品

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

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

桌遊

從現有說明文件中，「白板」定義了建構作業產生的架構，以及執行建構作業所需的裝置主要功能。這項設定會影響內含的驅動程式，同時也可能會影響裝置專用的核心參數。」

Fuchsia 建構參數是由 (產品、板) 元組指定。這組參數完整說明建構系統產生可刷卡產品映像檔時必須完成的工作。

目標

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

• 針對目前產品定義的現有使用者盡量減少遷移工作量，因此，移除 core 和 terminal 應盡可能簡化這些產品目前的使用者

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

• 簡化產品定義，簡化維護工作

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

• 定義新產品定義的使用方式、加入時機，以及我們在哪些情況下新增全新的產品定義

• 可能的話，請勿從根本變更產品的定義或主面板定義方式。確保在中期內能達成範圍

相關規定

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

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

• //products 中的所有產品都應以 SDK 隨附圖片的形式發布，且在樹狀結構中和外均均適用

• 讓測試不必在平台中新增內容即可執行產品。測試應能將其依附元件做為子套件加入自己的套件中。舉例來說，//bundles/buildbot:foo 應該只包含測試，而不應在產品或平台定義中加入任何資訊。

非目標

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

• 變更開發工作流程，而非替換產品定義。這個 RFC 只與產品定義的內容有關。

設計

本文件中的重要字詞「必須」、「不得」、「必要」、「應」、「不應」、「應該」、「不應該」、「建議」、「可能」和「選用」均以 IETF RFC 2119 說明描述。

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

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

我們期望「大部分」Fchsia 測試應在中型字詞中執行 minimal_eng，因為大部分的 Fuchsia 測試都應該以密封的方式封裝所有依附元件。

如果特定測試需要在依賴系統直接提供的服務 (而非獨立套件以外的版本) 的情況下執行，我們應該避免建立一般的樹狀產品中進行測試來進行測試。該測試應在其主要用於測試功能的產品上執行，或者定義專屬的私人樹狀結構外產品定義來執行。我們將不再針對所有可能的功能製作及維護通用的「測試產品」。與其使用只用於測試的產品，我們應優先為對客戶或開發人員較為實用的產品新增測試支援。

這表示在預設情況下，fuchsia.git 中的所有功能都不會存在於樹狀結構內產品的基本設定中。我們應偏好針對我們的產品建立整合和單元測試，而不要將所有功能加入平台支援產品並永久支援。

要保留的產品定義

bringup.gni

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

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

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

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

極簡 - 保持精簡

預期是「我們同樣稱為 Fuchsia 的最小單位」。也就是我們所稱之 Fuchsia 最小的系統，這個系統可以：

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

在 Fuchsia 專案中，這項產品的主要用途將執行包含所有依附元件的全方位套件測試。這也可以做為系統測試的基礎，但由於測試過程不具密義，但僅僅仰賴其中一部分的 Fuchsia 服務。

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

minimal 將支援下列項目：

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

建議使用 minimal_eng 來執行測試，且將僅因為是 _eng 設定而完全納入：

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

我們無意納入以下內容：

• 鋪路支援或 Zedboot
• 圖形支援
• 音訊支援
• 輸入支援
• 虛擬化支援
• 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 將是本機開發的產品設定，執行無法或不應該以草皮方式封裝的大型測試，以及執行比 minimal 支援的更多 Fuchsia 平台部分。它就像是文字的工作台，可支援開發工具，並可讓開發人員叫用系統並進行變更。並不能將產品當做運送給使用者，或做為產品的基礎。

除了 minimal 內含的功能外，我們預計 workbench 也將支援圖像、音訊和輸入支援 (觸控、滑鼠和鍵盤)。這樣一來，就能啟用完整的系統驗證測試來模擬圖形產品 (硬體加速影片解碼器和 DRM/受保護的記憶體除外)。

如果針對建構作業設定的面板支援 WLAN 和藍牙，我們也會在 workbench 版本中納入 WLAN 和藍牙支援。

這項產品會提供目前的 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？

我們預期會在 workbench 中新增元件，當該元件會用於支援圖像和音訊的所有 Fuchsia 產品中，或者大部分樹狀結構內的 Fuchsia 開發人員會因為將其納入測試流程或日常開發而受益。

例如：

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

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

部分 FIDL 通訊協定 (例如 fuchsia.web) 是由平台定義，實作項目並非來自平台。由於這些實作方式可能會改變，且平台通常不含實作這些通訊協定的元件，因此我們需要在實作這些通訊協定的元件拓撲中，為產品提供一個位置。

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

要移除的產品定義

我們將逐步遷移使用者的各項產品定義，然後刪除定義。

core.gni

從本 RFC 開始，core 及其所有子定義都已淘汰。

廣泛用於 Fuchsia 的基礎架構，以及由 Fuchsia 開發人員在他們的辦公桌前使用。這個系統遠比「Fuchsia 最小的功能」還大，當中包含藍牙工具、WLAN 工具、驅動程式遊樂場、音訊、Starnix 管理員、測試管理工具、支援模糊化作業、其他可變動的虛擬儲存空間、其他虛擬機器都支援、其他虛擬作業。

我們的看法是，core 是針對特定情況提供的實用產品，但針對產品應包含的「所有」 Fuchsia 產品基礎，都提供太多不同的意見。

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

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 完成後進行測試，我們應在 workbench 中加入 netstack2，並透過 core_with_netstack3 等新的產品定義 (如 core_with_netstack3) 修改 workbench 或藉由引數給 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 開發
  • 我們會將第一方 Starnix 開發的主要開發目標替換為 //vendor/google 中的內部產品，但仍可使用套件伺服器在 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 上運作良好

工作台

• 請定義不依據 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's Law 的情況再次遭到裁剪。特別是以下做法：

• 請讓解析器只存取自己的測試套件及其子套件，以免測試解析自身測試領域外的套件。這項功能目前適用於在測試管理員的密封測試領域中執行的測試，但我們仍需將舊的測試移植至新架構。
• 在測試中更廣泛地使用子套件：如果目前依賴的獨立套件，可能未來應該以子套件納入測試中。

所有在服務相關密面的密封包裝測試都可以針對 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 和子產品

系統正在將 workstation 從 Fuchsia 的 CI 中刪除，不過，目前仍在 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 和所有變化版本未變更。

這表示我們仍需維護這些產品設定，並執行作業，例如為核心領域提供合理的理性，或將產品遷移至以裸機為基礎的組裝，需要在大量支援的產品上複製。隨著時間推移減少少量產品設定，對於維護產品設定、組合和建構核心部分的團隊來說，會大幅簡化。

由於我們許多現有客戶使用這些產品時，對工作站的需求也較低，因此是簡化支援設定的最佳時機。

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

我們可以在樹狀結構外存放區中建立 workbench (類似 RFC-0095 中的提案)，因為許多測試都能以神奇的方式封裝並在 minimal 上執行。不過，許多測試和用途都會依賴圖形或音訊，或不想提取其他 OOT 依附元件，因此，我們必須有這些內容才能執行樹狀結構內圖像和音訊測試。最後，會與 workbench 等設定已在樹狀結構的其他位置中檢查。建議直接在 //products 目錄中進行維護。

先前的圖片和參考資料

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