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

Did your pip install fail with longintrepr.h: No such file or directory? The file likely is on your system, but it sometime or another it was moved, from /usr/include/python3.xx/longintrepr.h to /usr/include/python3.xx/cpython/longintrepr.h. The proper fix is to update the package in question with the new path, but if you’re installing an old version of something or a package that’s no longer maintained you can work around it like this:

ln -s /usr/include/python3.*/cpython/longintrepr.h .venv/include

This is to announce CSSC-1.5.0-rc3, a beta release.

This is a release candidate for a future stable 1.5.0 release.

There have been 46 commits by 2 people in the 109 weeks since CSSC-1.5.0-rc2.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Greg A. Woods (1)
  Paul Bryce (2)
  James Youngman (43)

James
==================================================================

Here is the GNU CSSC home page:
    https://gn ... rg/s/CSSC/

Here are the compressed sources and a GPG detached signature:
  https://alpha.gnu ... -1.5.0-rc3.tar.gz
  https://alpha.gnu ... .0-rc3.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.o ... rg/order/ftp.html

Here are the SHA256 and SHA3-256 checksums:

  File: CSSC-1.5.0-rc3.tar.gz
  SHA256 sum:   a78bc23062b11c33a858acd8a08c173ea2957f763f5b7ddb2990c0fee7c71cec
  SHA3-256 sum: 20733dd3c517c1bb44c67088b1a208ebf00e1eab4ab21e806bd963869faf918a

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
from coreutils-9.8.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify CSSC-1.5.0-rc3.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   rsa4096 2015-12-24 [SC]
        0CF4 E8D8 7159 3224 8428  32B8 88DD 9E08 C5DD ACB9
  uid   James Youngman <james@youngman.org>
  uid   James Youngman <jay@gnu.org>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key james@youngman.org

  gpg --recv-keys 88DD9E08C5DDACB9

  wget -q -O- 'https://savannah. ... SC&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.o ... u/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify CSSC-1.5.0-rc3.tar.gz.sig

This release is based on the CSSC git repository, available as

  git clone https://https.git ... .org/git/CSSC.git

with commit 26add75e45f79cd493409ee2f0c2646849314aad tagged as v1.5.0-rc3.

For a summary of changes and contributors, see:

  https://gitweb.gi ... tlog;h=v1.5.0-rc3

or run this command from a git-cloned CSSC directory:

  git shortlog 43b5b054701732df7ce24eb59821010c39c60cb6..v1.5.0-rc3

This release was bootstrapped with the following tools:
  Autoconf 2.72
  Automake 1.17
  Gnulib 2026-06-08 88592a2880cf39a2f597cd0294a90d8dd7faa2df

NEWS

• Noteworthy changes in release 1.5.0-rc3 (2026-06-14)

        * Some typos in error message have been fixed.

        * admin now supports combination of -r with -n as well as the
          portable combination of -r with -i.

        * Support "sccs sact"; the sact program already existed but
  could not previously be invoked via the sccs wrapper.
  Thanks to Greg A. Woods for this improvement.

        * In some places we now prefer "grep -E" to "egrep" in order
          to avoid a warning message from GNU grep.  Some very old
          versions of Unix may not support this option.

        * Various C++ portability improvements.

• Updated version of gnulib.

• Updated version of googletest; this is now at the last

          version at which it still supported building with Automake.

GNUtrition 0.33 is now released. This marks the first release of GNUtrition since 2012, approximately 14 years ago!

GNUtrition is free nutrition analysis software. The USDA Food and Nutrient Database for Dietary Studies (FNDDS) is used as the source of food nutrient information.

This release is a complete rewrite of GNUtrition in C rather than Python 2 with a new GTK 3 interface replacing the old GTK 2 one. The Nutrient Database of Standard Reference, which stopped getting updated in 2018, was replaced with the USDA Food and Nutrition Database for Dietary Studies. With help from some test volunteers, the build and installation process was better streamlined to resolve critical issues and difficulties so that GNUtrition can be a better program overall.

Considering the time between releases, GNUtrition currently is not available on OS package repositories (as far as I am aware). If you package software for your operating system's package manager, it would be very helpful if you could start packaging GNUtrition so that it may be even more easily used by people on said systems. If you don't, you may still request to those who do to start including GNUtrition.

Thank you to everyone who tested/used GNUtrition 0.33's release candidates and provided meaningful feedback on its functionality, design, and so on. I would also like to especially thank Jason Self for providing us with the C rewrite in the first place.

More information about GNUtrition may be found on its home page at http://gnu.org/so ... tware/gnutrition/. This release can be obtained from the ftp.gnu.org server at one of the following:

ftp://ftp.gnu.o ... gnu/gnutrition/
http://ftp.gnu.or ... g/gnu/gnutrition/
https://ftp.gnu.o ... g/gnu/gnutrition/

The FTP mirror list is available at https://gnu.or ... order/ftp.html, and https://ftpmirror ... u.org/gnutrition/ will automatically redirect you to a nearby mirror.

Please report any problems you experience to the GNUtrition bug reports mailing list: bug-gnutrition@gnu.org (https://lists.gnu ... fo/bug-gnutrition).

Happy hacking and calorie counting!!