RFC-0220：树内产品的未来

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

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

修改此 RFC

修改 RFC 元数据

摘要

一项提案，旨在简化开源 //products 目录中的产品配置集。

设计初衷

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

//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 但无需获得其批准的人员。

  • 软件组装团队
  • build 团队
  • 效果团队
  • Chromium 团队
  • 驱动程序开发团队
  • 启用团队

社交：

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

术语库

系统

一个系统是一组图像（兹比，维基百科以及可选的自由体积) 指定用于目标上的单个启动槽。这表示可启动的 Fuchsia 映像，但不包含我们希望刷写到生产环境目标的所有内容（例如恢复映像）。

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

产品

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

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

桌面和棋类

现有文档中指出：“开发板定义了 build 的生成目标架构，以及 build 预期运行的设备的关键特性。此配置会影响包含的驱动程序，并且可能还会影响设备专用内核参数。”

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

目标

  • 尽可能减少 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 项目中的主要用途是运行包含所有依赖项的密封打包测试。它还可以作为非密封但仅依赖于其中包含的一小部分 Fuchsia 服务的系统测试的基础。

我们将 minimal 定义为 _eng 构建类型，目前不会创建 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 提供铺路支持（不过，铺路服务需要在运行的 Fuchsia 映像上运行才能启用 OTA）
  • 图形支持
  • 音频支持
  • 输入支持
  • 虚拟化支持
  • WLAN 支持
  • 蓝牙支持

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

何时应将平台组件添加到 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 平台。它就像一个字面意义的工作台，支持开发工具，并允许开发者探查系统并进行更改。它不应作为面向用户分发的产品，也不应作为这些产品的基础。

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

如果为 build 配置的开发板支持 WLAN 和蓝牙，我们还会在 workbench build 中添加 WLAN 和蓝牙支持。

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

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 开发工具和组件
  • 我们不应添加仅适用于一小部分 Fuchsia 产品的组件。例如，我们不应向 workbench 添加相机实现，因为只有部分 Fuchsia 产品将配备相机。
产品提供的平台协议实现（例如 fuchsia.web）

某些 FIDL 协议（例如 fuchsia.web）由平台定义，其实现由平台外部提供。由于这些实现可能会发生变化，并且平台通常不包含实现这些协议的组件，因此我们需要在组件拓扑中提供一个位置，以便产品插入实现这些协议的组件。

具体而言，我们应在 workbench 组件拓扑中留出一个位置来实现 fuchsia.web，而不在树内产品定义中提供实现。希望添加 fuchsia.web 实现的产品所有者或开发者可以在构建期间使用 --with-base，将实现放置在 Fuchsia 软件包服务器中以在运行时加载，或者我们可以添加支持直接在产品组装配置中指定产品提供的实现。

要移除的产品定义

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

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 之所以存在，是因为在构建时有许多方法可以修改 core 映像（例如使用 GN 参数），因此对主核心映像的大小限制不切实际。minimal 的用途之一是，在构建时不可修改，并且只有一种配置，因此大小限制应是 minimal 配置不可或缺的一部分。

注意：我们希望尺寸检查不要依赖于特定的商品定义。例如，如果我们能够在不依赖特定产品配置的情况下跟踪一段时间内平台组件群组的大小，那就太好了。不过，目前还没有此功能，因此我们建议暂时对 minimal_eng 执行大小检查。因此，报告的总映像大小将受到开发者工具等非正式版软件包的影响，但正式版软件包的大小也会显示。

core_with_netstack3.gni

作为面向 netstack3 开发者的便捷产品，以及用于基础架构中的自动化测试。在 netstack3 完成时，我们应在 workbench 中添加 netstack2 以进行测试，并提供一个构建时开关，以便通过修改 workbench 的新产品定义（例如 core_with_netstack3）或通过基础架构方案中定义的 GN 或 Bazel build 参数来启用 netstack3。

terminal.gni

自本 RFC 发布起，terminal 已废弃。

文档中将其描述为“一个具有简单图形界面和命令行终端的系统”。目前，各种 OOT 客户都使用此 API 对具有图形系统的产品运行测试。我们打算将这些用户迁移到 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 上正常运行

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
    • Flutter on Fuchsia
    • 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 流失政策自行完成大部分迁移工作。

安全注意事项

我们不打算也不预计因实施此 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 及其所有变体不变。

这意味着，我们仍然需要维护这些产品配置，并且我们在优化核心领域或将产品迁移到基于 Bazel 的汇编等方面所做的工作需要在更多受支持的产品中复制。随着时间的推移，产品配置数量减少将极大地简化维护产品配置、组装和构建核心方面的团队的工作。

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

替代方案：创建非树型 Workbench

我们可以在树外代码库中创建 workbench（类似于 RFC-0095 中的提案），因为我们的许多测试都可以密封打包并在 minimal 上运行。不过，许多测试和用例都依赖于图形或音频，或者不想拉入其他 OOT 依赖项，而且我们无论如何都需要某种方式来运行树内图形和音频测试。最终，我们会将 workbench 等配置提交到树的某个位置。最好直接在 //products 目录中进行维护。

在先技术和参考文档

在文档的相关位置提供链接。