guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Insights for future development from the Guix Survey


From: Steve George
Subject: Re: Insights for future development from the Guix Survey
Date: Sun, 26 Jan 2025 12:42:11 +0000
User-agent: Mozilla Thunderbird

Hi 45mg,

Thanks for adding your thoughts!

On 25/01/2025 08:23, 45mg wrote:
Hi Steve!

First of all, thank you for all your hard work over these past months.

I guess this is as good a place as any for a general discussion thread.

For starters, I noticed that lack of support for LUKS + unencrypted
/boot was brought up multiple times. I wanted to note that there is
already an open patch series for this: [1], and it hasn't recieved
review in 4 months. I'm not sure where exactly it stands in the context
of the pending bootloader rewrite [2] (which, again, seems to have
stalled for lack of review/testing), but it might be worth looking into.
(...)

In general, the current work-flow and ethos within the team seems to favour incremental changes. Perhaps it's due to being volunteer-driven but I've seen multiple big patch-sets get to about 90% and then never make it over the line.

The number one reason for this, is the problem of a constrained contribution review process. I guess 'big' series will be deprioritised if it's not the reviewers specialist area.

Big changes need a group to work together, we have 'teams' (bit nascent) - but maybe we need some other way to highlight big changes and rally people together?

Then there's the frequent 'poor error messages' complaint. While I can
think of some significant improvements that could be made on the Guix
side (fix `guix repl` [3], maybe get `guix {home,system}` to print
errors in loaded modules [4]), I think the limiting factor here is
always going to be Guile itself: see [5], [6], etc.

(...)

Issues around the development experience being slow and that error messages and debugging are difficult come up high on contributor's concerns.

Guile is a small community, where possible we should leverage other communities tools/approach imho. I think Arei-rs [0] is a great example of that - as it's editor independent and is proven in the Clojure community - maybe there are other opportunities. Anything where a small group gets distracted into writing it's own tooling from first principles seems bad - probably fun, but not productive.


Looking forward to further discussion of the survey results! We're all
awaiting part 3, but there's enough to talk about already :)


[1] https://issues.guix.gnu.org/68524
[2] https://issues.guix.gnu.org/72457
[3] https://issues.guix.gnu.org/68895
[4] https://issues.guix.gnu.org/75822
[5] https://lists.gnu.org/archive/html/guile-user/2020-03/msg00051.html
[6] https://lists.gnu.org/r/guix-devel/2022-11/msg00283.html

[0] https://git.sr.ht/~abcdw/emacs-arei



reply via email to

[Prev in Thread] Current Thread [Next in Thread]