系列：Ubuntu开发（一）

正文：

本文是介绍UD（Ubuntu开发）的系列文章（一）。Ubuntu开发在一定程度上，并不要求大量的背景知识和熟悉掌握每步的概念、步骤、工具和架构。如果文章有误，敬请指出，以便修正。

Ubuntu 开发简介

Ubuntu是由许多不同程序语言、成千上万个部件组成的。每个组件，或是软件库、或是工具、或是图形化应用，都可以获得源码包（source package）。源码包一般情况下包括：真正的源码、元数据。元数据包括：包依赖、版权和协议信息、打包说明。一旦源码包编译完成后，构建过程就会提供二进制包，.deb文件用户就可以安装了。

每次应用的新版本发布，或有人修改了Ubuntu的源码，源码包必须上传到“Launchpad 构建器”（Launchpad’s build machines） 完成编译。生成的二进制包然后分发到归档文件和不同国家的镜像文件中。文件/etc/apt/sources.list里面的URL指向归档文件或镜像。每天，Ubuntu各版本的CD 镜像文件都会被构建。Ubuntu Destktop、Ubuntu Server,Kubuntu等其他版本都会指定CD上获得所需的软件包列表。这些CD 镜像文件 然后用来作为安装测试，为下一版本发布提供反馈。

Ubuntu 开发很大程度上 依赖 现处的发布周期阶段。Ubuntu每6个月发布一新版本，这些日期早被定的死死的。每个发布日期临近，需要开发者们尽量的少改动、少修改。发布周期约进行到一半时，进行“功能冻结”。在该阶段，功能会得到大幅完善。发布周期剩下的时间主要围绕修补bug展开。用户界面、文档、内核等等都逐渐冻结。紧接着，就会推出beta版本，接受用户的测试。从beta版本开始，只修复严重的bug，接着发布RC版本。如果RC版本没有什么大问题，就发布最新Ubuntu版本了。

如图：

几千个源码包，十多亿行代码，几百个贡献者必须进行大量的交流和规划制定，以获得高质量。在每个发行周期开始，都会举行“Ubuntu 开发者峰会”。Ubuntu开发者和贡献者们汇聚一堂，规划下一个版本的功能特点。大家都会在每个功能特点进行讨论和规范（比如关于假设、完善的详细信息，哪些地方需要做出必要的改动、如何测试等等问题）。上述讨论和规范制定都是在开放、透明的环境下进行，即使你没有亲临大会现场，你也可以远程参与，与与会者交流，提交自己的想法，时刻与大会保持同步。

会上并不讨论每个变动，主要是Ubuntu也得依赖其他项目。所以贡献者们要及时的保持联系。大多数团队或项目都使用邮件列表，这样可以有效避免一些无关的提议。为了更及时的合作，开发者们和贡献者们使用IRC交流。所有的讨论都是开放和公开进行的。

另一个重要的交流的工具，就是bug报告。无论什么时候，软件包或架构中的缺陷被发现后，都要在Launchpad上提交bug报告。所有的信息，无论大小，都在bug报告中。这在工作流中是一个非常有效地工具。

大家Ubuntu上安装的很多软件，并不是Ubuntu开发者自己写的。这些软件多数是其他开源项目开发者完成的，然后移植到Ubuntu来。这些项目称作“上游”（Upstream）,因为他们的源码流入Ubuntu，我们只是移植了下。对Ubuntu来说，与“上游”的关系对Ubuntu来说很重要。Ubuntu要从”上游”获取源码，“上游”也要从Ubuntu得到用户、bug报告和补丁。

Ubuntu最重要的“上游”就是Debian。Ubuntu就是基于Debian版本，很多软件包架构的决策也是来自Debian。一般说来，Debian 有专门的维护者或维护团队来负责每个软件包。Ubuntu下也有团队对某些软件包感兴趣，当然，每个开发者各有专长，同时，对每个“下游”的同学来说也是开放的，只要你能担当，有热情，有毅力。

(英文部分，看起来很易懂，写出来很费力，文章太长）

Getting a change into Ubuntu as a new contributor is not as daunting as it seems and can be a very rewarding experience. It is not only about learning something new and exciting, but also about sharing the solution and solving a problem for millions of users out there.

Open Source Development happens in a distributed world with different goals and different areas of focus. For example there might be the case that a particular Upstream might be interested in working on a new big feature while Ubuntu, because of the tight release schedule, might be interested in shipping a solid version with just an additional bug fix. That is why we make use of “Distributed Development”, where code is being worked on in various branches that are merged with each other after code reviews and sufficient discussion.

In the example mentioned above it would make sense to ship Ubuntu with the existing version of the project, add the bugfix, get it into Upstream for their next release and ship that (if suitable) in the next Ubuntu release. It would be the best possible compromise and a situation where everybody wins.

To fix a bug in Ubuntu, you would first get the source code for the package, then work on the fix, document it so it is easy to understand for other developers and users, then build the package to test it. After you have tested it, you can easily propose the change to be included in the current Ubuntu development release. A developer with upload rights will review it for you and then get it integrated into Ubuntu.

When trying to find a solution it is usually a good idea to check with Upstream and see if the problem (or a possible solution) is known already and, if not, do your best to make the solution a concerted effort.

Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream.

The most important requirements for success in Ubuntu development are: having a knack for “making things work again,” not being afraid to read documentation and ask questions, being a team player and enjoying some detective work.

Good places to ask your questions are ubuntu-motu-mentors@lists.ubuntu.com and #ubuntu-motu on irc.freenode.net. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software.