Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
Hi Katherine, I haven't had too much time lately in regards of the survey, but hope I'll be able to commit more time to it throughout the next weeks. Thanks for reviewing the first rough draft of the questions! Katherine Cox-Buday writes: > Does the GNU project have a "general translation" team? > > Maybe some of our Guix community members who speak multiple languages > would be willing to translate the survey into their primary language? I'm not too familiar with the structures of the GNU project; but there's a page mentioning translation teams for several languages at least[0]. Don't know how active these teams are, so maybe reaching out to other community members on this list would be a better bet? > My opinion is that we should not do free form questions for this first > time. We're new at this, we have enough topics to cover, and the > topics we are covering seem to cause a lot of discussion (that's good) > which could lead to a lot of text to read through. Agreed, having quantitative questions only already seems like a good amount of work; even though free form would be quite interesting, that's, as you said, out of scope for the first survey. > Have you done any more research on what other communities are doing? I did! Hope I'll be able to write a good cohesive summary of my org-roam notes on this to share in this thread soon-ish. > What are next steps? I think Simons idea of collecting our questions somewhere and improving those until we're happy/able to start the survey period sounds like a good plan. If time permits, I'll put the rough list of questions we have now in a .org document and open an issue containing them; so we have a place where the survey questions can be edited/improved/discussed. WDYT? [0]: https://www.gnu.org/server/standards/README.translations.en.html#teams -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Enabling contribution through documentation
Hello Matt; sorry, I've been distracted and almost missed your
reply a few weeks ago.
Matt writes:
[...] I tried to write a tutorial on packaging GNU Hello.
Really, if I were to look over the shoulder of someone packaging
GNU Hello, what would it look like? Why are they doing what
they're doing in addition to what and how. It's not obvious at
all. The Cookbook touches on GNU Hello. However, it's hard to
see how someone new to the details of Guix packaging, such as
myself, is supposed to go from 'Section 2.1.1 A “Hello World”
package' to actually packaging something in the wild. All paths
inevitably lead to the Guile manual.
Yes, there are several layers of complexity at play: building the
target package (not easy when all dependencies must also be
packaged), and specifying the package in Guile.
I'm not that uncomfortable with scheme, though I don't think I
fully understand g-expressions yet. It would be easier if I could
get Geiser working for looking up symbols, but if the docs were
better I suppose I wouldn't have to read the code.
I have successfully packaged some of my own things, trying to use
guix for managing dev environments; it's not too bad for some
things, but gets much more complicated when I have to step outside
the comfort zone of directly using existing packages and build
systems as inputs. The other major thing I'm not yet familiar
with is the patch submission and management process; not that I
have anything patch-worthy yet, but it is a hurdle.
Packaging is inherently complex. It requires *at least* knowing
something about Unix-like systems, build systems, and details of
software development ranging from general programming concepts
to specific applications to all the surrounding tooling.
I think it would be fair to assume minimal competence with using a
shell. Everything else should be given as clear, exact steps to
take ('mkdir package' not 'make a directory for your package'), so
that even someone who knows nothing can perform the steps and
produce the result.
A common assumption is that "they don't have to know anything
before getting started". Unfortunately, this is not true.
Fortunately, we can often abstract this away by giving only the
necessary information (not easy to do!) for whatever we're
explaining and handing off details to another resource. This is
where the Guile documentation fails Guix.
I think of tutorials as exposure rather than explanation, so the
tutorial itself shouldn't need to explain much or rely on external
resources. However, once the reader has finished the tutorial,
they should be able to look up the steps they were exposed to.
That is what the rest of the documentation is for, so I agree it
should be improved.
It's less clear how to "fix the documentation" than "write a
tutorial" though. Maybe we can start with the tutorial, then
improve the documentation for everything it used?
I'd be happy to work alongside you.
Cool! I'm going to be pretty distracted this week, but we could
start working on it asynchronously. Any thoughts on process? Maybe
we could have a repo managed the same way Guix is, so I can learn
that at the same time. (That is, emails for discussion and patches
to the tutorial)
How hard would that be to get or set up? That could also be the
'practice repo' people doing the tutorial would use for the final
submission parts.
After that, I think the first step is picking an easy but
non-trivial package to do. Maybe it should be one that's already
been packaged... I went through a list of packages that I wished
Guix had, and sadly none of them were easy enough for me to do. My
first choice was INN (a Usenet server), but it has multiple
service dependencies I wasn't sure how to handle. My other choices
were apparently in Rust, which always has waaay too many deps. We
could also do a better Hello tutorial. Thoughts?
Thanks,
-Samuel
Re: G-expressions and chroot environment? (was Re: branch master updated: gnu: Add passff.)
Hi, On Fri, 03 Nov 2023 at 19:46, Simon Tournier wrote: > However, there is still something that I am missing. The derivations > tracks all and that’s expected; thanks G-expression machinery. :-) > However, I miss how the builder works with the chrooted environment if > nothing is passed to it. Thanks to chat with civodul, now all is clear. :-) The isolated environment is populated using the list provided by the derivation. Somehow, the G-expression machinery tracks all for helping in constructing the derivation, then the inputs of that derivation are put inside the isolated environment where the builder Guile script runs. Cool! Cheers, simon
Re: Patch Review Flow
> which I then cherry pick from (via Magit), which makes it quick and easy to > apply patches. Hi Chris, That's a great idea to use magit to select the range of patches to apply. I was doing it in a more painful way via the CLI. thanks, jgart
Re: Patch Review Flow
On Mon, Nov 06 2023, Christopher Baines wrote: > "jgart" writes: > >> Does anyone follow this workflow for reviewing patches? >> >> git clone https://git.guix-patches.cbaines.net/guix-patches/ >> git checkout issue-x >> git format-patch ... >> # then in the development checkout of Guix: >> git am ...; make; ./pre-inst-env guix build >> >> Should we document it in the manual? >> >> Does anyone follow a workflow that is more efficient than the above? > > I have the guix-patches repository as a remote, which I then cherry pick > from (via Magit), which makes it quick and easy to apply patches. Or with Emacs you can apply patches directly from the Gnus or the Debbugs interface.
Re: Reproducible Builds 2023 in Hamburg
Am Fri, Nov 03, 2023 at 12:26:52PM + schrieb Christopher Baines: > Oh, and I forgot to say with the help of Bernhard I added Guix support > to [3]. > 3: https://ismypackagereproducibleyet.org/ Exciting, congratulations! Andreas
Re: Moment de convivialité Guix@Paris en octobre
Bonjour Edouard, Quoting Edouard Klein (2023-11-05 17:03:41) > Je souhaite venir également :) J'avais raté l'annonce pour octobre. Cool ! > J'aurais deux trucs à présenter: > - Du sucre syntaxique pour instancier, étendre, modifier, ou supprimer > des services, > - Comment monter des systèmes de fichier 9P au sein d'un guix container. > > C'est pas super formel, ce sont des recherches en cours, mais si je peux > rétroprojeter mon écran et blablater pendant environ 20 minutes (en > tout), ça serait super. C'est une super idée ! Il y a un vidéo projecteur ! La dernière fois, on a fait du partage d'écran *via* JitsiMeet pour que les personnes à distance puissent participer. > Il faut apporter à manger/boire pour partager ? Tes contributions seront les bienvenues ! La logistique n'est pas encore bien rodée, mais on se dirige vers un mélange de « chacun·e apporte ce qu'ielle veut » plus « on va chercher des pizzas ». Des pizzas ou autre chose d'ailleurs. Ce ne sont pas les resto’ qui manquent dans le coin. En attendant le prochain Guix@Paris, je te souhaite une excellente journée. -- Tanguy
