Hi Ludo,
I have not read yet the updated version…
> An incremental move from guix-patches to PRs as you suggest sounds
> perfectly reasonable to me
> I’ll propose
> changes along these lines.
…so I will comment elsewhere about how “incremental” it appears to
me. :-)
Initially, my objective here was to focus on few points and just precise
my previous comments. Then, I do not know who released my fingers. :-)
All will be fine with if my words are redirected to /dev/null. At
least, there are here for the record.
>> 1. Drop the section of « Issue Tracker Migration Path ».
>
> To be clear, are you suggesting to not use Codeberg for bug reports at
> all?
To be clear, yes.
> We could change it to “Migrating repositories and patches to Codeberg”;
> that has less appeal to me, because I’m confident that (1) this would
> lead to confusion, and (2) we’d miss out on cross-referencing and other
> niceties.
Cross-referencing fully locked in the Codeberg web-interface, right?
Which niceties do you speak about?
> I too hate having to create an account, but let’s face it: we’re used to
> it these days, and Codeberg allows you to sign in with a gitlab.com or
> github.com account (I don’t support any of these, but it’s a fact that
> many people have an account there already.) “Necessary evil” for me.
>
> As I wrote elsewhere, we’ll also gladly take bug reports on guix-devel
> in practice (we already get bug reports occasionally on mailing lists,
> IRC, etc.), so nobody would be “forced” to sign in on Codeberg.
It’s not about being “forced” or not, it’s about the signal it sends.
For instance, I cannot promote Free Software and advocate at length
about user-autonomy. Then somehow give up and say: Hey, no worry when
you don’t want to create yet another account, Codeberg bridges with .com
companies as gitlab or maybe worse github.
Somehow, I share the argument “we must act now about reviewing” because
a vicious circle is emerging and it could be detrimental more or less
quickly. And I also share the argument: it’s complicated to bridge the
submissions by email with CI – although we did not tried very hard if we
all are honest; Chris almost alone did – when it’s much easier with
Codeberg thanks to its rich API. For reviewing, what Codeberg brings on
the table outperforms the contradictory signal.
I consider the point about “lead to confusion” but that’s appear to me
weaker than the contradictory signal about user-autonomy.
Because we have to be very clear: the migration from emails to Codeberg
isn’t only the technical migration of the workflow. It’s much deeper:
it’s a “philosophical” migration.
It’s a migration from relying on standards protocols to relying on one
external central service. On one hand, it promotes user-autonomy and
illustrates the freedom by the example, because it pushes us to shape
our tools – yes, imperfect tools with many friction. On the other hand,
it promotes “efficiency” to do more or quicker with counterparts; the
freedom is locked. All the story isn’t about one being “evil” while the
other being “angel”, or vice-versa. All is grey and the story is about
the flavor of this grey.
We have to be very clear, it’s two-ways: communities shape their tool as
much as their tool shape the communities. I hope we are all aware that
this migration will modify the profile of people involved in the Guix
community. For the Good, the Bad and the Ugly.
>> b) How to deal with the backup of the history?
>
> I would rely on backups done by Codeberg e.V. after checking with them
> what’s in place.
Yes, OVH also told all will be fine. ;-)
> We could also set up our own thing; I’ll inquire to see if there are
> tools to do that for regular users.
This is what I have in mind. Please note I’m not considering this as
blocking or something we must have on Day-1.
> (Keep in mind though that nobody stepped up to help out with backups of
> our existing infrastructure, though.)
By design of mailing lists, it’s distributed and easy to recover in
extreme worst case scenario.
All the inboxes of subscribers are backup for patches and bugs. :-) In
addition, there is the mirrors of the mailing lists as Mail Archive or
others. Last, there is one public-inbox instance and thus many
public-inbox clones.
You agreed on more incremental migration. So I do not know who the
following is trying to convince. :-)
Maybe it’s an hidden call to the Deliberation member… Heh!
>> 3. More milestones for the « Repository Migration Paths ».
>
> On experience: collectively, we have experience with Codeberg and with
> other forges; many of us frequently interact with this kind of forge.
Who is the ’collective’? How many of the current people with write
access on Savannah have an account in Codeberg? And how many concretely
did at least one review (with comments) and merged a PR?
As I wrote elsewhere:
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, you developed a experience. Who Deliberation members might
report a minimal experience?
> So, while switching to Codeberg is a big change, I think we should also
> not downplay the ability of contributors to adapt to something many/most
> of them already know.
Obviously. :-) The question is about having an informed decision by the
people who deliberate. And not a vague picture from a galaxy far, far
away.
It’s not to make the decision bigger than it is. If I ask to the Ludo
from one year ago (before investing time with Codeberg and propose to
switch to the Guix-Science channel), do you want yo migrate? What would
have been your answer? Probably the same as I am doing now: Euh, yes
why not but hmm I am not sure, well I do not know.
Somehow, imagine all the annoyances you have with Emacs. Now, imagine I
tell you: Hey, look this tool does the same as Emacs without the
annoyances you are pointing and yes you can also extend it. Many people
use it. And some users are around. Wonderful, no? Do you switch
without trying it a bit?
If yes, cool now you are an happy user of VSCode for the next
decade. ;-)
Cheers,
simon
