我的书签
添加书签
移除书签1.3. Debian 项目的内部工作
从有经验的 Debian 开发者、Debian 软件包里的个别或集体作品、以及用户的回馈，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 的数据库包括所有登记有案的开发者、及其相关信息 (地址、电话、经纬度等地理信息)。部分数据 (姓名、国家、计划内使用的名称、IRC 名称、GnuPG 钥匙等) 系公开在网页上。
地理信息用于创建开发者在全球的分布地图。Debian 是真正的国际计划：虽然主要在 ‘西方国家’，其开发者确实遍布各大洲。
图 1.1. Debian 开发者遍布全球
软件包维护是相当团队性的活动、极需要记录与规范。实际上，必须与 Debian 政策 的标准相符。幸运的，很多任务具可以协助维护者的工作。因此，开发者可以集中心力在其软件包及其他复杂的工作，诸如调试。
→ http://www.debian.org/doc/debian-policy/
回到起点 包的维护，开发者的工作
维护软件包，表示 ‘包装’ 程序。特别是，定义安装的方法，以便在安装之后，此程序可以依照 Debian 计划设置的规则运作并兼容于 Debian 计划。其结果是保存在一个 .deb 文件内。有效果的程序安装不需要解压缩文件也不需要预安装或再安装其中的脚本。
过了初始阶段后，才真正开始维护流程：依照最新版的 Debian 政策准备更新，修正读者报告的错误，并包括新的程序 ‘上游’ 版本以备继续同步发展。例如，初次包装后，版本命名为 1.2.3。几个月之后，原著者发布新的稳定版，编号为 1.4.0。此时，Debian 维护者应更新软件包，用户才能取得最新的稳定版。
政策，是 Debian 项目中重要的元素，它是保障该发行版软件包品质与完美互通性的纲常。正因为有政策的约束，Debian 才能在愈来愈庞大的同时依然保持一致。然而，政策并非铭刻在石不能更改，要随着 [debian-policy@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-policy@lists.debian.org) 邮件列表中型塑出的提案不断演进。修订案在所有关注的各方有所共识后，才会被一小群没有编辑责任的维护者编写 (他们只接纳前述邮件列表内众 Debian 开发者接受的修改提案)。目前臭虫追踪系统内的修订提案在此：
→ http://bugs.debian.org/debian-policy
社区 政策的编辑流程
任何人都可以通过对debian-policy 包提交严重性为“愿望”的漏洞来申请修改 Debian 政策的新提议。随后的流程可以在/usr/share/doc/debian-policy/Process.html中找到：如果所揭示的问题需要通过在 Debian 政策中添加新的条款来解决，那么在 [debian-policy@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-policy@lists.debian.org)邮件列表上就会开始对此进行讨论。当达成一致意见后，就会产生一个新提议。一份新起草的政策修正条款会被提交审阅（以补丁的方式）。只要当有两名其他开发者认为，新起草的修改条款和之前讨论的内容保持一致（他们支持这一新修正条款），那么这一提议就会被某一位debian-policy 包维护者更新进正式的文件中。如果这一流程在上述的任一阶段失败了，那么维护者就会关闭这一漏洞，注明该提案被拒绝。
DEBIAN 政策 文档
每一个包的说明文档保存在/usr/share/doc/*软件包名称*/路径下。这一目录通常包含一个README.Debian文件。该文件描述了包维护者为Debian所做的特定调整。因此，在做任何配置前最好先读一下这个文件，从包维护者的经验中获益。我们还可以找到一个名为changelog.Debian.gz的文件，它描述了Debian维护者在各个软件包版本之间所做的更改。请不要将这个文件和changelog.gz文件（或类似名称的文件）混淆，后者是由上游开发者提供的，描述了上游的修订日志。copyright文件包含了软件作者和软件适用的授权条款的信息。最后，我们还可能找到名为NEWS.Debian.gz的文件，Debian开发者可以使用它发布有关更新的重要信息；如果apt-listchanges已在系统上安装，则这些信息将在更新时自动显示。所有其它的文件都和特定的软件包相关。我们特别指出可能存在名为examples的子目录，它通常包含了配置文件的示例。
政策含包装的技术细节。计划的大小也引发组织的问题；由 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 的成功领导。
宪章同样也定义了一个“技术委员会（technical committee）”。技术委员会的核心角色是对于那些在开发者之间尚未达成一致意见的技术事宜进行决策。除此以外，委员会则作为顾问角色，为任何无法为他们所负责的事宜作出决定的开发者提供帮助。值得一提的是，只有在相关问题方给委员会发送邀请时，委员会才会介入。
最后，宪章定义了一个“项目秘书”的职位，这一角色负责组织各种选举和决议的投票。
‘争议’ 进程在宪法中详列，从最初的讨论阶段至最后的计票。详情见：
→ http://www.debian.org/devel/constitution.en.html
文化网络舌战，引爆侮辱性攻击的讨论
‘发火’ 是极度不理性的争辩，双方都穷尽理论的辩论后转向人身攻击。部分议题较为论战式 (选择文本编辑器，’喜欢 vi 或 emacs？’，永远没有结论)。由于单方面 (每个人) 快速地交换电子邮件形成优势且极度地个人化此等议题。
这种讨论没什么特别；通常要远离这种争论，或者快速地略过其内容，因为阅读它们太费时了。
即使宪法创建了表面的民主，每日的运作却大不相同：Debian 遵守自由软件的蠢蛋进化论：做事的人决定怎么做事。争论解决问题的方法只是浪费时间；选择有用且满意的方案才是王道…有能力的人就是这么做。
这就是升级的唯一方法：做有用的事且显示把事情做好。Debian ‘管理’ 团体以增选方式管理，采用已有效奉献且证明其能力的志愿者。新的奉献者看到这些团队做了具有公共利益性质的工作就会主动加入协助。这就是 Debian 常被称为 ‘任人唯贤’。
文化 任人唯贤，统治知识
任人唯贤是治理的型式之一由有能力的人当家。在 Debian 里，长才由胜任衡量，也就是由过去的其他计划的行为评鉴现在 (前任领导人 Stefano Zacchiroli 提出 ‘蠢蛋进化论’，意指 ‘授权能把事性做好的人’)。
这种有效的管理方法保证在 Debian ‘关键’ 团队奉献者的品质。不见得是完美的且偶而凸搥。选择被团队接受的开发者是随兴的，甚至不公平的。而且，不是每个人对这些团队服务的期望是一样的。有些人受不了等8天才能收录新的 Debian 软件包，也有人耐心等待3周毫无怨言。所以，有些团队对 ‘服务品质’ 经常不满。
社区 新维护者的整合
负责批准新开发者加入事项的团队是最经常受到批评的。人们需要承认的是，经过多年的发展，Debian 项目开始变得越来越因为需求而去接纳一些程序员。一些人可能会在其中看见一些不公正的情况，但我们必须要承认的是，当一个超过 1000 人的社区需要去保证它所提供给用户的所有东西的质量与完整性时，这会比它在刚刚起步的时候要有挑战的多。
此外，由 Debian 客户经理这样一小群团队审核接受的进程 。特别容易被批评，因为在 Debian 开发者社区里说接受或拒绝的就是他们。实务上，必须多花点时间了解才能接受。当然，我们可以在被接受为正式的开发者前，先支持既有的开发者，做出实质的奉献。
1.3.2. 用户的积极角色
或许奇怪，需要在讨论 Debian 计划内工作者时加入用户，答案是必须的：用户扮演关键的角色。不只是 ‘被动’ 的角色，有些用户运行发展版并定期报告指定问题的错误。其他的人更深一层提出改进的意见，以 ‘愿望清单’ 或送出称为 ‘补丁’ 的修正后源代码 (见专栏 基础 补丁，送出修订)。
工具 缺陷跟踪系统
Debian 缺陷跟踪系统（Debian BTS）在项目的许多地方都有应用。其公开部分（网页界面）可以让用户查看所报告的问题，并提供选项以根据不同的筛选条件给出一个列表。这些条件包括：受影响的软件包、问题严重性、状态、报告者的电子邮件地址、负责维护软件包人员的电子邮件地址、标签，等等。用户也可以在线浏览与这些问题相关的所有讨论的历史记录。
表层下的 Debian BTS，以电子邮件为基础：保存参与者寄发的电子邮件做为信息。发送给[12345@bugs.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:12345@bugs.debian.org) 的电子邮件，将被指定为编号 12345 的错误。有权限的人可以叙明理由寄发另个电子邮件 [12345-done@bugs.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:12345-done@bugs.debian.org) ‘关闭’ (表示该错误已解决或无关紧要) 该错误。新的错误应以指定的格式辨识有问题的软件包再发送电子邮件给 [submit@bugs.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:submit@bugs.debian.org)。这个信箱 [control@bugs.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:control@bugs.debian.org) 用于编辑与该错误有关的所有 ‘中介信息’。
Debian BTS 还有其他功能特点，如添加错误标签时标记的使用。更多信息，参阅
词汇表 错误的严重度
报告问题时指定该错误的严重性。不是每个错误都具有相同的重要性；例如，手册内容的打字错误不能与服务器软件的安全漏洞相提并论。
Debian 以相当广泛的尺度描述错误的严重性。每级都有精准的定义以协助后续的解决选择。
→ http://www.debian.org/Bugs/Developer#severities
此外，很多对 Debian 满意的用户愿意奉献给这个计划。每个人撰写程序的能力不尽相同，有些人参与翻译与审核文档。有专门的不同语言的邮件列表来协调稳定翻译和审核工作。
→ https://lists.debian.org/i18n.html
→ http://www.debian.org/international/
基础 什么是 i18n 与 l10n？
‘i18n’ 与 ‘l10n’ 是国际化英文本 ‘internationalization’ 与本地化英文本 ‘localization’ 的缩写，保留第一个与最后一个字母，再加入省略字母的字数。
‘国际化’ 一个程序包括修改至可以翻译 (本地化) 的程度。涉及重写程序以便公开给所有的语系使用。
‘本地化’ 一个程序包括翻译原语言 (通常是英文) 为另一种语言。因此，必须先国际化。
总之，国际化系把软件整备至可翻译的程度，然后再运行本地化。
基础 补丁，送出修订
补丁是描述文件修改的文件。准确来说，包括移除或添加的代码清单，以及 (有时) 从参考文档取得的内容，用以取代修改的内文 (可以辨识取代的内容)。
修改该等文件的工具名称就是 patch。添加为 diff，用法如下：
$
file.patch 文件包括变更 file.old 为 file.new 的指令。可以发送给其他人，用于从两个文件添加 file.new，如：
$
现在，此文件 file.old 内容等同于 file.new。
工具 以 reportbug 报告错误
reportbug 是送出 Debian 软件包错误报告的工具。用于确认有问题的错误尚未被报告，避免重复报告。提醒用户指明该错误的严重性，让该报告尽量精准 (必要时，开发者可以调整严重性参数)。撰写并允许他人编辑它，用户就不必以精准的语法撰写完整的错误报告。再经由电子邮件服务器送出此报告 (缺省为本地，但 reportbug 也能使用远程服务器)。
此工具原先系供发展版使用，做为修正错误之用。后来发现，Debian 的稳定版也需要它，安全更新或重要更新 (或完全无效的软件包)。因此，Debian 软件包的次要错误的修订，在下个稳定版才纳入。
靠着用户的参与这些奉献愈来愈有效。不断地交换消息，用户不是孤立的个人而是一个真正的社区。从邮件列表里，[debian-user@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-user@lists.debian.org) (第 7 章 问题的解决与相关信息的检索 可看出详情)。
用户不仅自助 (也助人) 于直接影响他们的技术面，也讨论奉献 Debian 计划的最佳途径与协助其向前行 — 经常出现改进的建议。
Debian 不仅持续自我推广，其用户在扩散方面也居功甚伟，口耳相传其名声。
这些方法运作的不错，在自由软件的各个层面都有 Debian 粉丝：从本地 ‘Linux 用户社区’ LUGs 组织的安装会 (协助新手安装系统的工作坊)，到 Linux 相关的技术会议等。
志愿者制作海报、小册、贴纸及其他的推广文宣，供社会大众取用，部分内容在 Debian 网站可自由取用：
→ http://www.debian.org/events/material
1.3.3. 团队与子计划
Debian 从开始就以源代码的概念组织起来，每个软件包都有维护者。随时出现新的工作团队，于子计划内形成新的团队，确保基础建设的管理，以及流程运作不会被特定的软件包绑住 (品质保证、Debian 政策、安装器等)。
1.3.3.1. Debian 现有的子计划
每个 Debian 子计划是一群志愿者修改 Debian 供特定需求之用。选择部分程序供特定领域 (教育、医学、多媒体制作等) 使用之外，子计划的目标还包括改进现有的软件包、包装漏失的软件、调整安装器、添加特定的文档，等等。
术语 子项目与衍生发行版
所谓衍生发行版的开发进程，系根据某一特定版本的 Debian 做为起点，接着进行各种改造而成。其成品作成之基础建设完全在 Debian 项目之外。衍生版也不必有回馈自身改善的政策。这就是为何衍生发行版会「偏离」原版，并且必须定期与原版同步以便获取上游来的改善成果。
另一方面，子计划也可以不偏离，因为所有的作品直接取自改进的 Debian 以满足及自身需要。
Debian 的众多衍生发行版中，无庸置疑，最知名的当是 Ubuntu。请见 附录 A, 衍生发行版 了解其特点，及其与 Debian 间的地位关系。
目前较流行的子计划：
Debian-Junior，由 Ben Armstrong 制作，给儿童使用;
Debian-Edu，由 Petter Reinholdtsen 制作，针对学术圈的专门发行版;
Debian Med，由 Andreas Tille 制作，专供医护领域使用;
Debian Multimedia 针对音效与多媒体的工作;
Debian-Desktop 针对桌面与艺术作品的默认主题;
Debian GIS 照顾地理信息系统应用程序与用户;
Debian Accessibility，最后但也最重要，改良 Debian 满足身心障碍者的需求。
随着 Debian 子计划的成长此清单将愈来愈长。由 Debian 基础建设完全支撑，可以全然关注在加值部分，不需担心与 Debian 同步的问题，因为他们在 Debian 计划内发展。
1.3.3.2. 管理团队
大部分的管理团体以相对封闭的增选方式招募成员。最好的加入方法是协助现有成员工作，表示您了解该团体的目标与运作方式。
ftpmaster 管理员负责管理 Debian 软件包的官方仓库。他们维护用于接收开发者传来的软件包的程序；经过一些检查后，软件包将被保存在目标服务器上 (ftp-master.debian.org)。
他们也检查添加软件包的授权条款，确保在纳入它们之前，Debian 有权散布它们。被要求移除的软件包，由开发者经由错误追踪系统与 ftp.debian.org ‘虚拟软件包’ 向团队提出。
术语 伪软件包，监测工具
错误追踪系统，原先系处理 Debian 软件包错误而设计，后来发现在其他事物上也很实用：列出 Debian 软件包内外的待处理问题或待管理工作。’虚拟软件包’ 允许，指定团队在未链接实际软件包的环境下使用错误追踪系统。每个人都可以报告错误。例如，BTS 有个 ftp.debian.org 条目用于报告与追踪官方软件包的错误或要求移除软件包。同样的，www.debian.org 虚拟软件包则指向 Debian 网页的错误，且 lists.debian.org 汇集与邮件列表有关的问题。
工具 FusionForge，合作开发的瑞士军刀
FusionForge 程序有点像 www.sourceforge.net、alioth.debian.org、或savannah.gnu.org。典藏计划并提供其他服务促进合作发展。每个计划都有独立的虚拟空间，包括网站、几个可追踪 — 最常见的是 — 的错误与补丁 ‘开票’ 系统、调查工具、文件保存空间、论坛、版本控制系统保存所、邮寄清单及其他相关的服务。
alioth.debian.org 是 Debian 的 FusionForge 服务器，由 Tollef Fog Heen、Stephen Gran、与 Roland Mas 管理。Debian 开发者参与的计划都可以放在此处。
服务的范围颇广，看起来内部有点复杂，不过感谢 Christian Bayle 做的 Debian fusionforge 软件包，FusionForge 还是很容易安装的。
如众所期待，Debian 系统管理者 (DSA) 团队 ([debian-admin@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-admin@lists.debian.org)) 对计划内的多个服务器负责。确保所有的服务 (DNS、Web、e-mail、shell 等)、Debian 开发者要求安装的软件、以及安全相关事宜。
工具 Debian 软件包跟踪器
这是 Raphaël 的杰作之一。基本概念是，对于指明的软件包，尽可能将相关信息集结在同一页面中。这样一来，任何人都可以快速查看程序的状态、办识待处理的事项、以及提供协助等。这就是为何这个页面会集结所有的臭虫统计数据、各个发行版中的可用版本、在 Testing 发行版中打包的进度、软件描述和 debconf 模板的翻译状态、是否有新的上游版本、是否未遵循最新版 Debian 政策的通知、维护者的信息、以及维护者期望纳入的其他信息等。
电子邮件订阅服务也在此网页接口。自动送出选定的信息给此清单：错误与相关的讨论、Debian 服务器内的新版本、待校对的新翻译等。
因此，高端的用户可以紧密地跟踪此等信息，或取得足够的理解后，奉献其工作给计划。
另个网页接口，查看 Debian 开发者软件包 (DDPO)，提供开发者其主管软件包的状态摘要。
→ https://qa.debian.org/developer.php
这两个网站由 Debian 的品质保证成员 (通称为 Debian QA) 发展与管理的工具。
此 名单大师 管理邮件列表的电子邮件服务器。职责包括添加名单、处理送回 (无法送出的育知)、以及垃圾邮件过滤器 (未授权的批次邮件)。
文化 邮件列表的流量：某些数据
无疑地，邮件列表跟踪所有的事情，是项目活动性的最佳证据。某些统计数字 (2015年以来) 为该邮件列表自己说话：Debian 主持 240 多个邮件列表、共有 212,000 个订阅者。每个月送出 27,000 个消息每天产生 476,000 封电子邮件。
每个服务都有自己的管理团队，通常是设立该服务的志愿者 (同时也撰写通信工具给自己用)。错误追踪系统 (BTS)、错误追踪器、alioth.debian.org (FusionForge 服务器，见专栏 工具 FusionForge，合作开发的瑞士军刀)、在 qa.debian.org、lintian.debian.org、buildd.debian.org、cdimage.debian.org 等服务器的服务。
1.3.3.3. 发展团队、转换团队
不同于管理团队，发展团队较为开放，甚至可以说是置身于奉献者之外。Debian 自身不添加软件，计划仍需要外部软件满足其需要。当然，仍是在自由软件授权下发展，这些工具使用被自由软件世界验证的方法。
文化 Git
Git 是在多个文件合作运作的工具，维护修订的记录。有问题的文件多半是纯文本档，程序的源代码。由多人共同处理一个文件时，git 可以把不同部分的文件合而为一。否则，其中的 ‘冲突’ 必须以人工处理。
Git 是个分散系统，每个人都有完整记录的保存库。集中的保存库用于下载计划 (git clone) 并与他人共享成果 (git 送出)。保存库内可有多个版本但同一时间只能使用其中之：称为工作版本 (以指令 git checkout 可以变更指向其他版本)。Git 可以显示工作版本的变动 (git diff)、可以在版本记录里保存新的条目 (git commit)、可更新其他用户同时修改的工作版本内容 (git pull)、以及记录特定的配置供日后提取 (git tag)。
Git 可处理发展中的多个版本而不互相干扰。这些版本称为 branches。以树木的分枝形容相当精确，因为程序本来就是从一个主干开始。有了成果 (诸如 1.0) 后，就有两个分枝：发展枝为下个释做准备、维护枝管理 1.0 的更新与修订。
今天，Git 是最流行的版本控制系统，但不是唯一的。CVS (Concurrent Versions System) 是第一个广为流行的工具，但其先天的限制让位给现代的自由软件。包括subversion (svn)、git、bazaar(bzr)、以及 mercurial (hg)。
→ http://subversion.apache.org/
→ http://bazaar.canonical.com/
→ http://mercurial.selenic.com/
Debian 发展自己的小软件，但却是重要的软件，其名声远超越 Debian 计划本身。dpkg 是个例子，它是 Debian 软件包管理程序 (事实上，它是 Debian PacKaGe 的缩写，读成 ‘dee-package’)，另一个是 apt，自动安装 Debian 软件包的工具，检查其相依性，保证安装后与系统一致 (其名称为 Advanced Package Tool 的缩写)。然而，它们都是由小团队撰写的，只需要高端程序技巧就能了解该等程序的运作方式。
最重要的团队可能是 Debian 安装计划，debian-installer，2001年问世以来就是重要的部分。以一个程序安装十多种架构下的 Debian 不是件简单的事，需要很多奉献者才能完成它。每个架构需有自己的启动程序与引导程序。透过 [debian-boot@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-boot@lists.debian.org) 邮件列表，在 Cyril Brulebois 领导下，完成这些工作。
→ http://www.debian.org/devel/debian-installer/
→ http://joeyh.name/blog/entry/d-i_retrospective/
这个 (极小的) debian-cd 程序团队的目标更谦虚。由很多 ‘小小’ 的奉献者负责其架构，因为主要的开发者无法知道全部的细微之处，也不知道从CD-ROM 安装的正确方式。
需要多个团队彼此合作才能够将程序包装起来：以[debian-qa@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-qa@lists.debian.org) 为例，企图保证 Debian 计划的每个层面都达到既定的品质。[debian-policy@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-policy@lists.debian.org) 根据各地的建议列出 Debian 政策。负责每个架构的团队 ([debian-*architecture*@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-architecture@lists.debian.org)) 编绎所有的软件包，若有需要，再改编供特定架构使用。
其他的团队管理最重要的软件包以免重担放在单一团队的肩上；在 C 程序库与 [debian-glibc@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-glibc@lists.debian.org)，C 编绎器 [debian-gcc@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-gcc@lists.debian.org) 邮件列表，或 Xorg 在 [debian-x@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-x@lists.debian.org) (此社区以 X Strike Force 闻名)。
