据报道，Debian 开发人员还需要消除 54 个错误。这些被称为“发布关键错误”。我的问题是，
如果修复 bug 需要这么长时间，那么 Ubuntu 为什么会在这么短的时间内发布每个版本呢？
我的意思是，他们如何在这段时间内消灭这些错误？如果他们真的这样做了，那么为什么 Debian 不从 Ubuntu 获得调试后的代码呢？这些“发布严重错误”现在不应该被调试吗？由于Ubuntu使用Debian的testing/unstable作为基础，然后进行发布；显然 Ubuntu 不会发布有缺陷的版本。这对我来说没有意义。
答案1
Debian 和 Ubuntu 的发布流程非常不同。Ubuntu 发布基于时间表（设定发布日期），而 Debian 使用“准备就绪”模型。
以下是影响发布速度的一些关键点：
- Ubuntu 从 Debian 引入的大多数软件包均不受官方支持（universe 存储库）
- Ubuntu 支持 2 种架构，而 Debian 支持 13 种（某些版本的关键错误特定于某个架构）
- Ubuntu 没有“发布关键”错误的直接概念，尽管它确实有“关键”错误严重性
- 仅建议将第 4 个 Ubuntu 版本 (LTS) 用于生产用途。
答案2
作为约旦已经指出，发布周期是不同的：Ubuntu 每年四月和十月发布，无论发生什么，而 Debian 则在testing准备就绪时发布stable，由发布团队决定（部分基于发布关键错误计数）。
还有另一个巨大的区别：Canonical 雇佣人员来支持 Ubuntu 的核心，而 Debian 没有基础设施来支付人员在其发行版上工作的费用。有些人确实将 Debian 工作作为其工作的一部分，但 Debian 中的任何人都无法命令 Debian 贡献者从事任何特定的工作，包括修复发布关键的错误。因此，没有人可以说“在某某日期修复这些问题，否则！” （另一方面，我认为大多数 Debian 开发人员都希望发布该版本，所以......）
现阶段仍需要修复的发布关键错误大多是复杂的错误，难以重现、难以修复和/或难以验证。这些可能会特别打击志愿者贡献者的积极性；在某些情况下，花费数十个小时来处理一个甚至不影响修复该错误的人的错误可能很难证明是合理的。
（在任何人挑剔之前，现在已经有基础设施可以支付 Debian 开发人员在 Debian LTS 上工作的费用，但这无助于发布新版本。）
答案3
首先，因为 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 版本），因为众所周知它们不太稳定且问题较多。但对于较小的服务器或台式机来说，这种区别通常并不重要。