仅仅在 unstable 中提供高质量的软件包是不够的，大多数用户只有在您的软件包作为下一个 stable 版本的一部分发布时才能从中受益。因此，您应该与发布团队合作，以确保您的软件包被包含在内。

更具体地说，您应该监控您的软件包是否正在迁移到 testing（参见 第 5.13 节，“测试发行版”）。当迁移在测试期后没有发生时，您应该分析原因并努力解决这个问题。这可能意味着修复您的软件包（在发布关键错误或在某些架构上构建失败的情况下），但也可能意味着更新（或修复，或从 testing 中移除）其他软件包，以帮助完成一个过渡，您的软件包由于其依赖关系而卷入其中。如果您无法识别当前的阻碍因素，发布团队可能会为您提供关于给定过渡的当前阻碍因素的一些输入。

大多数软件包维护者的工作是提供 unstable 中软件包的更新版本，但他的工作也包括照顾当前 stable 版本中的软件包。

虽然不鼓励在 stable 中进行更改，但这是有可能的。每当报告安全问题时，您都应该与安全团队合作以提供修复版本（参见 第 5.8.5 节，“处理安全相关错误”）。当针对您的软件包的 stable 版本报告了严重（或更严重）的错误时，您应该考虑提供有针对性的修复。您可以询问 stable 发布团队他们是否会接受这样的更新，然后准备一个 stable 上传（参见 第 5.5.1 节，“特殊情况：上传到 stable 和 oldstable 发行版”）。

一般来说，您应该按照 第 5.8 节，“处理错误” 中描述的方式处理您软件包上的错误报告。但是，有一类特殊的错误您需要注意——所谓的发布关键错误（RC 错误）。所有严重程度为 critical、grave 或 serious 的错误报告都使该软件包不适合包含在下一个 stable 版本中。因此，它们可能会延迟 Debian 版本的发布（当它们影响 testing 中的软件包时）或阻止迁移到 testing（当它们仅影响 unstable 中的软件包时）。在最坏的情况下，它们将导致软件包被移除。这就是为什么这些错误需要尽快纠正。

如果由于任何原因，您无法在 2 周内修复您的软件包中的 RC 错误（例如，由于时间限制，或因为难以修复），您应该在错误报告中清楚地说明这一点，并且您应该标记错误 help 以邀请其他志愿者参与。请注意，RC 错误经常成为非维护者上传 (Non-Maintainer Uploads) 的目标（参见 第 5.11 节，“非维护者上传 (NMUs)”），因为它们可能会阻止许多软件包的 testing 迁移。

QA 团队通常将对 RC 错误的缺乏关注解释为维护者已经消失而没有正确孤立其软件包的迹象。MIA 团队也可能会介入，这可能会导致您的软件包被孤立（参见 第 7.4 节，“处理不活跃和/或无法联系的维护者”）。

作为 Debian 维护者，您的工作很大一部分是与上游开发者保持联系。Debian 用户有时会将非 Debian 特有的错误报告到我们的错误跟踪系统。您必须将这些错误报告转发给上游开发者，以便他们可以在未来的上游版本中修复这些错误。

虽然修复非 Debian 特有错误不是您的工作，但如果您有能力，您可以自由地这样做。当您进行此类修复时，请务必将它们传递给上游维护者。Debian 用户和开发者有时会提交补丁来修复上游错误——您应该评估并将这些补丁转发给上游。

如果您需要修改上游源代码才能构建符合策略的软件包，那么您应该向上游开发者提出一个好的修复方案，该方案可以包含在那里，这样您就不必修改下一个上游版本的源代码。无论您需要进行什么更改，始终尽量不要从上游源代码分叉。

如果您发现上游开发者对 Debian 或自由软件社区怀有敌意或变得怀有敌意，您可能需要重新考虑是否需要在 Debian 中包含该软件。有时，Debian 社区的社会成本不值得该软件可能带来的好处。

在 https://db.debian.org/ 有一个包含 Debian 开发者信息的 LDAP 数据库。您应该在那里输入您的信息并在更改时更新它。最值得注意的是，确保您的 debian.org 电子邮件转发到的地址始终是最新的，以及如果您选择订阅，您接收 debian-private 订阅的地址。

有关数据库的更多信息，请参阅 第 4.5 节，“开发者数据库”。

请非常小心您的私钥。不要将它们放在任何公共服务器或多用户机器上，例如 Debian 服务器（参见 第 4.4 节，“Debian 机器”）。备份您的密钥；保留一份离线副本。阅读您的软件附带的文档；阅读 PGP FAQ。

您不仅需要确保您的密钥安全，防止被盗，还需要确保它安全，防止丢失。生成并制作一份您的吊销证书的副本（最好也以纸质形式）；如果您的密钥丢失，则需要此证书。

如果您向您的公钥添加签名，或添加用户身份，您可以通过将您的密钥发送到 keyring.debian.org 的密钥服务器来更新 Debian 密钥环。

如果您需要添加一个全新的密钥或删除一个旧密钥，您需要让另一个开发者签署新密钥。如果旧密钥已泄露或无效，您还必须添加吊销证书。如果新密钥没有真正的理由，密钥环维护者可能会拒绝新密钥。详细信息可以在 http://keyring.debian.org/replacing_keys.html 找到。

在 第 2.3 节，“注册成为 Debian 开发者” 中讨论的相同密钥提取例程也适用。

您可以在 debian-keyring 软件包的文档中找到关于 Debian 密钥维护的更深入的讨论。

即使 Debian 实际上不是一个民主政体，我们仍然使用民主程序来选举我们的领导人并批准一般决议。这些程序由 Debian 宪章 定义。

除了每年的领导人选举外，投票不是例行举行的，而且它们不是轻易进行的。每个提案首先在 <debian-vote@lists.debian.org> 邮件列表中讨论，并且在项目秘书启动投票程序之前需要几个赞同。

您不必跟踪投票前的讨论，因为秘书将在 <debian-devel-announce@lists.debian.org> 上发布多次投票呼吁（并且所有开发者都应该订阅该列表）。如果人们不参与投票，民主就无法很好地运作，这就是为什么我们鼓励所有开发者投票的原因。投票通过 GPG 签名/加密的电子邮件消息进行。

所有提案（过去和现在）的列表都可以在 Debian 投票信息页面上找到，以及关于如何提出、附议和投票提案的信息。

开发者有一段时间的缺席是很常见的，无论是计划好的假期还是仅仅是埋头于其他工作。需要注意的重要事情是，其他开发者需要知道您正在休假，以便如果您的软件包或项目中的其他职责出现问题，他们可以做任何需要做的事情。

通常这意味着如果当您休假时发生重大问题（发布关键错误、安全更新等），其他开发者被允许 NMU（参见 第 5.11 节，“非维护者上传 (NMUs)”）您的软件包。有时它不像那么严重，但让其他人知道您无法使用仍然是合适的。

为了通知其他开发者，您应该做两件事。首先，发送一封邮件到 <debian-private@lists.debian.org>，并在您的邮件主题前加上 [VAC]^[2]，并说明您休假的时间段。您还可以给出关于如果出现问题该怎么做的特别指示。

另一件事是在 Debian 开发者 LDAP 数据库 中将您自己标记为休假（此信息仅 Debian 开发者可访问）。当您回来时，不要忘记删除休假标志！

理想情况下，您应该在预订假期时在 GPG 协调页面 上注册，并查看是否有任何人在那里寻找签名。当人们去我们还没有任何开发者但那里有人有兴趣申请的异国情调的地方时，这一点尤其重要。

如果您选择离开 Debian 项目，您应该确保执行以下步骤

遵循上述流程非常重要，因为查找不活跃的开发者并孤立他们的软件包需要大量时间和精力。

当遵循 第 3.2.5 节，“退休” 中的流程时，退休开发者的帐户被标记为“名誉退休”，否则被标记为“禁用”。拥有“名誉退休”帐户的退休开发者可以按如下方式重新激活其帐户

拥有“禁用”帐户的退休开发者需要再次通过 NM。