Gosh, just the FUDConniest time
AutoQA BarCamp Talk
On Friday Bill Peck and I gave a combined talk about our automated test efforts. My half was about the new AutoQA system (based on autotest) which we've developed to address some of the Big Problems in Fedora. (Slides are here). Bill's part was about Beaker, which is a system developed inside Red Hat to address some of the testing needs of RHEL. It's interesting to see where the two things overlap and the places where they diverge, just based on the differing needs of the two projects.
For example: AutoQA was designed to tackle things like Rawhide failing to build, the installer failing to start properly, packages with broken dependencies hitting the public repos, and so on. These problems are generally independent of the hardware you're running on, so AutoQA currently runs all its tests on whatever test system is available - or inside a VM.
Beaker, on the other hand, has some robust system inventory and provisioning features, because it's very important for Red Hat to be able to (for example) test new kernels on all the various hardware supported and sold by their partners.
Despite the differences we've been talking a lot about ways the two projects could work together to make them both stronger. Yay Open Source!
I had some hallway-style conversations with Seth Vidal and Jesse Keating which confirmed the idea that we can do a dependency check for new packages (or package updates) without having to do a full repoclosure run every time. I'm still working on code for this but with a little work we should be able to automate the check to happen after every single package build and proposed update, and prevent broken deps from ever getting into the repos again.
This will require a couple of new things in AutoQA - a post-bodhi-update hook, for example - but Luke Macken assures me this is pretty easy to do with the currently-available RSS feeds of info from Bodhi.
automating LiveCD testing
So Adam Miller (maxamillion on IRC, XFCE spin maintainer) wants a way to automatically test the Live images he's producing for XFCE. Which is awesome, because we all want a way to automatically test Live images. We talked a bit about ways to script GUI stuff (hello, Dogtail), how to boot Live images in a VM, and how to cram tests into Live images without completely rebuilding them.
It would be nice if Live images used a boot parameter like 'updates=XXX' and we could pass a filesystem image (or cpio archive) full of files that would get dumped onto the Live system before rc.sysinit. Then we could (for example) drop tests and a test-launcher in place at bootup. Until that happens, we might be able to fake it by using livecd-iso-to-disk and a loopback disk image instead of a real USB key. But if it comes down to it, we can probably tell the Live image to put a login console on the serial port, and log in through that.
We'll see where that all goes soon enough, I hope.
This is a project I keep picking up and messing aroung with - in short, a network-mountable filesystem with debuginfo data, so you don't have to install debuginfo packages anymore. The (old) Feature page is here.
Peter Jones and I restarted work on the debuginfofs client/server and talked through some of the implementation details. And apparently the GDB guys are going to rework the debuginfo packages so different package versions don't conflict with each other. Nice!
There were some other Big Ideas discussed at FUDCon - big changes to the way we do updates, completely revamped bug reporting, even the basic purpose of the Fedora Project - but I think those will get a lot more thought and discussion in the coming weeks.
Oh, two other things: The artichoke knows things, and you should all install the hot-dog boot animation. Because the mustard indicates progress.