Product SiteDocumentation Site

1.3. Debian 项目的内部工作

从有经验的 Debian 开发者、Debian 软件包里的个别或集体作品、以及用户的回馈,Debian 计划产出丰富的结果。

1.3.1. Debian 开发者

Debian 开发者有多项职责,也是计划的正式成员,对计划的方向有极大的影响力。Debian 开发者通常至少负责一个软件包;根据其空闲时间及意愿,开发者可以自行参与其他团队并在计划内取得更多的责任。
软件包维护是相当团队性、需要文档化甚至规范化的活动。实际上,必须与 Debian 政策 的标准相符。幸运的是,很多工具可以协助维护者的工作。因此,开发者可以集中心力在其软件包及其他更复杂的工作,诸如调试上。
政策,是 Debian 项目中重要的元素,它是保障该发行版软件包品质与完美互通性的纲常。正因为有政策的约束,Debian 才能在愈来愈庞大的同时依然保持一致。然而,政策并非铭刻在石不能更改,它随着 邮件列表中提出的提案不断演进。修订案在所有关注的各方有所共识后,才会被一小群没有编辑责任的维护者编写 (他们只是纳入前述邮件列表内众 Debian 开发者接受的修改提案)。目前修订提案可以在缺陷追踪系统查看:
政策含包装的技术细节。计划的大小也引发组织的问题;由 Debian 宪法处理,即创建决策的结构与方法。换句话说,就是正式的治理系统。
Debian 宪章定义了一些角色和职位,以及各自的职责和权力。值得特别指出的是,通过投票决议,Debian 开发者们总是拥有最终的决定权。对于重大的修改(例如会对基金会文档产生影响的),只有当有效票数超过四分之三(75%)时,才会通过。然而,开发者们每年都会选举一位“领导人”作为他们的会议代表,同时领导人也会在内部的各个团队协调沟通。这一选举总是伴随着一段紧张激烈的讨论过程。领导人的角色并没有在任何官方文件内被定义:参选的候选人常常会提出自己对于该职位的理解和定位。在实际工作中,领导人角色包括媒体发言人,协调内部团队,对项目提供总体领导。每一位开发者都参与其中,因为大多数项目成员都认同了 Debian 项目领导人的观点。
特别的,领导人拥有真正的特权;他们的投票可以解决票数相等的问题;他们可以对某个尚未归属于任何人管辖名下的事件作出决定,同时可以将他们自己的一部分职责委托他人代为执行。
自发起以来,项目已经经过了 Ian Murdock,Bruce Perens,Ian Jackson,Wichert Akkerman,Ben Collins,Bdale Garbee,Martin Michlmayr,Branden Robinson,Anthony Towns,SamHocevar,Steve Mclntyre,Stefano Zacchiroli,Lucas Nussbaum,Mehdi Dogguy,Chris Lamb 和 Sam Hartman 的成功领导。
宪章同样也定义了一个“技术委员会(technical committee)”。技术委员会的核心角色是对于那些在开发者之间尚未达成一致意见的技术事宜进行决策。除此以外,委员会则作为顾问角色,为任何无法为他们所负责的事宜作出决定的开发者提供帮助。值得一提的是,只有在相关问题方给委员会发送邀请时,委员会才会介入。
最后,宪章定义了一个“项目秘书”的职位,这一角色负责组织各种选举和决议的投票。
“通用解决方案”的整个程序,从发起讨论到最终的投票计数,都在宪章里有详细的记录。其中最有趣的一部分是在真正进行投票时,开发者们需要对不同的投票选项排序,最终获胜选项的胜出方式依据 孔多塞法(更确切地说,舒尔茨法)确定。更多的细节请参阅:
即使宪法创建了表面的民主,每日的运作却大不相同:Debian 遵守自由软件的蠢蛋进化论:做事的人决定怎么做事。争论解决问题的方法只是浪费时间;选择有用且满意的方案才是王道…有能力的人就是这么做。
这就是升级的唯一方法:做有用的事且显示把事情做好。Debian '管理' 团体以增选方式管理,采用已有效奉献且证明其能力的志愿者。新的奉献者看到这些团队做了具有公共利益性质的工作就会主动加入协助。这就是 Debian 常被称为 '任人唯贤'。
这种有效的管理方法保证在 Debian '关键' 团队奉献者的品质。不见得是完美的且偶而凸搥。选择被团队接受的开发者是随兴的,甚至不公平的。而且,不是每个人对这些团队服务的期望是一样的。有些人受不了等8天才能收录新的 Debian 软件包,也有人耐心等待3周毫无怨言。所以,有些团队对 '服务品质' 经常不满。

1.3.2. 用户的积极角色

有的人可能会感到奇怪,不明白为什么要在讨论 Debian 计划内工作的成员时加入用户。答案是确定的:用户在整个计划中扮演了关键的角色。其中不只有“被动”的角色,更有部分用户会日常使用 Debian 的开发版本并定期提交错误报告以指出软件的缺陷和问题。还有一部分用户会更进一步提出改进的意见,以“愿望清单(wishlist)”等级的错误报告阐述自己的观点,甚至提交对源代码的修改提议,或称为“补丁”(参见 第 1.3.2.3 节 “发送修复和补丁”)。

1.3.2.1. 提交缺陷报告

Debian 中提交缺陷报告的最基础工具是 Debian 缺陷跟踪系统(Debian BTS)。它在项目的许多地方都有应用。其公开部分(网页界面)可以让用户查看所报告的问题,并提供选项以根据不同的筛选条件给出一个列表。这些条件包括:受影响的软件包、问题严重性、状态、报告者的电子邮件地址、负责维护软件包人员的电子邮件地址、标签,等等。用户也可以在线浏览与这些问题相关的所有讨论的历史记录。
表层下的 Debian BTS 系统以电子邮件为基础:保存参与者寄发的电子邮件做为信息。发送给 的电子邮件,将被指定为编号 12345 的错误。有权限的人可以叙明理由寄发另个电子邮件 '关闭' (表示该错误已解决或无关紧要) 该错误。新的错误应以指定的格式辨识有问题的软件包再发送电子邮件给 。这个信箱 用于编辑与该错误有关的所有“元信息”。
Debian BTS 还有其他功能特性,如使用标签标记不同的缺陷报告。如需了解更多信息,请参阅
用户也可以使用 reportbug 命令行工具为 Debian 软件包提交缺陷报告。使用该工具可以协助确保该问题尚未被其它用户报告,以此避免重复。它也可以提醒用户指明该错误的严重性,让该报告尽量精准(必要时,开发者可以后续再调整严重性参数)。它还提供自动生成报告并允许用户在此基础上进行进一步修改的功能,以此便于用户撰写完整的缺陷报告而不必了解报告的精确语法。最终生成的报告将经由电子邮件服务器送出(默认情况下使用由 Debian 提供的一个远程服务器发出,但 reportbug 也能使用本地邮件服务器)。
此工具最初针对 Debian 的开发版本设计,缺陷的修复也在开发版本上进行。自然地,Debian 的稳定发行版本则尽量不做改动;在此基础上存在一小部分例外,如安全更新或其它重要更新(例如,如果某个软件包突然完全无法工作)。因此,对 Debian 软件包中小问题的修复常常需要在下一个稳定发行版本中才能体现出来。

1.3.2.2. 翻译和文档

此外,很多对 Debian 满意的用户会为这个计划做出自己的贡献。因为不同贡献者的编程水平不尽相同,有些人会选择参与翻译与审核文档。不同语言有各自专门的邮件列表,用来协调相应的工作。

1.3.2.3. 发送修复和补丁

更多的进阶用户还可能通过发送补丁的方式来提供对程序问题的修复方法。
补丁是描述文件修改的文件。准确来说,包括移除或添加的代码清单,以及 (有时) 从参考文档取得的内容,用以取代修改的内文 (可以辨识取代的内容)。
修改该等文件的工具名称就是 patch。添加为 diff,用法如下:
$ diff -u file.old file.new >file.patch
file.patch 文件包括变更 file.oldfile.new 的指令。可以发送给其他人,用于从两个文件添加 file.new,如:
$ patch -p0 file.old <file.patch
现在,此文件 file.old 内容等同于 file.new
实践中,大部分软件都一 Git 仓库维护,因而贡献者更有可能是通过 git 来获取源代码和建议更新。git diff可以生成与diff -u同样格式的文件,git apply 可以完成 patch命令的操作。
虽然git diff命令的输出文件也可以直接分享给其他开发者,但通常还有更好的办法提交更改。如果开发者偏向于通过邮件获取补丁,他们通常希望获得git format-patch生成的补丁,这样他们就能直接用git am命令将更改整合到仓库中。这种做法保留了提交的元数据,也让同时分享多个提交成为可能。
基于邮件的工作流程仍然很流行,但它的使用正在逐渐被merge requests(或pull requests,只要软件是由 GitHub 或 GitLab 类似的平台托管——Debian 使用 GitLab 服务器alsa.debian.org)所取代。在这些平台上,一旦你创建一个账户,folk一个仓库,你就马上在自己的账户里获得了该仓库的一份拷贝,然后你就可以下载仓库并把更改提交到仓库了。这时候,网页界面会建议你提交一个合并请求,让开发者知道你的更改,让他们可以方便地检查更改并可以通过点击一下就接受你的更改。

1.3.2.4. 其他贡献的方式

正是随着用户的不断参与,这些贡献途径才能越来越有效。用户并不仅仅是孤立的个体所组成的一个集合,用户们实际上是一个真正的社区,伴随着个体之间持续的信息交换。我们尤其注意到我们的用户邮件列表,,有十分活跃的交流活动。(第 7 章 问题的解决与相关信息的检索 一节对此有详细描述。)
用户们不仅会在直接影响他们的技术问题上自助(并帮助他人),也会讨论向 Debian 计划做出贡献以及使得计划继续前行的好方法——这些讨论经常能得出有用的改进建议。
Debian 不仅持续自我推广,其用户在扩散方面也居功甚伟,口耳相传其名声。
这些方法运作得不错,在自由软件社区的各个层面上都有 Debian 粉丝:从本地 Linux 用户社区(LUGs,即为“Linux 用户组”)组织的安装会(协助新手安装系统的工作坊)到大型技术会议中与 Linux 相关的展台,等等。
志愿者们制作海报、小册子、贴纸及其他的推广文宣,供社会大众取用;部分内容在 Debian 网站可自由取用:

1.3.3. 团队与子计划

Debian 从开始就以源代码的概念组织起来,每个软件包都有维护者。随时出现新的工作团队,于子计划内形成新的团队,确保基础建设的管理,以及流程运作不会被特定的软件包绑住 (品质保证、Debian 政策、安装器等)。

1.3.3.1. Debian 现有的子计划

每个 Debian 子计划是一群志愿者修改 Debian 供特定需求之用。选择部分程序供特定领域 (教育、医学、多媒体制作等) 使用之外,子计划的目标还包括改进现有的软件包、包装漏失的软件、调整安装器、添加特定的文档,等等。
目前较流行的子计划:
  • Debian Jr.,由 Ben Armstrong 制作,为儿童用户提供了有吸引力又易于使用的 Debian 系统;
  • Debian Edu,由 Petter Reinholdtsen 制作,专注于提供针对学术领域优化的发行版本;
  • Debian Med,由 Andreas Tille 制作,专供医护领域使用;
  • Debian Multimedia 针对音效与多媒体的工作;
  • Debian GIS 照顾地理信息系统应用程序与用户;
  • Debian Accessibility,专注于改进 Debian 以满足残障人士的需求;
  • Debian Science,终于,致力于为使用 Debian 的研究者和科学家提供更好的体验。
  • DebiChem,目标是化学领域,提供了化学工具套装和程序。
随着 Debian 子项目的逐步发展与优势的不断展现,可以预期子项目的数量将会不断增加。这是因为这些项目在 Debian 内进行开发并由 Debian 已有的基础设施进行支持,它们可以专注于为发行版提供额外的价值,而无需顾虑与 Debian 其余部分的同步问题。

1.3.3.2. 管理团队

大部分的管理团队以相对封闭的增选方式招募成员。最好的加入方法是先协助现有成员开展工作,展示出您了解该团体的目标与运作方式。
ftpmaster 管理员负责管理 Debian 软件包的官方仓库。他们维护用于接收开发者传来的软件包的程序;经过一些检查后,软件包将被保存在目标服务器上 (ftp-master.debian.org)。
他们也检查添加软件包的授权条款,确保在纳入它们之前,Debian 有权散布它们。被要求移除的软件包,由开发者经由错误追踪系统与 ftp.debian.org '虚拟软件包' 向团队提出。
如众所期待,Debian 系统管理员DSA)团队()对计划所使用的多个服务器负责。其职责包括确保所有的基础服务(DNS、Web、e-mail、shell 等)正常运作、按照 Debian 开发者的要求在机器上安装软件以及关注系统运行安全相关事宜。
名单大师 管理邮件列表的电子邮件服务器。职责包括添加名单、处理送回 (无法送出的育知)、以及垃圾邮件过滤器 (未授权的批次邮件)。
每个服务都有自己的管理团队,通常是设立该服务的志愿者(服务所使用工具的原作者通常也是他们)。例子有缺陷追踪系统(BTS)、软件包追踪站点(package tracker)、salsa.debian.org(GitLab 服务器,请参见侧边栏的 工具 GitLab、Git 仓库托管和相关事项)和在 qa.debian.orglintian.debian.orgbuildd.debian.org 以及 cdimage.debian.org 等服务器上的服务。

1.3.3.3. 发展团队、转换团队

不同于管理团队,发展团队较为开放,甚至可以说是置身于奉献者之外。Debian 自身不添加软件,计划仍需要外部软件满足其需要。当然,仍是在自由软件授权下发展,这些工具使用被自由软件世界验证的方法。
Debian 发展自己的小软件,但却是重要的软件,其名声远超越 Debian 计划本身。dpkg 是个例子,它是 Debian 软件包管理程序 (事实上,它是 Debian PacKaGe 的缩写,读成 'dee-package'),另一个是 apt,自动安装 Debian 软件包的工具,检查其相依性,保证安装后与系统一致 (其名称为 Advanced Package Tool 的缩写)。然而,它们都是由小团队撰写的,只需要高端程序技巧就能了解该等程序的运作方式。
最重要的团队可能是处理 Debian 安装程序(debian-installer)的团队;他们自2001年问世以来完成了许多重要的任务。以一个程序提供十多种架构的 Debian 安装支持不是件简单的事,需要很多奉献者共同完成。每个架构需有自己的启动程序与引导程序。所有工作使用 邮件列表进行协调,在 Cyril Brulebois 领导下进行开发。
这个 (极小的) debian-cd 程序团队的目标更谦虚。由很多 '小小' 的奉献者负责其架构,因为主要的开发者无法知道全部的细微之处,也不知道从CD-ROM 安装的正确方式。
需要多个团队彼此合作才能够将程序包装起来:以 为例,企图保证 Debian 计划的每个层面都达到既定的品质。 根据各地的建议列出 Debian 政策。负责每个架构的团队 () 编绎所有的软件包,若有需要,再改编供特定架构使用。
其他的团队管理最重要的软件包以免重担放在单一团队的肩上;在 C 程序库与 ,C 编绎器 邮件列表,或 Xorg 在 (此社区以 X Strike Force 闻名)。