unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: Guix Documentation Meetup
@ 2021-12-10 22:40 Blake Shaw
  2021-12-10 23:18 ` Ryan Prior
                   ` (3 more replies)
  0 siblings, 4 replies; 51+ messages in thread
From: Blake Shaw @ 2021-12-10 22:40 UTC (permalink / raw)
  To: jgart; +Cc: Guix Devel


hiya guix,

@cybersyn from IRC here, I recently contributed my first package, [notcurses]

--
tldr: is there also room to discuss contributing -- and possibly doing a
sizeable makeover to -- the *Guile* documentation? If so, I could give a
short 5 - 10 minutes presentation of what I think should be done (and
would volunteer to do).
--

I think I can personally offer a lot in terms of contributing to
documentation. While I don't serious experience w/technical writing,
prior to the pandemic I was doing my PhD in philosophy of mathematics,
so I come from a cross-disciplinary background that involves the often
difficult area of communicating new, formal ideas to previously
unexposed readers. I've also made a living as a new media artist since
2009, working mostly in C and C++ based frameworks, so I also have some
knowledge of the difficulties "crafters" have when learning new
development systems.

I don't know if this is the correct forum for it, but I personally think
the biggest documentation obstacle in Guix at the moment isn't so much
in Guix, but instead in Guile. I found Guix via SICP & Racket about a
year ago, and I remained a happy Racket hacker until a couple months ago
when I decided to devote my free time to learning Guile in hopes of
graduating to a Guix sensei one day.

While I've come to love Guile, compared to my experience with Racket its
been quite burdensome for me to get in the hang of, something I attribute
primarily to the structure of the docs, and not due to it being in any
way more difficult than Racket. While with Racket I was writing
useful programs in the standard #lang within my first week, with Guile
I often find that what should be almost trivial winds up with a lot of
time lost just trying to navigate and understand the docs. When I do
figure things out, it turns out to be no more difficult than the equivalent
in Racket, but a lack of consistency in the path that leads there in the
docs cause hangups, which has made trivial scripts that should take an hour
become weekend projects.

I know this isn't the Guile list, but when I've written on this topic in
the IRC I've had no response, which make me think docs could be a
bit of a bikeshedding topic in the community. But as Guile is
fundamental to Guix and theres a lot of crossover btwn the communities,
it seems like this could be a good time to raise these suggestions.

I've jotted down some notes on several concrete examples of where the docs
diverge from stylistic consistency, as well as some light analysis as to
why such seemingly small inconsistencies can lead to such hangups in the learning
process. If folks would be interested in me presenting a short 5-10min
presentation of these notes, I'd be happy to share.

Sorry for such a long-winded message! Personally, good documentation is
absolutely essential, and I feel like I could give Guile's docs a
serious makeover while I'm still at the early stage of my plunge and
have a perspective on the psychology of not-understanding -- something
that won't last long!

ez,
blake

-- 
“In girum imus nocte et consumimur igni”


^ permalink raw reply	[flat|nested] 51+ messages in thread
* Guix Documentation Meetup
@ 2022-03-10 17:02 Raghav Gururajan
  2022-03-10 17:11 ` Raghav Gururajan
  0 siblings, 1 reply; 51+ messages in thread
From: Raghav Gururajan @ 2022-03-10 17:02 UTC (permalink / raw)
  To: guix-devel; +Cc: jgart


[-- Attachment #1.1: Type: text/plain, Size: 588 bytes --]

Hello Guix!

WhereIsEveryone community is hosting a meetup regarding documentation in 
Guix.

We'll be discussing and/or working on; adding new contents, removing 
obsolete contents and improving contents where required. We can also 
look into current documentation style/model and generate 
feedback/suggestions. The documentation can pertain to manual or 
cookbook or prospective wiki. The outcome of the meetup will be 
recorded, organized and sent to Guix upstream.

DATE: Saturday, March 19, 2022.
TIME: 15:00 UTC
Duration: ~1.5hrs

Regards,
Raghav "RG" Gururajan.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

^ permalink raw reply	[flat|nested] 51+ messages in thread
[parent not found: <mailman.34870.1641617883.18145.guix-devel@gnu.org>]
* Re: Guix Documentation Meetup
@ 2022-01-08  4:52 Matt
  2022-01-10  9:47 ` Oliver Propst
  0 siblings, 1 reply; 51+ messages in thread
From: Matt @ 2022-01-08  4:52 UTC (permalink / raw)
  To: jgart; +Cc: guix-devel

I want to be a part of this.  I feel like I've been rubbing two sticks together while it seems some people out there have Zippo lighters. A real-time conversation, some paired programming, or simply looking over the shoulder of someone who knows what they're doing would go a long way.  I have been trying to learn and share by way of case studies: www.excalamus.com.  My hope is that these could one day be adapted for the manual, or at least prep me for making meaningful contributions to the official documentation.  I have several more studies that are unpublished.

I share many of the same challenges others have experienced, certainly with Guile.

These are things I'm interested in helping with:

* defining terms

  A glossary, improved indexing (which is there), and more references (also present), are things I want to help with.

  For example, I've spent the past few days' free time trying to understand how to install an old version of ungoogled-chromium, required for Jitsi. To do this required 1) knowing what a profile is and 2) knowing the syntax of "sourcing".  First, a profile is mentioned in passing several times in the manual as a directory. Yet, the guix package --profile option requires a *file* be specified.  (yes, a directory is a file, but guix complains if you pass a directory). So, is a profile a file or a directory? After much poking around, I found that the file specified by the --profile option is a symlink. This symlink points to another symlink (specifying the generation?), which in turn appears to point to the directory of packages . So, a profile *is* a directory, but, depending on how you look at it, it may be a file. Second, to activate the profile requires "sourcing" $GUIX_PROFILE/etc/profile (again, is a profile a file or a directory?). Some parts of the documentation give this as:

            GUIX_PROFILE="$HOME/.guix-profile" . "$GUIX_PROFILE/etc/profile"

  Nevermind having to look up what was meant by "sourcing", I did that. But it turns out that there are two syntaxes for it: the one above and the more clear `source "$GUIX_PROFILE/etc/profile"`. Of course, with my luck, that wasn't made clear with the resources I found. It took me far too long to see how what I found on the open web corresponded to the manual.

* meaning/consequences/significance

  Knowing words without understanding the consequences of their meaning is just memorizing jargon. A profile is a directory? So what? Is that significant or just trivia? I still don't know.  Sometimes I think I'm reading about the Turbo Encabulator (https://www.youtube.com/watch?v=Ac7G7xOG2Ag)

* context/workflows

  I want to help show what it means for Guix to be imperative and declarative.  Each has a different workflow, it seems, and the manual mixes those together. The context isn't always clear.

  Guix is flexible.  It can be complicated, but isn't by necessity.  I've been able to get by for nearly a year doing, more or less, guix pull, guix package -u, and occasionally guix system reconfigure (with a few guix installs thrown in :) Almost all the complex stuff has been from my choice to learn and do more.

  The simple daily workflows aren't apparent to me from the documentation. I don't need to code a config or define packages or set up channels or profiles or do any of that unless I want to? It took a bit of reading for me to realize, that's it?  I think there's a big focus on what can be done with Guix and not much said about the boring routine stuff. As a new user (even as a somewhat less new user), that's what I need first: I need security that my system will work, not crash or destroy my data and not consume my life *unless I choose for it to*. Isn't that really what Guix has to offer? Show me.

* navigation/discoverablity

  Guix is described as "the Emacs of distros".  To me Emacs, besides embodying freedom, means self-documenting. I wouldn't be a professional programmer without Emacs. It nurtures me by answering questions, giving examples, and scaffolding learning.  Emacs expands the zone of proximal development (https://en.wikipedia.org/wiki/Zone_of_proximal_development) and ensures I can achieve what I couldn't before.

  Guix is poised to do the same. However, the documentation and my difficulty navigating it is a huge problem for me.

  Others have touched on it when talking about Guile.

  - Is this symbol from Guile or Guix?
  - What does it do?
  - How is it used?
  - How many steps are required for someone to answer these questions?
    (answer: not one like, C-h f. Instead, it might be days searching the mailing list, getting familiar with IRC, and being lucky with timing and and experimenting)
  - Geiser seems great. How the f*** does it help me answer these
    questions? Wait, what problem am I trying to solve again?

  I love the info system.  Google has nothing on the info reader.  Yet even the info system's ability to overcome the documentation trilemma is strained.

  The documentation trilemma is:

    Intelligible, comprehensive, and discoverable: Pick two.

  I feel Guix does pretty well on being comprehensive. And, despite some rough spots, it's largely intelligible.

  Guix fails for me on discoverablity.  Can I quickly find the answer to my question *and know that I've found it?* That's why I think defining terms, focusing on their significance, and providing context through workflows can help.

  Discoverablity is also a technical problem.  I want a C-h f for Guix. That's something I think Guix and it's community is well positioned to solve, what with all these reproducible environments, Emacs users, and what not.  I'd love to help that come to fruition.

I can write and publish all day on my blog, but if it's not discoverable and, more importantly, not correct, it's not helping anyone.  I, and people like me, need help from experts.  That's why I'm so excited about this meet up.  I know I can string some words together enough to be understandable.  But is what I'm saying helpful?

One final question:

  How might announcements of the "Guix Documentation Meetup" (and "Guix Packaging Meetup)" be made more prominent?

I check the mailing list from time to time, but missed the announcements because they were buried.  Maybe meetings could be announced on info-guix?  If they become regular, maybe put them on https://guix.gnu.org/en/contribute/?  FWIW, I'm willing to be present so that a documentation meetup could run monthly. I'm an FSF member and could use the FSF Jitsi service if I needed to host it.  I've not used Big Blue Button before.

Sometimes I wonder why I'm choosing to struggle to learn Guix.  The reason I choose to persevere is that Guix could be like Emacs, software for a lifetime.  That's something I'm willing to invest in.



^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: Guix Documentation Meetup
@ 2021-12-13 13:45 Blake Shaw
  2021-12-13 15:55 ` Katherine Cox-Buday
  0 siblings, 1 reply; 51+ messages in thread
From: Blake Shaw @ 2021-12-13 13:45 UTC (permalink / raw)
  To: Katherine Cox-Buday; +Cc: Guix Devel

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

Katherine, reading a big deeper into your user experience report,
its really so so helpful to have this concrete sort of step-by-step
user experience report. Would you mind if I solicit the list
for more reports like this for anyone who might feel like offering them?
And would you mind if I cite this in the presentation I'm gathering?

-- 
“In girum imus nocte et consumimur igni”


^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: Guix Documentation Meetup
@ 2021-12-13 12:41 Blake Shaw
  0 siblings, 0 replies; 51+ messages in thread
From: Blake Shaw @ 2021-12-13 12:41 UTC (permalink / raw)
  To: Katherine Cox-Buday; +Cc: Guix Devel

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

Katherine this is great material to chew on, much of which I can relate
to!  

-- 
“In girum imus nocte et consumimur igni”


^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: Guix Documentation Meetup
@ 2021-12-13 12:33 Blake Shaw
  2021-12-15 17:37 ` Blake Shaw
  0 siblings, 1 reply; 51+ messages in thread
From: Blake Shaw @ 2021-12-13 12:33 UTC (permalink / raw)
  To: zimoun; +Cc: jgart, Guix Devel

zimoun <zimon.toutoune@gmail.com> writes:

Hi Simon, thanks for the input,
> Hi,
>
> On Sat, 11 Dec 2021 at 05:40, Blake Shaw <blake@nonconstructivism.com>
> wrote:
>
>> --
>> tldr: is there also room to discuss contributing -- and possibly
>> doing a
>> sizeable makeover to -- the *Guile* documentation? If so, I could
>> give a
>> short 5 - 10 minutes presentation of what I think should be done (and
>> would volunteer to do).
>> --
>
> Cool!
>
> Minor comments trying to feed this worth proposal.
>
>> I don't know if this is the correct forum for it, but I personally
>> think
>> the biggest documentation obstacle in Guix at the moment isn't so much
>> in Guix, but instead in Guile. I found Guix via SICP & Racket about a
>> year ago, and I remained a happy Racket hacker until a couple months
>> ago
>> when I decided to devote my free time to learning Guile in hopes of
>> graduating to a Guix sensei one day.
>
> I agree that the learning path in Guile land is not always smooth.
> However, I do not think mastering Guile and/or its specificity is a
> requirement to be a “Guix sensei”.  Obviously, better Guile
> documentation improves the ecosystem, then it is an overall better. :-)

I mostly agree, and I used Guix for probably half a year before recently
deciding to dive into Guile seriously. But I still won't be able to,
say, write a `guix import` for a different package manager without
needing to spend ample time consulting the docs, bumping up against
confusions, etc. I want to get to the point that I'm able to take
on such matters with confidence, and so learning Guile seems important.   

>
>> While I've come to love Guile, compared to my experience with Racket
>> its
>> been quite burdensome for me to get in the hang of, something I
>> attribute
>> primarily to the structure of the docs, and not due to it being in any
>> way more difficult than Racket. While with Racket I was writing
>> useful programs in the standard #lang within my first week, with Guile
>> I often find that what should be almost trivial winds up with a lot of
>> time lost just trying to navigate and understand the docs. When I do
>> figure things out, it turns out to be no more difficult than the
>> equivalent
>> in Racket, but a lack of consistency in the path that leads there in
>> the
>> docs cause hangups, which has made trivial scripts that should take
>> an hour
>> become weekend projects.
>
> Well, I am not convinced it is because the structure of the docs.
> Instead, I think it is because it is missing docs. :-)
>
> If we compare apple to apple, here are the entry points:
>
>     https://docs.racket-lang.org/
>     https://www.gnu.org/software/guile/learn/
>
> and so the Guile manual
>
>     https://www.gnu.org/software/guile/manual/guile.html
>
> is a reference manual, which correspond to, mainly
>
>     https://docs.racket-lang.org/reference/
>
> and also,
>
>     https://docs.racket-lang.org/guide/
>

I'm covering all this in a presentation I'll be putting together over
the coming weeks, including some visualization of the structure that I
think is helpful. I'd argue that `Hello Guix`, `Hello Scheme`,
`Programming in Scheme` and `Programming in C` serve a similar function
to `Quick`, `Continue` and `More` in the Racket docs.

> I am not convinced you started Racket by these ones. ;-)
>

I started with the Racket Guide! or really, with SICP and `#lang
sicp`, doing little bits of the Racket Guide along the way and that got
me interested in racket more generally.

But probably more importantly, I think like many programmers I
started writing little projects in Racket and read the docs along the
way. And thats where my analysis focuses: the documents should, and can,
be easier to navigate, allowing one to get in-and-out as needed, but
currently there are many related functions buried in disparate areas
usually without examples. Why FTW and POSIX in disparate parts of the
manual, things its obviously desirable to use in tandem? Why are there
multiple ways to do IO without a disclaimer as to which is prefered? If
there are 30 documented SRFIs, and most have only 1 or two sentences
written for most, but some contain a treasure trove of knowledge, many 
people will move on after linking into one or two SRFI entries and
forgoe the rest, and won't realize there are tranducers in guile.

All of this adds up to a fair amount of overhead imo, and I'm planning
to put together a report covering a structural analysis of it before the
end of the month.

> Indeed, one document on the Guile side vs two documents on Racket side;
> the Guile manual could be split, I do not know if the core issue here.
> Instead, IMHO, what is missing are all the others. :-) For instance,
>
>     https://htdp.org/
>
> which is a really smooth introduction.  Somehow, it appears to me
> that it is missing an introduction, a similar document as,
>
>      https://www.gnu.org/software/emacs/manual/html_mono/eintr.html
>
I haven't read htdp, but its always at the top of recommendations
regarding Scheme literature (or PL in general). I mean, Scheme in
general has better book-length literature than possibly any other
language! Dybvig's The Scheme Programming Language has been the most
helpful, but still, it doesn't tell me anything about GOOPs, Guile's
compiler infrastructure, Tree-IL, CPS soup, etc. 

but I guess my point it, those are canonical works by some of our finest
wizards. If someone can bring that degree of pedagogical pedigree to the
Guix ecosystem we will certainly be blessed. But I think what I can
personally offer is to work on refactoring what currently exists.
>> I know this isn't the Guile list, but when I've written on this
>> topic in
>> the IRC I've had no response, which make me think docs could be a
>> bit of a bikeshedding topic in the community. But as Guile is
>> fundamental to Guix and theres a lot of crossover btwn the
>> communities,
>> it seems like this could be a good time to raise these suggestions.
>
> I agree.  For what it is worth, I tried once to quickly explain monad,
> with the aim of “Store Monad“ in mind,
>
>     https://guix.gnu.org/manual/devel/en/guix.html#The-Store-Monad
>
> After several discussions with strong Guix hackers, it appears to me
> that they missed the general concept of monad, at least it was vague.
> Therefore, I tried to write a simple explanation,
>
>     https://simon.tournier.info/posts/2021-02-03-monad.html

nice, I look forward to checking this out! yet another monad tutorial is
always due for those of us who never ventured far down that path.
>
> Bah, the other part has never seen the light, another story. :-)  Long
> time ago, Pierre wrote down a quick introduction to Scheme, which ended
> into the Cookbook,
>
>     https://guix.gnu.org/cookbook/en/guix-cookbook.html#Scheme-tutorials
>
> From my point of view, the missing documentation is the one between
> newcomer and Reference manual.  For instance, setup a Guix/Guile
> environment is not straightforward; Geiser helps, but even after some
> time, I am often still fighting against it, and I do not know what
> exists outside the Emacs world.
>
Yeah, I agree. We need a "More Perfect Setup" for hacking on Guix! In
particular, I think it would be helpful to add a section showing how to
jump to definitions emacs style; thats probably been the most helpful
tool for learning, personally.

> On the Guile land, one feature which really annoys me is the poor
> discoverability from REPL; for an instance,
>
> $ guix repl
> scheme@(guix-user)> ,a fold-packages
> scheme@(guix-user)> ,use(gnu packages)
> scheme@(guix-user)> ,a fold-packages
> (gnu packages): fold-packages	#<procedure fold-packages (proc init #:optional modules #:key select?)>
> scheme@(guix-user)> ,d fold-packages
> Call (PROC PACKAGE RESULT) for each available package defined in one of
> MODULES that matches SELECT?, using INIT as the initial value of RESULT.  It
> is guaranteed to never traverse the same package twice.
oh interesting, I didn't know that it sometimes will fail to find a
package. in general, I'm a big fan of definitions in the repl. the less
I have to look away from my text editor, the better. this is certainly
smthng that could be improved. 
>
> well, IPython, GHCi, UTop (to name some I use) provide a complete
> different experience.  Well, maybe resuming this discussion [1] is
> worth.
>
> 1: <https://yhetil.org/guix/86d00evkmr.fsf@gmail.com/>
>
>> I've jotted down some notes on several concrete examples of where
>> the docs
>> diverge from stylistic consistency, as well as some light analysis
>> as to
>> why such seemingly small inconsistencies can lead to such hangups in
>> the learning
>> process. If folks would be interested in me presenting a short 5-10min
>> presentation of these notes, I'd be happy to share.
>
> I would be interested to listen your ideas, here, there or
> overthere. :-)
>
> Cheers,
> simon
>
>
thanks for the feedback! looking forward to keeping it going.

blake
-- 
“In girum imus nocte et consumimur igni”


^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: Guix Documentation Meetup
@ 2021-12-11  1:42 Blake Shaw
  0 siblings, 0 replies; 51+ messages in thread
From: Blake Shaw @ 2021-12-11  1:42 UTC (permalink / raw)
  To: Ryan Prior; +Cc: jgart, Guix Devel

Ryan Prior <rprior@protonmail.com> writes:

> Absolutely. The Guile docs are unusable and make Guile a pain to work
> with. I say this as an experienced lisp & scheme user with decades of
> experience now in elisp, racket, and clojure. 

oh good, I'm glad to hear that I'm not alone! to be honest I don't think
its *so* bad, but it certainly demands a the user of suffers a bit, which
makes Guix in general a more difficult sell. And Guile is a truly
impressive programming language; its docs are just in need of some
remodeling I think. 

> I've found the Guile IRC channel to be polite and encouraging, but
> also very self-satisfied, which makes it hard to feel heard as a Guile
> hacker who's struggling. I hesitate to tackle any kind of nontrivial

I first checked it out when I began learning about guix, and it
seemed quite friendly. but unfortunately since I started studying Guile
I haven't had any of my questions there responded to. hopefully all is
ok. 

> problem with Guile because I have no confidence I will find tools that
> save me time; I'm proficient with a half dozen other languages,
> including multiple lisps, which provide much better support. So even
> though I really want to learn Guile,because of Guix, Shepherd and
> other cool software written in it, I'm no more likely to choose Guile
> for a software project today than I was 3 years ago when I just
> started learning it.

As long as it doesn't stall out into bikeshedding and the community is
supportive I'm dedicated to this project of working on Guile's docs
while I become acquainted with its depths. As a media artist theres
really a lot it offers. But like you say, it can suck up time with little
return; trying to figure out certain basic things in Guile has made C
feel like Python at times. Luckily, the C interface is decently
documented.

>
> When I talk to experienced hackers in the Guile community I get the
> sense they've just accepted that yeah, the only way to get anywhere is
> to cold memorize the most popular ~80 SRFIs or implement everything
> you need yourself. One person I talked to was like "oh yeah Guile's
> great, you just have to implement your own standard library like I
> did."

I'd be interested to hear any anecdotes regarding whether restructuring
the docs was attempted in the past, and what problems it incurred.
Considering my background in academia, writing is second nature, and
this has been the only thing in Guix that has appeared to me as a
serious pain point, so if I'm the only one who doesn't find writing docs
insufferable, I'm happy to take on that task for the time being.

But again, it depends on whether the community will grant me their
confidence. 

> I'd love to hear your talk, if you're up to present at the Guix meetup
> I'll definitely come and listen. I'm also happy to do what I can to
> help drive Guile adoption, create a great learning experience around
> it, and finally start to build the language community that Guile is
> lacking.

Awesome! Me too! It's seriously an incredible language -- it's just lacking
a consistent, ergonomic presentation atm. But even without that, it's
the fastest-booting lisp I've tried, and already thats enough to keep me
from crawling back to Racket (which might boot fast now with CS, but I
haven't checked in lately)

As it currently stands, its better to ditch the docs and just browse
the code base. And while for some that might be like reading email,
for the vast majority thats demanding some serious overhead from users
who are likely to pick up Guile for their personal, off-hours, creative
work.

It won't be a talk, just a 5-10min presentation of some notes where I'll
try to provide a light analysis of a few problems, along with how I
would go about fixing them, and then if all agree I'll get to work on
it.

Thanks for the encouragement!

ez,
b
-- 
“In girum imus nocte et consumimur igni”


^ permalink raw reply	[flat|nested] 51+ messages in thread
* Guix Documentation Meetup
@ 2021-12-09  9:28 jgart
  0 siblings, 0 replies; 51+ messages in thread
From: jgart @ 2021-12-09  9:28 UTC (permalink / raw)
  To: Guix Devel

Hi Guixers,

I wanted to announce that this Sunday, December 12, we'll be meeting over
Big Blue Button to work on Guix Documentation.

The meetup will start at 10:30 AM ET.

https://meet.nixnet.services/b/jga-rtw-ahw-yky

Hope to see you there,

jgart


^ permalink raw reply	[flat|nested] 51+ messages in thread
end of thread, other threads:[~2022-03-10 17:12 UTC | newest]

Thread overview: 51+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-10 22:40 Guix Documentation Meetup Blake Shaw
2021-12-10 23:18 ` Ryan Prior
2021-12-11 18:55   ` Katherine Cox-Buday
     [not found]     ` <87lf0q2m7n.fsf@nonconstructivism.com>
2021-12-13  3:50       ` Katherine Cox-Buday
2021-12-30 21:52         ` adriano
2022-01-06 15:58           ` Katherine Cox-Buday
2021-12-13  8:29 ` zimoun
2021-12-14 16:01   ` Katherine Cox-Buday
2021-12-14 17:38     ` Luis Felipe
2021-12-14 17:52       ` Katherine Cox-Buday
2021-12-20 17:45 ` Guile documentation Ludovic Courtès
2021-12-21 11:01   ` Blake Shaw
2021-12-21  6:41 ` Guix Documentation Meetup adriano
  -- strict thread matches above, loose matches on Subject: below --
2022-03-10 17:02 Raghav Gururajan
2022-03-10 17:11 ` Raghav Gururajan
     [not found] <mailman.34870.1641617883.18145.guix-devel@gnu.org>
2022-01-08  8:42 ` calcium
2022-01-08 11:35   ` Ricardo Wurmus
2022-01-08 11:49     ` calcium
2022-01-08 16:24     ` Matt
2022-01-08 18:58       ` Ricardo Wurmus
2022-01-08 19:06       ` Leo Famulari
2022-01-09 21:12         ` Matt
2022-01-10  9:05           ` André A. Gomes
2022-01-10 13:40             ` Matt
2022-01-10 16:05               ` André A. Gomes
2022-01-11 18:45                 ` Matt
2022-01-12 18:41           ` Leo Famulari
2022-01-13  0:04             ` Matt
2022-01-13  0:22       ` Leo Famulari
2022-01-13 13:15         ` ilmu
2022-01-08 13:41   ` Matt
2022-01-08 14:09     ` Julien Lepiller
2022-01-08 14:54       ` Matt
2022-01-08 14:39     ` Josselin Poiret
2022-01-08  4:52 Matt
2022-01-10  9:47 ` Oliver Propst
2022-01-10 13:15   ` Matt
2022-01-11 16:24     ` jgart
2022-01-12  0:59       ` Matt
2022-01-12  1:20         ` jgart
2022-01-12  2:57           ` Matt
2022-01-12  3:10             ` Matt
2021-12-13 13:45 Blake Shaw
2021-12-13 15:55 ` Katherine Cox-Buday
2021-12-13 12:41 Blake Shaw
2021-12-13 12:33 Blake Shaw
2021-12-15 17:37 ` Blake Shaw
2021-12-15 19:12   ` zimoun
2021-12-15 22:37     ` jgart
2021-12-11  1:42 Blake Shaw
2021-12-09  9:28 jgart

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