On 2025-01-26 15:09, jbra...@dismail.de wrote:
January 26, 2025 at 7:42 AM, "Steve George" <st...@futurile.net
mailto:st...@futurile.net?to=%22Steve%20George%22%20%3Csteve%40futurile.net%3E
> wrote:
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?
One of the reasons Ive been trying to prioritise learing/mastering
Prolog is that I expect it will be very useful at aligning a users
interests with what general improvements need to be made wrt Guix
packaging and infrastructure.
For instance, a desire for having a more uptodate FOO tool may emphasize
certain patches to consider first.
>
> 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.
I feel that theres an irony in package definitions resolving errors.
When somebody experiences a package definition that needs tweaking there
needs to be the response from the system of:
'this tool experienced this similar issue. Here is its approach to
solving it'
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
Kind regards,
Jonathan
