Portal:Jump/Policy/ChangeValidation

Jump to: navigation, search

ROUGH CUTS

This document is summarizing the current strategy for Quality Assurance used in the openSUSE Jump concept.

Approval of this document will be one of prerequisites for a mini-interlock for openSUSE Leap 15.2.1 (poo#70969) , where we'll decide if we'll have an intermediate Leap 15.2 release or not.

Glossary

Reviewers

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.