Tomas Volf <~@wolfsden.cz> skribis: >> The software behind the forge has to be free software that is >> *plausibly* self-hosted on Guix System—this probably rules out GitLab >> Community Edition > > I am curious about this. GitLab Community Edition is under MIT (so > ticks the free software checkbox). While I am not an expert, I *think* > it is mix of golang and ruby code, so that seems feasible to self-host > on top of Guix system?
There are several issues with GitLab: first, it is developed by a for-profit under an “open core” model—not exactly in line with the way many of us in the project envision user freedom. Secondly, it’s a beast, a very big piece of software, and something that’s also not trivial to administrate (IT department at work runs an instance, but there’s quite a few people to keep it afloat). Last, even if we put client-side JavaScript aside, it’s unlikely we could package it all in Guix. > And GitLab would have the advantage that (Magit) Forge works with it. We briefly discussed it with the Codeberg/Forgejo people and they noted that most of the Gitea/Forgejo interface is actually the same as that of GitHub, so it may be that GitHub clients could do some/most operations on a Forgejo instance. Worth investigating. Overall, I’m not too concerned about our ability to figure this out; it’s work, yes, but little compared to developing and running mumi, running Patchwork, etc. >> The Savannah `guix.git` repository would become a mirror of the one at >> Codeberg, with a script periodically updating it, as a way to ease >> migration to the new repository for users. > > Will all the repositories listed above be mirrored? Or just the > guix.git? It’s up for discussion. Personally, I’d just keep guix.git on Savannah, clearly marked as a mirror; I think keeping all of them in both places could be confusing. >> ## Issue Tracker Migration Path >> >> Importing all the issues and patches from Debbugs/mumi into Codeberg >> would be impractical: it would require the development of specific >> tools, would be a lossy process due to the fundamental mismatch between >> plain text email threads and Forgejo issues and pull requests, and would >> bring little in return. > > I understand the impracticality, but just want to make sure I understand > the implications. Will this mean that I will have to go over all my > patches and resend them to Codeberg one by one, or is it expected the > patches already sent will still be processed (just new ones will not be > accepted)? What I’m proposing (but again, up for discussion) is to discuss patches already on issues.guix via email just like we currently do. >> Care will be taken to advertise the various interfaces to >> Codeberg/Forgejo that exist in addition to its web interface, such as >> [forgejo-cli](https://codeberg.org/Cyborus/forgejo-cli/) and >> [fj.el](https://codeberg.org/martianh/fj.el/). > > I took a look at the fj.el and I did not figure out how to for example > create a pull request. So I assume people will need to create their own > tooling, probably around the forgejo-cli. I would just extend fj.el in this case. The HTTP API basically covers everything one can do via the web interface, and it’s all pretty well documented: https://forgejo.org/docs/latest/user/api-usage/ https://codeberg.org/api/swagger#/ If the needs arise, we could even have a Guile client in the style of (guix swh), (guix import pypi), etc. >> ## Workflow >> >> [..] >> >> Since Guix requires signed commits by people listed in >> `.guix-authorizations`, we will *not* be able to click the “Merge” >> button nor to enable auto-merge on build success. > > Out of curiosity, is it possible to disable the merge button? I am > pretty sure it is just a matter of time until someone presses it by > accident. One can configure Forgejo to refused unsigned commits (this is what we did for <https://codeberg.org/guix-science/guix-science>, which is signed). In that case, Forgejo just won’t merge because it cannot sign commits (well, I think the instance could be configured to sign commits, but Codeberg’s is not). >> XXX: Does it really belong in this document? Should we just keep that >> for later? > > In my opinion this deserves separate document later. That would help to > keep the debate focused on a single topic. OK. Thanks, Ludo’.
