目录
Debian 不仅仅是打包软件和维护这些软件包。本章包含关于如何为 Debian 做出贡献的信息，这些方式通常是非常关键的，超越了简单地创建和维护软件包。
作为一个志愿者组织，Debian 依赖于其成员在选择他们想要从事的工作以及选择最关键的事情上拥有自主决定权。
我们鼓励您在 Debian 软件包中发现缺陷时提交报告。事实上，Debian 开发者通常是第一线测试人员。在其他开发者的软件包中发现并报告缺陷可以提高 Debian 的质量。
尝试从您可能收到邮件的普通用户帐户提交缺陷，以便人们在需要有关缺陷的更多信息时可以联系到您。请勿以 root 用户身份提交缺陷。
您可以使用类似 reportbug(1) 的工具来提交缺陷。它可以自动化并通常简化该过程。
确保该缺陷尚未针对软件包提交。每个软件包都有一个缺陷列表，可以轻松地通过 http://bugs.debian.org/ 访问。类似 querybts(1) 的实用程序也可以为您提供此信息（并且 reportbug 通常也会在发送之前调用 querybts）。软件包名称
尝试将您的缺陷定向到正确的位置。例如，当您的缺陷是关于一个软件包覆盖了另一个软件包中的文件时，请检查 这两个 软件包的缺陷列表，以避免提交重复的缺陷报告。
为了获得额外的加分，您可以浏览其他软件包，合并报告多次的缺陷，或者在缺陷已被修复时标记为“已修复”。请注意，当您既不是缺陷提交者也不是软件包维护者时，您实际上不应该关闭缺陷（除非您获得维护者的许可）。
您可能希望不时检查您提交的缺陷报告的进展情况。借此机会关闭那些您无法再重现的缺陷。要查找您提交的所有缺陷，您只需访问 http://bugs.debian.org/from:。您的电子邮件地址
针对许多不同软件包上的同一问题报告大量缺陷——即超过 10 个——是一种不推荐的做法。采取一切可能的步骤来避免批量提交缺陷。例如，如果检查问题可以自动化，请向 lintian 添加新的检查，以便发出错误或警告。
如果您一次报告超过 10 个关于同一主题的缺陷，建议您在提交报告之前向 <debian-devel@lists.debian.org> 发送消息描述您的意图，并在邮件主题中提及此事。这将允许其他开发者验证该缺陷是否是一个实际问题。此外，它将有助于防止多个维护者同时开始提交相同的缺陷报告的情况。
请使用程序 dd-list 以及适当情况下的 whodepends (来自软件包 devscripts) 来生成所有受影响软件包的列表，并将输出包含在您发送给 <debian-devel@lists.debian.org> 的邮件中。
请注意，当发送大量关于同一主题的缺陷时，您应该将缺陷报告发送到 <maintonly@bugs.debian.org>，以便缺陷报告不会转发到缺陷分发邮件列表。
当跨多个软件包提交缺陷时，您可能希望使用 BTS 用户标签。用户标签类似于正常的标签，例如“patch”和“wishlist”，但不同之处在于它们是用户定义的，并且占据特定用户唯一的命名空间。这允许多组开发者以不同的方式“用户标记”同一个缺陷，而不会发生冲突。
要在提交缺陷时添加用户标签，请指定 User 和 Usertags 伪标头
To: submit@bugs.debian.org Subject:title-of-bugPackage:pkgname[ ... ]User:email-addrUsertags:tag-name [ tag-name ... ]description-of-bug ...
请注意，标签由空格分隔，并且不能包含下划线。如果您为特定的组或团队提交缺陷，建议您在描述您的意图后将 User 设置为适当的邮件列表。
要查看使用特定用户标签标记的缺陷，请访问 http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=。电子邮件地址&tag=标签名称
即使有一个专门的质量保证小组，QA 职责也不仅仅为他们保留。您可以通过尽可能保持您的软件包无缺陷，并尽可能保持 lintian 清洁（请参阅 第 A.2.1 节，“lintian”）来参与这项工作。如果您发现这不可能，那么您应该考虑孤立您的一些软件包（请参阅 第 5.9.4 节，“孤立软件包”）。或者，您可以寻求其他人的帮助，以便赶上您积压的缺陷（您可以在 <debian-qa@lists.debian.org> 或 <debian-devel@lists.debian.org> 上寻求帮助）。同时，您可以寻找共同维护者（请参阅 第 5.12 节，“协作维护”）。
QA 小组不时组织缺陷消灭聚会，以尽可能消除更多问题。它们会在 <debian-devel-announce@lists.debian.org> 上宣布，并且公告会解释聚会的重点领域：通常他们专注于发布关键缺陷，但也可能发生他们决定帮助完成重大升级（例如新的 perl 版本，这需要重新编译所有二进制模块）。
在聚会期间，非维护者上传的规则有所不同，因为聚会的公告被认为是 NMU 的事先通知。如果您的软件包可能受到聚会的影响（例如，因为它们具有发布关键缺陷），您应该向每个相应的缺陷发送更新，以解释它们的当前状态以及您对聚会的期望。如果您不想要 NMU，或者您只对补丁感兴趣，或者您将自己处理缺陷，请在 BTS 中说明。
参与聚会的人员有特殊的 NMU 规则，如果他们将 NMU 上传到 DELAYED/3-day 至少，他们可以无需事先通知进行 NMU。所有其他 NMU 规则通常都适用；他们应该将 NMU 的补丁发送到 BTS（发送到 NMU 修复的开放缺陷之一，或发送到新缺陷，标记为已修复）。他们也应该尊重维护者的任何特殊愿望。
如果您对进行 NMU 没有信心，只需将补丁发送到 BTS。这远比一个损坏的 NMU 要好。
在您在 Debian 中的生命周期内，您将不得不出于各种原因联系其他维护者。您可能想要讨论一组相关软件包之间新的合作方式，或者您可能只是提醒某人有新的上游版本可用，并且您需要它。
查找软件包维护者的电子邮件地址可能会分散注意力。幸运的是，有一个简单的电子邮件别名 软件包@packages.debian.org软件包 替换为源软件包或二进制软件包的名称。
您可能还对通过 第 4.10 节，“软件包跟踪系统” 联系订阅给定源软件包的人员感兴趣。您可以使用 软件包@packages.qa.debian.org
如果您注意到某个软件包缺乏维护，您应该确保维护者是活跃的，并且将继续处理他们的软件包。他们可能不再活跃，但没有从系统中注销，可以这么说。另一方面，他们也可能只是需要提醒。
有一个简单的系统（MIA 数据库），其中记录了关于被认为失踪的维护者的信息。当 QA 小组的成员联系到不活跃的维护者或找到关于他们的更多信息时，这会被记录在 MIA 数据库中。此系统在主机 qa.debian.org 上的 /org/qa.debian.org/mia 中可用，并且可以使用 mia-query 工具进行查询。使用 mia-query --help 查看如何查询数据库。如果您发现尚未记录关于不活跃维护者的任何信息，或者您可以添加更多信息，您通常应按如下步骤进行。
第一步是礼貌地联系维护者，并等待合理的时间回复。很难定义合理的时间，但重要的是要考虑到现实生活有时非常忙碌。一种处理方式是在两周后发送提醒。
如果维护者在四周（一个月）内没有回复，则可以假设可能不会发生回复。如果发生这种情况，您应该进一步调查，并尝试收集尽可能多的关于相关维护者的有用信息。这包括
通过 开发者 LDAP 数据库 提供的 echelon 信息，该信息指示开发者上次在 Debian 邮件列表上发帖的时间。（这包括关于通过 <debian-devel-changes@lists.debian.org> 列表分发的上传邮件。）此外，请记住检查维护者是否在数据库中标记为休假。
该维护者负责的软件包数量，以及这些软件包的状况。特别是，是否有任何长期存在的 RC 缺陷？此外，一般有多少缺陷？另一个重要的信息是软件包是否已被 NMU，如果是，是由谁 NMU 的。
维护者在 Debian 之外是否有任何活动？例如，他们可能最近在非 Debian 邮件列表或新闻组中发布了一些内容。
一个有点问题的是被赞助的软件包——维护者不是官方的 Debian 开发者。echelon 信息不适用于被赞助的人，例如，因此您需要找到并联系实际上传软件包的 Debian 开发者。鉴于他们签署了软件包，无论如何他们都对上传负责，并且很可能知道他们赞助的人发生了什么事。
也允许向 <debian-devel@lists.debian.org> 发送查询，询问是否有人知道失踪维护者的下落。请抄送给相关人员。
一旦您收集了所有这些信息，您就可以联系 <mia@qa.debian.org>。此别名上的人员将使用您提供的信息来决定如何进行。例如，他们可能会孤立维护者的一个或所有软件包。如果软件包已被 NMU，他们可能更愿意在孤立软件包之前联系 NMU 者——也许进行 NMU 的人对该软件包感兴趣。
最后一句：请记住要有礼貌。我们都是志愿者，不能将我们所有的时间都奉献给 Debian。此外，您不了解所涉及人员的情况。也许他们可能病得很重，甚至可能已经去世——您不知道谁可能在接收端。想象一下，如果亲戚阅读死者的电子邮件，并发现一条非常不礼貌、愤怒和指责的信息，他们会作何感受！
另一方面，虽然我们是志愿者，但我们确实有责任。因此，您可以强调更大利益的重要性——如果维护者不再有时间和兴趣，他们应该放手，并将软件包交给更有时间的人。
如果您有兴趣在 MIA 团队工作，请查看 qa.debian.org 上 /org/qa.debian.org/mia 中的 README 文件，其中记录了技术细节和 MIA 程序，并联系 <mia@qa.debian.org>。
Debian 的成功取决于它吸引和留住新的和有才华的志愿者的能力。如果您是一位经验丰富的开发者，我们建议您参与引入新开发者的过程。本节介绍如何帮助新的潜在开发者。
赞助软件包意味着为无法自行上传的维护者上传软件包。这不是一件小事，赞助者必须验证软件包，并确保其质量达到 Debian 努力实现的高水平。
Debian 开发者可以赞助软件包。Debian 维护者不能。
赞助软件包的过程是
维护者准备一个源软件包 (.dsc) 并将其放在网上某处（例如在 mentors.debian.net 上），或者更好的是，提供一个指向公共 VCS 存储库的链接（请参阅 第 4.4.5 节，“VCS 服务器”），软件包在该存储库中维护。
赞助者下载（或检出）源软件包。
赞助者审查源软件包。如果她发现问题，她会通知维护者并要求她提供修复版本（该过程从步骤 1 重新开始）。
赞助者没有发现任何剩余问题。她构建软件包，签名并将其上传到 Debian。
在深入研究如何赞助软件包的细节之前，您应该问问自己，添加建议的软件包是否对 Debian 有益。
没有简单的规则来回答这个问题，这可能取决于许多因素：上游代码库是否成熟且没有安全漏洞？是否有可以执行相同任务的预先存在的软件包，它们与这个新软件包相比如何？新软件包是否已被用户请求，用户群有多大？上游开发者有多活跃？
您还应该确保潜在的维护者将成为一名优秀的维护者。她是否已经有一些其他软件包的经验？如果是，她是否在这些软件包上做得很好（检查一些缺陷）？她是否熟悉该软件包及其编程语言？她是否具备此软件包所需的技能？如果不是，她是否能够学习它们？
了解她对 Debian 的立场也是一个好主意：她是否同意 Debian 的理念，她是否打算加入 Debian？鉴于成为 Debian 维护者是多么容易，您可能只想赞助计划加入的人。这样您从一开始就知道您不必无限期地充当赞助者。
新的维护者通常在创建 Debian 软件包时遇到某些困难——这是完全可以理解的。他们会犯错误。这就是为什么将全新的软件包赞助到 Debian 中需要对 Debian 打包进行彻底审查。有时需要多次迭代，直到软件包足够好以可以上传到 Debian。因此，成为赞助者意味着成为导师。
在没有审查的情况下，永远不要赞助新的软件包。ftpmasters 对新软件包的审查主要确保软件确实是自由的。当然，他们有时会偶然发现打包问题，但他们真的不应该。您的任务是确保上传的软件包符合 Debian 自由软件指南并具有良好的质量。
构建软件包和测试软件是审查的一部分，但这也还不够。本节的其余部分包含审查中要检查的非详尽列表。[7]
验证提供的上游 tarball 是否与上游作者分发的 tarball 相同（当为 Debian 重新打包源时，自己生成修改后的 tarball）。
运行 lintian（请参阅 第 A.2.1 节，“lintian”）。它将捕获许多常见问题。务必验证维护者设置的任何 lintian 覆盖是否完全合理。
运行 licensecheck（第 A.6.1 节，“devscripts” 的一部分），并验证 debian/copyright 看起来是否正确和完整。查找许可证问题（例如带有“保留所有权利”标头的文件，或带有不符合 DFSG 要求的许可证的文件）。grep -ri 是您完成此任务的朋友。
使用 pbuilder（或任何类似的工具，请参阅 第 A.4.3 节，“pbuilder”）构建软件包，以确保构建依赖项完整。
校对 debian/control：它是否遵循最佳实践（请参阅 第 6.2 节，“debian/control 的最佳实践”）？依赖项是否完整？
校对 debian/rules：它是否遵循最佳实践（请参阅 第 6.1 节，“debian/rules 的最佳实践”）？您是否看到一些可能的改进？
校对维护者脚本 (preinst、postinst、prerm、postrm、config)：当依赖项未安装时，preinst/postrm 是否会工作？所有脚本是否都是幂等的（即，您是否可以多次运行它们而不会产生后果）？
审查对上游文件的任何更改（无论是在 .diff.gz 中，还是在 debian/patches/ 中，还是直接嵌入在二进制文件的 debian tarball 中）。它们是否合理？它们是否已正确记录（对于补丁，使用 DEP-3）？
对于每个文件，问问自己为什么该文件在那里，以及这是否是实现期望结果的正确方法。维护者是否遵循最佳打包实践（请参阅 第 6 章，最佳打包实践）？
构建软件包，安装它们并尝试软件。确保您可以删除和清除软件包。也许使用 piuparts 测试它们。
如果审核未发现任何问题，您可以构建软件包并将其上传到 Debian。请记住，即使您不是维护者，赞助者仍然对他上传到 Debian 的内容负责。这就是为什么鼓励您通过 第 4.10 节，“软件包跟踪系统” 关注软件包。
请注意，您不需要修改源软件包以将您的姓名放在 changelog 或 control 文件中。control 文件的 Maintainer 字段和 changelog 应列出进行打包的人，即被赞助者。这样她将收到所有 BTS 邮件。
相反，您应该指示 dpkg-buildpackage 使用您的密钥进行签名。您可以使用 -k 选项来做到这一点
dpkg-buildpackage -kKEY-ID
如果您使用 debuild 和 debsign，您甚至可以在 ~/.devscripts 中永久配置它
DEBSIGN_KEYID=KEY-ID
您通常会假设软件包已经过全面审查。因此，您无需再次进行审查，而是会仔细分析当前版本与维护者准备的新版本之间的差异。如果您自己没有进行初始审查，您可能仍然希望更深入地查看，以防初始审查者马虎。
为了能够分析差异，您需要两个版本。下载当前版本的源软件包（使用 apt-get source）并重新构建它（或使用 aptitude download 下载当前的二进制软件包）。下载要赞助的源软件包（通常使用 dget）。
阅读新的 changelog 条目，它应该告诉您在审查期间会发生什么。您将使用的主要工具是 debdiff（由 devscripts 软件包提供），您可以使用两个源软件包（.dsc 文件）、两个二进制软件包或两个 .changes 文件运行它（然后它将比较 .changes 中列出的所有二进制软件包）。
如果您比较源软件包（在新的上游版本的情况下排除上游文件，例如通过使用 filterdiff -i '*/debian/*' 过滤 debdiff 的输出），您必须理解您看到的所有更改，并且它们应该在 Debian changelog 中正确记录。
如果一切正常，构建软件包并比较二进制软件包，以验证源软件包上的更改是否没有意外后果（例如，错误地删除了一些文件、缺少依赖项等）。
您可能需要查看软件包跟踪系统（请参阅 第 4.10 节，“软件包跟踪系统”），以验证维护者是否遗漏了一些重要的内容。也许 BTS 中有翻译更新可以集成。也许软件包已被 NMU，维护者忘记将 NMU 中的更改集成到他的软件包中。也许有一个发布关键缺陷，他一直未处理，并且阻止迁移到 testing。无论如何。如果您发现她可以做得（更好）的事情，现在是时候告诉她，以便她下次可以改进，并让她更好地了解自己的责任。
如果您没有发现任何重大问题，请上传新版本。否则，请维护者提供修复版本。
请参阅 Debian 网站上关于 倡导潜在开发者 的页面。
请参阅 Debian 网站上的 申请管理员检查清单。