openSUSE:Factory development model
开发模式
Factory 版在开放构建服务器(OBS)上有其自己的项目 openSUSE:Factory. 你会发现，这是一个庞大的软件包库。开发过程并不会直接在 openSUSE:Factory 中进行，而是在开发项目里。开发项目 (devel projects), 顾名思义, 是供某一类特殊软件包进行开发的项目。像 multimedia, GNOME, KDE 或 Kernel。 openSUSE:Factory项目的软件包与开发项目中的软件包之间的关系是由openSUSE:Factory中包的meta元数据来说明的。
开发项目
每个开发项目都有一系列适合其自身的流程、规则和沟通方法。此参考信息可以通过其构建服务器上的项目描述获得。开发项目也在不停的变化，因为自由和开源软件的世界是持续发展的。某些软件会被抛弃，标准和默认的软件也会改变。这意味着开发项目可以更名、被抛弃、新建，或者改变其内容和开发方向，开发项目中的软件包亦然。当前的开发项目列表可以在此页面上方的下拉菜单中找到。在这里可以找到 Factory 提交程序的概要。
您可以查阅关于此主题的更详细的信息。
阶段项目
有时候，一个特定的核心软件包（例如新版本的GCC）被视为是有可能导致系统故障的，这种情况下 Factory 的维护者会创建一个特殊的阶段项目，在其中编译新的软件包。开发者可以先在这里修复问题，再将其整合进 Factory 中。
阶段项目可以视做 Factory 的一个分支，开发者会在这里修改/更新不同的软件包，把它们放在一起编译、测试，并在所有测试通过后提交到 Factory。
Factory 版可以被描述为划分成三个圆形区域的嵌套示意图（0-引导程序, 1-最小化X环境, 2-测试DVD）。最内的圆（0-引导程序）包含最基本和最小化的软件包。下一层包含0的部分加上需要运行最小化X系统的所有包，最外层的圆形区域包括了其他所有包。
当最内层软件包的提交申请被发出去以后，此申请会自动置于阶段主项目待处理队列中，以便对其审核并分配给特定的阶段项目。当前总共有10个阶段项目，命名为 A, B, C, D, E, F, G, H, I 和 J，它们的用途和包 含的软件包会随着时间而改变。阶段J是一个特例，其用途是用来测试不属于任何区域的包（例如新的软件包）。每个阶段项目都会定期生成ISO安装镜像，然后经过openQA 测试，以确认这些软件包不会将当前的 Factory 系统搞垮。
还有一种可能性，就是某个提交申请会导致其他包故障。在这种情况下，这些其他的软件包会被加入到相同的阶段项目中来，这样一来就可以在一起同时进行编译了。
一旦阶段项目中的每个包都编译成功，且 openQA 测试通过，Factory 的维护者会将其提交到 Factory 源，并保留阶段项目以便将来测试其他的修改。
osc-plugin-factory 这个工具可以用来处理关于阶段项目的一切工作。这个文档解释了如何使用此工具。
开发流程概述
完整的开发流程在此页面上有详细说明。其中包含以下步骤：
- 路线图和新增特性的计划由发布经理来管理。发布经理创建初始路线图，与此同时，开发者基于计划的发布和冻结日期制定此版本的技术目标
- 软件包开发过程起始于 OBS 中的 home 项目 [8]。开发者在这里打包，不会影响其它任何项目。当软件包足够完善时，就可以向开发项目发出提交申请了。
- 开发项目整合过程经由项目维护者关注并跟进。项目维护者将审查提交申请的技术质量，以及开发项目的整体状态。在软件被成功整合后，创建新的提交申请发给 Factory。
- 审核程序通过4次（有时是5次）审核，确保所有软件包以适当的流程进入到 Factory：
- Factory 版整合过程由 Factory 的维护者和发布经理负责，接受来自不同开发项目向 Facotry 发来的提交申请 [9]。他们在大多数情况下会依据发布周期和法规因素(例如冻结日期)来进行决策，因为审核程序已经确保了质量方面不存在问题。某些情况下，他们会决定是否需要阶段项目。当需要阶段项目时，提交的申请需要通过openQA检测且结果必须为绿色。一旦所有条件都满足了，Factory 的维护者会接受此阶段项目，自此所有属于此阶段项目的提交申请将进入到 Factory 版。
- 质量保障程序(openQA)会全天持续运转。每隔一段时间，OBS就会生成新的ISO镜像，并在预定义的测试组合中运行。如果发现了问题，就会针对相应ISO镜像创建关于此故障的报告。目前，openQA主要用于测试阶段项目和 Factory-ToTest 镜像。
- Factory-ToTest。在当前 Factory 模式下，Factory-ToTest 代表保留下来的若干 Factory 快照，它们将作为候选的发布镜像。前提是要通过 openQA 检测，其质量达到了一定的要求。
- 发布程序。基于发布周期和QA流程的结果，里程碑(milestone)或beta版将由发布经理经手发布。他/她会负责具体的发布任务：计算 ISO MD5/SHA1哈希值，设置软件源，准备镜像源并做种，部署产品线，动员市场部门发布消息。
- 公共测试在里程碑(milestone)发布后进行，测试环境通常是实体硬件，以及小部分虚拟机。
Beta版（完全冻结前最终的里程碑版本）发布后不久，发布团队将从 Factory 创建一个分支，并依据维护更新程序发布稳定版本。
管理模式
庞大的工厂版开发工作被分流到各个 开发源 里。开发源负责集中开发某系列软件包如 GNOME, 多媒体 或者 内核。臭虫修复和新特性首先要提交到开发源里，然后才能从那里转交给工厂版的主源。因此工厂版的管理也被分流给各个开发源了。
职责
| 软件包 | 开发源 | 工厂版 |
|---|---|---|
| 维护者 & Bug接收者 | 项目维护者 & Bug接收者 | 发布团队 |
这里有更详细的角色和职责清单。
逐級提交
大部分决定应由包的维护者来做。如果维护者不能做出决定或者包维护者之间产生分歧，那么源维护者要参与决策过程。如果源维护者也不能做出定论，或者两个不同源的源维护者之间产生分歧，openSUSE 发行团队参与仲裁。如果发行团队也不能做出决定，那么他们会呼吁 openSUSE 董事会促成所有方面的和解。如果那也不成功的话，董事会会发起全体 openSUSE 成员的投票。
维护者 ==> 开发源维护者 ==> openSUSE:Release team ==> openSUSE:Board ==> openSUSE:Members 投票zh:openSUSE:Factory_development_model