LWN: Fedora 再次进行Git-forge的讨论！
关注了就能看到更多这么棒的文章哦～
Fedora revisits the Git-forge debate
By Jake Edge
December 1, 2021
DeepL assisted translation
https://lwn.net/Articles/877240/
针对正在进行的 Fedora 选举的候选人的一个看起来很简单的问题，在 Fedora 开发邮件列表中引发了一场讨论，并扩展到了几个不同的方向。这个问题与该发行版曾经有过的挣扎有关：是否应该使用非自由（non-free）的 Git forge 工具。不过这次有所不同，讨论的重点是 source-git(或称 src-git) 仓库应该被托管在什么地方，这跟之前讨论的 dist-git 仓库的存放位置不是同一个问题。
Background
正如 Tomáš Tomeček 在 2020 年 5 月所描述的那样，dist-git 仓库是发行版中大部分软件包的创建和测试工作进行的地方。dist-git repository 目前对这个任务完成得相当好，特别是对那些熟悉它的使用方式的人来说，但它与 upstream 项目使用的 Git 仓库有很大不同。也有一些问题：
对于某些任务来说，工作流程是很不错的，而且相当直观。但对于其他任务来说，这个流程就很难用了——尤其是当你需要处理 patch 文件的时候，各种麻烦就就来了。我们居然还需要在 git 仓库中使用 patch 文件，这一点让我感到匪夷所思。
Tomeček 在介绍 source-git 的 blog 中给出了关于 dist-git 的更多信息。每个 Fedora 软件包都有一个 dist-git 仓库，它提供了创建最终发送给用户的 binary RPM 包所依赖的一切材料。其中包括 RPM spec 文件、源代码、Fedora 专用的 patch、tests 等等。
dist-git 库过去一直（现在也是）托管在 Fedora Pagure 代码托管系统上的，但是维护 Pagure 系统已经成为管理 Fedora 基础设施的 Red Hat Community Platform Engineering （CPE）团队的一个头痛问题。早在 2020 年 1 月的时候就提出了提案来收集对 Git-forge 解决方案的需求，期望用这个解决方案来满足 Red Hat 管理的所有发行版（Fedora、CentOS 和 RHEL）的需要。在 CPE 宣布选择 GitLab 之后，这个非常激烈的过程结束了，很多 Fedora 社区的人认为这已经是一个既成事实了。大约一年半之后，公布了一个针对 Fedora 的 GitLab 托管服务，其中包括一些专有的（proprietary） "ultimate tier" 功能，但 Pagure 系统仍将暂时继续提供服务：
我知道你们中的一些人想知道这对 Pagure.io 和 dist-git 意味着什么。社区平台工程（CPE）团队将像现在一样继续运行这些服务，保持继续支持模式。随着 GitLab 的出现，CPE 和 Source Git SIG 将继续探索 FESCo [Fedora 工程指导委员会] 的反馈，了解如何使 dist-git 在未来的 GitLab 上的托管变得更加可行。我们还将寻找方法将 Gitlab 整合到我们更多的工具中，从而为社区提供更多选择。不过现在，这只是为你增加了一个选项而已。如果你想把你的工作保留在 Pagure 上，那么完全没有问题。
source-git 这个工作（它是 Packit 项目的一部分）是一个为 Fedora 软件包建立 Git 仓库的机制，它会把相应的 upstream 来源镜像下来，这样就能让 upstream 的开发者感到非常熟悉自在。事实证明，许多 Fedora 软件包都已经以这种方式创建出来了，但是都是临时性的。所以 source-git 增加了一些工具，可以使用发行版特有的 patch 和 build 配置环境（比如 RPM spec 文件）来创建一个 source RPM，可以在 dist-git 中使用从而最终为用户生成二进制 RPM。目前，source-git 已经与 GitLab 和 GitHub 集成，但没有与 Pagure 集成。
Question
在这样的背景下，Michael Catanzaro 向 FESCo 和 Fedora 理事会的候选人询问了他们对托管 source-git 仓库的想法，即 "你是否支持让 Fedora src-git 仓库托管在 gitlab.com 上 (这是一个专有的软件 git forge)？" 他指出，开源解决方案至少有两个选择，Pagure，或者 GitLab 的开源版本，所以他想知道候选人在这个问题上的立场。事实证明，这个问题并不完全简单，因为它源于对 source-git 项目的目的以及它会如何与 dist-git 交互的某种误解。很容易就误解了 Catanzaro 实际上想问的问题，所以之前那个一直未被解决的“dist-git 将被托管在哪里”的问题也在一定程度上被重新提了出来。
例如，FESCo 候选人 Fabio Valentini 说，他反对从 Pagure 转向 "一个具有 'open core' 商业模式的供应商的专有解决方案"，部分原因是它 "向 FOSS 社区传递了错误的信息"。但他很快意识到他误解了这个问题，他对 source-git 与不太受欢迎的 forge 服务合作有一些担忧，但并不完全反对在 GitHub 和 GitLab 上托管这些仓库。
Fedora 项目负责人马修-米勒（Matthew Miller）并不是候选人之一，他对于 Fedora 选择 forge 服务会发出错误信息的想法表示并不赞同。他说，有必要对某些选择（如二进制的 firmware）采取务实的态度，以便人们能够在他们的机器上真正得以使用我们的发行版。同时，大部分开源社区已经选择了使用 Git* 这些 forge 网站服务了，所以我们应该有必要在用户们经常 "活动（live）" 的地方来满足他们的需求：
更重要的是，如果我们所做的事情真的传递出了一个信息……那么我们现在所传递的信息也是完全没有效果的。人们并没有成群结队地来帮助建立 Pagure。甚至 Fedora 之外使用 Pagure 的人数也并没有显著增长。再说一遍，这并不是因为 Pagure 不好——它确实很好，有一个伟大的基础设计（也就是 git ）。但是我们对它的使用并没有改变世界，我在这个方面没有看到什么改善。如果不改变人们的行为，那么我们虽然在象征意义上是正确的，但实际上并没有推动我们的使命和愿景，而且……事实上人们的行为就是没有改变。
每当这个话题出现的时候，我都会看到很多这样的情况，只是人们不会大声把这句话里的前半部分说出来：“当然我就希望大部分东西都用 GitHub，因为它有很多优点——但 Fedora，Fedora 绝对不应该使用这个平台”。我们不能让自己被这句话所牵制。
我不认为 Gitlab 的 open core 这个做法是理想做法。但我认为它比 GitHub 更接近理想了。我深信自由软件（free software）和真正的开放源代码（real open source）是更好的模式，我认为他们最终也会意识到这一点。我认为我们与 GitLab 合作帮助它走向 all-open 模式，会比继续走目前的道路能产生更大的影响。
在回答 Catanzaro 的问题时，Miller 明确表示，他认为这个问题的答案 "必须是'yes'，而且不仅仅是 GitLab，还有 GitHub"。如果 source-git 仓库要尽量跟 upstream 仓库内容接近的话，它们就需要放在承担了那些项目的相同的平台上。
除此之外，他还谈到了 dist-git 的问题。他注意到 Pagure 的一长串问题，并说该项目处于 "仅进行紧急维护的状态"。他指出，从历史上看，Fedora 无法建立和运行一个开源的 GitLab 实例，所以我们不应该继续按这个方向来走。他更希望有一个开源的的方案可供选择，但他并没有看到这么一个符合需求的选项，尽管他也确实希望 GitLab 有一天可以成为这种选择。他说，这是一个资源分配的问题，最后他列举了其他几个他希望看到大家关注的项目。
Catanzaro 对这一回应感到有些惊讶，部分原因是他不太明白 source-git 和 dist-git 如何协同工作：
src-git 专门用于 downstream 的 Fedora 打包工作，所以我不指望 upstream 会有任何兴趣，除非 upstream 的开发者也是 Fedora 中 package 的打包提供者，对吗？我的理解是，如果 src-git 被启用，直接提交到 dist-git 的工作就会被阻止 —— 否则我们如何保持它们的同步，避免破坏 src-git？—— 而提交到 dist-git 的唯一途径就是通过 src-git。这个说的对吗？
Miller 说，有相当多的 upstream 开发者也是 Fedora package 的提供者，所以他们可能会对这些 source-git 仓库有兴趣。此外，Packit 服务是一个组件，它能保持两个仓库的同步，这样贡献者就可以使用他们最习惯的两个工作流程中的随便哪个来完成这些工作了。正如 David Cantrell 所说："没有人需要使用它。如果你对使用 dist-git 感到舒服，那么就保持你现在的做法就行，没必要更改。"
Packit 开发者 Hunor Csomortáni 提醒说，source-git 仍然是一个实验性的工具，尽管目标是将其作为 Fedora 软件包的一个官方选项：
在这个领域正在进行的所有工作都是实验，相关的定制化工具也都是针对选出来的一些软件包专门定制的。是的，我们（Packit 团队）有一个目标，就是向社区提议采用这个工作流程来作为进行打包工作的另一种方式，并允许 source-git 仓库在 Fedora 内部托管，但是这个提议还没有撰写完成。
Csomortáni 说，目前讨论的问题只是关注于这些实验性的仓库可以托管在什么地方，但如果 source-git 被采纳为一种选择的话，最好是把 source-git 和 dist-git 都放在同一个 git forge 服务网站上。然而，目前关于这个问题的答案是 "mixed signals （不明确的规定）"。其实根据若干原因，能将这些 repository 都放在同一个 forge 中是很有意义的：
为了让开发者获得更好的、不至于过于支离破碎的体验，从而降低维护和管理成本并确保社区对它们的控制，我认为应该把官方的 source-git 仓库放在 dist-git 仓库旁边，放在同一个级别的命名空间中，并由同一个 Git-forge 提供服务，这样做是很有好处的。
Catanzaro 对 Miller 关于 Fedora 不能运行自己的开源 GitLab 实例的说法不太赞同。"如果 GNOME、KDE、freedesktop.org、Debian 和 Purism 都能做到，我很肯定 Fedora 也能做到。" Miller 说他也很希望被证明是错的，但是 Stephen John Smoogen 回复了一封邮件，描述了过去在尝试这样做时出现过的那些问题。那些工作都因为一些所有项目共有的困扰而搁浅了。"获得一个开源的 gitlab 并不是不可能的。只是需要大量的空闲时间、系统以及大家共同的贡献，才能真正让它得以实现"。
讨论并没有得出真正的结论，但似乎至少 source-git 背后的想法和它的目标让人们更好地理解了。仍然有一个潜伏的问题，即 dist-git 转移到 CPE 建立的专有 GitLab 实例时，很可能其他开源替代方案（Pagure 或开源 GitLab）不会被采纳。这对 Fedora（和其他一些地方）的许多自由和开源软件倡导者来说是可以理解的，但也可能是目前来说可以勉强接受的选择里面最好的一个了。无论如何，在一些人眼里，这个发行版还有其他重要的目标，所以把精力放在那些事情上可能是项目推进的一个更好的方式，希望时间会证明这一点。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～