上传到 stable 意味着该软件包将被转移到 proposed-updates-new 队列，以供 stable 发布管理器审查，如果获得批准，将被安装在 Debian 存档的 stable-proposed-updates 目录中。从那里，它将在下一个 point release 中包含在 stable 中。

为了确保您的上传被接受，您应该在上传之前与 stable 发布团队讨论更改。为此，使用 reportbug 向 release.debian.org 伪软件包提交错误，包括您要应用于当前 stable 版本软件包的补丁。对于上传到 stable 发行版的软件包，请始终在您的 changelog 条目中详细说明。

上传到 stable 时应格外小心。基本上，仅当发生以下情况之一时，才应将软件包上传到 stable：

过去，上传到 stable 也用于解决安全问题。但是，这种做法已被弃用，因为用于 Debian 安全公告的上传在公告发布时会自动复制到相应的 proposed-updates 存档。有关处理安全问题的详细信息，请参阅第 5.8.5 节，“处理安全相关的错误”。如果安全团队认为该问题过于良性，无法通过 DSA 修复，则 stable 发布管理器通常仍愿意在常规上传到 stable 中包含您的修复程序。

不鼓励更改软件包中任何不重要的内容，因为即使是微不足道的修复也可能在以后引起错误。

上传到 stable 的软件包需要在运行 stable 的系统上编译，以便它们的依赖项仅限于 stable 中可用的库（和其他软件包）；例如，上传到 stable 的软件包如果依赖于仅在 unstable 中存在的库软件包，将被拒绝。强烈不鼓励更改其他软件包的依赖项（通过修改 Provides 或 shlibs 文件），这可能会导致其他软件包无法卸载。

只要 oldstable 发行版尚未被存档，就可以上传到该发行版。与 stable 相同的规则适用。

请参阅testing 部分中的信息以了解详细信息。

要上传软件包，您应该使用匿名 ftp 将文件（包括签名后的 changes 文件和 dsc 文件）上传到 ftp.upload.debian.org 的目录 /pub/UploadQueue/。为了在那里处理这些文件，它们需要使用 Debian 开发者密钥环或 Debian 维护者密钥环中的密钥进行签名（请参阅 http://wiki.debian.org/DebianMaintainer）。

请注意，您应该最后传输 changes 文件。否则，您的上传可能会被拒绝，因为存档维护软件将解析 changes 文件并看到并非所有文件都已上传。

您可能还会发现 Debian 软件包 dupload 或 dput 在上传软件包时很有用。这些方便的程序有助于自动化将软件包上传到 Debian 的过程。

有关删除软件包的信息，请参阅 ftp://ftp.upload.debian.org/pub/UploadQueue/README 和 Debian 软件包 dcut。

有时立即上传软件包很有用，但希望此软件包仅在几天后才到达存档。例如，在准备非维护者上传时，您可能希望给维护者几天时间做出反应。

上传到 delayed 目录会将软件包保留在延迟上传队列中。当指定的等待时间结束时，软件包将被移动到常规的 incoming 目录进行处理。这是通过自动上传到 ftp.upload.debian.org 的上传目录 DELAYED/X-day（X 在 0 到 15 之间）完成的。0-day 每天多次上传到 ftp.upload.debian.org。

使用 dput，您可以使用 --delayed DELAY 参数将软件包放入其中一个队列。

在没有安全团队事先授权的情况下，不要将软件包上传到安全上传队列（oldstable-security、stable-security 等）。如果软件包不完全符合团队的要求，则会在处理不需要的上传时引起许多问题和延误。有关详细信息，请参阅第 5.8.5 节，“处理安全相关的错误”。

欧洲有一个备用上传队列，位于 ftp://ftp.eu.upload.debian.org/pub/UploadQueue/。它的操作方式与 ftp.upload.debian.org 相同，但对于欧洲开发者来说应该更快。

也可以通过 ssh 上传软件包到 ssh.upload.debian.org；文件应放在 /srv/upload.debian.org/UploadQueue。此队列不支持延迟上传。

Debian 存档维护者负责处理软件包上传。在大多数情况下，上传由存档维护工具 dak process-upload 每天自动处理。具体来说，对 unstable 发行版现有软件包的更新是自动处理的。在其他情况下，特别是新软件包，将上传的软件包放入发行版是手动处理的。当手动处理上传时，存档的更改可能需要一些时间才能发生。请耐心等待。

在任何情况下，您都会收到一封电子邮件通知，指示软件包已添加到存档中，这也指示哪些错误将通过上传关闭。请仔细检查此通知，检查您打算关闭的任何错误是否未被触发。

安装通知还包括有关软件包插入到哪个 section 的信息。如果存在差异，您将收到一封单独的电子邮件通知您。请继续阅读以下内容。

请注意，如果您通过队列上传，队列守护程序软件也会通过电子邮件向您发送通知。

如果您想成为一名优秀的维护者，您应该定期检查 Debian 错误跟踪系统 (BTS) 以查找您的软件包的错误。BTS 包含针对您的软件包的所有未解决的错误。您可以通过浏览此页面来检查它们：http://bugs.debian.org/yourlogin@debian.org。

维护者通过 bugs.debian.org 的电子邮件地址与 BTS 交互。有关可用命令的文档，请访问 http://www.debian.org/Bugs/，或者，如果您安装了 doc-debian 软件包，您可以查看本地文件 /usr/share/doc/debian/bug-*。

有些人发现获取有关未解决错误的定期报告很有用。如果您想每周收到一封概述针对您的软件包的所有未解决错误的电子邮件，您可以添加如下 cron 作业：

# ask for weekly reports of bugs in my packages
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

将 address 替换为您的官方 Debian 维护者地址。

在响应错误时，请确保您关于错误的所有讨论都同时发送给错误的原始提交者和错误本身（例如，<123@bugs.debian.org>）。如果您正在写一封新邮件，并且不记得提交者的电子邮件地址，您可以使用 <123-submitter@bugs.debian.org> 电子邮件来联系提交者并在错误日志中记录您的邮件（这意味着您无需将邮件副本发送到 <123@bugs.debian.org>）。

如果您收到一个错误，其中提到 FTBFS，则表示 Fails to build from source（从源码构建失败）。移植者经常使用此首字母缩略词。

一旦您处理完错误报告（例如，修复了它），请通过向 <123-done@bugs.debian.org> 发送解释消息，将其标记为 done（关闭它）。如果您通过更改和上传软件包来修复错误，您可以按照第 5.8.4 节，“当错误通过新的上传关闭时”中的描述自动化错误关闭。

您绝不应该通过发送到 <control@bugs.debian.org> 的错误服务器 close 命令来关闭错误。如果您这样做，原始提交者将不会收到任何关于错误为何关闭的信息。

作为软件包维护者，您经常会发现其他软件包中的错误，或者您自己的软件包收到错误报告，但实际上这些错误是其他软件包中的错误。错误跟踪系统的功能在Debian 开发人员的 BTS 文档中进行了描述。重新分配、合并和标记错误报告等操作在BTS 控制服务器文档中进行了描述。本节包含一些基于 Debian 开发人员集体经验的关于管理您自己错误的指南。

为在其他软件包中发现的问题提交错误报告是维护者的公民义务之一，详情请参阅第 7.1 节 “错误报告”。然而，处理您自己软件包中的错误更为重要。

以下是您可以遵循的处理错误报告的步骤列表：

当您的软件包中的错误和问题被修复时，作为软件包维护者，您有责任关闭这些错误。但是，您不应该在修复该错误的软件包被 Debian 存档接受之前关闭错误。因此，一旦您收到通知，告知您的更新软件包已安装到存档中，您就可以并且应该在 BTS 中关闭该错误。此外，应该使用正确的版本关闭该错误。

但是，可以避免在上传后手动关闭错误——只需在您的 debian/changelog 文件中列出已修复的错误，遵循一定的语法，存档维护软件将为您关闭错误。例如：

acme-cannon (3.1415) unstable; urgency=low

  * Frobbed with options (closes: Bug#98339)
  * Added safety to prevent operator dismemberment, closes: bug#98765,
    bug#98713, #98714.
  * Added man page. Closes: #98725.

从技术上讲，以下 Perl 正则表达式描述了如何识别错误关闭变更日志：

  /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig

我们更喜欢 closes: #XXX 语法，因为它是最简洁的条目，并且最容易与 changelog 的文本集成。除非通过 -v 开关指定给 dpkg-buildpackage，否则只关闭最近的变更日志条目中关闭的错误（基本上，正是 .changes 文件中的 changelog 部分中提到的错误被关闭）。

从历史上看，被标识为非维护者上传 (NMU)的上传会被标记为 fixed 而不是被关闭，但该做法随着版本跟踪的出现而停止。标签 fixed-in-experimental 也应用了相同的做法。

如果您不小心输错了错误编号或在变更日志条目中忘记了错误，请毫不犹豫地撤销错误造成的任何损害。要重新打开错误关闭的错误，请向错误跟踪系统的控制地址 <control@bugs.debian.org> 发送 reopen XXX 命令。要关闭由您的上传修复的任何剩余错误，请将 .changes 文件通过电子邮件发送到 <XXX-done@bugs.debian.org>，其中 XXX 是错误编号，并将 Version: YYY 和一个空行作为电子邮件正文的前两行，其中 YYY 是错误被修复的第一个版本。

请记住，不一定必须使用如上所述的变更日志来关闭错误。如果您只是想关闭与您进行的上传无关的错误，请通过电子邮件向 <XXX-done@bugs.debian.org> 发送解释说明来完成。如果软件包的该版本中的更改与错误没有任何关系，不要在版本的变更日志条目中关闭错误。

有关如何编写变更日志条目的通用信息，请参阅第 6.3 节 “debian/changelog 的最佳实践”。

由于安全相关错误的敏感性，必须谨慎处理。Debian 安全团队的存在是为了协调这项活动，跟踪未解决的安全问题，帮助维护者解决安全问题或自行修复，发送安全公告，并维护 security.debian.org。

当您意识到 Debian 软件包中存在安全相关错误时，无论您是否是维护者，都请收集有关该问题的相关信息，并及时联系安全团队，最好是在他们的 Request Tracker 中提交工单。请参阅 http://wiki.debian.org/rt.debian.org#Security_Team。或者，您也可以发送电子邮件至 <team@security.debian.org>。在未联系团队之前，请勿上传任何用于 stable 的软件包。有用的信息包括，例如：

作为软件包的维护者，您有责任维护它，即使在 stable 发行版中也是如此。您处于评估补丁和测试更新软件包的最佳位置，因此请参阅以下关于如何为安全团队准备软件包的章节。

有时软件包会更改其 section。例如，来自 non-free section 的软件包可能在以后的版本中获得 GPL 许可，在这种情况下，软件包应移至“main”或“contrib”。^[3]

如果您需要更改您的软件包的 section，请更改软件包控制信息以将软件包放置在所需的 section 中，并重新上传软件包（有关详细信息，请参阅Debian 策略手册）。您必须确保在上传中包含 .orig.tar.{gz,bz2,xz}（即使您未上传新的上游版本），否则它将不会与软件包的其余部分一起出现在新的 section 中。如果您的新 section 有效，它将自动移动。如果无效，请联系 ftpmasters 以了解发生了什么。

另一方面，如果您需要更改您的软件包的 subsection（例如，“devel”、“admin”），则过程略有不同。更正软件包控制文件中找到的 subsection，并重新上传。此外，您还需要更新 override 文件，如第 5.7 节 “指定软件包 section、subsection 和优先级”中所述。

如果出于某种原因您要完全删除一个软件包（例如，如果它是一个不再需要的旧兼容性库），您需要针对 ftp.debian.org 提交一个错误报告，要求删除该软件包；与所有错误一样，此错误的严重性通常应为 normal。错误标题应采用 RM: package [architecture list] -- reason 格式，其中 package 是要删除的软件包，reason 是删除请求原因的简短摘要。[architecture list] 是可选的，仅当删除请求仅适用于某些架构而非所有架构时才需要。请注意，当您使用 reportbug 向 ftp.debian.org 伪软件包报告错误时，它将创建一个符合这些规则的标题。

如果您要删除您维护的软件包，您应该在错误标题中通过前置 ROM (Request Of Maintainer) 来注明这一点。软件包删除的原因中使用了其他几个标准首字母缩略词，请参阅 http://ftp-master.debian.org/removals.html 以获取完整列表。该页面还提供了待处理删除请求的便捷概览。

请注意，删除只能针对 unstable、experimental 和 stable 发行版完成。软件包不会直接从 testing 中删除。相反，在软件包从 unstable 中删除并且 testing 中没有软件包依赖于它之后，它们将自动删除。

有一种例外情况，不需要明确的删除请求：如果（源或二进制）软件包不再从源代码构建，它将半自动删除。对于二进制软件包，这意味着不再有任何源软件包生成此二进制软件包；如果二进制软件包只是不再在某些架构上生成，则仍然需要删除请求。对于源软件包，这意味着它引用的所有二进制软件包都已被另一个源软件包接管。

在您的删除请求中，您必须详细说明证明该请求合理的理由。这是为了避免不必要的删除并保留软件包被删除原因的痕迹。例如，您可以提供取代要删除的软件包的软件包名称。

通常，您只请求删除您自己维护的软件包。如果您想删除另一个软件包，您必须获得其维护者的批准。如果软件包已孤立且因此没有维护者，您应该首先在 <debian-qa@lists.debian.org> 上讨论删除请求。如果达成共识，认为应该删除该软件包，您应该重新分配和重新命名针对 wnpp 软件包提交的 O: 错误，而不是提交新的错误作为删除请求。

有关这些和其他软件包删除相关主题的更多信息，请访问 http://wiki.debian.org/ftpmaster_Removals 和 http://qa.debian.org/howto-remove.html。

如果您不确定软件包是否可丢弃，请发送电子邮件至 <debian-devel@lists.debian.org> 征求意见。同样值得关注的是来自 apt 软件包的 apt-cache 程序。当以 apt-cache showpkg package 形式调用时，该程序将显示 package 的详细信息，包括反向依赖关系。其他有用的程序包括 apt-cache rdepends、apt-rdepends、build-rdeps（在 devscripts 软件包中）和 grep-dctrl。孤立软件包的删除在 <debian-qa@lists.debian.org> 上讨论。

软件包删除后，应处理软件包的错误。如果实际代码已演变为另一个软件包（例如，libfoo12 已删除，因为 libfoo13 取代了它），则应将其重新分配给另一个软件包；如果该软件只是不再是 Debian 的一部分，则应将其关闭。关闭错误时，为避免将错误标记为在先前 Debian 发行版中的软件包版本中已修复，应将它们标记为在版本 <most-recent-version-ever-in-Debian>+rm 中已修复。

当您的软件包的上游维护者选择重命名他们的软件（或者您在命名软件包时犯了错误），您应该遵循一个两步流程来重命名它。第一步，更改 debian/control 文件以反映新名称，并替换、提供和冲突过时的软件包名称（详情请参阅 Debian 策略手册）。请注意，只有当所有依赖于过时软件包名称的软件包在重命名后继续工作时，您才应该添加 Provides 关系。一旦您上传了软件包并且该软件包已移动到存档中，请针对 ftp.debian.org 提交一个错误报告，要求删除具有过时名称的软件包（请参阅 第 5.9.2 节，“移除软件包”）。不要忘记同时正确地重新分配软件包的错误报告。

在其他时候，您可能会在构建软件包时犯错，并希望替换它。唯一的方法是增加版本号并上传新版本。旧版本将以通常的方式过期。请注意，这适用于您软件包的每个部分，包括源代码：如果您希望替换软件包的上游源代码 tarball，您需要使用不同的版本上传它。一个简单的可能性是将 foo_1.00.orig.tar.gz 替换为 foo_1.00+0.orig.tar.gz 或 foo_1.00.orig.tar.bz2。此限制为 ftp 站点上的每个文件赋予唯一名称，这有助于确保镜像网络的一致性。

如果您无法再维护某个软件包，您需要通知其他人，并确保该软件包被标记为孤立。您应该将软件包维护者设置为 Debian QA Group <packages@qa.debian.org>，并针对伪软件包 wnpp 提交一个错误报告。错误报告的标题应为 O: package -- short description，表明该软件包现在是孤立的。错误的严重程度应设置为 normal；如果软件包的优先级为 standard 或更高，则应设置为 important。如果您觉得有必要，请将副本发送到 <debian-devel@lists.debian.org>，方法是将地址放在消息的 X-Debbugs-CC: 标头中（不，不要使用 CC:，因为那样消息的主题将不会指示错误编号）。

如果您只是打算放弃软件包，但目前可以继续维护，那么您应该改为针对 wnpp 提交一个错误报告，并将标题设置为 RFA: package -- short description。RFA 代表 Request For Adoption（请求认领）。

更多信息请访问 WNPP 网页。

需要新维护者的软件包列表可在 Work-Needing and Prospective Packages list (WNPP) 中找到。如果您希望接管 WNPP 中列出的任何软件包的维护工作，请查看上述页面以获取信息和步骤。

简单地接管您认为被忽视的软件包是不可以的——那将是软件包劫持。当然，您可以联系当前的维护者，询问是否可以接管该软件包。如果您有理由相信维护者已经 AWOL（擅离职守），请参阅 第 7.4 节，“处理不活跃和/或无法联系的维护者”。

一般来说，未经当前维护者的同意，您不得接管软件包。即使他们无视您，这仍然不是接管软件包的理由。关于维护者的投诉应提交到开发者邮件列表。如果讨论没有积极的结论，并且问题是技术性的，请考虑将其提请技术委员会注意（有关更多信息，请参阅 技术委员会网页）。

如果您接管了一个旧软件包，您可能希望在错误跟踪系统中被列为该软件包的官方维护者。一旦您上传了带有更新的 Maintainer 字段的新版本，这将自动发生，尽管上传完成后可能需要几个小时。如果您预计在一段时间内不会上传新版本，您可以使用 第 4.10 节，“软件包跟踪系统” 来获取错误报告。但是，请确保旧维护者对他们在此期间继续收到错误报告没有异议。

移植者有一项艰巨而独特的任务，因为他们需要处理大量的软件包。理想情况下，每个源代码软件包都应该开箱即用。不幸的是，情况往往并非如此。本节包含一份“陷阱”清单，这些陷阱通常是由 Debian 维护者造成的——常见的问题经常难倒移植者，并使他们的工作变得不必要地困难。

首先也是最重要的是快速响应移植者提出的错误或问题。请以礼貌待人，对待移植者，就好像他们实际上是您软件包的共同维护者一样（在某种程度上，他们确实是）。请容忍简洁甚至不清楚的错误报告；尽力找出问题所在。

到目前为止，移植者遇到的大多数问题都是由源代码软件包中的打包错误引起的。以下是您应该检查或注意的事项清单。

如果软件包可以开箱即用地为要移植到的架构构建，那么您很幸运，您的工作也很轻松。本节适用于这种情况；它描述了如何构建和上传您的二进制软件包，以便将其正确安装到存档中。如果您确实必须修补软件包才能使其为其他架构编译，那么您实际上是在进行源代码 NMU，因此请查阅 第 5.11.1 节，“何时以及如何进行 NMU”。

对于移植者上传，源代码未进行任何更改。您无需触摸源代码软件包中的任何文件。这包括 debian/changelog。

调用 dpkg-buildpackage 的方式是 dpkg-buildpackage -B -mporter-email。当然，将 porter-email 设置为您的电子邮件地址。这将仅使用 debian/rules 中的 binary-arch 目标，对软件包的仅架构依赖部分进行仅二进制构建。

如果您在 Debian 机器上进行移植工作，并且您需要在本地签署您的上传以使其被存档接受，您可以在您的 .changes 文件上运行 debsign 以方便地对其进行签名，或者使用 dpkg-sig 的远程签名模式。

有基础设施和几个工具可以帮助自动化软件包移植。本节包含对此自动化和移植到这些工具的简要概述；有关完整信息，请参阅软件包文档或参考资料。

某些软件包在某些 Debian 支持的架构上构建和/或工作时仍然存在问题，并且根本无法移植，或在合理的时间内无法移植。一个例子是特定于 SVGA 的软件包（仅适用于 i386 和 amd64），或使用其他并非所有架构都支持的特定于硬件的功能。

为了防止损坏的软件包被上传到存档，并浪费 buildd 时间，您需要做几件事

请注意，仅将您的软件包添加到 Packages-arch-specific 而不使其在不受支持的架构上构建失败是不够的：移植者或任何其他尝试构建您的软件包的人可能会意外地上传它，而没有注意到它无法工作。如果过去在不受支持的架构上上传了一些二进制软件包，请通过针对 ftp.debian.org 提交错误报告来请求删除它们。

默认情况下，non-free 部分的软件包不会由自动构建器网络构建（主要是因为软件包的许可证可能不赞成这样做）。要使软件包能够被构建，您需要执行以下步骤

在进行 NMU 之前，请考虑以下问题

在进行 NMU 时，您必须首先确保您的 NMU 意图明确。然后，您必须将包含当前软件包和您提议的 NMU 之间差异的补丁发送到 BTS。devscripts 软件包中的 nmudiff 脚本可能会有所帮助。

在准备补丁时，您最好了解维护者可能正在使用的任何软件包特定实践。考虑到这些实践可以减轻将您的更改集成到正常软件包工作流程中的负担，从而增加集成发生的可能性。查找可能的软件包特定实践的一个好地方是 debian/README.source。

除非您有充分的理由不这样做，否则您必须给维护者一些时间来做出反应（例如，通过上传到 DELAYED 队列）。以下是建议用于延迟的一些值

这些延迟只是示例。在某些情况下，例如修复安全问题或修复阻止转换的琐碎错误，希望修复后的软件包更快地到达 unstable。

有时，发布管理器决定允许对一部分错误（例如 7 天以上的发布关键错误）使用较短的延迟进行 NMU。此外，一些维护者将自己列在 Low Threshold NMU 列表中，并接受在没有延迟的情况下上传 NMU。但即使在这些情况下，最好还是在上传之前给维护者几天时间做出反应，特别是如果补丁之前在 BTS 中不可用，或者如果您知道维护者通常很活跃。

在您上传 NMU 后，您将对您可能引入的可能问题负责。您必须密切关注软件包（在 PTS 上订阅软件包是实现此目的的好方法）。

这不是随意执行 NMU 的许可证。如果您在维护者活跃并且会在及时的方式下确认补丁的情况下进行 NMU，或者如果您忽略本文档的建议，您的上传可能会导致与维护者发生冲突。您应该始终准备好为您的任何 NMU 的智慧辩护。

与任何其他（源代码）上传一样，NMU 必须在 debian/changelog 中添加一个条目，说明此上传的更改内容。此条目的第一行必须明确提及此上传是 NMU，例如

  * Non-maintainer upload.

NMU 的版本控制方式对于原生和非原生软件包有所不同。

如果软件包是原生软件包（版本号中没有 Debian 修订版），则版本必须是上次维护者上传的版本，加上 +nmuX，其中 X 是从 1 开始的计数器。如果上次上传也是 NMU，则应增加计数器。例如，如果当前版本是 1.5，则 NMU 将获得版本 1.5+nmu1。

如果软件包不是原生软件包，您应该在版本号的 Debian 修订版部分（最后一个连字符后的部分）添加一个次要版本号。这个额外的数字必须从 1 开始。例如，如果当前版本是 1.5-2，则 NMU 将获得版本 1.5-2.1。如果在 NMU 中打包了新的上游版本，则 Debian 修订版设置为 0，例如 1.6-0.1。

在这两种情况下，如果上次上传也是 NMU，则应增加计数器。例如，如果当前版本是 1.5+nmu3（一个已经 NMU 过的原生软件包），则 NMU 将获得版本 1.5+nmu4。

需要特殊的版本控制方案以避免中断维护者的工作，因为使用整数作为 Debian 修订版可能会与在 NMU 时已在准备中的维护者上传发生冲突，甚至与位于 ftp NEW 队列中的上传发生冲突。它还具有使存档中的软件包明显不是由官方维护者制作的优点。

如果您将软件包上传到 testing 或 stable，您有时需要“fork”版本号树。例如，安全上传就是这种情况。为此，应使用 +debXYuZ 形式的版本，其中 X 和 Y 是主版本号和次版本号，Z 是从 1 开始的计数器。当发布版本号尚不清楚时（testing 常常如此，在发布周期的开始时），必须使用高于上次稳定发布版本号的最低发布版本号。例如，当 Lenny（Debian 5.0）是稳定版时，针对版本 1.5-3 的软件包的稳定版安全 NMU 将具有版本 1.5-3+deb50u1，而针对 Squeeze 的安全 NMU 将获得版本 1.5-3+deb60u1。在 Squeeze 发布后，针对 testing 发行版的安全上传将版本化为 +deb61uZ，直到知道该版本是 Debian 6.1 还是 Debian 7.0（如果成为这种情况，上传将版本化为 +deb70uZ）。

在您请求 NMU 许可后不得不等待响应效率低下，因为它会使 NMU 者在返回问题时产生上下文切换。DELAYED 队列（请参阅 第 5.6.2 节，“延迟上传”）允许进行 NMU 的开发者同时执行所有必要的任务。例如，您应该将软件包上传到 DELAYED/7，并告知维护者他有 7 天的时间做出反应，而不是告诉维护者您将在 7 天后上传更新的软件包。在此期间，维护者可以要求您进一步延迟上传，或取消您的上传。

DELAYED 队列不应用于对维护者施加额外压力。特别是，重要的是您能够在延迟到期之前取消或延迟上传，因为维护者无法自行取消上传。

如果您对 DELAYED 进行 NMU，并且维护者在其软件包的延迟到期之前更新了其软件包，则您的上传将被拒绝，因为存档中已有一个更新的版本可用。理想情况下，维护者会注意将您提出的更改（或至少是针对他们解决的问题的解决方案）包含在该上传中。

当有人 NMU 您的软件包时，这意味着他们想帮助您使其保持良好状态。这使用户可以更快地获得修复后的软件包。您可以考虑邀请 NMU 者成为软件包的共同维护者。在软件包上收到 NMU 并不是一件坏事；这只是意味着该软件包足够有趣，可以供其他人进行处理。

要确认 NMU，请在您的下一次维护者上传中包含其更改和 changelog 条目。如果您没有通过在您的 changelog 中包含 NMU changelog 条目来确认 NMU，则错误报告将保持在 BTS 中关闭状态，但将被列为影响您的维护者版本的软件包。

NMU 的全称是 source NMU（源代码 NMU）。还有另一种类型，即 binary-only NMU（仅二进制 NMU），或 binNMU。binNMU 也是由软件包维护者以外的人上传的软件包。但是，它是一个仅二进制上传。

当库（或其他依赖项）更新时，使用它的软件包可能需要重建。由于不需要更改源代码，因此使用相同的源软件包。

BinNMU 通常由 wanna-build 在 buildds 上触发。条目被添加到 debian/changelog 中，解释了为什么需要上传，并按照 第 5.10.2.1 节 “重新编译或仅二进制 NMU” 中的描述增加了版本号。此条目不应包含在下次上传中。

Buildds 将其架构的软件包作为仅二进制上传上传到归档。严格来说，这些是 binNMU。但是，它们通常不称为 NMU，并且不会向 debian/changelog 添加条目。

NMU 是由软件包的指定维护者以外的其他人上传的软件包。还有另一种类型的上传，其中上传的软件包不是您的：QA 上传。QA 上传是孤立软件包的上传。

QA 上传非常像正常的维护者上传：它们可以修复任何问题，甚至是小问题；版本编号是正常的，并且不需要使用延迟上传。区别在于您未被列为软件包的 Maintainer（维护者）或 Uploader（上传者）。此外，QA 上传的 changelog 条目具有特殊的首行

 * QA upload.

如果您想进行 NMU，并且似乎维护者不活跃，明智的做法是检查软件包是否已孤立（此信息显示在软件包的软件包跟踪系统页面上）。在对孤立软件包进行首次 QA 上传时，维护者应设置为 Debian QA Group <packages@qa.debian.org>。尚未进行 QA 上传的孤立软件包仍然设置了其旧维护者。在 http://qa.debian.org/orphaned.html 上有一个它们的列表。

除了进行 QA 上传外，您还可以考虑通过让自己成为维护者来接管软件包。您不需要任何人的许可即可接管孤立软件包，您只需将自己设置为维护者并上传新版本（请参阅 第 5.9.5 节 “接管软件包”）。

有时，您修复和/或更新软件包是因为您是打包团队的成员（该团队使用邮件列表作为 Maintainer（维护者）或 Uploader（上传者），请参阅 第 5.12 节 “协同维护”），但您不想将自己添加到 Uploaders，因为您不打算定期为此特定软件包做出贡献。如果它符合您团队的策略，您可以执行正常的上传，而无需直接列为 Maintainer 或 Uploader。在这种情况下，您应该以以下行开始您的 changelog 条目

 * Team upload.

软件包通常在 unstable（不稳定版）中经过一定程度的 testing（测试）后安装到 testing 发行版中。

它们必须在所有架构上同步，并且不得具有使其无法卸载的依赖项；它们还必须在安装到 testing 时通常没有已知的发布关键错误。这样，testing 应该始终接近成为候选发布版。请参阅下文了解详细信息。

更新 testing 发行版的脚本每天运行两次，就在安装更新的软件包之后；这些脚本称为 britney。它们为 testing 发行版生成 Packages 文件，但它们以智能方式执行此操作；它们尝试避免任何不一致性，并且仅使用无错误的软件包。

从 unstable 包含软件包取决于以下条件

要了解软件包是否正在进入 testing，请参阅 testing 发行版的网页上的 testing 脚本输出，或使用 grep-excuses 程序，该程序位于 devscripts 软件包中。此实用程序可以轻松地在 crontab(5) 中使用，以便随时了解您的软件包进入 testing 的进度。

update_excuses 文件并不总是给出拒绝软件包的确切原因；您可能必须通过查找包含软件包会破坏什么来自行查找原因。testing 网页提供了一些关于可能导致此类问题的常见问题的更多信息。

有时，某些软件包永远不会进入 testing，因为相互关系集太复杂，无法通过脚本进行排序。请参阅下文了解详细信息。

一些进一步的依赖关系分析显示在 http://release.debian.org/migration/ 上——但请注意，此页面还显示了 britney 未考虑的构建依赖项。

testing 发行版根据上述规则从 unstable 中获取软件包。但是，在某些情况下，有必要上传仅为 testing 构建的软件包。为此，您可能需要上传到 testing-proposed-updates。

请记住，上传到那里的软件包不会自动处理，它们必须经过发布经理的手。因此，您最好有充分的理由在那里上传。为了了解在发布经理眼中什么是充分的理由，您应该阅读他们在 <debian-devel-announce@lists.debian.org> 上定期给出的说明。

当您可以通过 unstable 更新您的软件包时，您不应上传到 testing-proposed-updates。如果您不能（例如，因为您在 unstable 中有更新的开发版本），您可以使用此工具，但建议您首先向发布经理请求授权。即使软件包已冻结，如果通过 unstable 上传不会引入任何新的依赖项，则仍然可以通过 unstable 进行更新。

版本号通常通过添加 testing 发行版的代号和一个运行编号来选择，例如 1.2squeeze1 用于通过 testing-proposed-updates 上传的软件包版本 1.2 的第一次上传。

请确保您没有错过上传中的任何这些项目