Portal:Jump/Policy/SubmitRequests
Jump 提交请求
TLDR 版本
简单来说，如果软件包不在 SUSE Linux Enterprise 15 (SLE) 中，那么它将由 openSUSE Backports 处理。所有更改请求最初都会针对 openSUSE Jump 项目 软件包，不在 SLE 中的软件包将简单地在 openSUSE Backports 中处理。Ports 项目不再存在，我们现在有 s390x。
简介
目前此流程仅对 openSUSE Jump 有效，但旨在取代未来 openSUSE Leap 版本的提交流程以及 openSUSE Backports 的提交请求流程。
openSUSE Jump 项目 基本上是 SUSE Linux Enterprise (SLE) 和 openSUSE Backports (Packagehub) 之上的一个伞形项目。
我们不再拥有 ports 子项目，因此所有架构，即：x86_64、ppc64le、aarch64 以及新加入的 s390x，现在将以相同的方式构建。不幸的是，32 位 arvm7 必须单独处理。
openSUSE Jump 项目的主要目标是仅包含品牌软件包以及定义产品结构的软件包（kiwi 文件、发布软件包、模式等）以及构建 ftp 树和媒体。
那么我应该在哪里提交更改？
所有提交请求 (SR) 都提交到 openSUSE Jump 项目 或更新的 openSUSE Leap 15.3 项目 OBS 然后会自动将 SR 重定向到正确的位置。
例外情况是新的软件包请求，它必须提交到特定项目（openSUSE:Backports:SLE-15-SP3、SUSE:SLE-15-SP3:GA ...），因为重定向不知道其来源。
项目 GA（发布日）之后，所有维护更改请求都必须提交到各自的 :Update 项目（例如 openSUSE:Jump:15.2:Update）。
提交要求是什么？
提交到 Backports 需要遵循 openSUSE:Backports_Packaging_Policy。 [[openSUSE:Suse_sle_review_team]
提交请求截止日期
为了有效，我们必须使用与 SUSE Linux Enterprise 15 相同的截止日期（或至少等效的截止日期）。否则，您可能会遇到 openSUSE Jump 或未来的 openSUSE Leap 仍然允许为给定版本提交的情况，但是由于提交时间晚于截止日期，它们会在 SLE 中被拒绝。
提交重定向
OBS 负责根据软件包来源将提交请求重定向到正确的项目。这将是 openSUSE Backports 或正确的 SUSE:SLE-X:SPY{:GA,:Update}。
重定向到 SUSE:SLE 项目
所有针对 openSUSE Jump 的软件包在 SUSE SLE 下的提交都将被重定向到相应的 SUSE SLE 项目。SLE 项目的结构与 openSUSE Leap、Factory 或 Backports 不同，因此了解差异非常重要。
所有 SUSE:SLE* 项目在 https://build.opensuse.org 上都是只读的。所有更改实际上都必须发生在 SUSE 内部实例 (https://build.suse.de) 中。为此，OBS 团队引入了 提交请求镜像。
openSUSE 发布团队成员，角色为 suse-sle-reviewers 必须明确批准更改，然后才能进行镜像，更多详细信息请参见 此处。
一点历史
SLE 15 的所有软件包最初都是作为 SUSE:SLE-15:GA 项目 的一部分发布的，这通常被称为 SUSE Linux Enterprise 15 ServicePack 0。
发布后对这些软件包的任何更改都通过 SUSE:SLE-15:Update 项目 中的维护请求进行处理。
SLE 维护团队正在努力限制必须支持的代码流数量，因此我们尽量避免分叉。
因此，较新的 Service Pack 将仅包含以前不可用的新软件包或必须为该版本显式分叉的软件包，因为它们引入了不向后兼容或风险过高的更改，无法作为维护更新发布。
如果软件包实际上没有收到任何重大更新，那么该软件包的来源很可能是 https://build.opensuse.org/project/show/SUSE:SLE-15:Update SUSE:SLE-15:Update 项目]。最终，这是最好的情况，因为所有 SLE 代码流都具有相同的来源。
您可以使用“osc origin”或如 openSUSE Jump 或 Leap 版本中相应 SUSE:SLE 项目中的图片所示进行检查。
了解 SLE 项目结构的重要性
好吧，代码提交截止日期和规则仅适用于当前开发 Service Pack 中引入的软件包和更改。
在大多数情况下，实际上将是维护更新，因为这是大多数 SLE 软件包的来源。对这些软件包的更改可能具有略有不同的验收标准。
如果理由充分，我们可以分叉软件包。但这会增加维护成本，因为 SUSE 必须支持多个代码流。
重定向到 openSUSE Backports
openSUSE Leap 中的大多数软件包（超过 8000 个）将存储在 openSUSE:Backports 项目中。
您可以简单地说 Backports 是新的 Leap。这很有意义，因为所有 Leap（非 SLE）请求以前都必须在 Backports 中处理，才能在 Package Hub 中提供更新，因此现在我们只需构建一次即可。
提交到从 backports 继承的任何软件包都将简单地重定向到正确的 openSUSE Backports 项目（例如 Backports for SLE-15-SP2）或在最终镜像构建后相应的 :Update 项目。
更改如何传播到 openSUSE Jump？
openSUSE Backports 和 SUSE Linux Enterprise 软件包都继承到 openSUSE Jump 中。这是通过项目链接完成的。
<link project="openSUSE:Backports:SLE-15-SP2:Update"/> <link project="SUSE:SLE-15-SP2:Update"/>
SUSE Linux Enterprise 15 的二进制文件和源代码都通过 IBS -> OBS Sync 同步到 OBS，后者已经到位。 示例 同步项目。openSUSE Backports 然后通过项目元数据中的存储库定义从相关的 SLE 版本（15.2 ：SP2）继承软件包。
同步在每次软件包构建完成后触发。有一些例外情况。同步黑名单可以在此处查看 Portal:Leap:Jump/OBS/Blacklist。对列表的任何更改必须由 Autobuild 团队在 IBS 端手动传播。