let me share a proposal on how could the new submission workflow for
the "Jump" could look like. Just to make sure, Jump is the openSUSE
Leap prototype build on top of SLE Binaries and Backports.
FYI: Tasks for current Jump effort are tracked here:
**Let's define 4 separate package origins:**
(1) **SUSE:SLE-15* Code stream in OBS**
* Synced 1:1 from IBS with few packages skipped, 00products,
000release-packages, packages related to infrastructure, live patching,
... less than 50)
*Roughly 4000 packages
* Additional packages for Leap and SLE via https://packagehub.suse.com/
. Available by default to Leap user, SLE user has to enable Package
* Roughly 8000 packages
(3) **openSUSE Leap forks of SLE packages**
* Packages with additional functionality that didn't make it to SLES.
This should be a very small group of packages (<130).
* Less than 130 packages
(4) **openSUSE Leap distribution and branding**
* Packages defining content of openSUSE Leap artifacts (000products,
release packages, kiwi descriptions) and *-branding packages
* Less than 50 packages
So here are my thoughts ...
Updating the base system
There is currently no well-defined process for updating (1) aside from
the Factory First rule. Not many SLE packages are in sync with the
version from Factory, so that rule just by itself is not sufficient.
This is 1/3 of the openSUSE Leap distribution. Changes are usually
handled via bugs in openSUSE product.
Release Manager transforms Submit Requests or Bugs during review into
SUSE Linux Enterprise feature requests.
I usually try to handle this while Bugzilla triage, which is setting
priority to bugs with priority set to P5 (None).
A feature gets approved, or bug gets resolved. Change is implemented in
IBS, synced to OBS, Jump gets the new build.
This takes quite some time. And lowers the turnover rate of Rel-eng.
I did a small research and contacted all Bugzilla component owners in
Most of the feedback was that it is the team's best effort to triage
Bugzilla should be used only for bugs, not a feature request, which is
currently the case.
This is a candidate for a brand new process that should be available to
all active openSUSE Leap contributors.
I can imagine a similar process to an existing SUSE partner feature
request process in jira.suse.com
I did already create a request for our Jira team. At this point, it's
still unclear where and how will be the request tracked.
We'd like to have this implemented by Q3/2020.
Updating openSUSE Leap package which is not in SLE
Changes to (2) would be the same as today, in case that "Jump" is just
a parallel build. This means submission to openSUSE Leap 15.2.
From a Jump "as the only Leap" perspective. Submit Request is newly
created against the openSUSE Backports project in OBS.
openSUSE Backports don't have a Staging process to my knowledge, this
needs improvement. Integration testing is necessary.
Otherwise, I like this, since here it reduces work. One less SR and one
less build mean less waiting to get the change in. The workaround to
resolve blocking issues similar to SLE Workarounds would be still
available if we need it. Submit to openSUSE Backports was happening
anyway, to provide software to SLED/SLES.
We can now even distribute the very same binary for SLE and Leap.
Changing the distribution
This would be the case for any package in (4). A direct Submit Request
against the existing package in "Jump". Usually done by a member from
the openSUSE Rel-eng team.
Moving apart SLE and openSUSE Leap
Commits to (3) should be subject to extensive review. We should always
try to approach it in the same way as a Feature request in (1).
Try to get SLE buy-in and extend fork only if necessary. Generally, the
attempt here is to reduce this group and therefore have equal
functionality in SLE and Leap if possible.
What do you think?
Release Manager openSUSE Leap
SUSE Software Solutions Germany GmbH
(HRB 36809, AG Nürnberg)
Managing Director: Felix Imendörffer