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

Previous Next

Package: guix-patches;

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

Date: Sun, 23 Feb 2025 15:21:02 UTC

Severity: normal

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Full log


Message #173 received at 76503 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, Arun Isaac
 <arunisaac <at> systemreboot.net>
Cc: 76503 <at> debbugs.gnu.org, Ricardo Wurmus <rekado <at> elephly.net>,
 Christopher Baines <guix <at> cbaines.net>, Benjamin Slade <slade <at> lambda-y.net>
Subject: Re: [bug#76503] [GCD] Migrating repositories, issues, and patches
 to Codeberg
Date: Thu, 06 Mar 2025 17:36:29 +0100
Hi Ludo,

On Wed, 26 Feb 2025 at 22:01, Ludovic Courtès <ludo <at> gnu.org> wrote:

> I think I was/we were wrong in two ways: first it’s not just about
> providing a web interface, and second there are limitations in our
> workflow that we just cannot overcome, as I tried to explain in the
> “Motivation” section.  We tried, very hard, and for a reason: a belief
> (as far as I’m concerned) that we could not only be responsible for our
> infra but also, in a way, that we could show fellow free software
> hackers that an alternative development model was possible.

Have we really tried hard?  Not about the maintenance, big thanks for
all guix-sysadmin!

About developing the tools: As a project, I would not say “we tried very
hard”.  Chris did, almost alone – thanks Chris for this heroic long-term
commitment effort.  And about Cuirass, the last effort had been years
ago, to my knowledge.

As I wrote elsewhere, what are the concrete current features that
Codeberg offers against our limitations?

Our main limitation isn’t about contributing but about reviewing, IMHO.

Therefore how Codeberg is concretely helping?  Not what are the
potentialities that Codeberg offers, but what does Codeberg bring on the
table right now compared to our current workflow?

Well, from my understanding, it’s easier to automatically build a PR
than to automatically extract patches and build them.  So, Codeberg
helps right now because of CI.  Do I miss another feature that helps
reviewing? 


> I agree with Leo and the GCD mentions it as well: we need to talk with
> Codeberg e.V. from the start, possibly becoming a voting member, and to
> offer funding.

Hum, are we not putting the eggs before having the basket? :-)

Somehow, instead of a “Big Move”, it seems more approachable to only
move some teams, for example.  Something like an incremental
“improvement”.  It would help to have a concrete basis for discussing
how we can help them to have a sustainable solution for the Guix
project.


> Codeberg e.V. is specialized so I’d like to believe they have a lot of
> headroom.  That they’re transparent and upfront about their scalability
> issues is a rather good sign to me.

What if tomorrow Codeberg closes for whatever the reasons?  Obviously,
we will find another solution. :-)

However, what about all the history hosted there?  Yes, there is a nice
API and everything is doable. :-)  To my knowledge, nothing is done for
having a backup of all the history.

About Debbugs, we have one public-inbox at least.  Maybe archived [1] in
Software Heritage since public-inbox is Git-based. ;-)

> Assuming we agree that a move along the lines of this proposal is
> desirable (let me know if you think we don’t share that premise), what
> other options would you think of?

I do not know if I share the premise…  Well, for sure, as discussed with
a beer \o/ in Guix Days, I agree that we need to act now because the
current situation raises too much friction and that will be detrimental
for the project in the “short” term.

What I’m not sure about is the path for moving.  Somehow, I find it too
much in a hurry.  For instance, the GCD reads,

        Within **30 days** following acceptance of this GCD, committers would
        migrate all these repositories to https://codeberg.org/guix.

        For Guix itself, we would decide on a **flag day** 14 days after
        acceptance of this GCD at the earliest, and 30 days at the latest.  On
        that day, the official URL of the Guix repository would become
        https://codeberg.org/guix/guix.git.

when we have not yet discussed hard numbers with Codeberg.  Or when we
do not have discussed on Guix Foundation side what could be done for
supporting them.

Similarly, why do we need to move in the same time the Issue Tracker?

Somehow, I would prefer a more incremental move.  Because it would help
to improve step after step.  Maybe using 2 or 3 steps over the whole
2025 year.

Cheers,
simon


1: The first patch sent to guix-patches, SWH still ingesting when
   writing this. :-)  So maybe here…

https://archive.softwareheritage.org/swh:1:cnt;ce7a09543926f7e5717b7a3f8fa3c1f6d5fdb5f1




This bug report was last modified 16 days ago.

Previous Next


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