Other package set

The other package set consists of all packages not in the important package set.

Important workflow

All package updates are submitted to the 'updates-testing' repository. Then they await initial sanity test acceptance, a process owned by the Quality Assurance team. Acceptance is granted according to Initial requirements. The decision is based on the result of Package update acceptance test plan, which is executed automatically by AutoQA. When the approval is granted, the update is pushed to the 'updates-testing' repository.

Next, the updates must meet all of these requirements:

Updates must reach a specified positive Bodhi karma threshold [1] provided by a defined team (e.g. proventesters). These qualified testers should consider feedback (especially negative feedback) from other testers in deciding whether to provide approval, as well as their own tests.

Updates must spend some minimum amount of time [1] in updates-testing. This requirement does not hold for security updates.

Other workflow

All package updates are submitted to the 'updates-testing' repository. Then they await initial sanity test acceptance, a process owned by the Quality Assurance team. Acceptance is granted according to Initial requirements. The decision is based on the result of Package update acceptance test plan, which is executed automatically by AutoQA. When the approval is granted, the update is pushed to the 'updates-testing' repository.

Stable Requirements

RelEng: The package update type falls into the list of allowed update types(document not approved yet, just a sample).

+ maybe some more

Exception Process

Package maintainers may ask for exception, when:

they don't agree with QA rejecting their update

they need to push an update without fully adhering to policy requirements

this is suitable for high-important bug-fix updates, which repair severe regressions/breakages

some other candidates?

they don't agree with RelEng rejecting their update

The process of asking for an exception is yet to be defined. It can be a majority vote from FESCo.

Responsibilities

When a serious problem is found in a not yet released updated package, package update builder is responsible for removing this update from 'updates-testing' repository. Fedora Update System must provide this option for package update builder, package maintainer, Quality Assurance team and Release Engineering team.

The Fedora Update System is responsible for sending notifications to package update builder and package maintainer when:

the update has fulfilled requirements for submitting into 'updates' repository

the update has been accepted or rejected to be pushed to 'updates' repository by Release Engineering team

the update becomes available in the 'updates' repository

Even though some security updates do not fall within this policy, the Quality Assurance team is still obliged to test the packages, after they're pushed if necessary, and report any regressions that need to be fixed to the maintainer.