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

Previous Next

Full log

View this message in rfc822 format

From: indieterminacy <indieterminacy <at> libre.brussels>
To: Divya Ranjan <divya <at> subvertising.org>
Cc: Ekaitz Zarraga <ekaitz <at> elenq.tech>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Ludovic Courtès <ludo <at> gnu.org>, 76503 <at> debbugs.gnu.org, Carlo Zancanaro <carlo <at> zancanaro.id.au>, Felix Lechner <felix.lechner <at> lease-up.com>, Guix Devel <guix-devel <at> gnu.org>
Subject: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Date: Mon, 10 Mar 2025 12:05:08 +0000

Hello all,

Reading a random fediverse thread, I came across some aspects about 
growth of issues and governance around duplications and feature 
requests:

https://social.wildeboer.net/@jwildeboer/114131748974841455

```
What I gather from the replies is that better issue tracking should work 
with at least 3 separate queues:

- Bugs (things that don't work as they should, breaking functionality, 
can be fixed relatively fast)
- Feature requests (Things that don't exist yet in the codebase but 
could be added)
- Refactoring (Things that can be bugs or features, but to solve them a 
redesign/rewrite/refactor of certain parts of the codebase is needed)

Triage should decide where a new issue belongs.
```
https://social.wildeboer.net/@jwildeboer/114132897616035930

```
often issue trackers are used for feature requests.  I think it is 
reasonable for those to stay open for long-ish periods of time as part 
of a long term roadmap or a help-wanted list.  I agree those should be 
clearly distinguished from bugs, but sometimes the line between "missing 
feature" and "bug" blurs.
```
https://kolektiva.social/@cscott/114132771181298941


Is there a need to provide more formal clarifications regarding 
collective expectations and emphases?
Are there any case studies we are using to inform such outcomes?
In particular, is there anything distinct to the Guix experience that we 
need to be mindful of?

Kind regards,


Jonathan

On 2025-03-07 06:18, Divya Ranjan wrote:
> 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,

Previous Next

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