Guix minor version update?

Guix minor version update?

[zimoun]

Dear,

Currently, the proposed Guix to install is v1.0.1. This very version
has some "bugs" [1] fixed since then [2]. But it is not convenient
when using with Docker [3].

Why not update the minor version to v1.1?

Then, I propose to update this minor version:
 - each time core-updates or staging is merged
 - each time the bootstrapping toolchain is updated
 - each time major archives (Bioconductor) is updated
 - each time CLI is improved (time-machine, etc.)


Ludo "disagrees" [4], kind of. ;-)
<<
I guess semver doesn’t apply to Guix taken as a whole, so version
numbers should be chosen to suggest how “different” the new release is.
That’s pretty subjective, though.
>>

Let collect some ideas. :-)


Even if version is not really meaningful when speaking about Guix
because rolling etc. I find useful to bump the minor version more
often, IMHO, for 3 reasons:

 1. Changing the (minor) version attracts interest and increases visibility.
 2. It helps people --mainly HPC sysadmins-- to better trust "Guix
rocks!" because jumping from version to version fits more what they
know.
 3. It eases to navigate through all the packages and their version update.


What people think?

All the best,
simon


[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00540.html
[2] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c20ba18304ee63f01895f092bb51bc2a9ce3303b
[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195
[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195#25

Re: Guix minor version update?

[Pierre Neidhardt]

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

Agreed!  This would be really appreciated!

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

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

Re: Guix minor version update?

[Julien Lepiller]

Le 21 janvier 2020 08:32:00 GMT-05:00, zimoun <zimon.toutoune@gmail.com> a écrit :
>Dear,
>
>Currently, the proposed Guix to install is v1.0.1. This very version
>has some "bugs" [1] fixed since then [2]. But it is not convenient
>when using with Docker [3].
>
>Why not update the minor version to v1.1?
>
>Then, I propose to update this minor version:
> - each time core-updates or staging is merged
> - each time the bootstrapping toolchain is updated
> - each time major archives (Bioconductor) is updated
> - each time CLI is improved (time-machine, etc.)
>
>
>Ludo "disagrees" [4], kind of. ;-)
><<
>I guess semver doesn’t apply to Guix taken as a whole, so version
>numbers should be chosen to suggest how “different” the new release is.
>That’s pretty subjective, though.
>>>
>
>Let collect some ideas. :-)
>
>
>Even if version is not really meaningful when speaking about Guix
>because rolling etc. I find useful to bump the minor version more
>often, IMHO, for 3 reasons:
>
>1. Changing the (minor) version attracts interest and increases
>visibility.
> 2. It helps people --mainly HPC sysadmins-- to better trust "Guix
>rocks!" because jumping from version to version fits more what they
>know.
>3. It eases to navigate through all the packages and their version
>update.
>
>
>What people think?
>
>All the best,
>simon
>
>
>[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00540.html
>[2]
>https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c20ba18304ee63f01895f092bb51bc2a9ce3303b
>[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195
>[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195#25

I agree releases are too far apart, when we have all of these new things to show off to newcomers :)

Your proposed release cycle seems too short for me, especially since a release is a huge drain on our resources (we try to freeze the distro, fix packages, make sure we retain substitutes for that version "forever", …).

We should definitely keep releases far from core-updates merges and co. That would ensure we have time to fix the aftermath.

Re: Guix minor version update?

[Bengt Richter]

Hi,

On +2020-01-21 12:43:26 -0500, Julien Lepiller wrote:
> Le 21 janvier 2020 08:32:00 GMT-05:00, zimoun <zimon.toutoune@gmail.com> a écrit :
> >Dear,
> >
> >Currently, the proposed Guix to install is v1.0.1. This very version
> >has some "bugs" [1] fixed since then [2]. But it is not convenient
> >when using with Docker [3].
> >
> >Why not update the minor version to v1.1?
> >
> >Then, I propose to update this minor version:
> > - each time core-updates or staging is merged
> > - each time the bootstrapping toolchain is updated
> > - each time major archives (Bioconductor) is updated
> > - each time CLI is improved (time-machine, etc.)
> >
> >
> >Ludo "disagrees" [4], kind of. ;-)
> ><<
> >I guess semver doesn’t apply to Guix taken as a whole, so version
> >numbers should be chosen to suggest how “different” the new release is.
> >That’s pretty subjective, though.
> >>>
> >
> >Let collect some ideas. :-)
> >
> >
> >Even if version is not really meaningful when speaking about Guix
> >because rolling etc. I find useful to bump the minor version more
> >often, IMHO, for 3 reasons:
> >
> >1. Changing the (minor) version attracts interest and increases
> >visibility.
> > 2. It helps people --mainly HPC sysadmins-- to better trust "Guix
> >rocks!" because jumping from version to version fits more what they
> >know.
> >3. It eases to navigate through all the packages and their version
> >update.
> >
> >
> >What people think?
> >
> >All the best,
> >simon
> >
> >
> >[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00540.html
> >[2]
> >https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c20ba18304ee63f01895f092bb51bc2a9ce3303b
> >[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195
> >[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39195#25
> 
> I agree releases are too far apart, when we have all of these new things to show off to newcomers :)
> 
> Your proposed release cycle seems too short for me, especially since a release is a huge drain on our resources (we try to freeze the distro, fix packages, make sure we retain substitutes for that version "forever", …).
> 
> We should definitely keep releases far from core-updates merges and co. That would ensure we have time to fix the aftermath.
>

BF: How about generating a minimal "guix-maint" release as a binary-installable
guix (guix-maint-install.sh ?) which would install a minimal /gnu/store
like guix-install.sh if no existing /gnu/store, _but either way_ would install
guix-maint as a new generation of guix-maint in its own profile.

The idea is to be able to load a safe minimal and quality-controlled-up-to-date
seed environment (mes-derived?) which can be invoked as a base
for first-time install or later for maintenance or experimentation.

Maybe it could be a safe-mode boot option from grub, to run as something
selected from minimal profile alternatives?

HTH trigger some useful ideas,
even if this is ignorant newbie rambling :)

-- 
Regards,
Bengt Richter

Re: Guix minor version update?

[Ludovic Courtès]

Hi!

Julien Lepiller <julien@lepiller.eu> skribis:

> I agree releases are too far apart, when we have all of these new
> things to show off to newcomers :)

Agreed!

I think we really need someone to pay attention to the schedule.  It’s
too hard for me and I guess for many of us to, at the same time, hack on
new things, and sit down to prepare a release, which is often somewhat
exciting.

I also think we should rotate release responsibilities.  We’ve improved
the process and its documentation in the past, but I’m sure we can still
do better.

I’d encourage people to look at
<https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org>
and see if they can make a release with that info, and while doing it,
take note of things to improve.

Thanks,
Ludo’.

Re: Guix minor version update?

[Jonathan Frederickson]

As someone who just got a Pinebook Pro and is trying to use Guix on it, having more frequent minor releases sounds really nice, if only because it’s a longer-lived target and (I assume) would be more likely to have substitutes available than current master. Building things on ARM takes a long time!

Re: Guix minor version update?

[zimoun]

Hi Ludo,

On Thu, 23 Jan 2020 at 17:28, Ludovic Courtès <ludo@gnu.org> wrote:

> I think we really need someone to pay attention to the schedule.  It’s
> too hard for me and I guess for many of us to, at the same time, hack on
> new things, and sit down to prepare a release, which is often somewhat
> exciting.

Let engage a quick discussion at the Guix Days about that...

> I also think we should rotate release responsibilities.  We’ve improved
> the process and its documentation in the past, but I’m sure we can still
> do better.

...and that.


Because now Guix is becoming a piece of software \o/ and so more bugs
are opened than closed (no stats! :-)) then new features are touching
very different topics, we could imagine that 2-3 people take in charge
the release responsibilities because it would ease triage between what
is blocking and what is not.
Well, as usual, the difficult part is to bootstrap from scratch. ;-)
And the skills that are required are a bit abstract -- at least to me
-- so how to reach volunteers? :-)


Well, let talk at the Guix Days what could be done. :-)


Cheers,
simon

Re: Guix minor version update?

[Ludovic Courtès]

Hi!

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

> Currently, the proposed Guix to install is v1.0.1. This very version
> has some "bugs" [1] fixed since then [2]. But it is not convenient
> when using with Docker [3].
>
> Why not update the minor version to v1.1?

It’s definitely time for this, and I agree with the “1.1” number, FWIW.
:-)

However, I would really want to have good automated tests of the
installer before this happens:

  https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00225.html

Likewise, if someone could come up with a test for the binary tarball
installation on top of, say, Debian, that’d be great!  (Probably not a
blocker, but still helpful in giving more confidence about the release.)
Surely this could be done in QEMU with a dummy HTTP(S) proxy.

I’m sure there are other issues in the bug tracker that’d be worth
addressing.

Help welcome!

Ludo’.