Language Selection

English French German Italian Portuguese Spanish

Bringing Leap and SUSE Linux Enterprise closer together - a proposal

Filed under
SUSE
Hi everyone,

today I have some exciting news and a proposal to relay: SUSE wants to
go another step in openness towards the openSUSE community and suggests
to bring the relationship of openSUSE Leap and SUSE Linux Enterprise to 
a new level.

Internally this idea is called "Closing the Leap Gap" and proposes to
strengthen and bring more closely together:

 * developer communities, by focusing on openSUSE Leap as a 
   development platform for communities and industry partners;
 * user communities, by leveraging the benefits of both a stable
   Enterprise code base and the speed of community contributions;
 * the code bases of openSUSE Leap and SUSE Linux Enterprise (SLE), 
   by not only sharing sources, but also offering the SUSE Linux 
   Enterprise binaries for inclusion in openSUSE Leap.

The proposal includes a three step approach:

 1. Merge the code bases for the intersection of openSUSE Leap 15.2 
    and SUSE Linux Enterprise 15 SP2 as much as possible without loss 
    of functionality or stability. (SUSE has started a cleanup process 
    on the SUSE Linux Enterprise side already.)
 2. In parallel to classic openSUSE Leap 15.2 create a flavor leveraging
    SLE binaries, leading to an intermediate release in the October 2020
    time frame.
 3. Build openSUSE Leap 15.3 with SLE binaries included by default
    (assuming community agreement).

As you can imagine, a number of people have been involved with this
so far, and I'd like to pull some of them in front of the curtain in 
a little interview.

Q: Thomas, all of engineering at SUSE reports to you, and I know 
   openSUSE is something you care about quite a bit.  What is SUSE  
   putting on the table here?

Thomas Di Giacomo: Let me step back, and give you a perspective as I see
  it. SUSE for 27+ years has been a part of global open source ecosystem
  that includes a vast number of developers, end users, communities,
  and organizations of all sizes working together and benefiting from
  the collective work. Most of our engineers are involved as well with
  some open source communities that they feel passionate about.

  Open source communities are an integral part of who we are and the
  ecosystem we serve. Naturally, we feel responsible to support the
  communities and the work done by them. openSUSE is no different and
  is actually even more special and very dear to SUSE. So, it should
  come as no surprise that we are fully committed towards the openSUSE
  project(s) and its community. It makes us all feel proud to see Leap
  and Tumbleweed grow and evolve, together with SUSE Linux Enterprise.
  This effort of our engineers working together with others in the
  openSUSE community will benefit everyone involved for many years 
  to come.

Q: And why are you doing this?

Thomas: We want open source to succeed for everyone – developers,
  contributors to end users and everyone in between. The benefits of
  open source are tremendous when the ecosystem grows as a result of
  the positive virtuous cycle of – contributing more, supporting the
  contributions, benefiting from contributions, which inspires more
  people contributing, and it goes on to grow as an upward virtuous spiral.

  We feel fortunate to be in the position of seeing the openSUSE community
  grow in tandem with the success of SUSE Linux Enterprise, and both
  feeding off each other to grow even more. This idea definitely goes in
  that direction. Now, let me defer to Matthias who came up with this idea.

Q: Okay, so, Matthias, first of all: what is your role at SUSE?

Matthias Eckermann: I am leading the Product Management team for 
  Linux platforms, covering SUSE Linux Enterprise, Edge, and Security.

Q: And what made you propose this?

Matthias: My team and I realized that the engagement of our SLE 
  business with the openSUSE community does not fully fit our view 
  on openness, and that mutual benefits are not leveraged sufficiently.

  We discussed what it would take to bridge the gap and bring the
  relationship to the next level. Beyond a common ground on the
  technical side, the code streams, this requires learning from each
  other; for example, we need to re-establish an open feature process
  between community, SUSE, and our industry partners.

  Thus we developed "Closing the Leap Gap", and - to test whether it
  might have a chance to fly - we outlined the initial idea with the
  openSUSE Board before going for approvals by SUSE management.

Q: You mention the board, so let me ask.  What is your take?
   What opportunities, benefits do you see?  What risks?

Dr. Axel Braun: With this change, we can make better use of our
  resources, as two code bases converge - so one build target less to
  consider. Everyone who packages for Leap and for Package Hub will
  immediately benefit from this.

Marina Latini: It's really exciting to see how SUSE is trying to increase
  its support for Leap, reducing the existing differences between our
  openSUSE Leap and SLE. I can see this proposal as a way to be more
  inclusive, giving to the community the opportunity to contribute in 
  an easier way to Leap and giving the chance to bring the openSUSE 
  spirit also in an Enterprise product like SLE.

  On the other hand, every new move is a change and we need to be sure
  that the changes won't limit our community freedom to submit packages
  to Leap or won't slow down Leap for following the internal SUSE
  development model.

Q: Matthias, that sounds like some extra effort required.
   How is SUSE contributing, what is SUSE committing to?

Matthias: Indeed, there is quite some one-time effort needed to get
  (back) to the common ground; this is covered by SUSE engineering teams;
  two groups are heavily involved: The Open Build Service experts are
  designing a workflow for a smooth integration of the binaries, and
  for reducing the long term maintenance efforts for our community
  contributors. SUSE release managers and packagers are working hard
  to synchronize the code bases without losing functionality or quality.
  Hundreds of change requests have been filed already, and to get this
  done properly, we are delaying the release of SUSE Linux Enterprise
  15 SP2 to July.

  And we are willing to invest more, to drive the idea to success
  quickly: we would take the burden, to create an intermediate openSUSE
  Leap release in October 2020 which then would incorporate SUSE Linux
  Enterprise binaries into Leap the first time.

  Probably, Adrian can comment on the Build Service aspects, and Lubos
  what it means to developers within SUSE and to the community release
  process?

Q: So, Lubos, as release manager for Leap, what have you been doing
   so far, and what is the impact you see?

Lubos Kocman: I spent most of the time on collecting data regarding SLE
  and Leap differences and having follow-up discussions and transforming
  feedback into action items. Max and the rest of the openSUSE release
  engineering team meanwhile did an excellent job of keeping Leap release
  activities going forward.

  The idea of re-using should generally lower the effort on the Leap side.
  However, it comes with the price of increased complexity to bring all
  pieces together. A new process will allow external contributors to file
  feature or update requests directly to SLE. This will already help a lot.

Q: Is this an outcome bound effort, or time bound?  I know the SLE
   release schedule is a bit like a 300m tanker.

Lubos: It's both. I see this as a balance between what can we deliver,
  how, and to what date. It took quite some effort to create a plan
  acceptable by all involved teams. Splitting the work across the
  upcoming two releases seemed to be accepted well at least by 
  involved parties so far.

Q: So, that is SLE 15 SP2.  How about Leap 15.2?

Lubos: openSUSE Leap 15.2 will have to slip by about 8 weeks to incorporate 
  all changes from the SLE and align with its new schedule. I believe that 
  the release will find a great use for extra time since we're still 
  finishing the refresh of packages from Factory. The prototype will 
  be meanwhile available in parallel to the openSUSE Leap 15.2.

Q: How is that research proceeding, Adrian?

Adrian Schröter: We have an idea about the setup in build.opensuse.org.
  I anticipate to have a first prototype of the build setup in next three
  weeks. And more important is how to develop the workflows to allow a
  more collaborative joint effort between SLE and openSUSE development.

  However, we must keep in mind that this is really an entire new way to
  develop a distribution. On one hand it makes a lot of sense to integrate
  for example the SUSE Backports (aka Package Hub) people directly in our
  development process. This will make our distribution development stronger.

  On the other hand, we also must find ways how to solve new problems.
  For example how to keep our builds for architectures not covered by
  SLES like Arm 32bit and RISC-V. Also the turn around times of submissions
  and build results will be a challenge in the initial setup. And last but
  not least, the installed systems and users may need to deal with more
  repositories.

  But we have one year to work on these problems in parallel to our
  stable distribution. And we are indeed looking forward to make 
  openSUSE and SLE development more beneficial than ever.

Gerald: Thanks everyone for your input.  I'll be sharing all this with
  openSUSE mailing lists, and am sure there will be further questions,
  offers to help, and other input, so please chime in there.


https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap has an FAQ with
more details.


Lubos is going to send a proposal with more details on the implementation
side to opensuse-factory@.

I suggest we focus technical discussions of this offer and proposals
there (opensuse-factory@) and general discussions on opensuse-project@.


So, what do you think?

Gerald

Read more

OpenSUSE Leap + SUSE Linux Enterprise Planning To Move Closer

  • OpenSUSE Leap + SUSE Linux Enterprise Planning To Move Closer In 2020

    SUSE and the openSUSE community are working to move SUSE Linux Enterprise and openSUSE Leap closer together.

    A proposal sent out today with the interest of SUSE is for taking the openSUSE Leap and SUSE Linux Enterprise relationship to a new level. This new collaboration would more closely align the source trees of openSUSE Leap and SUSE Linux Enterprise Linux, including the use of SUSE Linux Enterprise binaries within Leap.

SUSE proposes synchronizing code streams, includes SLE binaries

  • SUSE proposes synchronizing code streams, includes SLE binaries for openSUSE Leap

    SUSE has sent a proposal to the openSUSE community about bringing the code streams of both SUSE Linux Enterprise and openSUSE Leap closer together. The proposal includes SLE binaries for the community version.

    Bringing the code streams closer together to provide full compatibility provides several advantages to the community going forward such as the use of higher-quality code due to the clean-up of spec-files, an improved relationship between the two distributions, easier bug reporting, less code streams to maintain, extensively tested packages and the inclusion of SLE supported architectures like s390x.

    “With this change, we can make better use of our resources as one code base converge, so one build target less to consider,” expressed openSUSE board member Axel Braun in an email sent out to the community about the proposal. “Everyone who packages for Leap and for Package Hub will immediately benefit from this.”

    The proposal provided a staged approach to implementing the vision. The email listed the following options: • Merge the code bases for the intersection of openSUSE Leap 15.2 and SUSE Linux Enterprise 15 SP2 as much as possible without loss of stability or functionality. (SUSE has actually started merging from Leap into SUSE Linux Enterprise.) • Create an intermediate openSUSE Leap flavor where SLE binaries are used inside (October 2020 time frame) in parallel to classic Leap 15.2. • Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement).

openSUSE & SUSE Linux Are Coming Closer

  • openSUSE & SUSE Linux Are Coming Closer

    openSUSE and SUSE are working on bringing their distribution even closers. So much so that SLE binaries will be available to openSUSE users and it will be easier for openSUSE users to easily migrate to enterprise-grade Linux. We sat down with Dr. Gerald Pfeifer, SUSE CTO and openSUSE chair and Matthias Eckermann, Director Product Management, Linux Platforms.

Bringing openSUSE Leap and SLE closer

  • Bringing openSUSE Leap and SLE closer

    SUSE Linux is one of the oldest Linux distributions still in existence today, with a history that starts in 1994. Today it exists in a few forms, including the commercial SLE offering, which mainly targets the server market.

    The openSUSE project creates a community version of the SUSE distribution; its work is largely sponsored by SUSE (the company). OpenSUSE produces two main variants, the relatively stable openSUSE Leap and a rolling version called openSUSE Tumbleweed. Leap is built on packages from SLE, which form a stable base made up of relatively old software releases. For example, the Leap kernel version is the same as in the corresponding SLE version. The openSUSE team adds some changes to the SLE packages, then rebuilds them for Leap; the team also adds newer versions of some packages, such as desktop environments, from Tumbleweed. The current version of Leap is 15.1 (as of April 2020).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Canonical/Ubuntu: LTS, ROS 2, OSM and Fabrica

  • Ubuntwtoooo 20.04!

    The next LTS release of Ubuntu has dropped and it’s frankly fantastic. We’re getting you up and running with it as quickly as possible in our main feature this month for those readers who are new to Linux or Ubuntu, and we’ll cover off the important new features you’ll be itching to try out. After nearly 16 years of continuous development this release isn’t here to innovate as much to refine Ubuntu. The Gnome desktop – love it or hate it – feels super-slick and has received some much-needed optimisations over the past year. The theme has been polished to a sheen and icons refreshed. There will, of course, be the usual cascade of spin-off updates, ranging from the usual array of xyz-buntus but also downstream distros. The new Pop!_OS is already out and we’ve managed to squeeze a review into this issue. We’re very much looking forward to seeing how Mint 20 works out, too.

  • The State of Robotics – May 2020

    With several countries finally emerging from lockdowns and markets showing signs of economic recovery, we’ve seen the newscycle steadily shift its focus away from Covid-19. And that will be reflected in our robotics recap as well. Let’s get right to it. [...] As is the ROS tradition, now that we’re nearing the ROS 2 Foxy release date, it’s time to name the G-version of ROS 2. The discussion thread has received a ton of suggestions. Our favorites so far are Galactic Gamera, Grumpy Gopherus, and Gutsy Gibba. Head over to the Discourse page to provide your own recommendations. Something to keep in mind – not every user is a native English speaker, so the best release names are easy to pronounce. Glacial, glorious and global are quite practical. Glamorous, groundbreaking and geosynchronous… not so much.

  • OSM#9 Hackfest: the highlights

    For this hackfest, the organisers decided to change the structure in a way that would facilitate hands-on sessions; with attendees playing with technology to learn and unlock new capabilities and skills – staying true to the very nature of a hackfest The event spanned three days of theory and workshop sessions, with an extra day for ecosystem-related presentations and leadership, and technical sessions happening in a parallel track for the full week. The overall experience was great with active participation and every session felt like adding a piece to the puzzle to highlight the benefits that OSM can bring to telcos in a landscape that is rapidly moving towards network function virtualisation and containerisation. Participants were introduced to the end-to-end hackfest scenario on the first day. The next two days were all about how to deploy and operate network functions on physical machines (PNFs), virtual machines (VNFs) and Kubernetes-managed containers (KNFs), and how to do network slicing, auto-scaling and testing. Slides from all sessions can be found on the OSM wiki. [...] Canonical has a strong presence in the OSM leadership team, with CEO Mark Shuttleworth being a technical steering committee (TSC) member plus Beierl and Garcia from Canonical’s OSM engineering team as MDLs. Canonical’s vision is to bring better economics for data centres by providing smarter operations at a better price. This vision is very appealing to telecommunications providers that face complex network operations at scale. Our engagement in OSM aims at driving comprehensive design choices to drive better code and operations. During the technical sessions, we presented the latest version of the OSM installer. The installer is able to deploy OSM using upstream OSM charms in high-availability mode on a user-provided Kubernetes, bootstrap a LXD cluster and link it to a virtual infrastructure manager (VIM) such as an Openstack cloud. Similarly, the installer can deploy OSM on a single-node, using Microk8s as the K8s substrate. The technical sessions also addressed the roadmap plan for OSM Release EIGHT that should be available in July 2020 and defined upcoming features to address production readiness. This marks an inflection point in OSM as the project enters a more mature stage.

  • Fabrica – Your self-hosted snap factory

    There are many ways one can go about building snaps. You can do it on your local system, by manually running commands in a terminal window. If you have a developer account in the Snap Store, you can use the integrated build functionality to create snaps. You can also use Launchpad, Electron Builder or a range of CI/CD systems. And you can also run your own, self-hosted snap building factory!

Yaru Colors Updated With Ubuntu 20.04 Yaru Theme In 12 Colors (GTK, Icons, GNOME Shell, More)

The colors available with this theme pack are aqua, blue, brown, deep blue, green, grey, MATE (uses the Ubuntu MATE green), orange, pink, purple, red and yellow. The themes are available in light, dark and regular (mixed) variants, just as Yaru is available in Ubuntu 20.04. There are also light and dark GNOME Shell themes. These are Yaru DarkBlue in regular and dark variants, and the Yaru Purple theme light variant... Read more

today's leftovers

  • Baïkal (CalDAV) 0.7.0 in Gentoo

    Just this past week, the new version of of Baïkal (0.7.0)—a PHP CalDAV and CardDAV server based on Sabre—was released, and one of the key changes was that support was added for more modern versions of PHP (like 7.4). Since my personal Gentoo server is running the ~amd64 branch, I had to wait for this release in order to get my CalDAV server up and running. For the most part, installing Baïkal 0.7.0 was a straightforward process, but there were a couple of “gotchas” along the way.

  • Fedora 33 Proposal To Allow Packages To Build With LLVM Clang Rather Than Requiring GCC

    A feature proposal raised by Red Hat's Jeff Law would allow Fedora packages to be built under the LLVM Clang compiler rather than defaulting that all packages to be built under GCC. Clang-built packages would happen where the upstream software recommends using Clang by default or for software without an upstream to let the packager(s) make their own decision.

  • Red Hat's Stratis Storage 2.1 Released With Encryption Support, Other Improvements

    Version 2.1 of Red Hat's Stratis daemon is now available that aims to bring Btrfs/ZFS-like functionality atop the XFS file-system paired with LVM. Stratis 2.1 is the first release in three months for this Red Hat storage project. Most notable to Stratis 2.1 is the daemon now handling encryption support, closing off a string of bug reports / requests over such functionality considering other modern Linux file-systems long offering easy to manage encryption support. The Stratis 2.1 storage encryption makes use of LUKS2 for encryption.

  • The Talospace Project: Firefox 77 on POWER

    Firefox 77 is released. I really couldn't care less about Pocket recommendations, and I don't know who was clamouring for that exactly because everybody be tripping recommendations, but better accessibility options are always welcome and the debugging and developer tools improvements sound really nice. This post is being typed in it. There are no OpenPOWER-specific changes in Fx77, though a few compilation issues were fixed expeditiously through Dan Horák's testing just in time for the Fx78 beta. Daniel Kolesa reported an issue with system NSS 3.52 and WebRTC, but I have not heard if this is still a problem (at least on the v2 ABI), and I always build using in-tree NSS myself which seems to be fine. This morning Daniel Pocock sent me a basic query of 64-bit Power ISA bugs yet to be fixed in Firefox; I suspect some are dupes (I closed one just this morning which I know I fixed myself already), and many are endian-specific, but we should try whittling down that list (and, as usual, LTO and PGO still need to be investigated further). I'm still using the same .mozconfigs from Firefox 67.

  • A New RegExp Engine in SpiderMonkey

    Regular expressions – commonly known as RegExps – are a powerful tool in JavaScript for manipulating strings. They provide a rich syntax to describe and capture character information. They’re also heavily used, so it’s important for SpiderMonkey (the JavaScript engine in Firefox) to optimize them well. Over the years, we’ve had several approaches to RegExps. Conveniently, there’s a fairly clear dividing line between the RegExp engine and the rest of SpiderMonkey. It’s still not easy to replace the RegExp engine, but it can be done without too much impact on the rest of SpiderMonkey. In 2014, we took advantage of this flexibility to replace YARR (our previous RegExp engine) with a forked copy of Irregexp, the engine used in V8. This raised a tricky question: how do you make code designed for one engine work inside another? Irregexp uses a number of V8 APIs, including core concepts like the representation of strings, the object model, and the garbage collector.

  • After Taming Open Access, Academic Publishing Giants Now Seek To Assimilate The World Of Preprints

    As Techdirt has reported, the open access movement seeks to obtain free access to research, particularly when it is funded by taxpayers' money. Naturally, traditional academic publishers enjoying profit margins of 30 to 40% are fighting to hold on to their control. Initially, they tried to stop open access gaining a foothold among researchers; now they have moved on to the more subtle strategy of adopting it and assimilating it -- rather as Microsoft has done with open source. Some advocates of open access are disappointed that open access has not led to any significant savings in the overall cost of publishing research. That, in its turn, has led many to urge the increased use of preprints as a way of saving money, liberating knowledge, and speeding up its dissemination. One reason for this is a realization that published versions in costly academic titles add almost nothing to the freely-available preprints they are based on.

  • USB4 Is Coming! USB4 Is Coming!

    Widely reported in the technical press, USB4, a.k.a. USB 4.0, should be finding its way to your computing world soon. There is hope for a late-2020 rollout for cables and devices, but sometime in the first half of 2021 is more realistic, given the global manufacturing shutdown prompted by the coronavirus pandemic. You can download the "official" spec information for USB4 here (zip file). For a little bit of background, in 2017, Intel donated the Thunderbolt 3 specs to the USB Implementers Forum for third-party use. Thunderbolt 3 is significant, due to it sporting 40Gbps transfer speeds. While the standard for Thunderbolt 3 is free to use and implement, the use of the Thunderbolt 3 trademark is not, and still requires certification by Intel before advertising that a device is Thunderbolt 3 compatible. Additionally, the Thunderbolt 3 compatibility is only available if individual manufacturers choose to build it in. And, I have to admit that I had never heard of Thunderbolt until I started to write this article. But then again, I don't spend endless hours perusing new computer systems that I know I cannot afford, either, which is most likely why Thunderbolt never appeared on my radar. After experiencing the confusing rollout of the USB 3 standard, and its subsequent (and even more confusing) split into USB 3.1 and USB 3.2 "standards," don't hold your breath for anything less confusing with the USB4 rollout. Like most users, I'll withhold judgement. After all, I live in Missouri, who's nickname is "The Show Me" state.

Programming Leftovers: Git, JS, Perl and Python

  • Top 20 Git Commands with Practical Example

    If you are here reading this post, there is a high probability that you have heard or interacted with Github, and you now want to learn Git. Before we continue with showing you some of the cool Git commands, let's understand the difference between Git and GitHub.

  • Melissa Wen: Walking in the KMS CURSOR CRC test

    In this post, I describe the steps involved in the execution of a kms_cursor_crc subtest. In my approach, I chose a subtest (pipe-A-cursor-alpha-transparent) as a target and examined the code from the beginning of the test (igt main) until reaching the target subtest and executing it. This is my zero version. I plan to incrementally expand this document with evaluation/description of the other subtests. I will probably also need to fix some misunderstandings.

  • Composer.js: Framework and toolset for rapidly building back-end API services using NodeJS

    AcceleratXR announced the launch of its new open source project – Composer.js. Composer.js is a framework and toolset for rapidly building back-end API services using NodeJS. The project is a fork of the internal tools and technology the company has been steadily building its innovative MMO gaming platform with over the last two years.

  • Code Gauntlet’s four-player co-op mode | Wireframe #39
  • CY's Recent Submission for PWC(061-063)
  • PyCharm: PyCharm 2020.2 Early Access Program starts now!

    The Early Access Program for our next major release, PyCharm 2020.2, is now open! If you are the kind of person who is always looking forward to the next ‘big thing’, we encourage you to join and share your thoughts on the latest PyCharm improvements! Our upcoming release is loaded with cool features!

  • ListenData: How to drop one or multiple columns from Pandas Dataframe

    In this tutorial, we will cover how to drop or remove one or multiple columns from pandas dataframe. What is pandas in Python? pandas is a python package for data manipulation. It has several functions for the following data tasks: Drop or Keep rows and columns Aggregate data by one or more columns Sort or reorder data Merge or append multiple dataframes String Functions to handle text data DateTime Functions to handle date or time format columns

  • Matt Layman: Designing A View - Building SaaS #59

    In this episode, I focused on a single view for adding a course to a school year. This view is reusing a form class from a different part of the app and sharing a template. We worked through the details of making a clear CreateView. The stream started with me answering a question about how I design a new feature. I outlined all the things that I think through for the different kinds of features that I need to build.

  • Configuring Wing Pro's Python Debugger for Your Code Base

    This Wing Tip provides a roadmap to the configuration options available for Wing's debugger, to make it easier to understand the available possibilities and how these can be applied to your development projects.