Category Archives: canonical

things I enjoy doing and am getting paid for at the same time

Welcome to the HUD

Today we are releasing one of the first projects I was involved in and I wanted to share some of the goodness with you.

One of the first topics in my new job was a project called HUD. The project has been talked about in length and design have been created, reviewed and started over again. It wasn’t until last UDS-P when I sat with the whole team to grasp the full scope and potential of HUD. Mark is describing his vision about a new generation of application interfaces in his current blog post and I am excited to be part of such a change.

It took the team only a little while to come up with a first prototype and the first responses were promising. After a few iterations of tuning and reviews we got to a stage where we were comfortable talking to the Ubuntu Platform team about including it into 12.04. Like every other component that is targeted for inclusion into Ubuntu, we are on our way to adhering to Ubuntu’s Acceptance Criteria.

On the technical side we had to make a few tough decisions:

  • Usability vs Privacy: in order to provide the best user experience we wanted to show the user only the content that matters to him. Next to some heuristics, this is done by keeping track of which actions are used most frequently. We understand that this is a privacy concern to some and thus we decided to make this option configurable (via com.canonical.indicator.appmenu.hud.store-usage-data).
  • Invocation: which key or key combination is appropriate to invoke menu actions? The current decision is to simply tap ALT to invoke the HUD.
  • Tuning: the prediction is based on the Levenshtein distance and will need some tweaking as we learn more about HUD’s interaction with other languages. We are exporting a few key parameters under com.canonical.indicator.appmenu.hud.search and invite people to report their findings.
While the team is working on integrating HUD into the upcoming Ubuntu 12.04 release you can get a preview on Youtube or download the packages from the PPA. Feel free to grab the sources from here and here.
The current release is headed towards more widespread testing and exposure and we are keen to get your feedback specifically on i18n issues and the preciseness of the prediction algorithm.

[UPDATE]: fixed 12.4 to 12.04 typo

A commitment to Quality

A lot of good things are currently happening around Quality in Ubuntu. Rick just introduced us to all the efforts the Ubuntu team is working on (Upstream Testing, Acceptance Testing, daily ISO builds and integration tests, automated daily Smoke Test …). Jono has hired a Community QA Coordinator to be the interface between Ubuntu, its community and everybody who is interested in the quality of Ubuntu. Pete has put together a strong Ubuntu QA team and is still increasing its capacity. It is amazing to see how the Platform and Unity teams are working together to make Ubuntu 12.4  the best LTS release ever.

The Unity Quality Team

However, Canonical’s commitment to Quality extends further than addressing quality where Ubuntu is being put together. As a sponsor to upstream projects of Ubuntu, we understand our responsibility that we have for these projects. With that in mind I am happy to update you on our commitment to Quality in the Unity team.

The Unity project will receive help from a dedicated Quality Team which we are currently ramping up. The team consists of various functions that are critical to provide well crafted code.

Alex, Allan, Thomi and Thomas in their role as Quality Engineers are working closely with the Unity Software Engineers. Their main priority is to support their assigned components in creating test frameworks and automated tests, work on integration tests and help us measure the performance of our projects. We are still looking at growing this team!

Omer and Bilal, our Bug Triagers are the first line of defense between our engineering teams and 20 Million users. This powerful team is connecting the dots between a filed defect report and the responsible engineer and is helping us in facilitating the defect management process. Let me know if you would like to participate.

Martin in his role as Quality Lead will be coordinating the efforts between the various engineering teams and the Quality team. He will be defining metrics and targets and his opinion will be sought to determine whether a component is ready to be released.

Open to everybody

With Unity being an open source project the Quality Team is going to follow suit and will work with the community wherever possible. Check out the Ubuntu fridge in January for dates for our Quality meeting, where the team will be giving updates on Unity testing, present test tools and methodologies and discuss Quality questions with everyone who is interested.  We have also started a blog, the Quality Hour, where we will update you with what’s going on in the team. With increasing demand, we are also looking at setting up a dedicated mailing list, but for now we are watching the Ayatana mailing list

Everybody is part of the Quality Team

High quality software is not the product of an individual software engineer nor of the Quality Team but it is the outcome of joint efforts of the whole software engineering team. The desire to produce something great, to produce manageable and maintainable code, the readiness to steadily review and improve test functionality and a commitment to quality is the base for a solid product. The Quality Team is a catalyst as they support the software engineers in getting quality straight into the foundation of our products. It is very exciting to see how the team approaches quality and I wanted to share a few examples of this joint effort with you.

  • Inspired by Thomas’ and Allan’s work on code coverage, Ted went ahead and looked at the code coverage for one of his test suites.  Unhappy with the results he sat down to implement more tests and testability hooks and bumped the coverage by 15%  for line coverage, 8% for function coverage and 22% for branch coverage.
  • Gerry is working on Testability, a test suite that will help us to drive automated GUI tests in Unity 2d
  • Thomas and Chase looked at improving the automated tests for the uTouch stack and needed a way to run tests in a headless X server. The outcome is a sweet little X.org google test extension, which allows to write tests that instrument a dummy or running X server.
  • Alex and others from the Unity and Platform team have been heads down in getting Autopilot v2 for Unity 3d up an running. Autopilot is one of the key tools of the continuous integration testing that Unity releases are put through.
  • Mirco has gone off and defined a process for how to handle design assets in Launchpad and bzr
The list could go on and on and I wanted to thank everybody (Didier, Sebastien, Ken, Evan, Tim, Jay, Neil, Sam, Robert, Martin, everyone who is currently integrating automated tests in projects, everyone who is writing regression tests for fixed bugs or new features… and everyone else whom I hereby forgot) who is putting in extra work to make this happen! You guys rock!