My first resolution is to learn my family by marriages language, that being Urdu. Particularly because my mother-in-law doesn’t speak English (a mother in law who can’t talk to you – sounds like some peoples dream!) and learning a language will broaden my horizons, since I’ve never really learnt a (human) language properly. I think this one will be difficult, but I’ll be happy as long as I make some improvement by the year end.

The second one is in the technical field. There’s a very interesting technology for message passing called Rabbit and though not directly related to my job, it’s something that brings me back to my university days when I was very interested in all sorts of distributed systems (I did projects on distributed file systems and message passing interfaces). Of course no-one has any significant amount of control over their career direction at the early stages, so I never got a chance to indulge myself in these areas further, having been thrust into the realm of QA as a graduate. So I will take some time to get up-to-speed on using this technology and hopefully get a chance to implement something in it (time willing)

Back to the soft skills again, a great passion of mine is cooking. I didn’t start doing any cooking for myself until I finished University (most of my food preperation before then could have been better described as ‘assembly’ rather than cooking) and I’d say by now I’ve reached the level of ‘competent home cook’. I want to take that to the next level. Not yet exactly sure what that will mean This ones going to be easy I think, because basically it’s just getting better at something I consider my hobby.

That’s it for concrete goals for now. I might pick a language or two to learn as well (my languages are becoming stale actually as I’m becoming increasingly focused on Python and Bash exclusively) just to keep myself fresh and on the soft (heh) side again there’s a general goal about fitness, but I won’t bore anyone with that.

If I can rememember to then I’ll post again next year on where I got – wish me luck!

First branch the branch you want merge the changes into:

bzr branch lp:checkbox-certification/0.9

then branch the branch which contains the changes:

bzr branch lp:~brendan-donegan/checkbox-certification/wireless_scanning_sru

change into the root of the branch you want to merge into and specify the bzr merge command giving the path to the file you want to ‘cherrypick’ the changes from:

cd 0.9; bzr merge ../wireless_scanning_sru/jobs/sru_suite.txt

This will merge all of the changes from the file wireless_scanning_sru/jobs/sru_suite.txt to 0.9/jobs/sru_suite.txt

The first one is titled ‘Improving automated certification testing of Kernel SRUs‘ and is based around increasing the overall scope and coverage of the test suite used when testing the SRU kernels. Recently I took the time to document the test suite we use during SRU testing, and if you read through it you can see that it’s really quite basic and hasn’t been especially good at picking up regressions so far. I’m quite excited at the prospect of doing this and my definition of success here will be a test suite that starts detecting real problems early. Linked at the bottom of the blueprint are some notes that were brainstormed together on the #ubuntu-kernel channel on FreeNode last week which will form a foundation for the discussion. If you’re interested in ensuring that kernel updates don’t break your system and will be at UDS P then feel free to subscribe to the blueprint (of course you’re free to send your feedback via this blog as well).

The second topic is titled ‘Image creation and publishing for kernel SRU testing‘ and has a less broadly interesting premise but will be important for us nonetheless. At the moment we use quite a complicated lab infrastructure to install all the necessary pieces for SRU testing over the network and it prevents us from easily allowing external parties to perform the same testing themselves. If we can easily automated the creation of images which include everything required for testing then we can get rid of this barrier. If the subject matter interests you then, again, either subscribe or leave feedback here.

One of the tests that I updated was one which would cycle through available resolutions on the system (using the xrandr tool) and request the tester to verify that they all looked okay with no graphical corruption. This is the sort of test that is fine when someone is running the tests on a one-off basis, it’s not so good when one tester needs to supervise 50+ systems during a certification run. One of the main problems is that it causes too much context switching, with the tester constantly needing to keep an eye on all the systems to see if they’ve reached this test yet. Obviously, it being a graphical test, it’s difficult to do fully automated verification so a compromise needed to be reached. The solution I came up with was to integrate screen capture into the test and then upload these screens in a tgz file as an attachment with the test submission. Everything going well, the tester can sit down at their own computer and go through the screens and confirm they’re okay. In fact the person verifying the screens doesn’t even need to be in the lab! The task can be distributed amongst any number of people, anywhere in the world.

Another test that looked like a prime candidate for automation was one for testing the functioning of the wireless card before and after suspending the system. Previously the test case was:

- Disconnect the wireless interface.
- Reconnect and ensure you’re online.
- Suspend the system.
- Repeat the first two steps

This was all specified to be done manually. I am currently updating this test to use nmcli to make sure a connection can be made, then disconnect and reconnect just as would happen if the tester did the steps manually using nm-applet. The one thing I haven’t got down pat yet is connecting to a wireless network where a connection didn’t exist before. This step may be optional as it could be expected that the tester will do this manually at some point during the setup of the tests and we can trust a connection to be available already. This will mean this test has gone from manual to fully automated and hopefully should shave potentially some significant number of minutes off the whole test run!

Saving time on our existing tests will allow us to introduce new tests where appropriate, so we’re able to provide even more thorough certification testing.

After the Ubuntu Developer Summit in Budapest one of the objectives I set for myself this year was to become more active in the Ubuntu community. Being a QA person, one of the most obvious routes was through the well structured bug handling initiatives that the community has in place (thus my posting about the Bug Squad and bug days). To this end I’ve devoted what spare time I have to these initiatives. Apart from Bug Days I also take part in the 5-a-day program which encourages participants to update five bugs a day (by commenting, changing status or updating titles – anything that could be construed as a valuable change to a bug). This is going pretty well and I’m on a 3-week streak of fulfilling my 5-a-day quota (according to the 5-a-day report).

As a result of all this activity I’d gathered enough experience (and evidence of that experience) to file an application for the ubuntu-bug-control team in Launchpad, who have permission to change bug Importance and set the status to ‘Triaged’. This involved testifying to having read some documentation and then providing some example bugs to demonstrate that I understood the bug triage process. It took a week and a half to get enough positive responses (two) to have my application accepted, but as of yesterday I am officially a member of ubuntu-bug-control!

I’ll do my best to use these powers effectively and diligently and hopefully make a big difference to the effectiveness of bug triage in Ubuntu.

alias chx='chmod +x'
alias rvim='sudo vim' (if you use VIM that is )
alias sagi='sudo apt-get install -y'
alias sagr='sudo apt-get remove'
alias sagu='sudo apt-get update'
alias saar='sudo add-apt-repository'

I find that especially the apt ones save a lot of typing. Hope you find them useful!

(oh yeah, just put the lines in your ~/.bashrc and run ‘source ~/.bashrc’)

So, without further adieu – here are a couple of shots of my setup:

I like it because it’s really compact and smacks of geekiness, with all the exposed circuits, yet is really quite easy to use in a lot of ways. The monitor is plugged in via the HDMI port on the right hand side (because of an issue with my monitor I can only get 640×480 out of it, so everything is very squeezed on the screen) and the wireless desktop receiver which handles my mouse and keyboard plugs right in to one of the two full sized USB 2.0 ports. The whole thing is powered by my laptop (even when it’s suspended) via USB-AC 5v connector, also on the right-hand side.

It’s running Natty/Unity 2D installed on the 8GB SDHC card on the left of the board. This means that the whole setup cost (if I had have payed for rather than borrowed it) just under $200. The white labeled chip on the top left hand side of the board is the WiFi/Bluetooth chip and that works *perfectly* out of the box – often picking up a better signal than the laptop sitting right next to it. I also have the option of plugging in my USB headset in the the same USB hub as the wireless receiver (it’s a tight squeeze but it just about fits) and that too works perfectly.

Cons are that I don’t have a USB HDD so Ubuntu is running on flash memory (notoriously bad performance) and that if I decide to power down my laptop but forget the Pandaboard has some task running on it then all is lost Overall though it’s a really nice piece of equipment and because of all the good work that has been done around it, I could recommend one to anyone with a bit of technical know-how (no ARM experience required!)

This issue was bugging me, so I decided I’d take it upon myself to patch it up. Someone had done a similar patch in software-center so I already had all of the knowledge needed right there (i.e. what are the new codes). I jumped into my Oneiric VM, branched the update-manager code and hacked away at a couple of Python modules, tweaked, buffed and polished until lo and behold, on starting update-manager it picked up the connection! A few command lines (bzr stat, bzr commit, bzr push) and a few clicks in Launchpad later my merge request was with the update-manager project maintainer (Michael Vogt aka mvo). Minutes later it was merged and the next day with the help of my patched version of update-manager I was able to update update-manager with the patch.

Looking at my own name there in update-manager’s description of the change, I couldn’t help but think how awesome it is that I’m able to do this with my favourite operating system. That’s what makes OSS magic for me…

Now that I’m at Canonical and trying to participate heavily in Ubuntu’s Bug Squad activities, it’s comforting to know that something similar goes on here (maybe we were subconsciously influenced by it ?). It also happens to be on the same day (Thursday) of the week. I’m of course referring to Hug Days, which are co-ordinated by the QA team. I’ve been involved in them over the last few weeks as a participant (rather than an organiser) and I find the structure to be very good and very accessible. Quite simply there is a list of bugs with different statuses (New, Confirmed or Incomplete) and simple instructions on what to do with each bug. New bugs need to be either Confirmed or set to Incomplete if you find you need to ask the reporter for extra details to be able to reproduce the bug. Confirmed bugs themselves need to be revisited and a check done to make sure the bug is still happening, leading to the bug either being Triaged or set back to Incomplete if it’s not happening and you need the reporter to reconfirm. Lastly, Incomplete bugs should be checked for a response from the reporter to the information request. If they gave the necessary info then the bug should be Confirmed. If not a follow up question should be asked and the bug left as Incomplete.

Some tools that are handy to have to assist with the process of going through all these bug reports and updating them correctly are the Hug Day tools, which semi-automate the process of ‘closing’ Hug Day bugs (they aren’t being closed as bugs, but as tasks on the Hug Day), as well as the Firefox Launchpad Improvements, which are useful not just for Hug Days but any bug work. The improvements include canned bug comments for common scenarios such as when an inexperienced bug filer has provided little info on the bug and you need to tell them to provide simple steps to reproduce the bug.

Each Hug Day is based on a particular package (which helps to focus the effort) and this weeks Hug Day is on Nautilus, Ubuntu’s file browser. I have and will be participating in this as much as I can, so if you decide to participate in it then say Hi on Freenode IRC #ubuntu-bugs where there are lots of knowledgeable Ubuntu people waiting to help out newcomers with the task at hand. See you there!

For the Ubuntu project, the team which has these permissions (amongst others) is Ubuntu Bug Control. This is a group of Ubuntu contributors who have, over a period of time demonstrated their capability at bug analysis. Joining this group is done through a merit system, whereby you have to apply and back up your application with evidence. You need to state that you’ve read the relevant documentation on bug importance, status, assigning bugs and triaging. You are also quizzed on the requirements that need to be met in order to mark a private Apport crash bug public. Then you need to give a commentary on your ‘best’  five bugs, explaining what actions you took on them (status changes, any actions taking place around the bug such as working on a fix or discussing issues with fellow community members).

In all, the process is not too demanding for someone who has been doing this a while, so I plan to make my own application soon. I’m still working on my ‘bug resume’, since I have the slight disadvantage that a lot of the packages my team works with are private, so triaging I do there can’t be used as examples. So for a few more weeks I will do a few bugs each day and probably submit my application before the end of June.