openSUSE:Maintenance/Technical Documentation

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.

incomplete submissions

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

update handling

Architectures

For packages that do not build for the i586 architecture, disable building for it. Except if the package contains a baselibs.conf.

Ports maintenance

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:

 openSUSE:Leap:42.3:Update/00Meta lookup.yml

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 GA and 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 -M of 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

Special updates

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 branch/mbranch from Update and submit to get the approval from the openSUSE package maintainer. Use stopped flags to note the work in progress, and setincident on 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.

Error conditions

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.