GNU bug report logs -
#76503
[GCD] Migrating repositories, issues, and patches to Codeberg
Previous Next
Full log
View this message in rfc822 format
Hi Ricardo,
On Fri, 07 Mar 2025 at 19:07, Ricardo Wurmus <rekado <at> elephly.net> wrote:
> https://codeberg.org/org/guix-science/pulls?\
> type=review_requested&\
> sort=recentupdate&\
> state=open&\
> q=&fuzzy=true
For instance, this is listed for me:
https://codeberg.org/guix-science/guix-science-nonfree/pulls/30
and…
> Reviews can automatically be requested via the CODEOWNERS file, so
> I think moulding our workflow around this overview would be an
> obvious improvement.
…and maybe I misread CODEOWNERS [1], but I miss why this PR is listed
for me.
1: https://codeberg.org/guix-science/guix-science-nonfree/src/branch/master/CODEOWNERS
>> 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.
Yeah good ol’ resistance to change. ;-)
However, the GCD reads
Within **30 days** following acceptance of this GCD, committers would
migrate all these repositories to https://codeberg.org/guix.
and we are just starting to discover what could be done with the API or
how to effectively improve the identified bottleneck with emails, but in
the same time, it also introduces annoyances.
For example, one thing is the backup of all what is going to happen in
Codeberg: all the history of PRs, revisions, discussions, etc.
We jump in without a concrete implementation for such backup. Bad
scenario, imagine: couple of months later – we will have several open
and closed PRs – Codeberg suddenly disappears for whatever unexpected
reasons: How do we get all the data associated to our open and closed
PRs?
> What do the current
> committers absolutely require of the forge to be able to complete
> at least as many reviews as they do today?
For me,
a) work offline and by batch;
b) comment on patches without the web-interface; comment from Emacs;
c) being able to personally tag for later retrieving back;
d) bridge with Org-mode.
If I am transparent, the biggest annoyance for me when reviewing isn’t
about the workflow but it’s about the CI and/or QA. In other words,
this “Big Move” will introduce much more frictions on my side than
effectively smooth.
My main issues with CI and/or QA is that it’s much too slow to work on.
Not slow to process the queue – it might be but hey! – no, it’s about
too slow to query; especially via the web-interface. Well, I do not
know what has changed over the past year, but now for me ci.guix is
almost unusable.
And the “Big Move” will change nothing about the data generated by CI
and/or QA. It could only ease the bridge, IIUC.
> (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.)
Somehow, I agree. The 4 items above are “minor inconvenience” because
it’s possible to find and/or implement workarounds. However, it does
not appear to me doable considering the time frame that the GCD proposes
with the “Migration Path”.
To say it explicitly, these 4 items are “no go” for me. Not that I
would block the GCD but for sure I will stay aside – and for being
consistent, I’ll ask to suspend my write access – the time to have
something that fulfills these requirements.
No big deal, I barely review these days after all. :-)
>> 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.
Well, maybe the level of team isn’t the good one for such partial move.
For sure, I find awkward to jump in the unknown without any prior
minimal experience with PR workflow for almost all the people who have
experience with email workflow and are reviewing.
Just to mention. What Ludo did months ago, Ludo tried Codeberg, then
Ludo moved the channels guix-science, then Romain adapted Cuirass – or
maybe Romain adapted Cuirass before the guix-science channels move,
anyway–, then ~100 PRs has been submitted. Etc. All that creates this
minimal experience.
Now, when Ludo says: it’s okish enough and it’ll be fine with me, yes I
trust their words. Because they are somehow backed.
How many of us have a same minimal experience with PR?
Somehow, it’s a biased decision: Here is the way you know well and thus
the way you concretely know the frictions and annoyances. Compared to
that, there is the way you imagine and thus the way you hypothetically
speculate how smooth it will be or how worse it’ll become.
Concretely, it does not sound to me reasonable to say: Hey after the
23rd of May, all will happen on Codeberg, post-scriptum: good luck! :-)
I find more reasonable to have 2-3 milestones. And we also must discuss
with Codeberg on concrete numbers because that’s not an unilateral
decision, IMHO.
All that to say, yes I totally agree, the best approach seems:
What do the current
committers absolutely require of the forge to be able to complete
at least as many reviews as they do today?
Cheers,
simon
This bug report was last modified 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.