GNU Guix 1.4.0 released

GNU Guix 1.4.0 released

[Ludovic Courtès]

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

We are pleased to announce the release of GNU Guix 1.4.0!

This release corresponds to more than 28,000 commits over 18 months by
453 people.  It adds new tools such as ‘guix shell’ for environment
management and ‘guix home’, which lets you declare your home
environment.  It refines the user and packager experience and improves
performance.  This release also includes many new packages and services
along bug fixes—see below for a list of changes.

Read more about today’s announcement at:

  https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/


• About

  GNU Guix is a transactional package manager and an advanced
  distribution of the GNU system that respects user freedom.  Guix can
  be used on top of any system running the Hurd or the Linux kernel, or
  it can be used as a standalone operating system distribution for i686,
  x86_64, ARMv7, AArch64, and POWER9 machines.

  In addition to standard package management features, Guix supports
  transactional upgrades and roll-backs, unprivileged package
  management, per-user profiles, and garbage collection.  When used as a
  standalone GNU/Linux distribution, Guix offers a declarative,
  stateless approach to operating system configuration management.  Guix
  is highly customizable and hackable through Guile programming
  interfaces and extensions to the Scheme language.

  https://guix.gnu.org


• Download

  Here are the compressed sources and a GPG detached signature[*]:
    https://ftp.gnu.org/gnu/guix/guix-1.4.0.tar.gz   (39MB)
    https://ftp.gnu.org/gnu/guix/guix-1.4.0.tar.gz.sig

  Here are the bootable USB installation images and their signatures[*]:
    https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.i686-linux.iso   (778MB)
    https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.i686-linux.iso.sig
    https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso   (814MB)
    https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso.sig

  Here is the QCOW2 virtual machine (VM) image and its signature[*]:
    https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2 (1.2GB)
    https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2.sig

  Here are the binary tarballs and their signatures[*]:
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.aarch64-linux.tar.xz   (94MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.aarch64-linux.tar.xz.sig
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.armhf-linux.tar.xz   (92MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.armhf-linux.tar.xz.sig
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.i686-linux.tar.xz   (98MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.i686-linux.tar.xz.sig
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.powerpc64le-linux.tar.xz   (98MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.powerpc64le-linux.tar.xz.sig
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz   (98MB)
    https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz.sig

  Use a mirror for higher download bandwidth:
    https://www.gnu.org/order/ftp.html

  Here are the SHA256 hashes:

  43c769cbf632ef05449ac1fa48c1ba152c33494c6abc7e47137bba7b2149f8a4  guix-1.4.0.tar.gz
  72d807392889919940b7ec9632c45a259555e6b0942ea7bfd131101e08ebfcf4  guix-binary-1.4.0.aarch64-linux.tar.xz
  162c114ffcd5d331ec4c2974fcdca09e601e0e62950925a1d839584a7c720130  guix-binary-1.4.0.armhf-linux.tar.xz
  1e6124e917288097ef94eebd175bf1bc73f5be67a20e98fec7d33368050fd02d  guix-binary-1.4.0.i686-linux.tar.xz
  a0c54a0af8b0ae3097bfd33ddf408503a5df2d98b0848a83bb7e8da5c8d1a7fa  guix-binary-1.4.0.powerpc64le-linux.tar.xz
  236ca7c9c5958b1f396c2924fcc5bc9d6fdebcb1b4cf3c7c6d46d4bf660ed9c9  guix-binary-1.4.0.x86_64-linux.tar.xz
  07a5484d5c8f11294fabe0d32b422bdfd966ed9d8faf396cbedd0b6e3c39c740  guix-system-install-1.4.0.i686-linux.iso
  087a97dba2319477185471a28812949cc165e60e58863403e4a606c1baa05f81  guix-system-install-1.4.0.x86_64-linux.iso
  905dbdf0d32490eda66c4afdba98a80d0c3e50358b1a868423771af0a8561cae  guix-system-vm-image-1.4.0.x86_64-linux.qcow2

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

    gpg --verify guix-1.4.0.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

    gpg --keyserver keys.openpgp.org \
        --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

  and rerun the ‘gpg --verify’ command.


• Changes in 1.4.0 (since 1.3.0)

  ** Package management
  *** New ‘guix home’ command, for home environment management
  *** New ‘guix shell’ command, the successor to ‘guix environment’
  *** New ‘guix system edit’ command, to edit services
  *** New ‘deb’ format for the ‘guix pack’ command
  *** New ‘guix import minetest’ command, to import Minetest extensions
  *** New ‘guix import elm’ command, to import Elm packages
  *** New ‘guix import egg’ command, to import CHICKEN egg packages
  *** New ‘guix import hexpm’ command, to import Erlang and Elixir packages
  *** New 'guix style' command, to auto-format package definitions
  *** ‘guix import texlive’ rewritten to use the TLPDB as its source
  *** ‘guix import elpa’ now supports the non-GNU ELPA repository
  *** ‘guix import pypi’ can now import a specific version
  *** ‘guix import cran’ can now import a specific version
  *** New updater (see ‘guix refresh’): ‘generic-git’
  *** ‘guix graph’ has a new ‘--max-depth’ option
  *** ‘guix deploy’ has a new ‘--execute’ option
  *** ‘guix shell’ has a new ‘--emulate-fhs’ option
  *** ‘guix shell’ has a new ‘--symlink’ option
  *** ‘--with-commit’ option now accepts strings returned by ‘git describe’
  *** ‘--with-source’ option now applied recursively
  *** Align tabular data output by commands like ‘guix package --list-available’
  *** Improved ‘guix import go’ importer via a new PEG parser
  *** Improved Software Heritage downloader
  *** New 'web.archive.org’ download fall-back
  *** Various performance enhancements
  *** New ‘--tune’ package transformation option
  *** ‘guix refresh’ ‘-L’ option is repurposed to ‘load-path’ modification
  *** ‘guix system image’ supersedes the ‘docker-image’ sub-command

  ** Distribution
  *** The installation script can now enable local substitute servers discovery
  *** The installation script can now customize the Bash prompt for Guix
  *** More control over boot-time file system checks and repairs
  *** XFS file systems can be created by the installer and mounted by label/UUID
  *** New interface for declaring swap space
  *** GNOME is now at version 42
  *** TeX Live is now at version 2021
  *** Multiple TeX Live trees can now be used via GUIX_TEXMF
  *** Python modules are searched in GUIX_PYTHONPATH instead of PYTHONPATH
  *** Python is now faster thanks to being built with optimizations
  *** The Rust bootstrap now starts from 1.54 instead of 1.19
  *** Most Python 2 packages have been removed
  *** Guix now makes use of parallel xz compression
  *** Faster shared libraries discovery via a per-package dynamic linker cache
  *** Package inputs can now be plain package lists
  *** A package origin can now be a single file rather than an archive
  *** New sanity-check phase to detect Python packaging problems at build time
  *** Fetching sources can now fall-back to use Disarchive
  *** Improved CI and infrastructure
  *** Multiple cross-compilation tooling addition and fixes
  *** Many Qt 6 modules are now packaged
  *** Configuring setuid programs is now more flexible
  *** Add support for the XFS file system
  *** Add partial support for LUKS2 headers when using GRUB
  *** GDM now supports Wayland
  *** Guix System static networking support is improved
  *** The installer final configuration is prettified
  *** The installer external command handling is improved
  *** The installer now has a crash dump upload mechanism
  *** Emacs now supports native compilation
  *** GRUB bootloader now supports chain-loading
  *** The GNU Shepherd was upgraded to 0.9.3
  *** The init RAM disk honors more arguments—e.g. ‘root’ and ‘rootflags’
  *** ‘guix system image’ can now generate WSL images
  *** The mcron task scheduler logs now contain the jobs exit statuses
  *** Chromium extensions are now built in a deterministic fashion
  *** The ‘rsync’ service lets you specify individual “modules”
  *** New services

  anonip, bitmask, fail2ban, gitile, greetd, jami, lightdm, log-cleanup,
  nar-herder, opendht, rasdaemon, samba, seatd, strongswan, wsdd

  *** 5311 new packages

  *** 6573 package updates

  Noteworthy updates:
  bash 5.1.8, binutils 2.37, clojure 1.11.1, cups 2.3.3op2, emacs 28.2,
  enlightenment 0.25.4, gcc-toolchain 12.2.0, gdb 12.1, ghc 8.10.7,
  gimp 2.10.32, glibc 2.33, gnome 42.4, gnupg 2.2.32, go 1.19.1, guile 3.0.8,
  icecat 102.5.0-guix0-preview1, icedtea 3.19.0, inkscape 1.2.1, julia 1.6.7,
  libreoffice 7.4.3.2, linux-libre 6.0.10, ocaml 4.14.0, octave 7.2.0,
  openjdk 18, perl 5.34.0, python2 2.7.18, python 3.9.9, racket 8.7,
  rust 1.60.0, r 4.2.2, sbcl 2.2.10, shepherd 0.9.3, xorg-server 21.1.4

  ** Programming interfaces
  *** Package input fields can now be plain package lists
  *** G-expressions can now be used in build phases
  *** New ‘modify-inputs’ macro to ease customizing a list of package inputs
  *** New ‘this-package-input’ and ‘this-package-native-input’ macros
  *** Build phases are no longer required to return a boolean
  *** (guix records) now supports “field sanitizers”
  *** Various improvements to the helpers in (gnu service configuration)
  *** ‘texlive-union’ is now deprecated in favor of ‘texlive-updmap.cfg’
  *** New (guix cpu) module
  *** New (guix least-authority) module
  *** New (guix platform) module
  *** New (guix read-print) module

  It provides a comment-preserving reader and a comment-preserving
  pretty-printer smarter than (ice-9 pretty-print).

  *** New ‘channel-build-system’

  This build system lets you build Guix instances from channel specifications,
  similar to how 'guix time-machine' would do it, as regular packages.

  *** New ‘pyproject-build-system’

  This is an extension of ‘python-build-system’ with support for PEP-517 and
  ‘pyproject.toml’ files.  It may eventually get merged back into
  ‘python-build-system’.

  *** New ‘elm-build-system’
  *** New ‘rebar-build-system’

  ** Noteworthy bug fixes
  *** Fall back to Software Heritage when cloning a channel
      (<https://issues.guix.gnu.org/44187>)
  *** ‘--with-patch’ can be used on packages with non-origin sources
      (<https://issues.guix.gnu.org/49697>)
  *** Fix pathological profile building performance in the presence of grafts
      (<https://issues.guix.gnu.org/49439>)
  *** Deduplication phase of the garbage collector is now faster
      (<https://issues.guix.gnu.org/24937>)
  *** File system flags are validated before system instantiation
      (<https://issues.guix.gnu.org/51425>)
  *** Fonts can now be discovered in any profile via XDG_DATA_DIRS
      (<https://issues.guix.gnu.org/31403>)
  *** Various Python reproducibility fixes
  *** The installer now supports MSDOS disk labels on UEFI systems
      (<https://issues.guix.gnu.org/47889>)
  *** The installer can now properly mount FAT16 partitions
      (<https://issues.guix.gnu.org/48419>)
  *** The installer no longer crashes when deleting a free space partition
  *** Emacs handles major upgrades better without a re-login
      (<https://issues.guix.gnu.org/47458>)
  *** The bootloader configuration now accepts multiple targets
      (<https://issues.guix.gnu.org/40997>)
  *** File system mount point is always created when ‘create?’ is true
      (<https://issues.guix.gnu.org/40158>)
  *** Build the man database only if ‘man-db’ is in the profile
  *** gdk-pixbuf now discovers pixbuf loaders via a search path
      (<https://issues.guix.gnu.org/50957>)
  *** Gitolite home directory permissions are fixed
      (https://issues.guix.gnu.org/56444)
  *** The man-db database is indexed via man pages names
      (https://issues.guix.gnu.org/38838)
  *** ‘chfn’ can now change the user's full name
      (https://issues.guix.gnu.org/52539)
  *** GNOME Settings Bluetooth panel is now working
      (https://issues.guix.gnu.org/32166)
  *** Inferiors are now caching store connections
      (https://issues.guix.gnu.org/48007)
  *** Retry downloads when a substitute has become unavailable
      (https://issues.guix.gnu.org/57978)
  *** The installer doesn't segfault when removing an extended partition
  *** The installer doesn't ship an older Guix revision
      (https://issues.guix.gnu.org/53210)
  *** The installer cannot proceed without any non-root user accounts
      (https://issues.guix.gnu.org/54666)
  *** <operating-system> compiler truly honors the 'system' argument
      (https://issues.guix.gnu.org/55951)


Please report bugs to bug-guix@gnu.org
Join guix-devel@gnu.org and #guix on Libera.Chat for discussions.

Thanks to everyone who contributed to this release!

Ludovic, on behalf of the Guix team.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: GNU Guix 1.4.0 released

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

> • Changes in 1.4.0 (since 1.3.0)
>
>   ** Package management
>   *** New ‘guix home’ command, for home environment management
>   *** New ‘guix shell’ command, the successor to ‘guix environment’
>   *** New ‘guix system edit’ command, to edit services
>   *** New ‘deb’ format for the ‘guix pack’ command
>   *** New ‘guix import minetest’ command, to import Minetest extensions
>   *** New ‘guix import elm’ command, to import Elm packages
>   *** New ‘guix import egg’ command, to import CHICKEN egg packages
>   *** New ‘guix import hexpm’ command, to import Erlang and Elixir packages
>   *** New 'guix style' command, to auto-format package definitions
>   *** ‘guix import texlive’ rewritten to use the TLPDB as its source
>   *** ‘guix import elpa’ now supports the non-GNU ELPA repository
>   *** ‘guix import pypi’ can now import a specific version
>   *** ‘guix import cran’ can now import a specific version
>   *** New updater (see ‘guix refresh’): ‘generic-git’
>   *** ‘guix graph’ has a new ‘--max-depth’ option
>   *** ‘guix deploy’ has a new ‘--execute’ option
>   *** ‘guix shell’ has a new ‘--emulate-fhs’ option
>   *** ‘guix shell’ has a new ‘--symlink’ option
>   *** ‘--with-commit’ option now accepts strings returned by ‘git describe’
>   *** ‘--with-source’ option now applied recursively
>   *** Align tabular data output by commands like ‘guix package --list-available’
>   *** Improved ‘guix import go’ importer via a new PEG parser
>   *** Improved Software Heritage downloader
>   *** New 'web.archive.org’ download fall-back
>   *** Various performance enhancements
>   *** New ‘--tune’ package transformation option
>   *** ‘guix refresh’ ‘-L’ option is repurposed to ‘load-path’ modification
>   *** ‘guix system image’ supersedes the ‘docker-image’ sub-command
>
>   ** Distribution
>   *** The installation script can now enable local substitute servers discovery
>   *** The installation script can now customize the Bash prompt for Guix
>   *** More control over boot-time file system checks and repairs
>   *** XFS file systems can be created by the installer and mounted by label/UUID
>   *** New interface for declaring swap space
>   *** GNOME is now at version 42
>   *** TeX Live is now at version 2021
>   *** Multiple TeX Live trees can now be used via GUIX_TEXMF
>   *** Python modules are searched in GUIX_PYTHONPATH instead of PYTHONPATH
>   *** Python is now faster thanks to being built with optimizations
>   *** The Rust bootstrap now starts from 1.54 instead of 1.19
>   *** Most Python 2 packages have been removed
>   *** Guix now makes use of parallel xz compression
>   *** Faster shared libraries discovery via a per-package dynamic linker cache
>   *** Package inputs can now be plain package lists
>   *** A package origin can now be a single file rather than an archive
>   *** New sanity-check phase to detect Python packaging problems at build time
>   *** Fetching sources can now fall-back to use Disarchive
>   *** Improved CI and infrastructure
>   *** Multiple cross-compilation tooling addition and fixes
>   *** Many Qt 6 modules are now packaged
>   *** Configuring setuid programs is now more flexible
>   *** Add support for the XFS file system
>   *** Add partial support for LUKS2 headers when using GRUB
>   *** GDM now supports Wayland
>   *** Guix System static networking support is improved
>   *** The installer final configuration is prettified
>   *** The installer external command handling is improved
>   *** The installer now has a crash dump upload mechanism
>   *** Emacs now supports native compilation
>   *** GRUB bootloader now supports chain-loading
>   *** The GNU Shepherd was upgraded to 0.9.3
>   *** The init RAM disk honors more arguments—e.g. ‘root’ and ‘rootflags’
>   *** ‘guix system image’ can now generate WSL images
>   *** The mcron task scheduler logs now contain the jobs exit statuses
>   *** Chromium extensions are now built in a deterministic fashion
>   *** The ‘rsync’ service lets you specify individual “modules”
>   *** New services
>
>   anonip, bitmask, fail2ban, gitile, greetd, jami, lightdm, log-cleanup,
>   nar-herder, opendht, rasdaemon, samba, seatd, strongswan, wsdd
>
>   *** 5311 new packages
>
>   *** 6573 package updates

Congrats, and yay!  It's a hell of a release! :-) Let's try to make more
punctual ones from now on, and also try to lower the amount of manual
labor producing one incurs (by streamlining the process), as speaking
for me, this was one of the reasons I kept putting it back.

Kudos to you and everyone involved and happy holidays!

-- 
Maxim

Re: GNU Guix 1.4.0 released

[Ludovic Courtès]

Hi!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Congrats, and yay!  It's a hell of a release! :-) Let's try to make more
> punctual ones from now on, and also try to lower the amount of manual
> labor producing one incurs (by streamlining the process), as speaking
> for me, this was one of the reasons I kept putting it back.

Definitely, let’s see how we can make the process smoother.

In my experience though, a lot of the work is coordination: keeping
track of what needs to be done, open bugs, calling for testing, etc.

I think we should start thinking about the next release, forming a
small release team, and I’ll be happy to mentor!

Thanks,
Ludo’.

Re: GNU Guix 1.4.0 released

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Congrats, and yay!  It's a hell of a release! :-) Let's try to make more
>> punctual ones from now on, and also try to lower the amount of manual
>> labor producing one incurs (by streamlining the process), as speaking
>> for me, this was one of the reasons I kept putting it back.
>
> Definitely, let’s see how we can make the process smoother.
>
> In my experience though, a lot of the work is coordination: keeping
> track of what needs to be done, open bugs, calling for testing, etc.
>
> I think we should start thinking about the next release, forming a
> small release team, and I’ll be happy to mentor!

Great!  I think it'd be nice to have automation as much as possible,
with the end goal of pressing a button and having all the artifacts and
texts (at least templates of the final) produced.

-- 
Thanks,
Maxim

Re: GNU Guix 1.4.0 released

[indieterminacy]

On 03-01-2023 10:08, Ludovic Courtès wrote:
> Hi!
> 
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> 
>> Congrats, and yay!  It's a hell of a release! :-) Let's try to make 
>> more
>> punctual ones from now on, and also try to lower the amount of manual
>> labor producing one incurs (by streamlining the process), as speaking
>> for me, this was one of the reasons I kept putting it back.
> 
> Definitely, let’s see how we can make the process smoother.
> 
> In my experience though, a lot of the work is coordination: keeping
> track of what needs to be done, open bugs, calling for testing, etc.
> 
> I think we should start thinking about the next release, forming a
> small release team, and I’ll be happy to mentor!
> 
> Thanks,
> Ludo’.

Out of curiosity, have you ever approached developing a release from the 
perspective of doing documentation first?

For example, test driven approaches like BDD or TDD have allowed the 
expectations and examples to be worked out first and the the 
implementation built to form it.

More practically, theres a recent thread concerning different approaches 
and priorities concerning syntaxes. Also, if during 1.5 there were 
articulations regarding how existing behaviour does not conform with 
desired behaviour then it may become easier to divide up tasks into 
chunks for teams or individuals to work on.

With idealised documentation in place this could provide a point of 
motivation for developers and avoid any fatigue once the solution is in 
place as the /drudgery/ of explaining how things work and how they can 
be used had been worked out in advance.

In any case, while I cannot comment on the tactics within the OpenBSD 
community I always considered it a noble thing that no improvements we 
put into their OS until the features were correctly documented.

Thanks everybody with your work on 1.4.0 !

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: GNU Guix 1.4.0 released

[Joshua Branson]

indieterminacy <indieterminacy@libre.brussels> writes:

> On 03-01-2023 10:08, Ludovic Courtès wrote:
>> Hi!
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>> 
>>> Congrats, and yay!  It's a hell of a release! :-) Let's try to make more
>>> punctual ones from now on, and also try to lower the amount of manual
>>> labor producing one incurs (by streamlining the process), as speaking
>>> for me, this was one of the reasons I kept putting it back.
>> Definitely, let’s see how we can make the process smoother.
>> In my experience though, a lot of the work is coordination: keeping
>> track of what needs to be done, open bugs, calling for testing, etc.
>> I think we should start thinking about the next release, forming a
>> small release team, and I’ll be happy to mentor!
>> Thanks,
>> Ludo’.
>
> Out of curiosity, have you ever approached developing a release from the
> perspective of doing documentation first?
>
> For example, test driven approaches like BDD or TDD have allowed the
> expectations and examples to be worked out first and the the implementation
> built to form it.
>
> More practically, theres a recent thread concerning different approaches and
> priorities concerning syntaxes. Also, if during 1.5 there were articulations
> regarding how existing behaviour does not conform with desired behaviour then it
> may become easier to divide up tasks into chunks for teams or individuals to
> work on.
>
> With idealised documentation in place this could provide a point of motivation
> for developers and avoid any fatigue once the solution is in place as the
> /drudgery/ of explaining how things work and how they can be used had been
> worked out in advance.

What areas does guix need more documentation?  To answer that question
for myself, I might say more gexp examples.  Though unmatched-paren is
working on a series of blog posts to dive really deep into that topic.

> In any case, while I cannot comment on the tactics within the OpenBSD community
> I always considered it a noble thing that no improvements we put into their OS
> until the features were correctly documented.
>

While OpenBSD does a pretty good job of documenting everything, I would
also chime in and say that Guix does a fantastic job of translating the
existing documentation into other languages. What do we have
documentation in English, German, French, and significant parts in
Russian and some asian languages. That's pretty stellar!

>
> Thanks everybody with your work on 1.4.0 !

Re: GNU Guix 1.4.0 released

[indieterminacy]

On 03-01-2023 19:42, Joshua Branson wrote:
> indieterminacy <indieterminacy@libre.brussels> writes:
> 
>> On 03-01-2023 10:08, Ludovic Courtès wrote:
>>> Hi!
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>> 
>>>> Congrats, and yay!  It's a hell of a release! :-) Let's try to make 
>>>> more
>>>> punctual ones from now on, and also try to lower the amount of 
>>>> manual
>>>> labor producing one incurs (by streamlining the process), as 
>>>> speaking
>>>> for me, this was one of the reasons I kept putting it back.
>>> Definitely, let’s see how we can make the process smoother.
>>> In my experience though, a lot of the work is coordination: keeping
>>> track of what needs to be done, open bugs, calling for testing, etc.
>>> I think we should start thinking about the next release, forming a
>>> small release team, and I’ll be happy to mentor!
>>> Thanks,
>>> Ludo’.
>> 
>> Out of curiosity, have you ever approached developing a release from 
>> the
>> perspective of doing documentation first?
>> 
>> For example, test driven approaches like BDD or TDD have allowed the
>> expectations and examples to be worked out first and the the 
>> implementation
>> built to form it.
>> 
>> More practically, theres a recent thread concerning different 
>> approaches and
>> priorities concerning syntaxes. Also, if during 1.5 there were 
>> articulations
>> regarding how existing behaviour does not conform with desired 
>> behaviour then it
>> may become easier to divide up tasks into chunks for teams or 
>> individuals to
>> work on.
>> 
>> With idealised documentation in place this could provide a point of 
>> motivation
>> for developers and avoid any fatigue once the solution is in place as 
>> the
>> /drudgery/ of explaining how things work and how they can be used had 
>> been
>> worked out in advance.
> 
> What areas does guix need more documentation?  To answer that question
> for myself, I might say more gexp examples.  Though unmatched-paren is
> working on a series of blog posts to dive really deep into that topic.
> 

Over the years in general (ie for whatevever in programming), I tend to 
find documentation examples to provide the easiest way of explaining 
things and this can create shortcomings as creating or maintenan
FWIW, I always need multiple examples for any programming domain but 
this was not the point I was trying to make.
(in any case I learn systems through breaking them, it tends to give me 
a better understanding of systems).

For an idea about documenting before a project, it may be good to create 
diagrams,
as some (like myself) are visually orientated.
Not only can it be a visual assistance, it can also aid recall.
In terms of a project, this may widen the talent pool and improve 
alignment.

>> In any case, while I cannot comment on the tactics within the OpenBSD 
>> community
>> I always considered it a noble thing that no improvements we put into 
>> their OS
>> until the features were correctly documented.
>> 
> 
> While OpenBSD does a pretty good job of documenting everything, I would
> also chime in and say that Guix does a fantastic job of translating the
> existing documentation into other languages. What do we have
> documentation in English, German, French, and significant parts in
> Russian and some asian languages. That's pretty stellar!
> 
Yes, indeed!

Seeing this talk in Paris made it very clear how much this is being 
treated seriously.
https://10years.guix.gnu.org/program/#let-s-translate-guix-together-

Thanks for making this point.

Perhaps some people from different language communities require 
assistance in order to build
next generation Guix functionality.
It may be worth lowering the cost of them articulating their needs, 
including
which section within the documentation requires focus for a specific 
language.

>> 
>> Thanks everybody with your work on 1.4.0 !

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: GNU Guix 1.4.0 released

[indieterminacy]

On 03-01-2023 19:42, Joshua Branson wrote:

> What areas does guix need more documentation?  To answer that question
> for myself, I might say more gexp examples.  Though unmatched-paren is
> working on a series of blog posts to dive really deep into that topic.
> 

Guix should use more em dashes in the documentation — gets coat

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: GNU Guix 1.4.0 released

[Simon Tournier]

Hi Ludo, all,

On Tue, 03 Jan 2023 at 10:08, Ludovic Courtès <ludo@gnu.org> wrote:

> In my experience though, a lot of the work is coordination: keeping
> track of what needs to be done, open bugs, calling for testing, etc.

Yes, coordination is large part of the work, but not only as shown by
previous experiences (e.g., [1,2,3,4] and older others).

1: <https://yhetil.org/guix/86bkvckcgr.fsf@gmail.com>
2: <https://yhetil.org/guix/86ilvq5kmf.fsf@gmail.com>
3: <https://yhetil.org/guix/87tun2om0a.fsf_-_@gmail.com>
4: <https://yhetil.org/guix/867dmcifii.fsf@gmail.com>


> I think we should start thinking about the next release, forming a
> small release team, and I’ll be happy to mentor!

Definitively!  Count on me to candidate on such team. :-)

From my point of view, this team will be a rotating effort.  For
instance, from 2 to 4 people will be part.  The duty is to be part for 2
releases; 1-2 person step downs for welcoming 1-2 new person after each
release.  Well, something similar to NixOS release management.

As usual, the question is about the bootstrap. ;-)

5: <https://nixos.org/community/teams/nixos-release.html>
6: <https://nixos.github.io/release-wiki/Release-Management-Team.html>


Cheers,
simon

Setting up the release team

[Ludovic Courtès]

Hello!

Simon Tournier <zimon.toutoune@gmail.com> skribis:

>> I think we should start thinking about the next release, forming a
>> small release team, and I’ll be happy to mentor!
>
> Definitively!  Count on me to candidate on such team. :-)

Yay, thank you!!

Who else is able and willing to dedicate time to this?  I think work
could actually start real soon.

As I see it, people on the release team will *not* do all the work.
Rather, they will keep track of things and make sure we together tackle
the relevant tasks so we converge towards a release.  It does not have
to be very technical.

> From my point of view, this team will be a rotating effort.  For
> instance, from 2 to 4 people will be part.  The duty is to be part for 2
> releases; 1-2 person step downs for welcoming 1-2 new person after each
> release.  Well, something similar to NixOS release management.
>
> As usual, the question is about the bootstrap. ;-)
>
> 5: <https://nixos.org/community/teams/nixos-release.html>
> 6: <https://nixos.github.io/release-wiki/Release-Management-Team.html>

Agreed, that would be ideal.

I think we should formalize it at some point along the lines of what
NixOS did, presumably with a section in the manual.

Thanks,
Ludo’.

Re: GNU Guix 1.4.0 released

[Tobias Platen]

Hi,

Currently I am testing that one on my ThinkPad X200 and on my Talos II.

Tobias Alexandra
On Thu, 2023-01-05 at 10:57 +0100, Simon Tournier wrote:
> Hi Ludo, all,
> 
> On Tue, 03 Jan 2023 at 10:08, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> > In my experience though, a lot of the work is coordination: keeping
> > track of what needs to be done, open bugs, calling for testing,
> > etc.
> 
> Yes, coordination is large part of the work, but not only as shown by
> previous experiences (e.g., [1,2,3,4] and older others).
> 
> 1: <https://yhetil.org/guix/86bkvckcgr.fsf@gmail.com>
> 2: <https://yhetil.org/guix/86ilvq5kmf.fsf@gmail.com>
> 3: <https://yhetil.org/guix/87tun2om0a.fsf_-_@gmail.com>
> 4: <https://yhetil.org/guix/867dmcifii.fsf@gmail.com>
> 
> 
> > I think we should start thinking about the next release, forming a
> > small release team, and I’ll be happy to mentor!
> 
> Definitively!  Count on me to candidate on such team. :-)
> 
> From my point of view, this team will be a rotating effort.  For
> instance, from 2 to 4 people will be part.  The duty is to be part
> for 2
> releases; 1-2 person step downs for welcoming 1-2 new person after
> each
> release.  Well, something similar to NixOS release management.
> 
> As usual, the question is about the bootstrap. ;-)
> 
> 5: <https://nixos.org/community/teams/nixos-release.html>
> 6:
> <https://nixos.github.io/release-wiki/Release-Management-Team.html>
> 
> 
> Cheers,
> simon
>