QA

Motivation¶

Currently, http://dashboard.qam.suse.de/blocked shows maintenance incidents with failing openQA tests sorted by priority (highest priority first). While this is helpful for reviewing test failures according to the priority given by the Maintenance Coordination/Security engineers, it does not express the urgency that is behind the incidents displayed. E.g. the list could be full of updates that have a planned released date far in the future or full of updates that need to be released soon or a mixture of it.

We should make use of the schema for priority calculation used by Maintenance Coordination (see https://tools.io.suse.de/smelt/user/process.html#requests ) to breakdown the list of incidents displayed on http://dashboard.qam.suse.de/blocked .

Acceptance criteria¶

When looking at http://dashboard.qam.suse.de/blocked, it must be obvious where the swimlanes are for the following groups of updates:

1. priority > 650 (updates with severity classes Remote Root, Data Corruption, Severe Regression or other critical updates)
2. 550 < priority <= 650 (updates with severity class important or highly desired feature updates)
3. priority <= 550 (updates with severity classes moderate and low)