I do have some exciting news to share!
TLDR: openSUSE Jump builds will be now publicly available,
access for contributors in 5 weeks, OBS submissions
against SLE packages will be submitted against Jump and mirrored in
IBS. Any updates on request will be then synced outside (bi-directional
sync). Proposed workflow received thumbs up from Maintenance and SLE
First, I'd like to announce that we'll start publishing images and FTP
trees for openSUSE Jump*, so people can get their hands on. Please be
aware that Jump is still in Alpha quality. I expect data to be
available later this week as there is still pending work on pontifex by
Second, I've agreed on ETA of 5 weeks for the initial availability of
JIRA partner access to openSUSE Contributors (JIRA-722). In this way,
we can have transparent handling of feature requests, just like for any
other SUSE partner. I hope that this brings some more transparency and
self-service for SLE -> openSUSE feature requests. TAM for openSUSE
(Lubos) will be in charge of controlling the access.
We'll initially have rather a smaller pool of users (initially 10) and
will grow it over time based on the popularity. Just FYI: The standard
size of the pool for partners is 2, so openSUSE is being taken
seriously as a partner here.
Second, the proposal of the new submission model for the openSUSE Jump
and it's SUSE Linux Enterprise part was accepted well by the
Maintenance team and SLE Release management, therefore **I'd like to
hear your opinion**. My hard requirement is that we will NOT reject
submissions just because it's a submission against an SLE package.
My attept to capture is here
(also available in drawio and png).
Log story short, an openSUSE contributor would always submit code
against a single project. Let's say openSUSE:Jump:15.2 for now (later
Code submission would then get redirected to a proper origin
(Backports, Leap, SLE). The tool for SR redirection is already in place
openSUSE Backports (for the majority of Leap packages ~8k),
openSUSE Leap (mostly branding packages, patterns, and SLE package
forks of packages necessary to keep openSUSE Leap building ~100)
SUSE Linux Enterprise (~4k packages, the core)
Backports and openSUSE Leap code submissions will have pretty much the
same experience as now. With the exception that you'll be able to use
just one submit request target for more convenience and reusability as
there will be one build used for both Package Hub and Leap.
Submissions to SUSE Linux Enterprise will get more transparent.
I'd really like to ask you to look at it as a good starting point.
I see it as a big improvement from what we have now since you'll be now
able to see behind the scenes. This all is constantly happening, you
were just not able to see it before.
This would be more or less a regular way to update an SLE package.
0) The contributor reports a bug or logs in to jira.suse.com
a partner feature request for new features.
JIRA request can still be created by TAM (Lubos) if there would be any
problem (e.g. missing access etc). User (and other openSUSE
contributors who requested JIRA access) see updates in JIRA.
1) TAM reviews feature and reject with reasoning or gives it a go and
passes it for further evaluation.
1) The contributor submits code against openSUSE:Jump:15.2 (later
Leap), optionally references openSUSE Partner JIRA feature (see my note
on JIRA access) or a bug
2) openSUSE Release team reviews a new type of review let's refer to it
as an "openSUSE Jump" review for now.
3) Approved submissions will get mirrored (OBS-63) from OBS to IBS
(Internal SUSE OBS instance) with bi-directional sync on comments,
updates for full transparency so the contributor can see progress on
the submission by himself.
4) Submission gets processed by SLE Release Management or Maintenance
team based on the origin (see my note below).
At this point, it's either rejected or passed on staging for pre-
Reject reasons might be not following (not a full list)
Failed code review such as skipping Factory First, mandatory 4 eyes
Change is past the code-submission deadline
Missing approval on a feature, ECO or a missing issue reference
Does not meet usual maintenance update criteria such as backward-
incompatible update or would require a rebuild of a lot of packages
Failed pre-integration testing.
The reject reason would be communicated in the submission.
Generally, the submission criteria would be the same as any SUSE
5) openSUSE TAM (Lubos) optionally creates an ECO* to get approvals for
feature requests in a late development phase or Maintenance updates.
6) Mirrored SR in IBS and Original SR (via bi-directional sync) gets
accepted (or rejected).
7) The partner feature request is marked as Done or bug is marked as
Just one note on SLE Submit requests, which I believe will be a source
of many conflicts.
Submissions to SUSE Linux Enterprise* are a bit more tricky due to the
project inheritance, as packages are coming from older SLE Service
Packs, respective its ":Update" projects.
That means that it won't be uncommon that the user will be submitting
code against for an example openSUSE Leap 15.3 during the Early Alpha
phase, however, in the end, it's going to be a submission for SUSE:SLE-
15-SP1:Update. Such submission may require additional ECO* approval or
will result in a fork in the latest Service Pack of SLE. So I recommend
all users to use "osc origin" to check where does the package come
from, to avoid any surprises later on.
And the last I'll check our wiki pages and make sure that the content
is in alignment with the presented idea.
So what do you think?
 openSUSE Jump https://en.opensuse.org/Portal:Leap:Jump
 ECO - https://en.opensuse.org/ECO
 The submit request will be mirrored in OBS under a different ID
etc. but the state of original submission will be Accepted.
 IBS - SUSE Internal OBS instance, that is used to build SUSE Linux
Thank you for your time