Re: Insights for future development from the Guix Survey

[jbranso]

January 26, 2025 at 7:42 AM, "Steve George" <steve@futurile.net 
mailto:steve@futurile.net?to=%22Steve%20George%22%20%3Csteve%40futurile.net%3E 
> wrote:



> 
> 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?

Perhaps we could write a blog post? To highlight some of those things?
Maybe we can encourage someone to look at those various patches, or
at least have a record of cool patches that need review.
Something like:

Merging Guix's unfixed patches

Guix is a significant free software project, and it has lots of really
cool featured that are almost done.  Perhaps you would like to help us
get these accross the finish line?

- support for testing php packages:  https://issues.guix.gnu.org/67902
- opensmtpd-service-type  (my fault it's not finished) 
https://issues.guix.gnu.org/56046
- new bootloader code that is not grub-specific  
https://issues.guix.gnu.org/72457
- package phosh ( https://issues.guix.gnu.org/44400 )

blah blah blah

If a blog post is a bad idea, then maybe we could add those cool patches
to the TODO.org file?

> > 
> > 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
>