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

Previous Next

Full log

View this message in rfc822 format

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: arunisaac <at> systemreboot.net, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, ludo <at> gnu.org, Cayetano Santos <csantosb <at> inventati.org>, Andrew Wong <wongandj <at> icloud.com>, slade <at> lambda-y.net, 76503 <at> debbugs.gnu.org, guix <at> cbaines.net, Leo Famulari <leo <at> famulari.name>
Subject: [bug#76503] [GCD] Migrating repositories, issues, and patches to Codeberg
Date: Fri, 07 Mar 2025 19:07:06 +0100

Hi Simon,

> On Thu, 06 Mar 2025 at 21:05, Ricardo Wurmus 
> <rekado <at> elephly.net> wrote:
>
>> It seems that on Codeberg the primary means of keeping track of 
>> things
>> is through notifications.  I fear I might still end up dropping 
>> the
>> ball when a PR requires my attention if it gets buried in 
>> countless
>> notifications -- especially if I have to keep them unread to 
>> ever have
>> a chance of finding them again.  Obviously, a fix here would be 
>> to
>> adjust my behaviour and not let notifications pile up, but this 
>> has no
>> chance of ever happening.  (In completely unrelated news: I've 
>> got
>> 17532 unread Guix emails.)
>
> Yes, I agree.  IMHO, it would be a mistake to think that 
> Codeberg would
> ease how to deal with all the submissions.  Even, because there 
> is no
> simple tools at hand – as Maxim said in [1] – the current 
> interface
> makes the process harder, from my point of view.
>
> For example, Leo wrote [2]:
>
>         For me, the big problem with email is that resolved 
>         tickets don't get
>         removed from my inbox. Currently, my guix-patches inbox 
>         has 7000
>         messages. And 520 for bug-guix. Since April 2024.
>
> and yeah that’s an issue!  Well, maybe I’ve missed the obvious 
> but my
> Notifications are not removed when the PR is merged.
>
> Somehow, the way Codeberg Notifications is currently implemented 
> does
> the same way as “my inbox”, IIUC, except that instead of being 
> able to
> manipulate these tickets with the comfort on a good email 
> reader, now we
> need API queries or live in the browser.

It seems that Forgejo Notifications are not the correct interface 
to improve our overview, because as you say they would suffer from 
the same problem as emails with the added disadvantages of 
cluttering the email inbox (with notification emails) and the lack 
of a local client to make sense of them (which is what email 
allows us to do).

I found that the URL

   https://codeberg.org/org/guix-science/pulls?\
       type=review_requested&\
       sort=recentupdate&\
       state=open&\
       q=&fuzzy=true

Shows me current pull requests that still await my review. 
Likewise I can list those I've reviewed already with 
"type=reviewed_by" and those assigned to me with "type=assigned". 
Curiously, these filters don't seem to be exposed in the API 
endpoint /repos/{owner}/{repo}/pulls.

Reviews can automatically be requested via the CODEOWNERS file, so 
I think moulding our workflow around this overview would be an 
obvious improvement.

> Somehow, we need something more gradual. For instance, 2 or 3 
> steps with
> concrete and detailed milestones; targeting the end of “patch by 
> email”
> something as next December.
>
> Why?  Because we need to learn more where the friction could be, 
> what is
> really lacking, what makes too much hurdle, etc.  And adapt 
> accordingly.

This sounds reasonable, but perhaps the migration is not quite a 
big as we think.  There are not that many committers, who would be 
on the receiving side of pull request review.  What do the current 
committers absolutely require of the forge to be able to complete 
at least as many reviews as they do today?  Perhaps we can 
concretely list the committers' requirements, and see what 
solutions or workarounds we can find for each of them.

This is setting aside more fundamental misgivings such as "I don't 
like that Codeberg requires an account" or "I don't feel I can 
trust Codeberg e.V. with our data", which ought to be negotiated 
in this discussion.  (I don't like that Codeberg requires an 
account, even for the AGit workflow, but I think there could be 
workarounds, and I don't consider this more than a minor 
inconvenience.)

> All that to say, I am not convinced that completely jumping to 
> something
> fully new for most of us is a good approach; especially when the 
> same us
> already know the pitfalls of our tools or behaviour.

A complication of a partial move (perhaps just the r-team and the 
python-team) is that it starts an extended period of confusion for 
contributors.  We would have to document the preferences of each 
team.  I don't know if the GCD process is laid out for per-team 
decisions like this.

If the experiment is deemed a failure by those who have moved to 
Codeberg they'll just move back.  But what if the experiment is 
only deemed a failure by those who haven't actually given Codeberg 
a try?  We'd end up with permanent fragmentation.

-- 
Ricardo

Previous Next

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