Portal:Jump/Policy/ChangeValidation
ROUGH CUTS
Glossary
- 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/
Reviewers
- openSUSE Review team
- SUSE SLE review team
- openSUSE Release team
- openSUSE Backport review team
- Package Hub team
- License digger
- Factory-Auto
- 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.
All changes have to pass Staging Review and related test in OpenQA. The change request is in the end explicitly rejected or merged into the product by a member of openSUSE Release team.
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
There is one extra 'suse-sle-reviewers' review in case that the change was initiated by a Community member via a Submit request against openSUSE Jump.
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).
openSUSE Testing Core team in co-operation with openSUSE Release team decides which issues should be soft fails and which hard fails.
Responsibility of openSUSE Testing Core team is that test results represents well quality of the product. The Review of test results for each build is solely responsibility of openSUSE Release team.