One year with Codeberg — 2026 — Blog — GNU GuixOne year with Codeberg<br>Ludovic Courtès — June 22, 2026<br>A year ago, Guix migrated to<br>Codeberg for<br>source code hosting, issue tracking, and pull requests. This is a<br>significant change for a project with more than 400 people contributing<br>code each year, after more than decade hosting code at<br>Savannah and dealing with bug<br>reports and patches by email, tracked by a Debbugs<br>instance. This article discusses the<br>process that led to this change and lists some takeaways, a year later.<br>The non-obvious choice<br>For years before, the question of our choice of source code hosting and<br>collaboration tools would regularly come up. However, with a community<br>effectively built around the existing tools and workflows, a change to<br>pull-request workflow was far from obvious—even if many would admit that<br>yes, pull requests are more familiar to many younger hackers than<br>patches and bug reports by email.<br>Active contributors were efficient with the email workflow—often thanks<br>to Emacs and/or to<br>top-notch email clients—while at the same time being critical of<br>“modern” Web-based forges: after all, Debbugs weighs in at a few hundred<br>lines of Perl, building upon the battle-tested standards and built-in<br>federation of email, whereas a forge like Forgejo<br>is much bigger with hundreds of Go dependencies.<br>A further complication is that, over time, contributors had built tools<br>around this workflow: mumi would<br>provide a nice web interface to Debbugs<br>and the Quality Assurance service would<br>automatically apply patch series in a Git branch and build packages from<br>that branch—to give the most visible examples. Migrating was all but<br>obvious.<br>Despite these achievements, dissatisfaction was palpable though, even<br>more so when Steve George (a.k.a. Futurile) published the results of<br>the first user and contributor<br>survey<br>in January 2025, with feedback from no less than 900 people. For<br>contributors who took part in the survey, the email workflow was often<br>mentioned as a<br>hindrance.<br>Making decisions<br>As if things were not difficult enough, there was no “benevolent<br>dictator” that the project could rely on to make a sharp decision.<br>Instead, in December 2024, the project adopted a process for collective<br>decision-making: the Guix Consensus Document (GCD)<br>process. The<br>process is ambitious: instead of merely asking “project members” (a<br>concept that needs to be properly defined!) to vote on proposals,<br>authors of proposals are expected to work with everyone to build<br>consensus on the proposal; participants cannot merely “oppose” a<br>proposal but should instead express their needs and suggest concrete<br>changes to address them. At the end of the process, participants can<br>“support”, “accept”, or “disapprove” the final revision of the proposal.<br>It is too early to tell whether the GCD process will stand the test of<br>time—as of this writing seven proposals were submitted through this<br>process, with varying outcomes—but it<br>surely proved to be a good way to work collectively on the forge<br>migration issue, which was the first real-world use of the GCD process.<br>GCD 002 was<br>submitted in February 2025 as a proposal to migrate to Codeberg for<br>source code hosting and collaboration. The<br>discussion lasted for two<br>months—the maximum duration permitted by the process—with contributions<br>by many people. Two thirds of the Guix team members participated in the<br>deliberation, among which 72% expressed “support” while the remaining<br>28% merely “accepted” the proposal; nobody “disapproved” it so the<br>proposal came into force in early May 2025.<br>The discussion showed that many long-time contributors were not<br>comfortable with the idea of moving to a workflow largely perceived as<br>Web-first and inefficient compared to the email workflow. The idea of<br>abandoning part of the infrastructure carefully built around the email<br>workflow over the years was also unappealing. Yet, the prospect of<br>reaching out to a broader community and improving the developer<br>experience for many was probably a driving force that led to this<br>positive outcome.<br>One thing in the proposal that didn’t trigger much debate though is the<br>preference both for a free-software-based forge and for one hosted by a<br>non-profit, Codeberg e.V. This choice is<br>very much in line with the Guix ethos.<br>Switchover<br>As agreed-upon in the GCD, the switch to Codeberg was incremental: the<br>main repository was migrated on May 25th,<br>2025, with the<br>former repository still available as a mirror today; the former issue<br>and patch tracker was kept active until January 1st, 2026, when Codeberg<br>issues and pull requests became the only supported mechanisms (but older<br>bug reports and patches remain accessible<br>on-line).<br>Thanks to the planning devised during the consensus-building discussion,<br>there were few hiccups and surprises when we switched. The quality of<br>service achieved by the Codeberg e.V. employees and volunteers has been<br>very good and the occasional downtime was usually short and clearly<br>communicated.<br>For some of us, the...