openSUSE 开发和集成流程（详情）

从路线图到 Beta1

版本 1.0.3 - 2013/08/29

作者：SUSE 的 openSUSE 团队

在此处解释了工厂开发模型。有关开发流程的概述，请参阅此页面。

1. 路线图和功能规划

目的

创建发布的时间线：路线图
确定新版本的关键技术目标

入口标准

E1.1 发行版的先前版本已发布

任务

T1.1 创建路线图描述。此任务以先前的路线图为模板完成，并围绕中国、德国、捷克共和国和美国的假期进行工作。有关构建路线图所用规则的详细描述，请参见 [15]。最终路线图需要使用来自 [4] 的模式以 XML 格式编写。此路线图包含来自 T1.1 和 T1.2 的所有信息。此 XML 使用 SIMILE JavaScript 程序 [5] 发布，以创建时间线网页作为官方参考。与此同时，路线图发布在项目的 wiki 中 [1]，并在发布过程中维护，在发布新里程碑时链接新的里程碑。重要的日期（路线图和冻结）明确易于用户和开发人员查阅。
T1.2 功能冻结日历。与路线图日历相关联的是关联的功能冻结日历 [1]。有三个阶段的冻结：M3 之后的工具链冻结，M4 之后的基系统冻结，以及 B1 之后的完全功能冻结。此后，维护过程开始。冻结安排在里程碑开发周期结束时，以便在里程碑发布后进行开发。它们不应放置在下一个发布日期太近，因为冻结的组件在里程碑发布之前应进行一些测试。
T1.3 确定新功能。通过邮件列表（讨论想法和功能的首选渠道）和其他社区沟通渠道，讨论并确定了此版本中预期的功能。其中一些功能可以在 openFATE [6]（使用不广泛）或 wiki [3] 上记录。这些功能可以在社区内部确定（此时仅由一小部分贡献者完成），或者在 SLE 和 openSUSE 之间存在关系时在 SUSE 内部确定：开发人员可以为 SLE 创建一个功能，然后在之后添加 openSUSE（这种功能在外部不可见）。目前，我们没有严格的策略来使用 openFATE。一些功能也是在稍后没有计划和文档的情况下确定的。如果该功能在冻结日历之后实现，则需要工厂维护者的明确批准才能进行集成。

验证

V1.1 审查路线图。路线图需要产品经理和发布经理批准。
V1.2 路线图维护。路线图中的小更改不会进行沟通，只是执行。但是，如果延迟威胁到发布日期，则需要发出公告，如果延迟严重，则需要广泛沟通 [17] [18]。在任何情况下，T5 都会参与其中，更新 wiki。

出口标准

X1.1 路线图和冻结日历已发布到邮件列表中

交付成果

D1.1 描述路线图的 XML 文档 [4]
D1.2 在 openFATE [6] 和 wiki [3] 上记录的功能

2. 包开发

目的

在 devel 项目或 Factory 中创建、更新或修复包
开发流程的起点
开发和实验，而不干扰 devel 项目和 Factory 包

入口标准

E2.1 开发人员正在创建一个新的包，该包不在 Factory 或 devel 项目中，但打算将该包集成到发行版中
E2.2 开发人员想要更新当前在发行版中的包
E2.3 开发人员想要修复当前在发行版中的包中的错误，以响应 Bugzilla 或其他渠道中的错误报告 [19]
E2.4 消息系统 (Hermes) [20] [21] 描述了需要对先前的提交请求执行的操作

任务

T2.1 创建本地包。如果包是新的（尚未存在于 devel 项目或 Factory 中），则开发人员使用 osc 命令行工具或 Web 界面创建新包。创建包是一个复杂的过程，文档完善 [22]，并且开发人员必须遵循策略 [23]。如果新包存储在 CPAN、Pypi 或是 Ruby gem 中，则有脚本可以在包创建期间提供帮助，但在任何情况下，打包者都需要提交包。
T2.2 分支包。如果包当前存在于其中一个 devel 项目和/或 Factory 中，则包开发人员将包从原始项目分支到本地主目录。此过程类似于复制文件，但新副本与原始包之间的关系得以保留（存储在一些元数据文件中）。开发人员仍然需要遵循 T2.1 中引用的常规策略
T2.3 修复/更新包。开发人员的实际工作通过此任务表达。包开发人员现在可以修复错误、创建新功能或更新包。完成工作后，开发人员将更改提交到 OBS，以启动“V2.2 自动检查成功完成”中描述的过程。
T2.4 提交到 Devel 项目。创建或修复/更新包后，并且 V2.2 成功完成，包开发人员为 Devel 项目（请参阅术语表以了解 Devel 项目与 Factory 之间的关系）创建提交请求，以使包包含在其中。如果他/她不知道与包相关的 Devel 项目（可能是新包），则包开发人员需要在 opensuse-factory [47] 邮件列表中询问。工厂维护者可以创建一个新的 Devel 项目，以防没有与包匹配的 Devel 项目，或者更常见的情况是，指向现有的 Devel 项目。
T2.5 自动提交。有一些外部脚本会自动更新某些包。这些脚本与一些非常特定的 Devel 项目相关，通常不使用。运行后，它们就像一个包开发人员一样，更新包并直接提交到 OBS（V2.2）

验证

V2.1 是否在 Factory 中。创建新包以供将来集成到 Factory 中的工作流程与修复错误或更新当前在 Factory 中的包的工作流程不同。通过此验证点，开发人员做出明确的决定来更改工作流程的路径。
V2.2 自动检查完成成功。每个软件包都需要提交到 OBS，OBS 将构建该软件包并运行一些标准测试。如果编译成功并且软件包通过测试，开发者可以创建一个提交请求。

出口标准

X2.1 开发者在 OBS 中创建一个提交请求。此提交请求将由该软件包的软件包维护者或项目维护者接收。
X2.2 开发者放弃更改，中止开发过程。

交付成果

D2.1 提交请求。本文档是由软件包开发者在软件包在 OBS 中成功创建并被软件包开发者认为准备好后创建的数字文档。软件包维护者和项目维护者使用此文档将新版本软件包的更改集成到 devel 项目中。

3. Devel 项目集成

在软件包可以集成到 Factory 之前，它需要属于一个 devel 项目。devel 项目是一组相关的软件包，它们共享某些特性。例如，在 devel:language:python 中存储了所有与 Python 编程语言相关的软件包。LibreOffice:Stable 是 devel 项目，其中存储了更新到最新稳定版本的 LibreOffice 软件包。

目的

提供一个空间，用于进行主要开发（集成功能发布）。
为了保证软件包最终集成到 Factory 之前达到一定的质量和集成水平。此集成过程遵循 checkout – fix – commit – 提交请求的循环，与 2. 软件包开发中描述的过程非常相似。

入口标准

E3.1 软件包开发者向 devel 项目提交的提交请求。
E3.2 项目维护者直接在 Devel 项目中更改软件包的决定

任务

T3.1 集成提交请求。项目维护者可以在 V1 中完成审查后集成来自提交请求的代码。通常，此集成是通过 OBS Web 界面或 osc 命令行工具完成的。软件包维护者只能接受和集成其自身软件包的提交请求。
T3.2 软件包检出。项目维护者有两种处理 devel 项目中软件包的方式：一种是使用退出标准并在其自己的 home 项目中分支软件包（将角色更改为软件包开发者）。另一种选择是直接从 devel 项目中检出软件包并提交更改。前一种选择更安全、更清晰，因为它避免了与新的提交请求冲突。后者是一种更快速的方法，更适合于维护者和开发者数量较少的项目。为了帮助此过程，一些 devel 项目使用 OSC 命令行工具的扩展。例如，GNOME 项目使用插件 [24] "collab" [25] 以允许高级工作流程。
T3.3 修复/更新软件包。开发者的实际工作通过此任务表达。项目维护者或软件包维护者可以使用来自 bugzilla [19] 的错误，或为其自身项目计划的功能作为输入。
T3.4 提交到 Factory。一旦软件包或项目维护者认为其项目中的软件包足够好，他/她就会为 Factory 创建一个提交请求。

验证

V3.1 提交请求审查。在集成之前，项目维护者（如果请求与他/她自己的软件包相关，则为软件包维护者）会手动检查请求，以检测 spec 文件、附加的补丁或编译过程中的问题。如果没有发现问题，则接受请求并进行集成（T3.1），否则拒绝请求，Hermes 会向提交请求的创建者发送消息。一些 devel 项目具有内部审查流程，但默认情况下没有共享策略。
V3.2 在 OBS 中编译。每个软件包都会提交到 OBS。OBS 将根据 spec 文件 [26] 构建二进制文件。如果编译成功，项目维护者可以创建一个提交请求并将其发送到 Factory，或继续使用其余软件包进行集成过程。
V3.3 自动安全审查。对于使用 SETUID 二进制文件或提供 D-BUS 服务或 PAM 模块的某些软件包，将进行自动安全审查。检查在软件包创建的 rpmlint 阶段执行，如果适用其中一项安全策略 [27]，则无法编译该软件包。为了解除构建软件包的限制，软件包维护者必须联系（开具票证）安全团队进行审查。只要软件包不在白名单中，就无法提交到 Factory。

出口标准

X3.1 软件包或项目维护者为 Factory 创建提交请求。
X3.2 软件包维护者决定更改角色为软件包开发者并在其 home 项目中分支软件包。

交付成果

D3.1 提交到 Factory 的请求。可以创建并发送到 Factory 的类似提交请求。项目维护者可以将一组提交请求组合成一个单独的请求，该请求可以作为整体接受或拒绝。

4. 审查流程

审查流程仅针对 Factory。

目的

为了提高提交请求的质量。
潜在地简化请求集成到 Factory 的过程。
检测法律、技术（软件包内和软件包间）和安全方面的最常见错误。
避免接受相互依赖的软件包的问题。通过审查，您可以确保在提交到 Factory 之前，所有相关软件包都达到一定的质量水平并遵循某些策略，从而防止 Factory 因某些软件包未达到质量标准而崩溃。

入口标准

E4.1 项目维护者为 Factory 创建提交请求 [28] [29] [30]

任务

由于此审查过程是完整的验证步骤，因此此过程仅由验证步骤组成，而不是任务

验证

V4.1 法律审查。法律审查分为两部分：（1）脚本 Factory-auto [10] 检查软件包中的许可证是否已更改。如果没有更改并且许可证在许可证数据库中，此脚本将接受该请求。（2）如果软件包包含许可证的更改，或者是一个许可证未在许可证数据库中找到的新软件包，则法律团队必须手动检查该请求并接受或拒绝。
V4.2 Factory Auto 审查。Factory-auto 是一个脚本 [10]，它执行浅层技术审查，试图找到通常在请求中发现的最常见问题。例如，此脚本检查关联软件包是否当前在 OBS 中成功编译。此检查速度很快，用于拒绝最明显质量差的请求。
V4.3 技术审查。审查团队检查请求中更复杂的技术方面。技术审查员将检查规范文件是否遵循预定义的策略 [23] [26]，查看补丁中代码的质量并验证 changelog 文件的内容。
V4.4 Check Repo 审查。此审查也是自动的。由 check-repo 脚本 [10] 执行，并检查典型的集成问题。例如，此机器人检查 Factory 项目中是否存在某些依赖项，Base:build 中的所有依赖项是否都包含在同一个特殊项目中，或者新的请求组是否会在 Factory 中创建新的问题依赖循环。

出口标准

X4.1 所有审查都通过。
X4.1 如果来自其中一个验证点的审查为负面，则请求将被拒绝，Hermes 会向请求的发送者发送通知。一些自动检查会标记请求（如果失败），但不会完全拒绝该软件包。在这种情况下，提交者需要采取行动才能将其视为退出标准。OBS 还允许对请求进行评论，其中一些需要提交者采取行动。

交付成果

D4.1 审查过程会更改请求的状态，随时显示哪些审查待处理、已接受或已拒绝。

5. Factory 集成

目的

将所有软件包组合在一个树中，创建一个一致的整体
用作新产品 ISO 镜像的基础
确保流入 Factory 的软件包遵循功能冻结和时间规则
确保 Factory 的其他分支（里程碑、Beta、RC、发布）的一致性

入口标准

E5.1 已从 devel 项目提交提交请求并已通过审查过程
E5.2 Factory 维护者决定在 Factory 中修复问题

任务

T5.1 监控 Factory。定期，Factory 维护者会检查 Factory 的运行状况，如果存在任何问题（解决方案超出 Factory 维护者角色的范围），他/她会向正确的角色发送提醒，或撤销导致问题的软件包。Factory 维护者使用三种类型的监视器：构建监视器，显示所有过程的当前阶段（失败的软件包） [31] [32]，提交请求队列 [33] 和用户。
T5.2 维护用于生成 ISO 镜像的 OBS 使用的 XML 文件。发布维护者更新和修复 KIWI [34] 生成产品的 ISO 镜像所需的 XML。此过程当前未记录。
T5.3 集成提交请求。Factory 维护者接受并集成来自 devel 项目的提交请求到 Factory。为了避免 OBS 服务器过载，Factory 维护者会根据经验（即，未记录）遵循一些基本规则 [9]。
1. 不要在正在进行新的构建时接受 SR。
2. 如果接受了 leaf 软件包，OBS 将触发一小部分软件包。
3. Base 或 core 软件包可能导致 Factory 中大量重新编译。这些通常会延迟到周末结束。
T5.4 撤销或删除软件包。如果软件包维护者没有及时响应，或者如果软件包造成巨大麻烦，则可以撤销或删除该软件包。
T5.5 发出通知。Factory 维护者检测到并通知软件包或项目维护者 Factory 中与软件包相关的问题。
T5.6 创建 staging 项目。为了简化集成过程和问题检测，Factory 维护者可以创建 staging 项目。staging 项目通常包含一个新的重要软件包（如 GCC 或 Perl）以及所有依赖项和其他相关软件包。这样，维护者可以检测仅与新软件包相关的新问题，避免由其他集成操作或更新引起的问题。
T5.7 创建 Patterns。Factory 维护者创建和更新安装所需的 patterns [36]。patterns 的格式和用途在此处描述 [35] [37]。

验证

V5.1 Factory 是否开放提交？ 检查冻结或其他不接受 SR 的原因
V5.2 简要审查。审查过程会过滤掉低质量的提交请求，因此 Factory 维护者不会验证质量。相反，他/她会判断现在是否是接受请求并启动构建过程的适当时间。Factory 维护者通常会对请求进行简单的审查，如果
1. 提交请求与当前冻结的软件包相关，并且该软件包不是修复问题
2. 该软件包会破坏太多其他软件包，以至于需要 staging 项目

出口标准

X5.1 该软件包已集成到 Factory
X5.2 该软件包被拒绝，并在 Hermes 中报告了一个事件
X5.3 在 bugzilla 中创建了一个错误报告

交付成果

D5.1 软件包集成到 Factory
D5.2 一个可用的 Factory 仓库

6. 质量保证流程

质量保证流程可以使用 openQA [11] [12] 工具自动完成，也可以在虚拟机或真实机器中手动完成。

目的

确定 T4. Factory 集成后生成产品的质量。
测试 ISO 镜像，这些镜像有望成为里程碑或 Beta 1
尝试识别 ISO 构建中的真实错误（集成错误或软件包错误），而不是修复问题
量化最终构建质量，检测错误并使用新错误更新 Bugzilla 以进行修复。

入口标准

E6.1 OBS 生成了一个新的自动构建
E6.2 发布经理或 Factory 维护者决定测试具体的构建镜像，作为最终产品（里程碑或 Beta）的候选者
E6.3 QA团队决定测试一项新功能或重现BNC中报告的错误 [19]

任务

T6.1 创建新的测试。如果QA团队认为当前测试集的覆盖范围不足，他们需要编写一个覆盖新功能/用例的测试。
T6.2 测试维护。为Factory创建测试的方法是使用openQA。该工具需要维护某些组件，名为needles，用于在测试中断言结果条件 [46]。当艺术作品或其他影响发行版外观和行为的重要更改发生时，需要更新和调整这些needles。
T6.3 创建错误报告。openQA检测到发行版中的问题，但它没有指定影响ISO镜像的确切问题。QA Reviewer将深入研究失败的测试，推断出问题所在，并将调查结果记录在bugzilla中发布的错误报告中。该错误分配给正确的开发者，以修复T2.软件包开发任务或T3.Devel项目集成中的错误。

验证

V6.1 测试审查。测试根据一小部分标准进行分组：测试阶段（安装过程、文本应用程序或图形应用程序）和相对重要性（关键、重要、普通）。如果关键测试未成功通过，或者安装过程中的某些测试失败，该工具可以将一个ISO标记为失败。如果openQA的最终结果不是绿色，则必须调试ISO并编写错误报告（T6.3）

出口标准

X6.1 重要和关键测试均为绿色，并且ISO被认为是里程碑或Beta发布的候选版本
X6.2 该工具在某些配置中检测到一个重要错误，并且ISO被拒绝作为可行的产品候选版本。

交付成果

D6.1 测试报告。该应用程序生成带有屏幕截图和测试状态的测试报告。该报告由QA Reviewer审查。
D6.2 错误报告。如果发现错误（关键或非关键），QA Reviewer将创建带有错误描述的错误报告，并将其分配给软件包的正确维护者。

7. 发布流程

目的

提供里程碑/Beta镜像进行测试 [38] [39]
完成流程

入口标准

E7.1 距离所选发布日期还有2天

任务

T7.1 更新路线图。发布经理调整并传达新的路线图。
T7.2 构建镜像。使用KIWI，OBS创建在XML文档中指定的ISO镜像。不同的产品（ISO镜像）具有不同的XML文档。
T7.3 生成签名。autobuild团队代表SUSE生成签名，并生成与上一个里程碑的delta ISO
T7.4 计算哈希值。发布经理计算镜像的ISO MD5/SHA1哈希值
T7.5 为营销创建更改列表。发布经理使用dvddiff脚本生成当前里程碑与先前里程碑之间的差异，并将其与其它重要说明一起发送给营销部门。根据更新的重要性，将生成的列表缩减到更易于管理的数量（10到30之间）。
T7.6 为Beta分支源代码。在Beta版本的情况下，发布经理将Factory中的所有源代码分支出来。分支创建完成后，Factory再次开放开发。
T7.7 创建公告。营销经理根据差异和progress.o.o上的模板创建公告 [40]
T7.8 将镜像同步到镜像站点。发布经理将镜像和二进制存储库同步到镜像站点 [41]。发布经理通过邮件通知镜像管理员有关新的iso和建议的发布日期 mirror@opensuse.org。发布经理在镜像站点上发布镜像（使文件可读）
T7.9 更新Staging。发布经理更新staging区域，用于bittorrent的metalinks
T7.10 在NPP中启用产品。发布经理在bugzilla中的Novell产品页面中将新的里程碑作为产品启用
T7.11 发布公告。营销经理发布公告

验证

V7.1 选择镜像。发布经理根据openQA输出决定，潜在的发布镜像是否足够好。如果发布是早期里程碑，发布经理可以根据不同于openQA输出的标准决定发布。越接近发布，发布经理提高发布阈值的要求就越高。
V7.2 讨论Beta路线图。如果是Beta版本，将与产品经理和管理层召开会议，讨论Factory的状态和路线图。对于最终发布，将与发布经理、Controller、QA Reviewer、产品经理和管理层召开一次“是/否”会议，以决定是否延迟发布。
V7.3 检查沟通。发布经理检查延迟（如果有）是否足够大，需要进行沟通
V7.4 检查同步状态。发布经理检查镜像是否已同步并发布到镜像站点

出口标准

X7.1 发布可用并已发布

交付成果

D7.1 支持所有受支持平台和体系结构的ISO镜像
D7.2 用于news.o.o和邮件列表的发布公告文本
D7.3 如果延迟：公告和新的路线图

8. 公共测试

在发布流程之后，由社区（开发者和用户）进行第二次QA。此测试不是自动的，通常在真实硬件上完成

目的

确定发布后生成的产品的质量
识别真实硬件和真实用例中的真实错误
检测错误并使用新错误更新Bugzilla以供修复。

入口标准

E8.1 新发布（里程碑或Beta）在sofware.o.o上发布 [14]

任务

我们可以将此操作视为任务或验证点。如果这是一个验证点，则没有实际的任务分配给此操作。

验证

V8.1 在真实机器上测试。用户（或开发者）可以访问software.o.o [14]下载发布并将其安装在真实硬件上。如果他/她检测到错误，则在bugzilla [19]中创建一个新的错误报告，或者/以及将邮件发送到Factory邮件列表。此外，许多用户决定直接更新存储库来测试Factory [50]，而无需安装发布的媒体。

出口标准

X8.1 发布已发布

交付成果

D8.1 错误报告。如果发现错误，测试人员将创建带有错误描述的错误报告。QA Reviewer可以重现该错误并将其分配给正确的开发者。

项目组织

1. 角色和职责

有大量人员参与Factory开发。我们确定了以下角色

产品经理
- 负责规划功能
- 联系方式：abebe@suse.de
发布经理
- 设置发布计划并监督发布的所有阶段，并在必要时进行调整。
- 联系方式：coolo@suse.de
Factory维护者
- 作为软件包维护者的备份，并帮助处理更复杂的集成问题。
- 联系方式：coolo@suse.de
软件包开发者
- 创建软件包，添加功能并将其更新到较新版本。
软件包维护者
- 修复软件包中的错误。
- 默认情况下是创建软件包的人。
- 如果看到持续的良好贡献和对软件包的关心，现有的维护者（如果未激活，则Devel项目维护者）可以添加新的维护者。
Devel项目维护者
- 审查进入devel项目的请求。
Super Devel项目维护者
- 作为devel项目维护者的备份。此角色在OBS中通过在所有devel项目中将“factory-maintainers”组在“maintainer”角色中实现。
- 联系方式：tchvatal@suse.com

以下工具参与特定角色

Factory Auto
- 检查是否满足一些基本的打包标准。
- https://github.com/coolo/factory-auto
Legal Auto
- 自动检查，评估是否需要Legal Team的手动审查。
Factory Repo Checker
- 进行更深入的检查（软件包构建、安装、不冲突等）后，才允许软件包通过。
- https://github.com/coolo/factory-auto

并且以下团队参与其中

审查团队
- 负责维护提交到Factory的软件包的质量
- 提交到Factory的每个软件包都必须由该团队的成员审查，以检查软件是否正确打包并按照我们的打包指南编写。
- 描述：https://en.opensuse.net.cn/openSUSE:OpenSUSE_review_team
- 联系方式：review@opensuse.org
Legal团队
- 检查我们是否可以合法分发软件包。
- 审查声明的许可证是否正确，并查找可能的冲突许可证
- 联系方式：opensuse-bar@opensuse.org
安全团队
- 审查软件包是否存在特殊权限（suid、capabilities等），未经其批准，Factory中没有任何东西可以获得这些权限。
- 报告潜在的安全问题。
- 描述：https://en.opensuse.net.cn/openSUSE:Security_team
- 联系方式：opensuse-security@opensuse.org
Autobuild团队
- 生成SUSE签名和ISO之间的delta
文档团队
- 负责维护文档。
- 描述：https://en.opensuse.net.cn/Documentation_Team
- 联系方式：opensuse-doc@opensuse.org
QA团队
- 负责测试Factory和评估潜在的里程碑
- 描述：https://en.opensuse.net.cn/openSUSE:Testing_Core_team
- 联系方式：opensuse-testing@opensuse.org
营销团队
- 负责与外界沟通并推广发布
- 描述：https://en.opensuse.net.cn/openSUSE:Marketing_team
- 联系方式：opensuse-marketing@opensuse.org

其中一些在Open Build Service中分配了一个或多个角色。请参阅概述 [42] [43] [44] [45]。

术语表

分支

当贡献者想要处理软件包时，第一步是创建原始软件包的副本。OBS将在原始软件包和复制（分支）软件包之间建立关系。在合并过程（集成过程）发生之前，这两个软件包可以分别演化。

BNC

参见Bugzilla

Bugzilla

用于收集、监控、分配和更新错误报告的管理工具。该项目使用Novell的bugzilla安装 [19]。该站点也被称为BNC。

提交

当开发者（贡献者）处理软件包时，他/她需要注册所做的更改。此注册过程称为提交，在OBS中使用OSC命令行工具或在Web界面中自动完成。

Devel 项目

项目是Factory的上游部分。Factory由一组不同的Devel项目组成，这些项目集成在一起以构建下一个发布版本。在 [48] 中，对什么是Devel项目有更正式的描述。Devel项目可以有一个或多个维护者，他们决定为该软件包实现的功能（路线图）并致力于将其集成到项目中。

ETVX

IBM于1985年开发的描述流程的正式方法。该方法被归类为叙述性，而不是图形化 [13]（流程图）。

工厂

Factory是存储在OBS中的项目，它集成了不同的Devel项目，目的是创建未来的openSUSE发布。Factory中的工作通常由Factory维护者（集成不同的项目软件包）和发布经理（基于Factory的ISO镜像创建发布）完成。

功能冻结

为了更容易地将 devel 项目集成到 Factory 中，发布经理会建立一个日历，其中规定了在特定期间内允许更新哪些软件包（冻结）。在发布经理和 Factory 维护者启动新的发布周期之前，只允许进行错误修复（不允许发布新版本或新功能）。可以例外处理。

Hermes

Hermes [21] 是 openSUSE 项目的中央通知中心。它允许用户控制他们想要接收的通知类型、方式和时间。

主项目

每个开发者都会被分配一个主项目，可以在其中开发和实验，而不会干扰存储在不同项目中的其他软件包。当开发者从 devel 项目或 Factory 分支一个软件包时，复制的软件包会自动存储在他的或她的主项目中。

KIWI

openSUSE KIWI [34] 镜像系统为支持的 Linux 硬件平台以及 Xen、Qemu 或 Vmware 等虚拟化系统提供完整的操作系统镜像解决方案。

OBS

开放构建服务 (OBS) [8] 是一个通用的系统，用于以自动、一致和可重现的方式从源代码构建和分发二进制软件包。它用于发布软件包以及更新、附加组件、设备和针对各种操作系统和硬件体系结构的全部分发版。

openFATE

openFATE [6] [7] 是 openSUSE 社区的特性和需求管理系统。用于向所有 openSUSE 成员开放产品规划流程。

openQA

借助 openQA [11]，我们可以自动运行分发版的测试。有些测试旨在在虚拟（或真实）机器中完成分发版的完整安装，并采用不同的文件系统、桌面环境、体系结构、介质等配置。

OSC

用于与 OBS 交互的命令行工具

软件包

源软件包是包含文件列表（通常是 tar 文件和补丁文件等资源）和规范文件的集合，可用于生成一个或多个二进制软件包

模式

与指定配置或功能相关的预定义软件包集合。模式用于安装可以形成常用配置（笔记本电脑、服务器、桌面、开发者、办公用户等）的一组软件包

项目

源软件包容器。

仓库

二进制软件包容器。为特定体系结构编译的二进制软件包的测试。

路线图

一种将短期和长期目标与特定的技术解决方案相匹配的计划，以帮助实现这些目标

Staging 项目

用于在提交到 Factory 之前测试关键组件的临时项目。Staging 项目可以根据需要由 Factory 维护者创建和销毁，但其中一些项目，例如 [49]，更通用且经常被重用。

提交请求

开发者建立并由 OBS 管理的数字文档，描述了对源软件包所做的更改集合。

参考资料

[1] openSUSE Roadmap: https://en.opensuse.net.cn/openSUSE:Roadmap

[2] openSUSE Goals: https://en.opensuse.net.cn/openSUSE:Goals_13.1

[3] openSUSE Features: https://features.opensuse.org/statistic/product/opensuse_131

[4] XML Roadmap: http://turing.suse.de/~coolo/opensuse_13.1/opensuse.xml

[5] SMILE view of the Roadmap: http://turing.suse.de/~coolo/opensuse_13.1/

[6] openFATE: https://features.opensuse.org/

[7] openFATE description: https://en.opensuse.net.cn/openSUSE:Openfate

[8] Open Build Service (OBS): https://build.opensuse.org/

[9] Factory Release Process: https://en.opensuse.net.cn/openSUSE:Release_team_processes

[10] Factory-Auto and other scripts: https://github.com/openSUSE/openSUSE-release-tools

[11] openQA: http://openqa.opensuse.org/

[12] openQA (Internal link): http://opensuseqa.suse.de/

[13] ETVX Methodology: Radice, R.A.; Roth, N.K.; O'Hara, A.C., Jr; Ciarfella, W.A. " A Programming Process Architecture" IBM Systems Journal Vol.24, No 2 (1985), pp.79-90.

[14] Software openSUSE (devel): https://software.opensuse.net.cn/developer/en

[15] Roadmap (openSUSE 12.2 report): https://wiki.innerweb.novell.com/index.php/OpenSUSE_team_report_12.2#Schedule

[16] OBS Tutorial: https://en.opensuse.net.cn/openSUSE:Build_Service_Collaboration

[17] Delay announcement: https://news.opensuse.net.cn/2012/06/14/where-is-my-12-2-my-kingdom-for-a-12-2/

[18] Analysis of the delay: http://lists.opensuse.org/opensuse-factory/2012-06/msg00468.html

[19] Bugzilla Novell: http://bugzilla.novell.com/

[20] Hermes: https://hermes.opensuse.org/

[21] Hermes description: https://en.opensuse.net.cn/openSUSE:Hermes

[22] Create a package with OBS: https://en.opensuse.net.cn/openSUSE:Build_Service_Tutorial

[23] Package policies and guidelines: https://en.opensuse.net.cn/openSUSE:Packaging_guidelines

[24] OBS plugins: https://en.opensuse.net.cn/openSUSE:OSC_plugins

[25] Some OBS plugins: https://en.opensuse.net.cn/openSUSE:Build_Service_Tools