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 directory 中的商品配置集。

设计初衷

//products 目前包含 10 个商品定义。自从这些产品定义创建以来，Fuchsia 已经发生了显著变化，这些产品的用户变得越来越分散。有些产品只有几个用户或用例，或者具有只存在于该产品中的界面堆栈等独特功能。更改产品组装、构建系统、图形或网络堆栈等交叉功能时，需要考虑每个产品及其差异。这不仅会耗费开发者的时间和精力，还会减慢平台的发展速度。

//products 目录也没有明确的路线图或目的声明。README 中并未明确说明该目录中的产品为何存在、这些产品适用于哪些人或谁负责维护。由志愿者组成的临时志愿者负责关注产品定义并提供产品定义，并且没有明确的授权。

与其在平台源代码树中大量具有特定用例的产品，Fucsia 应更倾向于使用较少的严格限定范围的产品定义，以提供参考实现和示例来说明如何基于树 (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 团队
• 驱动程序开发团队
• 启动团队

社交化：

此 RFC 已在内部以文档形式与很多组织成员进行社交，包括列为“已咨询”的团队和 Fuchsia 工程委员会。

术语库

系统

editeditedit这表示可启动的 Fuchsia 映像，但不包含我们想要在生产环境中刷写到目标的所有内容（例如恢复映像）。

如需详细了解启动槽和可刷写的映像，请参阅 RFC-0115。

产品

我们的现有文档：“产品定义了 build 将生成的软件配置。最重要的是，产品通常会定义所提供的用户体验类型，例如用户可能会观察到的图形 shell 的类型、是否包含多媒体支持等。"

在我们的产品组装流程的输出中，产品定义旨在放置在目标上的一个或多个系统（位于槽位 A、B 和/或 R）的组合。例如，产品映像可能包含内核映像、FVM、vbmeta、恢复映像、恢复 vbmeta 和引导加载程序映像。

主板

我们的现有文档指出：“开发板定义了 build 所生成的架构以及运行 build 的目标设备的关键功能。此配置会影响包含的驱动程序，还可能会影响特定于设备的内核参数。"

Fuchsia 构建参数由（产品、开发板）元组指定。这组参数完整描述了构建系统为了生成可刷写的产品映像而必须完成的工作。

目标

• 尽可能减少 Fuchsia 团队在一段时间内支持的产品定义数量，以最大限度地减少开发者和基础架构的负载

• 尽可能减少现有产品定义的现有用户的迁移工作量 - 对于这些产品的当前用户来说，迁移 core 和 terminal 应尽可能简单

• 请移除不再代表 Fuchsia 平台预期用途的产品定义，或使用已弃用的配置

• 简化保留的产品定义，使其更易于维护

• 对于仍然存在的产品定义（bringup 除外），请实现 build 类型，以便正式版产品在实现自己的版本时可以引用适当的 build 类型

• 定义应如何使用新的商品定义、何时应添加新的商品定义，以及在什么条件下应添加全新的商品定义

• 如果可能，请勿从根本上更改产品的定义方式或板的定义方式。保持在中期可以实现的范围

要求

• 我们必须支持内核和新板开发，而无需自定义产品定义。

• 所有产品都必须在基础架构中自动进行测试

• //products 中的所有产品都应作为 SDK 配套图片分发，并且在树内和树外均可获得同样的效果

• 避免测试需要向平台添加内容以在产品上运行。测试应该能够将其依赖项作为子软件包导入自己的软件包。例如，//bundles/buildbot:foo 应仅包含测试，而不应在产品或平台定义中添加任何内容。

非目标

• 重新构建或重新定义开发板、build 类型和产品的交互。 此 RFC 应尽可能关注 //products 的内容及其用途。

• 除了替换产品定义之外，还可以更改开发工作流程。此 RFC 仅关注商品定义的内容。

设计

本文档中的关键字“必须”“不得”“必需”“会”“不会”“应”“不应”“建议”“可以”和“可选”应按 IETF RFC 2119 中的说明进行解释。

目前，//products 中有 10 个商品定义。我们将逐步移除其中 8 个乘积定义，保留 2 个（minimal 和 bringup），然后再添加 1 个：workbench。目前，我们仅创建 minimal 和 workbench 的 _eng build 类型，但日后可能会根据需要添加 _user 和 _userdebug build 类型。

当前的许多定义都支持测试流程，并且包含其特定的软件包和配置，因为测试直接依赖于系统映像中包含的服务，而不是将其依赖项与它们的依赖项一起放入自己的软件包中。

我们希望大多数 Fuchsia 测试在中期都应在 minimal_eng 上运行，因为大多数 Fuchsia 测试都应与其所有依赖项密封封装。

如果特定测试需要在依赖由系统直接提供的服务（而不是运行自身软件包的版本）时运行，那么我们应避免创建通用树内产品进行测试。该测试应该在要测试其功能的产品上运行，或者应该定义自己的私有树外产品定义来运行它。我们将不再为针对所有可能功能的测试创建并维护通用的“测试产品”。我们应该更倾向于为对客户或开发者更常用的产品添加测试支持，而不是使用仅用于测试的产品。

这意味着，默认情况下，并非 fuchsia.git 中的所有功能都会存在于树内产品的基本配置中。我们应该更喜欢创建可以在我们拥有的产品上封闭运行的集成和单元测试，而不是向平台支持的产品添加所有功能并永久支持这些功能。

要保留的产品定义

bringup.gni

目前主要由内核开发者使用。bringup 用于测试内核和核心驱动程序，以及在新开发板上进行开发。

我们打算让 bringup 保持其用途和内容不变，但使其改用产品组件。我们不再打算将 bringup 用作所有已定义产品的“基类”，因为启动具有某些不适用于所有产品的功能。

要添加或改编的商品定义

//products 中其余的产品定义将由 Fuchsia 架构和软件组装团队共同拥有。日常维护将由 Software Assembly 完成。

极简 - 保留，尽量精简

旨在是“我们依然称之为紫红色的最小产品”。从定义上看，我们仍要称之为 Fuchsia 的最小系统，它能够：

• 启动到用户空间
• 运行组件管理器和组件
• 使用我们的无线下载更新系统自行更新
  • 这意味着存储和网络运行正常， 且单板提供的驱动程序由主板提供，

对于 Fuchsia 项目，此产品的主要用途是运行封闭封装的测试，其中包含其所有依赖项。它还可以用作非封闭系统测试的基础，这些测试仅依赖于其包含的一小部分 Fuchsia 服务。

我们将 minimal 定义为 _eng build 类型，但目前不会创建 minimal 的 _user 或 _userdebug 版本。产品组合中的所有产品定义都必须是 _eng、_userdebug 或 _user 中的一个。因此，本文档其余部分对 minimal_eng 和 minimal 的所有引用均等效。

minimal 将支持：

• 组件
• 软件包，以及对系统进行 OTA 更新的功能
• 通过 fastboot 刷写系统
• 驱动程序框架和数量非常少的驱动程序（最好为零；我们应该更倾向于在板定义（而不是产品定义）中添加驱动程序，除非所有 Fuchsia 产品都需要这些驱动程序）
• 日志记录
• 网络（如果板没有其他网络功能，则可以包括 USB CDC 以太网）
• 存储空间
• 会话支持（但未指定会话）
  • 会话将在运行时使用 ffx session launch 在 eng build 上添加。
• 上述功能的大小限制支持

minimal_eng 将是运行测试的推荐配置，由于是 _eng 配置，因此包含的并非详尽无遗：

• SSH 支持
• 遥控器服务支持
• 测试管理器

我们不打算包含以下内容：

• 通过 zedboot 支持铺路（不过 paver 服务需要处理正在运行的 Fuchsia 映像才能启用 OTA）
• 图形支持
• 音频支持
• 输入支持
• 虚拟化支持
• WLAN 支持
• 蓝牙支持

注意：虽然 minimal 在基础中不支持这些功能，但仍然可以在封闭打包的测试中的 minimal_eng build 上测试它们，因为所有 _eng 产品 build 都包含测试支持。例如，即使屏幕上不会显示任何图形，图形测试也可以对 Fuchsia 界面子系统和硬件虚假对象（由 test_ui_stack 提供）进行子打包，并在 minimal_eng 上运行。我们将鼓励所有测试在 minimal_eng（而非 workbench）上运行（如果可以这样做），因为 minimal_eng 由于体积更小而构建时间更短，可调试性更高。

应在何时将平台组件添加到 minimal？

如果 minimal 中包含的 Assembly Input Bundle 支持 minimal 产品的核心目标，平台开发者应向该组件添加一个组件。例如，应将 Fuchsia 的新默认文件系统添加到 minimal，因为 OTA 更新需要文件系统，而 minimal 应使用默认 Fuchsia 文件系统。如果打算在所有 Fuchsia 产品中使用一个新的驱动程序框架，则应将新的驱动程序框架添加到 minimal。不应将新的图形驱动程序或控制系统添加到 minimal，因为并非所有 Fuchsia 系统都需要图形来启动或更新系统。

我们有两个压力测试，用于明确确定 minimal_eng 中是否应包含给定组件：

1. 该组件是否应包含在所有采用 _eng build 类型的紫红色产品中？
2. 如果没有 minimal，是否将无法使用？

如果某个平台组件不应过度使用，它可能仍适合 workbench。

minimal地区的司机

如果在所有开发板上支持 OTA 或运行组件管理器至关重要，我们应该在 minimal 的平台配置中包含对驱动程序堆栈的支持。这意味着，即使运行 minimal 的开发板提供蓝牙支持，我们也不应该在生成的配置中包含该驱动程序堆栈，因为产品不需要它。

这意味着在设计时，最终映像中包含的一组驱动程序是产品请求的功能与板的硬件支持之间的交集。此交叉功能正在与软件组装团队一起开发。

工作台

workbench 将是用于本地开发的产品配置，用于运行无法或不应密封打包的大型测试，以及执行比 minimal 支持的更大的 Fuchsia 平台部分。它就像一个文字工作台，因为它支持开发工具，并允许开发者对系统进行标记并进行更改。它既不是一款向用户配送的产品，也不是这些产品的基础。

除了 minimal 包含的功能之外，我们打算在 workbench 中纳入图形、音频和输入支持（触摸、鼠标和键盘）。这将启用模拟图形产品的完整系统验证测试（硬件加速视频解码器和 DRM/受保护内存除外）。

我们也将在 workbench build 中添加 WLAN 和蓝牙支持（如果为 build 配置的开发板支持这些功能）。

此产品将满足当前 workstation 和 terminal 产品的大多数用途，但维护费用低得多。例如，当前在 core 上运行的许多测试都需要在 workbench 上运行，因此 workbench 将能够使用 --with //bundles/buildbot:core 的等效项进行构建，以创建可用测试的软件包代码库。

workbench 将具有改编自 tiles-session 的默认会话，但默认情况下不会启动任何元素。这样即可对不同的图形元素（如图形演示或终端）进行交互式测试和调试。默认情况下，需要不启动会话的软件或测试将能够使用运行时配置来停用启动。

workbench 不会将 Flutter 或 Chrome 等运行时作为基础软件包，但它们能够从软件包服务器中按需加载以进行开发。

workbench 将使用与 minimal 相同的平台定义进行汇编，但会向其添加内容。它不会沿用 minimal 的整个产品配置。

我们将 workbench 定义为 _eng build 类型，但目前不会创建 workbench 的 _user 或 _userdebug 版本。产品组合中的所有产品定义都必须是 _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 管理器、测试管理器、对存储机制、支持所有短期存储、支持虚拟化支持的功能等。

我们认为，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 开发者的便捷产品，以及在基础架构中进行自动化测试。我们应该在 workbench 中包含 netstack2，以便在 netstack3 完成时进行测试，并提供一个构建时开关，以便通过修改 workbench 的新产品定义（如 core_with_netstack3）或通过基础架构配方中定义的 GN 或 Bazel build 的参数来启用 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

它曾用作驱动程序框架版本 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 添加依赖项（大致按此优先级顺序）。

以下是实施计划的草图：

• 确定依赖项。已知的从属实体：
  • 平台树中的性能测试
  • 紫红色的 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 流失政策自行完成大部分迁移工作。

安全注意事项

我们不打算或预计会因为此 RFC 的实现而发生重大的安全性更改。只要保持较少的产品配置，我们的安全状况就会得到改善（如果有的话）。

我们的所有新产品均不得提供给用户或在生产环境中使用。这些产品应尽可能安全地实现 Fuchsia 配置。_eng 变体会自然允许进行一些操作，例如添加 core 和 terminal 等当前产品已默认允许的软件包代码库。

隐私注意事项

我们的任何新产品均不得提供给用户或在生产环境中使用，也不得用于任何个人信息。我们不认为与这些新产品相关的隐私权问题。

测试

测试此 RFC 的实现非常简单：我们当前包含树内和树外的所有测试仍然应该通过。某些服务可能需要进行迁移，以依赖于不同的服务实现、模拟或虚构服务。不过，我们应该实现与目前相同的测试覆盖范围，我们不应为了实现此 RFC 的目标而停用测试套件。

文档

我们将更新 //products 目录中的文档，其中介绍了每个产品的用途。如果开发者希望增加测试覆盖范围，说明应该针对哪些产品进行测试，以及如何使用这些产品，我们将添加相关文档。

在执行移除操作时，我们会移除或修改 fuchsia.dev 上与 workstation 以及我们要移除的其他产品相关的文档。包含已移除或重命名的产品的教程或 Codelab 将随着我们的变更而更新。

我们将更新 RFC-0095，以表明此 RFC 将取代该 RFC，并且我们目前不会基于树构建 workstation 或其后继 workbench。

缺点、替代方案和未知问题

缺点：基础架构工作负载暂时增加

从 terminal 和 core 转换到新产品定义意味着，我们需要在从旧产品构建过渡的同时运行新的产品构建器。这将增加基础架构负载，直到我们删除旧产品定义的构建器为止。这可能会导致我们在过渡期间影响开发者体验。

替代方案：不执行任何操作

此 RFC 的主要替代方法是减少操作。我们可以移除 workstation，让 core、minimal、terminal 及其所有变体保持不变。

这意味着我们仍然需要维护这些产品配置，并且我们需要在更多受支持的产品中复制我们所做的工作，例如合理化核心领域，或将产品迁移到基于 bazel 的组装。对于维护产品配置、组装和构建核心方面的团队而言，随着时间的推移，产品配置的数量会越来越少。

由于我们重新调整了工作站的优先级，因此这些产品的许多现有客户需求都较低，因此现在是简化我们支持的配置的最佳时机。

替代方案：在树外创建工作台

我们可以在树外代码库中创建 workbench（类似于 RFC-0095 中的提案），因为我们的许多测试都可以封闭封装并在 minimal 上运行。不过，许多测试和用例依赖于图形或音频，或者不希望引入其他 OOT 依赖项，并且无论如何，我们需要一些工具来运行树内图形和音频测试。最终，我们会将类似 workbench 的配置签入某处的树中。最好的做法是将其保存在 //products 目录中。

先验技术和参考资料

已在文档的相关点链接。