Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Ian Eure]

Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

> Sorry for second email, few more comments and questions.
>
> Ludovic Courtès <ludo@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