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
--
Dr. Gerald Pfeifer