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

[Liliana Marie Prikler]

Hi Guix,

I'm in support of having a forge, but not exactly thrilled to structure
my workflow around it(s web interface).  IMHO, Forgejo/Codeberg is a
good choice however, so I won't debate that.

Am Dienstag, dem 28.01.2025 um 15:33 +0100 schrieb Ludovic Courtès:
> To keep track of bug reports and patches, Guix historically chose
> tools that were *simple* in their design:
> 
>   - bug reports and patches can be sent by plain email, without
>     having to create an account or even subscribe to a mailing list;
>   - discussion and patch review happen naturally by email, without
>     requiring special tools;
I think we should still have simple tools at our disposal, even if they
end up talking to Forgejo in the end.

Perhaps instead of
>   - Within **30 days** after acceptance of this GCD, mailing list
>     administrators will set up the `bug-guix` and `guix-patches`
> mailing
>     lists in “Emergency Moderation” mode in the Mailman
>     interface—meaning that messages will not get through anymore.  It
>     will still be possible to interact on individual issues via
>     `NNN@debbugs.gnu.org`.
we can make it so that emails to these addresses get forwarded to
Forgejo's bug tracker?

> 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.  This is a security
> feature that we want but it limits scalability as actual merges lays
> on the shoulders of committers.  To reduce the load on committers, we
> could use a scheme as follows:
> 
>   - contributors create pull requests against a `staging` branch
> (TODO:
>     check PR templates to force `staging` by default);
>   - the `staging` branch is *not* signed and team members can somehow
>     enact (TODO: figure how) merging into that branch;
I think we could go harder on the automation through the use of a merge
bot.  On a successful build+lint of a pull request, that request would
be merged into staging for a reviewer to look at.

Either way, having a single staging branch might be an issue if
submissions target different branches; e.g. one for python-team, one
for gnome-team.  Perhaps "teams" should be given their own
repositories, where they are free to create feature branches as they
like and have their "staging" branch(es) tail a particular branch.

Another idea would be that "staging" keeps the patches themselves as
files in a particular directory (e.g. patches/${bugnumber}), and
committers can apply them by doing something like

$ # git worktree add staging staging
$ git am staging/patches/${bugnumber}/latest/* --signoff

OTOH, whether this is preferable to grabbing the actual issue/PR is
debatable.

> That way, pushes to `master` will be limited to changes that have
> already been validated and built.
Perhaps we should rename 'master' to something else too.  Food for
thought for a future GCD :)

Cheers