Am 08.09.2011 13:08, schrieb Colin Guthrie:
'Twas brillig, and Samuel Verschelde at 08/09/11 11:59 did gyre and gimble:
(QA Team and Triage team in CC, but please answer only to
mageia-dev@mageia.org)

I was asked to define a process for backports validation, so here is a
proposal. We can discuss it a few days and then I'll add the result to the
backports policy page.

Process for backports :

Triage:
- identify backport requests
- add "Backport Request: " in the bug report summary
- add the "backport" keyword
- assign to maintainer

The maintainer can refuse to do the backport :
- doesn't want to maintain it =>  assign the bug report back to
bugsq...@mageia.org so that another packager can step in
- has a good reason for not providing this backport (policy, possible
breakage...) =>  close as wontfix

Packager:
- create bug report if not done already
- submit to {core,nonfree,tainted}/backports_testing
Is this straight from the cauldron tree in subversion?

- find a tester : original bug reporter when there is one, yourself if there's
none, or ask in forums/irc/MLs...
- once tested by at least one person (it must be said explicitly in the bug
report), hand it to QA :
   - make sure the bug report summary starts with "Backport Request: " or
"Backport Candidate:"
   - add the "backport" keyword if missing
   - assign to qa-b...@ml.mageia.org
   - list the source RPMs if there are several
- be ready to fix bugs and answer QA team questions

QA:
- test backports the same way that we test updates. But don't forget that
updates have a higher priority than that of backports.
- move the packages from backports_testing to backports
Just from a man power perspective this, could be a lot of work for QA
(even at lower priority) but I cannot see a way to improve this without
sacrificing quality control!
If the packager himself does basic testing and makes sure backport works,
that would relieve QA from some work, no?

Reply via email to