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

From: Arun Isaac <[email-masked]>
Date: Thu, 27 Feb 2025 01:44:29 +0000

Hi Ludo,

> First, thank you and Ricardo for mumi.  I didn’t write a single line of
> it but I certainly encouraged it, enjoyed it (the version you deployed
> yesterday or so is super nice, BTW!), and for a long time saw it as the
> key to providing a good contributor experience “to those who don’t like
> email”.

Thank you, I appreciate it. :-) I have more improvements (filtering
issues by team, for instance) in the pipeline, and will probably deploy
them in another week or so.

> Your message raises concerns about the storage/bandwidth requirements of
> Guix and the ability of a non-profit to keep up.
>
> I agree with Leo and the GCD mentions it as well: we need to talk with
> Codeberg e.V. from the start, possibly becoming a voting member, and to
> offer funding.

Good points, I agree.

> Codeberg e.V. is specialized so I’d like to believe they have a lot of
> headroom.

> That they’re transparent and upfront about their scalability issues is
> a rather good sign to me.

I agree. I liked the honesty of the person we met at the FOSDEM stall.
And, I like it that their blog discusses their scaling issues openly.

> Assuming we agree that a move along the lines of this proposal is
> desirable (let me know if you think we don’t share that premise), what
> other options would you think of?

I think we share the premise. I am not fundamentally opposed to the
proposal in any way. Lowering the barrier to entry and making the
project more accessible is a good thing. But…

According to the survey, only 9% want a pull request workflow, while 20%
just want timely reviews. My hunch (I have no data or proof) is that the
9% would also be perfectly happy if we just provide them timely reviews.
And, to provide timely reviews, we need to be focussing on entirely
different things—for example, the infinite growth of our package
collection and the strictness of our code reviews. If we could decompose
Guix into smaller channels, some of which have less stringent review
processes, we may get much faster reviews. To some extent, we see this
already in channels such as guix-science (less stringent review),
guix-cran (no review!), etc. Centralization of review and decision
making does not scale well. To grow, we need to devolve power. One day,
we aim to be as big as or bigger than Debian. We cannot do that without,
in some way, imitating their organizational structure. Shovelling more
coal into the fire may not be enough. It might work for a bit, but then
we'll just hit another limit and be stuck again. And, considering the
counterintuitive speed of exponential growth, we may reach that new
limit in no time. Some version of
https://en.wikipedia.org/wiki/Amdahl%27s_law applies here.

The proposal mentions better automation of our review process. But, many
of our review processes are not automatable—at least not easily so. For
example: the avoidance of marketing language in synopses and
descriptions, the listing of licenses for every single file in the
source tarball, the indentation of code[1], etc. Some rules such as the
use of double space[2] are antiquated and can be dropped with no
consequence. Our baroque Changelong format is another target of much ire
(even though I personally like it enough to use it in my own projects!).

[1]: there's human judgement involved (and for good reason) despite guix
     style and other tools
[2]: Even the behaviour of Emacs sentence commands are not much of an
     excuse here. I found out recently about the
     sentence-end-double-space variable.

The Codeberg move aims to make it easier for contributors. But, if
anything, we already have too many contributions and are unable to keep
up with reviews! :-D Codeberg is likely to increase the number of
contributors without significantly increasing the number of reviewers. I
cannot be sure of this, nor can I provide much in the way of proof; only
time will tell.

I am sure a move to Codeberg can be seen as orthogonal to all these
concerns. And, perhaps it is. But, I'm just saying we should discuss the
limitations of this approach and be more aware of the larger
bottlenecks. What if we're throwing away the email workflow for nothing!
[half kidding] ;-)

Requiring the agit workflow and disallowing forks (preferably enforced
by technical means), thus solving the storage problem, would remove my
most important grievances with this proposal. I don't mean to block this
proposal at all. Let us proceed.

Thank you for your time and your patience.

Cheers!
Arun