Subject: Re: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg

From: Divya Ranjan <[email-masked]>
Date: Fri, 07 Mar 2025 06:18:25 +0000

Hello Carlo,

> I don't think this is a fair summary of the goal. The first sentence of
> the GCD[1] is:
>
>   The contribution workflow in Guix has been facing several challenges:
>   difficult onboarding, lack of legibility, complex, unreliable, and
>   labor-intensive infrastructure, and lack of automation.
>
> Of these, only "difficult onboarding" is about newcomers. Your proposal
> (which I might describe as "proxy Codeberg into debbugs") involves
> building new infrastructure without helping the other issues.

You are correct, Carlo, the GCD does have multiple goals. But in my email I also elaborated how the onboarding issue is a high-priority task, reflective from the last survey and also something that can be achieved without risking too much. I believe we are at a probabilistic trade-off decision here, do we wish to achieve all the goals, including a complete change of infrastructure, workflow etc. in the proposed timeline of 15 days or so, and thus incurring a lot of problems that a team of committers would’ve to put a lot of effort into resolving? Or, do we wish to slowly achieve some of the goals, take those goals as a litmus test for the overall proposal and proceed gradually? I believe latter would be a safer bet, with less to risk immediately and opportunity to fix mistakes from feedback.

So, yes, my proposal cannot resolve all the goals, but I am trying to find a way to integrate what we have with what we might switch to. I might be at fault here, and feel free to elaborate on that, such as how can we approach the proposed quick migration to Codeberg while having a huge backlog of patches? 

>> Since Codeberg already allows to communicate in issues over email,
>> i.e. you can respond to someone in a particular issue over email, this
>> shouldn’t be too difficult to arrange.
>
> This is not true today. While Forgejo supports replying via email,
> Codeberg does not have that enabled due to bugs. They have an issue
> tracking it: https://codeberg.org/Codeberg/Community/issues/1562

Thank you for this. I had tried it on a Forgejo repository, not a Codeberg one, so I believed the same could be possible here as well. From the discussions I see, if we spend enough time with them--which we need to do either ways--for the migration, they might get it working? Does not look far from possible to me.

> Even if it was true, the big disconnect here would be around commenting
> on specific lines of code. An email with a comment on a patch would come
> through as a top-level comment on the PR, which is not natural in that
> context.

Also thank you for bringing this issue, indeed this is a crucial functionality. But to be clear, this is specifically for a pull-request. The issues functionality is totally doable out of the box with Forgejo, we just need to make it work with Codeberg and polish it. With regards to the PR, one has to remember that the entire process needs to be wrapped around Forgejo’s API, not as our used to method of plain text. We’d be parsing JSON to-and-fro. For "reviewing a Pull Request" in Codeberg methodology, Forgejo provides a =/repos/{owner}/{repo}/pulls/{index}/reviews= API[0] to initiate a review. This API will take the comments from the patch in the Email, place them in the "body" string of the JSON, and the respective positions from the diff, the commit_id and so on. I agree it is non-trivial, but so is switching a workflow that has been in-place for years, also a non-trivial task. I think the API has enough things for what we need. And again, we don’t need all of them, we only require implementing those for now that bridge existing email workflow and the newcomers’ onboarding. Merging, for example, I propose to be done in the usual way of taking a patch and applying it. Eventually once we have less of a backlog, and more ease of migration, one might consider moving these core tasks to the Codeberg as well.

Either ways, we are at the crossroads and we need to decide which trade-off is worth the pain. I believe it is *not* certain that once we entirely migrate to Codeberg, the goals of "complexity" and "lack of legibility" would be immediately reaped. It creates a possibility of enjoying them, but given the assumption that the switch from existing architecture is smooth. And, once again, if we were a relatively smaller project such as the Guix-Science, this could’ve been a decision much simpler and with less at stake, but that is not the case. But I think it *is* certain that if we take an approach that doesn’t directly replace one workflow with another, but bridges the new one with the previous one, the committers will have a better way to switch. Simply because they can try to finish the backlog using the existing workflow, and the new patches can come to them with that as well. Where we go from there, can be decided upon how good the litmus test goes.

[0]: https://codeberg.org/api/swagger#/repository/repoCreatePullReview

Regards,
-- 
Divya Ranjan,
Philosophy, Mathematics, Libre Software.

PGP Fingerprint: F0B3 1A69 8006 8FB8 096A  2F12 B245 10C6 108C 8D4A