How ubuntu is created

Ubuntu Community Manager explains how to create a popular distribution.
Ubuntu is one of the most honed Linux distributions available, using the work of the global community, sponsors that provide a large number of people and their skills to make Ubuntu what it is now.

While we all enjoy the benefits of the new Ubuntu release every six months, many people ask the team over the years how this large number of “volunteers” manage to create a new Ubuntu release.
')
In this article, we are going to explain how the new release of Ubuntu is being done, what skills and talents are being used and what organizational structure we use to combine this set of contributions into one related module.

Regular issues

At the core of the Ubuntu project is a commitment to deliver a new release every six months. Unlike many software projects that are ready to delay release, while some features are not ready, Ubuntu is never late with the releases. If some function is not ready for release, we begin to actively work on the implementation of this function, without delaying the next release.

This six-month development and preparation period is known as the Release Cycle and is published at the beginning of a new cycle. As an example, the current development release (Ubuntu 10.10) is published on this page.

The cycle is divided into several key components:

Freezing

Freezing is when a certain type of development must stop, usually ready for release. There are various types of freezing, such as “UI freezing” (changes in user interface elements) and freezing functions.

Alpha

Throughout the release cycle, we do a lot of snapshot releases as the release is being developed. These alpha versions are sometimes incomplete and error-prone (due to the fact that they are in the process of development), but provide a good opportunity to get acquainted with the features of the release.

Beta

Beta version - issues with completed features that need a lot of testing. We often recommend beta for updating testers to a stress test, for example.

Release Version

The pre-release version appears just before the final version, and is released to encourage users on the final testing unit.

It all starts with Debian

To create a Ubuntu package, you need to take the source code from open source projects (known as upstream) and upload it to the build machine in a project that will create a package ready for installation on Ubuntu. These packages mesh together to form a complete distro - from the kernel that boots the machine, right down to the applications you run.

The first phase of the release cycle includes the introduction of new upstream releases in Ubuntu. To do this, we import the complete archive of the Debian package and create it for Ubuntu.

We use Debian because it is the only most effective way to improve with upstream code and because Debian and Ubuntu are very similar: for example, fixing bugs (bugfixes) for Debian are the same fixes for Ubuntu.

With this basic set of packages from Debian imported into Ubuntu, we take a number of our modifications to many of the packages (known as patches) that convert a Debian package to one that is more like Ubuntu.

As an example, the Debian packages for Gnome do not include many of the modifications we make, such as: default software options, default theme, additional panel features, etc. All these patches, which convert Debian packages to Ubuntu packages, are freely available at patches.ubuntu.com .

The next step is to decide which new development or feature we want to do and embed these developments in the new Ubuntu release. Major decisions are made at the Ubuntu Developer Summit, the location of which varies between the United States and Europe.

The Ubuntu Developers Summit (UDS) is an event in which we send our full Ubuntu development team, and we sponsor a significant number of community members to monitor the development progress.

The weekly event is divided into nine stages (Desktop version, Server version, Community, Mobile, Projects, Basics, QA, Security and Ubuntu on ARM), each of which has a schedule that designates sessions for each stage during the week. These sessions are in demand by Canonical staff, community members and organized to provide a place where you can discuss and plan some features that define the context of the new release.

For a whole week, a huge number of topics are discussed at the summit, decisions are made, everything is presented in detail, and ultimately the output of this is all documented.

After this session at the Summit, where a specific feature was discussed, this feature is registered in a special place - on the Launchpad, the entry on the Launchpad outlines the purpose of the function and the reference to the specification. The specification is a wiki page on wiki.ubuntu.com , which fully outlines a plan for what problem the function solves and how it should be implemented.

Most specifications include the following information:

Summary - What the function does (feature).
Explanation - Why we need a function.
Use Cases - Typical examples that describe its functionality in general terms.
Context - What elements of the function will be completed within the loop.
Project - The project itself works on this function.
Implementation Plan - How the implementation works and what work has been done.
Unsolved Issues - Any unresolved issues.

With this registered project, which points to a specification with a full statement of the essence of the function, anyone in the community can easily see the full range of features that are being discussed for the next Ubuntu release.