Hi,

We mostly agree with everything so let me focus on the points I were I'd like to add more.

Thanks for adding your thoughts, they are really valuable.

On 2024-10-25 14:58, Thompson, David wrote:

I'd like to use this opportunity to say that the Guix project needs to
stop relying upon email for *everything*. Whom amongst us doesn't have
an overflowing inbox where they lose track of things? The email-based
patch review workflow is particularly terrible. Newcomers by-and-large
*do not* want to figure out how to send a patch over email and the
review process is extremely clunky compared to literally any Git forge
with a pull request feature. And I dare say it's inconvenient for
experienced Guix contributors, too. It drives me bonkers. The mumi
interface to debbugs makes things better, but Guix desperately needs
to leave debbugs and Savannah behind for a forge from this millenium.

I don't think this is the most important part of the problem, but it's really hard to measure.

I think the level of technical proficiency a project like Guix demands is high enough to ensure that people who take part on it are able to use the email for their goals. It is weird for them, but I think that's something they can get over. (we could also discuss about English being a problem for most of the world, and here I am, talking in my third language)

In most cases I saw, just some help via IRC or email makes people send their first patch and feel really accomplished. (This mentoring needs people and time to invest)

The main problem I think comes later, when the contributor made all the effort to send the email and then no one answers back. If the first effort didn't kill the process, the lack of response murders any possible future contribution.


I don't want to focus the conversation on this part, the forge vs email (maybe there's a way to support both). What we should discuss is the fact that is topic is really hard to discuss or make it to something we can apply. Things take too much time because, in practice, I don't think we have a governance model.

Is the Guix Foundation (https://foundation.guix.info/) the official
non-profit for Guix? In addition to finding grants and large donors...
is there an easy way for Guix to collect donations from individual
supporters? The Guix Foundation website says they accept wire transfer
and in-person donation at events. That's cool but there needs to be a
donate button on the Guix website that makes it very easy to donate
with a credit card.

A big part of this email is to try to be more clear about this. I think Guix Foundation is too separate from Guix, or the relation is not clear. How does the FSF take part in the funding? Is the Guix Foundation competing with it somehow or they collaborate or...?

It should be easier to access and donate to from Guix's own website.

Maybe also to accept large donations from the companies or organizations that need Guix to work well. I'm sure there has to be some.

I heard some speculation that the number of new contributors is on the
decline? Is this true? I think this partly a funding/governance issue
and partly a tools issue, as mentioned above. It is simply *too
difficult* to submit a patch to Guix and it is *too annoying* to do
code review through email.

I think solving the governance issue would enable further action later.

The biggest questions for me are: Who makes decisions right now? Who
is handling money? What's the overlap? I know there's a desire for
collective decision making, which is great, but *right now* I think a
smaller group of core people (Ludovic + some others) needs to put a
structure in place because it feels like nothing will happen
otherwise. A little bit of benevolent dictatorish action could really
get the ball rolling here.

Exactly. It's a really tricky situation. I think we all look to Ludovic when something needs to happen. And I don't think he (hi!) needs to feel that kind of pressure.


Ludovic recently said
the next step is to get an RFC process in place. Sure... who makes the
call on that?

I think Steve is working on it on top of what Simon did, and I'm happy to collaborate on that.

Definitely best for another thread, but I'll just say: I don't think
Guile has been left to rot, but things have been moving too slowly and
Andy/Ludovic are spread too thin. The Guile 3.0.10 release happened
because Spritely paid for it in the form of Andy's contractor hours so
he'd have the time to focus on it. I have told both Andy and Ludovic
that I think Guile could use at least 1 additional maintainer that is
focused on, ahem, "developer experience". Keeping up with the patch
queue, improving documentation, ease of use, etc. I'll save further
comments for a guile-devel thread, should you make one. :)

I will, but I'll send it with guix-devel included, because I think that as connected as both are, we should blur the line totally and take more part on Guile.

Your thoughts here David are a little bit biased to your position, where you have some of Andy's attention (you paid for it, this is also relevant to the topic of the email). Mine are biased to the other direction: in the last 3 years I had a little attention (or none) from Guile's side.

I ported lightening (guile's JIT, a project that is managed by Andy, separately) to RISC-V but I have trouble fixing a segfault it has. I pass all the tests but in the last 3 years I had no help with that segfault, and I didn't see any effort to review my changes. I'm sure with a little bit of help I we could make it work, as all the boring part is done. But here we are, still, years later.

I'm not blaming people, but this is very discouraging.

I'll open the thread. Let's see if with help we can do guile thrive as it deserves.

Thanks for getting the conversation started!

Thank you for your thoughts.


Reply via email to