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