[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
- Insights for future development from the Guix Survey, Steve George, 2025/01/24
- Re: Insights for future development from the Guix Survey, 45mg, 2025/01/25
- Re: Insights for future development from the Guix Survey,
Steve George <=
- Re: Insights for future development from the Guix Survey, jbranso, 2025/01/26
- Re: Insights for future development from the Guix Survey, indieterminacy, 2025/01/26
- Re: Insights for future development from the Guix Survey, 45mg, 2025/01/27
- Re: Insights for future development from the Guix Survey, Suhail Singh, 2025/01/27
- Re: Insights for future development from the Guix Survey, jbranso, 2025/01/27
- Re: Insights for future development from the Guix Survey, Suhail Singh, 2025/01/28
- Re: Insights for future development from the Guix Survey, Steve George, 2025/01/28
- Re: Insights for future development from the Guix Survey, jbranso, 2025/01/28