WIP openSUSE:Factory 开发模型
开发模型
Factory 在其自身的项目 openSUSE:Factory 上，在 开放构建服务参考服务器上构建。正如您所见，它是一个包含大量软件包的巨大仓库。然而，开发并非直接在 openSUSE:Factory 中进行，而是在所谓的 devel 项目 中进行。devel 项目，顾名思义，是针对特定软件包组进行开发的项目。例如 multimedia、GNOME、KDE 或 Kernel。openSUSE:Factory 项目中的软件包与 devel 项目 中的软件包之间的关系，体现在 openSUSE:Factory 内部软件包的元数据中。
Devel 项目
每个 devel 项目 都有其自身的一套流程、规则和通信渠道，以最适合它们的方式。有关此信息的参考点是其构建服务项目的项目描述。Devel 项目 也会发生变化，因为 FOSS 软件的世界在不断发展。某些软件会过时，标准和默认设置会发生变化。这意味着 devel 项目 可以更改名称、被放弃、被新创建或更改内容和方向，就像 devel 项目 中的软件包一样。目前向 factory 输送的 devel 项目 可以在 此页面 顶部的下拉菜单中找到。您可以在 此处 找到关于 Factory 提交流程 的摘要描述。
您可以查看关于此主题的 更详细的信息。
Staging 项目
有时，特定的核心软件包（例如 GCC 的新版本）被认为有潜力破坏太多，以至于 Factory 维护者决定创建一个特殊的 staging 项目，在其中使用新软件包构建 Factory。其开发者可以修复由此产生的破坏，然后再将其集成回 Factory。
Staging 项目可以看作是 Factory 的一个分支，开发者可以在其中准备更改/更新不同的软件包，将它们一起构建、测试，并在一切都经过测试后提交以包含到 Factory 中。
Factory 已划分为三个环（0-bootstrap、1-minimalX、2-testDVD）。最内层环（0-bootstrap）包含构成最基本、最精简系统的软件包。下一层环包含第 0 层以及运行最简 X 系统所需的一切。最外层环包含所有其他内容。
当向属于内层环的软件包提交请求时，该请求会自动放入 Staging Master 的待办事项列表中，以便进行审查并分配给特定的 staging 项目。目前有 9 个 staging 项目，分别命名为 A、B、C、D、E、F、G、H、I 和 J。Staging J 是一个特殊情况，用于测试不属于环的软件包。其目的和包含的软件包会随着时间的推移而变化。每个 Staging 项目都会定期生成镜像，并在 openQA 上测试镜像，以识别哪些软件包不会破坏当前的 Factory。
osc-plugin-factory 是处理所有 Staging 项目的工具，staging 插件文档 解释了此工具的使用方法。
如果由于此提交请求导致其他软件包失败，则将这些软件包添加到同一个 staging 项目中，以便它们相互构建。
一旦 staging 项目中的每个软件包都成功构建并在 openQA 上测试通过，Factory 维护者就可以将其提交到 Factory，并让其自由测试未来的其他更改。
开发流程概述
完整的开发流程详述在 此页面 上。
- 路线图和功能规划 由发布经理管理，他们创建初始路线图。与此同时，开发人员根据预期的发布和冻结日期为发行版设定技术目标。
- 软件包开发 从 OBS home 项目 [8] 开始。软件包开发者可以在这里工作，而不会影响其他任何内容。一旦软件包足够好，就可以创建提交请求到 devel 项目。
- Devel 项目集成 随后进行，由项目维护者监督，他们密切关注提交请求的技术质量和 Devel 项目的整体状态。成功集成后，项目维护者为 Factory 创建提交请求。
- 审查流程 确保所有前往 Factory 的软件包都经过 4 次（有时是 5 次）审查
- Factory 集成 由 Factory 维护者和发布经理监督，他们接受来自不同 devel 项目到 Factory 的提交请求 [9]。他们主要根据时机和策略因素（例如可能生效的冻结）做出决定，因为审查流程已经处理了质量问题。在某些情况下，他们决定需要一个 Staging 项目。如果需要 Staging 项目，提交请求需要通过 openQA，并且必须获得绿色结果。一旦一切顺利，Factory 维护者将接受该 Staging 项目，然后将属于该 Staging 项目的提交请求签入 Factory。
- 质量保证流程 (openQA) 始终运行。定期由 OBS 生成 ISO 镜像，并通过预定义的测试集进行运行。如果发现问题，将创建一个报告，指出 ISO 镜像中的故障。
- Factory-ToTest。在当前的 Factory 模型中，Factory-ToTest 代表 该项目，其中存储了几个 Factory 快照，这些快照是候选版本，如果 openQA 上的质量足够好，则可以发布。
- 发布流程。根据时机和 QA 流程的结果，发布经理可以发布里程碑或 Beta 版本。他/她负责发布任务：计算 ISO MD5/SHA1 哈希值，设置存储库，准备并播种到镜像站点，部署产品并启动营销以沟通发布。
- 公开测试 在里程碑发布后进行，通常在真实硬件上，并在较小程度上在虚拟机中进行。
在 Beta 版（总冻结之前的最终里程碑）发布后不久，发布团队从 Factory 分叉发布，并使用 维护更新流程 来稳定发布。
治理模型
错误修复和新功能必须首先提交到 devel 项目，然后从那里转发到主要的 openSUSE Factory 项目。因此，Factory 项目的治理也进一步分解。
职责
| 软件包 | Devel 项目 | 工厂 |
|---|---|---|
| 维护者 & Bugowner | 项目维护者 & Bugowner | 发布团队 |
在 此处 查看有关角色和职责的更详细列表。
升级
大多数决策由软件包的维护者做出。如果维护者无法做出决定，或者如果维护者之间发生冲突，devel 项目的维护者将共同决定。如果 devel 项目的维护者也无法达成一致，或者两个 devel 项目之间发生冲突，openSUSE 发布团队将做出决定。如果发布团队也无法做出决定，他们将向 openSUSE 委员会提出上诉，委员会将尝试与所有相关人员一起促成决策。如果这也未能成功，委员会会将问题提交给成员投票。
维护者 ==> Devel 项目维护者 ==> openSUSE:Release team ==> openSUSE:Board ==> openSUSE:Members 投票
您可以阅读关于 openSUSE/factory 开发流程的 更详细的信息。