Samuel Verschelde a écrit :
Le jeudi 8 septembre 2011 21:16:50, Florian Hubold a écrit :
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
[email protected])
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
[email protected] so that another packager can step in
- has a good reason for not providing this backport (policy, possible
breakage...) => close as wontfix
It would be a good idea to require giving the reason why refused, for clarity.
(e.g. "Don't intend to maintain" or "Will conflict with version 123 of xyz",
or whatever.)
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 [email protected]
- 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?
In my opinion this is what a packager should always do, be it for an update, a
backport, or a package in cauldron. But this doesn't remove the need for a QA
validation if we want to guarantee a minimal level of quality.
Agree - that should always be done. QA is there to find what the packager
might have missed.
It seems an excellent backport policy - the weak link being the backport
packager having to commit to support for the life of the release -- even though
we can't garantie that it will be the case, that is a good requirement.
Samuel
--
André
