Fedora Linux 37 会迟到； 很晚了。 这就是为什么。 您可能听说过， OpenSSL 项目公布了一个版本 定于周二发布。 它将包括对严重严重错误的修复。 在周二发布之前，我们不会知道问题的细节，但它可能很重要。 因此，我们决定推迟发布 Fedora Linux 37. 我们现在 目标是 11 月 15 日的发布日.
信息不完善
大多数决策都是在信息不完整的情况下发生的。 这个特别不完美。 如果您不熟悉禁运流程，您可能不明白为什么。 当发现安全问题时，通常会与项目保密地共享此信息。 这允许开发人员在更多人知道并利用它之前解决问题。 然后，项目与下游共享信息，以便他们做好准备。
讽刺地， Fedora的开放性意味着我们不能提前开始准备。 我们所有的构建管道和工件都是开放的。 如果我们要开始构建更新，这将在禁运解除之前披露漏洞。 因此，我们只知道 OpenSSL 认为这是最高级别的严重性，Red Hat 的产品安全团队强烈建议我们在发布之前等待修复 Fedora Linux 37.
平衡时间和质量
作为 Fedora 项目经理，我们的发布时间表是我的责任。 我为从前任那里继承的准时发布记录感到自豪。 我们一直在进行 Fedora Linux 34 于 2021 年 4 月发布。在那段时间，我们进行了重大的技术更改（例如切换到 Btrfs 作为大多数变体的默认设置），并让彼此经历了一场大流行。 我为社区在困难的情况下能够取得的成就感到自豪。
但准时并不是唯一的因素。 我们知道您依赖 Fedora Linux 用于工作和娱乐，因此质量始终是一个考虑因素。 知道我们要延迟 OpenSSL 漏洞，问题变成了“多长时间”？
我们在星期四做出“去/不去”决定，以便在下周二发布。 这为镜像更新到镜像提供了时间。 OpenSSL 项目团队计划在我们为 11 月 8 日的目标做出决定前约 48 小时发布安全修复程序。 考虑到构建更新的 openssl 包并生成候选版本的时间，这给了我们大约一天半的时间来进行测试。 没有足够的时间来适应对如此重要的软件包的更改。
因此，我们给自己额外的一周时间，这样我们就可以确信 Fedora Linux 37 具有您所期望的相同质量水平。
这是正确的决定吗？
时间会证明我们是否做出了正确的决定。 今天的 Go/No-Go 会议很热闹，并不是每个人都同意我们应该因此而推迟发布。 就像我说的，我们没有什么信息可以继续。 重要的是要注意，这个决定是作为一个团队做出的，而不是一个人的命令。 Fedora 重视协作决策，这是一个很好的 example.
当周二公布细节时，我们可能会“哇，推迟发布不值得”。 但我认为我们根据现有信息做出了最好的决定。
同时，请在 11 月 4 日至 5 日加入我们 Fedora Linux 37 发布派对。 即使版本还没有完全发布，它也会很有趣。
