A quick note for the terminally curious: the Rawhide nightly live build succeeded for the first time in 2011 tonight. If you grab the image from that link and throw it on a DVD or USB stick (too big for a CD at present), and you have co-operative hardware, it should boot up into a vaguely functional and very current GNOME 3 / GNOME Shell environment. (I'm not making any promises, though - it works on my Intel graphics adapter but not my NVIDIA, at present). Curious how things are looking in the GNOME Shell world right now? Take a look. Of course, there's still many tweaks and improvements to come before GNOME 3 and Fedora 15 are done - we're not even at Alpha for F15 yet - but if you just can't wait, go for it!

As my strategies for avoiding writing the QA beat for FWN reach ever greater heights, today I finally set things up so I can receive mail at happyassassin.net; I used the rather neat No-IP Reflector service to get around my ISP's port 25 block, so now my mail server is fully-fledged one at last, accepting mail for delivery to happyassassin.net as well as all the other stuff I had it doing. Yay geekery.

So, I'll start using adamw AT happyassasin D 0 T net for most personal (i.e. non-Fedora, non-Red Hat, non-Mandriva) email in the near future. Add it to your adamw collection!

Project Mojito, my long-term work goal, involves us making the Fedora QA process sufficiently well-oiled and automated that the squishy humans can spend all our time on the beach with mojitos. (Continuing to draw a paycheck in this glorious future is a somewhat tricky problem which I've yet to solve, but give me time!) Here's just one small step on the path to that promised land.

We run many Test Days for Fedora. Each cycle, I organize a set of three, one for each commonly-used X graphics driver. Together, these are known as the X Test Week. Back in the dark ages of Fedora 11, when this started, the three test days were somewhat more separated, and the particular areas tested for each driver were quite different. Each driver ended up with its own range of test cases, some of which were very similar, some of which aimed to test the same thing but were written quite differently, and some of which were unique to one driver and not present on the other.

Over time the set of test cases for each driver got more and more similar, but all the test case pages were still completely independent. Little differences grew up between otherwise identical test cases - errors fixed in one but not another, additional instructions given for Intel but not Radeon. It was silly.

No more! The brand new world is here!

If you go to the page for a specific graphics test case now - for instance, the Intel XVideo test - you will see a boring old test case, much as it has looked for years. But look at the page source, and you will find only the category, and this mysterious invocation:

{{Template:Testcase_video_xv|driver=intel|module=i915}}

This is the beauty of abstraction, laid scandalously bare to your inspection. The use of templates is pretty common in mediawiki-based wikis; if you edit the Fedora wiki at all you're likely used to using 'small' templates like {{package|packagename}} to format (packagename) with a neat little standard format that makes it obvious you're referring to a package, for instance. But you can use templates for much bigger stuff, if you like. For this purpose, I converted each of the various X test cases into one gigantic template. Template:Testcase_video_xv is the template for the XVideo test case: you can see it here. You can see that it simply contains the entire test case, with variables named driver and module. When you include this template with the driver and module parameters specified - as in the mysterious invocation seen above - they are inserted into the template, so now it refers to the X driver 'intel' and the kernel module 'i915', and we have an Intel-specific X video test case. Simply by changing the driver= and module= parameters we can create the Radeon and Nouveau XVideo test cases, and all three will now always be in sync; any change to the test process itself is made to the template, and will of course appear in each of the three driver-specific test case pages.

You can nest templates, as deeply as you like - so each of the X test case templates uses several other templates, mostly typical utility templates like {{package}} and {{command}}. I also created yet another new template to add one more step of abstraction to the X test cases. I noticed just about each one starts out by instructing you to check the X and kernel configuration, and do a clean boot. Instead of having this same text in each test case template, I made it into its own little template and included that template into each test case template. Now if the general procedure for preparing the system properly to run an X test changes, we only have to change that template once, not change each test case template separately.

You can also play neat little tricks. There are still occasions where the test procedure may differ slightly between packages. For instance, when testing OpenGL, you have to install the mesa-dri-drivers-experimental package for nouveau, but not for the other two drivers. I could have just put this step into the generic template - it wouldn't really hurt radeon or intel users to install it - but instead I found a more elegant method. I added this variable to the start of the setup step of the OpenGL test case template:

{{{extrasetup|}}}

that is, it's a variable called 'extrasetup'. The neat bit is the pipe with nothing after it; that sets the content of the variable, if it's not specified when the template is called, as nothing at all (the default is to fill it in with the variable's name). So if you call the template and specify content for the 'extrasetup' variable, that content will be included as steps at the start of the 'setup' process. If you don't specify the extrasetup variable, everything will look fine, there will be no extra setup steps. So you can see that the nouveau OpenGL test case specifies content for the 'extrasetup' variable to add an extra setup step instructing the user to install mesa-dri-drivers-experimental; the Radeon and Intel OpenGL test cases don't specify the 'extrasetup' variable at all, and they simply get the normal setup steps from the template.

This was an afternoon's work to set up, but it allowed me to standardize the test case set across all three drivers, and it means that it'll be much easier to adjust the test cases in future, and they will not fall out of synchronization.

My educational background doesn't come into my 'work' (ish) life often, as my degree was in history. But today Larry Cafiero set me off with this blog post. In the end I wasted two hours researching the history of Facebook logos. You can find my fascinating dissertation in the comments. Anyone want to give me a PhD? :)

So, the weirdness first!

For anyone who doesn't keep in touch with gaming news, the background (that's an early story, from before this was as solidly confirmed as it now is). Last month, it became apparent that unauthorized third parties have gained access to the Sony private key used to sign all Playstation 3 software. The key can pretty much be considered entirely compromised, now; the two hackers publicly known to have access to it are white hatters who steadfastly refuse to use it even to allow piracy, never mind actual nefarious stuff, but it's pretty likely it's either already in the hands of less ethical hackers, or soon will be.

The funny thing is how small a story this is, so far. Even the mainstream tech press doesn't seem to have picked up on it; so far it's mainly a story in the gamer press being reported as "homebrew and 'backups' will soon be possible!"

Now, imagine if Red Hat or Canonical were to screw up this mightily; it'd be an absolute car crash. All hell would break loose all over the Linux and mainstream press. It's possible the Sony story will hit the mainstream news once they get wise to it, but still, it's kind of an interesting difference. This kind of utter and complete security fail would be huge news for a more traditional computing company, but since this is a game console and Sony isn't really thought of in the way RH or Canonical or Microsoft are, it doesn't get the same coverage.

The funny thing is I'm kind of a Sony fanboy; I have two Sony portables, a Sony e-reader, and various other misc bits of Sony kit. They make some awesome hardware. But when they screw up, boy, they seem to screw up big time.

Okay, on to my own stuff: Gwenole Beauchesne very kindly fixed up a few bugs I hit trying to build recent vdpau-video code, so the latest vdpau-video is now up for F13, F14 and Rawhide in my video-experimental repo (yes, I'll note the irony before anyone else does: said repo is unsigned, if anyone pwns my webserver, you're in trouble. And I run Wordpress. So, y'know, watch out. :>) I've also once more revived my work on getting libva into Fedora, so with any luck that review might actually finally get done at some point soon.

I've been pushing along on getting the Fedora 15 test day schedule into shape; X test week has been moved up a bit to late February (so the nouveau test day will be on my birthday, that'll be fun!) and I've created the pages for each of the days. I'll be updating the test cases soon.

Intel's Jesse Barnes is awesome, as just in the last week he's managed to get on top of the messy issues with the new eDP standard for laptop panels, which has been playing all sorts of havoc with owners of Dell E4310s, E6410s and E6510s, and Sony Vaio Zs (and possibly a few other quite new laptop models). I've been tracking Jesse's progress on this work and trying to help co-ordinate feedback and testing with Fedora users, and now Jesse's got a tree which seems to be playing nice for everyone. So those systems should be A-OK for Fedora 15, and even with any luck for Fedora 14, if we get the fixes backported or F14 gets bumped to the 2.6.37 kernel series (which I think may be on the cards).

I've not been able to do a lot of work on Unity lately, mainly because I'm in the UK visiting family and don't have any native Rawhide systems here (and you can't run Unity within a KVM VM), but some good news is that the GNOME developers implemented something for this glib proposal which was written for Unity and sent upstream; the final framework is quite different from what the Unity developers came up with, but it will work fine for Unity, and the Unity team is already at work adjusting bamf to work with the new code. So that's one more barrier to packaging Unity outside of Ubuntu removed, with the help of some great collaboration between a bunch of people, and that's the kind of awesome we need! I'll be able to get back to full steam on Unity when I'm back in Canada near the end of the month.

Finally, the package-specific test case organization proposal seems to be rolling along nicely; I'm happy with the latest drafts and other people seem to be too. The actual policy seems to be mostly done at this point, the next steps are to put it into place officially, and start migrating existing test cases into the new organization scheme, then start writing some new ones. I'll be reaching out to test and devel lists soon to ask people to help out with that.

To celebrate the new year (and because someone poked me about it on IRC), I updated my video-experimental repo. F12 is out, F14 and Rawhide are in, and there are updated versions of mplayer-accelerated and gstreamer-vaapi (which still doesn't work for me, for the record). There's a newer vdpau-video available upstream, but it doesn't build; I've asked Gwenole for help with that, and will upload it if I can get a fix.

For anyone who doesn't know, the repo contains hardware video acceleration related stuff; it used to contain a build of libva, the VA-API video playback acceleration framework, but that's now in RPM Fusion. It now contains only a build of mplayer with libva support added, called mplayer-accelerated, and gstreamer-vaapi, which should add libva support to gstreamer (but, as I mentioned, currently doesn't work for me; YMMV). vdpau-video wraps the VDPAU support of the NVIDIA proprietary driver, letting you use libva-supporting apps with that driver. Since I can't get the current version to build, as mentioned, it's only available for F13. Also only in the F13 repo at present is mplayer-mt, a build of mplayer with support for multithreaded playback; I suspect this isn't of much interest to anyone these days so I haven't bothered to build it for F14 or Rawhide yet. Yell if this is something that'd be really useful to you.

So I'm still working on my current big QA project, package-specific test cases - this started out as 'critical path package test cases', but it became clear as I was working on laying out a model for this that that wasn't the best way of looking at it; not all test cases relating to a critical path package are related to critical path functionality, so we needed to define the concept of package-specific test cases, and also provide a way of marking particular test cases (whether package-specific or not) as being related to critical path functionality.

I recently posted a draft of my proposal for a standard categorization method for package-specific test cases (and critical path test cases) to the devel and test mailing lists, and it's been getting some good feedback and I've been refining it. However, the whole thing may be a bit hard to get a hold of a corner on unless you're thinking about it as much as I am, so I thought a super-lame mockup might help! Voila:

Of course any final implementation of this would not look like ass (I hope...) but this should get the point across. The idea is that having a standardized categorization scheme for package-specific test cases will allow Bodhi (and other tools, like fedora-easy-karma) to reliably discover what test cases relate to a particular package, and then display the relevant test cases for any update on the page for that update. They would be links, of course. So you can look at the page for an update and immediately discover what test cases you can run to test it. Having a category for critical path test cases allows Bodhi to do a trivial operation ('what test cases are in both the category for this package and the critical path test cases category?') to prioritize any test cases relating to the package which also relate to critical path functionality. The optional 'advanced' categorization in my proposal, if used, allows Bodhi to display test cases for core functionality and test cases for extended functionality separately.

Note that there's no 'special sauce' needed for what's in this mockup: the way it looks is how it would look if Bodhi simply derived all the text strings from category names. It should be simple for Bodhi to find the category 'Category:Package_xorg-x11-drv-ati_core_test_cases', and extract the string 'Core' to display as the name for that group of test cases (as the rest of the category name is standardized). Possibly we'd need to hard code the relative priority of certain standard group names, so Core gets displayed above Extended, or we could figure out a way to extend the proposal to denote this. But mostly it's all there. (The test case names would have to be standardized to allow Bodhi to display only the relevant bit of the test name, I suppose - I haven't put this in the proposal yet, but I could).

So, this is the sort of thing the proposal is meant to make possible - I hope this makes it clear why it's cool! The advanced version of this would be that, with Bodhi 2.0 featuring non-numeric karma, the listing for each test case would have a drop-down box or radio buttons or something to mark 'pass' or 'fail'. fedora-easy-karma could similarly display the available test cases, and provide a method for you to input a result for each.

So, lately almost every comment I post is authenticated by either Disqus or OpenID, using my Fedora OpenID.

Something cool about Disqus is that if I go to my profile page there, I can see all the comments I have posted lately. Or, y'know, ever. This is awesome. It allows me to go back and admire the sight of people thanking me humbly for graciously bestowing my considerable wisdom upon them. This pleases me.

Can't OpenID do this? Can't we get a page in FAS where I can go and see all the actions I've done (i.e., almost always, comments I've left) that were authenticated via my FAS OpenID? It must be possible! Do it! Do it now! I HAVE A MIGHTY NEED!

(no. I won't fix the OpenID commenting on my blog. Hypocrisy? I've heard of it.)

Is it just me, or are recaptchas getting harder lately? I seem to be getting words that are archaic, or misspelled, or obscure proper nouns, or use non-Roman characters. I think they ran out of the easy stuff. I'm not sure how long it'll be before I can't pass recaptcha any more =)

Jim Gettys is a hero, and I highly recommend sticking with his recent series of blog posts. Yes, those long, initially apparently slightly nutty rants about 'bufferbloat'. He's just fixing the Internet, is all.

I confidently predict his stuff will find its way into exactly no mainstream news (and probably very little tech press news), which is a bit depressing. After all, it's only, y'know, most of the world economy which now relies on this here Internet thing which we all vaguely expect to just work all the time. It's not complicated, right? Just a bunch of computers all wired into each other. You know. Billions(? are we at billions yet?) of them. All owned by different people, in different countries, connected together in about fifteen thousand different ways, from ethernet to satellite to carrier pigeon. Nothing could go wrong with that, after all.

Even if you only follow about a fifth of what the hell he's talking about (like me...), it's fascinating stuff.