Distribution build / delivery Distribution build / delivery styles, - - PowerPoint PPT Presentation

Distribution build / delivery Distribution build / delivery styles, one style to rule them styles, one style to rule them all ? all ?

Is rolling release the answer for everything ? Is rolling release the answer for everything ? Or Service Pack ? SUSE and openSUSE experience Or Service Pack ? SUSE and openSUSE experience

Frédéric Crozat <fcrozat@suse.com> SUSE Linux Enterprise Release Manager

What we don’t do

What we do

Distribution delivery styles Distribution delivery styles

4

Three distributions styles

• Rolling:

–

Bleeding edge

–

Release as soon as possible

–

Example: openSUSE Tumbleweed, ArchLinux, Gentoo

• Regular:

–

Release one to twice a year

–

Update their entire stack for each release

–

Example: Ubuntu, Fedora, Debian

• LTS / Enterprise:

–

Slow cadence (yearly or even less than that)

–

Very few things move between sub-releases

–

Example: openSUSE Leap, Ubuntu LTS, SLES/SLED, RHEL

5

Can a geeko adapt to everything ?

• penSUSE/SUSE terminology
• SLE = SUSE Linux Enterprise (Server / Desktop)

–

Enterprise distribution, developed by SUSE

• penSUSE Factory:

–

Development repository

• penSUSE Tumbleweed:

–

• penSUSE Rolling release, by openSUSE, using only Factory

packages, tested by openQA

• penSUSE Leap:

–

• penSUSE Stable release, based on SLE common code +

Packages from Factory (or specific repository)

7

Integration process Integration process

8

Submitting to SLE or 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

• penQA runs a

small testsuite

Factory first policy (for SLE)

• New guidelines in effect for development since SLE12 SP3
• Whenever possible, development should be done on OBS

(openSUSE:Factory) and pushed back to SLE15-SP1

• 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 can see SLE15(SP1) development “live” since we are in Beta phase

10

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, ensure patch are mentioned in 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)

11

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

12

Right tooling allows everything Right tooling allows everything

13

• penSUSE Tumbleweed
• Everything is rolling all the time
• Many stagings in parallel (14 for core packages + up to 150 for leaf

packages)

• For instance, new gcc / python / perl will take some time before being

accepted, but won’t slow other changes

• Average “quiet” (busy) week:
• 3 (5) distribution releases
• 150 (300) packages updated
• 20 (50) packages added / 20 (50) removed to DVD
• 1 (2) kernels updates

14

SUSE Linux Enterprise 15 (currently SP1)

• Initially a subset of Tumbleweed packages
• Service Pack 1 is being developed (visible on OBS)
• About 3300 source packages are inherited from SLE15 (SP0)
• Corresponding binaries RPMs are re-used (or their maintenance

updates)

• Only 900 sources packages branched in SP1 (30%) and rebuilt
• SP1 = SP0 RPM + SP1 branches RPM
• Yearly cadence

15

• penSUSE & SUSE Linux Enterprise

Developed together - Reminder

• penSUSE Tumbleweed

Leap 15.0 SLE 15

Shared Core 15.0

Leap 15.1 SLE 15 SP1

Shared Core 151

Packages list with their origin: https://build.opensuse.org/package/view_file/openSUSE:Leap:15.0/00Meta/lookup.yml

• penSUSE Leap 15.x
• Use SLE 15 packages as a base

–

Leap 15.0 <=> SLE15 SP0

–

Leap 15.1 <=> SLE15 SP1

• Add Tumbleweed packages when not available on SLE15
• Unlike SLE15 SP1, openSUSE Leap 15.1 is fully rebuild for

each release

17

• penSUSE Leap 15.x packages origin

18

Leap 15.0 Leap 15.1 2000 4000 6000 8000 10000 12000 14000 Devel SLE 15 SP1 SLE 15 SP0 Leap 15.0 Tumbleweed

• penSUSE Leap 15.x packages origin
• Leap 15.0

–

12000 “source” packages

–

2940 inherit from SLE15 (~30%)

–

8600 from Tumbleweed

–

A few from Devel projects (KDE 5 LTS)

• Leap 15.1

–

12700 “source” packages

–

8142 from Leap 15.0

–

600 from SLE15 SP1

–

2400 from SLE15 SP0

–

1200 from Tumbleweed

19

Summary

Thanks to OpenBuildService, openQA and our processes, we can deliver any distributions style we want Questions ?

20