GNU bug report logs - #76503
[GCD] Migrating repositories, issues, and patches to Codeberg

Previous Next

Full log

View this message in rfc822 format

From: Christopher Baines <mail <at> cbaines.net>
To: 76503 <at> debbugs.gnu.org
Subject: [bug#76503] [GCD] Deliberation on: Migrating repositories, issues, and patches to Codeberg
Date: Mon, 05 May 2025 23:21:25 +0100

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> It’s been two months since we started discussing GCD 002, entitled
> “Migrating repositories, issues, and patches to Codeberg”.  Its final
> version is attached below.
>
> In accordance with the GCD process, team members have until May 6th to
> participate in deliberation by sending one of the following replies
> (quoting the GCD process):
>
>   - “I support”, meaning that one supports the proposal;
>   - “I accept”, meaning that one consents to the implementation of the
>     proposal;
>   - “I disapprove”, meaning that one opposes the implementation of the
>     proposal.  A team member sending this reply should have made constructive
>     comments during the discussion period.

I accept.

I do see some advantages for some of the repositories on Savannah that
will have new associated features like issue and patch tracking by
moving to Codeberg, but since Guix does differ from typical software
projects in the nature of the "code" and contributions, I remain
concerned that conforming the guix.git repository and associated patch
tracking in to the Codeberg/Forgejo model might not be in the best long
term interests of the project and contributors.

While this document is in favour of using a hosted service, personally I
think there are benefits to self-hosting and the project controlling the
domain that users use for the Git repository. Maybe the latter is
achievable depending on how the "Detailed Design" is implemented.

In the short term, this move will mean that QA will require significant
changes to continue doing something similar to what it's doing now for
providing automated testing for patches. Of course QA has been
notoriously unreliable so this isn't a new thing, and there is a
commitment to setup Cuirass at ci.guix.gnu.org to process Forgejo Pull
requests, but I'm unsure if this will fill in for QA and this gap may be
unfilled for an extended period.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.