Portal:Leap/FAQ/ClosingTheLeapGap
问：正在宣布什么信息？
大约 8 年前，SUSE 提供了来自 SLE 的源代码以在 Leap 中使用。这些核心软件包与 Leap 专用软件包一起被重组从而创造了 Leap。其中一些 Leap 软件包直接基于 openSUSE 的滚动发行版 —— openSUSE Tumbleweed。
如今，SUSE 除了提供源代码外，还提供了来自 SLE 的预构建二进制文件，以提高兼容性并发挥协同效应。
SUSE 希望将 openSUSE Leap 和 SUSE Linux Enterprise （SLE） 的经验和质量提升到一个新的水平。SUSE 还希望推动 openSUSE Leap 作为社区和行业合作伙伴未来的开发平台。
我们可以共同实现这一目标，在 openSUSE Leap 和 SLE 之间密切合作。
问：SUSE 建议的过程是什么？
朝这个方向迈出的第一步是简化和清理 SUSE Linux Enterprise （SLE） 和 openSUSE Leap 通用的软件包。SUSE 正在投入工程资源以快速完成此工作。
同时，SLE 二进制包将在名为 Jump 的构建项目中提供（链接将在可用时更新）。为了确保顺利集成，二进制包不会直接添加到 Leap 中。
下一步，SUSE 建议在经过一段时间的审查和整合后，在可行的情况下将当前 openSUSE Leap 二进制文件替换为 Jump 项目中的二进制文件。Leap（以及 Jump）仍将由 SLE 和 openSUSE Leap 中的核心软件包以及 openSUSE Leap 已添加的一组已知软件包集合组成。
我们希望为社区提供良好的体验，而不是失去社区的贡献或推翻决策，因此，我们正在积极地手动审查和清理软件包。我们不会失去功能——无论是 Leap 还是 SLE。我们把两者的源代码放在一起，查看每个代码库上的偏差并减少这种偏差，因此总的来说，两个代码流都有一个积极的结果。
这次清理和准备是非常重要的基础工作，它将为今后几年 SUSE Linux Enterprise 和 openSUSE Leap 的更多、更紧密的协作奠定基础。为了适应 openSUSE Leap 的准备工作，SUSE 已决定将其自己的 SUSE Linux Enterprise 15 SP2 的发布推迟大约 4 周。
问：这对社区有何益处？
社区开发人员将看到核心软件包包（Leap 和 SLE 相同的那些）的以下好处：
- 经过良好测试的软件包。Leap 用户将收到经过严格测试的软件包。
- 经过良好测试的更新。SUSE 将使来自 SLE 的软件包可以获得更新，并将资源用于测试和修复它们。
- 更容易报告错误。SUSE 工程师将能够快速查找 bug，因为由于不同的构建设置（Leap 与 SLE）导致的"重建错误"减少了。
- 使用高质量的代码。预计两个项目（Leap 和 SLE）的质量会全面提高。此外，SLE 和 Leap 都将受益于此过程期间将发生的 spec 文件的清理。较少的条件语句可以减少混淆。
问：这对 openSUSE Leap 来说意味着什么？
这个提议被提供给社区，以评估和讨论 SUSE 的提议和新版本的愿景。这些二进制文件将通过一个名为「Jump」的原型提供。这为 openSUSE 提供了一个讨论建议的机会，并就如何将代码流更紧密地结合在一起的愿景形成共同意见。整个过程有几个步骤或阶段要实现。
首先，对受影响的软件包的 spec 文件进行彻底检查，对版本进行调整，并在一个或另一个项目中构建以前未构建的软件包包。这应该不会影响 openSUSE Leap 提供的功能——除非类似软件包的版本可能会更新这样的情况。在代码方面，几百个软件包的 spec 文件将被更改；它们将变得更简单，并且内部的一些错误将得到修复。
同时，将使用来自 SUSE Linux Enterprise 的预构建二进制文件填充Jump项目。
SUSE 建议并愿意投资，以在 2020 年 10 月创建一个中间 openSUSE Leap 版本，以在 Leap 中尝试 SLE 二进制包的集成。
这两个项目可能共存一段时间。在此期间，openSUSE Leap 社区、用户和发布团队可以比较产品，并决定它们是否认为继续以 Jump 来提供 Leap 15.3 是合适的。此时间范围允许根据需要进行调整和更正。
只有在Leap 15.3内使用Jump的内容时，openSUSE Leap 才会发生显著的改变。这些改变部分是由于不同的签名，部分是由于使用了默认设置。
问：是否有任简单的方法来更新 openSUSE Leap 中来自 SUSE Linux Enterprise 的软件包？
会有的！—— SUSE 计划在今年晚些时候推出一个全新的流程。在此之前，让我们继续当前的「最佳实践」：
当前的最佳做法是通过 bugzilla 或电子邮件联系包维护者。如果您在开放构建服务中应用您所建议的变更构建了一个软件包，以便他们可以直接导入，那么维护人员可能会觉得很有帮助。如果您无法联系维护者来提交针对 openSUSE Leap 的请求，发布管理最终将将其转换为 SLE 功能请求。这或许也可用于文档请求。
另一种方法是使用 bugzilla.opensuse.org，在这里，发布管理器以未设置的优先级（P5）处理针对 openSUSE 发行版的所有错误，并将具有充分理由的功能请求转换为 SLE 功能。
我们知道这种现有做法并不方便，我们希望在未来几个月改进它，从而对软件包和请求产生更直接的影响。
问：这件事的时间表是什么？
该提案所需的任务将分几个阶段完成。暂定时间表如下：
正在进行：作为 SUSE Linux Enterprise 的一部分，SUSE 已经选择开始处理这其中的许多任务，因为在大多数情况下，差异一开始就不应该存在。这包括对软件包的工作——清理 spec 文件，修复错误等。在某些情况下，效果仅在 SLE 上可见——如版本更新发生或子软件包构建被启用。
在提案宣布并获得普遍接受之后：将开始执行所需的项目和流程。这包括在 openSUSE 构建服务（OBS）中设置项目，创建脚本和机制以将包从内部构建服务（IBS）同步到 OBS。
2020 年 7 月：SLE 15 SP2、openSUSE Leap 15.2 和 Jump 即将发布，大部分清理和巩固工作已完成。SLE 和 Jump 交集中的二进制文件是相同的。Leap 的二进制文件将有所不同，因为源代码虽然相同，但仍要经历重新构建。
2020 年 10 月：提案建议让 Jump 成为新的 Leap （版本号有待讨论）。10月份的 openSUSE 会议是讨论和决定是否提案应该向前推进、可能需要哪些修改/调整，或者该提案是否不应继续进行的一个很好的机会。
2020 年 7 月：如果提案被接受，将出现 SLE 15 SP3 和 Leap 15.3，Jump 将不再被需要。
问：这项提案将在哪里讨论？
这项议案已发送到 opensuse-project 和 opensuse-factory 邮件列表，这两个列表是分别用于讨论建议和技术影响。
问：Leap 和 Jump 会永远共存吗？
否。我们的目的是让 Leap 和 Jump 并行存在几个月。当 openSUSE Leap 15.3 / SLE 15 SP3 发布时，两个项目中只能保留一个。将被保留的是「Jump」or「Leap」（像目前这样），以及有关它将如何被命名的话题将由社区在发布前决定。（另请参阅「这件事的时间表是什么？」）
问：社区是否应该考虑甚至正在考虑重命名发行版？
不建议重命名发行版。然而，这是一个可能的决定，重命名发行版带来了一些挑战，正如我们从 openSUSE 13.2 过渡到 openSUSE Leap 42.1 时发现的挑战。
问：为什么原型叫「Jump」？
新 Leap 的原型需要一个可以很好与旧版相区分的名字。这个名字应该接近「Leap」，并反应出对于从内部构建系统到 openSUSE 构建系统的软件包而言，这是一个巨大的飞跃。而「Leap」（飞跃）这个名字已经被使用了。
问：我能否将自己的软件包添加到新版本？
是，该版本将允许用户/开发人员添加自己的软件包。请参阅下文了解如何这样做。和以前一样，openSUSE Tumbleweed 仍然是开发要提交给 Leap 和 SLE 的软件包的渠道。
问：如何向新的 openSUSE Leap 更新或添加新软件包？
答案很简单：您可以针对下一个 openSUSE Leap 版本创建提交请求。发布团队将检查该软件包包是否是完全新的，或者是否已在 SLE 中可用，然后相应地处理请求。「Factory First」仍然适用。
问：openSUSE Leap 和 SUSE Linux Enterprise 都各种支持一组不同的平台。这对 openSUSE Leap 来说意味着什么？
SUSE Linux Enterprise 15 在四种体系结构上提供： aarch64、x86-64、ppc64le、s390x。这些也应可用于 openSUSE Leap 和 Jump。
openSUSE Leap 将保留 RISC-V 和 ARMv7 支持。它们很可能必须与其他包一起构建在一个单独的项目中。
目前没有为 RISC-V 和 ARMv7 构建 SUSE Linux Enterprise 的计划。
问：我从8周的发行单中可以获得什么？为什么不将所有更改推迟到下一个版本呢？
在进入 openSUSE Leap 15.3 的 Beta 阶段之前，我们希望有一个有效的概念证明和新的更新机制。这些更改比起一个单一的发布版来说更大。
多余的时间将用于减少 Leap 中 SLE 软件包的派生数。这也应该会减少 openSUSE Leap 维护者和发布工程的工作。
Beta 和 RC 阶段都将延长，这将给我们更多的时间完成 Factory 正在进行的软件包更新。
问：我将来能否提出 Leap 的功能请求？
是。这在未来一段时间内是不可能的，但计划最晚在 openSUSE Leap 15.3/SLE 15 SP3 中实现。
问：完成切换到「Jump」后我该如何提交 Bug？
错误的过程没有改变。您可以在 https://bugzilla.opensuse.org/ 中针对 openSUSE 发行版报告错误。
功能请求将单独处理，请参阅「是否有任简单的方法来更新 openSUSE Leap 中来自 SUSE Linux Enterprise 的软件包？」
问：包含更多来自 SUSE Linux Enterprise (SLE) 的软件包的好处是什么？
SLE 和 Leap 共享包括 Package Hub 存储库在内的更多资源。第三方构建将同时与 openSUSE Leap 和 SLE 兼容。
问：为什么不干脆有个FreeSLE呢？
SUSE 认为这是一种选择，但认为这会带来与 openSUSE 发行版的利益冲突。SUSE 认为当前的提案对 openSUSE 和 SUSE 来说都是一个更好的选择，并认为该提案统一了努力和开发社区，为Leap做出了贡献。将 Leap 和 SLE 更紧密地结合在一起提供了一个真正的通用代码库，并为上游开发人员提供一致的消息和平台。
问：为什么 SLE 不是完全在 openSUSE 构建服务中开发的？
目前，由于几个外部因素，包括认证要求和技术合作伙伴的处理，这不可行。不过，它被视为下一个主要代码流的选项。
问：我从哪里可以获取有关基于 SLE 二进制软件包的下一版 openSUSE Leap 原型的更多信息？
项目设置完成后，将在这里添加指向 Jump 项目的链接。
问：每个版本的「结束支持」模型会是什么样子的？
EOL 模型将保持不变。用户应该在新版本发布后的六个月内更新到新版本。
问：Leap 15.1 或 15.2 的维护和安全性是否会受到影响？
Leap 15.1 的生命周期结束时间 （EOL） 将比原计划更长。Leap 15.2 将具有与早期版本的 Leap 类似的 EOL。基于 SLE 二进制文件的建议发行版将从 SLE 接收相同的维护和安全更新，因此将代码流更紧密地连接在一起是有好处的。
问：openSUSE Leap 是否仍会在 GPL 下发布？
是，openSUSE 的最终用户许可协议不会更改。
问：openSUSE 用户是否需要注册才能访问 Leap 二进制文件？
否，下载、更新或使用 openSUSE Leap 不需要任何注册。
问：为 Leap 做贡献会不会更难？
否，贡献核心软件包的过程将保持不变。所有共享软件包仍将在开放构建服务中可用，供社区根据需要派生和修改。
问：将代码流更紧密地连接在一起的风险是什么？
如果准备不当，此举可能会给核心软件包的贡献者带来一些开发障碍。关于如何减少对贡献的任何负面影响的选项已经讨论过了。另请参见上文：「我将来是否可以提出Leap的功能请求？」
问：是否有任何功能问题？
SLE 中不可用的功能预计将通过 Leap 中的派生或子软件包提供。由于在 Leap 中启用了更多 bug 修复，可能会存在一些小的功能差异。但这些修复的数量较低，可能不会直接影响用户。
问：如何处理 SLE 和 openSUSE 的区别？
有多种方法可以解决这个问题：
- 在 SUSE Linux Enterprise 15 中实现 openSUSE Leap 的功能或其子集。这需要作为 SUSE Linux Enterprise 请求流程的一部分进行批准。SUSE 产品管理团队表示愿意打开和改进此过程，因此社区成员可以直接进行交互。
- 将功能拆分为单独的特定于 Leap 的软件包（类似于品牌）
- 在可能的情况下，修改差异，以便与系统无关（在安装过程中从 /etc/os 中读取字符串）。