RFC-0220：树内产品的未来

RFC-0220：树内产品的未来
状态已接受
区域
  • 常规
  • 软件程序集
说明

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

修改此 RFC

修改 RFC 元数据

摘要

旨在简化开源 //products 目录中的产品配置集。

设计初衷

//products 目前包含 10 个产品定义。自创建这些产品定义以来，Fuchsia 发生了显著变化，相应产品的用户也变得分散。有些产品只有少数用户或用例，或者具有仅在该产品中存在的特殊功能（例如界面堆栈）。对产品组装、build 系统或图形/网络堆栈等跨领域功能进行更改时，需要考虑每个单独的产品及其差异。这会浪费开发者的时间和精力，并减缓平台的发展速度。

//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 团队
  • 驱动程序开发团队
  • 启动团队

共同化：

此 RFC 以文档形式在组织内部进行了广泛宣传，包括列为“咨询”的团队和 Fuchsia 工程委员会。

术语库

系统

系统是一组映像（ zbi ) 旨在用于目标设备上的单个启动 slot。这表示可启动的 Fuchsia 映像，但缺少我们想要刷写到生产环境中的目标设备的所有内容（例如恢复映像）。

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

产品

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

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

桌面和棋类

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

Fuchsia build 参数由（产品、主板）元组指定。这组参数完整地描述了 build 系统必须完成的工作，才能生成可刷写的产品映像。

目标

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

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

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

  • 简化保留下来的产品定义，以便更轻松地进行维护

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

  • 定义新产品定义的使用方式、添加时间以及在什么条件下添加全新的产品定义

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

要求

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

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

  • //products 中的所有产品都应作为 SDK 随附映像分发，并且在树内和树外都能正常运行

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

非目标

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

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

设计

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

我们目前在 //products 中有 10 个产品定义。我们将在一段时间内移除这八个产品定义，保留两个 (minimal、bringup)，并添加一个：workbench。目前，我们只会创建 minimal 和 workbench 的 _eng build 类型，但如果需要，未来可能会添加 _user 和 _userdebug build 类型。

许多当前定义的存在是为了支持测试流程，并且包含其特定的软件包和配置，因为测试直接依赖于系统映像中包含的服务，而不是在自己的软件包中携带依赖项。

我们打算在中期让大多数 Fuchsia 测试在 minimal_eng 上运行，因为大多数 Fuchsia 测试都应以密封方式打包，包含所有依赖项。

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

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

要保留的产品定义

bringup.gni

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

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

要添加或重新利用的产品定义

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

极简 - 保留，尽可能极简

旨在成为“我们仍会称之为 Fuchsia 的最小事物”。从定义上来说，我们仍会称之为 Fuchsia 的最小事物是一个可以执行以下操作的系统：

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

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

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

minimal 将支持：

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

minimal_eng 将是建议用于运行测试的配置，并且由于是 _eng 配置，因此会非详尽地包含：

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

我们无意包含以下内容：

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

注意：虽然 minimal 不会在基础中包含对这些功能的支持，但仍可在密封封装的测试中针对 minimal_eng build 对这些功能进行测试，因为所有 _eng 产品 build 都包含测试支持。例如，图形测试可以对 test_ui_stack 提供的 Fuchsia 界面子系统和硬件伪造件进行子软件包化，并在 minimal_eng 上运行，即使屏幕上不会显示任何图形。如果所有测试都能在 minimal_eng 上运行，我们会鼓励它们这样做，因为 minimal_eng 更小，因此 build 时间更短，可调试性更强。workbench

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

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

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

  1. 该组件是否应位于 _eng build 类型的所有 Fuchsia 产品中？
  2. 没有它，minimal 是否无法使用？

如果某个平台组件不应放入最小配置中，则很可能仍适合 workbench。

minimal地区的司机

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

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

workbench

workbench 将是本地开发的产品配置，用于运行无法或不应密封打包的较大测试，并运行比 minimal 支持的更大的 Fuchsia 平台部分。它旨在成为一个真正的工作台，支持开发工具，并允许开发者探测系统并进行更改。它并非旨在成为面向用户的产品，也不是此类产品的基础。

我们希望 workbench 除了包含 minimal 所包含的功能之外，还包括图形、音频和输入支持（触控、鼠标和键盘）。 这样一来，便可进行完整的系统验证测试，以模拟图形产品（硬件加速视频解码器和 DRM/受保护的内存除外）。

如果为 build 配置的板支持 WLAN 和蓝牙，我们也会在 workbench build 中包含 WLAN 和蓝牙支持。

此产品可满足当前 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 实现的产品所有者或开发者可以在 build 期间使用 --with-base，将实现放置在 Fuchsia 软件包服务器中以便在运行时加载，或者我们可以在产品 assembly 配置中直接添加对指定产品提供的实现的支持。

要移除的产品定义

我们会逐步将用户从这些产品定义中迁移出来，然后删除这些定义。

core.gni

自此 RFC 发布之日起，core 及其所有各种子定义均已弃用。

广泛用于 Fuchsia 的基础设施，并由 Fuchsia 开发者在办公桌上使用。这远大于“我们称为 Fuchsia 的最小事物”，并且包含 蓝牙工具、WLAN 工具、驱动程序 Playground、音频、Starnix 管理器、测试管理器、模糊测试支持、虚拟化支持、SSH 支持、用于管理短期可变存储空间的实用程序，以及许多其他并非所有产品都需要的东西。

我们认为，core 在某些情况下是一款有用的产品，但它包含太多关于产品应包含哪些内容的武断选择，因此不适合作为所有 Fuchsia 产品的依据。

我们计划随着时间的推移，将基础架构和开发者从 core 转移到 minimal 和 workbench，并最终删除 core。我们将通过子软件包、密封集成测试等技术，以及使用软件交付工具在运行时轻松添加软件来实现这一目标。

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，是因为在 build 时（即使用 GN 实参）修改 core 映像的方法非常多，因此对主要核心映像设置大小限制是不切实际的。minimal 的部分目的是在 build 时不可修改，并且仅以一种配置提供，因此大小限制应是 minimal 配置的组成部分。

注意：我们希望大小检查不要依赖于特定的产品定义。例如，如果我们能够跟踪平台组件组的大小随时间的变化，而不依赖于特定的产品配置，那就太好了。不过，目前还没有这种功能，因此我们建议暂时针对 minimal_eng 进行大小检查。因此，报告的总体映像大小会受到开发者工具等非生产软件包的影响，但也会提供生产软件包的大小。

core_with_netstack3.gni

用作 netstack3 开发者的便利产品，并用于基础架构中的自动化测试。在 netstack3 完成之前，我们应在 workbench 中包含 netstack2 以进行测试，并提供 build 时开关，以通过修改 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 开发
    • 我们将使用内部产品替换第一方 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 上运行良好

workbench

  • 定义一种不基于 GN 继承（因为我们不会使用 GN 来定义产品，请参阅 RFC-0186）的方法，以在 minimal 的平台定义之上组合 workbench，确保这两个产品不会出现差异。
  • 确保 workbench 在 NUC、VIM3、Google Compute Engine 和 FEMU 上运行良好。
  • 让系统验证测试正常运行
  • 为希望在运行时向 tiles-session 添加元素以运行图形终端等内容的开发者提供支持和文档。

迁移用户并移除已弃用的产品定义

首先：改进了对子软件包的支持，并随 SDK 分发软件包

许多此类迁移将依赖于对在树外创建子软件包的支持，以及我们用于在树内和树外支持完全密封的集成测试的工作流。我们必须先实现此功能，然后才能大规模迁移。

我们还必须能够分发树外的软件包，这在 RFC-0208 中已涵盖。

其余工作流可以彼此并行运行。

核心和 core_size_limits

此产品定义可能最难让用户放弃，因为无论是在树内还是树外，其用户数量都是最多的。

由于之前对测试的密封性要求宽松，许多测试现在依赖于 core 产品定义的某些方面。例如，测试可能会解析它知道位于 core 中的基本集内的软件包。在从 core 迁移为测试产品时，我们应防止再次出现这些 Hyrum 定律的实例。具体而言，我们应该：

  • 通过为测试提供仅可访问其自身测试软件包及其子软件包的解析器，防止测试解析其自身测试领域之外的软件包。目前，在测试管理器下于密封测试领域中运行的测试存在此问题，不过我们仍需将旧测试移植到该新框架。
  • 在测试中更广泛地使用子软件包 - 如果某个测试目前依赖于单独的软件包，那么未来应该将其子软件包化到测试中。

所有以封闭方式打包且在服务方面也是封闭的测试都可以针对 minimal 未经修改地运行。我们应尽快将尽可能多的树内测试移至 minimal 上运行，并为允许在 core 中运行的测试建立许可名单，以防止更多测试依赖于 core 的配置。

在为 core 的用户创建许可名单后，我们会与这些测试的所有者联系，以便使用上述最佳实践将这些测试迁移到 minimal 或 workbench。

树外用户将是另一个挑战，因为我们无法轻松地枚举他们或他们的测试。我们将与每位花瓣所有者单独合作，确定他们对 core 的使用情况，以及他们是否可以迁移到 minimal 或 workbench。如果这些产品在不进行更改的情况下无法移动，我们可以按照周转政策进行更改，或者专门为这些 petal 的测试创建树外产品。

终端

terminal 可能是我们最复杂的移除对象，因为它是除 workstation 之外最复杂的开源产品，并且拥有许多用户。此 RFC 并不声称拥有针对 terminal 的完美完整迁移计划，但它确实承诺 Fuchsia 组织将通过以下方式支持客户迁移：通过使用子软件包实现 OOT 密封测试、添加 OOT 产品以进行测试，或向 workbench 添加依赖项（大致按优先级顺序）。

下面是实现计划的草图：

  • 确定受抚养人。已知依赖项：
    • 平台树中的性能测试
    • Fuchsia 上的 Chromium
    • Fuchsia 上的 Flutter
    • Antlion 构建器
  • 这些依赖项可能正在使用 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 变动政策自行完成大部分迁移工作。

安全注意事项

我们不打算或预计因实施此 RFC 而导致重大安全变更。如果说有什么变化，那也应该是由于维护的产品配置减少，我们的安全状况有所改善。

不得将任何新产品提供给用户或在正式版中使用。这些产品应尽可能实现安全的 Fuchsia 配置。 _eng 变体将自然而然地允许添加软件包代码库等操作，而 core 和 terminal 等当前产品默认已允许这些操作。

隐私注意事项

不得将任何新产品提供给用户或用于生产，也不得用于任何个人信息。我们认为这些新产品不存在隐私权问题。

测试

测试此 RFC 的实现非常简单：我们目前在树内和树外的所有测试都应仍然通过。有些可能需要迁移到不同的服务实现、模拟对象或伪对象。 不过，我们应实现目前相同的测试覆盖率，并且不应停用测试套件来实现此 RFC 的目标。

文档

我们将更新 //products 目录中的文档，其中说明了每种产品的用途。我们将为希望添加测试覆盖率的开发者添加文档，说明他们应该针对哪些产品进行测试，以及如何使用这些产品。

在移除 workstation 和其他要移除的产品时，我们会移除或修改 fuchsia.dev 上与这些产品相关的文档。包含已移除或已重命名的产品的教程或 Codelab 将会根据我们的更改进行更新。

我们将更新 RFC-0095，以说明此 RFC 取代了该 RFC，并且目前不会在树外构建 workstation 或其后继版本 workbench。

缺点、替代方案和未知因素

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

从 terminal 和 core 过渡到新产品定义意味着，在停用旧产品构建器之前，我们需要先运行新产品构建器。这会增加基础架构负载，直到我们可以删除旧产品定义的构建器为止。在过渡期间，这可能会对开发者体验造成负面影响。

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

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

这意味着我们仍需维护这些产品配置，并且我们在合理化核心 realm 或将产品迁移到基于 Bazel 的程序集方面所做的工作需要复制到更多受支持的产品中。随着时间的推移，产品配置数量减少，对于维护产品配置、组装和 build 核心方面的团队来说，工作会大大简化。

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

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

我们可以在树外代码库中创建 workbench（类似于 RFC-0095 中的提案），因为我们的许多测试都可以密封打包并在 minimal 上运行。不过，许多测试和使用情形都依赖于图形或音频，或者不想引入另一个 OOT 依赖项，因此我们需要一些东西来运行树内图形和音频测试。最终，我们会在树中的某个位置签入类似 workbench 的配置。最好将其直接保留在 //products 目录中。

在先技术和参考资料

链接位于文档中的相关位置。