Starting with openSUSE Leap 42.2, a lot of cooperation has been done to bridge gaps between openSUSE and SUSE Linux Enterprise distributions. Things have been improving nicely with openSUSE Leap 42.3.
We'll go into details on what this cooperation means for both openSUSE contributors and for SUSE and how we ensure it takes place. We will also discuss how we adjusted SLE15 development and how was done in harmony with openSUSE Tumbleweed (rolling release).
Diamond Application Development Crafting Solutions with Precision
Developing Enterprise and Community distributions at the same time, impossible ?
1. Developing Enterprise andDeveloping Enterprise and
Community distributions at theCommunity distributions at the
same time, impossible ?same time, impossible ?
openSUSE / SUSE example: Tumbleweed / Leap and SLEopenSUSE / SUSE example: Tumbleweed / Leap and SLE
Frédéric Crozat <fcrozat@suse.com>
SUSE Linux Enterprise Release Manager
2. openSUSE/SUSE terminology
●
SLE = SUSE Linux Enterprise (Server / Desktop)
– Enterprise distribution, developed by SUSE
●
openSUSE Factory:
– Development repository
●
Tumbleweed:
– openSUSE Rolling release, by openSUSE, using only Factory as
basis, tested by openQA
●
Leap:
– openSUSE Stable release, based on SLE common code +
Packages from Factory (or specific repository)
2
3. openSUSE & SUSE Linux Enterprise
Developed together - Reminder
openSUSE Tumbleweed
Leap
42.2
SLE
12 SP2
Shared Core
12.2
Leap
42.3
SLE
12 SP3
Shared Core
12.3
Leap
15
SLE
15
Shared Core
15
Packages list with their origin:
https://build.opensuse.org/package/view_file/openSUSE:Leap:15.0/00Meta/lookup.yml
5. Mistakes were made (a few examples)
●
In SLE12 (SP0), we forked GNOME 3.10.3..
●
Even worse, we didn’t backport our features to
openSUSE:Factory !
●
We were saying “we’ll do that later...”
●
For SLE12 SP1, people were too busy bug fixing
●
“We’ll do that later...”
5
6. We started to fix those mistake
●
Goal was to sync back SLE 12 GNOME with openSUSE one
●
Could we share the same SRPM between SLE 12 SP2 and
Leap 42.2 ?
6
7. We did it !
●
More than 300 packages to sync
●
A lot of discussion and interaction between SUSE desktop
teams and openSUSE GNOME team
●
Tooling was essential, to get overview of divergeance
between SLE and openSUSE packages
●
Very few patches were enabled only on SLE 12 SP2
●
Sometime, in later bug reports, we discovered Leap 42.2 was
suffering from bugs not present in SP2, because of the above.
7
8. Main points
●
Work was done first internally and then pushed to openSUSE
●
Changelog integration
– Packages between SP should never loose FATE / CVE /
BSC
– openSUSE was very helpful in accepting some older
changelog entries to preserve this
●
Update handling for bug reported on Leap for packages
inherited from SLE
8
9. Scenes from current episode inScenes from current episode in
production (aka SLE15 / Leap 15)production (aka SLE15 / Leap 15)
9
10. Submitting to SLE/Factory
Submit
Request
Target:
Distro
Developer creates a
Submit Request
Distro:Staging:Foobar
SR is moved to a specific staging for testing
Mini-ISO is generated
Check-in team and various
bot
review SR
Everything is fine
(openQA is green and
review was ok)
SR committed to
Distro
ISO are
generated for all arch
OpenQA runs
full testsuite
openQA runs a
small testsuite
11. Factory first policy (for SLE)
●
New guidelines in effect for development since SLE12 SP3 and now for SLE15
●
Whenever possible, development should be done on OBS
(openSUSE:Factory) and pushed back to SLE15
●
When submission is reviewed and accepted on Factory, it is automatically
submitted to SLE15 (unless packages was branched in SLE15). This was in
place for most of the development period.
●
When a submission is sent to SLE15, a automated check will ensure similar
submission was done to openSUSE:Factory
●
Based on this knowledge, SLE Release Managers decide what to do with
those submit requests
●
You could see SLE15 development “live” since we were in Beta phase
11
13. Factory first policy enforcement / bot reviews
●
Legal bot (license OK)
●
Maintenance bot (does the package build in the developer project)
●
Changelog checker bot (each SLE submission must have a bug or feature
number in its changelog)
●
Leaper bot (check if the package is supposed to be following Factory or is
allowed to fork):
– If the package is inherited from Factory, ensure the same changes are
already in Factory or waiting to be approved by Factory maintainer. If it is
not the case, submission is automatically REJECTED
– If package is allowed to branch, still check if identical changes have been
pushed to Factory and give the results as a comment to the submission
(will not auto-reject)
13
14. Lessons learned
●
Using automation as much as possible:
– People are less emotional if they get an rejection by a
automated tool which is enforcing a policy than a human
– If the rejection can be informative, it is better
– Have a way to override the tool, if needed
– Empower your contributors, ensure they don’t have to do
work several times
14