问题描述
据报道，Debian开发人员需要更多解决54个bug。这些被称为“发布关键错误”。我的问题是
如果这个bug-squashing花了这么多时间，那么Ubuntu如何在这么短的时间内发布每个版本？
我的意思是，他们如何在这段时间内解决这些错误？如果确实如此，那么Debian为什么不从Ubuntu获得调试的代码？这些“发布关键错误”现在是否应该调试？由于Ubuntu以Debian的测试/不稳定为基础，然后发布它们；很明显，Ubuntu不会发布错误版本。这对我来说毫无意义。
最佳思路
Debian和Ubuntu之间的发布过程非常不同。 Ubuntu的发布基于时间表(设置发布日期)，而Debian使用“准备就绪”模型。
以下是一些影响发布速度的关键点：
-
官方不支持Ubuntu从Debian提取的大多数软件包(通用存储库)
-
Ubuntu支持2种体系结构，而Debian支持13种(某些发行关键错误特定于一种体系结构)
-
Ubuntu没有”release critical”错误的直接概念，尽管它具有”critical”错误严重性
-
建议仅将第4个Ubuntu版本(LTS)投入生产。
次佳思路
正如jordanm所指出的那样，发布周期不同：Ubuntu每年4月和10月发布，而Debian在testing准备好成为stable时发布，这由发布团队确定(部分基于release-critical bug-count)。
还有另一个巨大的区别：Canonical雇用人员来支持Ubuntu的核心，而Debian没有基础设施来支付人们在其发行版上的工作。有些人确实将Debian做为工作的一部分，但是Debian中的任何人都无法命令Debian贡献者从事任何特殊的工作，包括修复release-critical错误。因此no-one可以说“用such-and-such将其修复为日期，否则！” (另一方面，我认为大多数Debian开发人员都希望将其发布，所以…)
在此阶段仍需要修复的release-critical错误大多数是复杂的错误，难以复制，难以修复和/或难以验证。对于志愿捐助者，这些尤其是de-motivating。在某些情况下，花数十小时来研究一个错误，甚至不影响修复该错误的人，可能很难证明是合理的。
(在任何人nit-picks之前，现在已经有基础设施来支付Debian开发人员使用Debian LTS的费用，但这并不会有助于发布新版本。)