与Codeberg相伴一年

# 与 Codeberg 共度一年 — 2026 — 博客 — GNU Guix 来源：https://guix.gnu.org/en/blog/2026/one-year-with-codeberg/ ## 与 Codeberg 共度一年 Ludovic Courtès — 2026年6月22日 一年前，Guix [迁移至 Codeberg](https://guix.gnu.org/blog/2025/migrating-to-codeberg/) 用于源代码托管、问题跟踪和拉取请求。对于一个每年有超过400人贡献代码的项目来说，这是一个重大的变化——此前十多年里，代码托管在 [Savannah](https://savannah.gnu.org/projects/guix)，错误报告和补丁通过电子邮件处理，由 [一个 Debbugs 实例](https://issues.guix.gnu.org/) 跟踪。本文讨论了导致这一变化的历程，并列出一年后的一些经验教训。 ## 并非显而易见的选择 多年以来，我们对于源代码托管和协作工具的选择问题时常被提及。然而，由于社区实际上已经围绕现有的工具和工作流程建立起来，转向拉取请求工作流程远非显而易见——即使许多人承认，对许多年轻的黑客来说，拉取请求确实比通过电子邮件发送补丁和错误报告更为熟悉。 活跃贡献者通过电子邮件工作流程效率很高——这通常得益于 [Emacs](https://elpa.gnu.org/packages/debbugs.html) 和/或顶级的电子邮件客户端——但与此同时，他们对“现代”基于 Web 的代码托管平台持批评态度：毕竟，Debbugs 只有几百行 Perl 代码，构建在经过实战检验的标准和电子邮件内置的联邦机制之上，而像 [Forgejo](https://forgejo.org/) 这样的平台则要大得多，拥有数百个 Go 依赖项。 另一个复杂因素是，随着时间的推移，贡献者们围绕这一工作流程构建了工具：[mumi](https://codeberg.org/guix/mumi) 为 Debbugs 提供了 [漂亮的网页界面](https://issues.guix.gnu.org/)，[质量保证服务](https://qa.guix.gnu.org/) 会自动将补丁系列应用到 Git 分支中并构建该分支的包——这些只是最显著的例子。迁移远非易事。 尽管取得了这些成就，不满情绪仍然显而易见，尤其是在史蒂夫·乔治（又名 Futurile）于2025年1月发布 [首次用户和贡献者调查结果](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/) 之后，调查收到了不少于900人的反馈。对于参与调查的贡献者来说，电子邮件工作流程 [常被提及为一个障碍](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-3/)。 ## 做出决策 事情本就已经够复杂了，项目没有可以依赖的“仁慈的独裁者”来做出果断的决定。相反，在2024年12月，项目采用了一种集体决策流程：**Guix 共识文档 (GCD) 流程**。这个流程雄心勃勃：不仅仅是要求“项目成员”（这个概念需要正确定义！）对提案进行投票，提案作者需要与所有人合作，*就提案建立共识*；参与者不能仅仅“反对”提案，而应该表达他们的需求，并提出具体的修改建议来解决这些问题。在流程结束时，参与者可以对最终修订版提案表示“支持”、“接受”或“反对”。 现在判断 GCD 流程能否经得起时间考验还为时过早——截至本文撰写时，已有七项提案通过该流程提交，[结果各不相同](https://consensus.guix.gnu.org/)——但它确实被证明是就代码托管平台迁移问题（这也是 GCD 流程的第一次实际应用）进行集体协作的有效方式。 GCD 002 于2025年2月提交，作为迁移到 Codeberg 进行源代码托管和协作的提案。[讨论](https://issues.guix.gnu.org/76503) 持续了两个月——这是流程允许的最长时间——许多人参与了讨论。三分之二的 Guix 团队成员参与了审议，其中 72% 表示“支持”，其余 28% 仅仅“接受”了该提案；没有人“反对”，因此该提案于2025年5月初生效。 讨论表明，许多长期贡献者对于转向一个被普遍认为以 Web 为主、效率低于电子邮件工作流程的做法感到不安。放弃多年来围绕电子邮件工作流程精心构建的部分基础设施的想法也不具吸引力。然而，与更广泛的社区接触并改善许多开发者体验的前景，可能是促成这一积极结果的主要推动力。 提案中一个没有引发太多争论的事情是，倾向于使用基于自由软件的代码托管平台，并且由非营利组织 [Codeberg e.V.](https://codeberg.org/about) 托管。这一选择非常符合 Guix 的精神。 ## 切换 按照 GCD 的约定，切换到 Codeberg 是逐步进行的：主仓库于 [2025年5月25日迁移](https://guix.gnu.org/blog/2025/migrating-to-codeberg/)，之前的仓库至今仍作为镜像可用；之前的问题和补丁跟踪器一直保持活跃直到2026年1月1日，届时 Codeberg 的问题和拉取请求成为唯一支持的机制（但旧的错误报告和补丁仍可 [在线访问](https://issues.guix.gnu.org/)）。 得益于共识构建讨论中制定的计划，切换过程中几乎没有什么意外和波折。Codeberg e.V. 的员工和志愿者提供的服务质量非常好，偶尔的停机时间通常很短，且沟通明确。 对我们一些人来说，主要困难是适应新的工作流程。对于那些喜欢脱离浏览器工作流程的人来说，好消息是 Emacs 界面——`fj.el` 和最近的 [Emacs-Forgejo](https://codeberg.org/thanosapollo/emacs-forgejo)——由于其出色的开发者而日益完善；能够 [使用 AGit 工作流程创建拉取请求](https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html) 也有助于带来和平与和谐。 一个没有充分预料到的问题是拉取请求的持续集成。之前用于构建通过电子邮件发送的补丁的包的那部分 `qa.guix.gnu.org` 没有移植到 Codeberg。几个月来，评审者不得不确保拉取请求不会破坏任何东西——这种情况是不可持续的。 由 @guix-cuirass-bot 进行的“审查”截图，显示了成功和失败的包构建。 2025年9月，一个 [Cuirass](https://guix.gnu.org/en/cuirass) 实例在 `pulls.ci.guix.gnu.org` 上搭建，终于开始构建拉取请求。这最初被认为是一个 [临时解决方案](https://codeberg.org/guix/maintenance/pulls/28)，因为与之前的 `qa.guix.gnu.org` 相比，它存在一些限制——例如，现在包只针对单一架构构建。然而，对新来者来说，一个好处是反馈立即可见：Cuirass 会以 `guix-cuirass-bot` 的身份直接在拉取请求中发送成功或失败的报告。 ## 焕然一新的协作 当我们决定迁移到 Codeberg 时，一个直觉和希望是，拉取请求工作流程及其 Web 界面将使我们能够接触到更广泛的贡献者。实际情况如何？ 首先，提交率（主分支上推送的提交数量）是一个嘈杂的指标，并不能揭示太多信息。我们观察了2024年5月至2026年5月期间（即迁移前后各一年）的数据，基本上显示提交率始终保持在“高”和“非常高”之间： 显示2024年5月至2026年5月间每月提交率的图表。 （顺便问一下，有什么工具可以从 Git 仓库绘制这样的统计数据？我发现自己 [拼凑了一些代码](https://codeberg.org/civodul/git-plot)。） 观察贡献情况更有意义。下面的图表显示了同一时期每月提交作者数量、每月提交者数量以及每月新提交作者数量（首次出现在 Git 历史中的作者）。 显示 Guix 每月贡献量的图表。 每月作者数量（包括新作者）持续增长。2025年6月，即迁移到 Codeberg 之后，作者数量和新来者数量均达到峰值，但除此之外，2025-2026 半年和 2024-2025 半年的增长情况似乎相当。Guix 持续吸引新的贡献者，但并没有显著的“Codeberg 效应”。 与作者数量更急剧的增长相比，每月提交者数量的轻微增长可能表明提交者更“高效”，处理了更多的贡献。 由于用户调查强调一些贡献者对贡献补丁的延迟或缺乏回应感到沮丧——这是许多自由软件项目都面临的问题——一个问题是 Guix 目前处理得如何。下面的图表显示了过去一年中每月拉取请求的创建和关闭率，以及每月的积压量（当月之前或当月打开且仍处于打开状态的拉取请求）。这些数据是通过 [出色的 Forgejo 界面](https://codeberg.org/api/swagger#/repository/repoListPullRequests) 获取的。 显示2025年5月至2026年5月拉取请求率的图表。 这再次显示了惊人的代码流入率——每月超过500个拉取请求！——以及同样惊人但略低的合并率，导致积压量不断增加。以前在 [Debbugs 上也观察到过类似的积压](https://debbugs.gnu.org/rrd/guix-patches.html)。目前，在总共打开的 6,459 个拉取请求中，约有 639 个处于打开状态，占 10%；相比之下，Nixpkgs 在 [总共打开的 473,000 个拉取请求中](https://github.com/NixOS/nixpkgs/pulls) 有 12,000 个打开，占 2.5%。Guix 中这个令人担忧的积压可能归因于过多的摩擦和/或不足的持续集成反馈。 一个摩擦来源是要求每个提交必须由 [授权的提交者签名](https://guix.gnu.org/manual/devel/en/html_node/Channel-Authentication.html)。与包括 Nixpkgs 在内的许多其他项目不同，这一要求意味着一个人需要承担责任，并应用和签署他们合并的更改，而不仅仅是点击“合并”按钮。从某种意义上说，我们是在用开发者的便利性换取 [用户安全性](https://guix.gnu.org/en/blog/2020/securing-updates/)。这是我们愿意做出的权衡，因为我们关心确保“软件供应链”的安全，但我们仍需看看能否以某种方式减轻这个成本。 好的一面是，尽管这更难衡量，但迁移到 Codeberg 的一个积极影响是项目内的活动更加 *清晰可辨*。我已经提到持续集成直接在拉取请求中提供反馈，这样贡献者能立即发现它，但这还不止于此。 Guix 团队以 Codeberg 团队的形式体现，其范围由 `CODEOWNERS` 文件指定，以便正确的成员被提及。一个机器人还会添加相应的标签——例如，Python 团队范围的内容添加 `team-python` 标签——允许按标签过滤问题和拉取请求。然而，[团队不会收到带有对应标签问题的通知](https://codeberg.org/forgejo/forgejo/issues/11703)，这令人恼火。 其他功能，如问题/拉取请求之间的交叉引用以及 [里程碑](https://codeberg.org/guix/guix/milestones)，似乎也促进了协作。 ## 展望 这很好，但仍有改进空间。 我们的基础设施需要一些帮助。`pulls.ci.guix.gnu.org` 的构建能力应该提升，理想情况下还要增加多样性——为非 x86 架构构建会很棒！Cuirass 本身存在许多缺点；有些正在为 [即将到来的 1.4.x 系列](https://codeberg.org/guix/cuirass/milestone/27316) 解决，但还有更多工作要做。此外，`pulls.ci.guix.gnu.org` 仍然非常面向包；在合适的情况下，运行 [系统测试](https://guix.gnu.org/blog/2016/guixsd-system-tests/) 也会很好。 包维护者的工作流程仍有改进空间，特别是关于 [主题分支和世界重建调度](https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html)，这在很大程度上仍然与……我们早已退役的错误跟踪器相关联。 我们还希望保持良好的公民意识，[不给 Codeberg 服务器带来过多负载](https://codeberg.org/Codeberg-Infrastructure/scripted-configuration/issues/96)（哎呀！），并关注存储使用情况：单个 Guix 的“fork”可能超过 Codeberg 的新每个用户配额 750 MiB。解决方案是 [要求新贡献者使用 AGit 工作流程](https://lists.gnu.org/archive/html/guix-devel/2026-06/msg00007.html) 来创建拉取请求。AGit 在 Guix 贡献者中已经很流行；然而，*要求* 使用它被一些人视为“降级”，因为它缺乏“常规”拉取请求工作流程的熟悉感。一种缓解方法可能是让它更容易被发现，比如像 [Gentoo 所做的那样](https://codeberg.org/gentoo/gentoo) 添加一个“AGit fork”图标。 成为好公民的一部分，对于 Guix 和 Codeberg e.V. 而言，是倾听并考虑对方的关切，这一点迄今为止运作良好。[Guix 基金会](https://foundation.guix.info/) 最近 [投票](https://codeberg.org/guix-foundation/website/pulls/16) 成为 Codeberg e.V. 的支持（无投票权）成员，以此表达感激和支持。 哦，*突发新闻*：[一个添加 Forgejo 及其在 Guix 上设置服务的拉取请求刚刚被提交](https://codeberg.org/guix/guix/pulls/9006)！纯声明式配置，完全可复现的代码托管平台部署——你能想象吗？共生在起作用。 ## 致谢 衷心感谢 Steve "Futurile" George、Noé Lopez 和 Maxim Cournoyer 审阅本文的早期草稿。 除非另有说明，本站博客文章由其各自作者拥有版权，并根据 [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) 许可和 [GNU 自由文档许可证](https://www.gnu.org/licenses/fdl-1.3.html)（版本 1.3 或更高，无不变章节，无封面文本，无封底文本）的条款发布。