The document discusses the challenges faced by SUSE developers in integrating GNOME into SUSE Linux Enterprise (SLE) releases, specifically between SLE 12 SP0 and SP2. It outlines the goals to merge SLE with openSUSE and address prior technical debt while upgrading the desktop stack to newer GNOME versions. Ultimately, the aim is to establish a unified source RPM for GNOME across SLE 12 SP2 and openSUSE Leap 42.2 to reduce maintenance efforts.

1. Bridging openSUSE and SLE gap
The GNOME example

2. The problem
2

3. The past 1/2
●
For SLE12 (SP0), we used openSUSE:Factory as a basis,
after 13.1 was released, which included GNOME 3.10.3
●
Based on this, SLE desktop engineers worked on fixing bugs
from customers, backporting features which were present in
SLE11 and make sure user experience was acceptable for
enterprise customers
●
For instance, SLE Classic was written, as a modified version
of GNOME Classic, but with just one panel at bottom of
screen, similar to GNOME SLAB on SLE11
3

4. The past 2/2
●
Even when using openSUSE 13.1/Factory as a basis, getting
GNOME 3.10 usable for enterprise customers was a huge
task
●
Our SUSE developers didn't always had time to submit they
changes to GNOME:Factory which had already switched to
3.12.x when we were hardening 3.10.x.
●
OpenQA was not yet used when SLE12 SP0 was developed
●
In the end, we focused on getting SLE 12 SP0 released and
decided on merging our SLE only changes after SP0 was
released
4

5. So what was the problem ?
●
Once SLE12 SP0 was released, people still had to cope with
their regular tasks, such as L3 bug fixing (for SLE11 and
newly released SP0), working on SLE11 SP4, etc..
●
For SLE12 SP1, which was a stabilization service pack (no
version upgrade on the desktop), all our engineering
resources were focused on developing features and fixing
bugs on the existing (GNOME 3.10.x) codebase
5

6. Bridging the gap
6

7. SLE 12 SP2 goals
●
From the beginning, our goal was to merge again with
openSUSE and reimburse our “technical debt”
●
After SLE12 SP0 was released, a new project openSUSE
project was launched: openSUSE Leap. Maybe we (SUSE
Desktop teams) could work in cooperation with openSUSE
GNOME team ?
●
SLE12 SP2 plan was to upgrade our desktop stack, to
GNOME 3.18 or 3.20 (was still undecided in early stage)
●
Early talks with openSUSE GNOME team regarding our plans
and their plan for next Leap release: could we use same
SRPM ? 7

8. Which GNOME release to pick for SP2 ?
●
3.18 :
– Pro: It was already in Tumbleweed
– Con: It would be already replaced by another major release in TW by
the time we would be in SP2 Beta cycle
– Con: Any fixes we might do might not be accepted upstream because
code would be already changed
●
3.20:
– Pro: Potentially the same version for next Leap (42.2)
– Pro: Still in development upstream: fixes could be merged upstream as
they are submitted there.
– Con: a bit tight with SP2 beta schedule
8

9. Battle plan 1/2
●
Getting GNOME:Next built on SLE12
– Thanks to OBS, it was quite easy to setup a mirror of
GNOME:Next project (containing GNOME 3.19.x), built on
top of SLE12 SP1
– We fixed all build failures and dependencies in
GNOME:Next (no code change was done in SLE12 at that
time)
●
With the result, it was possible to install GNOME 3.19.x
(similar to openSUSE TW version) on top of SLE 12 SP1 and
confirm it was OK to use it for SP2.
9

10. Battle plan 2/2
●
Setup a devel project internally
– In the past, SLE desktop packages were not using a devel
project (similar to GNOME:Factory)
– We created such project, with our developers reviewing
other developers' submissions
●
Sharing the workload among developers: about 300 packages
to update
10

11. “Updating” packages
●
What do we mean by this:
– For each of those 300 packages, merge of:
●
SLE 12 codebase (ie 3.10.x + feature development +
all bug fixes until now)
●
GNOME 3.19.x/3.20.x codebase (ie all the changes
from openSUSE Tumbleweed (3.20.x)
– When possible, push patches / feature development to
upstream (GNOME)
11

12. Success ?
●
For SLE12 SP2 Beta1, we were able to get GNOME 3.20.1
integrated
●
However, again, due to time constraint, we weren't able to get all
our changes back to openSUSE GNOME:Factory by Beta1
deadline
●
Discussion is now really happening between SUSE developers
and openSUSE GNOME team !!
●
Why didn't you succeed ?
– Have you ever tried to submit a .changes with a trailing space
to GNOME:Factory ? ;)
– More seriously, learning GNOME:Factory guidelines takes time 12

13. Next steps
13

14. Merging back SLE12 SP2 changes to Factory
●
With SLE12 SP2 being in beta, codebase is now available on
OBS
●
This has allowed openSUSE GNOME team to look at the SP2
changes before SP2 is released, comment on them, integrate
some of them and help us sort work to be done
●
We are now tracking internally the “divergence” between SLE12
SP2 and GNOME:Factory and are working with our developers
so they submit changes to GNOME:Factory:
– For SLE only changes, code will be in G:F but not built
– For relevant changes, patch will be applied for G:F
14

15. Ultimate goal
●
We want to the same source RPM packages for GNOME in
both :
– SLE 12 SP2
– openSUSE Leap 42.2
●
This will lower openSUSE GNOME team maintenance work
for Leap 42.2, if packages origin is SP2.
●
Right now, 54 packages remaining (yes, it includes SLE
Classic ;) !
15

16. Stretch goal
●
Getting more packages available for SLE12 users
●
This is openSUSE:Backport project
●
Check Scott Bahling talk on Friday, 14:30
●
It even contains KDE5 for SLE12 SP1 now !
16

17. Questions / Reactions ?
17