Fedora 21 Beta, wikitcms/relval improvements, more stupid mediawiki tricks, working on laptops...

I really should blog more, shouldn't I?

Today's big news, of course, is that Fedora 21 Beta is out!

Fedora 21 Beta

It was an interesting release to test, with a lot of the practical consequences of the Fedora.next 'Product-ization' effort getting shaken out. There are still some fudges and rough bits here and there in the practical implementation of that vision, but it's not that bad, for a first cut. It's definitely great to see the Cloud images showing up and the awesome Roshi co-ordinating test efforts there - I think the Product approach is really paying off in terms of highlighting the Fedora Cloud story.

The Server bits are also coming together - there's still further to go, but in Beta you can use the current Rolekit code successfully to set up a Server system as a 'domain controller' (a FreeIPA server) pretty painlessly, and Cockpit is pretty great. It's neat to do a Server installation and go straight to its Cockpit interface to manage it.

I'm pretty happy with the quality of 21 Beta as well, especially given all the moving parts we had to keep track of. The big emergency - there's always one - turned out to be a somewhat nasty upgrade issue we discovered after we'd already signed off on the Beta images, but we've ben able to come up with a pretty good strategy for dealing with that, and the only practical consequence for most folks should be that trying to upgrade to 21 with fedup will fail (safely, and intentionally) until we've got images we're happy are safe from this bug lined up later today. No-one should be able to mess up their system due to it. Of course, upgrading is inherently dangerous and upgrading to a pre-release is more so, and you should never do it without solid backups and a recovery plan.

Relval / wikitcms

Since I last blogged about wikitcms/relval I've cut a few more releases. 1.2 added a 'post-processor' to the testcase-stats sub-command which basically cleans up its output in a couple of ways; it handles things better when tables are renamed or test cases moved around or added or removed between composes. I'm hosting testcase_stats output for all Fedora releases from 12 onwards - the output for the current release is updated daily or hourly, depending on how hot testing for the release is at present (right now I'm on daily updates for 21).

relval 1.3 added a report-results sub-command: you can now report release validation results using a rather 1980s-style TUI rather than by editing wiki pages. It's a bit silly, but I found at least for me with 21 Beta validation it was rather more efficient than editing the wiki pages directly. It's pretty easy to try out, so give it a shot.

Currently I'm working on making the whole project more generic. wikitcms 1.4 added some preliminary support for QATracker, Ubuntu's manual test management system - not because I'm specifically interested in QA Tracker, but because it was a handy real-world implementation of something similar to Fedora release validation using a different system.

After 1.4 I decided my initial approach - adding more generic object types within wikitcms - wasn't quite the right one. Instead I'm planning to revert wikitcms to being strictly a client for the Fedora 'TCMS', and instead add a third component, perhaps called python-libtcms, whose job will be to provide a consistent interface to multiple TCMSes. libtcms will have concepts like 'unique test instances' and 'results' implemented in such a way that libtcms consumers just pick a particular TCMS to interface with, and can then use the same methods and so on regardless of what TCMS they picked.

I've already done a proof of concept where a minimally-modified version of relval was able to generate testcase-stats results for Ubuntu instead of Fedora; I'm hoping to get the production implementation done and probably released as 1.5 or 2.0 some time soon. Then I'll look at adding additional backends, perhaps for Moztrap next (I picked QATracker as the first non-wiki system that got implemented because it's a real system with real-world data and it already has a nice simple Python module for talking to its API).

Stupid Mediawiki Tricks

Along the way with Fedora 21 validation and relval work, I added a couple of refinements to the wiki magic bits of the Fedora release validation complex. I'm still trying to decide if the extent to which we've managed to abuse mediawiki for these purposes is cool, terrifying, or both. Anyhow, there's now a new CurrentFedoraCompose template which simply identifies the 'current' TC or RC. This is updated automatically by relval compose when invoked with --current in recent versions. I initially wanted to edit the Test Results:Current (testtype) Test redirect pages to use that template, so they didn't each have to be edited each time a new compose is run, but turns out you can't use templates in redirects, unfortunately.

Still, there's a couple of other places so far where the template has come in handy. When you run relval report-results without specifying the compose you want to file results for, it checks the contents of the template and defaults to filing results against that compose (so it usually defaults to the right one).

The stupid mediawiki trick I was thinking of, though, is on the validation instructions template. This is transcluded in every results page, with variables specifying the compose version and the test type. I took advantage of that and added a warning that's only displayed conditionally. If the page's compose version matches CurrentFedoraCompose, it isn't displayed. Otherwise, it is. The warning says that the page is not for the current compose, and links to the correct page for the current compose.

This uses a mediawiki extension called ParserFunctions, which lets you do clever stuff like that - it has a few special templates which let you do conditionals and evaluate expressions and stuff. This particular trick uses the {{#ifeq:}} function which tests whether some string (in this case, the combination of the page's {{{release}}} {{{milestone}}} and {{{compose}}} variables) matches some other string (in this case, the current contents of the {{CurrentFedoraCompose}} template), and produces different content depending on whether it does or not - in this case the content if it matches is nothing at all, and the content if it doesn't match is the "Warning! Not the current compose" note.

This saves poor Andre Robatino going through all the old compose pages adding the same warning manually!

Working on laptops

Kevin Fenzi's on a mission to blog daily at present, and today he explained why he uses a laptop as his primary work machine. I found it interesting because I have more or less the opposite experience - I use a desktop full-time. I usually go to the UK for a few weeks a year and have to use a laptop as my main system there, and I find it terrible and can't wait to get back to my desk.

I post pictures of my desk occasionally, the latest is still pretty much accurate. I think the main thing that makes me more productive at the desktop is the two large displays, followed by a real mouse and a real mechanical keyboard. I think the display issue varies a lot depending on your work; my work tends to involve a lot of context switching and writing one thing with reference to another thing, which is probably why I find the dual displays so valuable. I can imagine it'd matter much less if you focused on one task at a time and didn't need reference material so much, or if a lot of your work was done through remote console sessions in any case.

My typical dual display workflows are having mail open on one head and a browser on the other (often writing an email with reference to a web page), having a text editor on one head and a browser on the other (lately the text editor usually has some Python that doesn't work, and the browser has sixteen tabs open on either StackOverflow or the Python docs...), having test VMs open on one head and IRC running on the other, stuff like that. On a laptop I just never feel like I have enough room to keep an eye on everything at once.

I've never found any kind of laptop-y pointing device which could get anywhere close to a real mouse. You can carry a mouse around with a laptop, of course, but then you always have to find the damn thing and set it up. My desktop mouse sits on my desk and is always plugged into my desktop, it's an attractively simple scenario. :)

And more!

Well, I guess there's not a lot more? I spent some time polishing the ownCloud updates for Fedora 19 and EPEL 6 after I first blogged about them - I think they should both be good to go, though I'm hoping for at least some Bodhi feedback before I push them. I'm nearly in a position to do an ownCloud 7 build for EPEL 7, as well - I'm just waiting on an EPEL 7 branch for php-phpseclib-crypt-rijndael, then I can do a few builds / tags and a bit of testing and send a build out. I'm pretty sure all the necessary major bits are available for the build to work. I need to find a few hours to clean up some upstream submissions and ideas I have lying around for OC, as well.

Fedlet is sort of sitting third on my passion project list behind wikitcms and ownCloud ATM - apologies to Fedlet folks waiting impatiently for new bits :) I will try and do a Fedora 21 Betaish build with a 3.18 kernel some time soon, though.