简介

AOSC OS 于 2020 年秋季结束了季度性迭代模式，开始了基于“主题”的新维护模式。每个主题会涉及对一个或多个包的改动，例如升级与重构。

缘由

传统迭代模式的限制和不足使开发者日渐面露难色，最终催生了主题制的诞生。以 2020 年春季周期为例，虽然这次迭代没有拖延，但它的代价就是大家合并了更少的修改，而这意味着其余更新必须被迫进入 testing-proposed 和 testing 源中，长草至少三个月后才能和普通用户见面。不仅如此，由于例外包的依赖项同样是例外包，这些例外包的更新会出现测试不足的情况。

一个简单的对比

主题制的迭代方式废弃了现有的六分支工作流（参考AOSC OS 维护指南（已弃用）），转而将每个包 (如 GNU Nano 5.4) 或每组包 (KDE Applications 20.08) 的更新定义为一个“主题”，而不同主题之间的构建、测试与分发不会相互干扰。

例：若要将 KDE Applications 从 20.04 升级到 20.08，其传统更新流程如下：

这个坐牢型迭代模式不但耗时三个月以上，还会导致其他软件包的更新和 KDE Applications 20.08 混在同一个分支里。消灭了这些弊病的新流程如下：

在新流程中，KDE Applications 20.08 可按照自己独立的时间安排来完成维护，而非按季度规划行事。因为 KDE Applications （应该）会有不少用户，测试便能很快做完，大幅缩短（本来 3 个月的）维护周期。

下面是新流程的细节内容。

定义、规则和流程

本小节会介绍新规相关的定义、规范和流程。

定义

对一个或多个包进行升级、重构或修改的行为即可认定为一个“主题”。每个主题仅包含其变更的最小软件包集合，并拥有与其他主题相独立的调查、讨论、打包、测试、提醒和交付周期，以免影响其他主题的交付。

规范

1. 每个主题必须仅修改其必须修改的包，不可捎带其他无关的包。
   • 若多个包同属一个组织且一同更新，或来自不同上游却高度相似，则可视作该规则的例外情况。例如，一个桌面环境发行新版时可能同时发布大量组件的新版本（如 GNOME 3.38 和 Plasma 5.20 的更新）；一组性质类似的软件包值得一同更新（各种第三方 RIME 数据包）；一个库的更新破坏了大量下游包（Boost 1.73）皆属于此类例外。
2. 主题在合并后不可以原名复活。
3. 主题之间不可形成冲突，也不可要求他人对自己主题变基。
   • 在创建主题前，维护者须提前沟通以解决潜在的跨主题冲突风险。
   • 一旦发现潜在冲突，维护人员应进行讨论，并在必要时推迟有关主题的发起与合并。
   • 若意外造成冲突，维护人员应制定方案，将一个分支变基到另一个分支上。
4. 更新类主题名须遵循 $PKGNAME-$PKGVER 的命名格式（例： nano-5.4）。Git 仓库的分支名即为主题名（如前文中的 nano-5.4）。
   • 非更新类主题的格式为$PKGNAME-$PKGVER-$PURPOSE，依据重构的目的而命名（如gnome-shell-3.38.1-build-fix, gnome-shell-3.38.1-ppc64el-adaptation）。在引入新包时， $PKGVER 字段可以省略（如gnome-shell-ng-new）。
   • 同时修改多个包的主题应以该主题所涉及的关键包命名，如（gnome-3.38 和 boost-1.73）。
   • 在多包多版本大型更新中，主题名应以主要内容、“survey”字段和主题发起日期组成，例如 rime-data-survey-20200928。
5. 主题里的每个包都必须是干净环境下构建的产物。因此，每个包打完后都必须将环境回滚为基础的 BuildKit 环境，才能进行下一个包的构建。
   • 本规范没有例外，强制执行。
6. 发起拉取请求（PR）以接受审阅。
   • 其他维护者会来测试相关软件包，装了 AOSC OS 的用户们也可通过主题管理器（oma topics）参与测试。
   • 测试完成、代码审阅完成后即可合并 PR。
   • 合并后，对 stable 分支重新构建一次，再将构建产物推送至 stable 软件源。主题分支内的临时包会被退休。
7. 测试周期没有固定时长，但一个主题的包如果得到了来自所有架构的测试，即算作测试完成。
   • 若有主题长期得不到测试，往往意味着没人愿意用或维护这些包，因此可以考虑将它们直接退休。
   • 不可因没人测试而直接合并主题。

主题周期

主题制迭代周期的大致步骤如下：

• 调研：找出要更新、修改或重构的软件包。
• 讨论：与其他主题的维护者沟通，看是否会修改别的主题也在修改的软件包，以免阻碍双方的维护。
  • 例如，在更新 Boost 时，Boost 的一切逆向依赖（依赖 Boost 的软件包）基本都需要重构。在此情况下，其他维护者们也需要检查自己正在修改的软件包是否在 Boost 的重构列表里。受影响的非 Boost 主题需要延迟到 Boost 交付后再推进交付，而其他主题则不受影响，正常推进。
• 打包：创建自己的“主题”。
  • 向与主题对应的仓库推送构建好的软件包。
• 审核：创建当前主题的 PR 以让其他维护者审阅相关构建脚本。
  • 遇到不符合软件包样式指南的代码时，审阅者需在 PR 页面标记出需要修改的行，并使用 GitHub 上的 "Request changes" 功能要求维护者参照样式指南修改代码。
• 测试：用 OMA 程序的 topics 子命令打开测试源，试用待测试的软件包。
  • 若该主题所涵盖之软件包在实测中无功能和品质缺陷，主题发起人以外的开发者即可放行当前主题。
• 交付：当主题获批通过后，主题维护者即可合并对应 PR 并面向 stable 分支发起构建和推送软件包。
  • 在上传软件包前，维护者必须在一个干净的 stable 环境中构建当前主题修改的所有软件包。

Stable 分支的保护

stable 分支开了推送保护，无法直接推送提交。对 stable 的一切变更必须以上文所述流程进行。

文档

需适配主题制流程的文档

随着迭代模型走向主题制，如下文档需要做出符合主题制的内容更改：

• 软件包维护入门：进阶教程
  • 分支描述部分需更改；findupd-stable 命令已废弃。
• 软件包维护入门：基础教程
  • 需更改分支描述内容。
• .NET 生命周期策略
  • 需更改分支描述内容。

过时文档

如下文档不适用于主题制流程，现已废弃：

• AOSC OS 维护指南（已弃用）
• 更新周期的例外情况（英文版）
• 稳定频道的补丁发行规则（英文版）