What's going down in QA land

You may have noticed the blog has been a bit light on QA news lately. I attribute this to the sudden outbreak of tennis- and golf-friendly weather. ;) No, really, it's mostly because we're in the Post-Release Lull where we do a lot of planning and little Exciting Stuff. But there are a few things happening! Of course, work on AutoQA continues apace, with new hooks and watchers and code improvements coming in thick and fast. I'm not really well up on the gory details, but it's very obvious that this is moving along nicely and we should be able to start really using it in anger for F14 and F15. One particularly notable development is that the AutoQA team is now offering package maintainers the chance to be notified of rpmlint, rpmguard and (when available) initscript LSB compliance test failures for all Koji builds of their packages. This is something of an interim system, but the fact that the AutoQA infrastructure is already capable of running these tests against each Koji build and providing the results to the package maintainers is great. What's this 'initscript LSB compliance' testing, then? The AutoQA team is implementing tests to check whether initscripts in Fedora packages comply with LSB guidelines. The tests need to be customized to each individual initscript, so this is a lot of work. Josef Skladanka put out a call for help in implementing the actual tests and reviewing the tests to make sure they're working correctly. There's a wiki page which describes the whole effort and the various ways you can get involved and help out. The Bugzappers group has also seen some great developments lately. A new member, Jeff Raber, has heroically taken on the mantle of the triage metrics project. We've long wanted to have some way of measuring progress with triage, so we can know how many bugs we're triaging, how many components we're covering, and so forth. We're now taking a new, simplified approach to this, based around simply coming up with some canned Bugzilla queries we can run manually every so often to generate some basic statistics. This should allow us to get up and running with at least some information in a manageable timescale. Jeff's already come up with a few queries and some small modifications to python-bugzilla to produce the type of output we need, so that's looking very promising! We've also been working on kernel triage again, with the coolly-nicknamed 'JP' (tcpip4000 on IRC) revising the stock responses on the old kernel triage wiki page to be more in line with the rest of the Bugzappers stock responses. I'm also supposed to be talking to the kernel team to get a current list of distinctly-maintained kernel subsystems out of them, as part of our plan to effectively split the kernel bugs in Bugzilla up by kernel subcomponent, using tracker bugs. James has been working hard on the Fedora 13 QA retrospective, which we'll use to identify various areas we can improve on for Fedora 14. Many members of the QA group have chipped in with ideas and suggestions here. And finally, I'm working on my big Sekrit Project for F14, which will be to try and extend the desktop validation testing we did for the default desktop (GNOME) in Fedora 13 to all the major desktops Fedora ships - KDE, LXDE and Xfce. I'd like us to be able to ship F14 with the same level of confidence in basic desktop functionality for all four main desktops. Even though they happen not to be the default desktop, they're still significant parts of the Fedora project which many of our users take advantage of. I'm hoping to work this into the validation process starting right from the first pre-releases, and I'm already working with the KDE, LXDE and Xfce SIGs to try and make it a reality. Of course, Fedora 14 Test Days will be coming soon, and it won't be long before we have an initial snapshot and then an Alpha release, and then we'll be well on our way to Beta and then Final. Lots to look forward to!