Portal:Jump/Policy/ChangeValidation
初步草稿
术语表
- 实施 - 将代码更改合并到产品中的行为，在本例中为 openSUSE Jump 15.2.1。
- 更改请求 - 在 Open Build Service 的实例中发起的提交请求。无论是 https://build.opensuse.org 还是 https://build.suse.de。
- 软件包 - 由 .spec 文件表示的实体，而不是单个二进制 rpm。
- SLE - SUSE Linux Enterprise
- Backports - https://packagehub.suse.com/ 对应的 OBS 项目
审核人员
- openSUSE 审核团队
- SUSE SLE 审核团队
- openSUSE 发布团队
- openSUSE 回溯审查团队
- Package Hub 团队
- License digger
- Factory-Auto
- Staging bot
实施前更改的验证
提交到 openSUSE:Jump:15.2 的更改在大多数情况下需要提交请求重定向。让我们看一下每个重定向目标以及在更改实施之前发生的审核范围。
直接在 openSUSE:Jump:15.2 项目中的软件包更改
位于 openSUSE:Jump:15.2 项目中的软件包数量大约为 80 个，主要是品牌和镜像构建相关的软件包以及与 SUSE Linux Enterprise (SLE) 重叠的软件包，但是我们需要 fork 它们以保留特定功能（例如，fpc 集成的 gdb）。 所有更改请求都受 Factory 开发模型 和相关的 Factory 审核 以及 openSUSE 审核团队 的审核。唯一的例外是包含产品构建元数据的软件包的更改。
所有更改都必须通过 Staging Review 以及在 OpenQA 中的相关测试。最终，更改请求由 openSUSE 发布团队 的成员明确拒绝或合并到产品中。
从 openSUSE Backports 继承的软件包更改
从 openSUSE Backports 继承的软件包数量大约为 8000 个。 openSUSE Backport 审核团队 负责在实施前审核请求。
从 SLE 继承的软件包更改
从 SUSE Linux Enterprise 15 或其他 SLE 系列产品继承的软件包数量大约为 4000 个。
这些 4000 个软件包主要来自 DVD 安装介质，但也有一些直接在 openSUSE Jump 中 fork 的桌面环境或软件包（参见第一个目标）。
社区发起的 SLE 更改的额外审核
如果更改是由社区成员通过针对 openSUSE Jump 的 提交请求 发起的，则有一个额外的 'suse-sle-reviewers' 审核。
所有来自 SLE 的更改都来自 SUSE 维护请求或当前开发的 Service Pack 的提交请求，后者通常对应于 openSUSE Jump 的版本。
从当前开发的 Service Pack 继承的更改
所有这些来自 SUSE:SLE-X:Y:GA（例如 15-SP2:GA）的请求必须通过与 openSUSE Jump X.Y 提交类似（参见 第 2.1 节）的审核，但不同之处在于提交由 SLE 发布经理评估。
从 SUSE 维护请求继承的更改
与 openSUSE Leap 不同，SUSE:SLE-X:Y:GA 项目布局会继承来自以前 Service Pack 的软件包，除非有 fork 软件包的理由。例如，由于向后不兼容的更改或重大的版本更新。openSUSE Jump 继承来自 SUSE:SLE-X:Y:GA 的软件包
与 openSUSE 维护团队审核 类似，SUSE Linux Enterprise 的所有维护更新都必须通过 SLE 维护团队和 SLE QA Maintenance (QAM) 的某些审核和测试。我们认为 SLE 维护团队和 QAM 所做的测试足以用于 openSUSE Jump，因此不需要在 openSUSE 端进行额外的实施后测试。
实施后更改的验证
每个 openSUSE Jump 构建都必须通过在 openQA 中定义的测试集，否则根本不会发布。失败可以是硬失败或软失败。软失败不会阻止构建的发布，而硬失败会阻止，并且必须由 [[openSUSE:Release_team|openSUSE 发布团队]] 的成员明确放弃才能继续。放弃以评论的形式进行，应具有约定的语法，并应参考 boo# bug 或 poo# 触发失败的 ticket。
openSUSE 测试核心团队 与 openSUSE 发布团队 合作决定哪些问题应该是软失败，哪些问题应该是硬失败。
openSUSE 测试核心团队 的责任是测试结果能够很好地代表产品的质量。 openSUSE 发布团队 对每个构建的测试结果的审核负全部责任。