Subject: Re: GCD005: Regular and efficient releases

From: Efraim Flashner <[email-masked]>
Date: Mon, 12 May 2025 20:28:08 +0300

On Mon, May 12, 2025 at 01:11:15PM -0400, Greg Hogan wrote:
> On Mon, May 12, 2025 at 12:23 PM Rutherther <[email-masked]> wrote:
> >
> > Hi Greg,
> >
> > Greg Hogan <[email-masked]> writes:
> >
> > > On Fri, May 9, 2025 at 5:55 PM Steve George <[email-masked]> wrote:
> > >>
> > >> I hope the initial user experience wouldn't be to "break on the user's first pull", since with annual releases we wouldn't have release artefacts that are 2.5 years out of date. And, we'd also degraft regularly which would be beneficial for all users.
> > >>
> > >> As you can tell I would _love_ us to be able to have a slower moving branch, but purposefully have kept the GCD more limited. For now focusing on the step forward of regular releases.
> > >
> > > I have not updated a 2.5+ year old Guix system, but what is the issue
> > > here? How is this any different from updating a week old system? If
> > > the archive contains broken packages then the user upgrade experience
> > > will fail just the same. And clearing the archive of broken packages
> > > also breaks user manifests!
> >
> > There isn't an issue as long as you use substitutes. But if you decided
> > you won't, then there is an issue currently. Specifically there is a
> > misbehaving mirror crysys.hu that returns 200, but returns page not
> > found html page. That means packages like gnutls aren't building. For
> > people that are installing Guix from their system's package manager,
> > they will get hit by this unless they actively activate the substitutes.
> >
> > This points to a more general problem that can be happening in the
> > future, it can be misbehaving mirrors or pages that aren't handled well
> > by Guix and lead to non-buildable software. As long as pages behave as
> > they should, everything should be fine, ie. SWH gets triggered on
> > missing repositories, subsequent mirror urls are used, etc. But
> > misbehaving pages are always going to cause issues.
> 
> So for the (small?) subset of users (myself included) who do not
> enable substitutes, then for the small set of packages provided
> pre-built with the installation ...
> 
> >> guix depends on gnutls
> [email-masked]
> [email-masked]
> [email-masked]
> 
> Can we not retry mirrors on checksum mismatch? And differentiate
> between binary substitutes and sources? The latter are strongly hashed
> and therefore no different from patches or the package code itself.
> Does use of SWH require substitutes to be enabled?

SWH doesn't require substitutes to be enabled, they only serve source
files.

> > Apart from that there has been a mistake made in generation of the 1.4.0
> > iso, the iso has used a local channel url, /home/ludo/..., so now if you
> > install from the iso, your system will have this path in the
> > channels.scm provenance file. Then if you do not pull at all, but
> > reconfigure right away, you will get an error that /home/ludo/... is not
> > found. That is because of the forward update check that is going to try
> > to check if your current commit is descendant of the previous one.
> > (I think that the check should have a way to abort early if no
> > commits have changed btw)
> > Mistakes like that will probably be happening with new releases
> > as well. Though this one should be impossible already - the url is going
> > to be replaced in the operating-system from install.scm.
> >
> > The more releases the faster issues like this can get resolved, and not
> > confuse the users.
> 
> I think we should release more often (multiple times per year) and
> also add checks like building  release artifacts and bootstrapping
> systems with clocks set into the future to detect another major
> annoyance: timebombs. Anything which can be automated.

These are still things that we can do.  I hope that any manual parts of
the release process we can identify and automate going forward,
including making sure any package or service we offer from the installer
actually builds.

> > Regards
> > Rutherther

-- 
Efraim Flashner   <[email-masked]>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted