openSUSE:开发流程
openSUSE 开发与集成流程
从路线图到 Beta1
版本 1.1.0 - 2013/09/25 作者：SUSE 的 openSUSE 团队
关于本文档
草稿文档 编辑
警告：此草稿文档是一个正在进行中的工作；它可能无法代表开发流程的完整图景。社区目前正在审查它。
文档目标
openSUSE 集成流程，被称为 Factory 开发，是一个复杂的软件开发流程，涉及全球数百名开发人员，通常持续 5 到 7 个月。
本文档的目标是
- 作为现有流程文档的主要参考。
- 为潜在的参与者提供流程的全局视图。
- 帮助我们发现需要改进的领域。
遵循的流程
创建文档所遵循的流程是
- 收集和分析现有的文档和参考资料。（请参阅文档末尾的 参考资料）。
- 在与 openSUSE 团队的一次会议期间创建高级工作流程。
- 使用 ETVX [13] 方法论来描述该流程。
- 根据 ETVX 结果创建 WBS（工作分解结构）。
文档的创建是迭代完成的
- 由 SUSE 的 openSUSE 团队进行分析和编辑。
- 来自参与 openSUSE 的 SUSE 员工和管理人员的反馈。
- 来自 openSUSE 贡献者（主要是 Factory/devel 项目）的反馈。
文档结构
本文档按照自上而下的方式描述该流程。它首先提供高级概述（），并辅以对每个活动的更详细描述（第 3 节）。在 第 4 节中，解释了参与该流程的角色和团队。最后，文档包括术语表（第 5 节）和许多指向更多信息的参考资料（第 6 节）。
由于该流程过于复杂，本文档并未涵盖流程的所有细节。为了创建详细的 WBS，需要更深入的分析。
先前工作
之前曾有一项关于记录开发流程的努力，重点是如何运作 Factory。您可以在这里找到该版本 https://en.opensuse.net.cn/openSUSE:Factory_development_model
反馈
要提供反馈，请联系 Alberto Planas (aplanas@suse.com) 或 SUSE 的 openSUSE 团队的任何其他成员。
开发与集成流程概述
ETVX 摘要
本节介绍开发和集成流程的总体视图。此流程图显示了整个流程的非常概括的视图。此流程的每个操作在此部分中简要描述，并在下一节中使用 ETVX 表格进行更详细的描述。
| 路线图和功能规划 | |||
| E1.1 | 已发布发行版的先前版本 | ||
| T1.1 | 创建路线图描述 | 发布经理 | |
| T1.2 | 功能冻结日历 | 发布经理 | |
| T1.3 | 确定新功能 | 项目维护者软件包维护者 | |
| V1.1 | 审查路线图 | 产品经理发布经理 | |
| V1.2 | 路线图维护 | 发布经理 | |
| X1.1 | 路线图和冻结日历已发布到邮件列表中 | ||
| D1.1 | 包含路线图的 XML 文档 | ||
| D1.2 | 在 openFATE 和 wiki 中记录的功能 | ||
| 软件包开发 | |||
| E2.1 | 开发人员创建 Factory 或 devel 项目中不存在的新软件包 | ||
| E2.2 | 开发人员想要更新当前在发行版中的软件包 | ||
| E2.3 | Bugzilla 报告 | ||
| E2.4 | OBS / Hermes 消息 | ||
| T2.1 | 创建本地软件包 | 软件包开发人员 | |
| T2.2 | 分支软件包 | 软件包开发人员 | |
| T2.3 | 修复/更新软件包 | 软件包开发人员 | |
| T2.4 | 提交到 Devel 项目 | 软件包开发人员 | |
| T2.5 | 自动提交 | 软件包开发人员 | |
| V2.1 | 在 Factory 中 | 软件包开发人员 | |
| V2.2 | 自动检查成功完成 | 软件包开发人员 | |
| X2.1 | 开发人员在 OBS 中创建提交请求 | ||
| X2.2 | 开发人员放弃更改，中止开发流程 | ||
| D2.1 | 提交请求 | ||
| Devel 项目集成 | |||
| E3.1 | 软件包开发人员向 devel 项目发出的提交请求 | ||
| E3.2 | 项目维护者想要直接在 Devel 项目中更改软件包 | ||
| T3.1 | 集成提交请求 | 项目维护者 软件包维护者 | |
| T3.2 | 软件包检出 | 项目维护者 | |
| T3.3 | 修复/更新软件包 | 项目维护者 软件包维护者 | |
| T3.4 | 提交到 Factory | 项目维护者 | |
| V3.1 | 提交请求的审查 | 项目维护者 软件包维护者 | |
| V3.2 | 在 OBS 中编译 | 项目维护者 软件包维护者 | |
| V3.3 | 自动安全审查 | 安全审查员 | |
| X3.1 | 软件包维护者为 Factory 创建提交请求 | ||
| X3.2 | 软件包维护者充当软件包开发人员，并将软件包分支到主项目中 | ||
| D3.1 | 提交请求到 Factory | ||
| 审查流程 | |||
| E4.1 | 项目维护者为 Factory 创建提交请求 | ||
| -- | -- | ||
| V4.1 | 法律审查 | 法律审查 | |
| V4.2 | Factory 自动审查 | Factory 维护者 | |
| V4.3 | 技术审查 | 技术审查员 | |
| V4.4 | 检查 Repo 审查 | Factory 维护者 | |
| X4.1 | 所有审查均为正面 | ||
| X4.2 | 存在负面审查 | ||
| D4.1 | 提交请求的状态 | ||
| Factory 集成 | |||
| E5.1 | 已审查提交请求 | ||
| E5.2 | Factory 维护者决定在 Factory 内部修复问题 | ||
| T5.1 | 监控 Factory | Factory 维护者 | |
| T5.2 | 维护 OBS 用于生成 ISO 镜像的 XML 文件 | Factory 维护者发布经理 | |
| T5.3 | 集成提交请求 | Factory 维护者 | |
| T5.4 | 撤销或删除软件包 | Factory 维护者 | |
| T5.5 | 发出通知 | Factory 维护者 | |
| T5.6 | 创建分阶段项目 | Factory 维护者 | |
| T5.7 | 创建模式 | Factory 维护者发布经理 | |
| V5.1 | Factory 是否开放提交？ | Factory 维护者发布经理 | |
| V5.2 | 简要审查 | Factory 维护者 | |
| X5.1 | 软件包已集成到 Factory | ||
| X5.2 | 软件包被拒绝，并在 Hermes 中生成事件 | ||
| X5.3 | 在 bugzilla 中创建错误报告 | ||
| D5.1 | 软件包集成到 Factory | ||
| D5.2 | 正在构建的 Factory 存储库 | ||
| 质量保证流程 | |||
| E6.1 | OBS 生成新的自动构建 | ||
| E6.2 | 发布经理/Factory 维护者测试新的构建镜像 | ||
| E6.3 | QA 团队决定测试新功能或重现 bugzilla 中报告的错误 | ||
| T6.1 | 创建新的测试 | QA 审查员 | |
| T6.2 | 测试维护 | QA 审查员 | |
| T6.3 | 创建错误报告 | QA 审查员 | |
| V6.1 | 测试审查 | QA 审查员 | |
| X6.1 | 重要/关键测试为绿色。ISO 是发布候选 | ||
| X6.2 | 检测到重要/关键错误。ISO 被拒绝 | ||
| D6.1 | 测试报告 | ||
| D6.2 | 错误报告 | ||
| 发布流程 | |||
| E7.1 | 距离选定的发布日期还有 2 天 | ||
| T7.1 | 调整并沟通新的路线图 | 发布经理 | |
| T7.2 | 构建镜像 | 发布经理 | |
| T7.3 | 生成签名 | 发布经理 | |
| T7.4 | 计算镜像的 ISO MD5/SHA1 哈希值 | 发布经理 | |
| T7.5 | 生成当前里程碑与先前里程碑之间的差异 | 发布经理 | |
| T7.6 | 在 Beta 的情况下，发布经理将所有源代码分支到 Factory | 发布经理 | |
| T7.7 | 基于差异创建公告 | 营销经理 | |
| T7.8 | 将镜像和二进制存储库同步到镜像 | 发布经理 | |
| T7.9 | 在 bugzilla 的 Novell 产品页面中启用新的里程碑作为产品 | 发布经理 | |
| T7.10 | 发布发布公告 | 营销经理 | |
| V7.1 | 使用 openQA 检查发布是否足够好 | 发布经理 | |
| V7.2 | 如果为 Beta 1，则进行 Go/NoGo 会议 | 发布经理 | |
| V7.3 | 检查延误 | 发布经理 | |
| V7.4 | 检查镜像同步和发布 | 发布经理 | |
| X7.1 | 发布可用并已发布 | ||
| D7.1 | 所有受支持的平台和体系结构的 ISO 镜像 | ||
| D7.2 | 用于 news.o.o 和邮件列表的发布公告文本 | ||
| D7.3 | 如果延迟：公告和新的路线图 | ||
| 公开测试 | |||
| E8.1 | 新的发布版（里程碑或 Beta）在 sofware.o.o 中发布 | ||
| -- | -- | ||
| V8.1 | 在真实机器上测试 | QA 审查员 | |
| X8.1 | 发布了新版本 | ||
| D8.1 | 错误报告 | ||
openSUSE 开发和集成流程高级描述
目的
本节提供了 openSUSE Factory 开发流程的概述，并描述了里程碑（直至 Beta1 发布）共享的开发流程。该流程的目标是
- 开发 openSUSE 并将其从路线图推进到 Beta 1 阶段
- 协调工作以平衡新功能（开发流程）与发行版的质量（审查流程和 QA），由路线图中建立的功能和截止日期指导。
入口标准
- 产品经理和发布经理决定可以开始新的发布周期
任务
- 路线图和功能规划。发布经理通过参考 [1] [2] [3] 创建初始路线图，确定需要为发行版发布的里程碑、Beta 版和候选版本数量。考虑到假期和路线图流程中描述的其他限制，会调整时间表。与此同时，社区开发者将根据预计的发布和冻结日期 [4] [5]，使用邮件列表确定发行版的一系列技术目标，并将这些功能记录在 openFATE [6][7] 或每个项目的专用 wiki 页面中（有关功能确定方式的更多描述，请参阅 T1.3）。功能冻结作为此任务的一部分进行安排。
- 软件包开发。开发过程在 OBS [8] 中的一个home项目开始。软件包开发者可以在这里创建或修复应用程序，而不会影响其他任何内容。一旦他/她认为足够好，就可以创建一个提交请求到 devel 项目。对于新软件包，开发者必须找到合适的 Devel 项目来发送提交请求。
- Devel 项目集成。Devel 项目由项目维护者维护，其任务是检查发送到项目的不同提交请求的技术质量。有许多按主题分组的 devel 项目，每个项目都分配了若干项目维护者。有些项目有内部审查流程，该流程在流程工作流程图中不可见。审查过程的其他部分将在本文档的其他层级中明确说明，例如安全审查过程。如果开发者需要修复软件包，他/她会将软件包分支到自己的 home 项目，并创建提交请求到原始 devel 项目。这些请求可以由项目维护者和软件包维护者（仅针对其自己的软件包）批准。
- Factory 集成。Factory 维护者和发布经理接受来自不同 devel 项目的提交请求到 Factory [9]。所有提交到 Factory 的内容都必须符合在验证任务 Review 中检查的策略。正如我们稍后将看到的，此验证保证了（最终结果是 Factory 维护者和发布经理只需进行简短的检查即可批准请求）
- 软件包具有最低的技术质量水平（它可以编译，spec 文件语法正确等）
- 许可证与我们的策略兼容
- 软件包已经进行了基本的安全审查。
- 发布流程。如果 QA 流程通过，发布经理可以执行里程碑或 Beta 版本的发布。这里涉及的任务与发行版的发布所需的工作类似：计算 ISO MD5/SHA1 哈希值，设置仓库，准备并播种到镜像站点，部署产品并启动营销以沟通发布信息。
验证
- 审查流程。审查流程用于过滤和提高提交到 Factory 的请求的质量，并避免在 T2 和 T3 中可能产生的某些稳定性问题。所有前往 Factory 的软件包都将通过 4 次（有时 5 次）审查
- 质量保证流程 (openQA)。在 Factory 之后，当发布经理或自动系统 (OBS) 决定可以为不同的产品创建 ISO 镜像时，QA 流程开始。ISO 镜像用于运行预定义的测试集，以检测集成中的故障或软件包本身的错误。如果发现问题，将创建一个报告，指出 ISO 镜像中的故障。
退出标准
- 发布经理和产品经理宣布 Beta 1 状态
- 发布 Beta 1 产品，并在邮件列表和其他通信渠道中进行公告
交付成果
: