Hi
On 2025-06-16 14:49, Thompson, David wrote:
Hi Ekaitz,
This discussion has reminded me that I have a bunch of hastily typed
notes from Guix Days about this very topic! The notes touch upon a
number of things brought up in this thread.
- Current situation is that Ludovic and Andy are maintainers
- Ludovic doesn't have much time
- Andy is focused on compiler engineering
- What we don't have is someone that can focus on patch review
- We don't have someone stewarding new contributors
- Patches waiting a year or more for review
- Like the Windows JIT patches
Mostly what I detected and shared in my previous email. Good.
- Should we add another maintainer?
- Group here agrees
Now the question here is: who?
- Dev experience work needed too
This is important. Very.
- Andy doesn't have the time he used to
- "I'm not going to change" lol
- Want to give people feeling of ownership and power to do things
- Andy doesn't want to decide things in a top-down way
This is key, but we need him to take action in a couple of things he
only can do. For example: I could try to get involved in the JIT as a
commiter-maintainer if needed, but the lightening should be hosted in
the same place Guile is (whatever that is, a forge or not), and we need
him to give people access.
- Keeping stability is important
Not only important. It's in my opinion mandatory.
Now, the knowledge is too concentrated in Andy, and we should manage to
distribute it better so others can ensure this stability.
- Would a forge make it easier to participate in the contribution
process?
That could be, not only for contribution but specially for tracking bugs
and reverting the current situation.
- Existing contributors should be empowered more
- Rob Browning specifically should feel more empowered to make commits
without direct approval from Ludovic/Andy
YES. YES. YES.
- Rules about API/ABI changes are institutional knowledge that aren't
written down anywhere
Problem -> it requires that those who have the knowledge share it. Or
write those things down. We already stated they don't have the time for
that.
Now, what?
- Guile feels more difficult to contribute to than Guix
This we can change. The Guile standard library is as simple to work on
as Guix (maybe even easier!).
The JIT is very simple (air quoting here a little), too.
This perception we could change. I have a plan for this.
- Ludovic thinks we could get more people to take care of simpler
things like POSIX (is that simple? lol) and the web client
- Easier to submit things that could be useful to Guile to Guix
instead; edit distance algorithm given as example
- Ludovic felt like an imposter at the time a previous maintainer made
him a maintainer
If he did, of course the rest of us could feel the same. We can work our
way sharing that experience, and telling people that's ok. We could try
to mentor them through the process.
- 2 experienced maintainers + 1 new maintainer seems good to Andy
This feels great. But it's Guile community who should choose, someone
needs to raise their hand, and so on. This I think is the most important
step, but it doesn't directly depend on us. The current maintainers need
to do something else than just giving the ok. It requires action from
their side.
- Where is Guile headed? Can maintainers set direction?
At this very moment it is stuck, imho.
- Missing persistent data structures, strong consensus on priority to
get those
- There was a pressure on Guile to get things into core
- Guile lacking a nice build system for Guile-only code (no C)
- Andy says pretty much every time something gets brought into Guile
core it's been a win
- Cites the (web ...) modules
- Seems to be agreement that more deprecation needs to happen and
default (guile) module needs to be reduced in size
- A bit of a divide between those that value standard Scheme and those
that value Guile-specific APIs
- Hash langs as path for legacy Guile compatibility?
- Could we capture some of the Racket use cases to encourage adoption?
Some of these are debates that we should tackle after there's some
effective leadership and contributor base. At this very moment, I think
it's not feasible to tackle them. But the points are super interesting.
And some others can be done in parallel if a brave developer wants to
(!) but taking in account that the changes may take long until merged.
- Andy wants to merge the interesting parts of Hoot into Guile at some
point
- Whole-program compilation in Guile itself for Guile bytecode,
similar to Hoot
- Running a REPL on Hoot is a challenge, but seems solvable (Spritely
will be working on this)
- Wasm emitting toolchain, CPS to Wasm, could be useful for Guile and
should be merged upstream
- Andy thinks it's dangerous to have the entire Hoot compiler outside
of Guile; too much risk
- Spritely agrees, of course
"Andy doesn't want to decide things in a top-down way", but in practice
Guile feels like his own scheme implementation where he decides, invents
and implements. It's great, because he is a great programmer, but also
kind of dangerous.
- LGPL complicates whole-program compilation
- Andy would like single-binary output for Guile bytecode linked with
libguile.a + minigmp + etc. (I agree)
- Ludovic is interested in whole-program compilation for initial RAM
disks, etc.
Interesting.
- Fundraising????
- More people are using Guix for their day job, can they pitch in
for funding?
- Spritely, NLnet, and Igalia are paying Andy for some Guile
development
I'm working on GNU Mes right now thanks to NLnet, and we could try to
push some of that if we have a...
- Would be nice to have a Guile roadmap
... roadmap.
- Hacking on Guile feels intimidating
Already discussed. We could manage. I think I can manage.
- The Scheme procedures implemented in C, legacy code, are confusing
newcomers now
- Things should be moving C to Scheme, especially things that call
back into Scheme due to how stack capture works for continuations
Someone with skills could rewrite these things but carefully, because we
shouldn't break any of the rules we don't have written anywhere :)
- Better backtraces desired, underscores are confusing (variables that
have been optimized out, space that has been reused)
- Andy: "So you're saying you want a worse compiler" (half-joking)
Yes. Or at least I think we'd like to have an obvious way and very well
explained to choose how good the compiler is.
Debugging should also be improved.
Geiser shouldn't be the only way to work in Guile: I am aware that some
people is working on that.
- Action items:
Who should take the action? Let's take a look:
- We need to empower more contributors
People with the knowledge and the status in the community could do this.
- Maybe bringing on a new maintainer
This only maintainers could do (+ the person that wants to become the
maintainer).
- Guile should use Guix as a guide for the issues of debbugs
vs. forge and the GNU issue (update: Guix is now on Codeberg, time
for Guile to make the switch?)
- Maintainer for the forge migration
Maintainer again?
- Teams for subsets of Guile codebase?
I don't think we need that, Guile is not that huge project.
But we already have some of that: the JIT is in a separate project.
- Project plan
Maintainers again?
- More onboarding resources (talk recordings on website, "try it
now" REPL in browser, etc.)
This we can all do, independently. Providing resources in our own and
then we could gradually add them to the Guile website.
This is good. I like this. This would also help with the impression
people has about the difficulty.
Personally, I think a move to Codeberg + a new maintainer + some newly
empowered committers would go a long way, with Andy/Ludovic helping to
set high-level project direction (replacing C with Scheme,
deprecations, cleaning up default namespace, etc.)
I agree in most of it, but it requires the current maintainers attention
and I'm not sure how much we could rely on it.
What we could do is make them a promise that after a short time that
requires their effort, they will be relieved or future effort.
About Ludovic, I think his voice is important both in Guix and Guile
regardless if he wants to be a maintainer or not, and actually being a
maintainer makes that obvious. In Guix it's a little bit easier to know
his voice is important because he is the author of Guix, but in Guile,
if he steps down, that wouldn't be that obvious. I wouldn't like that to
happen. I would prefer if he stays (ofc it's his decision) even if he
doesn't take active part that often, because his experience in other
projects that require Guile and Guile itself is really valuable.
Maybe the same with Andy. His knowledge and opinion are very valuable,
but maybe he prefers to step down from those tasks he doesn't like that
much. I'd prefer he stays, too.
But if they stay in an advisor role, maybe just one extra maintainer
won't be enough if the committer base is not large.
- Dave
Thanks for sharing the notes.
I'm very glad that most of us agree in the core. I think people like
yourself are doing a lot to make Guile better. Thank you for that, too.
Best,
Ekaitz
