1.5.0 release?

1.5.0 release?

[Greg Hogan]

Hi Guix,

With the recent core-updates merge, and as the master branch
stabilizes, is there a plan or desire for a 1.5.0 release?

It has been 20 months since the 1.4.0 release, which is already more
than the previously longest interval (18 months for v1.4.0). 2023 was
the first year without a release since the project was started.

This seems to be the ideal time to create new installation artifacts
(shortly after base packages have been updated) so as to reduce the
number and size of packages to be replaced post-installation.

Greg

Re: 1.5.0 release?

[Ludovic Courtès]

Hi Greg,

Greg Hogan <code@greghogan.com> skribis:

> With the recent core-updates merge, and as the master branch
> stabilizes, is there a plan or desire for a 1.5.0 release?

Desire, definitely; plan? we have to come up with one.

I think there should be a team of ~4 volunteers who can commit to focus
on it for, say, 2–5 months¹ (the shorter the better, but we have to
prepare for extra time).

Since I was involved in previous releases, I would be happy to help and
mentor when needed (as an outsider), but I think leadership and
coordination of this effort should come from other community members.

An important skill required here is the ability to keep track of what
needs to be done, what is outside of that scope, coordinating the work
of individuals, and regularly communicating progress with the broader
community.  Regular communication is what will allow people to help in
areas they’re familiar with.

I know there are people who’d do a great job on that coordination part
and people who’d be great on the more technical side of things.

Thoughts? Volunteers?

Ludo’.

¹ This has been discussed several times over the past few years.  NixOS
  has had dedicated release teams for a while: each team is a small
  group of people that focuses on one release for a few months, and then
  passes on the torch to another group.  Rotation is important.

Re: 1.5.0 release?

[Greg Hogan]

On Fri, Sep 6, 2024 at 5:32 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hi Greg,
>
> Greg Hogan <code@greghogan.com> skribis:
>
> > With the recent core-updates merge, and as the master branch
> > stabilizes, is there a plan or desire for a 1.5.0 release?
>
> Desire, definitely; plan? we have to come up with one.
>
> I think there should be a team of ~4 volunteers who can commit to focus
> on it for, say, 2–5 months¹ (the shorter the better, but we have to
> prepare for extra time).

That seems like a lengthy time to roll some release artifacts. Is the
remaining effort to fix failing builds?

With Guix embracing the chaos of rolling releases, and a presumption
that users will `guix pull` soon after installation, I count only
three motivations to tag a new release: 1) replacing an old release
with an outdated Guix unable to self update, 2) security fixes for
installation packages so as not to be immediately pwned, and 3)
minimizing the number of replacement installation packages (especially
after core packages updates).

Whether the remainder of the packages are available or even buildable
at release seems inconsequential, since without release branches or
backported security fixes all Guix systems should be kept up-to-date.
We do need "quality control", but on a continuing basis rather than at
particular points in time.

I believe other distributions the size of Guix have some version of
package "ownership" (responsibility), which both reduces duplicated
effort and when lacking informs deprecation and removal of the
package. Guix teams is coarse, both in subsetting packages and
contributors.

Greg

Re: 1.5.0 release?

[Giacomo]

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

Hi Greg, Ludo', 

I think 5 months are a long but not unbelieveable amount of time, especially if the team has to be onboarded in that time frame as well.

I work for my dayjob as Release Engineer at a company that makes another Linux distribution, so I happen to have an idea of some of the necessary task around releases, never did in Guix context but I'd be willing to learn anything required.

If a team is formed I would love to participate in Guix 1.5 release, for sure I don't think I can lead it but if I my work can help increase the bus factor please count me in.

Cheers,

giacomo

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

Re: 1.5.0 release?

[Ludovic Courtès]

Hi Greg,

Greg Hogan <code@greghogan.com> skribis:

> On Fri, Sep 6, 2024 at 5:32 AM Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> I think there should be a team of ~4 volunteers who can commit to focus
>> on it for, say, 2–5 months¹ (the shorter the better, but we have to
>> prepare for extra time).
>
> That seems like a lengthy time to roll some release artifacts. Is the
> remaining effort to fix failing builds?

Fixing failing builds, but more importantly fixing issues with the
installer, which receives little attention during the rest of the time.

[...]

> Whether the remainder of the packages are available or even buildable
> at release seems inconsequential, since without release branches or
> backported security fixes all Guix systems should be kept up-to-date.
> We do need "quality control", but on a continuing basis rather than at
> particular points in time.

I agree.  In practice, we need to make sure that things like desktop
environments that the installer lets you choose and actually
buildable/installable/working in that release.

But yes, we should keep it the scope of the release work as reduced as
possible like you say.  If we can get it done in a few weeks rather than
the 2–5 months I talk about, that’s great.

What matters anyhow is to have a small group of people with a clear list
of things to address before they tag the release and upload the
artifacts.

> I believe other distributions the size of Guix have some version of
> package "ownership" (responsibility), which both reduces duplicated
> effort and when lacking informs deprecation and removal of the
> package. Guix teams is coarse, both in subsetting packages and
> contributors.

Guix chose to not have package ownership.  Package ownerships has pros
and cons, and historically we chose to go for collective ownership.

But anyway, I think this is mostly a separate topic.

Thanks!

Ludo’.

Re: 1.5.0 release?

[Denis 'GNUtoo' Carikli]

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

On Tue, 10 Sep 2024 18:21:17 -0400
Greg Hogan <code@greghogan.com> wrote:

> With Guix embracing the chaos of rolling releases, and a presumption
> that users will `guix pull` soon after installation, I count only
> three motivations to tag a new release: 1) replacing an old release
> with an outdated Guix unable to self update, 2) security fixes for
> installation packages so as not to be immediately pwned, and 3)
> minimizing the number of replacement installation packages (especially
> after core packages updates).

There is also at least 1 project (GNU Boot, which I'm involved in) that
currently uses a released Guix version (Guix 1.4.0 for i686) to build
other software as the Guix manual for the latest release is easily
accessible and doesn't change much, so contributors can easily refer to
it.

It's not a big issue to workaround some things on top of a release but
if a complete language that we use is missing that creates a lot of
complications for us.

Bitcoin can also use Guix to build things but they seem to use an
arbitrary revision not based on any releases (guix 1.3 with lots of
commits on top). I've no idea if there are many other projects that
reuse Guix fixed revisions.

Another thing that may be relevant (not related to projects I'm
involved in) could be to somehow validate if all the architectures
supported by Guix work fine and maybe get important packages working on
them. Though note that I'm not a Guix maintainer and I don't have
commit access, so I can't participate in decisions on what is important
or not.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]