After two years and a half in the Ubuntu QA team I have moved to the Hardware Certification team, on Platform Services. I was very happy to be given the opportunity to join the Hardware Certification team and I couldn’t reject. I am very excited to be able to help in the goal of making Canonical profitable.
How will that affect my collaboration with Ubuntu QA
It is been a great pleasure to work all this time with a great group of people (both Canonical and non-Canonical). Obviously, as working directly on Ubuntu QA won’t be part of my paid job, I won’t be able to dedicate it as much as time as I did before. So, first of all, sorry if I am not getting back to you as quickly as I did in the past. But I love the Ubuntu QA community and I am still part of it. I will still be working on some of the things I did before, in my spare time. There are some projects, like the Desktop Testing Program or Desktop Testing Automation that are very close to my heart and I would like to stay somehow involved with them, I will try to attend the Ubuntu QA meeting at least twice per month and I will stay active in the ubuntu-qa mailing list.
The Hardware Certification Team
Having a successful certification program is both beneficial for vendors, ensuring their costumers that the hardware will work with Ubuntu, and the Ubuntu community, as they have access to the list of systems that work out of the box. We agree that sometimes we don’t expose the Hardware Certification program to our community as much as we should. There are people very active in the Ubuntu development that don’t know that Canonical has a public website where people can check what systems are certified to work with Ubuntu or even that the certification program exists. We don’t keep it as a secret, though; the Hardware Certification team has been attending UDS, our main testing tool is open sourced and installed by default in Ubuntu and, as I said, the systems that have been certified are published. I understand that we can do a better job explaining how the hardware certification program itself works and keep it more in the open, accepting suggestion and criticism.
To start with, Victor, the Hardware Certification team manager, has written a wiki page to explain a bit how the certification programs works and we have now a public project in Launchpad where you will be able to file bugs related to the project or ask questions. We would love to hear your thoughts and feedback about the program. In return, we will make our best to improve the program in ways that makes it more useful for our community.
It’s been a while since the last time I blogged about Mago, but Natty is going to be an exciting cycle for desktop testing automation (a lot is happening!) and I would like to present some of the work we have been doing.
Today I will write about Magomatic, a new side project related to Mago.
If you have tried to add a new testcases to an existing Mago wrapper, you can see that this is pretty straight forward. Most of the things that you need are already there, and you need to add only the code of the test, without thinking on the accessibility information of the application (OK, sometimes you have to, but it is quite simple to start the process). If you, however, have ever tried to add a new wrapper application to Mago I guess that you have found the process a bit difficult: you need to understand how the accessibility information is presented by LDTP, you need to create the application python file, you also will have to create a test suite python file, and a XML data file. This is time consuming and I though it could (and should) be automated.
So I created Magomatic. And how does it work?
Magomatic uses templates and accessibility information to create those files for you. Using it is pretty straight forward:
- Open the application you want to create the wrapper for.
- Run Magomatic:
$ bzr branch lp:magomatic $ cd magomatic/bin $ ./magomatic
- When prompted, you will need to select the window you want to create the wrapper for with the mouse pointer.
- Done! Under the
folder you will find a folder with the name of the application with the needed files to add to Mago and start coding your tests.
This is a work in progress, but the main and most important functionality is already there. We really hope that this will lower the entry barrier to Mago and more people will join us adding new tests in the Natty cycle.
The HW Certification team at Canonical is hiring three localized engineers: one in our offices in Lexington (MA), USA; one in Taipei, Taiwan; and one in Montréal, Canada.
The HW Certification team, part of Platform Services, provides certification as a service to partners. Basically, if a computer vendor wants to get one of their machines certified to work nicely with Ubuntu, they can buy this service.
The variety of work involved in our side is big and fun: from receiving the machines to be certified (some of them even brand new machines not yet public!), to commercial relationships, passing from a lot (a lot!) of technical work: writing testcases, maintaining our testing infrastructure, etc.
For me, working at Canonical, has been (and it is) the best professional experience I have had so far. It is great to be able to work in such a great environment, with very smart people and making Ubuntu better for everybody. I truly recommend Canonical as workplace. Please, ping me me on IRC if you would like to know more about how it is to work here.
So, if you live in any of these three locations or are willing to relocate (Canonical does not offer a relocation package), please, have a look to the following job descriptions and send your resume to victorp AT canonical DOT com.
As you may know, during Maverick cycle we introduced statistics from our testers to be reflected in the Ubuntu Hall Of Fame. Well, now, and thanks to my good friend Daniel Holbach, we have, not only individual statistics, but also statistics by LoCo team.
This is how it looks on the Hall Of Fame. Nifty, isn’t it?
Everybody agrees how important the Out-Of-Box experience is for a product. If the users’ first experience with any kind of product is frustrating it is very likely that they’ll return it and never look back.
On Operating Systems, usually, this first experience is turning on the computer and reply to some basic questions. For all the major OS like Windows or Mac OS, the software comes preinstalled in the computer. For many users, therefore, that’s the computer itself: something that you turn on and it starts working.
For Linux is quite different. Despite the efforts that some companies (including Canonical) are doing in order to be easier and easier to buy a computer with a Linux distribution preinstalled, nowadays, the first experience a user has with Linux is, most of the times, a CD and an installation process. Well, if you then want to have one of the best first Linux experiences ever, wait until Sunday and install the brand new Ubuntu 10.10. Its installation process is, ladies and gentlemen, pure joy:
I would like to congratulate the Ubiquity team for the fantastic work they do every six months. They make the first experience of those people who start with Linux better every time. It is great to have the opportunity to work with you, guys.
As you might know, Ubuntu version for netbooks, UNE, is having a major re-engineering work for Maverick Meerkat, soon to be Ubuntu 10.10. The old interface, which included packages like netbook-launcher or maximus, is going to be replaced by Unity. If you don’t know what Unity is, the nice people behing OMGubuntu published some days ago a nice review of the brand new UNE interface.
I will give you a clue: it does look very different from what you’re used to. That’s why we want to collect as many reports as possible of people upgrading from UNE 10.04 to 10.10 (with Unity).
My experience upgrading
OK, I don’t want to ask people to test something if I haven’t (and I have the means for it). I took my Dell Mini 9 (well, technically is Canonical’s, but, anyway) and I installed Ubuntu Netbook Edition 10.04.1 in Spanish. The installation went very well and fast.
After reboot, I updated my 10.04 installation and started the upgrade to Unity. Although the upgrade itself did not have any major problems it took almost six hours! Of course, I reported this as bug 646638. I talked with Michael Vogt on IRC and he will investigate.
Once the upgrade finished everything worked as expected: the language was still Spanish and there were no major crashes. Nevertheless, the global menu stayed there with “File Editar” even when no applications were running. I filed that as bug 646890 in Unity.
Your experiences upgrading
My system is not a real system. I use the Dell Mini 9 with SSD 8GB for testing purposes. I don’t use it on a daily basis. I reinstall almost every flavour of Ubuntu on it every milestone. My upgrade experience was from a nice, cleaned, UNE 10.04 to 10.10. No PPAs or third party software installed.
That’s why we need real feedback from the people that often use UNE 10.04 on their upgrades to 10.10. If you want to participate in our testing effort, just follow the next steps:
Use my testing report as an example. You see that you can add comments (like the system you used,or general impressions) and, of course, add bug numbers if you encounter any.
Thanks and happy testing!
It’s been more than two years since I started working at Canonical and, although I have been blogging about my daily job here, I have never talked about how this job is important to me.
I love testing software. Yes, I know it seems strange to love an activity that some other people find a bit tedious, but I do. I was a full time developer when I discovered that I liked testing the software. Testing software gets you the opportunity to see the product as a whole, but without losing the technical part of the job. So, when I got the opportunity to work at Canonical as a member of the Ubuntu QA team it was like a dream job. Not only I was going to be able to test free software during my daily job but, also, I was going to test ALL the free software that is included in Ubuntu.
When I was hired, one of my first missions was to create a way to to test the desktop in a repeatable way, easy to maintain. That’s how Mago project started, a couple of years ago. Working on this project has been great, as it has been working closely with LDTP upstream developers. I have contributed to LDTP through bug reports, patches and helping with the release of LDTP in Ubuntu. I always tried that the latest LDTP was successfully released and uploaded to Ubuntu.
I specially remember when we were trying to get the latest LDTP before Ubuntu 10.04 Feature Freeze. Nagappan, the main LDTP upstream developer and I worked closely on IRC to meet the deadline. Together, we fixes issued, verified them, got everything together and got it uploaded it to Ubuntu just in time. It was the perfect example of Open Source collaboration.
Mago, itself, is free software, released under the GPLv3. People inside and outside Canonical have contributed to it with bug reports, patches, new features and, of course, new tests to test the desktop applications, often GNOME applications.
But, apart from Mago and desktop testing automation, I am specially happy to be able to test all the open source bits that make Ubuntu: from the kernel to the desktop, from brand new topics as Multitouch, to all time classics as Firefox.
I work for Canonical, testing free software, trying to make it better for everybody. I need to remind myself everyday how privilege I am.