Hi Tomas,
Tomas Volf <~@wolfsden.cz> writes:
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.
I’m not sure what the current state is, but when I was looking at
setting up a self-hosted forge, GitLab was operationally very
difficult, and I would say it arguably fails to clear the bar of
"plausibly self-hostable." And, having used it as a day-to-day
system for work, it’s very buggy and complex; and the public
gitlab.com instance has frequent outages.
And if you take issue with Codeberg’s ToS, I don’t think you’re
going to like GitLab’s. https://about.gitlab.com/terms/
## 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)?
I’m also wondering about the mechanics of this. With the volume
of patches Guix gets, any single cutover date will impact
someone’s work in flight. If it’s possible transition by:
- Setting a date for new work to occur in codeberg.
- Disabling the creation of new bugs in debbugs on that date.
- Allowing work in progress which was started in debbugs to be
completed in debbugs.
...that seems like a reasonable way to shift over.
## 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.
Yes. The repo settings lets you control which merge styles are
offered, and unchecking everything other than "Manually merged"
will disable the button.
-- Ian
