Re: Thank you for participating in the Guix Day!

["Ludovic Courtès" <ludo@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]

Hi!

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

> On Fri, 27 Nov 2020 at 11:57, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Despite being a first experience, the live event went very smoothly (for
>> me at least, with ungoogled-chromium), it was great to see faces during
>> the break :-), and the discussions were all exciting for me.  I agree
>> it’d be great to have a blog post summarizing the event while it’s
>> fresh, even if it’s concise because we were all busy listening and
>> chatting instead of taking notes.
>
> The blog post is coming…  Writing depends on the materials at hand; for
> now nothing.

Sorry for the delay (don’t hesitate to ping me on IRC when that
happens :-)).

> Could you send your Org file to guix-days? Because I only noted the
> items that interested me.  Well, I volunteer to add words because it is
> worth, IMHO.  Nothing is written on stone but from my point of view, it
> is good to specify where Guix is eager to go more or less and especially
> helpful for the future when looking back. :-)

Attached are my (and Maxim’s) Guix Days notes for the “road map”
session, FWIW.

I agree a blog post with a recap would be/have been nice.

> BTW, initially the idea was to publish in this very blog post the links
> of the talks on audio-video.gnu.org.  But, I am confused how to upload
> them and the GNU folks behind have not answered to my email.  Anyway, it
> is not a blocking and will be added later.

Do you know exactly where it’s blocking?  Did you try filing a “support
request” under <https://savannah.gnu.org/projects/audio-video>?

Alternatively, we could keep videos on our infrastructure, but we’ll
have to make sure to set up backups and mirrors.  Chris Baines is
looking into that for the web site so that could be part of that effort.

If someone’s willing to help on setting up a web site backup, let’s
talk!

> When preparing, we discussed per-topic sub-room but the implementation
> was vague.  Now, it is clearer, so definitively for the next one. :-)
>
> About not recording, it was a conscientious choice.  We discussed it and
> we agreed that not-recording seems more in the usual “unconference” Guix
> style; especially discussions are freer when the words are not saved for
> eternity and so take the floor should be less impressive.

Alright, makes sense to me; it’s a tradeoff and being able to have
informal off-the-record discussions is nice.  Another option would be to
have a mixture of off-the-record discussions (like the real-life
“hallway track”, coffee breaks, etc.) and recorded Q&A/panel
discussions.

Thanks,
Ludo’.


[-- Attachment #2: Guix Days notes --]
[-- Type: text/x-org, Size: 2068 bytes --]

#+TITLE: The ways forward
#+STARTUP: hidestars

* tentative road map for 1.2.0

  [[https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00400.html][Medium-term road map (Apr. 2020)]]

* What's Guix?

** dependable
** liberating
*** not just FSDG
*** also helps users master complexity
*** empower users
** hackable
*** no programming language barrier
*** no need for a PhD in category theory
** high quality
*** a curated package distribution
*** community rules and QA
*** requirements not found elsewhere: build from source, unbundle, reproducible builds, bootstrap

* the things that suck
** performance
*** `guix pull' ("Computing guix derivation")
*** substitute downloads
*** broken CI (see Mathieu's talk)
*** UI glitches
**** guix shell at last!
**** search by file name (Pierre)
*** creating union directories is slow
** easier ways to work on a channel
** package size
*** deal with locales (e.g., coreutils)
** year-old bugs :-)
* the corners we cut
** build system gexp
** daemon in Scheme
** source location maps for staged code
** shepherd on Fibers (?): socket activation, etc.
* the future
** GNU/Hurd (-> janneke)
** substitutes over P2P (-> Chris Webber)
** new package definitions: no labels in inputs fields
** POLA: `guix run', --with-pola-wrapper
** 'guix hack' to work on a package?
** transparent import of packages from third-party repos?
** modularized package collection?
*** easier to hack on them, no longer different from other channels
*** more scalable (build times)
** time travel tested, formalized?
** guix environment --fhs  (file hierarchy standard)
** guix pack --format .deb|.rpm|...
** adding the missing GNU packages to the GNU Guix collection
** scalable workflows, recruiting more contributors (-> Chris Baines)
** outreach: functional deployment for everyone, not just geeks!
*** doc, translated
*** polished UI
*** graphical installer ✓
*** graphical UI (Danny)
*** graphical system UI à la YunoHost
*** blogging, training!
** CPU and power efficiency