One year with Codeberg

Ludovic Courtès — June 22, 2026

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.

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.

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.

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.

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.

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 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.

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.

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.

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).

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.

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.

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.

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 immediately visible: Cuirass sends reports indicating success or failure directly in pull requests as guix-cuirass-bot.

Renewed collaboration

One of the intuitions and hope we had when we decided to migrate to Codeberg is that the pull-request workflow and its Web interface would allow us to reach out to a broader set of contributors. How did it go?

A first insight is that the commit rate—measured as the number of commits pushed on the main branch—is a noisy metric that doesn’t reveal much. What we see by looking at the period from May 2024 to May 2026 (so one year before and one year after the migration) essentially shows that the commit rate remained essentially between “high” and “very high”:

(As an aside, where are the tools to plot statistics like this from a Git repository? I found myself hacking something together.)

Looking at contributions is more insightful. The plot below shows the number of monthly commit authors, the number of monthly committers, and the number of new commit authors each month (people who authored a commit for the first time in the Git history) for that same period.

The number of monthly authors, including new authors, keeps growing. There was a peak both in the number of authors and number of newcomers in June 2025, right after the migration to Codeberg, but for the rest growth appears to be comparable in the 2025–2026 half and in the 2024–2025 half. Guix keeps attracting new contributors but there wasn’t a significant “Codeberg effect”.

The slight increase in number of monthly committers compared to the sharper increase in number of authors might suggest that committers are more “productive”, handling more contributions.

Since the user survey highlighted some contributors were frustrated by the delay or the lack of response on contributed patches—a problem that many free software projects struggle with—a question is how well Guix deals with that today. The graph below shows the creation and closing rate of pull requests per month over the past year, together with the monthly backlog (pull requests opened the month before or earlier and still opened). This data was acquired using the amazing Forgejo interface.

This again shows an impressive rate of incoming code—more than 500 pull requests opened each month!—and an equally impressive, but slightly lower, merge rate, leading to a constantly-increasing backlog. A similar backlog was observed on Debbugs before. Today, there are about 639 opened pull requests out of 6,459 ever opened, or 10%; for comparison, Nixpkgs has 12k opened pull requests out of 473k ever opened, or 2.5%. This concerning backlog in Guix can perhaps be attributed to excessive friction and/or insufficient continuous integration feedback.

One source of friction is the requirement for each commit to be signed by an authorized committer. Unlike many other projects, including Nixpkgs, this requirement means that a person needs to take responsibility and to apply and sign changes they merge, as opposed to just clicking the “Merge” button. In a way, we’re trading developer convenience for user security. It’s a tradeoff we’re willing to make because we care about securing the “software supply chain”, but we have yet to see if this cost can be mitigated in some way.

On the bright side, and although this is harder to measure, one positive impact of the move to Codeberg is that activity within the project is more legible. I already mentioned continuous integration that provides feedback directly in pull requests, such that contributors immediately discover it, but there’s more.

Guix teams are reified as Codeberg teams and their scope is given the CODEOWNERS file such that the right people are pinged. A bot also adds a corresponding label—e.g., the team-python label for what’s in the scope of the Python team—allowing for issue and pull request filtering by label. However, teams are not notified of issues tagged with the corresponding label, which is irritating.

Other features such as cross-references among issues/pull requests as well as milestones also appear to facilitate collaboration.

Outlook

This is nice and all but there’s still room for improvement.

Our infrastructure could use some help. Build power for pulls.ci.guix.gnu.org should be increased, ideally with also more diversity—building for non-x86 architectures would be great! Cuirass itself has a number of shortcomings; some are being addressed for the upcoming 1.4.x series but there’s more work to be done. And also, pulls.ci.guix.gnu.org remains very much package-oriented; it would be nice, when appropriate, to run system tests as well.

The packager workflow still leaves a bit to be desired, in particular with regards to topic branches and world rebuild scheduling, which is still mostly tied to… our otherwise retired bug tracker.

We also want to remain good citizens, not causing excessive load on Codeberg servers (oops!) and keeping an eye on storage use: a single “fork” of Guix could exceed Codeberg’s new per-user quota of 750 MiB. The solution would be to require new contributors to use the AGit workflow to create pull requests. AGit is already popular among Guix contributors; however, the idea of requiring it is seen as a “downgrade” by some because it lacks the familiarity of the “regular” pull request workflow. One way to mitigate that might be to make it more discoverable with an “AGit fork” icon as was done for Gentoo.

Part of being a good citizen, for Guix and for Codeberg e.V., is listening to and accounting for one another’s concern, and this has worked beautifully so far. Guix Foundation recently voted to become a supporting (non-voting) member of Codeberg e.V. as a way to express gratitude and support.

Oh, breaking news: a pull request adding Forgejo and a service to set it up on Guix has just been submitted! Purely declarative configuration, fully reproducible deployment of a forge—can you imagine⁈ Symbiosis at play.

Acknowledgments

Many thanks to Steve “Futurile” George, Noé Lopez, and Maxim Cournoyer for reviewing an earlier draft of this post.

Related topics:

Unless otherwise stated, blog posts on this site are copyrighted by their respective authors and published under the terms of the CC-BY-SA 4.0 license and those of the GNU Free Documentation License (version 1.3 or later, with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts).