On Wed, 2012-06-20 at 04:46 -0400, Jaroslav Reznik wrote: > > We get help fairly often for GNOME > > and KDE, and satellit_ usually covers Sugar, but we very rarely get > > anything for Xfce or LXDE. > > The main issue here is - the TC/RC images are "released" too fast to > be able to fill in the matrix for all DE and all TCs/RCs. > > The idea could be - fill in the Matrix when first TC/RC is created, > then follow closely the changes (to test only stuff that could be > affected - hah, could be tricky) - not to fill the whole matrix and > go through the all tests that even do not test the real change and > then we can have one full matrix test for last one in the series of > images and let some amount of time to do it (to mark it - done). > Otherwise we will never have all DEs filled in as it's impossible > in a time we have. And I have to thank you Fedora QA guys for > helping us to cover KDE test, I always try my maximum but sometimes... I know they iterate fast :/ When a candidate doesn't likely change anything significant wrt. a desktop I try to say so, but the thing is, it's possible for really weird stuff to happen, and we have to try and exclude that possibility as much as possible. So instead of trying to do something like you propose above and run the risk of dropping the ball somewhere and declaring that a test has passed which actually fails for the latest compose, I'd prefer to always have a fresh matrix for each compose. What we can do when we're *almost* sure the results for, say, TC2 will hold for TC3 so far as KDE is concerned, is copy the results across; we do do that sometimes. It has the advantage that it's clear we're relying on a previous candidate test, rather than giving the false assurance that we've actually tested it directly with the latest build. Unfortunately the fast iteration is a fact of life on the release cycle we use, there's no possible other way to do it so far as I can see :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
