> 21.06.2012 14:30, Maarten Vanraes kirjutas: [...] > Well, AFAIK there is still no stance on backports policy (are we > backporting from cauldron > (n) to n-2 or not - if we do, we break upgradability here!). > Cherry-picking backports is > needed.
This is true, but has to be solved anyway, no bearing on this problem. and cherry-picking should not be needed(since it's not supported), so that's a different problem. > And i don't think that the packager who is creating update should > check all possible backports. no, since cherrypicking is not supported, only needs to be test with backports and without. > What if that backport comes into play later? When the update is > already released? then the backport packager needs to make sure his backport works, and since he's part of QA (according to policy), he'll need to test with and without backports. > I still think that backports should not be used during updates. you're free to think so, but with your skills, i'm sure you can make that easily happen, like keeping backports disabled, unless you need something. > And it doesn't make QA work any easier here. [...] actually, i think it is easier for QA, because cherry-picking cannot be supported, and the backport packager is responsible for his backport testing. for updates, only needs to be tested with or without backports. so, since they need 2 tests anyway (i586 and x86_64), if one of them is with backports enabled and the other is without, it doesn't need any more testing than before.
