- 1 general submission handling
- 2 update handling
- 3 SLE imported updates
general submission handling
In general, apply the openSUSE:Maintenance_policy but help and support community users as much as possible.
direct submissions from devel projects
All submissions for single packages that come directly from a devel package must be checked for build-time dependencies that may have changed:
osc build --alternative-project openSUSE:Leap:42.3:Update standard
submissions for multiple packages
Multiple submissions that need to go together should be requested to be done from a composite maintenance project containing only these packages. If the maintainer struggles with that, you may copy the previously submitted sources and submit yourself.
If we maintain multiple stable releases and the maintainer did not do a complete submission, ask for it to be completed. Do not reject but ask for a complete submission. If the sources are identical, you may submit or copy the update yourself rather than doing a full new turn-around.
known broken submissions
Submissions known to be frequently broken for Leap 42.3:
- Python 3 singlespec conversions
- multibuild (usually broken, or at least risky)
direct submissions for SLE inherited updates
- In general, ask for the issue to be reported to SLE and submitted to SLE maintenance
- As an exception, fork the package if the maintainer agrees
- For packages that do not build for the
i586architecture, disable building for it. Except if the package contains a
- Ports maintenance to be done on a best effort basis only.
- For any build failures in Ports, disable building of this package only for this architecture only for the ports repo.
- If ALL ports build fail, remove the Ports target from the Project meta.
- SLE imported updates that fix ports issues only may be stopped until the next update
SLE imported updates
openSUSE Leap inherits some packages from SLE, and thus benefits from SLE release engineering and maintenance QA. This relationship is at source level only, there is no binary import or guaranteed binary compatibility.
tracking SLE inherited packages
SLE inherited packages are tracked as follows:
For each stable Leap release, the Maintenance team maintains a meta file. It is copied from the initial release repository when maintenance starts. Location:
For each package, it will specify if (currently) the package is inherited from SLE, or not. If it is inherited from SLE, the location will be given as follows:
pkg1: SUSE:SLE-12:GA pkg2: SUSE:SLE-12:Update pkg3: SUSE:SLE-12-SP3:GA
The difference between
Update is ignored by scripts, and only denotes the original location.
adjusting tracking data
If required, Leap packages can be switched to inherit SLE maintenance updates going forward. Also the other way around, if Leap wants a different packages. The decision is taken by openSUSE Maintenance team based on user requirements.
Check out the
00Meta package from the update project and edit directly. Specify the reason for the change, e.g. update, bug reference.
SLE sources in OBS
Almost the entirely of the
SUSE:SLE-12* tree is exported as sources into the OBS. All importing for updates into Leap maintenance must be done from there.
Importing updates from SLE
A script runs inside the SUSE MaintSec infrastructure. It loops through the metadata and performs the following for all SLE inherited packages:
- Check if there is a source diff between the Leap package and the SLE package
- If so, look if there is a pending Leap maintenance update that matches the SLE package
- If not:
- open a new incident in openSUSE:Maintenance
- do a
branch -Mof the Leap update package into the incident
- do a copypac of the latest SLE sources into the incident
- copy the SLE patchinfo into the incident
- mark the SLE patchinfo with a stopped flag: Review SLE patchinfo text
SLE-to-leap importer script owners: Marcus, Andreas.
Standard processing SLE imported updates by openSUSE Maintenance team
- Review ALL source package diffs to make sure the diff is sane, and not a revert.
- Review the SLE patchinfo text. If required, remove SLE specific instructions and change it so it applies to Leap
- Finally Remove the stopped flag and process the update as normally
- SLE imported updates may be released as soon as all other reviews are passed
When processing SLE imported updates, openSUSE maintenance team may add missing packages and remove undesired packages (e.g. Leap has a newer package). It may resolve build or binary issues and split/combine incidents.
The update may pass SLE maintenance checkers, OpenQA and manual QA, but fail in Leap OpenQA or simply not work on Leap. openSUSE Maintenance team must delay release of the update and investigate solutions. And openSUSE Leap specific code changes done with the approval of the maintainers are to be fed back into SLE maintenance, so as to become part of the next SLE maintenance update. Meanwhile the modified Leap maintenance incident may progress and thus temporarily divers from the SLE sources, to be later synchronized again.
Adjusting the incident
- In the general case, do a
Updateand submit to get the approval from the openSUSE package maintainer. Use stopped flags to note the work in progress, and
setincidenton the request to denote the target incident of the request.
- for copying a new package from SLE, using the following procedure is accepted as an alternative of a submissions:
osc branch -M openSUSE:Leap:42.3:Update/newpackage openSUSE:Maintenance:$INCIDENT && osc copypac -e -K SUSE:SLE-12:Update/newpackage openSUSE:Maintenance:$INCIDENT/newpackage.openSUSE_Leap_42.3_Update.
- The importer script will import the complete SLE incident upon the first diff encountered, including other packages in the incident that are in the incident but which may not be a SLE inherited package. Decide which sources you want to take, if in doubt switch to SLE maintenance if newer.
- The importer script bails on SLE incidents which add a new package that did not previously exist in leap.
- The importer script errors out on user IDs noted in the patchinfo that differ between IBS and OBS. It has a hardcoded list of replacements.