unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Insights for future development from the Guix Survey
@ 2025-01-24 12:52 Steve George
  2025-01-25  8:23 ` 45mg
  0 siblings, 1 reply; 11+ messages in thread
From: Steve George @ 2025-01-24 12:52 UTC (permalink / raw)
  To: guix-devel

Hi,

Part 1 [0] and Part 2 [1] of the Guix User and Contributor survey's results are out. These cover the user-focused parts of the survey, with the contributor part still to come. I think the results have some great insights for where Guix development should/could focus, hopefully it will spart some discussion at Guix Days! ;-)

Here's 5 insights from each one - adoption (post 1)

1. There are lots of new Guix users: almost 50% of respondants had been using Guix for less than 2 years! This could have implications for how we provide end-user documentation and the focus of tooling to assist new users.

2. Almost 50% of adopters start by using Guix as a GNU/Linux distribution, predominantly as a desktop. While a third start by using it as a hosted package manager on top of another distro. This could have implications for how the project prioritises packaging and testing.

3. Adopters struggle with (a) lack of how-to's and examples (rather than reference documentation), (b) Guile/Lisp syntax, and (c) differences in Guix's approach from other Linux distros.

4. Users who stopped using Guix focused on how the complexity of maintenance was too high, missing packages/services they needed and issues around drivers/proprietary software. There's really good comments in this section which bring up lots of ideas for future development!

5. Overall, 67% were satisfied with their initial adoption experience. This is great, and the survey shows lots of ways which could improve the how user's adopt Guix.


Some insights from general usage (post 2):

1. Using Guix as a graphical desktop is the most popular: 73% use it on laptop, workstation hardware. It's used in a server configuration by roughly a third of users. Many users start with the desktop configuration, and when they become familiar they expand to server usage.

2. Proprietary drivers are used by a majority of the participants. The lack of all drivers being included by default in Guix was a problem for about a third of users. This is a much-commented area within the survey and I know it will draw lots of attention - worth reading through the set of views and comments, whereever you stand on this area.

3. Overall satisfaction with Guix was good about 70%. There's also some clear limiters and the same themes come up. About 50% of participants would like to see better runtime performance (e.g. guix pull), there's challenges with needed packages/services and problems with error messages/debugging.

4. In general, both in the user survey and in the contributor section there was a lot of focus on making the latest version of packages available (package freshness) and more packages (more is better) with an outright rejection of a smaller/more-focused package set. There's lots of potential implications for where the project could automate and put energy across these areas.

5. I know that all sounds bad but it isn't! There's lots of positive love for Guix - the comments are wonderfully uplifting - great love for the friendliness and hard work of everyone involved in the project - worth reading!

Being a bit self-serving (it's been a lot of work) - I really encourage everyone to read through the posts and scan some of the comments. I hope it will give you ideas for topics to discuss at Guix Days, and areas you'd like to focus on. 

Here's the posts:

[0] https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/
[1] https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-2/


Steve / Futurile





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-24 12:52 Insights for future development from the Guix Survey Steve George
@ 2025-01-25  8:23 ` 45mg
  2025-01-26 12:42   ` Steve George
  0 siblings, 1 reply; 11+ messages in thread
From: 45mg @ 2025-01-25  8:23 UTC (permalink / raw)
  To: Steve George, guix-devel

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.

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.

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-25  8:23 ` 45mg
@ 2025-01-26 12:42   ` Steve George
  2025-01-26 14:09     ` jbranso
  0 siblings, 1 reply; 11+ messages in thread
From: Steve George @ 2025-01-26 12:42 UTC (permalink / raw)
  To: 45mg, guix-devel

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-26 12:42   ` Steve George
@ 2025-01-26 14:09     ` jbranso
  2025-01-26 16:10       ` indieterminacy
  2025-01-27 14:47       ` 45mg
  0 siblings, 2 replies; 11+ messages in thread
From: jbranso @ 2025-01-26 14:09 UTC (permalink / raw)
  To: Steve George, 45mg, guix-devel

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
>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-26 14:09     ` jbranso
@ 2025-01-26 16:10       ` indieterminacy
  2025-01-27 14:47       ` 45mg
  1 sibling, 0 replies; 11+ messages in thread
From: indieterminacy @ 2025-01-26 16:10 UTC (permalink / raw)
  To: jbranso; +Cc: Steve George, 45mg, guix-devel

On 2025-01-26 15:09, jbranso@dismail.de wrote:
> 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:

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-26 14:09     ` jbranso
  2025-01-26 16:10       ` indieterminacy
@ 2025-01-27 14:47       ` 45mg
  2025-01-27 17:35         ` Suhail Singh
  1 sibling, 1 reply; 11+ messages in thread
From: 45mg @ 2025-01-27 14:47 UTC (permalink / raw)
  To: jbranso, Steve George, 45mg, guix-devel

Hi jbranso,

jbranso@dismail.de writes:

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

I recently conducted a small survey on guix-devel, to get people's
opinions on sending pings to neglected patches:

https://lists.gnu.org/r/guix-devel/2025-01/msg00209.html

Of note here, there was a fair amount of interest in having a dedicated
place to send pings (eg. a separate thread or mailing-list).

I'm thinking this could help collect unreviewed work in one place so
that everyone who wants to can see it. Additionally, the fact that
someone has submitted a patch to such a thread/list would signify that
they're still ready to respond to review, send new versions, etc., which
is often not clear with patches that have simply gone silent after
months.

For an example of this, NixOS has monthly 'PRs ready for review' threads
on their Discourse, where people can post theirs:

https://discourse.nixos.org/t/prs-ready-for-review-december/1711


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-27 14:47       ` 45mg
@ 2025-01-27 17:35         ` Suhail Singh
  2025-01-28  0:44           ` jbranso
  0 siblings, 1 reply; 11+ messages in thread
From: Suhail Singh @ 2025-01-27 17:35 UTC (permalink / raw)
  To: 45mg; +Cc: jbranso, Steve George, guix-devel

45mg <45mg.writes@gmail.com> writes:

> I'm thinking this could help collect unreviewed work in one place so
> that everyone who wants to can see it.

For your situational awareness, note that one such place already exists
to an extent today.  The usertag "patch-review-hackers-list" has been
used by some to get some attention to existing issues awaiting review.

I'm not arguing against having another mechanism (in its stead) to
denote items in need of review, I'm merely advocating that we consider
any such mechanism in relation to the current options today.

-- 
Suhail


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-27 17:35         ` Suhail Singh
@ 2025-01-28  0:44           ` jbranso
  2025-01-28  5:02             ` Suhail Singh
  0 siblings, 1 reply; 11+ messages in thread
From: jbranso @ 2025-01-28  0:44 UTC (permalink / raw)
  To: Suhail Singh, 45mg; +Cc: Steve George, guix-devel

January 27, 2025 at 12:35 PM, "Suhail Singh" <suhailsingh247@gmail.com mailto:suhailsingh247@gmail.com?to=%22Suhail%20Singh%22%20%3Csuhailsingh247%40gmail.com%3E > wrote:



> 
> 45mg <45mg.writes@gmail.com> writes:
> 
> > 
> > I'm thinking this could help collect unreviewed work in one place so
> >  that everyone who wants to can see it.
> > 
> For your situational awareness, note that one such place already exists
> to an extent today. The usertag "patch-review-hackers-list" has been
> used by some to get some attention to existing issues awaiting review.

What is "patch-review-hackers-list" ?  Can you send me some documentation
on how to use it?

> 
> I'm not arguing against having another mechanism (in its stead) to
> denote items in need of review, I'm merely advocating that we consider
> any such mechanism in relation to the current options today.
> 
> -- 
> Suhail
>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-28  0:44           ` jbranso
@ 2025-01-28  5:02             ` Suhail Singh
  2025-01-28  8:48               ` Steve George
  0 siblings, 1 reply; 11+ messages in thread
From: Suhail Singh @ 2025-01-28  5:02 UTC (permalink / raw)
  To: jbranso; +Cc: Suhail Singh, 45mg, Steve George, guix-devel

jbranso@dismail.de writes:

> What is "patch-review-hackers-list" ?  Can you send me some documentation
> on how to use it?

It's one of a few tags that the london guix meetup has used in the past.
See <https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024>
for details, including other related usertags such as
escalated-review-request.

In terms of how to review the list of packages with a given usertag,
debbugs.el in Emacs provides M-x debbugs-gnu-usertags.

-- 
Suhail


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-28  5:02             ` Suhail Singh
@ 2025-01-28  8:48               ` Steve George
  2025-01-28 13:45                 ` jbranso
  0 siblings, 1 reply; 11+ messages in thread
From: Steve George @ 2025-01-28  8:48 UTC (permalink / raw)
  To: jbranso; +Cc: 45mg, guix-devel, Suhail Singh

Hi,

At 'Guix Social' we've been trying to do regular patch review sessions, 
along with the talks and socialising. Thanks the link that Suhail gave you.

Debbugs has a system called 'usertags', we set some standardised ones 
and I normally ask around on the mailing lists/IRC for people to tag 
"easy bugs" that the group can review.

You are also very welcome to review some issues yourself - and the Wiki 
page provides a process for doing that - it helps a lot!

Steve / Futile


On 28/01/2025 05:02, Suhail Singh wrote:
> jbranso@dismail.de writes:
> 
>> What is "patch-review-hackers-list" ?  Can you send me some documentation
>> on how to use it?
> 
> It's one of a few tags that the london guix meetup has used in the past.
> See <https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024>
> for details, including other related usertags such as
> escalated-review-request.
> 
> In terms of how to review the list of packages with a given usertag,
> debbugs.el in Emacs provides M-x debbugs-gnu-usertags.
> 



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Insights for future development from the Guix Survey
  2025-01-28  8:48               ` Steve George
@ 2025-01-28 13:45                 ` jbranso
  0 siblings, 0 replies; 11+ messages in thread
From: jbranso @ 2025-01-28 13:45 UTC (permalink / raw)
  To: Steve George; +Cc: 45mg, guix-devel, Suhail Singh

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



> 
> Hi,
> 
> At 'Guix Social' we've been trying to do regular patch review sessions, along with the talks and socialising. Thanks the link that Suhail gave you.
> 
> Debbugs has a system called 'usertags', we set some standardised ones and I normally ask around on the mailing lists/IRC for people to tag "easy bugs" that the group can review.
> 
> You are also very welcome to review some issues yourself - and the Wiki page provides a process for doing that - it helps a lot!

Thanks for the invitation!  I am one of those people that has 
temporarily stepped away from guix and guix system.  When I come
back to guix, I should take a look!

I essentially had some upgrade issues that I could not resolve with guix system.
I tried following my own tutorial from my blog to build guix from source, but 
that failed too.

https://gnucode.me/guix-deploy-failed-to-update-my-guix-server.html

I think my /gnu/store/ got corrupted, and that caused some issues.  But
I have no idea really.

Anyway, I'm playing in OpenBSD land now, and maybe I have fallen for their
marketing, but I really like the idea of their secure and correct philosophy.

https://gnucode.me/openbsds-philosophy.html

I still can't configure my speaker's to play well on OpenBSD, and I miss
guix's declarative configuration.  A LOT!

 
> Steve / Futile
> 
> On 28/01/2025 05:02, Suhail Singh wrote:
> 
> > 
> > jbranso@dismail.de mailto:jbranso@dismail.de  writes:
> >  What is "patch-review-hackers-list" ? Can you send me some documentation
> > 
> > > 
> > > on how to use it?
> > > 
> >  It's one of a few tags that the london guix meetup has used in the past.
> >  See <https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024> https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024%3E 
> >  for details, including other related usertags such as
> >  escalated-review-request.
> >  In terms of how to review the list of packages with a given usertag,
> >  debbugs.el in Emacs provides M-x debbugs-gnu-usertags.
> >
>


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2025-01-28 13:45 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-24 12:52 Insights for future development from the Guix Survey Steve George
2025-01-25  8:23 ` 45mg
2025-01-26 12:42   ` Steve George
2025-01-26 14:09     ` jbranso
2025-01-26 16:10       ` indieterminacy
2025-01-27 14:47       ` 45mg
2025-01-27 17:35         ` Suhail Singh
2025-01-28  0:44           ` jbranso
2025-01-28  5:02             ` Suhail Singh
2025-01-28  8:48               ` Steve George
2025-01-28 13:45                 ` jbranso

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).