Ubuntu is one of the most polished Linux distributions available, fusing the work of a global community of contributors who provide a diverse range of skills to make Ubuntu what it is.
While we all enjoy the fruits of a new Ubuntu release every six months, many people have asked the team over the years how this wide range of contributors manage to come together to build a new Ubuntu release.
In this article we're going to explain how a new Ubuntu release is made, what kind of skills and talent go into it, and what organisational structure we use to bring together this range of contributions into one cohesive unit.
Regular releases
At the heart of the Ubuntu project is a commitment to deliver a new release every six months. Unlike many software projects that identify a set of core features to deliver in a release, and who are often willing to delay the release until those features are complete, Ubuntu never releases late. If a given feature will not be ready in time for release, we bump the feature, not delay the release.
This six-month period is known as a Release Cycle and is published at the beginning of a new cycle. As an example, the current development release (Ubuntu 10.10 Maverick Meerkat) has its schedule published at http://wiki.ubuntu.com/MaverickReleaseSchedule.
The cycle is broken down into a few key components:
Freezes
A freeze is when a particular type of development must stop, typically ready for release. There are different type of freeze, such as UI Freeze (no more changes in user interface elements), string freeze (no more translations), and feature freeze (no more significant feature development).
Alphas
Throughout a release cycle we make a number of snapshot releases as the release develops. These alpha releases are sometimes incomplete and buggy (owing to their work-inprogress nature), but provide a good opportunity to target features to them.
Betas
Beta release are feature-complete releases that need a lot of testing. We often recommend the beta as a good time for testers to upgrade, stresstest Ubuntu and file bugs.
Release candidate
A release candidate comes just before the final version, and is released to spur on a final chunk of testing from the community. This six-month cycle and these different elements are present in every release, and the community is welcome to upgrade to a new development release as soon as it opens for work – though regular users may wish to wait until the later stages of development before they try the new version out.
It all begins with Debian
The way we build Ubuntu is to take source code from open source projects (known as upstreams) and upload it to a build machine in the Launchpad project hosting site that will build a package ready for installation in a Ubuntu system. These packages mesh together to form the full distro, from the kernel that boots the machine, right up to the applications you run.
The first phase of the release cycle involves bringing in new releases of upstream components into Ubuntu. To do this we import the full Debian package archive and build it for Ubuntu.
We use Debian because it's the single most effective way to keep up to date with upstream code (Debian maintainers package new upstream releases on a frequent basis, often faster than we are able to do so), and because Debian and Ubuntu are similar in many ways so their bugfixes are often bugfixes for us too.
With this core set of packages from Debian imported into Ubuntu, we then take a set of our modifications to many of the packages (known as patches), which transform the Debian package into one that looks more like Ubuntu.
As an example, the Debian packages for Gnome don't include many of the modifications we make such as default software choices, default theme, additional panel features etc. All of these patches that transform Debian packages into Ubuntu packages are freely available at http://patches.ubuntu.com.
The next step is to decide what new feature development we want to do and to build those features into the new Ubuntu development release. The Ubuntu Developer Summit Primary feature decisions and plans are made at our twice-annual Ubuntu Developer Summit, whose location alternates between the USA and Europe.
The Ubuntu Developer Summit (UDS), is an event in which we send our full Ubuntu development team, and we sponsor a significant number of community members to attend.
The week-long event is broken into nine tracks (Desktop, Server, Community, Mobile, Design, Foundations, QA, Security, and Ubuntu on ARM) each of which has a track lead who schedules sessions for each track throughout the week. These sessions are requested by Canonical staff, community members and more and are designed to provide a place to discuss and plan particular features, scoped specifically to the new release.
Throughout the full UDS week a huge range of topics are discussed, decisions are made, solutions are fleshed out, and ultimately these conclusions are documented. And thus, we move on to the blueprinting phase.
