Bringing Leap and SUSE Linux Enterprise closer together - a proposal

I don’t generally follow the mailing lists, but this interesting thread caught my attention…
https://lists.opensuse.org/opensuse-project/2020-04/msg00002.html

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).

I see it as a positive step allowing openSUSE and SUSE Linux Enterprise to develop more collaboratively and reinforce each others efforts.

I note that it is mentioned here as well
https://news.opensuse.org/2020/04/10/SUSE-proposes-synchronizing-code-streams-includes-SLE-binaries-for-openSUSE-Leap/

Basically I see this as a good thing, yes. But I can also see the worries some people expressed. Not deep enough into the matter to have a well based opinion though, and I guess more details on how it all should work on a daily basis will be needed to have such an opinion.

From this distance, it looks like a good idea.

Once people sit down and start to work out the details, it might not look quite as good. There are bound to be some conflicts. There does seem to be a provision to deal with those, but there are always unexpected difficulties.

For my personal computer use, I don’t see a problem. I can always switch to Tumbleweed if things go poorly.

Hi
It really is a work flow issue, since the SLE packages need to be certified and built in a controlled environment etc. If I need anything on SLE, either build or just push to SUSE Package Hub if it’s in Tumbleweed, best of both worlds…

I was hoping you, knowing you build for SLE and openSUSE/* you could shed some light on this, re. how this could impact on openSUSE in both negative and positive ways. I can see some issues ( bugreports, changelogs etc ), but I lack the detailed knowledge to understand the full impact of it.

Hi
Bug reports are always an issue since the ones that aren’t public have customer information that is needed to fix, some can be made public, but it means another bug report is made on the openSUSE side with sanitized information. I don’t see a way around that to be honest, it is what it is… suffice to say some fixes etc make it to openSUSE before something is noticed or there is an awareness of an issue and fixes underway.

If someone really wants to know about a specific bug report, I haven’t seen an out right no, but we can share information about the bug, seems a good compromise.

Having reported a bug in Leap 15.1 which was also in SLE, it appears that the two bug reports were connected by those working on them but the bugzilla threads remained separate. That seemed to work fine in the case I know about.