Every six months we release a new version of Ubuntu. Each one brings together hundreds of developers, translators, testers and documentation writers to integrate the latest and greatest upstream applications, as well as new and innovative Ubuntu technologies.
Building and releasing a new operating system every six months is hectic. Really hectic. However, since 2004, when we founded the project, we've striven to get the very best out of everyone who participates in building Ubuntu, ensuring that each release is as good as it can be.
This article explains how this organised chaos works and provides an insight into how Ubuntu is put together. Everything is encased in a rigorous release cycle, made up of a series of important milestones, which are always publicly available. Let's get started by looking at the start of a new cycle.
Casting the net
Before we even start the new release, and while we're still putting the finishing touches to the previous version, we start performing a requirements gathering exercise. The teams at Canonical reach out to different stakeholders and the community to see what the next release should focus on.
What new features does Ubuntu need? What problems require fixing? Which use cases should we support? This process results in a laundry list of needs that we start to sort into prioritised areas of focus.
At the same time, we're coordinating the structure of the next Ubuntu Developer Summit. This face-to-face event happens a few weeks into the start of every new release cycle. We send almost all of Canonical's Ubuntu engineers and sponsor a number of key community members to join us. The event is open to everyone, and many business representatives join in as well.
At the Ubuntu Developer Summit we have 14 tracks covering different themes and we schedule open discussion sessions for the various areas of focus. The goal of every session is to discuss the topic, and make and document decisions and assigned actions in public blueprints. These are web pages that we use to track the work on the features in an open and transparent way. You can see the interface at http://status.ubuntu.com for the next Ubuntu release.
The first task we need to tackle in a new cycle is getting the toolchain finalised. The toolchain is the core set of developer tools used to build software for the release. This deep and dirty low-level work is performed first, and then we synchronise the Debian Unstable archive with this toolchain. This effectively builds all Debian packages against the toolchain, so we have Debian Unstable in our Ubuntu developer repository.
When this sync is complete, Ubuntu developers start applying the hundreds of Ubuntu patches to these packages that transform Debian Unstable into Ubuntu. At this point, we have a developer version of Ubuntu that looks and feels like our last release, but built against the new Debian packages and using our toolchain. Now the real work can begin.
Catch of the day
Over the following months, the developer community starts working on the features and goals agreed upon at the Ubuntu Developer Summit. Progress is made every day: developers triage and prioritise bugs, fix them, and upload fixes to the archive. New features are developed, packaged and uploaded, as well.
Each day, when an Ubuntu developer wakes up, he or she will update their system to pull in the latest packages, and then start work on their features and bugs. Typically, this workflow involves looking at the current bug list and at the highest priority bugs and resolving those, while working on the feature goals for the cycle. This feature work often involves cherry-picking specific features from upstreams that are of interest, or creating the code for these new features and building them into the release.
An important piece of this is the new development work that goes into the Ayatana project with Unity, the indicators and other innovative desktop functionality. This work is broken into two primary teams: the Design team designs the functionality based around user needs, and the Desktop team uses these designs to write the code to implement them.
Regular releases
When the Desktop Experience team make a release, they send the code to the Ubuntu Desktop Engineering team, who then package it and upload it to the archive, where everyone can run and test the new code.
In each release, we strive to have a new Desktop Experience team release at least once a week (usually Thursday). This weekly deadline has been useful for regular progress. Throughout this period, we release development versions of Ubuntu that we encourage the community to test, file bugs on and help improve.
Alpha 1 is shortly after the new release cycle opens and includes the new Debian packages with merges included. Alpha 2 is when you typically start seeing significant new features. Alpha 3 is usually released a few months before the final Alpha and just before Feature Freeze.
At Feature Freeze, we lock the release down so no big new features are allowed in and all developer time is focused instead on refining what's already there. This milestone effectively switches gear from cramming in new and untested features to building quality into what we already have.
