One year with Codeberg

Codeberg 一周年回顾

Ludovic Courtès — June 22, 2026 Ludovic Courtès — 2026年6月22日

A year ago, Guix migrated to Codeberg for source code hosting, issue tracking, and pull requests. This is a significant change for a project with more than 400 people contributing code each year, after more than decade hosting code at Savannah and dealing with bug reports and patches by email, tracked by a Debbugs instance. This article discusses the process that led to this change and lists some takeaways, a year later. 一年前，Guix 迁移到了 Codeberg，用于源代码托管、问题追踪和合并请求（Pull Requests）。对于一个每年有超过 400 人贡献代码的项目来说，这是一个重大的变革。在此之前，该项目在 Savannah 托管代码已超过十年，并通过 Debbugs 实例以电子邮件方式处理错误报告和补丁。本文将探讨促成这一变革的过程，并总结一年后的心得体会。

The non-obvious choice

并非显而易见的选择

For years before, the question of our choice of source code hosting and collaboration tools would regularly come up. However, with a community effectively built around the existing tools and workflows, a change to pull-request workflow was far from obvious—even if many would admit that yes, pull requests are more familiar to many younger hackers than patches and bug reports by email. 在此之前的多年里，关于源代码托管和协作工具的选择问题经常被提及。然而，由于社区实际上是围绕现有的工具和工作流构建的，转向合并请求工作流绝非易事——尽管许多人承认，相比于电子邮件补丁和错误报告，合并请求对许多年轻的黑客来说确实更熟悉。

Active contributors were efficient with the email workflow—often thanks to Emacs and/or to top-notch email clients—while at the same time being critical of “modern” Web-based forges: after all, Debbugs weighs in at a few hundred lines of Perl, building upon the battle-tested standards and built-in federation of email, whereas a forge like Forgejo is much bigger with hundreds of Go dependencies. 活跃的贡献者们能够高效地使用电子邮件工作流（这通常归功于 Emacs 和/或顶级的电子邮件客户端），同时他们也对“现代”基于 Web 的代码托管平台持批评态度：毕竟，Debbugs 仅由几百行 Perl 代码组成，建立在久经考验的标准和电子邮件内置的联邦机制之上；而像 Forgejo 这样的平台则庞大得多，拥有数百个 Go 语言依赖项。

A further complication is that, over time, contributors had built tools around this workflow: mumi would provide a nice web interface to Debbugs and the Quality Assurance service would automatically apply patch series in a Git branch and build packages from that branch—to give the most visible examples. Migrating was all but obvious. 另一个复杂之处在于，随着时间的推移，贡献者们围绕这一工作流构建了各种工具：例如，mumi 为 Debbugs 提供了友好的 Web 界面，质量保证（QA）服务会自动将补丁系列应用到 Git 分支并从中构建软件包——这些是最显著的例子。因此，迁移绝非显而易见。

Despite these achievements, dissatisfaction was palpable though, even more so when Steve George (a.k.a. Futurile) published the results of the first user and contributor survey in January 2025, with feedback from no less than 900 people. For contributors who took part in the survey, the email workflow was often mentioned as a hindrance. 尽管取得了这些成就，但不满情绪依然显而易见，尤其是在 2025 年 1 月 Steve George（又名 Futurile）发布了首次用户和贡献者调查结果之后，该调查收集了多达 900 人的反馈。对于参与调查的贡献者来说，电子邮件工作流经常被提及为一种阻碍。

Making decisions

决策过程

As if things were not difficult enough, there was no “benevolent dictator” that the project could rely on to make a sharp decision. Instead, in December 2024, the project adopted a process for collective decision-making: the Guix Consensus Document (GCD) process. The process is ambitious: instead of merely asking “project members” (a concept that needs to be properly defined!) to vote on proposals, authors of proposals are expected to work with everyone to build consensus on the proposal; participants cannot merely “oppose” a proposal but should instead express their needs and suggest concrete changes to address them. At the end of the process, participants can “support”, “accept”, or “disapprove” the final revision of the proposal. 仿佛事情还不够复杂，项目并没有可以依赖的“仁慈独裁者”来做出果断决策。相反，在 2024 年 12 月，项目采用了一种集体决策流程：Guix 共识文档（GCD）流程。该流程雄心勃勃：它不再仅仅要求“项目成员”（一个需要被明确定义的概念！）对提案进行投票，而是要求提案作者与所有人合作，就提案达成共识；参与者不能仅仅“反对”提案，而应表达他们的需求并提出具体的修改建议来解决这些需求。在流程结束时，参与者可以对提案的最终修订版进行“支持”、“接受”或“不赞成”。

It is too early to tell whether the GCD process will stand the test of time—as of this writing seven proposals were submitted through this process, with varying outcomes—but it surely proved to be a good way to work collectively on the forge migration issue, which was the first real-world use of the GCD process. 现在判断 GCD 流程是否经得起时间考验还为时过早——截至撰写本文时，已有七项提案通过此流程提交，结果各不相同——但它确实被证明是集体处理代码托管平台迁移问题的有效方式，这也是 GCD 流程的首次实际应用。

GCD 002 was submitted in February 2025 as a proposal to migrate to Codeberg for source code hosting and collaboration. The discussion lasted for two months—the maximum duration permitted by the process—with contributions by many people. Two thirds of the Guix team members participated in the deliberation, among which 72% expressed “support” while the remaining 28% merely “accepted” the proposal; nobody “disapproved” it so the proposal came into force in early May 2025. GCD 002 于 2025 年 2 月提交，提议迁移至 Codeberg 进行源代码托管和协作。讨论持续了两个月（流程允许的最长期限），许多人参与了贡献。三分之二的 Guix 团队成员参与了审议，其中 72% 表示“支持”，其余 28% 表示“接受”；没有人“不赞成”，因此该提案于 2025 年 5 月初生效。

The discussion showed that many long-time contributors were not comfortable with the idea of moving to a workflow largely perceived as Web-first and inefficient compared to the email workflow. The idea of abandoning part of the infrastructure carefully built around the email workflow over the years was also unappealing. Yet, the prospect of reaching out to a broader community and improving the developer experience for many was probably a driving force that led to this positive outcome. 讨论表明，许多长期贡献者对转向一种被普遍认为是以 Web 为中心、且相比电子邮件工作流效率较低的工作流感到不适。放弃多年来围绕电子邮件工作流精心构建的部分基础设施的想法也令人难以接受。然而，接触更广泛社区的前景以及改善许多人的开发者体验，可能是促成这一积极结果的驱动力。

One thing in the proposal that didn’t trigger much debate though is the preference both for a free-software-based forge and for one hosted by a non-profit, Codeberg e.V. This choice is very much in line with the Guix ethos. 提案中有一点并未引发太多争议，那就是对基于自由软件的代码托管平台以及由非营利组织 Codeberg e.V. 托管的平台的偏好。这一选择非常符合 Guix 的精神。

Switchover

切换

As agreed-upon in the GCD, the switch to Codeberg was incremental: the main repository was migrated on May 25th, 2025, with the former repository still available as a mirror today; the former issue and patch tracker was kept active until January 1st, 2026, when Codeberg issues and pull requests became the only supported mechanisms (but older bug reports and patches remain accessible on-line). 正如 GCD 中所约定的，向 Codeberg 的切换是渐进式的：主仓库于 2025 年 5 月 25 日迁移，原仓库至今仍作为镜像提供；旧的问题和补丁追踪器一直保持活跃至 2026 年 1 月 1 日，此后 Codeberg 的问题和合并请求成为唯一支持的机制（但旧的错误报告和补丁仍然可以在线访问）。

Thanks to the planning devised during the consensus-building discussion, there were few hiccups and surprises when we switched. The quality of service achieved by the Codeberg e.V. employees and volunteers has been very good and the occasional downtime was usually short and clearly communicated. 得益于在共识构建讨论期间制定的计划，我们在切换时几乎没有遇到什么波折或意外。Codeberg e.V. 的员工和志愿者所提供的服务质量非常好，偶尔出现的停机时间通常很短，并且有明确的通知。

For some of us, the main difficulty was to adapt to the new workflow. For those who prefer a workflow out of the browser, the good news is that Emacs interfaces—fj.el and more recently Emacs-Forgejo—have been getting better everyday thanks to their amazing developers; the ability to create pull requests using the AGit workflow has also helped bring peace and harmony. 对于我们中的一些人来说，主要的困难在于适应新的工作流。对于那些喜欢在浏览器之外工作的人来说，好消息是 Emacs 接口（fj.el 以及最近的 Emacs-Forgejo）在出色的开发者们的努力下每天都在变得更好；使用 AGit 工作流创建合并请求的能力也有助于带来平静与和谐。

The one issue that wasn’t sufficiently anticipated is continuous integration for pull requests. The part of qa.guix.gnu.org that would previously build packages for patches sent by email was not ported to Codeberg. For several months, it was up to reviewers to make sure that pull requests would not break anything—a situation that was not sustainable. 唯一没有被充分预料到的问题是合并请求的持续集成。qa.guix.gnu.org 中之前为通过电子邮件发送的补丁构建软件包的部分并没有移植到 Codeberg。在几个月的时间里，审查人员必须确保合并请求不会破坏任何东西——这种情况是不可持续的。

In September 2025, an instance of Cuirass was set up at pulls.ci.guix.gnu.org to finally build pull requests. This was initially seen as a stopgap because of several limitations compared to what qa.guix.gnu.org would previously do—such as the fact that packages now get built for a single architecture. However, one advantage for newcomers is that feedback is immedi 2025 年 9 月，一个 Cuirass 实例在 pulls.ci.guix.gnu.org 上建立，终于实现了对合并请求的构建。这最初被视为一种权宜之计，因为它与 qa.guix.gnu.org 之前的功能相比存在一些局限性——例如，软件包现在只能针对单一架构进行构建。然而，对于新手来说，一个优势是反馈是即时的。