我的 12.2 在哪里，我的 12.2，我愿意付出一切！

很多人已经注意到，这个 openSUSE 版本的里程碑和 Beta 版本已经被推迟甚至取消，比如里程碑 4。现在 RC 计划于周四发布 - 但这似乎不太可能实现，因为 Factory，我们的开发项目，仍然太不稳定了。Coolo 向 openSUSE Factory 邮件列表 发送了一封邮件，指出我们需要重新思考我们的工作方式。

我们需要新的想法

Coolo 的邮件是对 openSUSE 的一个警钟。目前，我们通过 devel 项目进行工作，这些项目协作地向 Factory 提交更好的软件包。但即使这样，有时会出现重大问题，而且由于我们社区的增长，这种问题出现的频率越来越高。解决这个问题的方法之一是更广泛地使用“staging 项目”，在软件包移动到 Factory 之前进行更深入的测试和更多的集成。我们还可以采取的另一个方向是建立在我们的优势之上，例如 OBS 和 Tumbleweed。放慢我们的发布周期，以产生更稳定的版本，例如每年一次，同时加大对 Tumbleweed 和我们的 OBS 仓库中更新软件的重视和投入，可以为“前沿”爱好者和依赖于稳定 openSUSE 的用户提供他们想要的东西。或者，我们可以放宽我们的发布计划，在 openSUSE “准备好”时发布。

所有选项都有优点和缺点。我们不想迷失自我：引入规则和程序来解决问题不是我们的方式。因此，我们需要新的想法，并向其他方向看。现在是讨论这些事情的时候了：我们正在撞击我们工作方式的极限，因此紧迫感是存在的！

限制：延误和取消

openSUSE 12.2 的几乎每个里程碑都已延误甚至取消。与初步计划相比，里程碑 1 到 3 仅晚了一到两周 - 但里程碑 4 必须取消，即使 Beta 1 也晚了两周。发布候选版本 1 也无法按时发布 - 为了使 Factory 接近可发布状态，我们需要考虑严重的延误。

怎么回事？

里程碑面临着通常的问题。有时，Buildservice 会崩溃 - 并且由于正在进行的大量开发，它需要一段时间才能处理其积压并赶上来。另一个问题是一些大功能集成出现的问题 - 最值得注意的是 GCC 4.7，但 Automake 仍然会造成很大的麻烦。一般来说，openSUSE Factory 的稳定性并不像我们通常的标准那么高，正如 Factory 邮件列表存档 中显示的许多线程一样。

不是偶发事件

但 Coolo 认为，这些集成问题不仅仅是偶发事件，而是暴露了更深层的问题。openSUSE 的贡献在过去几年中有所增长，但我们过去的工作方式无法扩展到我们当前的大小。

破碎的窗户

随着越来越多的新贡献者提交更大和更小的改进，以及 openSUSE 中进行着大量的管道工作，问题正在出现。所有这些变化都需要结合、集成、使其成为一个整体。有些人需要着眼于全局。这没有以应有的速度发生，因此 Factory 中的东西比以往任何时候都更容易出现故障。这导致了一点 破碎的窗户问题：破坏得越多，人们越不在乎，完成任何事情就越困难 - 从而让贡献者感到沮丧。欢迎来到恶性循环。

所有这些都让我们到达了发布经理不相信我们能够按时发布 openSUSE 的地步。实际上，Coolo 认为如果我们要进行任何适时的发布，就需要做出改变。看起来是一个挑战！

新的方向

我们需要花时间思考并改变事物。发布将被推迟，这是肯定的。但是我们将来如何应对？由于我们已经变得太大，无法采用当前模式，我们有机会找到新的方法。

仅仅增加更多的人并不能解决问题。特别是对工具链的重大更改，只需要一个由经验丰富的核心黑客组成的团队才能在合理的时间范围内修复所有问题，以避免“破碎的窗户”。虽然我们呼吁人们站出来，但我们也需要向其他方向看。

发布计划和 staging 项目

我们可以放弃固定的发布计划，并在“准备好”时发布。但这可能会导致长时间的冻结（像 Debian 一样），用户的不确定性，以及过时的软件包或质量差异巨大。

Coolo 说放弃发布，将 openSUSE 变成 tumbleweed-on-SLE 也是可行的。但是 - 仅提及这个方案的一个问题，Tumbleweed 需要基于新版本进行重新构建，因为它不是设计用于永远滚动。因此，它将依赖于新的 SLE 版本进行主要的管道工作，这实际上只是将问题转移到了 SUSE。

[caption id=”attachment_12917” align=”alignright” width=”150” caption=”Devel feeds Factory”][/caption]

Coolo 建议的另一个步骤是仔细研究我们的工作方式。在 Devel 项目中工作很好，但会导致集成问题。使用更多的 staging 项目需要工具支持，并不能解决所有问题，但这是朝着正确的方向迈出的一步。

组合？

解决方案可能存在于上述任何方向 - 或所有方向中。一个可能的方案是稍微放慢发布周期，每年发布一次（可能在四月左右），并变得更加保守：发布将包含更改，但只有经过充分测试和稳定的新技术才会包含在内。与此同时，我们将更加强调 Tumbleweed 和 OBS 仓库，作为获取最新和最伟大的自由软件的方式。我们还需要改变我们的工作方式，引入 staging 项目，也许改进 OBS 工作流程的某些部分。对于最终用户，我们可能会发布 Tumbleweed 的“快照”，或者试验我们可以通过 SUSE Studio 提供的内容。

如果有效，这个方案将意味着发布团队的工作量更低，我们的最终用户有更多的选择：更稳定（发布）和更最新（tumbleweed）。与所有重大更改一样，它存在风险，并且需要对细节进行大量的思考。但最终结果可能是更好、更酷的 openSUSE！

讨论

作为一个社区项目，openSUSE 由愿意承担责任并发挥作用的人领导。现在应该由这些人站出来，指出我们需要前进的方向。Coolo 呼吁每个人

公开讨论事情 - 我认为我们已经了解了当前模式有效和无效的地方，因此我们可以一起开发新的模式。

openSUSE 面临着一项挑战，而且是一项有趣的挑战。我们会怎么做？Factory 邮件列表上的讨论才刚刚开始，我们不会很快做出决定。有一点是肯定的：openSUSE 12.2 不会在 7 月 11 日看到光明，但我们会为未来带来一些很棒的东西！