Hi, Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
>> 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. Let’s not underestimate the development work by Ricardo, Arun, and Chris over these tools for years (7 years for mumi), but also the everyday sysadmin work done to keep things running. > 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 I wouldn’t say that Savannah has been stable; debbugs.gnu.org is running an unpublished, non-version-controlled fork of the original Debbugs running on a single machine, manually-modified every now and then (I know because I tried to rectify this back then, and so did Felix I believe). I agree that maintenance of these is largely a given for Guix. But let’s not idealize it: there is a huge technical debt in all this infrastructure. > 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). That may be true, but I wouldn’t blame them given what it costed us to run one server with a free BIOS¹. Codeberg/Forgejo volunteers are free software activists though. ¹ Andreas gave a good account of this story in <https://10years.guix.gnu.org/video/ten-years-of-failures/>. > 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. Correct. Though, as the GCD states, it would reduce the number of services and amount of code to maintain (Patchwork, email parsing, 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. I held this view for many years, which is part of why we have this infrastructure; we’re not throwing the baby with the bathwater, we have a decade of experience. I think this endeavor hasn’t been as fruitful as we had hoped for and that it’s holding back the project now. (For the record, Forgejo is known to be lightweight; the code base is “human-sized” and easy to navigate IME.) > 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. As others noted, better tooling is likely to improve reviewer throughput. Of course nobody can guarantee any speedup, but there are hints suggesting that. I have been using the PR style (initially reluctantly) for Guix-Science, Guix-HPC, and related repositories; I find it easier to see where my attention is needed and what the status of patches is. That’s also the reason I’ve been inviting people to give it a try: I initially knew very well what I loved about the email workflow and what I hated about the PR workflow, but only through experience did I discover good things about the PR workflow. > One serious usability quirk I can foresee is that given our current > PGP-based security design, The “Merge” button would be disabled, as noted in the GCD. > - Issues won't be closed automatically since we can't use the merge > button. There’s an “autodetect manual merge” feature; it’s not as “auto” as one might like but it’s okay. > - Both PR and issues must then be closed manually, which is what we > currently have Issues are closed automatically upon “Fixes #123” messages in commits. Please give it a spin; it’s not perfect but it’s much better than what you suggest. :-) > 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. As noted in my reply to Arun², I think there’s a risk of splitting the community if this experiment were too last for several months (Arun proposed 30-day coexistence period, with eventual migration to Codeberg). But maybe you can propose wording to amend the GCD? ² https://issues.guix.gnu.org/76503#37 > 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. The GCD process is about collectively building a proposal; there’s no voting. I would encourage everyone to propose changes to the proposal to address their concerns—it’s a living document. As for experimenting, I agree and I reiterate my invitation to send trivial patches to <https://codeberg.org/civodul/guix> (or to Guix-Science, Guix-Past, etc.). I think this GCD’s discussion period is the right time to give it a try as it can better inform discussions. Thanks for your feedback! Ludo’.
