Making Ubuntu better, if possible
This is old news, but I have been busy lately and I just haven’t had the time for a quick post about it.
I wrote an introductory article about Mago for the GNOME Journal and it was published in its November issue.
If you want to learn about Mago and how can it can help you testing your desktop application, the article is a good starting point.
GNOME Journal: GNOME desktop testing automation and how to use Mago
Next Thursday, December 10th, Lucid Lynx Alpha 1 is going to be released.
We will be spending next week testing the ISOs and coordinating efforts in #ubuntu-testing Freenode IRC channel.
If you are planning to help with the testing, start syncing your Lucid images today, to avoid network bottlenecks and last minute hurries.
To sync your images, you can use the rsync URLS at http://cdimage.ubuntu.com, or use Steves Beattie’s script that do all the work for you.
Lucid knows when you’ve been bad or good, so be good for goodness sake! (and help us testing the candidate images…)
Updated: Steve’s script URL is now fixed.
I am a happy user of the daily build of Thunderbird 3. Although it is still under development, is the best email client for Linux I’ve tried so far, at least, the one that better works for me. Email search & filtering is fast and reliable.
The only thing I don’t like is that wrapping your emails to 72 characters when sending plain text is not straightforward. Once you have selected to send your emails as plain text and have set the line wrap option to 72, there is still one more option to tweak.
Thunderbird has a “feature” that sends by default all plain text with the option format=flowed, which unwraps the email in the client receiver. To turn this feature off, you have to toggle one of the options in the chrome editor:
To disable flowed paragraphs, enforcing line breaks as formatted in the message, set the preference:
mailnews.display.disable_format_flowed_support true
(http://kb.mozillazine.org/Mail_content_types#Plain_text)
To disable paragraph flow when you send plain text messages, and in the plain text part of multipart messages, set the preference:
mailnews.send_plaintext_flowed false
(http://kb.mozillazine.org/Mail_content_types#Disabling_paragraph_flow)
I put it here, in case is helpful to someone else.
As you may already know, next Ubuntu release, Lucid Lynx (10.04) is an LTS release.
For testers this means one important thing: upgrades should be smooth from either Ubuntu 9.10 (Karmic Koala) or latest Ubuntu LTS release (8.04, Hardy Heron).
As we all know, nowadays, computer storage is very very cheap, but bandwidth is not. Later in the cycle we are going to need to test as many upgrades from Hardy and Karmic as possible. So, why not planning ahead and start downloading today Hardy and Karmic images? The unstoppable Shane Fagan has started doing so already! You rock!
Later in the cycle you will be able to easily install Hardy or Karmic in a spare machine or a virtual machine and upgrade from there. You will have part of the work done. And you can start contributing to your beloved distribution just now 
Other releases from Ubuntu derivatives can be found at:
Well, I think the title of this post is a bit strong, but let me explain you my point.
I work for Canonical, a 100% distributed company where the majority of employees work remotely. We meet every once in a while to work together for a week, but, normally, we don’t see each other.
I joined the company a year and a half ago and, even back then, the people who had been there for more than 3 years stated “It is big now!! Do you remember when we knew the name of everybody?”. Well, Canonical is not THAT big, but it is getting harder and harder to remember people’s name and, because it is a distributed environment, people’s faces. Even harder, we rely a lot on IRC communication so you have to match a real name, with a face, and with an IRC nickname. For me this is almost impossible to achieve.
When I wrote an email I relied too much on email addresses auto-completion and this was making the problem bigger. “I think his name started with an M, and it might continue with an E, no, wait, an I. Here he is!”. I don’t do that any more. I write a good amount of emails, but not too many to not be able to spend one minute writing down the addresses it goes to.
Canonical has an internal web tool called “Directory” where you can quickly search a person (by team, name, IRC nickname, town, manager, email address, etc.) and you will soon find the record with a picture, real name, email address and IRC nickname. Then I copy and paste the email address to the “To:” field. It does the trick for me. It helps me visualizing who I am writing to and helps me matching the face with an IRC nickname, so the next time I get a ping from someone I can see the face behind.
Does your company has such a web tool? I really recommend it.
If you think that testing software is an unskilled activity that “even a two-year-old can perform”, keep reading, I’ll try to change your mind. If you do not agree with that sentence, keep reading, you may be interested in joining us.
Software testing is generally seen as the poor cousin of programming. While the bad reputation of testers happens in all software environments, this is more common in free software communities, probably because the “show me the code” motto is too deeply attached to the open source communities. This, unfortunately, is too often translated in unreliable software released with a lot of bugs (some of them critical).
Testing software, as any human activity, is a task that almost everybody can perform to some sort of proficiency. However, that does not mean that it is an unskilled activity. You have to know what to do. You need to have (or to develop), among others, excellent communication skills, technical writing skills, software architecture knowledge, technical research expertise, a critical mindset, etc.
We cannot leave quality to good luck. We cannot rely in having millions of users who will find bugs as they use the applications. Our users want to use the software, not to find bugs and report them. FOSS projects in general and Ubuntu in particular need a new way of rethinking testing as a skilled activity and an opportunity to contribute to the project.
We want to build a Testing Team in Ubuntu to try to minimize the impact of bugs in the released versions. This team would have a mailing list and regular meetings on IRC. Activities will be diverse and will include things like: formal manual testing, exploratory testing, writing new test cases, organize and conduct community testing days, automated testing and developing new tools (yes, if you like to code, there’s also a place for you).
We would love you to join us and make it happen.
We are having a session at UDS Lucid to discuss this topic (scheduled for Wednesday). You can subscribe to the blueprint as well.
This Thursday Karmic reaches the last milestone before the final release. As for every milestone, we need to test all the ISO images we produce, with every possible installation.
All of these test cases will appear, with instructions to follow, in the ISO tracker. If you don’t know how to use the tracker, this blog post will serve as starting guide.
One of the complains of the new comers is that they don’t know which test case needs testing. The coordination is done at #ubuntu-testing at Freenode and not everybody can access IRC. This time, Dave Morley and I, will try something new. As the RC images start appearing and testing begins, we are going to update in Twitter, using #ubuntutesting as tag.
If you want to help us testing RC images, please, follow us in Twitter and make sure to search for #ubuntutesting for updates. And if you’re helping testing, please, tweet about it!
Of course, this is an extra way to get informed. Coordination will happen, as usual, at #ubuntu-testing IRC channel.
Ubuntu 9.10 (Karmic Koala) Beta was released last Thursday. I am so glad to announced that we 98.9% coverage of the test cases in the ISO tracker. I would like to thank the community members that helped testing the ISOs, specially those who joined recently. Thanks! I am discussing with the Community team about the possibility of including this participation in the Ubuntu Hall Of Fame, just as the bug triagers or sponsors are.
I will blog about Release Candidate ISO testing as we approach the milestone week 
Also, and because we are getting new contributions, I would like to comment some of the reports we got, so we can improve every milestone.
We got this comment, in a test case marked as failure:
I have a tablet fujitsu p1630 and the stylus works in the life cd! great, congratulations!
(missing is the calibration tool which should be loaded. The stylus is not properly calibrated and cannot reach the top line (where the application menus sit!).[...]
In the ISO test tracker we mark as failures those experiences that prevented us to do what we want to achieve in that test case. I.e. If we want to install, and the partition manager fails, that’s a failure. If we do install (or can access to the Live environement, as in this case), the test didn’t fail as such. We would mark that as success, but will link the non-critical bugs that we find.
The lack of colour in the default options during installation could cause problems for new users.
The default setting of Mute, for sound could cause problems for new users.
These are great examples of usability bugs. Thanks for noticing them! Usability bugs are bugs, so do not only put them as comments in your report, also go and file bugs in Launchpad for them. They will help a lot to new users to understand how Ubuntu works.
Love Ubuntu? Want to help?
Karmic Beta candidate images have started to appear in the ISO tracker.
You don’t know how to use it? It is pretty easy!
As part as the Ubuntu Developer Week, I gave a Mago tutorial on how to add new test cases to available applications in the Mago library.
I have reformatted a bit the logs to make the reading easier and it is now part of the Mago documentation. Enjoy!
