(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 Packager: - create bug report if not done already - submit to {core,nonfree,tainted}/backports_testing - 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 Packager again: - be ready to fix bugs : once you pushed a backport, you have to maintain it until the distribution's end of life :) Does this seem a good process, from the packager, QA and triage point of view? Best regards Samuel Verschelde
