RFC-0220：树内产品的未来

RFC-0220：树内产品的未来
状态已接受
领域
  • 常规
  • 软件组装
说明

用于简化开源 //products 目录中产品配置集的提案。
问题
Gerrit 更改
  • 831920
作者
审核人
提交日期（年-月-日）2022-04-06
审核日期（年-月-日）2022-06-13

修改此 RFC

修改 RFC 元数据

总结

旨在简化开源 //products directory 中产品配置集的提案。

设计初衷

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

//products 目录也没有明确的路线图或目的声明。README 中不清楚该目录中的产品为什么存在、它们适用于哪些对象或者由谁维护。一个专门的志愿者团队关注并完善产品定义，但其没有明确的授权。

Fuchsia 不应在平台源代码树中包含大量具有特定用例的产品，而应首选数量较少的产品定义，这些产品定义提供参考实现和有关如何从树创建产品 (OOT) 的示例。

现在是时候为 //products 目录制定路线图，并显著减少 Fuchsia 产品定义的用户群碎片化问题。

利益相关方

  • 基础架构
  • Fuchsia 工程委员会
  • 产品管理
  • 我们建议修改或移除的商品的用户
    • 工作站
    • 最终 build
    • Core
  • 软件组装
  • Build

教员：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 工程委员会。

术语库

系统

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

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

产品

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

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

桌面和棋类游戏

根据我们的现有文档：“主板”定义了 build 所针对的架构以及运行该 build 的设备的关键功能。此配置会影响包含的驱动程序，还可能会影响特定于设备的内核参数。”

Fuchsia 构建参数由 (product, board) 元组指定。这组参数完整描述了构建系统为了生成可刷写的产品映像而必须完成的工作。

目标

  • 尽量减少 Fuchsia 团队长期以来必须支持的产品定义数量，最大限度地减少开发者和基础架构的负载。

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

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

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

  • 对于保留的产品定义（bringup 除外），请实现 build 类型，以便正式版产品在实现自己的版本时可以引用相应的 build 类型

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

  • 如果可能，不要从根本上更改产品或主板的定义方式。确保范围在中期可实现

要求

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

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

  • //products 中的所有产品都应作为 SDK 随播图片分发，且在树中和树外都能正常工作

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

非目标

  • 重新构建或重新定义主板、build 类型和产品的互动。 此 RFC 应尽可能重点介绍 //products 的内容及其用途。

  • 改变开发工作流，而不仅仅是替换产品定义。此 RFC 仅与产品定义的内容相关。

设计

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

我们今天在//products中有 10 个商品定义。我们将逐步移除其中 8 个产品定义，保留两个（minimal、bringup），然后继续添加 1 个：workbench。我们目前只会创建 minimal 和 workbench 的 _eng build 类型，但未来可能会根据需要添加 _user 和 _userdebug build 类型。

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

我们计划，大多数 Fuchsia 测试中期都应在 minimal_eng 上运行，因为大多数 Fuchsia 测试都应与其所有依赖项打包在一起。

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

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

要保留的商品定义

bringup.gni

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

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

要添加或改作他用的产品定义

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

尽量少 - 保持，尽量少

旨在是“我们仍然可以称之为‘紫红色’的最小装置。”从定义上说，我们仍然可以称之为 Fuchsia 的最小系统，它是一个具有以下特点的系统：

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

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

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

minimal 将支持：

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

minimal_eng 是建议运行测试的配置，但由于是 _eng 配置，因此并非详尽无遗：

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

我们无意包含以下内容：

  • 铺路支持或 zedboot
  • 图形支持
  • 音频支持
  • 输入支持
  • 虚拟化支持
  • WLAN 支持
  • 蓝牙支持

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

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

如果平台开发者在支持 minimal 产品的核心目标时，应该向 minimal 中包含的汇编输入 Bundle 中添加组件。例如，应将新的 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 配置的开发板支持 Wi-Fi 和蓝牙，我们还将在这些 build 中提供 Wi-Fi 和蓝牙支持。

该产品将支持当前 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？

在以下情况下，我们应向 workbench 添加组件：预计该组件将用于支持图形和音频的所有 Fuchsia 产品，或者大多数树内 Fuchsia 开发者可从纳入测试流程或日常开发中受益。

例如：

  • 我们添加到 minimal 的所有内容也应添加到 workbench
  • 我们应在其默认配置中添加新的图形、音频以及常规 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。我们将通过子软件包等技术、封闭的集成测试以及使用软件交付工具在运行时轻松添加软件来实现这一点。

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 完成时进行测试，并提供构建时开关，以便通过新的产品定义（如 core_with_netstack3，它修改了 workbench）或通过向基础架构方案中定义的 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 开发
    • 我们会将第一方 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 定律。具体而言，我们应该：

  • 通过向解析器提供只访问自己的测试软件包及其子软件包的权限，防止测试解析自己的测试领域之外的软件包。目前在测试管理器下的封闭测试领域运行的测试就是如此，不过我们仍然需要将旧测试移植到新框架中。
  • 在测试中更广泛地利用子软件包 - 如果测试目前依赖于单独的软件包，则将来它可能会再打包到测试中。

所有对服务同样封闭的封闭式测试均可针对 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 运行测试时的目标产品。在实现过程中，我们还可能会帮助将某些测试迁移到其他样式（如前所述，将其与依赖项作为子软件包封闭打包）。

向后兼容性

由于我们呈现的是大多数用户需要的新产品，因此大部分产品定义变更都是向后兼容的。对于要重命名或更改内容的产品的客户，我们将提供软转换和通知期。此外，我们还会根据用户流失政策自行完成大部分迁移工作。

安全注意事项

我们不打算或预见由于此 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 目录中。

早期技术和参考资料

已在文档中的相关点链接。