Sponsored Link

This quirky scheme of adjectives and animals presents a pretty puzzle every six months. What mix of characteristics do we want to celebrate in the next release? Here we are, busily finalizing the precise pangolin (which was a rather perfect product placement for a scaly anteater, all things considered) and before one realises it’s time to talk turkey, so to speak, about Q! Our code names may raise a quizzical eyebrow here and there, but they capture the zeitgeist of a cycle and shape our discussions in surprising ways. The quest for a name has no quick answer unless, of course, you jump to the last paragraph 😉
12.04 being an LTS we’ve been minding our P’s and Q’s, but many of our quality-oriented practices from 12.04 LTS will continue into Q territory. We’ll keep the platform usable throughout the cycle, because that helped hugely to encourage daily use of the release, which in turn gives us much better feedback on questions of quality. And we’ll ratchet up the continuous integration, smoke testing and automated benchmarking of the release, since we can do it all in the cloud. We have, so to speak, stacks and stacks of cloud to use. So quality is quotidian rather than quarterly. And it is both qualitative and quantitative, with user research and testing continuing to shape our design decisions. The effort we put into polishing Unity and the rest of the platform in 12.04 seem to have paid off handsomely, with many quondam quarrelsome suddenly quiescent in the face of a surge in support for the work.

But the finest quality is that without a name, so support for “quality” as a codename would at best be qualified. Every release has quality first these days – they all get used, on the server, on devices, and while the term of maintenance might vary, our commitment to interim releases is just as important as that to an LTS.

Our focus on quality permeates from the platform up to the code we write upstream, and our choices of upstream components too. We require tests and gated trunks for all Canonical codebases, and prefer upstreams that share the same values. Quality starts at the source, it’s not something that can be patched in after the fact. And I’m delighted that we have many upstreams using our tools to improve their quality too! We have awesome tools for daily builds from branches, continuous integration support in Launchpad, the ability to provide a gated trunk with tests run in the cloud for projects that really care about quality. Rumours and allegations of a move from Upstart to SystemD are unfounded: Upstart has a huge battery of tests, the competition has virtually none. Upstart knows everything it wants to be, the competition wants to be everything. Quality comes from focus and clarity of purpose, it comes from careful design and rigorous practices. After a review by the Ubuntu Foundations team our course is clear: we’re committed to Upstart, it’s the better choice for a modern init, innit. For our future on cloud and client, Upstart is crisp, clean and correct. It will be a pleasure to share all the Upstart-enablement patches we carry with other family friends as soon as their release is ready and they can take a breath, so to speak.