all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Roadmap for Guix 1.0
@ 2018-07-29 15:18 Ludovic Courtès
  2018-07-30  1:23 ` Pjotr Prins
                   ` (3 more replies)
  0 siblings, 4 replies; 34+ messages in thread
From: Ludovic Courtès @ 2018-07-29 15:18 UTC (permalink / raw)
  To: guix-devel


[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès
@ 2018-07-30  1:23 ` Pjotr Prins
  2018-07-30  9:02   ` Nils Gillmann
  2018-08-29 16:12   ` Roadmap for Guix 1.0 Amirouche Boubekki
  2018-07-30  5:08 ` Chris Marusich
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 34+ messages in thread
From: Pjotr Prins @ 2018-07-30  1:23 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès
  2018-07-30  1:23 ` Pjotr Prins
@ 2018-07-30  5:08 ` Chris Marusich
  2018-07-30  7:33   ` Pierre Neidhardt
  2018-08-19 11:11   ` Ludovic Courtès
  2018-08-19 21:52 ` Amirouche Boubekki
  2018-09-04 22:55 ` fis trivial
  3 siblings, 2 replies; 34+ messages in thread
From: Chris Marusich @ 2018-07-30  5:08 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-30  5:08 ` Chris Marusich
@ 2018-07-30  7:33   ` Pierre Neidhardt
  2018-08-19 11:19     ` Ludovic Courtès
  2018-08-19 11:11   ` Ludovic Courtès
  1 sibling, 1 reply; 34+ messages in thread
From: Pierre Neidhardt @ 2018-07-30  7:33 UTC (permalink / raw)
  To: Chris Marusich; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-30  1:23 ` Pjotr Prins
@ 2018-07-30  9:02   ` Nils Gillmann
  2018-07-30 12:47     ` Pierre Neidhardt
  2018-08-29 16:12   ` Roadmap for Guix 1.0 Amirouche Boubekki
  1 sibling, 1 reply; 34+ messages in thread
From: Nils Gillmann @ 2018-07-30  9:02 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-30  9:02   ` Nils Gillmann
@ 2018-07-30 12:47     ` Pierre Neidhardt
  2018-08-19 11:06       ` LVM support Ludovic Courtès
  0 siblings, 1 reply; 34+ messages in thread
From: Pierre Neidhardt @ 2018-07-30 12:47 UTC (permalink / raw)
  To: Nils Gillmann; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* LVM support
  2018-07-30 12:47     ` Pierre Neidhardt
@ 2018-08-19 11:06       ` Ludovic Courtès
  0 siblings, 0 replies; 34+ messages in thread
From: Ludovic Courtès @ 2018-08-19 11:06 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel, Nils Gillmann

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-30  5:08 ` Chris Marusich
  2018-07-30  7:33   ` Pierre Neidhardt
@ 2018-08-19 11:11   ` Ludovic Courtès
  2018-08-20  1:12     ` Chris Marusich
  1 sibling, 1 reply; 34+ messages in thread
From: Ludovic Courtès @ 2018-08-19 11:11 UTC (permalink / raw)
  To: Chris Marusich; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-30  7:33   ` Pierre Neidhardt
@ 2018-08-19 11:19     ` Ludovic Courtès
  0 siblings, 0 replies; 34+ messages in thread
From: Ludovic Courtès @ 2018-08-19 11:19 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès
  2018-07-30  1:23 ` Pjotr Prins
  2018-07-30  5:08 ` Chris Marusich
@ 2018-08-19 21:52 ` Amirouche Boubekki
  2018-08-20  7:44   ` Ricardo Wurmus
  2018-09-04 22:55 ` fis trivial
  3 siblings, 1 reply; 34+ messages in thread
From: Amirouche Boubekki @ 2018-08-19 21:52 UTC (permalink / raw)
  To: ludo; +Cc: guix-devel, Guix-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-19 11:11   ` Ludovic Courtès
@ 2018-08-20  1:12     ` Chris Marusich
  2018-08-30 19:34       ` Ricardo Wurmus
  0 siblings, 1 reply; 34+ messages in thread
From: Chris Marusich @ 2018-08-20  1:12 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-19 21:52 ` Amirouche Boubekki
@ 2018-08-20  7:44   ` Ricardo Wurmus
  2018-08-29 16:05     ` Amirouche Boubekki
  0 siblings, 1 reply; 34+ messages in thread
From: Ricardo Wurmus @ 2018-08-20  7:44 UTC (permalink / raw)
  To: Amirouche Boubekki; +Cc: guix-devel, Guix-devel


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-20  7:44   ` Ricardo Wurmus
@ 2018-08-29 16:05     ` Amirouche Boubekki
  0 siblings, 0 replies; 34+ messages in thread
From: Amirouche Boubekki @ 2018-08-29 16:05 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, guix-devel-bounces+amirouche=hypermove.net

[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-30  1:23 ` Pjotr Prins
  2018-07-30  9:02   ` Nils Gillmann
@ 2018-08-29 16:12   ` Amirouche Boubekki
  2018-08-30 11:46     ` Pierre Neidhardt
  1 sibling, 1 reply; 34+ messages in thread
From: Amirouche Boubekki @ 2018-08-29 16:12 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: guix-devel, Guix-devel


"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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-29 16:12   ` Roadmap for Guix 1.0 Amirouche Boubekki
@ 2018-08-30 11:46     ` Pierre Neidhardt
  2018-08-30 12:04       ` Ludovic Courtès
  2018-08-30 21:45       ` Taylan Kammer
  0 siblings, 2 replies; 34+ messages in thread
From: Pierre Neidhardt @ 2018-08-30 11:46 UTC (permalink / raw)
  To: Amirouche Boubekki; +Cc: guix-devel, Guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 11:46     ` Pierre Neidhardt
@ 2018-08-30 12:04       ` Ludovic Courtès
  2018-08-30 12:57         ` Ricardo Wurmus
                           ` (3 more replies)
  2018-08-30 21:45       ` Taylan Kammer
  1 sibling, 4 replies; 34+ messages in thread
From: Ludovic Courtès @ 2018-08-30 12:04 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel, Guix-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 12:04       ` Ludovic Courtès
@ 2018-08-30 12:57         ` Ricardo Wurmus
  2018-08-30 14:20           ` Tobias Geerinckx-Rice
  2018-08-30 19:13           ` George Clemmer
  2018-08-30 15:36         ` George Clemmer
                           ` (2 subsequent siblings)
  3 siblings, 2 replies; 34+ messages in thread
From: Ricardo Wurmus @ 2018-08-30 12:57 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Guix-devel


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 12:57         ` Ricardo Wurmus
@ 2018-08-30 14:20           ` Tobias Geerinckx-Rice
  2018-08-30 15:17             ` Nils Gillmann
  2018-08-30 19:13           ` George Clemmer
  1 sibling, 1 reply; 34+ messages in thread
From: Tobias Geerinckx-Rice @ 2018-08-30 14:20 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Guix-devel

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 14:20           ` Tobias Geerinckx-Rice
@ 2018-08-30 15:17             ` Nils Gillmann
  0 siblings, 0 replies; 34+ messages in thread
From: Nils Gillmann @ 2018-08-30 15:17 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: guix-devel, Guix-devel

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 12:04       ` Ludovic Courtès
  2018-08-30 12:57         ` Ricardo Wurmus
@ 2018-08-30 15:36         ` George Clemmer
  2018-08-30 17:11         ` Hartmut Goebel
  2018-08-30 18:17         ` Jan Nieuwenhuizen
  3 siblings, 0 replies; 34+ messages in thread
From: George Clemmer @ 2018-08-30 15:36 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Guix-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 12:04       ` Ludovic Courtès
  2018-08-30 12:57         ` Ricardo Wurmus
  2018-08-30 15:36         ` George Clemmer
@ 2018-08-30 17:11         ` Hartmut Goebel
  2018-08-30 18:17         ` Jan Nieuwenhuizen
  3 siblings, 0 replies; 34+ messages in thread
From: Hartmut Goebel @ 2018-08-30 17:11 UTC (permalink / raw)
  To: guix-devel

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 |

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 12:04       ` Ludovic Courtès
                           ` (2 preceding siblings ...)
  2018-08-30 17:11         ` Hartmut Goebel
@ 2018-08-30 18:17         ` Jan Nieuwenhuizen
  3 siblings, 0 replies; 34+ messages in thread
From: Jan Nieuwenhuizen @ 2018-08-30 18:17 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Guix-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 12:57         ` Ricardo Wurmus
  2018-08-30 14:20           ` Tobias Geerinckx-Rice
@ 2018-08-30 19:13           ` George Clemmer
  2018-08-30 20:12             ` Gábor Boskovits
  1 sibling, 1 reply; 34+ messages in thread
From: George Clemmer @ 2018-08-30 19:13 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Guix-devel


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-20  1:12     ` Chris Marusich
@ 2018-08-30 19:34       ` Ricardo Wurmus
  0 siblings, 0 replies; 34+ messages in thread
From: Ricardo Wurmus @ 2018-08-30 19:34 UTC (permalink / raw)
  To: Chris Marusich; +Cc: guix-devel


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 19:13           ` George Clemmer
@ 2018-08-30 20:12             ` Gábor Boskovits
  2018-08-31 14:25               ` George Clemmer
  0 siblings, 1 reply; 34+ messages in thread
From: Gábor Boskovits @ 2018-08-30 20:12 UTC (permalink / raw)
  To: myglc2; +Cc: Guix-devel, guix-devel-bounces+amirouche=hypermove.net

[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 11:46     ` Pierre Neidhardt
  2018-08-30 12:04       ` Ludovic Courtès
@ 2018-08-30 21:45       ` Taylan Kammer
  1 sibling, 0 replies; 34+ messages in thread
From: Taylan Kammer @ 2018-08-30 21:45 UTC (permalink / raw)
  To: Pierre Neidhardt; +Cc: guix-devel, Guix-devel

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-30 20:12             ` Gábor Boskovits
@ 2018-08-31 14:25               ` George Clemmer
  2018-08-31 15:45                 ` Vincent Legoll
  0 siblings, 1 reply; 34+ messages in thread
From: George Clemmer @ 2018-08-31 14:25 UTC (permalink / raw)
  To: Gábor Boskovits
  Cc: Guix-devel, guix-devel-bounces+amirouche=hypermove.net


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-31 14:25               ` George Clemmer
@ 2018-08-31 15:45                 ` Vincent Legoll
  2018-08-31 15:54                   ` Amirouche Boubekki
  0 siblings, 1 reply; 34+ messages in thread
From: Vincent Legoll @ 2018-08-31 15:45 UTC (permalink / raw)
  To: myglc2; +Cc: guix-devel, guix-devel-bounces+amirouche=hypermove.net

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-31 15:45                 ` Vincent Legoll
@ 2018-08-31 15:54                   ` Amirouche Boubekki
  2018-09-01  7:36                     ` rchar01
  0 siblings, 1 reply; 34+ messages in thread
From: Amirouche Boubekki @ 2018-08-31 15:54 UTC (permalink / raw)
  To: vincent.legoll
  Cc: guix-devel, guix-devel-bounces+amirouche=hypermove.net, myglc2

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-08-31 15:54                   ` Amirouche Boubekki
@ 2018-09-01  7:36                     ` rchar01
  2018-09-01  9:27                       ` Pjotr Prins
  0 siblings, 1 reply; 34+ messages in thread
From: rchar01 @ 2018-09-01  7:36 UTC (permalink / raw)
  To: guix-devel@gnu.org; +Cc: myglc2@gmail.com

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-09-01  7:36                     ` rchar01
@ 2018-09-01  9:27                       ` Pjotr Prins
  2018-09-01 10:09                         ` Nils Gillmann
  0 siblings, 1 reply; 34+ messages in thread
From: Pjotr Prins @ 2018-09-01  9:27 UTC (permalink / raw)
  To: rchar01; +Cc: guix-devel@gnu.org, myglc2@gmail.com

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-09-01  9:27                       ` Pjotr Prins
@ 2018-09-01 10:09                         ` Nils Gillmann
  0 siblings, 0 replies; 34+ messages in thread
From: Nils Gillmann @ 2018-09-01 10:09 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: guix-devel@gnu.org, myglc2@gmail.com

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès
                   ` (2 preceding siblings ...)
  2018-08-19 21:52 ` Amirouche Boubekki
@ 2018-09-04 22:55 ` fis trivial
  2018-09-04 23:09   ` Adam Van Ymeren
  3 siblings, 1 reply; 34+ messages in thread
From: fis trivial @ 2018-09-04 22:55 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel@gnu.org


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Roadmap for Guix 1.0
  2018-09-04 22:55 ` fis trivial
@ 2018-09-04 23:09   ` Adam Van Ymeren
  0 siblings, 0 replies; 34+ messages in thread
From: Adam Van Ymeren @ 2018-09-04 23:09 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel@gnu.org

[-- 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 --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2018-09-04 23:09 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-07-29 15:18 Roadmap for Guix 1.0 Ludovic Courtès
2018-07-30  1:23 ` Pjotr Prins
2018-07-30  9:02   ` Nils Gillmann
2018-07-30 12:47     ` Pierre Neidhardt
2018-08-19 11:06       ` LVM support Ludovic Courtès
2018-08-29 16:12   ` Roadmap for Guix 1.0 Amirouche Boubekki
2018-08-30 11:46     ` Pierre Neidhardt
2018-08-30 12:04       ` Ludovic Courtès
2018-08-30 12:57         ` Ricardo Wurmus
2018-08-30 14:20           ` Tobias Geerinckx-Rice
2018-08-30 15:17             ` Nils Gillmann
2018-08-30 19:13           ` George Clemmer
2018-08-30 20:12             ` Gábor Boskovits
2018-08-31 14:25               ` George Clemmer
2018-08-31 15:45                 ` Vincent Legoll
2018-08-31 15:54                   ` Amirouche Boubekki
2018-09-01  7:36                     ` rchar01
2018-09-01  9:27                       ` Pjotr Prins
2018-09-01 10:09                         ` Nils Gillmann
2018-08-30 15:36         ` George Clemmer
2018-08-30 17:11         ` Hartmut Goebel
2018-08-30 18:17         ` Jan Nieuwenhuizen
2018-08-30 21:45       ` Taylan Kammer
2018-07-30  5:08 ` Chris Marusich
2018-07-30  7:33   ` Pierre Neidhardt
2018-08-19 11:19     ` Ludovic Courtès
2018-08-19 11:11   ` Ludovic Courtès
2018-08-20  1:12     ` Chris Marusich
2018-08-30 19:34       ` Ricardo Wurmus
2018-08-19 21:52 ` Amirouche Boubekki
2018-08-20  7:44   ` Ricardo Wurmus
2018-08-29 16:05     ` Amirouche Boubekki
2018-09-04 22:55 ` fis trivial
2018-09-04 23:09   ` Adam Van Ymeren

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.