Hi Ludovic, Ludovic Courtès <l...@gnu.org> 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
