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 建议在经过一段时间的检查和整合后，用 Jump 项目中的二进制软件包替换当前的 openSUSE Leap 二进制软件包。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 工程师将能够快速查看错误，因为由于不同的构建设置（Leap 与 SLE）导致的“重建错误”减少了。
- 使用高质量的代码。预计两个项目（Leap 和 SLE）的整体质量都会提高。此外，Leap 和 SLE 都将受益于在此过程中发生的 spec 文件清理。更少的条件语句，导致更少的混淆。
问：这对 openSUSE Leap 有什么意义？
该提案提供给社区评估和讨论 SUSE 的报价和对新版本愿景。二进制文件将通过一个名为“Jump”的原型提供。这为 openSUSE 提供了一个机会来讨论该提案并集体形成对拉近代码流的愿景的看法。整个过程的实现有几个步骤或阶段。
首先，受影响软件包的 spec 文件经过修改、版本调整，并且之前未构建的软件包将在其中一个项目中构建。这不应影响 openSUSE Leap 中提供的功能——除非例如软件包的版本可能会更新。从代码角度来看，三个位数数量的软件包的 spec 文件将会更改；它们将变得更简单，并且一些错误将被修复。
与此同时，Jump 项目将填充来自 SUSE Linux Enterprise 的预构建二进制文件。
SUSE 建议并愿意投资，在 2020 年 10 月创建一个中间的 openSUSE Leap 版本，以测试在 Leap 中集成 SLE 二进制软件包。
这两个项目可能会并行存在一段时间。在此期间，openSUSE Leap 社区、用户和发布团队可以比较提供的服务，并决定是否可以继续使用 Jump 提供的服务来获得新的 Leap 15.3 版本；这段时间允许进行调整和更正（如果需要）。
只有当 Jump 的内容被用于 openSUSE Leap 15.3 时，才会发生 openSUSE Leap 中的（可见）变化。这部分是由于不同的签名，部分是由于使用的默认设置。
问：是否有简单的方法来更新来自 SUSE Linux Enterprise 的 openSUSE Leap 包？
是的！- SUSE 计划在今年晚些时候推出一个全新的流程来实现这一目的。
目前的最佳实践是联系软件包维护者，通过 bugzilla 或电子邮件。维护者可能会觉得有帮助，如果您提供了一个使用您建议的更改构建的软件包，以便他们可以直接导入它。如果您无法联系维护者，请直接针对 openSUSE Leap 提交请求，发布管理最终会将其变成 SLE 功能请求。这也可以用于文档请求。
另一种方法是使用 bugzilla.opensuse.org，发布经理会处理所有优先级未设置 (P5) 的 openSUSE 分发程序中的错误，并将具有足够理由的功能请求变成 SLE 功能。
我们知道这种现有的做法不方便，我们希望在未来几个月内改进它，允许对软件包和请求产生更直接的影响。
问：时间表是什么？
提案所需的任务将分几个阶段完成。一个暂定的时间表如下
正在进行中：作为 SUSE Linux Enterprise 的一部分，SUSE 已经选择开始进行许多这些任务，因为在大多数情况下，差异本来就不应该存在。这包括对软件包的工作——清理 spec 文件、修复错误等等。在某些情况下，效果仅在 SLE 中可见——例如，版本更新发生或子软件包的构建启用。
在宣布并普遍接受提案后：将开始实施所需的项目和流程。这包括在 openSUSE Build Service (OBS) 中设置项目，创建从 Internal BuildService (IBS) 到 openSUSE 的同步软件包的脚本和机制。
2020 年 7 月：SLE 15 SP2、openSUSE Leap 15.2 和 Jump 将发布，大部分清理和整合工作完成。SLE 和 Jump 的交叉点中的二进制文件相同。Leap 二进制文件将不同，因为虽然源代码相同，但仍然需要重新构建。
2020 年 10 月：该提案是让 Jump 成为新的 Leap（版本号待讨论）。10 月的 openSUSE 会议是一个很好的机会来讨论并决定是否应该继续推进该提案，可能需要哪些更改/修改，或者是否不应该继续进行该提案。
2021 年 7 月：如果该提案被接受，SLE 15 SP3 和 Leap 15.3 将发布，Jump 将不再需要。
问：这个提案将在哪里讨论？
该提案已发送到 opensuse-project 和 opensuse-factory 邮件列表。这两个邮件列表是讨论提案和技术影响的逻辑邮件列表。
问：Leap 和 Jump 这两个项目会永远并存吗？
不。意图是让 Leap 和 Jump 并行存在几个月。当 openSUSE Leap 15.3 / SLE 15 SP3 发布时，只有两个项目中的一个会保留。无论是“Jump”还是“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”后，我该如何提交错误报告？
错误报告的流程没有改变。您可以在 https://bugzilla.opensuse.org/ 上针对 openSUSE Distribution 产品报告错误。
功能请求将单独处理，请参考“是否有简单的方法来更新来自 SUSE Linux Enterprise 的 openSUSE Leap 软件包？”
问：包含更多来自 SUSE Linux Enterprise (SLE) 的软件包有什么好处？
SLE 和 Leap 共享更多资源，并且包含 Package Hub 仓库。第三方构建将与 openSUSE Leap 和 SLE 兼容。
问：为什么不直接提供一个免费的 SLE？
SUSE 考虑过这个选项，但认为这会带来与 openSUSE 版本竞争的利益冲突。SUSE 认为当前的方案对 openSUSE 和 SUSE 来说都是更好的选择，并认为该方案能够统一努力和开发者社区，为 Leap 做出贡献。将 Leap 和 SLE 结合得更紧密，可以提供一个真正的通用代码库，并为上游开发者营造一种统一的信息和一致的平台。
问：为什么 SLE 不能完全在 openSUSE 构建服务中开发？
目前，由于认证要求和技术合作伙伴处理等多种外部因素，这不可行。但作为下一个主要代码流的选项也在考虑中。
问：在哪里可以获取有关下一个 openSUSE Leap 基于 SLE 二进制原型机的更多信息？
项目设置完成后，Jump 项目的链接将在此处添加。
问：每个版本的支持生命周期结束模型会是什么样子？
EOL 模型将保持不变。预计用户在发布后六个月内更新到新版本。
问：Leap 15.1 或 15.2 的维护和安全性会受到影响吗？
Leap 15.1 的生命周期结束 (EOL) 将比最初计划的更长。Leap 15.2 的 EOL 将与 Leap 的先前版本类似。基于 SLE 二进制的提议版本将从 SLE 接收相同的维护和安全更新，因此将代码流结合得更紧密具有积极意义。
问：openSUSE Leap 仍然会根据 GPL 发布吗？
是的，openSUSE 的最终用户许可协议不会改变。
问：openSUSE 用户是否需要注册才能访问 Leap 二进制文件？
否，下载、更新或使用 openSUSE Leap 不需要任何注册。
问：为 Leap 贡献会更困难吗？
否，为核心软件包贡献的流程将保持不变。所有共享软件包仍然将在 Open Build Service 中提供，供社区分叉和修改。
问：将代码流结合得更紧密有哪些风险？
如果准备不充分，此举可能会为核心软件包的贡献者带来一些开发障碍。已经讨论了如何减少对贡献的任何负面影响的选项；请参阅上面的“未来我还能为 Leap 提出功能请求吗？”
问：会出现任何功能问题吗？
预计 Leap 中 SLE 中不可用的功能将通过分叉或子软件包提供。随着更多错误修复在 Leap 中激活，可能会出现一些小的功能差异，但这些差异被认为很小，可能不会直接影响用户。
问：SLE 和 openSUSE 之间的差异将如何解决？
有多种方法可以解决这个问题
- 将 openSUSE Leap 功能或其子集实现于 SUSE Linux Enterprise 15* 中。这需要作为 SUSE Linux Enterprise 要求流程的一部分获得批准。SUSE 产品管理团队表示愿意开放和改进此流程，从而社区成员可以直接互动。
- 将功能拆分为 Leap 专属软件包（类似于品牌）
- 尽可能修改差异，使其与系统无关（在安装期间从 /etc/os-release 读取字符串）。