(1) Debian 项目介绍

第一章 the Debian project

在学习技术之前，让我们先了解一下什么是Debian Project，以及它的目标，理念和运作。

1.1 什么是Debain？

Debian名字起源：
截止目前，Debian不是一个缩写词。事实上，它是两个first名字的缩写：Ian Murdock和他当时的女友Debra。Debra+Ian=Debian

Debian是一个GUN/LINUX和GNU/kFreeBSD发行版本。我们将在第1.5章节讨论发行版本，但是现在，我们仅仅声明：Debian是一个完整的操作系统，它包含各种软件，软件安装系统，管理，这些都是基于Linux或FreeBSD内核和自由软件的。

1993年，Ian Murdock创建了Debian，该项目从属于FSF。Ian Murdock在Debian Manifesto中申明了该项目的明确目标，这个自由操作系统必须实现两个重要特性。第一个，高质量：Debian会被严格开发为一个能配得上Linux内核的系统；Debian会是一个非商业化的发行版，而且能够和主流商业版本竞争。因为这两个远大目标，Ian Murdock觉得，只有将Debian开发开放，才能够完成，就像Linux和GNU项目一样。同时，规模庞大的审查会持续提高产品的质量。

GNU，the project of FSF：
GNU项目包含了一系列的自由软件，它们由自由软件基金会开发或者赞助。自由软件基金会(FSF)的创始人是Richard M.Stallman博士。GNU是一个递归地缩写：“GNU is not Unix”

Richard Stallman：
他是FSF的创始人，GPL的作者，是自由软件领域的一位受人尊敬的领导者。因为坚持自由精神，所以也引起了部分反对，不过他对自由软件的贡献，则人人称赞。

1.1.1 多平台操作系统

Ian Murdock's journey：
作为Debian的创始人，Ian Murdock在1993年到1996年期间一直担任着Debian的第一位领导人。当Bruce Perens接任后，他就很少在出现在公众面前了。他回到自由软件协会工作后创建了Progeny公司，目标是为了从Debian派生出一个商业化的版本。但是悲剧的是，这次创业失败了。几年之后，这家公司仅仅提供服务支持，最终在2007年4月破产。Progeny公司起初发起的多个项目中，现在只有discover仍在活跃，它是一个硬件自动侦测工具。

遵循着起初的设计目标，如今，Debian取得了很大的成功。这个发行版体积已经变得非常庞大。它有13种架构，覆盖了11类硬件架构，包含了两个内核(Linux和FreeBSD)。此外，Debian还提供了超过17300个源码包，无论在家还是公司，只要你需要的，Debian都有提供对应的软件。

但是如果发行版体积过大，是很不方便的。试想一下，如果发行版要70个光盘才能在一个普通计算机上安装一个完全的版本，那将是极不合理的。所以，Debian日益地被看作一个原始发行版本，可以从该版本中提取并制定各种用途的版本：用于办公的Debian-Desktop，用于教育的Debian-Edu，用于医学的Debian-Med，用于儿童的Debian-Junior等等，更详细的介绍请参考1.3.3.1节。

所有的Debian工具也都在朝着这个方向发展：Debian光盘包含一套预装的软件包集合的CD-ROMs；Debian-installer也能够让用户自定义选择和安装软件包。APT安装原始版本的软件包(跟发行版安装盘中的一致)，从而保证了系统版本的一致。

Creating a Debian CD-ROM：
debian-cd创建了各种安装媒体(包含ISO镜像)。任何相关的讨论，都在debian-cd@lists.debian.org 邮件列表中能够找到。

计算机架构：
“架构”这个术语指的是一种计算机。每种架构之间的处理器不同，不能相互兼容。这种硬件上的差异，使得软件必须针对不同架构的硬件进行编译。Debain中的软件大部分都是使用可移植的编程语言编写：同样的源码可以在不同的架构中编译。事实上，一个可执行文件总是为了在特定架构上运行而编译出来的，在其他架构中无效。

1.1.2 自由软件的质量

Debain一直遵循着自由软件的条例，新的版本在成熟稳定之后才得以发布。开发人员不会被强迫限制开发期限。人们经常抱怨稳定版本发布周期太长，但是只有这种谨慎的方式才能够确保Debian的稳定可靠：对于一个发行版而言，只有经过数十个月的测试过程，才称得上稳定。Debian不会在质量上有所妥协，所有的重要BUG都会在新的版本中得到解决，甚至会因此推迟新版本的预定发布日期。

1.1.3 法律框架：一个非营利组织

从法律的角度上讲，Debain是一个由一个美国的非营利的志愿者团体管理的项目。这个项目有1000名左右的开发人员，但是，有更大数量的贡献者参与了进来（翻译人员，测试人员，艺术家，非正式开发人员等等）。

SPI机构和局部分枝：
Debian没有对应名字的服务器，因为它仅仅是SPI(Software in the Public Interest)机构唯一的项目，SPI管理着硬件和财务方面。虽然当初只是为了Debian项目创建的，但是现在，这个机构也维护了其他软件项目，尤其是PostgreSQL database,Freedesktop.org，Libre Office。

http://www.spi-inc.org/

另外，为了扩大Debian的资源，还成立了很多个当地社团协同工作，从而避免所有资源都集中在美国。它们被称谓“信任的组织机构”。这些机构的建立减少了国际上传输的成本，也符合了 Debian项目开源非营利的本质。

然而，这些机构的数量还很少，也有很多其他Debian相关的机构，这些遍布全世界的机构的目标是增强Debian：Debian France , Debian-UK,Debian-ES,debian.ch 和其他一些。赶快加入到你们当地的组织机构中去吧！

http://wiki.debian.org/Teams/Auditor/Organizations
http://france.debian.net/
http://wiki.earth.li/DebianUKSociety
http://www.debian-es.org/
http://debian.ch/

为了实现这个使命，在很多赞助商的帮助下，Debian已经有大量的服务器遍布全球。

1.2 基础文档

在项目启动的几年后，Debian被正式明确为一个自由软件项目。通过这个深思熟虑的决议，所有参与人员都向着这一方向处理，从而使得该项目有条不紊的进步着。任何开发者和申请人都要确认并证明他们支持自由软件这一准则，并且拥护Debian基础文档中的规定。

开发过程中经常需要争论，而基础文档则是被广泛，统一的支持，所以它们很少改动。Debian也规定了其他规则来保证软件的稳定性：一处修改必须要通过四分之三的有资格成员的肯定。

1.2.1 对用户的承诺

Debian项目有一个“社会契约”。这些文档难道只是面向开发人员的吗？不是的，因为Debian是服务与用户的，所以是面向社会的。这个契约概括了Debian的承诺内容，下面让我们更详细的了解：

1.Debian保持100%的自由

这是最重要的一条规则。Debian一直是并永远是完完全全的自由软件，而且，在Debian项目内的软件本身也是自由软件。

Beyond software：
第一版的Debian Social Contract中宣称“Debian将保持100%的自由”。这句话意味着Debian不仅仅在软件方面保持自由，而且在文档以及系统中提供的元素都是自由的。然而这种变化带来了很多问题，尤其是一些有问题的文档的移除。而且，随着驱动的中的固件的增加，很多硬件必须由对应的非自由固件才能正常工作。

2.任何成果都会返回到自由社区

在发行版中的任何贡献成果，都将被返回给相关作者(被称为upstream)。一般地，Debian是跟自由软件社区协同合作而不是相互独立。

upstream author,or Debian developer?：
术语"upstream author"是指完成某个工作的开发者或者说作者。然而，Debiandeveloper是将这些存在的工作放到Debian package中(用“Debian maintainer”形容更贴切点)。

实际上，这个区别非常不明显。通常，Debian maintainer也许只是为了用户写一个补丁。Debian也鼓励他们参与到相应的upstream中来。

3.不包庇任何问题

Debian不是完美的，我们每天都会发现问题需要解决。我们将一直保持着bug report数据库的开放，其他人可以查看这些report。

4.我们的重心是用户使用和自由软件

实现这种承诺是困难的。在Debian中，当需要某项决议时，不是采用实现起来简单但用户使用不便的方案，而是会倾向于更完美的方案，尽管实现可能更困难。这就意味着，Debian将用户和自由软件作为一个重心。

5.能够使用non-free软件

Debian接受并且理解那些想使用non-free软件的用户。这就是Debian项目允许发布安全的non-free软件。

for or against the non-free section?
对于维护一个容纳non-free软件的架构这个承诺，一直以来是社区里的喋喋不休的话题。反对者认为，这将使人们远离自由软件精神，与自由软件精神相悖。而支持者则宣称大多数non-free软件包是“接近自由”的，这些软件包经常有一个或两个限制(通常是商业用途方面的禁止条约)。non-free软件包在non-free分支下正常运作，这将间接地向non-free软件作者说明他们的软件会被人们更多的了解，如果被包含在主分支中，这些软件会得到更加广泛的使用。因此他们会被邀请以实现这个目标。

1.2.2 Debian自由软件的相关准则

这个参考文档定义了哪些“足够自由”软件能够被加入到Debian中。如果一个程序的执照遵循这些规则，那么它是能够被添加到main section中去的；相反的，不是自由软件但允许自由发行的软件，也许会出现在non-free section中。non-free section不属于debian官方，但其作为一个附加的服务提供给用户。

这个文档中的定义不仅仅是Debian的可选准则，还成为了free software的权威定义，是“开源的定义”的基本。从历史上说，它算是第一个free software的正式定义中的一个。

GNU许可，BSD许可和Artistic许可是传统的自由许可，它们都遵循了文档中的9点规则。下面列出了这些规则，它们同样公布在debian主页上：

https://www.debian.org/social_contract#guidelines

自由软件许可
尽管GPL许可，BSD许可和Artistic许可这些许可之间各不相同，但它们都遵循debian自由软件准则。

GNU GPL由FSF发起和维护，是最通用的一种许可。它最主要的特点是许可适用于任何derived work，也就是说，任何包含或使用GPL许可源码的程序的发行仍要遵循GPL协议。因此这样就限制了GPL许可代码的重用性。同样地，有时候将一个其他自由软件许可的软件链接一个GPL库是不可能的。另一个方面，这个许可的法律效力在美国是非常坚定的：FSF律师们参与了部分起草，他们经常强制违反许可者和睦地达成一致，避免走向法庭。

http://www.gnu.org/copyleft/gpl.html

BSD许可的限制最少：任何行为都是被允许的，包括在私有项目中修改BSD许可代码。微软甚至在BSD内核的基础上开发Windows操作系统的TCP/IP层。

http://www.opensource.org/licenses/bsd-license.php

Artistic许可是这两者的一个折中：私有项目中可以包含该许可代码，但是禁止修改。

http://www.opensource.org/licenses/artistic-license-2.0.php

在任何Debian系统中的/usr/share/common-licenses/下可以找到上述的许可说明。

    1.免费发行。Debian许可不会限制任何一方出售或赠送其中的组件，以作为包含了多个不同来源的软件中的一个组件。这个许可不会要求使用费，或者购买费用。

    2.开源。Debian程序必须包含源代码，而且允许以源码或预编译的形式发布。

    3.Derived works。GPL许可允许修改和derived works，但是必须仍旧遵循GPL许可发行。

copyleft
copyleft指的是一个准则，它使用版权来保证软件和衍生品的自由权利，而不是限制其使用。它跟术语"copyright"意思相对。Richard Stallman发现这个想法源自于他的一个朋友，发现了这个双关寓意，并在信封上写了“copyleft:all rights reversed.”寄送给了他。copyleft禁止使用GPL库的产品私有化。最出名的copyright许可有GPL，LGPL，FDL，GNU Free Documentation许可。不幸的是，通常它们互不兼容，通常，最好只使用其中一个许可。

    4.集成代码。GPL许可限制代码被修改后发布，除非在生成程序时将包含GPL许可代码的部分以“补丁”发行。许可必须显式地允许修改了代码的软件的发布。许可也许会要求derived works修改名字或者更改版本号。

    5.不区分个人和团体。GPL不区分对待任何个人和团体。

    6.不区分所在领域。GPL不区分对待使用软件的各种领域。例如，不会区别对待一个企业和遗传研究机构。

    7.程序的发布。对于GPL协议软件所具有的权限，再次发布时不需要附加其他许可即可拥有同样的权限。

    8.许可不限定于Debian。对于具有GPL许可的权限的软件，不能限定为Debian系统。其他非Debian相关的软件都应该享受同等的权限。

    9.不能影响其他软件。GPL许可不能将许可限制强加到其他一同发行的软件中去。例如，不能要求在同一种媒介发行的其他软件必须是自由软件。

Bruce Perens,一位极具争议的领导者
Bruce Perens是继Ian Murdock后的第二任Debian Project的领导人。他在管理方面备受争议。尽管如此，他仍是一位重要的Debian贡献者，对于"Debian Free Software Guidelines"(该项目来源于Ean Schuessler的一个想法)的完成有很大贡献。之后，他根据这个项目完成了"opensource definition"。
http://www.opensource.org/
Bruce Perens离开Debian十分情绪化，但是自从继续致力于Debian在政治和经济领域的发行以来，Bruce仍然一直奉献于Debian。他偶尔也会在邮件列表中提出自己的建议，表现出了他对于Debian的积极性。

1.3 Debian project的内部相互协作

许多有经验的开发人员，不管他们是个人开发还是集体开发，和大量的用户反馈信息，一起构建了Debian项目的核心“引擎”，促进着大量成果的产生。

1.3.1 Debian开发人员

Debian开发人员承担着很多责任，而且作为正式开发成员，他们更是影响着整个项目的发展。一个Debian开发人员一般要负责至少一个软件包，但根据个人的自由时间和兴趣目标的不同，他们可以自由地加入到其他小组中，从而承担起更多的责任。

http://www.debian.org/devel/people
http://www.debian.org/intro/organization
http://wiki.debian.org/Teams

开发人员数据库
Debian有一个数据库，这个数据库包含了所有注册的开发人员的相关信息(地址，电话，地理位置等)。其中一些信息在网站上公开：
http://db.debian.org/
地理位置信息可以绘制成一个列出全球所有注册开发人员的地图。可以看出，Debian 项目是一个国际化项目，开发人员遍布全球，尽管大部分集中在西方国家。

包的维护工作相对开发来说，内部协作就显得紧凑多了。事实上，这项工作必须按照Debian Policy制订的标准进行。幸运的是，有许多工具使维护工作变得容易。因此开发人员可以更加专注地将精力放到更复杂的工作中，比如解决BUG。

http://www.debian.org/doc/debian-policy/

包的维护和开发人员的工作
维护工作首先要求给程序打包。特别地，这意味着要定义如何进行安装一个程序，一旦安装完成，这个程序就可以在Debian系统中正常运作。打包的文件通常为.deb文件。有效的安装过程包含提取压缩文件和执行其中的一些安装脚本或者程序。
安装阶段完成后，就真正开始进入维护周期了。准备更新Debian Policy上最新的版本，这个版本解决了用户提交的bug，并且包含了新的“upstream”版本。例如程序安装的时候版本是1.2.3,几个月后，改程序作者发布了新的稳定版本1.4.0，那么维护人员就会及时更新该程序，使用户及时能够使用它。

这个Policy，是Debian项目中的一个基本元素，它建立了规范以确保软件包的质量和完美的发行版协调能力。正是由于它，Debian才一直保持着一致性，尽管项目规模非常庞大。这个Policy不是固定不变，一直以来都根据debian-policy@lists.debian.org邮件列表中的提议而不断完善。对于所有有兴趣的各方的同意的修改，都会被一小群没有编辑责任的维护者接受，并将这些修改更新到Policy中去。你可以到缺陷跟踪系统(bug tracking system)上的查看当前的修改建议：
http://bugs.debian.org/debian-policy

Policy涵盖了整个打包过程中的技术方面。项目规模的扩大会引起组织问题，这些问题都可以由Debian规章解决。换句话说，它就是一个正式的管理系统。这个规章(Constitution)定义了多种角色，以及赋予各种角色的责任和权利。特别地，开发人员这一角色，对于一项决议，总是有最终的决定权，只有开发人员的投票总数超过75%才能通过针对某个有较大改进的项目的决议。然而，每年各个小团体内的开发者都会选举一个领导，跟其他小组的代表一起参与决议。选举总是一个激烈讨论的过程。这种领导角色没有正式定义：应聘者会给出自己的定义。实际上，这个角色的职责包含了负责对外场合，以及内部与其他团队之间的协调关系，提供项目的全面指导，然而要达成这个愿景，必须要求组内成员可以协同起来，多数成员共同维护同一决议。尤其是这个角色有着真正的权利，他的投票能够打破平局，他的决定不受其他人干涉，也可以将部分权利或责任委托给他人。

自项目启动以来，已经有多位领导人成功领导过：Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson,Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli 和 Lucas Nussbaum。

这个规章(constitution)也定义了一个“技术委员会”。该委员会的基本角色是当开发人员之间没有在某个技术问题上达成一致时参与并制订决议，否则，委员会会为有义务却不能做出决议的开发者提供咨询。也就是说，只有在某个团体组织陷入困难的时候并邀请后，委员会才会被参与进来。

最后，规章(constitution)也定义了一位“项目秘书”，他负责各种投票工作的组织，包括各种选举和一般的决议。

“一般的决议”的举行过程，从开始讨论阶段到最后的投票统计，在规章(constitution)中都有详细描述。更多的信息请参考：

http://www.debian.org/devel/constitution.en.html

Flamewar,the discussion that catches fire
"Flamewar"是一场十分激烈的论战，一旦双方的合理争论的耐心被耗尽，他们最终很可能会互相攻击对方。一些话题总是比其他话题更频繁的出现(例如"你更喜欢vi还是emacs?"就是一个老的月经贴)。由于他们经常为了这种事情进行选择各自心中的答案，所以经常会因此快速交换各自的email。像这样的争论一般不会有什么用处。遇到这样的争论的正确的做法是，快速跳过，否则要阅读完这些无意义的争论是浪费时间的。

Debian实质上遵循自由软件的准则：谁负责谁来决定。但是大量时间用在争论孰优孰劣上面就得不偿失了，而作者的决定一般来就是最好的决定。

这是唯一的方式使开发人员努力地做出好用的产品。很多debian“行政管理”团队根据任命工作，但是更依赖于那些志愿者，他们已经做出了很多有用的贡献，并证明了他们的能力。这种方式是可行的，因为大部分团队的工作是公开的，因此，可以跟任何一个有兴趣的开发人员交流。这就是为什么Debian经常被称为“精英管理机构”。

Meritocracy,知识的统治管理
"Meritocracy“就像一个政府机构，通过权利发挥最大作用。对于Debian来说，这种方式的优势是能够判断出一个人的能力，同样地也能够通过与其接触，其他成员也能够估计出这个人的能力。他们能够一直参与开发，这本身就肯定了他们的能力。他们完成的自由软件通常伴随源码一同发布，其他人可以很方便的获取代码并审查代码，以此便可评估该开发者的能力。

这种有效的写作方式保证了Debian的贡献者的能力。但这种方法并不完美，偶尔有人不接受这种运作方式。在团队接受新成员的时候似乎有点武断，甚至是不公平的。此外，并不是每个人都跟他们的团队有相同的看法。对一些人来说，要等一个新的Debian软件包是不可接受的，而其他人会耐心地等待三个星期也没有问题。因此，经常有人对此抱怨。

和新的维护人员的融入
负责批准新成员的团队经常受到批评。必须承认的是，经过这些年的发展，Debian项目在接收新成员方面越来越苛刻。尽管许多人觉得这样有失公平，但我们必须承认，随着社区规模超过1000人的时候，要保证产品质量和统一性，变得越来越具有挑战性。因此，Debian将审批申请成员是否通过的工作交给了一个叫“Debian Account Managers”的小团队。可想而知，这个团队要特别地针对那些批评者，因为他们是专门负责审核新成员的权威机构。实际上，有时候这些申请者必须经过一段时间的熟悉操作后才能被批准成为新成员。一旦能够在成为正式成员前做出成绩的申请者才会得到当前正式成员们的认可。

1.3.2 用户扮演的角色

有人可能想知道他跟Debian项目是否密切相关，答案是肯定的，而且他们扮演了评论性的角色。一些用户会尝试开发版本，经常主动提交他们发现的BUG。还有些人甚至会提出软件的改进建议，或者直接提交修改的源码，这些代码被称为补丁。

bug追踪系统
Debian bug追踪系统(BTS)被应用到Debian项目的大部分过程中。公开部分(通过网页)允许用户访问所有提交的bug，并提供一个功能，使用户可以按照包，重要性，状态，提交报告人的地址，包维护人员的地址，标签等要素进行排序。而且也可以浏览到所有关于每个bug的讨论的历史记录。BTS的运作依赖电子邮件的交流。BTS也有其他的一些功能，例如使用标记来标签话Bug。更多信息请查阅：http://www.debian.org/Bugs/

bug严重等级
每个bug都被正式地赋值，来表明该bug的严重等级。这样就清楚的表明不是所有bug都同样的重要。例如，一个排版错误肯定没有服务器端软件的bug更严峻。Debian使用一种扩展的衡量办法来描述bug的严重等级。

另外，也有很多不会编程的普通用户也会做出自己的一些贡献，比如参与翻译或者文档的审查。下面的链接是一些非英语内容的邮件列表：
https://lists.debian.org/i18n.html
http://www.debian.org/international/

i18n和l10n
"i18n"和"l10n"分别是"internationalization"和"localization"的缩写。为了实现软件的国际化(internationalize)，或许需要重写软件以支持多种语言。而一个软件的本地话(localized)则是将默认语言转化翻译成本地化语言，所以它首先要被国际化(internationalize)。也就是说，国际化是软件多语言支持的能力，而本地化则是具体表现手段。

所有这些用户参与的贡献机制使得Debian运转的更高效。不像一群单独隔离的成员，用户群里就像一个真正的社区，在这个社区中发生着很多改进。这里我们自然而然的想起了起着很大作用的邮件列表：debian-user@lists.debian.org。

用户不仅在直接影响到他们的技术问题上给予贡献，他们还会讨论最好的贡献方式，从而推动Debian的发展。

因为Debian不在宣传上面花费资金，所以它的用户就成了一个关键的角色，帮助推广Debian。

这种方法的效果很不错，因为Debian粉丝遍及各种自由软件社区：从涉及安装的小型社区到大型linux技术论坛等。

有志愿者制作出了很多海报(poster),brochures, stickers,和其他一些有用的物品，来帮助其他用户认识Debian：
https://www.debian.org/events/material

1.3.3 团队和子项目

已存在的子项目

对于对Debian感兴趣的人来说，一个子项目是由一群对某个Debian方面有兴趣的志愿者组成的。除了在特定领域的相关子项目外，子项目也会参与一些改善现有的包，packaging missing software，adapting the installer,创建特定文档以及其他的工作。

子项目与衍生发行版
一个衍生的发行版本的产生导致了一个特殊Debian版本的开始，但是这个发行版的相关工作跟Debian项目已经没有关系了。这个不同之处解释了为什么衍生版本和原始版本是分歧的，衍生版本要经常地重新同步源码以便从原始版本中获得好处。总之，子项目不能跟Debian项目分离，因为它们的目的是为了改进和完善Debian，实现某个特定的目标。最著名的衍生版毫无疑问是ubuntu，当然还有其他很多版本。

下面列出了一部分子项目：

• Debian-Junior，由Ben Armstrong发起，目标是针对少年群体提供一个有趣易用的系统；
• Debian-Edu，由Petter Reinholdtsen发起，致力于创建适用于教育行业的系统；
• Debian Med, 由Andreas Tille发起, 致力于一个用于医疗行业的系统；
• Debian-Multimedia, 由Agnula的创建者发起, 致力于创建一个多媒体版本系统；
• Debian-Desktop,由Colin Walters发起,致力于桌面；
• Debian-Ham, 由Bruce Perens创建, 服务于业余的无线电爱好者；
• Debian-NP ，服务于非营利组织机构；
• Debian-Lex, 服务于法律领域；

这份列表会随着时间继续增长，进而增强由Debian子项目带来的魅力。现在的Debian项目工作机制架构，能够完全满足这种需求，各个子项目只需要关心各自的特殊功能，而不用太担心项目的同步，因为它们同属一个Deian框架内。

Debian与学术界
Debian-Edu起初是一个法国人创建的项目，它由téphane Casset和Raphaël Hertzog发起，作为他们在Logidée工作的一部分，并代表一个教学文档部门中心。之后Raphaël将它整合为Debian的一个子项目。但是由于时间限制，它并没有得到很快的发展，因为自由软件项目总是缺少贡献者。

Debian与多媒体
Agnula是一个在意大利团队管理下的欧洲项目。由于“DeMuDi”部分，它必然会使得开发精力集中在多媒体应用程序上。一些该项目的成员，尤其是Marco Trevisani，为了继续发展这个版本，就把它整合进了Debian项目。Debian-Multimedia子项目就这样诞生了。
https://wiki.debian.org/DebianMultimedia
然而，这个子项目的发展却颇为不顺，项目成员的开发成果都以一个Debian衍生版本(指64Studio发行版)的形式提供。现在这个发行版由一个新的公司提供技术支持。
http://www.64studio.com/

管理团队

大多数管理团队相对封闭，仅仅通过内定方式来吸收新成员。其他人想要成为其中一员的最好办法是聪明地帮助成员，向他证明你已经理解他们的目标和操作方法。

FTP上的管理员负责所有的官方Debian包的组织管理。他们维护着一个程序，这个程序会接收由开发者发出的包，并做出一些检查工作后自动存储它们，这些过程都在 ftp-master.debian.org服务器上进行。

在纳入新的待发布的包的时候，他们必须校验这些包的许可证以确保它们的合法性。当开发者想移除某个有BUG的包时，他们会通过bug追踪系统和“pseudo-package”通知这个团队。

Debian系统管理员（DSA）团队(debian-admin@lists.debian.org)，正如人们所料，他们是负责Debian项目所使用的服务器的系统管理。他们确保所有功能(DNS，Web，电子邮件，shell等)的最佳运作状态，也负责安装由开发者请求的软件，并采取一切防范措施来确保服务器的安全。
https://dsa.debian.org/

每一个具体的服务有其自己的管理团队，通常由参与该服务的志愿者组成。像这样的例子有：bug tracking system (BTS), the package tracking system (PTS), alioth.debian.org, 在qa.debian.org上的可用的服务, lintian.debian.org, buildd.debian.org, cdimage.debian.org等。

开发团队，transversal(?)团队

不像管理团队一样封闭，开发团队是很开放的。尽管Debian项目不是一项职业工作，但要实现Debian的目标必须完成大量的指定软件。当然了，由于遵循自由软件许可，就可以大量采用相应许可的自由软件。

CVS
CVS (Concurrent Versions System)是一个用于多用户协同工作的工具，它能够保存所有的修改操作。一般操作的文件是文本文件，如源码文件。如果不同的人对同一个文件做出了修改，那么CVS将会对不同部分的修改进行合并。但是如果是同一部分有多个修改，那么就会产生冲突，解决冲突必须手动解决。CVS通过记录每行的内容来实现版本管理。

Debian开发了自己的软件，有些软件不仅仅自己使用，而且已经扩散到非Debian项目中去。一个好的例子是dpkg,Debian包管理程序，还有apt，一个自动安装任何包和管理包之间的依赖关系的工具。这些团队的规模一般很小，因为这些团队要求成员必须有很高的编程能力，理解这些程序的所有操作。

当中最重要的团队可能是为Debian安装程序，debian-installer，自从2001这个项目启动以来，至今已经完成了绝大部分。写的一个可以安装多种不同的架构的安装程序是非常困难的，因此它需要大量的贡献者。每种架构都有自己的启动机制和bootloader。这些工作是在Joey Hess和Cyril Brulebois的指导方向下进行，可以在debian-boot@lists.debian.org邮件列表中查看这些信息。

https://www.debian.org/devel/debian-installer/
http://joeyh.name/blog/entry/d-i_retrospective/

然而debian-cd团队的任务就小多了，他们自己负责程序的架构设计，因为主要的核心开发者不可能要了解所以细节。

通常很多团队间需要协同合作：debian-qa@lists.debian.org，例如为了保证Debian项目整体的质量。debian-policy@lists.debian.org邮箱根据各个地方的提议，用于列表改进Debian Policy。负责每种架构的团队(debian-architecture@lists.debian.org)根据自己的需要，也许会编译所有的包，以适用于各自的架构中。

还有其他的团队，管理着其他重要的包，这样做可以减轻一个团队的压力；比如说C库，C编译器和Xorg等。

1.4 Follow Debian News

正如前面所提到过的，Debian的发展是以版本发布为节点的，这样会导致一个结果：可能有时候为了了解发生了什么改变，就必须面对海量的信息通知。

如果你仅仅是想了解重要的信息，那么你可能需要订阅debian-announce@lists.debian.org列表。这个列表每年只会发布十几条重要通知，例如有新的stable版本，新的项目领导人的选举，年度Debian大会等。

更多点的一般性消息通知会被发送到 debian-news@lists.debian.org列表。这个列表上的信息量也不多，每个月会有不多的消息发布。这个列表也包含了发生在Debian项目中的各种小事情的新闻。因为所有的Debian开发者觉得他们需要公开一些信息的时候，他们就可以发布这些信息，所以DPN给了用户木群体很丰富的信息。

关于Debian的发展演化的更多信息和在某个时间点发生在某个团队的事情，都在debian-devel-announce@lists.debian.org列表上面发布。由这个名字来看，它发布的信息可能使开发者对其更有兴趣，但它也允许感兴趣的第三方关注一些具体情况，而非仅仅当一个稳定版本发布的时候的一些信息。

一个非正式的信息来源也可以在Planet Debian找到，这里聚集着Debian贡献者在各自的博客上发表的文章。这些内容不光有开发相关的信息，也有社区里发生的事情以及一些成员在做些什么。

http://planet.debian.org/

在互联网中也存在一些其他的Debian相关的信息。很多Debian贡献者都开通了Twitter ，Facebook,Google+等，但在自由软件平台中，只有唯一的一个官方存在。

https://identi.ca/debian

https://twitter.com/debian

https://www.facebook.com/debian

https://plus.google.com/111711190057359692089

1.5 The Role of Distributions

一个GNU/Linux发行版有两个主要目标：安装自由的操作系统和提供用户所需要的各种自由软件。

1.5.1 debian-installer

debian-installer的设计十分模块化，它的目标是提供一个尽可能通用的安装程序。它囊括了很多安装场景，对于一个具体的安装需求都能够满足。

由于模块化的设计，会导致安装程序设计的过于复杂，这样可能会使开发者对其望而生畏；但是无论是图形界面还是文本界面，用户的操作经验都是相似的。Debian已做出了巨大的努力，使用户在安装的时候减少了大量的疑问，其中很大部分要归功于硬件自动侦测软件。

有意思的一点是派生于Debian的发行版在这方面却很不相同，它们提供了有限的安装(只提供i386和amd64架构)，而非Debian那样用户友好。另一方面，它们仍会跟随Debian的脚步，以免脱离太远会引起各种问题。

1.5.2 The Software Library

从数量上来说，在自由软件数量方面上，Debian无疑是这方面的领导者，拥有超过17300的源码包。Debian的政策和很长的测试周期证明了它有资格被冠以稳定性和一致性的美誉。遍布全球的很多镜像服务器每6个小时都会更新，上面的一切东西都是可用的。

有很多软件零售商会在网络上低价出售CD-ROMs，但这样做有个缺点：如果新的稳定版本发布周期很长的话，就不能及时包含新的软件了。

多数新的自由软件都能够被包含进开发版本中，如果因为包的依赖太多而更改太多的时候，这些软件也可以在稳定版本中重新编译。

1.6 Lifecycle of a Release

Debian每次发布会同时发布3个或4个不同的版本：Experimental, Unstable, Testing和Stable。每种都对应着软件的不同的开发阶段。为了更好地理解，让我们一起深入了解程序开发的整个周期。

release
在Debian中，属于release是指一个特定的发行版本，它也表明了一个新的稳定版本的发布。/p>

1.6.1 实验版本

首先我们先看一下实验性质的发行版的具体情况：它包含大量的还在开发过程中的软件包，这些包没有完全开发完毕，其作者是为了获得用户的使用反馈和意见。当然了，并不是所有的软件都要经过这一步骤。另外，实验版本中存在很多修改，如果将这些修改整合到Unstable版本中可能会有糟糕的问题。因此，只有将其完全隔离在一个版本中，才能不会把问题传染到其他版本中去。实验版本也不是什么软件都有，它只包含了一部分软件包，而且通常不包含Debian的基础系统。因此，这个版本跟其他版本组合起来的时候很有用，例如Unstable版本。

1.6.2 不稳定版本

让我们再回过头来看看典型的软件包。当开发者完成了Unstable版本的软件包后，将其放在ftp-master.debian.org服务器中。之后要经过审查以及ftp服务器管理员的验证，才能在unstable版本中使用该软件。选择使用unstable版本的用户更关心的是新的软件而不是各种各样的bug，他们探寻到软件并测试它。如果他们使用过程中遇到了Bug,就会提交给软件维护人员，维护人员会定期更新新版本到服务器上。

新版本软件都会在六小时内更新到全世界的所有镜像网站中，然后用户测试并找出可能由更改导致的问题。版本更新可能发生的很快，这些工作可以由autobuilder机器人来完成。通常，软件维护人员会在传统PC上编译i386/amd64架构；自动编译机器人会自动编译其他架构的版本。有些可能会发生失败，如果失败，软件维护人员将会收到描述错误的bug，当Bug被发现后，可能会通过一个补丁来解决。

buildd
buildd是“build daemon”的缩写。它能够自动重新编译新版本的debian软件包，这个软件的架构跟随主机的架构(跨平台版本编译总是不尽人意)。

1.6.3 迁移到测试版本

在加入unstable版本之后，软件包会趋于成熟；然后重新编译所有架构版本，不用再担心修改可能带来的问题，之后就成为了Testing版本的备选软件包。一个程序会每天自动选择软件并将其包含进Testing中，选择的依据有：

• 1.很少的bug，或者比当前Testing版本中的版本bug更少；
• 2.至少在Unstable版本中存放10天，以保证有足够的时间去让用户发现问题；
• 3.能够在所有官方支持的架构中编译成功；
• 4.软件依赖的库也能够被迁移到Testing版本中；

Testing版本并不意味着就没有问题；用户也会定期地发现各种Bug。但是它比unstable版本bug少多了，更加稳定。对于想尝试新版本的用户来说是一个相对折中的选择。

Testing版本的一些限制
虽然非常讲究原则，但Testing版本还是会遇到问题：包之间的交叉依赖，以至于软件包很少独立的就能完成完全安装。有时一个软家包需要迁移大量的依赖包到Tesing中，但是其中的一些包可能很少定期更新。另一方面，标识着这些依赖包的脚本很难创建它们。这就是为什么我们需要在安装过程中手动操作，指导用户需要什么样的依赖包。

发布管理者
发布管理者肩负着很大的责任，是一个重要的职位。管理者必须有效的管理新的稳定版本的发布，并定义Testing版本的发展过程，直到它符合发布稳定版本的质量要求。他们有时候也会定义一些计划安排，但通常未被实行过。 也存在稳定版本发布管理者，通常缩写为SRM，他们选择并进行更新到当前稳定版本。他们会按照严格步骤来加入安全补丁，以及检查其他的申请，比如开发者希望更新他们的新版本软件包。

1.6.4 测试到稳定版本

我们假定我们的软件包现在被包含在稳定版本中。只要包含进稳定版本后，软件的维护者必须持续地进行维护更新，并重新开始从Unstable版本中迁移的过程。当软件没有问题的时候，维护人员就编译这些软件，然后就将其包含进稳定版本中去，其实这些软件是经过Release Manager筛选的，跟同时刻的Testing版本中的软件一致。理想情况下，这种决策的制定的时候，installer可用，并且Testing中不存在任何已知的bugs。

因为这种理想的情况从没有出现过，实际上Debian必须采取妥协的处理办法：移除维护者不能准时解决bug的软件，同意发行在大量的软件中仍旧存在一些bugs的版本。Release Manager会有一个冻结阶段，在这个时期内，Testing中的软件的更新必须被证实其正确性。这样做的目的是屏蔽任何新的软件版本，仅仅验证已有的更新是否已经解决了Bugs。

冻结阶段：冲刺阶段
在这个阶段，暂时阻塞Testing发行版软件的开发，软件更新被禁止，除了Release Managers。目的是为了防止新的版本会带来新的bug；另一方面，验证已有更新是否解决了那些重要的bugs。

当一个新的稳定版本发布后，Stable Release Manager会继续管理后续开发版本(称为 “revisions”,例如5.0.1,5.0.2是版本5.0的修正版本)。这些更新会包含所有的安全补丁。它们也会包含一些重要的软件修改。

现在，我们的假象的包已经被包含到了稳定版本中了。以上所描述的Debian的这种发布路线，解释了分为不同版本直至到稳定版本的原因。这种过程保证了Debian的整体质量。多数用户满意他们能够使用三个同时可用的发行版中的一个。系统管理员只关心服务器的稳定性，他们不需要最新的GNOME，那么他们可以选择稳定版本，这样就能满足他们。普通用户对最新的GNOME或KDE更感兴趣而非稳定性，那么他们可以选择测试版本，该版本在软件的版本和稳定性方面比较均衡。最后，一些开发者和有经验的用户可能会选择不稳定版本，他们冒着被各种Bug困扰的风险，测试新的软件版本。每一类用户都有其适合的版本。