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

[Divya Ranjan]

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