Roadmap for Guix 1.0

Roadmap for Guix 1.0

[Ludovic Courtès]

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

Hello Guix!

I’ve pushed to guix/maintenance.git a list of things that IMO we should
do or might want to do for 1.0, with the understanding that 1.0 should
happen in 2018 (or early 2019 at the latest!).  :-)

  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org

The list focuses on “big item” features and tasks, omitting routine bug
fixes and improvements.  Some of these items don’t require a lot of work
or expertise though, so hopefully there’s enough on everyone’s plate.

Feel free to comment, volunteer, add items (but not too many!), remove
items, promote items, etc.  Committers should feel free to edit the file
directly in maintenance.git, especially to mark things as done.  ;-)

Copy of the file attached below.

Ludo’.

PS: I’m starting the discussion but will go AFK soon after sending this
    message.  :-)


[-- Attachment #1.2: The road to 1.0. --]
[-- Type: text/x-org, Size: 2236 bytes --]

#+TITLE: Roadmap for Guix 1.0, 2018
#+STARTUP: hidestars

* 'guix pull' & co.
** TODO 'guix pull' honors ~/.config/guix/channels.scm
*** (guix channels) module provides easy way to build a set of channels
*** (guix inferior) uses that to allow interaction with an arbitrary Guix
** MAYBE 'guix pull' & commit authentication <https://bugs.gnu.org/22883>
** TODO 'guix package -m' (?) allows users to specify a Guix channel
** TODO Profile manifest entries record the channel instance they come from
** TODO build-self.scm trampoline runs faster
* UI/UX
** TODO Add colors for messages (error, warnings, hints, and possibly build logs)
** MAYBE Hide build logs in some UIs, as in ‘wip-ui’ branch & Cuirass
** MAYBE Rework grafts and profile hooks to run as “build continuations” <https://bugs.gnu.org/28310>
** MAYBE Add ‘guix install’ alias
** TODO Add ‘guix system --delete-generations’
** MAYBE Polish & merge ‘wip-installer’
* core
** TODO Update & merge ‘wip-build-systems-gexp’
** MAYBE Merge ‘wip-gexp-hygiene’ if we have a portable way to compute gensyms
** TODO Use [[https://notabug.org/cwebber/guile-gcrypt][Guile-gcrypt]] instead of (guix gcrypt) & co.
** TODO Minimal bootstrap with Mes & co. for i686/x86_64 merged (‘wip-bootstrap’)
** MAYBE Use [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] instead of Bash during bootstrap
* infrastructure
** TODO ci.guix.gnu.org points to berlin.guixsd.org
** TODO ci.guix.gnu.org is the default substitute server; hydra.gnu.org is deprecated
** TODO ARM build machines (+ qemu-binfmt) added behind berlin.guixsd.org
** TODO Tatiana's web UI deployed on berlin.guixsd.org
** TODO Clément's Cuirass improvements deployed (inputs, non-blocking SQLite, etc.)
** TODO web site available at guix.gnu.org
*** DNS already set up with two entries, but how to do deal with LE certs and all?
** TODO Mumi web UI available at patches.guix.gnu.org and bugs.guix.gnu.org
** TODO berlin.guixsd.org has big storage, uses a TTL > 60 days
** TODO Nar bandwidth issues on berlin fixed (nginx misconfiguration?)
* miscellaneous
** TODO “GuixSD” renamed to “Guix System”?
** TODO “Cuirass” renamed to “Guix CI”?

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

Re: Roadmap for Guix 1.0

[Pjotr Prins]

On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote:
> #+TITLE: Roadmap for Guix 1.0, 2018
> #+STARTUP: hidestars
> 
> * 'guix pull' & co.
> ** TODO 'guix pull' honors ~/.config/guix/channels.scm
> *** (guix channels) module provides easy way to build a set of channels
> *** (guix inferior) uses that to allow interaction with an arbitrary Guix
> ** MAYBE 'guix pull' & commit authentication <https://bugs.gnu.org/22883>
> ** TODO 'guix package -m' (?) allows users to specify a Guix channel
> ** TODO Profile manifest entries record the channel instance they come from
> ** TODO build-self.scm trampoline runs faster
> * UI/UX
> ** TODO Add colors for messages (error, warnings, hints, and possibly build logs)
> ** MAYBE Hide build logs in some UIs, as in ‘wip-ui’ branch & Cuirass
> ** MAYBE Rework grafts and profile hooks to run as “build continuations” <https://bugs.gnu.org/28310>
> ** MAYBE Add ‘guix install’ alias
> ** TODO Add ‘guix system --delete-generations’
> ** MAYBE Polish & merge ‘wip-installer’
> * core
> ** TODO Update & merge ‘wip-build-systems-gexp’
> ** MAYBE Merge ‘wip-gexp-hygiene’ if we have a portable way to compute gensyms
> ** TODO Use [[https://notabug.org/cwebber/guile-gcrypt][Guile-gcrypt]] instead of (guix gcrypt) & co.
> ** TODO Minimal bootstrap with Mes & co. for i686/x86_64 merged (‘wip-bootstrap’)
> ** MAYBE Use [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] instead of Bash during bootstrap
> * infrastructure
> ** TODO ci.guix.gnu.org points to berlin.guixsd.org
> ** TODO ci.guix.gnu.org is the default substitute server; hydra.gnu.org is deprecated
> ** TODO ARM build machines (+ qemu-binfmt) added behind berlin.guixsd.org
> ** TODO Tatiana's web UI deployed on berlin.guixsd.org
> ** TODO Clément's Cuirass improvements deployed (inputs, non-blocking SQLite, etc.)
> ** TODO web site available at guix.gnu.org
> *** DNS already set up with two entries, but how to do deal with LE certs and all?
> ** TODO Mumi web UI available at patches.guix.gnu.org and bugs.guix.gnu.org
> ** TODO berlin.guixsd.org has big storage, uses a TTL > 60 days
> ** TODO Nar bandwidth issues on berlin fixed (nginx misconfiguration?)
> * miscellaneous
> ** TODO “GuixSD” renamed to “Guix System”?
> ** TODO “Cuirass” renamed to “Guix CI”?

Are these all really necessary for 1.0? Or can it be 1.1? I think we
are pushing ourselves too much to have all deployment tools and
website stuff aligned ;)

Q: how large a big storage do we need for TTL>60d today? I don't have
a build farm in the USA, but I can create a mirror if you allow rsync
and have guix publish running on guix.genenetwork.org (or any name,
really). Is that of interest?

Pj.

Re: Roadmap for Guix 1.0

[Nils Gillmann]

Pjotr Prins transcribed 2.9K bytes:
> On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote:
> > #+TITLE: Roadmap for Guix 1.0, 2018
> > #+STARTUP: hidestars
> > 
> > * 'guix pull' & co.
> > ** TODO 'guix pull' honors ~/.config/guix/channels.scm
> > *** (guix channels) module provides easy way to build a set of channels
> > *** (guix inferior) uses that to allow interaction with an arbitrary Guix
> > ** MAYBE 'guix pull' & commit authentication <https://bugs.gnu.org/22883>
> > ** TODO 'guix package -m' (?) allows users to specify a Guix channel
> > ** TODO Profile manifest entries record the channel instance they come from
> > ** TODO build-self.scm trampoline runs faster
> > * UI/UX
> > ** TODO Add colors for messages (error, warnings, hints, and possibly build logs)
> > ** MAYBE Hide build logs in some UIs, as in ‘wip-ui’ branch & Cuirass
> > ** MAYBE Rework grafts and profile hooks to run as “build continuations” <https://bugs.gnu.org/28310>
> > ** MAYBE Add ‘guix install’ alias
> > ** TODO Add ‘guix system --delete-generations’
> > ** MAYBE Polish & merge ‘wip-installer’
> > * core
> > ** TODO Update & merge ‘wip-build-systems-gexp’
> > ** MAYBE Merge ‘wip-gexp-hygiene’ if we have a portable way to compute gensyms
> > ** TODO Use [[https://notabug.org/cwebber/guile-gcrypt][Guile-gcrypt]] instead of (guix gcrypt) & co.
> > ** TODO Minimal bootstrap with Mes & co. for i686/x86_64 merged (‘wip-bootstrap’)
> > ** MAYBE Use [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] instead of Bash during bootstrap
> > * infrastructure
> > ** TODO ci.guix.gnu.org points to berlin.guixsd.org
> > ** TODO ci.guix.gnu.org is the default substitute server; hydra.gnu.org is deprecated
> > ** TODO ARM build machines (+ qemu-binfmt) added behind berlin.guixsd.org
> > ** TODO Tatiana's web UI deployed on berlin.guixsd.org
> > ** TODO Clément's Cuirass improvements deployed (inputs, non-blocking SQLite, etc.)
> > ** TODO web site available at guix.gnu.org
> > *** DNS already set up with two entries, but how to do deal with LE certs and all?
> > ** TODO Mumi web UI available at patches.guix.gnu.org and bugs.guix.gnu.org
> > ** TODO berlin.guixsd.org has big storage, uses a TTL > 60 days
> > ** TODO Nar bandwidth issues on berlin fixed (nginx misconfiguration?)
> > * miscellaneous
> > ** TODO “GuixSD” renamed to “Guix System”?
> > ** TODO “Cuirass” renamed to “Guix CI”?
> 
> Are these all really necessary for 1.0? Or can it be 1.1? I think we
> are pushing ourselves too much to have all deployment tools and
> website stuff aligned ;)

I think it's okay. In the end version numbers are just numbers. We are
at 0.15, so we can go all the way up to 1.0 with many version releases
between to fit in parts of 1.0.

> Q: how large a big storage do we need for TTL>60d today? I don't have
> a build farm in the USA, but I can create a mirror if you allow rsync
> and have guix publish running on guix.genenetwork.org (or any name,
> really). Is that of interest?
> 
> Pj.
> 
> 

Re: Roadmap for Guix 1.0

[Pierre Neidhardt]

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

Also how far did we go with LVM support?

-- 
Pierre Neidhardt

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

LVM support

[Ludovic Courtès]

Hi!

Pierre Neidhardt <ambrevar@gmail.com> skribis:

> Also how far did we go with LVM support?

This was discussed looong ago (whether/how the device-mapping code would
be a good fit for LVM) but we don’t have any code.

This would be nice to have, though I wouldn’t consider it a blocker for
1.0.

Ludo’.

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

"There are only two hard problems in Computer Science: cache 
invalidation and naming things"


On 2018-07-30 03:23, Pjotr Prins wrote:
> On Sun, Jul 29, 2018 at 05:18:21PM +0200, Ludovic Courtès wrote:
>> #+TITLE: Roadmap for Guix 1.0, 2018

>> * miscellaneous
>> ** TODO “GuixSD” renamed to “Guix System”?

Guix System is not good because "system" is a word that is too generic.

What about "Guix OS"?

>> ** TODO “Cuirass” renamed to “Guix CI”?

OK

Re: Roadmap for Guix 1.0

[Pierre Neidhardt]

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


> >> ** TODO “GuixSD” renamed to “Guix System”?
>
> Guix System is not good because "system" is a word that is too generic.
>
> What about "Guix OS"?
>
> >> ** TODO “Cuirass” renamed to “Guix CI”?
>
> OK

On the one hand, OS and CI are rather ubiquitous.

On the other hand, I've personally always been wary of excessive use of
abbreviations: newcomers will find documentation and communication cryptic,
while abbreviations proliferate, sometimes out of control.

But I don't think it's the case for Guix OS and even Apple went for "macOS" so I
guess "OS" is pretty safe (much more than "SD" at least).

Conversely, "Guix CI" is much less widespread, although I suppose many
developers are familiar with the term.  I personally prefer unique, easy names
to abbreviations.

- The name "Guix CI" tells developers what it is (continuous integration) while
  "Cuirass" does not.  This is mostly true, however, for almost all applications
  (mpv, firefox, chromium, emacs, <add almost everything here>).

- If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
  will end up with a bunch Guix FS, Guix IP, Guix CD...

-- 
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: Roadmap for Guix 1.0

[Ludovic Courtès]

Hello,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Conversely, "Guix CI" is much less widespread, although I suppose many
> developers are familiar with the term.  I personally prefer unique, easy names
> to abbreviations.
>
> - The name "Guix CI" tells developers what it is (continuous integration) while
>   "Cuirass" does not.  This is mostly true, however, for almost all applications
>   (mpv, firefox, chromium, emacs, <add almost everything here>).
>
> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
>   will end up with a bunch Guix FS, Guix IP, Guix CD...

I think “Guix System” is OK.  Most of the time we’ll just say “Guix”, as
is already the case, and when we need to disambiguate (for instance when
addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
using the Guix distro?”, and everything will be fine.  :-)

The motivation for this name change is that “SD” is obscure to most, as
you note, plus it creates confusion when people visit the web site: the
web site has a “GuixSD” logo, but then it talks about features of the
package manager.  Designating the whole tool set as “Guix” will simplify
this, and we can always be more specific when we need to.

For Cuirass, I think “Guix CI” (or “Guix Continuous”?) is good enough.
It remains a tool primarily for Guix developers anyway, and a secondary
tool in the Guix toolbox.

Ludo’.

Re: Roadmap for Guix 1.0

[Ricardo Wurmus]

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

> Hello,
>
> Pierre Neidhardt <mail@ambrevar.xyz> skribis:
>
>> Conversely, "Guix CI" is much less widespread, although I suppose many
>> developers are familiar with the term.  I personally prefer unique, easy names
>> to abbreviations.
>>
>> - The name "Guix CI" tells developers what it is (continuous integration) while
>>   "Cuirass" does not.  This is mostly true, however, for almost all applications
>>   (mpv, firefox, chromium, emacs, <add almost everything here>).
>>
>> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
>>   will end up with a bunch Guix FS, Guix IP, Guix CD...
>
> I think “Guix System” is OK.

I think so too.

> Most of the time we’ll just say “Guix”, as
> is already the case, and when we need to disambiguate (for instance when
> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> using the Guix distro?”, and everything will be fine.  :-)

Exactly.

I wrote this on IRC:

The name “GuixSD” is opaque and creates an arbitrary distinction between
the system running on bare metal and the systems you can create with the
“guix system” commands.  It makes it difficult to communicate about
Guix.  Do we really offer “a package manager” and a “distro” — or is it
really all one thing with various levels?

The “guix system” command can be used without GuixSD to create Guix
virtual machines or containers.  Describing “guix system” is difficult
when we think in terms of “package manager” vs “distro”.  Guix itself is
also a distro – none of the packages it provides link with the host
system, and the collection of packages is a distribution of free
software.

I think that simplifying the name by using “guix” as a category will
make communication easier.

> The motivation for this name change is that “SD” is obscure to most, as
> you note, plus it creates confusion when people visit the web site: the
> web site has a “GuixSD” logo, but then it talks about features of the
> package manager.  Designating the whole tool set as “Guix” will simplify
> this, and we can always be more specific when we need to.

I agree.

--
Ricardo

Re: Roadmap for Guix 1.0

[Tobias Geerinckx-Rice]

Guix,

Ricardo Wurmus wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
>> I think “Guix System” is OK.
>
> I think so too.

Big +1.

If you use 'guix system', you're using Guix System[0].

It doesn't get less confusing than that.

Kind regards,

T G-R

[0]: The only question left is 'on what?'. Everything, of course.

Re: Roadmap for Guix 1.0

[Nils Gillmann]

Tobias Geerinckx-Rice transcribed 340 bytes:
> Guix,
> 
> Ricardo Wurmus wrote:
> > Ludovic Courtès <ludo@gnu.org> writes:
> > > I think “Guix System” is OK.
> > 
> > I think so too.
> 
> Big +1.
> 
> If you use 'guix system', you're using Guix System[0].
> 
> It doesn't get less confusing than that.
> 
> Kind regards,
> 
> T G-R
> 
> [0]: The only question left is 'on what?'. Everything, of course.
> 

Sounds good for me too.

Re: Roadmap for Guix 1.0

[George Clemmer]

Ricardo Wurmus <rekado@elephly.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello,
>>
>> I think “Guix System” is OK.
>
> I think so too.

I recommend against renaming GuixSD >> "Guix System". Here is Why:

1) A noob would expect "guix system" to refer to the whole Guix
enchilada. If we use it to refer to GuixSD, a specific Guix deployment
mode, we have created a new, counter-intuitive thing we have to explain.

2) As Ricardo points out below, the "guix system" command clashes with
this use of Guix system. This is a second counter-intuitive thing we
would have to explain.

Bottom line: we shouln'd use the general term "Guix System" in any way
beyond, perhaps in a descriptway way, e.g., The Guix project develops
the Guix System, a set of tools that manage software environments.

>> Most of the time we’ll just say “Guix”, as
>> is already the case, and when we need to disambiguate (for instance when
>> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
>> using the Guix distro?”, and everything will be fine.  :-)
>
> Exactly.
>
> I wrote this on IRC:
>
> The name “GuixSD” is opaque and creates an arbitrary distinction between
> the system running on bare metal and the systems you can create with the
> “guix system” commands.  It makes it difficult to communicate about
> Guix.  Do we really offer “a package manager” and a “distro” — or is it
> really all one thing with various levels?
>
> The “guix system” command can be used without GuixSD to create Guix
> virtual machines or containers.  Describing “guix system” is difficult
> when we think in terms of “package manager” vs “distro”.  Guix itself is
> also a distro – none of the packages it provides link with the host
> system, and the collection of packages is a distribution of free
> software.
>
> I think that simplifying the name by using “guix” as a category will
> make communication easier.
>
>> The motivation for this name change is that “SD” is obscure to most, as
>> you note, plus it creates confusion when people visit the web site: the
>> web site has a “GuixSD” logo, but then it talks about features of the
>> package manager.  Designating the whole tool set as “Guix” will simplify
>> this, and we can always be more specific when we need to.
>
> I agree.

I agree too. You may recall that I recommendi this approach when we
discussed the web site in January. That thread includes a product
description [1] that might be a good place to start when describing the
"whole tool set".

[1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html

Re: Roadmap for Guix 1.0

[Gábor Boskovits]

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

George Clemmer <myglc2@gmail.com> ezt írta (időpont: 2018. aug. 30., Cs,
21:14):

>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >> Hello,
> >>
> >> I think “Guix System” is OK.
> >
> > I think so too.
>
> I recommend against renaming GuixSD >> "Guix System". Here is Why:
>
> 1) A noob would expect "guix system" to refer to the whole Guix
> enchilada. If we use it to refer to GuixSD, a specific Guix deployment
> mode, we have created a new, counter-intuitive thing we have to explain.
>
> 2) As Ricardo points out below, the "guix system" command clashes with
> this use of Guix system. This is a second counter-intuitive thing we
> would have to explain.
>
> Bottom line: we shouln'd use the general term "Guix System" in any way
> beyond, perhaps in a descriptway way, e.g., The Guix project develops
> the Guix System, a set of tools that manage software environments.
>
> >> Most of the time we’ll just say “Guix”, as
> >> is already the case, and when we need to disambiguate (for instance when
> >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> >> using the Guix distro?”, and everything will be fine.  :-)
> >
> > Exactly.
> >
> > I wrote this on IRC:
> >
> > The name “GuixSD” is opaque and creates an arbitrary distinction between
> > the system running on bare metal and the systems you can create with the
> > “guix system” commands.  It makes it difficult to communicate about
> > Guix.  Do we really offer “a package manager” and a “distro” — or is it
> > really all one thing with various levels?
> >
> > The “guix system” command can be used without GuixSD to create Guix
> > virtual machines or containers.  Describing “guix system” is difficult
> > when we think in terms of “package manager” vs “distro”.  Guix itself is
> > also a distro – none of the packages it provides link with the host
> > system, and the collection of packages is a distribution of free
> > software.
> >
> > I think that simplifying the name by using “guix” as a category will
> > make communication easier.
> >
> >> The motivation for this name change is that “SD” is obscure to most, as
> >> you note, plus it creates confusion when people visit the web site: the
> >> web site has a “GuixSD” logo, but then it talks about features of the
> >> package manager.  Designating the whole tool set as “Guix” will simplify
> >> this, and we can always be more specific when we need to.
> >
> > I agree.
>
> I agree too. You may recall that I recommendi this approach when we
> discussed the web site in January. That thread includes a product
> description [1] that might be a good place to start when describing the
> "whole tool set".
>
> [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html
>
> What do you think about  GuixSD >> "Guix Distribution"? This naming seems
to resolve the ambiguities mentioned so far, and has a widespread
use, that exactly matches the intended meaning. WDYT?

[-- Attachment #2: Type: text/html, Size: 3993 bytes --]

Re: Roadmap for Guix 1.0

[George Clemmer]

Gábor Boskovits <boskovits@gmail.com> writes:

> George Clemmer <myglc2@gmail.com> ezt írta (időpont: 2018. aug. 30., Cs,
> 21:14):
>
>>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>> > Ludovic Courtès <ludo@gnu.org> writes:
>> >
>> >> Hello,
>> >>
>> >> I think “Guix System” is OK.
>> >
>> > I think so too.
>>
>> I recommend against renaming GuixSD >> "Guix System". Here is Why:
>>
>> 1) A noob would expect "guix system" to refer to the whole Guix
>> enchilada. If we use it to refer to GuixSD, a specific Guix deployment
>> mode, we have created a new, counter-intuitive thing we have to explain.
>>
>> 2) As Ricardo points out below, the "guix system" command clashes with
>> this use of Guix system. This is a second counter-intuitive thing we
>> would have to explain.
>>
>> Bottom line: we shouln'd use the general term "Guix System" in any way
>> beyond, perhaps in a descriptway way, e.g., The Guix project develops
>> the Guix System, a set of tools that manage software environments.
>>
>> >> Most of the time we’ll just say “Guix”, as
>> >> is already the case, and when we need to disambiguate (for instance when
>> >> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
>> >> using the Guix distro?”, and everything will be fine.  :-)
>> >
>> > Exactly.
>> >
>> > I wrote this on IRC:
>> >
>> > The name “GuixSD” is opaque and creates an arbitrary distinction between
>> > the system running on bare metal and the systems you can create with the
>> > “guix system” commands.  It makes it difficult to communicate about
>> > Guix.  Do we really offer “a package manager” and a “distro” — or is it
>> > really all one thing with various levels?
>> >
>> > The “guix system” command can be used without GuixSD to create Guix
>> > virtual machines or containers.  Describing “guix system” is difficult
>> > when we think in terms of “package manager” vs “distro”.  Guix itself is
>> > also a distro – none of the packages it provides link with the host
>> > system, and the collection of packages is a distribution of free
>> > software.
>> >
>> > I think that simplifying the name by using “guix” as a category will
>> > make communication easier.
>> >
>> >> The motivation for this name change is that “SD” is obscure to most, as
>> >> you note, plus it creates confusion when people visit the web site: the
>> >> web site has a “GuixSD” logo, but then it talks about features of the
>> >> package manager.  Designating the whole tool set as “Guix” will simplify
>> >> this, and we can always be more specific when we need to.
>> >
>> > I agree.
>>
>> I agree too. You may recall that I recommendi this approach when we
>> discussed the web site in January. That thread includes a product
>> description [1] that might be a good place to start when describing the
>> "whole tool set".
>>
>> [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00457.html
>>
>> What do you think about  GuixSD >> "Guix Distribution"? This naming seems
> to resolve the ambiguities mentioned so far, and has a widespread
> use, that exactly matches the intended meaning. WDYT?

Hi Gábor,

I think this discussion was primarily triggered by the realization that
we can improve the top-level presentation of Guix by downplaying the
distinction between Guix and GuixSD. In fact, we could delay the
introduction of Guix/GuixSD to the download page.

A more informative download page might look like:

Use Guix to manage ...

entire computers: GuixSD download options: x86_64 i686

VMs: download options: GuixSD x86_64-QEMU-image

GNU/Linux user environments: Guix download options: x86_64, i686, armhf,
aarch64

Here we see the primary purpose of the Guix/GuixSD labels is to identify
the different download options and to enable the user to find the
correct install instructions and doc sections for whatever they
download.

GuixSD doesn't necessarily need to be changed. But the issue has been
raised, as mentioned above, that because "SD" is not a recognized
abbreviation "GuixSD" carries no intuitive meaning. If we want an
improved label for the Guix system distribution, the best one is
probably "GuixOS" since "OS" is a widely used and recognized
abbreviation ...

Term                google hits
OS                  3.0 * 10**9
operating system    0.7 * 10**9
system distribution 0.5 * 10**9

I guess the issue with this is that it seems odd to say "the GNU Guix
GNU/Linux System Distribution, abbreviated GuixOS" ;-)

HTH - George

Re: Roadmap for Guix 1.0

[Vincent Legoll]

Hello,

I was refraining to answer, but this:

On Fri, Aug 31, 2018 at 4:29 PM George Clemmer <myglc2@gmail.com> wrote:
> I think this discussion was primarily triggered by the realization that
> we can improve the top-level presentation of Guix by downplaying the
> distinction between Guix and GuixSD. In fact, we could delay the
> introduction of Guix/GuixSD to the download page.
>
> A more informative download page might look like:
>
> Use Guix to manage ...
>
> entire computers: GuixSD download options: x86_64 i686
>
> VMs: download options: GuixSD x86_64-QEMU-image
>
> GNU/Linux user environments: Guix download options: x86_64, i686, armhf,
> aarch64
>
> Here we see the primary purpose of the Guix/GuixSD labels is to identify
> the different download options and to enable the user to find the
> correct install instructions and doc sections for whatever they
> download.
>
> GuixSD doesn't necessarily need to be changed. But the issue has been
> raised, as mentioned above, that because "SD" is not a recognized
> abbreviation "GuixSD" carries no intuitive meaning. If we want an
> improved label for the Guix system distribution, the best one is
> probably "GuixOS" since "OS" is a widely used and recognized
> abbreviation ...

Is exactly my opinion also, so it gets a +1

Bye

-- 
Vincent Legoll

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

> > >If we want an
> > improved label for the Guix system distribution, the best one is
> > probably "GuixOS" since "OS" is a widely used and recognized
> > abbreviation ...
>
> Is exactly my opinion also, so it gets a +1
>

Top 3:

1) GuixOS
2) Guix
3) Guix System

Re: Roadmap for Guix 1.0

[rchar01]

As an example, PureOS had a similar idea for the name.

- https://www.pureos.net/
- from https://www.gnu.org/distros/free-distros.en.html


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On August 31, 2018 5:54 PM, Amirouche Boubekki <amirouche.boubekki@gmail.com> wrote:

> > > > If we want an
> > > > improved label for the Guix system distribution, the best one is
> > > > probably "GuixOS" since "OS" is a widely used and recognized
> > > > abbreviation ...
> >
> > Is exactly my opinion also, so it gets a +1
>
> Top 3:
>
> 1.  GuixOS
> 2.  Guix
> 3.  Guix System

Re: Roadmap for Guix 1.0

[Pjotr Prins]

On Sat, Sep 01, 2018 at 07:36:35AM +0000, rchar01 wrote:
> As an example, PureOS had a similar idea for the name.
> 
> - https://www.pureos.net/
> - from https://www.gnu.org/distros/free-distros.en.html

We should have some flavours:

FunGuixOs
SeriousGuixOs
VerySeriousGuixOS
VerySeriousGuixOSIndeed

Just kidding. GuixOS sounds fine to me. How will be distinguish
between Linux and Hurd?

GuixLinuxOS
GuixHurdOS

or simplify to

GNU Guix Linux
GNU Guix Hurd

Pj.

Re: Roadmap for Guix 1.0

[Nils Gillmann]

Pjotr Prins transcribed 466 bytes:
> On Sat, Sep 01, 2018 at 07:36:35AM +0000, rchar01 wrote:
> > As an example, PureOS had a similar idea for the name.
> > 
> > - https://www.pureos.net/
> > - from https://www.gnu.org/distros/free-distros.en.html
> 
> We should have some flavours:
> 
> FunGuixOs
> SeriousGuixOs
> VerySeriousGuixOS
> VerySeriousGuixOSIndeed
> 
> Just kidding. GuixOS sounds fine to me. How will be distinguish
> between Linux and Hurd?

We don't have to. Why would you want this?
Simply give a download a descriptive name, and put the details in
parens behind it or a proper description box.

Imagine we get support for one of the BSD kernels in the future. And
then a variant which builds our own BSD-based GuixSD/OS.. you don't
need to come up with a new name every time.

GuixOS (Linux-libre)
GuixOS (Hurd)
GuixOS (obsd)

easy as that

> GuixLinuxOS
> GuixHurdOS
> 
> or simplify to
> 
> GNU Guix Linux
> GNU Guix Hurd
> 
> Pj.
> 

Re: Roadmap for Guix 1.0

[George Clemmer]

Hi,

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

> Hello,
>
> Pierre Neidhardt <mail@ambrevar.xyz> skribis:
>
>> - If we get started with Guix CI and Guix OS, I'm afraid that soon enough we
>>   will end up with a bunch Guix FS, Guix IP, Guix CD...
>
> I think “Guix System” is OK.  Most of the time we’ll just say “Guix”, as
> is already the case, and when we need to disambiguate (for instance when
> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> using the Guix distro?”, and everything will be fine.  :-)
>
> The motivation for this name change is that “SD” is obscure to most, as
> you note, plus it creates confusion when people visit the web site: the
> web site has a “GuixSD” logo, but then it talks about features of the
> package manager.  Designating the whole tool set as “Guix” will simplify
> this, and we can always be more specific when we need to.

This is good because it declutters the Guix-Verse for new users.

I suggest that the distinction between GuixOS, package manager, QEMU
image, and source can be re-positioned as download options.

We could simplify the choice of these by improving the download
page. For example ...

1) We could simplify the download labels/descriptions, e.g.,

   "GuixSD 0.15.0 QEMU Image QCOW2 virtual machine (VM) image. Download
   options: x86_64"

   ... might become ...

   "x86_64 VM (GuixSD 0.15.0 QEMU Image QCOW2 virtual machine image)"

2) We could add a feature check list that helps with download selection.

With such changes the support question is: what did you download?

IMO it would be desirable to pick a single term for each download option
and use it obsessively throughout the site and doc. This small thing can
be quite helpful to a noob because it eliminates any confusion that
might be caused by multiple terms meaning the same thing. So, IMO we
should settle on only one of Guix System, GuixSD, GuixOS, or maybe "Guix
bare metal".

- George

Re: Roadmap for Guix 1.0

[Hartmut Goebel]

Am 30.08.2018 um 14:04 schrieb Ludovic Courtès:
> “Guix Continuous”

For me this sounds like a fail-save system which will continue running,
and running, and running.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Roadmap for Guix 1.0

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> I think “Guix System” is OK.  Most of the time we’ll just say “Guix”, as
> is already the case, and when we need to disambiguate (for instance when
> addressing bugs), we’ll ask “Are you using Guix System?” or “Are you
> using the Guix distro?”, and everything will be fine.  :-)

Yes, I found that "SD" is often more confusing than not.

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Roadmap for Guix 1.0

[Taylan Kammer]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> - The name "Guix CI" tells developers what it is (continuous integration) while
>   "Cuirass" does not.  This is mostly true, however, for almost all applications
>   (mpv, firefox, chromium, emacs, <add almost everything here>).

Just an anecdote: I didn't know what Cuirass was until I read this
thread, though I saw the name many times. :-)

Taylan

Re: Roadmap for Guix 1.0

[Chris Marusich]

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

ludo@gnu.org (Ludovic Courtès) writes:

> #+TITLE: Roadmap for Guix 1.0, 2018

A lot of good stuff!  I hope I can find the time to help knock out some
of these things.

At the moment, I only have this to add: It would be nice if we could
decide on how we will use version numbers going forward and publish a
description of that in the manual or on the website.

I think the important thing is that we publish a description.  The
details of it are less important.  We can use Semantic Versioning [1],
Sentimental Versioning [2], or something totally different.  As long as
we publish our decision and stick to it, everyone will know what to
expect.


Footnotes: 
[1]  https://semver.org/

[2]  It's not my top choice, though!  http://sentimentalversioning.org/

-- 
Chris

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

Re: Roadmap for Guix 1.0

[Pierre Neidhardt]

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

> Sentimental Versioning

Didn't know about this, interesting take... :)

My two cents because I'm not sure it fits the list:

- `man' is broken.
	https://lists.gnu.org/archive/html/help-guix/2018-05/msg00084.html
It seems trivial but I don't think we should put a 1.0 stamp on an OS that can't
display standard documentation correctly.
I'll open a bug about it, I can work on it later.

- As Julien mentioned recently, I think we should provide a "stable"
channel.  Is it already implied by the new (guix channel) module?

- `guix package --upgrade' reverses the order of packages.
	https://lists.gnu.org/archive/html/help-guix/2018-04/msg00070.html
	https://bugs.gnu.org/31142
I think "infinite upgrades" will look very ugly to the casual user, we ought to
fix that :)

- TeXlive... (sigh!)
TeXlive is rather important for lots of users but also lots of packages.
Some packages (e.g. "asymptote" and "mit-scheme") currently depend on the full
TeXlive distribution (5GB).  This is way too much for many users (low disk
space, low bandwidth, or simply lack of time).
I'm working on adding the missing individual TeXlive packages, but it's
surprisingly hard, so help is more than welcome.
	https://lists.gnu.org/archive/html/help-guix/2018-05/msg00218.html
We also need a user hook to install individual packages to the user profile:
	https://bugs.gnu.org/27217

Anything among these deemed for a post 1.0 release?
-- 
Pierre Neidhardt

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

Re: Roadmap for Guix 1.0

[Ludovic Courtès]

Hello,

Pierre Neidhardt <ambrevar@gmail.com> skribis:

> My two cents because I'm not sure it fits the list:
>
> - `man' is broken.
> 	https://lists.gnu.org/archive/html/help-guix/2018-05/msg00084.html

[...]

> - As Julien mentioned recently, I think we should provide a "stable"
> channel.  Is it already implied by the new (guix channel) module?
>
> - `guix package --upgrade' reverses the order of packages.
> 	https://lists.gnu.org/archive/html/help-guix/2018-04/msg00070.html
> 	https://bugs.gnu.org/31142

Agreed, these are “regular bugs” that should be fixed.

Regarding the “stable” channel, it sounds nice, but again we need
machinery to do automatic merging from master to stable when things are
built (if I remember Julien’s proposal correctly.)   I don’t know, I’m
not entirely sure how this could happen.  :-)

> - TeXlive... (sigh!)

Oh right, definitely something we need for 1.0!  It’s great that you
already started looking at importing more packages from TeXLive, even if
that turns out to be incredibly tricky.  Then we’ll need a profile hook
so people have the option to directly install individual texlive
packages in their profile.

Thanks,
Ludo’.

Re: Roadmap for Guix 1.0

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> At the moment, I only have this to add: It would be nice if we could
> decide on how we will use version numbers going forward and publish a
> description of that in the manual or on the website.
>
> I think the important thing is that we publish a description.  The
> details of it are less important.  We can use Semantic Versioning [1],
> Sentimental Versioning [2], or something totally different.  As long as
> we publish our decision and stick to it, everyone will know what to
> expect.

Good point!  The difficulty here is that Guix is effectively a large
collection of libraries, which makes it hard to map it to the semver
story, I think.  Or to put it differently, we should map to semver in an
“abstract way”: what semver refers to as “API changes” would rather be
important CLI/API changes.

Thoughts?

Ludo’.

Re: Roadmap for Guix 1.0

[Chris Marusich]

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

Hi Ludo,

ludo@gnu.org (Ludovic Courtès) writes:

> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> At the moment, I only have this to add: It would be nice if we could
>> decide on how we will use version numbers going forward and publish a
>> description of that in the manual or on the website.
>>
>> I think the important thing is that we publish a description.  The
>> details of it are less important.  We can use Semantic Versioning [1],
>> Sentimental Versioning [2], or something totally different.  As long as
>> we publish our decision and stick to it, everyone will know what to
>> expect.
>
> Good point!  The difficulty here is that Guix is effectively a large
> collection of libraries, which makes it hard to map it to the semver
> story, I think.  Or to put it differently, we should map to semver in an
> “abstract way”: what semver refers to as “API changes” would rather be
> important CLI/API changes.
>
> Thoughts?

I spoke of version numbers, but what I really meant to say is that for
1.0 and beyond we should clearly set expectations regarding stability.
By properly setting expectations, we can avoid surprises and improve the
experience for people using Guix, especially people trying Guix for the
first time.  The version number scheme is just one aspect of that.

I'm not advocating that we change anything; I'm only advocating that we
should make our stability promise (if any) clear by documenting it.  If
you want to know my thoughts about what sort of stability promise we
should provide, I'd be happy to talk about that also, but here I'm only
saying that we should provide a promise.  The details of the promise are
less important.

If you agree, then perhaps we can proceed along the following lines:

1) Discuss what our stability promise should be.  It might be that we
   decide to simply stick with the status quo and document it.  But
   whatever the result, it should be something that hopefully everyone
   agrees on (especially maintainers and contributors).

2) Document it.  Put it on the website, in the manual, etc.

3) Follow it.  Mention it in the Contributing section of the manual, the
   README, etc., and require people to adhere to it when making changes.

As a maintainer, what do you think?  Does it makes sense for the Guix
project to set expectations by documenting our stability promise?

-- 
Chris

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

Re: Roadmap for Guix 1.0

[Ricardo Wurmus]

Hi Chris,

> I'm not advocating that we change anything; I'm only advocating that we
> should make our stability promise (if any) clear by documenting it.  If
> you want to know my thoughts about what sort of stability promise we
> should provide, I'd be happy to talk about that also, but here I'm only
> saying that we should provide a promise.  The details of the promise are
> less important.
>
> If you agree, then perhaps we can proceed along the following lines:
>
> 1) Discuss what our stability promise should be.  It might be that we
>    decide to simply stick with the status quo and document it.  But
>    whatever the result, it should be something that hopefully everyone
>    agrees on (especially maintainers and contributors).
>
> 2) Document it.  Put it on the website, in the manual, etc.
>
> 3) Follow it.  Mention it in the Contributing section of the manual, the
>    README, etc., and require people to adhere to it when making changes.
>
> As a maintainer, what do you think?  Does it makes sense for the Guix
> project to set expectations by documenting our stability promise?

This is difficult.  The version jump signalizes that Guix is ready for
“productive” use; it really merely adjusts the version number in
accordance with how the community has been using Guix.

I’d be wary of putting something more than that in writing.  1.0 means
“this works pretty well” and “you shouldn’t expect sudden large changes
to how this works”.

I’d like to leave the discussion of a stability promise to a time when
we decide to maintain a “stable” branch.  The other kind of stability
applies only to using Guix as a library, which I don’t think is a very
popular use outside of Guix itself.

--
Ricardo

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

Hello everyone,

On 2018-07-29 17:18, ludo@gnu.org wrote:
> Hello Guix!
> 
> I’ve pushed to guix/maintenance.git a list of things that IMO we should
> do or might want to do for 1.0, with the understanding that 1.0 should
> happen in 2018 (or early 2019 at the latest!).  :-)
> 
>   
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
> 

I see no mention of containers. What is the status and goal about that 
subject?


-- 
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: Roadmap for Guix 1.0

[Ricardo Wurmus]

Amirouche Boubekki <amirouche@hypermove.net> writes:

>> I’ve pushed to guix/maintenance.git a list of things that IMO we should
>> do or might want to do for 1.0, with the understanding that 1.0 should
>> happen in 2018 (or early 2019 at the latest!).  :-)
>>
>>   https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
>>
>
> I see no mention of containers. What is the status and goal about that
> subject?

What feature regarding containers would you like to know more about?

“guix environment”, for example, supports isolation through container
features.

--
Ricardo

Re: Roadmap for Guix 1.0

[Amirouche Boubekki]

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

Le lun. 20 août 2018 à 09:45, Ricardo Wurmus <rekado@elephly.net> a écrit :

>
> Amirouche Boubekki <amirouche@hypermove.net> writes:
>
> >> I’ve pushed to guix/maintenance.git a list of things that IMO we should
> >> do or might want to do for 1.0, with the understanding that 1.0 should
> >> happen in 2018 (or early 2019 at the latest!).  :-)
> >>
> >>
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
> >>
> >
> > I see no mention of containers. What is the status and goal about that
> > subject?
>
> What feature regarding containers would you like to know more about?
>

Thanks for your reply. I use containers (via LXC) as lightweight Virtual
Machines
as such I can emulate my use of LXC with guix already using a VM.

The difference I see between guix containers and LXC is that in LXC the
container
has its own network device and an IP. What I usually do with LXC:

a) start the lxc container
b) ssh into it and

proceed as if I was in a Xen Virtuam Machine.


Have nice day!

>
> “guix environment”, for example, supports isolation through container
>

[-- Attachment #2: Type: text/html, Size: 1957 bytes --]

Re: Roadmap for Guix 1.0

[fis trivial]

Ludovic Courtès writes:

> Hello Guix!
>
> I’ve pushed to guix/maintenance.git a list of things that IMO we should
> do or might want to do for 1.0, with the understanding that 1.0 should
> happen in 2018 (or early 2019 at the latest!).  :-)
>
>   https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
>
> The list focuses on “big item” features and tasks, omitting routine bug
> fixes and improvements.  Some of these items don’t require a lot of work
> or expertise though, so hopefully there’s enough on everyone’s plate.
>
> Feel free to comment, volunteer, add items (but not too many!), remove
> items, promote items, etc.  Committers should feel free to edit the file
> directly in maintenance.git, especially to mark things as done.  ;-)
>
> Copy of the file attached below.
>
> Ludo’.
>
> PS: I’m starting the discussion but will go AFK soon after sending this
>     message.  :-)

Hi Ludovic,

For near future version of GUIX, maybe 1.1, would it be possible to:

    Upgrade to latest GCC as base compiler

    Use gold linker as default

Based on experience, newer GCC and gold linker could reduce compilation time
and memory requirement dramatically.  It would be beneficial to both build
farm which have heavy load and laptop users who have very limited memory.

Thanks.
-- 
Jiaming

Re: Roadmap for Guix 1.0

[Adam Van Ymeren]

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

Kinda late to the party here but I think a goal for 1.0 should be to ensure every  single package builds on x86_64 and/or i686 and that most substitutes are available at the time of release.

Having guix claim to have packages which then fail to build can leave a poor first impression.  It's fine for alpha/beta but I think it will be really important for 1.0 to feel as robust as possible.

I'd even say that any packages which don't build for 1.0 should be deleted or at least hidden. Maybe of channels happen we could use a stable vs unstable channels.

That's my 2 cents on 1.0 at least.

On September 4, 2018 6:55:57 PM EDT, fis trivial <ybbs.daans@hotmail.com> wrote:
>
>Ludovic Courtès writes:
>
>> Hello Guix!
>>
>> I’ve pushed to guix/maintenance.git a list of things that IMO we
>should
>> do or might want to do for 1.0, with the understanding that 1.0
>should
>> happen in 2018 (or early 2019 at the latest!).  :-)
>>
>>  
>https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/1.0.org
>>
>> The list focuses on “big item” features and tasks, omitting routine
>bug
>> fixes and improvements.  Some of these items don’t require a lot of
>work
>> or expertise though, so hopefully there’s enough on everyone’s plate.
>>
>> Feel free to comment, volunteer, add items (but not too many!),
>remove
>> items, promote items, etc.  Committers should feel free to edit the
>file
>> directly in maintenance.git, especially to mark things as done.  ;-)
>>
>> Copy of the file attached below.
>>
>> Ludo’.
>>
>> PS: I’m starting the discussion but will go AFK soon after sending
>this
>>     message.  :-)
>
>Hi Ludovic,
>
>For near future version of GUIX, maybe 1.1, would it be possible to:
>
>    Upgrade to latest GCC as base compiler
>
>    Use gold linker as default
>
>Based on experience, newer GCC and gold linker could reduce compilation
>time
>and memory requirement dramatically.  It would be beneficial to both
>build
>farm which have heavy load and laptop users who have very limited
>memory.
>
>Thanks.
>-- 
>Jiaming

[-- Attachment #2: Type: text/html, Size: 2601 bytes --]