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

[Ekaitz Zarraga]

Hi,

In general I've been trying to avoid to take part in the conversation 
because I basically don't know what to say.

I have a codeberg account that I use with my students, and I also have 
github and gitlab accounts. I also have one account in many gitlab 
instances of projects I contributed to... I don't like having that many, 
but I have no choice.

You don't need an account to contribute to Guix (committers have the 
account in your behalf). That's a very good point, and I'd like to keep 
that if possible.

Also, I'd prefer some platform that keeps the process similar to what we 
currently have. Sr.ht has been proposed before, but it's really hard to 
operate and US based if I'm not mistaken. So that leaves us with only 
one reasonable option, which is the one that has been proposed.

It's a good proposal. I was unsure if the "noise" that people who wanted 
the change was payed attention to a little bit too much, and the survey 
also shows that is a minority, but is a large one and I predict that 
most of the people don't actually care about the process, but about the 
software. I'm in that team.

I don't know if I like the proposed contribution process, but I think it 
will be fine. Or at least as good as the current one is.

My main concern was about the sustainability of Codeberg, and that's 
being taken in account so: It looks good to me.


On 2025-01-30 07:48, Ricardo Wurmus wrote:
> I'd just like to note that (the GNU instance of) Debbugs is a third
> party dependency, and it is inflexible enough that mumi cannot
> effectively work around all its defects or annoyances.  Both (this fork
> of) Debbugs and Savannah---while operated by dedicated volunteers---are
> not in active development, as far as I know.  Extending them for our
> puproses is not a realistic option.

About this, Ricardo, you have a great point here. Savannah and Debbugs 
are very old and they are not under development. Maybe it's the FSF who 
should migrate their infrastructure to some better forge that fits their 
needs. Sr.ht fits more with their style, and they have the energy to 
operate it. In any case, and thankfully, it's not our goal to fix the FSF.

On the other hand, everything won't be lost in the process! We could 
keep some of our tools if we don't mind to rewrite some parts. Forgejo 
has an API we can exploit:

https://codeberg.org/api/swagger#/issue

Cheers!