GNU Guix: One year with Codeberg

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.

Source: Planet GNU