If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
- 1 Glossary
- 2 Validation of the change before the implementation
- 2.1 Changes to packages directly in the openSUSE:Jump:15.2 project
- 2.2 Changes to packages inherited from openSUSE Backports
- 2.3 Changes to packages inherited from SLE
- 3 Validation of the change after the implementation
- Implementation - the act of merging code change into a product, in this case openSUSE Jump 15.2.1
- Change request - a Submit request made in an instance of the Open Build Service. Either https://build.opensuse.org or https://build.suse.de.
- Package - Entity represented by a .spec file, not individual binary rpms.
- SLE - SUSE Linux Enterprise
- Backprorts - Corresponding OBS project for https://packagehub.suse.com/
- openSUSE Review team
- SUSE SLE review team
- openSUSE Release team
- openSUSE Backport review team
- Package Hub team
- License digger
- Staging bot
Validation of the change before the implementation
Changes submitted against openSUSE:Jump:15.2 are in most cases subject to a submit request redirection. Let's have a look at every redirection target and scope of reviews that happens prior the change implementation.
Changes to packages directly in the openSUSE:Jump:15.2 project
The Amount of packages located in the openSUSE:Jump:15.2 project is roughly 80 packages it is mainly branding and image build related packages and packages that overlap with SUSE Linux Enterprise (SLE), however we need fork them to preserve specific functionality (e.g. gdb for the fpc integration). All change requests are subject to the Factory development model and related Factory review by openSUSE Review team. The only exception is a change to packages containing product building metadata.
Changes to packages inherited from openSUSE Backports
The Amount of packages inherited from openSUSE Backports is roughly 8000. openSUSE Backport review team is responsible for review of request before implementation.
Changes to packages inherited from SLE
The Amount of packages inherited from SUSE Linux Enterprise 15 or other products from SLE family is roughly 4000.
These 4000 mostly packages from the DVD install media with exception of some desktop environments or packages directly forked in openSUSE Jump (see the first target).
See Portal:Jump/Policy/SubmitRequests#How_does_the_change_gets_propagated_to_openSUSE_Jump.3F how do changes to SLE get propagated to Jump.
An extra review for SLE changes initiated by community
All changes from SLE come from either a SUSE maintenance request or a submit request from a currently developed Service Pack which typically corresponds with a version of openSUSE Jump.
Changes inherited from the currently developed Service Pack
All of these request coming from SUSE:SLE-X:Y:GA (e.g. 15-SP2:GA) have to pass through a similar review as openSUSE Jump X.Y submissions (See Section 2.1), but with a difference that submission is evaluated by SLE Release Manager.
Changes inherited from SUSE Maintenance requests
Unlike in openSUSE Leap, SUSE:SLE-X:Y:GA project layout inherits packages from previous Service Packs unless there was a reason to fork the package. E.g. because of a backwards incompatible changes or a significant version update. openSUSE Jump inherits packages from SUSE:SLE-X:Y:GA
Similarly to openSUSE Maintenance team review all maintenance updates for SUSE Linux enterprise have to pass certain reviews and tests by SLE Maintenance team and SLE QA Maintenance (QAM). We believe that testing done by SLE Maintenance team and QAM are sufficient for openSUSE Jump, and therefore do not require any additional per-implementation testing on openSUSE side.
Validation of the change after the implementation
Each openSUSE Jump build have to pass set of defined tests in openQA or it's not released at all. Fails can be either hard or soft fails. Soft fails are not blocking release of the build, while hard fails are and would have to be explicitly waived by member of [[openSUSE:Release_team|openSUSE Release team]to proceed. The waiver is done in a form of a comment with an agreed syntax and should also reference boo# bug or poo# ticket triggering the failure. Waivers should not be done for issues breaking requirements for given project milestone (Alpha, Beta, RC, GM).