Portal:Leap/FAQ/ClosingTheLeapGap
Q. What is being announced?
About 8 years back, SUSE had provided the sources from SLE for usage in Leap; for creating Leap those core packages are rebuilt together with the Leap-only packages; some of those Leap packages are directly based on openSUSE's rolling release, openSUSE Tumbleweed.
Today, SUSE is also offering the pre-built binaries from SLE in addition to the sources, to increase compatibility and to leverage synergies.
SUSE wants to bring the experience and quality of openSUSE Leap and SUSE Linux Enterprise (SLE) to a new level. SUSE would also like to promote openSUSE Leap as a development platform for communities and industry partners going forward.
We can achieve this together, collaborating closely between openSUSE Leap and SLE.
Q. What process is SUSE suggesting?
A first step in this direction is to simplify and clean up packages across SUSE Linux Enterprise (SLE) and openSUSE Leap. SUSE is committing engineering resources to get this done quickly.
In parallel, the SLE binary packages will be provided in a build project called Jump (link will be updated once available). To ensure a smooth integration, the binary packages will not be added to Leap directly, yet.
As a next step, SUSE is suggesting to replace the current openSUSE Leap binaries with those from the Jump project where feasible after a time of examination and consolidation. Leap (as well as Jump) would still consist of the core packages that are in SLE and openSUSE Leap as well as the known set of packages openSUSE Leap adds already on top of that.
We want to contribute to a good experience for the community, not lose community contributions or overrule decisions, thus we are actively and manually reviewing and cleaning up packages. We shall not lose functionality – neither in Leap nor SLE. The idea is to bring the two source codes together. We look at deviations on each code base and reduce that deviation, so overall there is a positive outcome for both code streams.
This clean-up and preparation is very important ground work that will set the stage for more and closer collaboration of SUSE Linux Enterprise and openSUSE Leap for years to come. To accommodate for the preparation work for openSUSE Leap, SUSE has decided to delay its own release of SUSE Linux Enterprise 15 SP2 by about 4 weeks.
Q. How will this benefit the community?
Community developers will see the following benefits for the core packages (those identical in Leap and SLE):
- Well tested packages. Leap users will receive packages that have undergone rigorous testing.
- Well tested updates. SUSE will make the updates available for packages coming from SLE, and spend resources on testing and fixing them.
- Easier bug reporting. SUSE engineers will be able to look into bugs quickly, as "rebuild-errors" due to different build setups (Leap vs. SLE) for packages are reduced.
- Use high quality code. Overall improvement in quality is expected for both projects (Leap and SLE). In addition, both, SLE and Leap will benefit from the clean-up of spec-files that will happen during this process. Less conditionals leading to less confusion.
Q. What does this mean for openSUSE Leap?
The proposal is provided to the community to evaluate and discuss SUSE's offer and vision for a new release. The binaries will be made available through a prototype called 'Jump'. This provides openSUSE an opportunity to discuss the proposal and collectively form an opinion about the vision for bringing the code streams closer together. There are several steps or phases for the whole process to be achieved.
First, the spec-files of the affected packages are overhauled, versions are adapted, and packages that were not built before will be built in one or the other project. This should have no impact on the functionality provided in openSUSE Leap - except where e.g. a version of a package might get updated. Code wise, the spec-files of a three-digit number of packages will change; they will become simpler, and some mistakes inside will be fixed.
In parallel, the Jump project will be populated with the pre-built binaries from SUSE Linux Enterprise.
SUSE suggests, and is willing to invest, to create an intermediate openSUSE Leap release in October 2020, to test drive the integration of SLE binary packages in Leap.
The two projects may co-exist for some time. During that time frame, the openSUSE Leap community, users and Release Team can compare the offerings, and decide if they are fine proceeding with the Jump offering for a new Leap 15.3 version; This time frame allows for adaptions and corrections where needed.
Only when the content of Jump is used inside of Leap 15.3, a (visible) change will take place in openSUSE Leap. This is partly due to different signings and partly due to defaults used.
Q. Is there any easy way to update an openSUSE Leap package that comes from SUSE Linux Enterprise?
There will be! - SUSE plans to introduce a brand new process for exactly this purpose later this year. until then, let's continue with the current "best practice":
The current best practice is to contact the package maintainer either through bugzilla or via email. A maintainer may find it helpful if you have a package built with your suggested changes in open build service so they can import it directly. If you are unable to contact the maintainer submit a request directly against openSUSE Leap and release management will eventually turn it into an SLE feature request for you.. This could be perhaps also used for a documentation requests.
Another way is to use bugzilla.opensuse.org where the release manager processes all bugs against openSUSE Distribution with unset priority (P5) and turns feature requests with good enough reasoning into SLE features.
We know this existing practice is not convenient and we want to improve it during the next months, allowing more direct impact on the packages and requests.
Q. What's the timeline for this?
The tasks required for the proposal will be done in several stages. A tentative timeline is as follows:
Happening now: As part of SUSE Linux Enterprise, SUSE has chosen to begin work on many of these tasks already as in most cases the differences shouldn't have existed in the first place.This includes work on the packages - cleaning up spec-files, fixing errors and so on. In some cases the effect is only visible on SLE - like a version update happening, or the building of a sub-package enabled.
Following the announcement and general acceptance of the proposal: The implementation of the required projects and processes will start. This includes the setup of the project(s) in the openSUSE Build Service (OBS), the creation of the scripts and mechanism for syncing the packages from the Internal BuildService (IBS) to the openSUSE one (OBS).
July 2020: SLE 15 SP2 , openSUSE Leap 15.2 and Jump will be released, with the majority of clean-up and consolidation work done. Binaries in the intersection of SLE and Jump are identical. Leap binaries will be different, because the sources, while identical, still undergo a rebuild.
October 2020: The proposal is to make Jump the new Leap (with a version number to be discussed). The openSUSE conference in October is a good opportunity to discuss and come to a decision whether the proposal should go forward, what changes/modifications may be needed, or if the proposal should not proceed.
July 2021: If the proposal is accepted, SLE 15 SP3 and Leap 15.3 will come out, with Jump no longer needed.
Q. Where will this proposal be discussed?
The proposal was sent to the opensuse-project and opensuse-factory mailing lists. These two lists are the logical mailing lists to discuss the proposal and technical implications respectively.
Q. Will the two projects Leap and Jump co-exists forever?
No. The intent is to have Leap and Jump exist in parallel for only few months. When openSUSE Leap 15.3 / SLE 15 SP3 is released, only one of the two projects shall remain. Whether it's "Jump" or "Leap" (as of today), and how it's named will be up to the community to decide before the release (See also "What's the timeline?") .
Q. Should the community consider renaming the distribution? Is this even being considered?
Renaming the distribution is not recommended. It is a possible decision, however, renaming a distribution poses quite some challenges as we discovered when we transitioned from openSUSE 13.2 to openSUSE Leap 42.1.
Q. Why is the prototype called 'Jump'?
The prototype of the new Leap needed a name, to distinguish between the old and new format in a good way. The name should be something close to 'Leap', but also reflect that its a big jump for the packages from the internal build system to the openSUSE build system. And the name 'Leap' was taken already. (wink)
Q. Would I be able to add my own packages to the new release?
Yes, the release would allow users/developers to add their own packages. See below for "how". As before, openSUSE Tumbleweed remains a conduit for developing packages to be submitted for Leap and SLE.
Q. How do I update or add a new package to a new openSUSE Leap?
In the end, the answer is pretty simply: You create a submit request against the next openSUSE Leap version. The Release Team will check if the package is completely new, or already in SLE available, and then handle the request accordingly. "Factory First" still applies.
Q. openSUSE Leap and SUSE Linux Enterprise both support a different set of the platform. What does that mean to openSUSE Leap?
SUSE Linux Enterprise 15 is provided on four architectures: aarch64, x86-64, ppc64le, s390x. Those shall also be a available for openSUSE Leap and Jump.
openSUSE Leap will keep RISC-V and ARMv7. They will most likely have to be built together with remaining packages in a separate project.
There are currently no plans to build SUSE Linux Enterprise for RISC-V and ARMv7.
Q. What do I get from the 8 weeks release slip? Why not defer all changes to the next release?
We'd like to have a working proof of concept and new updates mechanism before we enter the Beta phase for openSUSE Leap 15.3. And these changes are bigger than just a single release.
The extra time will be used to reduce the number of forks of SLE packages in Leap. This should also reduce work for both openSUSE Leap maintainers and release engineering.
Both Beta and RC phases will be extended and that will give us more time to finish ongoing package refreshes from Factory.
Q. Will I be able to raise feature requests for Leap in the future?
Yes. It will not be possible in the next few days, but this is planned for openSUSE Leap 15.3 / SLE 15 SP3 at the latest.
Q. How do I file bugs after the switch to 'Jump' is done?
There is no change in the process for bugs. You can report bugs against product openSUSE Distribution in https://bugzilla.opensuse.org/
Feature requests will be handled separately, refer "Is there any easy way to update an openSUSE Leap package that comes from SUSE Linux Enterprise?"
Q. What would be the benefit of including more packages from SUSE Linux Enterprise (SLE)?
SLE and Leap share more resources and the Package Hub repositories are included. Third party builds will be compatible with both openSUSE Leap and SLE.
Q. Why not just have a FreeSLE?
SUSE considered this as an option, but felt it would bring about competing interests with openSUSE releases. SUSE believes the current proposal is a better option for both openSUSE and SUSE, and sees the proposal unify efforts and developer communities to contribute to Leap. Bringing Leap and SLE closer together provides a true common code base and foster one message and one consistent platform for upstream developers.
Q. Why isn't SLE simply developed completely in the openSUSE Build Service?
Currently, this is not feasible due to several external factors, including certification requirements and technology partner handling. It is considered though as an option for a next major codestream.
Q. Where do I get more info about the SLE binary-based prototype of the next openSUSE Leap?
Links to the Jump project will be added here after the project setup is finished.
Q. What would the support end of life model for each release look like?
The EOL model will remain the same. Users are expected to update to a new version within six month of its release.
Q. Would maintenance and security be affected for Leap 15.1 or 15.2?
Leap 15.1 will have a longer than expected End of Life (EOL) than originally planned. Leap 15.2 would have similar EOL as previous versions of Leap. The proposed release based on SLE binaries would receive the same maintenance and security updates from SLE, so there is a positive benefit to moving the code streams closer together.
Q. Will openSUSE Leap still be released under the GPL?
Yes, the end user license agreement for openSUSE will not change.
Q. Will openSUSE users need to register to access Leap binaries?
No, there will not be any registration required to download, update or use openSUSE Leap.
Q. Will it be harder to contribute to Leap?
No, the process for contributing to core packages will remain the same. All the shared packages will still be available in Open Build Service for the community to fork and modify as needed.
Q. What would be the risks in bringing the code streams closer together?
If not prepared correctly, the move could provide some development hurdles for contributors to the core packages. Options have already been discussed on how to reduce any negative impact on contributions; see also above Will I be able to raise feature requests for Leap in the future?
Q. Will there be any functionality issues?
Functionality that is not available in SLE is expected to become available through forks or sub-packages in Leap. There might be small functional differences as more bug fixes are activated in Leap, but the amount of those is considered low and may not affect users directly.
Q. How will the difference between SLE and openSUSE be addressed?
There are multiple ways to address this:
- Implement openSUSE Leap features or a subset thereof in SUSE Linux Enterprise 15*. This requires approval as part of the SUSE Linux Enterprise requirements process. The SUSE Product Management team has expressed their willlingness to open and improve this process, thus community members can directly interact.
- Split functionality into a separate leap-specific package (similar to branding)
- Where possible, modify differences so it's system agnostic (read strings from /etc/os-release during install).
Q. Are there any weekly updates?
History of weekly updates can be found here [1]. Related openSUSE release engineering meeting minutes history is can be found here [2].