问为什么与Ubuntu相比，Debian压缩要花费这么多时间？

EN

Debian和Ubuntu之间的发布过程非常不同。Ubuntu的发布基于时间安排(设定发布日期)，而Debian则使用“准备就绪”的模型。

以下是影响发布速度的一些要点：

1. 大多数Ubuntu从Debian获得的包都不受官方支持(宇宙存储库)
2. Ubuntu支持2种体系结构，而Debian支持13种(某些发布的关键bug是特定于体系结构的)
3. Ubuntu没有“发布关键”bug的直接概念，尽管它具有“关键”bug严重性。
4. 只有第四个Ubuntu发行版(LTS)推荐用于生产使用。

正如约丹所指出的那样，发布周期是不同的: Ubuntu在任何情况下都会在每年4月和10月发布，而Debian则在testing准备好成为stable时发布，这是由发布团队决定的(部分基于发布关键的bug计数)。

另一个巨大的区别是:规范雇佣人员支持Ubuntu的核心，而Debian没有为用户提供工作的基础设施。有些人确实在Debian上工作，这是他们工作的一部分，但是Debian中的任何人都无法命令Debian贡献者进行任何特定的工作，包括修复版本关键的bug。所以没有人能说“用这样的日期来解决这些问题，否则！”(另一方面，我认为大多数Debian开发人员都希望发布该版本，所以.)

在这个阶段仍然需要修复的关键版本错误大多是复杂的bug，很难复制，很难修复和/或难以验证。对于志愿者撰稿人来说，这些可能会让他们失去动力；在某些情况下，很难证明花上几十个小时在一个bug上工作是没有道理的，因为它甚至不会影响修复bug的人。

(在没有人选择之前，现在已经有了支付Debian开发人员在Debian上工作的基础设施，但这无助于推出新版本。)

首先，因为Ubuntu可以(而且应该)将它们的bug“上游”地传递出去。第二，因为Debian的分支比Ubuntu定义得更多。还有更多的步骤来标记在Debian中完成的bug，然后在Ubuntu中标记一个bug。最重要的是，Ubuntu是一个“下游”版本。这意味着他们可以得到Debian所拥有的所有bug修复，这样他们就可以专注于其他bug，而Debian实际上正在修复Debian bug和Ubuntu bug。

例如，Ubuntu中的foo.deb中有一个bug被标记为“上游”，需要由Debian修复。bar.deb中的bug需要在Ubuntu和Debian中修复。Ubuntu团队可以忽略foo.deb，专注于bar.deb，而Debian则需要在foo.deb和bar.deb上工作。

另一个例子是发布周期。Ubuntu的发布周期比Debian的要简单得多，例如，在Debian中的包在进行测试之前在“不稳定”中停留6-12个月或更长时间并不奇怪。然后再花6个月的时间进行测试，然后才能达到“稳定”。对于debian来说，这是很棒的，因为您可以在Debian稳定平台上运行关键任务服务器，而不必愚弄它。在Ubuntu上运行关键任务服务器不太理想(即使是LTS版本)，因为它们不太稳定，而且问题也更多。但对于小型服务器或台式机来说，这种区别通常并不重要。