LWN: Fedora和各种edition！

关注了就能看到更多这么棒的文章哦～

Fedora and its editions

By Jake Edge
December 8, 2020
DeepL assisted translation
https://lwn.net/Articles/839214/

Fedora 一直有独立的工作站（Workstation edition）和服务器版本（Server edition），并在 8 月份的时候新增了一个针对物联网（IoT）设备的版本。这些版本针对发行版的不同使用场景，基于同样的理由，CoreOS 这个特殊版本的出现了。它是针对云和 Kubernetes 环境部署用途的。最近在 Fedora 开发邮件列表中有关于将 Fedora CoreOS 提升为完整版（full edition）来作为 Fedora 34 的一部分的讨论。其中也讨论了某个发行版成为 Fedora 的一部分意味着什么。

Fedora CoreOS edition

Fedora 项目经理 Ben Cotton 在 12 月初提出了这个建议。他认为让 Fedora CoreOS 成为官方版本 "将有助于提升采用率，并能将 Fedora 定位为运行容器工作流程（container workflow）的可靠解决方案"。按提案中描述的，听起来并没有多少工作需要做，因为 "Fedora CoreOS 已经创建好并发布出来了"。Neal Gompa 同意这个想法，称这只是一个 "paperwork change"。

然而，Adam Williamson 并不那么确定，因为 Fedora CoreOS 有很多边边角角的地方还相当粗糙。他担心，如果这种情况在 Fedora 34 中得不到改善，人们会提出 "尴尬的问题"。比如：

注意，如果你现在去 getfedora.org 点击 CoreOS，那么它会给你提供一个基于 Fedora 32 的 CoreOS。这种行为，在新兴版本（Emerging Edition）还是可以接受的。但是我认为对于一个正式 Edition 来说，不可以接受这种表现。如果我们接受 CoreOS 作为一个版本，那么在 Fedora 34 "发布" 两个月后，我们的 "stable" CoreOS 仍然是基于 Fedora 33 的，这就看起来很糟糕了。

Dusty Mabe 介绍了 Fedora CoreOS 版本发布的一些细节。发行版有三个 "分支（stream）"，分别是 stable、next 和 testing，这三个分支的做法并不相同。目前 stable stream 来自 Fedora 32，但 next 和 testing stream 都是基于 Fedora 33。"如果你想要 Fedora 33，而且你是 Fedora CoreOS 用户，你可以很容易地采用有 Fedora 33 的那个 stream"。Fedora CoreOS 默认会进行自动更新，而 Fedora 33 中出现的几个改动可能会造成破坏，所以团队正在努力解决这些问题，之后才能切换缺省版本。

理想情况下，我们会将 stable stream 按照接近 Fedora 真正发布时间的日子来更新 stable stream，但我认为更好的做法也许是不要把 Fedora CoreOS 与 Fedora major release 的发布日期绑定起来，原因有几个：

• 我们的有些用户是持续跟踪 stream 的更新，系统会自动进行更新

• 这样更像是一个 "滚动发布(rolling)" 的版本，日常持续进行功能改进并且定期做 rebase

• • 这与 Atomic Host 的做法不同，那些情况下你必须手动决定什么时候来进行 rebase 升级。

  • 一直在增加新功能，可能做到一半就加进来了，所以这里更像是一个持续开发（continuous development）模式。

在讨论中另一个子线程里，Williamson 描述了如果提升 IoT edition 的地位会带来的一些问题，他认为这些问题对于 CoreOS 来说会更糟糕："我认为有很多我们在 IoT 上遇到的问题，但是会在 11 版本出现。" 例如，Fedora CoreOS 跟 Fedora 主版本的编译工具都不一样，也没有跟 Fedora edition ecosystem 生态系统整合好：

所以我们来归结出一个有代表性的问题：当我们在大约四个月后做 Fedora 34 Go/No-Go （确定是否能够发布的）会议时，我们如何决定是否要发布 "Fedora CoreOS 34"？

在 CoreOS 的构建和发布相关方面，"Fedora CoreOS 34 准备好了吗 "这个问题到底意味着什么？我们将决定发布或不发布哪些部分，以及如何决定、沟通？我们将在哪里看到测试结果和判定标准，从而以此结果来做出决定？

Gompa 似乎改变了想法，他同意目前 CoreOS 与项目的其他部分并没有很好的结合。他指出，这已经导致了一些真的问题：

Fedora CoreOS 以这种方式工作的一个非常糟糕的后果是，他们基本上不参与关于 Changes（改动） 讨论，而是在没有提前预警或文档的情况下就开始按新的方法来进行改动。当 Fedora CoreOS 在核心的、基本的部分与 Fedora 的其他版本有差异时，这已经出现了问题。甚至曾经在无意中发生过这种问题，由于 Fedora CoreOS 使用了错误的 iptables variant 而意外地跟 Fedora (和 RHEL CoreOS!) 不一致了：https://github.com/coreos/fedora-coreos-tracker/issues/676。

Integration difficulties

Jonathan Lebon 承认，集成 CoreOS 出现过一些问题，但 "我们的目标总是尽可能地匹配 Fedora"。iptables 问题是个 "不幸的失误"。在构建工具方面，他表示，CoreOS Assembler 和 OSBuild 团队之间正在进行讨论，以找到共同解决方法，但这些改动都还需要一段时间。同时，"我们愿意以任何必要的方式与 Fedora 工作流程整合起来"

Cotton 同意 Williamson 关于两边需要协调一致的看法，他还想知道是否有很多问题需要解决，从而将这一改动推到 Fedora 35 时：

我明白其中的道理，但我真的希望看到 FCOS[Fedora CoreOS]能与其他版本的发布日程保持一致，或者至少制定一个清晰简洁的解释，说明为什么会延迟，让公众以及科技媒体可以理解。

但作为提案者的 Clement Verna 担心 Fedora CoreOS 根本无法融入现有的工作模式：

Fedora CoreOS 34 并不存在，而是有 Fedora CoreOS stable、testing 和 next 这几个分支，每个分支都是每 2 周发布一次。Go/No-Go 的判断是基于每个分支上得到的报告，然后 next stream 就会被晋升为 testing stream，testing 则提升为 stable。如果在 next 或 testing 中发现任何阻碍发布的问题，那么都不会被提升为 stable 版本。

他指出在设计文档(https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#release-streams) 里面有提到关于这些 stream 的切换流程的更多细节。Verna 想知道 "edition" 的定义具体是什么，同时，他也认为 Fedora 本身需要进行一些修改来适应 Fedora CoreOS。"我认为，如果我们不想接受关于发布时间表和发布流程的理念的不同之处，那么我们本可以直接关闭这个提案了。" Williamson 说，他并不希望拒绝这个提案，而只是想在通过此提案之前，先把影响想清楚。

[……]我们如何把公众对于 Fedora 的清晰印象，即 "Fedora 是一个(或一组)产品，每六个月发布一次，请留意我们的 Fedora XX 版本的公告！" 转变到 "Fedora 是这样的，但它还有另外一个部分，它有三个 stream，每两周发布一次，并完全忽略 6 个月的这种规律而是进行滚动发布"？诸如此类的问题我们需要思考。

我并不是说这些东西会阻碍这个提案，我是说这些东西是 需要考虑而作为实施改动 的一部分，并决定相应的改动时间规划。

花了一点时间来回争论之后，Verna 现在想到了一些改进提案的想法(https://lwn.net/ml/fedora-devel/CAHTjmtZinKm9y=bwupO6nSphtzAm8JZL0FDVRMiVyWtfqOwh-g@mail.gmail.com/)，希望能解决 Williamson 和其他人的担忧。Fedora 项目负责人 Matthew Miller 也有一些想法(https://lwn.net/ml/fedora-devel/20201202205709.GA24264@mattdm.org/)，关于成为 edition 代表了什么意义，以及如何将某些发布版本跟传统的六个月节奏脱钩。事实上，他对今后的发展有一个更广阔的愿景：

Fedora Workstation，这是我们最受欢迎的桌面产品，它将继续保持熟悉的 4 月/10 月发布节奏。Silverblue、IoT 和 CoreOS 这些其他 Fedora 操作系统变种，可以遵循滚动发布模式。我们的 KDE Plasma Desktop 会遵循 upstream 的 KDE 发布周期，也就是每四个月发布一次，并使用当时最新的 Fedora 软件版本。（最后这句话显然不是真实情况，但我希望它可以实现）。另一方面，我们的 Fedora School OS 变种 （现在也不存在）则每年只在五月底更新一次，这样学校的 IT 团队可以在夏天部署，直到下一个夏天之前都不用再操心升级的事情。

Whither Server?

Miller 没有提到 Fedora Server edition，这是因为讨论中的另一个子话题中已经讨论过了 Server 版本的未来。在回复他自己发布的建议改动时，Cotton 指出，把 CoreOS 加入进来的这个讨论引发他想起了一个 "不舒服的问题"：Server edition 是否应该被 "降级(demoted)"？他建议还是需要创建这个 Server edition，但也许应该不再强调它。Server working group 已经不再活跃，不过这个 edition 仍旧得到维护。虽然 Fedora CoreOS 并不是针对 Server edition 的替代品，但现在似乎也成为了一个机会。他说，另一个替代方案就是重新将 working group 的工作提升起来。

Gompa 说，有人希望提供帮助来恢复 Server working group 的工作，但 Williamson 不确定是否真的有这个需要。Server edition 基本上处于休眠状态，因为它现在的方式也能工作得很好。当然，如果不再是一个 edition 的话，现有的模式也同样可以继续，但 "我不确定是不是只是因为它有点平静且不引人注目就需要来对它降级，特别是，我们还没有明确的替代品来取代它"。

但 Cotton 显然更希望看到这个 Server project 能更积极一点，更加主动一点，如果它想要成为 Fedora 的旗舰产品之一的话。他指出，这个工作组 "至少在过去两年中看起来都是处于僵尸状态"。尽管，Server 发行版确实不应该太超前，但是 "Fedora Server 是在做现在该做的事情，还是在做两年前就应该做的事？"

Miller 也更希望 Server 能继续保持作为一个 edition，"但我们需要它变得更活跃才行"。Gompa 愿意帮助 working group 来重新进入更活跃的状态，但他担心我们的决策是基于 "仅仅因为需要做改变而去做改变"。但这并不是米勒想要表达的意思：

这不是一个为了改变而改变的问题，我希望我们能在 Fedora 服务器上有一定程度的创新和实验。还有就是一些正常的工作，比如准备市场推广材料、进行推广、写博客文章、撰写文档等，都可以持续进行的。

许多人站出来说他们愿意帮忙，这导致了之前奄奄一息的 Fedora server mailing list 中出现了一个邮件。在这则发起邮件中，Miller 概述了需要解决的各种问题，目前也已经有几个人表示愿意提供帮助。看来，Server working group(以及相应的 Server edition)将再次崛起。

目前，Fedora 和 CentOS 这两个同属于 Red Hat 的社区发行版(community distribution)之间有一些重叠。所以，12 月 8 日宣布的切换到 CentOS Stream，可能也是导致这个改动的因素。CentOS 一直是很多人的 "首选" 服务器发行版，目前还不清楚 CentOS Stream 是否还能胜任这一角色。如果不是，可能会有更多的人使用 Fedora Server，哪怕支持周期仅为一年。总的来说，对于 Fedora 和 CentOS 来说，这是一个变革的时代，尘埃落定还需要一些时间。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～