Portal:Jump/Policy/SubmitRequests
Jump Submit requests
TLDR version
In simple terms, if the package is not in SUSE Linux Enterprise 15 (SLE) then it will be handled in openSUSE Backports. All change requests will be initially created against openSUSE Jump project packages not in SLE will be simply processed in openSUSE Backports. Ports project is no more we now have s390x.
Intro
This process is currently effective only for openSUSE Jump but is intended to replace the submissions process for future releases of openSUSE Leap and submit request process for openSUSE Backports.
openSUSE Jump project is basically an umbrella on top of SUSE Linux Enterprise (SLE) and openSUSE Backports (Packagehub).
We no longer have the ports subproject so all architectures namely: x86_64, ppc64le, aarch64, and newly s390x will be now built the same way. The 32bit arvm7 will have to be unfortunately handled separately.
The primary goal of the openSUSE Jump project is to contain just branding packages and packages defining product structure (kiwi files, release packages, patterns, etc) and built ftp-trees and media.
So where do I submit changes?
All submit requests (SR) are submitted against openSUSE Jump project. or later openSUSE Leap 15.3 project OBS will then automatically redirect the SR to the correct place.
Exception is new Package request, where it has to be submitted against particular project (openSUSE:Backports:SLE-15-SP3, SUSE:SLE-15-SP3:GA ...) as redirect wouldn't know what's the origin.
After the project GA (release day) all maintenance change requests will have to be submitted against respective :Update project (e.g. openSUSE:Jump:15.2:Update).
What are the requirements for Submission?
Submission to Backports need to follow openSUSE:Backports_Packaging_Policy. [[openSUSE:Suse_sle_review_team]
Submit request deadlines
In order to be effective, we have to use the same deadlines (or at least equivalent) as SUSE Linux Enterprise 15. Otherwise, you might get to a situation when openSUSE Jump or future openSUSE Leap still allows submission for a given release, however, they would get rejected in SLE as they were created post-deadline.
Submit redirection
OBS is responsible for the submit request redirection to the proper project based on the package origin. This will be either openSUSE Backports or correct SUSE:SLE-X:SPY{:GA,:Update}.
Redirection to SUSE:SLE projects
All submissions against openSUSE Jump for packages under SUSE SLE will be redirected to corresponding SUSE SLE project. The structure of SLE project is different than in openSUSE Leap, Factory or Backports, so it's important to understand the difference.
All SUSE:SLE* projects in https://build.opensuse.org are read-only. All changes really have to happen in the SUSE internal instance (https://build.suse.de). For this purpose OBS team introduced a submit request mirroring.
Member of openSUSE Release team with role suse-sle-reviewers has to explicitly approve change prior it gets mirrored, more details can be seen here.
Bit of history
All packages for SLE 15 were initially released as part of SUSE:SLE-15:GA project, this is often referred to as SUSE Linux Enterprise 15 ServicePack 0.
Any changes to these packages after the release were then handled via maintenance requests in the SUSE:SLE-15:Update project.
SLE Maintenance team is trying to limit the amount of code streams that have to be supported, therefore we try to avoid forking as much as possible.
So newer Service Packs will only contain new packages that were not previously available or packages that had to be explicitly forked for this release as they introduced changes that were not backward compatible or were too risky to be released as a maintenance update
In case that package didn't really receive any major update it's very likely that the origin of the package is actually still https://build.opensuse.org/project/show/SUSE:SLE-15:Update SUSE:SLE-15:Update project]. At the end that's the best case, as all SLE code streams have the same sources.
You can check this with 'osc origin' or as shown on the picture in the corresponding SUSE:SLE project for your openSUSE Jump or Leap release.
Why is it important to understand SLE project structure
Well the code submission deadline and rules apply only for packages and changes introduced in currently developed Service Pack.
In most cases it will be in fact a maintenance update, as this is from where the most SLE packages come from. Changes to these packages might have slightly different acceptance criteria.
We can fork package if there is a good reason. But it increase maintenance cost as SUSE has to support multiple code streams.
Redirection to openSUSE Backports
Most packages (more than 8 000) that were in openSUSE Leap will be stored in openSUSE:Backports project.
You could oversimplify it and say that Backports is the new Leap. This makes sense as all Leap (non-SLE) requests had to be handled previously in Backports as well to provide updates in Package Hub, so now we build it just once.
Submission to any package which is inherited from backports will be simply redirected to the correct openSUSE Backports project (e.g. Backports for SLE-15-SP2) or respective :Update project after the final image was built.
How does the change gets propagated to openSUSE Jump?
Both openSUSE Backports and SUSE Linux Enterprise packages are inherited into openSUSE Jump. This is done via project links.
<link project="openSUSE:Backports:SLE-15-SP2:Update"/> <link project="SUSE:SLE-15-SP2:Update"/>
Both binaries and sources of SUSE Linux Enterprise 15 packages are synced into OBS via IBS -> OBS Sync which is already in place. Example of synced project. openSUSE Backports then inherit packages from relevant SLE version (15.2 : SP2) via repository definition in the project metadata.
The sync is triggered every time when a package build finishes. There are some exceptions. Blacklist for the sync can be seen here Portal:Leap:Jump/OBS/Blacklist. Any change to the list must be manually propagated by Autobuild team on the IBS side.