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

[Steve George]

On 28 Jan, Ludovic Courtès wrote:
> Hello Guix!
> 
> I’m anticipating on the acceptance (hopefully) of the Guix Consensus
> Document (GCD) process:
> 
>   https://issues.guix.gnu.org/74736
> 
> (Speaking of which, if you’re member of a team as per ‘etc/teams.scm’
> and haven’t replied yet as part of the deliberation period, now is the
> time to do it!)
> 
> I believe this GCD can only be in “submitted” state if and after the GCD
> process is accepted, which would be on February 5th.  That doesn’t
> prevent us from having preliminary discussions, including in Brussels
> for those of us attending the Guix Days.
> 
> Anyway, the proposal is about migrating repositories, issues, and
> patches to Codeberg.  You’ll find the rationale, plan, and open issues
> in the attached draft.  I already found two “sponsors” for the proposal
> (meaning they agree with the general direction and are willing to
> participate in discussions) but if anyone else would like to sponsor it,
> I’m happy to add them.
> 
> Feedback welcome!
(...)

Hi,

I'm supportive as I think this will help the project develop and retain more 
developers.

The Survey shows the #1 piece of feedback from contributors is that the **speed 
and capacity of reviews** is a massive challenge: in one question 63% of 
contributors specified this as the biggest challenge. I think we know this - 
but seeing it at those levels really brings the point home! I can see that 
using a well-known forge would be give us ways to focus on automating patch 
review and simplify our overall process over time.

Second, people who've stopped contributing directly cited the overall friction 
and the email-based model as reasons why they stopped contributing. There were 
many comments about the unfamiliarity of the current process compared to the 
standard PR-based system. I infer that this change will help us reach out to 
develop our community of contributors.

I do think there's a cost for those of us who have a comfortable workflow (or 
in my case about 5 files of instructions!) - so I appreciate it's going to be 
uncomfortable/bumpy - but I believe the project will benefit.

Personally, I like Codeberg from what I've seen. I'd be interested in 
understanding how we can build a relationship with them?

Can we work with them as we migrate, what is their situation, and how do we 
support them financially since infrastructure isn't free?

Running less of our own infrastructure would be great, but we should be good 
citizens with Codeberg as a small non-profit (that's my current understanding 
of their situation).

Steve / Futurile