Debian 开发者有多项职责,也是计划的正式成员,对计划的方向有极大的影响力。Debian 开发者通常至少负责一个软件包;根据其空闲时间及意愿,开发者可以自行参与众多团队和项目,并在计划内取得更多的责任。
软件包维护是相当团队性的活动、极需要记录与规范。实际上,必须与
Debian 政策 的标准相符。幸运的,很多任务具可以协助维护者的工作。因此,开发者可以集中心力在其软件包及其他复杂的工作,诸如调试。
政策,是 Debian 项目中重要的元素,它是保障该发行版软件包品质与完美互通性的纲常。正因为有政策的约束,Debian 才能在愈来愈庞大的同时依然保持一致。然而,政策并非铭刻在石不能更改,要随着
debian-policy@lists.debian.org
邮件列表中型塑出的提案不断演进。修订案在所有关注的各方有所共识后,才会被一小群没有编辑责任的维护者编写 (他们只接纳前述邮件列表内众 Debian 开发者接受的修改提案)。目前臭虫追踪系统内的修订提案在此:
政策对构建软件包的技术方面提供了广泛的覆盖。项目的规模也引发了组织上的问题;这些问题通过 Debian 宪章 来处理,该宪章建立了一个结构和决策手段。换句话说,是一个正式的治理体系。
Debian 宪章定义了一些角色和职位,以及各自的职责和权力。值得特别指出的是,通过投票决议,Debian 开发者们总是拥有最终的决定权。对于重大的修改(例如会对基金会文档产生影响的),只有当有效票数超过四分之三(75%)时,才会通过。然而,开发者们每年都会选举一位“领导人”作为他们的会议代表,同时领导人也会在内部的各个团队协调沟通。这一选举总是伴随着一段紧张激烈的讨论过程。Debian 项目领导人(
DRL)的角色并没有在任何官方文件内被定义:参选的候选人常常会提出自己对于该职位的理解和定位。在实际工作中,领导人角色包括媒体发言人,协调内部团队,对项目提供总体领导。每一位开发者都参与其中,因为大多数项目成员都认同了 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 和 Jonathan Carter。
宪章同样也定义了一个“技术委员会(technical committee)”。技术委员会的核心角色是对于那些在开发者之间尚未达成一致意见的技术事宜进行决策。除此以外,委员会则作为顾问角色,为任何无法为他们所负责的事宜作出决定的开发者提供帮助。值得一提的是,只有在相关问题方给委员会发送邀请时,委员会才会介入。
最后,宪章定义了一个“项目秘书”的职位,这一角色负责组织各种选举和决议的投票。
“通用解决方案”(
GR)的整个程序,从发起初始讨论到最终的投票计数,都在宪章里有详细的记录。其中最有趣的一部分是在真正进行投票时,开发者们需要对不同的投票选项排序,最终获胜选项的胜出方式依据
孔多塞法(更确切地说,舒尔茨法)确定。更多的细节请参阅:
即使宪法创建了表面的民主,每日的运作却大不相同:Debian 遵守自由软件的蠢蛋进化论:做事的人决定怎么做事。争论解决问题的方法只是浪费时间;被选中的解决方案将是第一个既功能性又令人满意的方案……这将源自一个有能力的人所付出的时间。
这就是升级的唯一方法:做有用的事且显示把事情做好。Debian '管理' 团体以增选方式管理,采用已有效奉献且证明其能力的志愿者。新的奉献者看到这些团队做了具有公共利益性质的工作就会主动加入协助。这就是 Debian 常被称为 '任人唯贤'。
这种有效的管理方法保证在 Debian '关键' 团队奉献者的品质。不见得是完美的且偶而凸搥。选择被团队接受的开发者是随兴的,甚至不公平的。而且,不是每个人对这些团队服务的期望是一样的。有些人受不了等8天才能收录新的 Debian 软件包,也有人耐心等待3周毫无怨言。所以,有些团队对 '服务品质' 经常不满。
有的人可能会感到奇怪,不明白为什么要在讨论 Debian 计划内工作的成员时加入用户。答案是确定的:用户在整个计划中扮演了关键的角色。其中不只有“被动”的角色,更有部分用户会日常使用 Debian 的开发版本并定期提交错误报告以指出软件的缺陷和问题。还有一部分用户会更进一步提出改进的意见,以“愿望清单(wishlist)”等级的错误报告阐述自己的观点,甚至提交对源代码的修改提议,或称为“补丁”(参见
第 1.3.2.3 节 “发送修复和补丁”)。
Debian 中提交缺陷报告的最基础工具是 Debian 缺陷跟踪系统(Debian BTS)。它在项目的许多地方都有应用。其公开部分(网页界面)可以让用户查看所报告的问题,并提供选项以根据不同的筛选条件给出一个列表。这些条件包括:受影响的软件包、问题严重性、状态、报告者的电子邮件地址、负责维护软件包人员的电子邮件地址、标签,等等。用户也可以在线浏览与这些问题相关的所有讨论的历史记录。
Debian BTS 还有其他功能特性,如使用标签标记不同的缺陷报告。如需了解更多信息,请参阅
用户也可以使用 reportbug
命令行工具为 Debian 软件包提交缺陷报告。使用该工具可以协助确保该问题尚未被其它用户报告,以此避免重复。它也可以提醒用户指明该错误的严重性,让该报告尽量精准(必要时,开发者可以后续再调整严重性参数)。它还提供自动生成报告并允许用户在此基础上进行进一步修改的功能,以此便于用户撰写完整的缺陷报告而不必了解报告的精确语法。最终生成的报告将经由电子邮件服务器送出(默认情况下使用由 Debian 提供的一个远程服务器发出,但 reportbug
也能使用本地邮件服务器)。
此工具最初针对 Debian 的开发版本设计,缺陷的修复也在开发版本上进行。自然地,Debian 的稳定发行版本则尽量不做改动;在此基础上存在一小部分例外,如安全更新或其它重要更新(例如,如果某个软件包突然完全无法工作)。因此,对 Debian 软件包中小问题的修复常常需要在下一个稳定发行版本中才能体现出来。
此外,很多对 Debian 满意的用户会为这个计划做出自己的贡献。因为不同贡献者的编程水平不尽相同,有些人会选择参与翻译与审核文档。不同语言有各自专门的邮件列表,用来协调相应的工作。
更多的进阶用户还可能通过发送补丁的方式来提供对程序问题的修复方法。
补丁是描述文件修改的文件。准确来说,包括移除或添加的代码清单,以及 (有时) 从参考文档取得的内容,用以取代修改的内文 (可以辨识取代的内容)。
修改文件的工具名为 patch
。创建补丁的工具名为 diff
,用法如下:
$
diff -u file.old file.new >file.patch
file.patch
文件包括变更 file.old
为 file.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
)所取代。在这些平台上,一旦你创建一个账户,fork一个仓库,你就马上在自己的账户里获得了该仓库的一份拷贝,然后你就可以下载仓库并把更改提交到仓库了。这时候,网页界面会建议你提交一个合并请求,让开发者知道你的更改,让他们可以方便地检查更改并可以通过点击一下就接受你的更改。
用户们不仅会在直接影响他们的技术问题上自助(并帮助他人),也会讨论向 Debian 计划做出贡献以及使得计划继续前行的好方法——这些讨论经常能得出有用的改进建议。
Debian 不仅持续自我推广,其用户在扩散方面也居功甚伟,口耳相传其名声。
这些方法运作得不错,在自由软件社区的各个层面上都有 Debian 粉丝:从本地 Linux 用户社区(
LUGs,即为“Linux 用户组”)组织的安装会(协助新手安装系统的工作坊)到大型技术会议中与 Linux 相关的展台,等等。
志愿者们制作海报、小册子、贴纸及其他的推广文宣,供社会大众取用;部分内容在 Debian 网站可自由取用:
从一开始,Debian就以源码包为基础进行组织,每个源码包都有其维护者或维护团队。随着时间的推移,许多工作团队相继出现,负责管理基础设施、处理与特定包无关的任务(质量保证、Debian政策、安装程序等)。最近一系列的团队也围绕子项目和整合项目逐渐壮大。
1.3.3.1. Debian 现有的子项目与整合
每个人都有自己的Debian!子项目是一群志愿者,他们致力于将Debian适应特定需求。除了选择适用于特定领域(教育、医疗、多媒体创作等)的程序子组,子项目还参与改进现有软件包、打包缺失的软件、调整安装程序、创建特定文档等工作。虽然“整合”可能并不完全相同,但它的工作方式相似,并且也试图为打算在特定领域使用Debian的人群提供解决方案。可以说,“Debian Pure Blends”是子项目的继任者。
这是当前已发布的一些Debian Pure Blends 的小选择:
Debian Junior,由 Ben Armstrong 制作,为儿童提供了一个有吸引力又易于使用的 Debian 系统;
Debian Edu,由 Petter Reinholdtsen 制作,专注于为学术和教育界创建专门的发行版;
Debian Med,由 Andreas Tille 制作,专供医护领域使用;
Debian Multimedia,专注于音频和多媒体工作;
Debian GIS,关注地理信息系统应用和用户;
Debian Astro,适合专业人士和业余天文学家;
Debian Science,致力于为研究人员和科学家提供更好的Debian使用体验;
Freedombox,旨在开发、设计和推广运行自由软件的个人服务器,用于隐蔽、个人通信;
Debian Games,在 Debian 中提供从街机、冒险类到模拟及策略类型的游戏;
DebiChem,目标是化学领域,提供了化学工具套装和程序。
随着Debian Pure Blends的逐步发展与优势的不断展现,可以预期子项目的数量将会不断增加。这是因为这些项目在 Debian 内进行开发并由 Debian 已有的基础设施进行支持,它们可以专注于为发行版提供额外的价值,而无需顾虑与 Debian 其余部分的同步问题。
大部分的管理团队以相对封闭的增选方式招募成员。最好的加入方法是先协助现有成员开展工作,展示出您了解该团体的目标与运作方式。
ftpmaster 管理员负责管理 Debian 软件包的官方仓库。他们维护用于接收开发者传来的软件包的程序;经过一些检查后,软件包将被保存在目标服务器上 (ftp-master.debian.org
)。
他们也检查添加软件包的授权条款,确保在纳入它们之前,Debian 有权散布它们。被要求移除的软件包,由开发者经由错误追踪系统与 ftp.debian.org '虚拟软件包' 向团队提出。
如众所期待,
Debian 系统管理员(
DSA)团队(
debian-admin@lists.debian.org
)对计划所使用的多个服务器负责。其职责包括确保所有的基础服务(DNS、Web、e-mail、shell 等)正常运作、按照 Debian 开发者的要求在机器上安装软件以及关注系统运行安全相关事宜。
listmaster 管理邮件列表的电子邮件服务器。职责包括添加名单、处理送回 (无法送出的通知)、以及垃圾邮件过滤器 (未授权的邮件)。
每个服务都有自己的管理团队,通常是设立该服务的志愿者(服务所使用工具的原作者通常也是他们)。例子有缺陷追踪系统(BTS)、软件包追踪站点,
salsa.debian.org
(GitLab 服务器,请参见侧边栏的
工具 GitLab、Git 仓库托管和相关事项)和在
qa.debian.org
、
lintian.debian.org
、
buildd.debian.org
以及
cdimage.debian.org
等服务器上的服务。
不同于管理团队,开发团队较为开放,甚至可以说是置身于奉献者之外。Debian 自身不添加软件,计划仍需要外部软件满足其需要。当然,仍是在自由软件授权下发展,这些工具使用被自由软件世界验证的方法。
Debian 发展自己的小软件,但却是重要的软件,其名声远超越 Debian 计划本身。dpkg
是个例子,它是 Debian 软件包管理程序 (事实上,它是 Debian PacKaGe 的缩写,读成 'dee-package'),另一个是 apt
,自动安装 Debian 软件包的工具,检查其相依性,保证安装后与系统一致 (其名称为 Advanced Package Tool 的缩写)。然而,它们都是由小团队撰写的,只需要高端程序技巧就能了解该程序的运作方式。
最重要的团队可能是处理 Debian 安装程序(
debian-installer
)的团队;他们自2001年问世以来完成了许多重要的任务。以一个程序提供十多种架构的 Debian 安装支持不是件简单的事,需要很多奉献者共同完成。每个架构需有自己的启动程序与引导程序。所有工作使用
debian-boot@lists.debian.org
邮件列表进行协调,在 Cyril Brulebois 领导下进行开发。
这个 (极小的) debian-cd
程序团队的目标更谦虚。由很多 '小小' 的奉献者负责其架构,因为主要的开发者无法知道全部的细微之处,也不知道从CD-ROM 安装的正确方式。