Sorry for second email, few more comments and questions. Ludovic Courtès <l...@gnu.org> writes:
> ## Choice of a Forge > > 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? And GitLab would have the advantage that (Magit) Forge works with it. > 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? > ## 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)? > 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. > ## 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. > [..] > > 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. > Migrating to a different Forgejo instance would be rather simple since > Forgejo is able to *import* entire repositories with their settings > (including teams) and issues and pull requests from other instances. > Users would have to create accounts on the new forge instance though. > However, if federation support matures in Forgejo, one may be able to > operate on a repository from distinct but *federated* instances. That > would make any move much easier. The federation looks interesting and I really hope it will get finished. Would be pretty neat solution to lot of problems. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
