Precision and Reliability in Ubuntu Accomplishments

222

In the Ubuntu world we have some common values that are not just focused on freedom, but also in how we build Ubuntu. Values such as cadence, design, quality and precision help guide us in building the best Ubuntu that we can.

These values continued to be common themes at the recent Ubuntu Developer Summit in California. Today our culture continues to involve important integration work that is a rich and interesting challenge, but this work has also been augmented by us building assurances around Ubuntu too; assurances such as regular releases (cadence), the reliability and quality of the experience (quality), and attention to detail in both design and engineering (precision) are all examples of the strong balance of predictability and innovation that we want to bring.

These values are not limited to Ubuntu though: we want Ubuntu to be a platform where you can get the very best software experience, whether you are using Open Source or commercial applications. In a nutshell, we want to take the lessons we have been learning regarding cadence, design, quality and precision and share them with our upstreams. This is going to be a big chunk of what Michael Hall will be focusing on in the coming months.

One upstream project though that I am actively involved in in my spare time is Ubuntu Accomplishments and I wanted to share some of our plans surrounding our next 0.2 release and how these values are forming an important core of this work. Before I continue though, I just want to say a huge thank-you to everyone who has been participating in Ubuntu Accomplishments. Ever since our 0.1 release a few weeks ago we have had over 180 people start using this very early PPA and a number of people have started contributing accomplishments. Thanks to all of you!

Quality

With the expanded number of accomplishments being contributed, I started thinking last week about how we could perform better testing around these contributions as well as daily testing reports; I wanted to ensure that our project, even though we are very young and small, demonstrates a level of quality that we can be proud of. To kick this off, this weekend I wrote a small tool called battery that helps us assure quality. I created a validation test for every accomplishment and battery runs all the accomplishments and feeds them this data that will cause an accomplishment to succeed as well as fail. This serves a few valuable purposes:

  • We now have better testing for new contributions and we can test both success and failure more effectively.
  • We can build testing into the accomplishment submission process so that when someone contributes an accomplishment we will ask them to also submit a test file (the test file is extremely simple and just specifies data used for success and data used for failure). This should take a contributor ten seconds to put together.
  • Finally, we can now run battery in an automated environment every day and have it alert us when one of the tests fails. This gives us better visibility on our accomplishments collections to ensure that we can assure quality and resolve issues quickly.

As an important part of building good design into the system, battery was designed to not require any changes to the existing accomplishments sets and require a bare minimum from our contributors who should be spending more time having fun writing accomplishments than caring about tests. I am delighted with the results.

The Road To 0.2

In addition to helping to ensure the accomplishment contribution process is simple (see our list of ideas for accomplishments and how to create them), we have been planning the 0.2 release. This will continue to focus on refinements and building a strong, reliable platform for both community and local accomplishments…

Read more at jonobacon@home