I’ve been reading on the mailing lists about Leap 15.3 and linking it up to SLE. I thought I had a clear idea of this but I don’t so could someone like the title says please explain this to me?
Hi
Have you had a read here? Portal:Jump - openSUSE Wiki
Also follow the Project Mailing List archive (or subscribe): eg [opensuse-project] An update on the Jump and Leap 15.3 - openSUSE Project - openSUSE Mailing Lists
Perhaps some specific items you not clear on?
So starting with leap 15.3 a hefty portion of it will be SLE packages those parts of packages that for licensing reasons can’t be in SLE will be in the openSUSE Community version (that’s us) along with those SLE packages.
Those of us in the community here can make some changes to the code through like OBS or bugzilla and have it seriously considered by SUSE the company. If it works you’ve contributed to both the company and the community. If it works for just you then it works for just you or something’s wrong, thus not included in anything beyond one’s personal set up.
Finally this will make it so that someone using openSUSE and then say starts a business. trains the staff on openSUSE then the business expands far enough that individual will then very likely need/buy the SLE version. with a very seamless transition to both that person and the staff.
This is how I understood the entire thing and from what I read this is how I still understand it do I got it right?
Teams of Leap and SLE did the same work in a different manner. With everybody streamlining their development and maintenance this became a big disadvantage over competitors. They are trying to improve.
Hi
What user karlmistelberger said 
De-duplicate the work…
Well if I really want something in SLE available as an end user, it’s not that bad, just get the package into Tumbleweed and then it can be subbed to Backports and Package Hub for SLE users (this can be done by a user if the Maintainer is happy to have in Backports). If it’s in SUSE Package Hub, then your system (SLE Packages) will still be supported…
The move to SLE if your not a GNOME user could be time consuming 
but a Plasma version is available via Package Hub, so not all is lost…
As far as I know, KDE is not in SLE simply because they chose to go with Gnome. So there are reasons other than licensing.
My understanding is that from the start of Leap, part has come from SLE and part is separate (loosely derived from Tumbleweed, but then SLE is also loosely derived from Tumbleweed).
Up through Leap 15.2, the SLE sources have been used and recompiled for Leap. The plan with 15.3 is to directly use SLE packages without the recompiling.
so then this might end up being something like Ubuntu has where the backend stuff code and such is the same whether it’s the business version or the personal version and that which is not in SLE will be like Ubuntu’s PPA’s?
I’m not saying this is a bad thing it’s not it works really well for Ubuntu if that’s what’s going on then I understand that. IMO it’d work great for openSUSE.
I don’t know enough about Ubuntu organization to comment on that part.
Yes, I think this can work well. But there might be a few bumps in the road as they try to get it all worked out.
Back when i was using Ubuntu there were 2 versions. One was the latest animal for masses the other was the enterprise versions. It’d be based on some animal version deemed an LTS and supported for a longer time. I’ve not used Ubuntu for loooong time so the lifetime length is no longer recalled. The enterprise version was sold to businesses as a service Canonial wuold the support this LTS for the lifetime of the LTS. When I was there it was not unusual for a core product to be in the animal and the LTS simultaneously and sometimes a modification from a user to the animal would make its way to the LTS also. This didn’t happen very often but it did happen despite what some may say.
Now some could at their option run the animal then later buy the LTS enterprise version.
From what I understand Suse the corporation is sort of like this selling what it calls SLE. At one time SLE and openSUSE were not quite attached but this jump is supposed to make SLE and leap close to one in the same like the versions of Ubuntu.
Meanwhile back to the semi annual animal there would of course be the core packages drivers and the kernel. Not all of the things that one would use in Linux would be in the core. This was handled by a thing called the PPAs this would have extra packages in it like when I was there they had one called Miro. That wasn’t in any of the Ubuntu repos at the time. Also I believe the codecs at the time were from a PPA. An openSUSE user would likely use OBS or Packman. Even now as I understand it in Ubuntu it is through the use of a PPA that you get KDE Neon. A lot of new different or untried stuff is in those PPAs much like our own OBS.
It’s in the semi-annual animal that various new items to the core get introduced these cores are then used by the masses and tested by them. Then these applications from the animals after being tested by the users makes its way into the next LTS.
It was not unusual for the devs of Ubuntu to be in the forums there. As I understand it this is not a practice of the devs for openSUSE. One of the points I’m not clear on is that with the merger of SLE and openSUSE does that mean the devs will finally make some trips into here and find out that we’re not just a bunch of potted plants!
So in essence does this mean that jump and the merger 15.3 and SLE will be kind of like the way I described Ubuntu above?
From a purely outside, non-contributing observer…
Starts with “Pre-LEAP” when publicly licensed openSUSE was a clearly separate product from the “paid for” SLES/SLED products.
In those days, Tumbleweed was the factory where new contributions were tested and a clear flow existed from Tumbleweed to openSUSE. If SLES imported anything, that was entirely a separate decision.
Starting with LEAP, it was announced the flow would change.
Instead of a completely separate product, openSUSE and SLES/SLED would share core components and the set of shared components would be indicated by the new naming scheme (well, after the 42.x series which was based on someone’s whim).
But, that raised questions and issues that exist to to this day, including the role of Tumbleweed.
New contributions have generally appeared in Tumbleweed, but Tumbleweed supposedly still retains its independent architecture and is not that similar to SLES and LEAP, so Tumbleweed acquired its own new identity as a standard rolling release.
This new package adoption flow has more or less been made possible through OpenQA, which is automated testing lessening the need for Tumbleweed to test packages prior to widespread distribution.
To this day, LEAP is still undergoing changes that incorporate integration with SLES.
It’s still a bit of a muddle with no clear flow how contributions move from one OS project to another, but someone, somewhere may have this clearly mapped out.
SLES has numerous tools and procedures which are different than how things are done in openSUSE, and I haven’t looked closely at whether SLES tools retain their completely independent code or if they’ve been refactored to truly re-use functionality in LEAP.
But note that this only applies to the operating system and not subsystems like the Desktop (Gnome, KDE, etc). No matter what flavor of openSUSE you are running, you can run the default that is chosen for you or you can add a repository and run the bleeding edge latest from those projects… So, for instance you can install a “very stable” LEAP with a “very unstable” KDE Plasma with your choice of Qt Framework, for example. The zypper resolver somehow makes whatever your cauldron’s brew work.
Anyway,
That’s an outsider’s perspective of someone who doesn’t participate in the changes… Which may not even be accurate since it’s based only on observation…
TSU