据报道，Debian 开发人员还需要解决 54 个错误。这些被称为“发布关键错误”。我的问题是，
如果这个 bug 压缩需要这么多时间，那么 Ubuntu 怎么会在这么短的时间内发布每个版本？
我的意思是，他们如何在这段时间内消除错误？如果他们真的这样做了，那么为什么 Debian 不从 Ubuntu 获得调试过的代码呢？现在不应该调试这些“发布关键错误”吗？由于Ubuntu使用Debian的testing/unstable作为基础，然后发布它们；显然 Ubuntu 没有发布有缺陷的版本。这对我来说没有意义。
jor*_*anm 12
Debian 和 Ubuntu 之间的发布过程非常不同。Ubuntu 发布基于时间表（设置发布日期），而 Debian 使用“何时准备就绪”模型。
以下是影响发布速度的一些关键点：
作为jordanm指出，释放周期是不同的：Ubuntu的发布每年四月和十月，来了可能，而Debian的发行版时，什么testing是准备好成为stable，由发行团队确定（部分基于严重错误的计数） .
还有另一个巨大的区别：Canonical 雇用人员来支持 Ubuntu 的核心，而 Debian 没有基础设施来支付人们在其发行版上工作的费用。有些人确实在 Debian 上工作作为他们工作的一部分，但 Debian 中的任何人都无法命令 Debian 贡献者从事任何特定的工作，包括修复发布关键错误。所以没有人可以说“在某某日期之前解决这些问题，否则！” （另一方面，我认为大多数 Debian 开发人员都希望发布该版本，所以......）
在此阶段仍需要修复的发布关键错误大多是复杂的错误，难以重现、难以修复和/或难以验证。对于志愿者贡献者来说，这些可能特别令人沮丧；在某些情况下，很难证明花费数十个小时来处理甚至不影响修复错误的人的错误。
（在任何人挑剔之前，现在有基础设施可以支付 Debian 开发人员在 Debian LTS 上工作的费用，但这无助于发布新版本。）
首先，因为 Ubuntu 可以（并且应该）将它们的错误传递到“上游”。其次是因为 Debian 的分支比 Ubuntu 更明确。在 Debian 中标记 bug 已完成的步骤比在 Ubuntu 中更多。最重要的是，Ubuntu 是一个“下游”版本。这意味着他们可以获得 Debian 拥有的所有错误修复，以便他们可以专注于其他错误，其中 Debian 有效地修复了 Debian 错误和 Ubuntu 错误。
例如，Ubuntu 中 foo.deb 中的错误被标记为“上游”，需要由 Debian 修复。Ubuntu 和 Debian 中需要修复 bar.deb 中的错误。Ubuntu 团队可以忽略 foo.deb 并专注于 bar.deb，而 Debian 团队需要处理 foo.deb 和 bar.deb。
另一个例子是发布周期。Ubuntu 的发布周期比 Debian 简单得多。例如，Debian 中的某个软件包在进行测试之前停留在“不稳定”状态 6-12 个月或更长时间，这并不奇怪。然后再花 6 个月进行测试，然后达到“稳定”。对于 Debian 来说，这非常棒，因为您可以在 Debian 稳定版上运行关键任务服务器，而不必愚弄它。在 Ubuntu 上运行关键任务服务器不太理想（即使是 LTS 版本），因为众所周知它们不太稳定且问题较多。但对于小型服务器或台式机来说，这种区别通常并不重要。