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
- Should we add another maintainer?
- Group here agrees
- Dev experience work needed too
- 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
- Keeping stability is important
- Would a forge make it easier to participate in the contribution
process?
- "The GNU/FSF thing"
- Should we go along with some of the decisions that Guix makes wrt
forge/gnu?
- Existing contributors should be empowered more
- Rob Browning specifically should feel more empowered to make commits
without direct approval from Ludovic/Andy
- Rules about API/ABI changes are institutional knowledge that aren't
written down anywhere
- Guile feels more difficult to contribute to than Guix
- 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
- 2 experienced maintainers + 1 new maintainer seems good to Andy
- Where is Guile headed? Can maintainers set direction?
- 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?
- 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
- 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.
- 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
- Would be nice to have a Guile roadmap
- Hacking on Guile feels intimidating
- 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
- 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)
- Action items:
- We need to empower more contributors
- Maybe bringing on a new 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
- Teams for subsets of Guile codebase?
- Project plan
- More onboarding resources (talk recordings on website, "try it
now" REPL in browser, etc.)
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.)
- Dave
