Subject: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

From: Maxim Cournoyer <[email-masked]>
Date: Tue, 04 Mar 2025 20:22:59 +0900

Hi Ludovic,

Ludovic Courtès <[email-masked]> writes:

[...]

> However, to overcome several limitations, the project developed
> processes and tools, which can be characterized as *incidental
> complexity*:
>
>   - because the Debbugs web interface is crude by today’s standards and
>     hard to search and navigate, the project developed
>     [mumi](https://git.savannah.gnu.org/cgit/guix/mumi.git/), the web
>     interface running at https://issues.guix.gnu.org;
>   - to navigate bugs and patches more conveniently than what an email
>     client supports, contributors were
>     [encouraged](https://guix.gnu.org/manual/devel/en/html_node/Debbugs-User-Interfaces.html)
>     to use interfaces like `debbugs.el` or `b4`;
>   - sending patch series by email does not play well with Debbugs’
>     automatic identifier assignment, so [contributors were told to send
>     their “cover letter”, wait for an identifier to be assigned, and
>     then send the
>     rest](https://guix.gnu.org/manual/devel/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1);
>   - to help sending and applying patch series, mumi was extended to
>     provide a command line interface;
>   - to build patch series submitted by email, the [QA
>     service](https://qa.guix.gnu.org) has to rely on a [Patchwork
>     instance](https://patches.guix-patches.cbaines.net/project/guix-patches/list/)
>     that is subscribed to the `guix-patches` mailing list, coupled with
>     its own [parsing of incoming
>     email](https://git.savannah.gnu.org/gitweb/?p=guix/data-service.git;a=blob;f=guix-data-service/branch-updated-emails.scm;h=aeb1570dfda725864a77780d0541f26c090b0e55;hb=c886685e9284da4bbed9377f70dd70da9e7ca29f);
>   - the project added a commit hook to create add unique `Change-Id`
>     headers in commit messages in an attempt to correlate commits in the
>     repository with messages send to `guix-patches`; none of the
>     existing tools takes advantage of it though, and it is up to
>     contributors to manually close entries in the bug/patch tracker once
>     they have been fixed/applied.
>
> Developing and maintaining this software and infrastructure is
> time-consuming.  Worse, it leaves contributors largely dissatisfied for
> a variety of reasons:

I don't think maintaining the infrastructure *that would be replaced*
has been too time consuming.  Sure, Mumi has had some issues and needed
some fixing, but most of what is used today:

- Savannah (git hosting)
- Debbugs (bug tracker) & Mumi
- Git configs/hooks
- Contributing documentation

rarely ever changes and has been stable, all while being generously
hosted, without limits on repository size or other criteria, on
freedom-respecting hardware and a friendly associated org (FSF/GNU),
which I assume can't be said of Codeberg (w.r.t. using free software
friendly hardware, such as using the GNU Boot bootloader).  The
complexity of the flow can be partly explained by the fact that there
isn't only one flow possible, but a multitude of flows (Emacs Debbugs,
Mumi, git send-email, etc.), which is more of a strength than a defect
when it comes to the freedom of choice/flexibility for our contributors.

I see the argument that there's an HTTP API for Forgejo; that's great,
but it requires that everyone relearn another way of doing something
that already works well enough for me and others, which I'm not too
excited about.  I also assume the Forgejo-related tooling, given their
young age, would not be as mature and missing features in places, and
that it would require invested time to comfortably do all that can be
done today in Gnus and Emacs Debbugs, away from the web interface, in
the environment of choice (Emacs) of perhaps a majority of the Guix
contributors.

The parts that have required the most maintenance would be, I assume, CI
(Cuirass) and QA (Guix Build Coordinator), but these components will
continue to be used in the event we migrate to Codeberg, so we wouldn't
gain much on the maintenance side, it seems.

>   - the process is unfamiliar to most newcomers;
>   - the tools and infrastructure in Guix have become a maze;
>   - apart from the happy few using `debbugs.el` in Emacs, navigating
>     open issues and patches is hard; filtering incoming messages is
>     equally hard, even for those with 10+ years of experience with
>     advanced email tools (Gnus, mu4e, notmuch, b4, etc.);
>   - because the various parts of the development process (repository,
>     issue tracking, QA automation, `etc/teams.scm`) are largely
>     disconnected, even long-time contributors can hardly follow issues
>     relevant to them; issues may remain open after they’ve been fixed,
>     new activity on an issue may go unnoticed, cross-references among
>     issues are not visible in any of the interfaces, etc.

I believe some of the above, such as notifying everyone involved in a
ticket's discussion when replying, has been/could be tackled in the
improved GNU Debbugs rewrite that Felix has been refining and testing
[0, 1].  I think improving Debbugs for the whole of GNU (the Emacs
project actively use it still for example) would make sense and is
something I've been meaning to do, but not high in my priority list
(since it already works well enough for the most part).  Hacking a small
Perl code base doesn't appear much more daunting than the modern
Go-written, web framework library heavy mastodon I assume
Gitea/Forgejo is, so I'm not sure why we wouldn't try this first
instead.  I can't help but feel like we'd be throwing the baby out with
the bathwater: in my view, the current situation is not as bad as
suggested in your outlook, though I agree further automation and
simplifications would be welcome.

[0]  https://codeberg.org/lechner/mumi
[1]  https://patchwise.org/

> All this contributes to a [poor
> experience](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-3/)
> for those who choose to contribute despite the barrier to entry,
> probably discourages many to even start contributing, and adds to the
> load of committers and infrastructure maintainers.

My reading of the survey's results was that the main concern of the
community was packages' freshness and availability.  Our backlog is
already larger than we can handle.  Opening contributions from more
people, if that's what Codeberg would help with, wouldn't solve the real
problem of lack of eyes & hands to review and merge the contributions,
while giving us more work documenting the new workflows and their
quirks.

One serious usability quirk I can foresee is that given our current
PGP-based security design, committers would still need to push the
commits manually from their local machine so they can sign the commits
with their key, which probably defeats the streamlined and automated
niceties of the PR flow:

- The merge button in web UI would need to be disabled or documented as
prohibited (I doubt we'd even be able to disable it? or we'd need to
ensure the merge can be fast-forwarded and is already signed, which
would be a bit annoying since we'd need to not only fetch + rebase but
then visit the web interface to merge a change).  It can all be
automated via the HTTP API I'm sure, but that wouldn't be much of an
improvement (if at all) over our current flow.

I suspect not being able to follow the expected way of merging things
probably further implies that:

 - Issues won't be closed automatically since we can't use the merge
   button.
 - Both PR and issues must then be closed manually, which is what we
   currently have
 - The flow would be *even* more confusing than now, since it'd look
   like Github but require committers to use it very differently.

Which would again need more custom tools/scripts as a workaround.

[...]

> Within **30 days** following acceptance of this GCD, committers would
> migrate all these repositories to https://codeberg.org/guix.
>
> For Guix itself, we would decide on a **flag day** 14 days after
> acceptance of this GCD at the earliest, and 30 days at the latest.  On
> that day, the official URL of the Guix repository would become
> https://codeberg.org/guix/guix.git.  A commit would reflect that by
> updating:

I'd like to suggest extending the 'trial' period to something much
longer, like a year or so, to make sure our parachute is properly
installed before jumping the cliff :-).  Letting both systems co-exist
and compete for merit seems a good trial, and we could also extract
useful data (such as how many contributions were merged on one or the
other, etc.).  It'd be a bit annoying to keep an eye at two places for
some time, but at least we wouldn't commit to something that may not
scale/match our peculiar requirements as well as we expected.

After such trial we could then vote on whether we want to fully migrate
to Codeberg, when all regular contributors would have gotten a chance to
try the new tools and find a flow that works for them, hopefully.  With
this insurance in place, I'd be happy to experiment with Codeberg and
see whether it truly improves things.

Thank you for proposing this GCD!

-- 
Maxim