[PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.

---

005-regular-releases.md | 449 ++++++++++++++++++++++++++++++++++++++++

1 file changed, 449 insertions(+)

create mode 100644 005-regular-releases.md

Hi all,

It's been ~2.5 years since the last Guix release, which led me to think we should do another one! Initially, I was just going to see if anyone wanted to create a release project. But, before I knew it I was writing a GCD! ...

Below you'll find a proposal for moving to a regular release cycle.

Thanks to Andreas Enge, Ludovic Courtès and Efraim Flashner for their initial comments and insights. They've agreed to sponsor it - which means they agree with the general direction (but not necessarily with all aspects), and will help to 'garden' the discussion to move us towards a consensus on whether it's a good proposal.

This is a **draft** submission so I look forward to your consideration of it, thoughts and comments.

Thanks,

Steve / Futurile

Steve George <steve@futurile.net> writes:

I think we may need to change the name. We used the name staging before

switching to the team-based process. If we reuse this name, it may cause

confusion for later users when searching for information.

On 9 May, Z572 wrote:

No problem, is there something you would favour?

If not, what about `next-master` to indicate that it's the next master? If we think that's too generic we could give it a time-based date `202509-next-master` - meaning it will be merged back in during September 2025.

Hi Steve,

thanks for this. I have a few notes left in the text, but generally I

like this.

I think the proposal is missing the version numbering that will be used,

like, let's say the releases are x.y.z, is y increased? Or should the

numbering going to be switched to something like yyyy.mm?

Also, should the GCD document what happens if something goes horribly

wrong after the release is made, ie. a new minor release created to

mitigate the issue?

Steve George <steve@futurile.net> writes:

The initial pull won't be faster, the pull is so slow because there is

no checkout and no commits checked for auth, not because the iso is so

old. No matter the age of iso, the full clone has to be made and authenticated.

If there was a checkout in the cache, it would be faster, the more up to

date it is, the faster the pull is. Additionally what would greatly

improve the experience is if this checkout has been copied to the

installed system.

But that's not related to the releases themselves, but to how the iso is made.

I think releases are also needed for other distro package managers to

update. While users are encouraged to use the guix-install.sh script,

some will end up installing with their system's package manager. Maybe

it would be good to mention that?

Is May smart if GNOME is to be targeted? I think NixOS really struggles

to make the GNOME updates in time. And there is less people working on

it on Guix as far as I know. Gnome is like two releases back? If we

wanted to include GNOME, wouldn't June make more sense to give an extra month?

Or for a better approach: is there a specific list of packages that

would be targeted so it can be used for the decision?

So total of 9 week freeze? Isn't that too long for users to not receive

those updates if they were ready?

I think that should be at least mentioned in the drawbacks, even if most

people won't consider it a major drawback, it sounds like a drawback to me.

But I suppose it will still be possible to commit those changes, you

just won't be able to switch the default toolchain. Though Rust, Python

etc. currently don't really support more than one version for building

other packages, at least not well.

What modules exactly, all? And what kind of alterations? I suppose some

changes will still be possible, like adding a new package or service,

no?

I think it doesn't make sense to completely block alterations to the

daemon, ie. if there was a bug or security issue.

So hypothetically, if a package/service worked on non-primary

architecture or one primary architecture, but not the other, it will be

removed, completely? That doesn't sound right. Am I misunderstanding

here? Where is the package removed from, the guix repository or just

from the package set that should be passing for the release?

Either way, like this it conflicts with the earlier 'packages and

services

Hello,

probably I should not reply quickly every time someone writes to this GCD

so as not to obstruct a healthy discussion :)

The timeline should probably be discussed and fixed to some concrete

values during the discussion period, as this is an important detail;

with a balance between moving quickly (very desirable) and what we can

effectively achieve. My fear is rather that the timeline is already

too ambitious :) Just to put things into perspective, we have a backlog

of team branches to be merged right now of about 3 months.

So then not merging to master for 5 weeks or so would almost not be

noticeable...

Andreas

On Fri, May 9, 2025 at 8:54 AM Steve George <steve@futurile.net> wrote:

[...]

[...]

This is a proposal for a beautiful release process. The process is

detailed and well thought out, but without stability these beautiful

releases quickly decay to our status quo. And I agree that we do not

have the capacity to maintain two branches (though it could solve our

naming issue).

1) It seems a waste to synchronize around a point-in-time beautiful

release only to have this break on the user's first pull. And builds

will quickly break when the freeze is lifted and the backlog

unblocked. The alternative to a pull is to forego security updates for

a year until the next release.

2) The project is currently unable to keep up with the teams workflow,

and now we are introducing an additional, quite long pause into the

calendar.

3) Package cleanup is a problem that I believe we are afraid to

address. I agree that we should not have package "ownership", but

perhaps "sponsorship" or (to borrow from this GCD) "advocate" with

notifications when builds break on CI. I believe this proposal is too

aggressive in pruning packages without considering alternatives (in

another GCD).

I think we should greatly reduce the scope and initially try (as I

noted in December buried in the "On the quest for a new release model"

discussion) creating a release team which would:

1) operate as any other team

2) be responsible only for building and improving release artifacts

3) operate with a cadence sufficient to build and retain this

expertise (which would currently be one cycle of the queue, but

ideally every ~3-4 months)

By using the teams queue everyone will know when the release is

coming, and whether their branch will be merged before or after the

next release.

Greg

Steve George <steve@futurile.net> writes:

I don't have any idea, 202509-next-master might be good, I don't know

what others think

On 2025-05-09, Steve George wrote:

Thanks for nudging this forward! :)

...

Maybe more like 4 or 5 months, but who's counting? :)

Notably, Debian has time based freezes, and releases "quando paratus

est" ... e.g. when it is ready (e.g. no major blockers to release).

I think this is a more realistic and honest model for a volunteer

project than trying to make a time-based "release", as you can predict

or decree when you are going to start the process, but you cannot

reliably predict when you will finish.

...

For what it is worth, May would be awful timing for getting guix into

Debian stable releases, which tend to approach a hard freeze around that

time of year, so Debian stable will always end up effectively (at least)

one release behind... but you cannot please everybody. :/

A yearly release cycle would at least allow Debian to provide backports

of guix more reliably, at least...

Of course, we are about to see the second Debian release since the

release of guix 1.4.0, so this proposal would still be a huge

improvement!

...

This seems a reasonable broad-strokes starting point, nice!

I fail to see a distinction between minimal and standard, perhaps due to

"core installation", so this perhaps could use a bit more elaboration.

It seems like all desktop environments is awfully broad, as there are

some unusual or niche desktop environments in Guix, although Guix users

maybe also tend to fill certain niches more than the general

population. Still, I suspect this should maybe be narrowed down to a

more specific set...

What are "standard server packages and services" ?

What are these?

...

Sounds reasonable.

Do we currently have all these for x86_64-linux and aarch64-linux, the

two proposed primary architectures?

I think someone already mentioned freezing master should be noted as a

drawback. I would, in a weird way, second that, despite thinking it is

actually a feature. :)

Ambitious, but may as well aim high!

The weeks listed here are -5 indexed, but are described as a 1 indexed

bulleted list, it would be nice to keep them using the same indexing!

(a.k.a. ### -5.)

...

It seems like you would need to clarify the toolchain package set the

week prior.

Yay! This should also give the build farms a chance to "catch up" with

builds.

...

If they are minor package upgrades, do you even need a team branch?

Spell out "RC" at least once in the document, presumably "Release

Critical"?

Not sure how you cram two weeks into week 13! (or... is that week 10?)

:)

^^ release ^^

As a downstream packager of Guix for Debian, I would appreciate

(pre)release candidates be included earlier in the process somehow.

Maybe even in sync with a weekly cadence in line with this release

process?

I usually do find bugs in the process of packaging Guix for Debian, and

it would be nice to more easily catch those earlier.

Yay!

Thanks again, really glad to see some good thoughts and energy go into

this!

live well,

vagrant

Hi Greg,

On 9 May, Greg Hogan wrote:

Thank-you for the kind words - my aim is to be pragmatic about what we can achieve. Taking a concrete step forward allows us to make progress and who knows maybe we can achieve more in subsequent steps.

(...)

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 agree this is a problem, for the purposes of focusing discussion on this GCD lets keep it out of the remit. Perhaps a separate discussion or separate GCD!

Can you point me to the part where you think it's too aggressive? Maybe it's overstating it in some way. In my mind I think the release is a checkpoint where we can use the package sets and the project plan focus to do what we should be doing using our existing process.

In a way this does create a team in the way you brought up in December [0]. It creates a "release team" for one project and tries to limit the "toil" by keeping the project to 3-4 months of effort. It defines a specific time when a release will happen so everyone knows when it's happening, can get involved and help.

Where it differs is that realistically the release artifacts involve the kernel, core packages, networking, base utils, guix daemon, and graphical environments [1]. I don't think this can be done by 3-4 volunteers, there has to be some co-ordination and energy from all teams - we are a small team after all!

Does that address your concerns?

Steve / Futurile

[0] https://lists.gnu.org/archive/html/guix-devel/2024-12/msg00205.html

[1] https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm

Hi Steve,

I agree on the motivation and the analysis, but I want to share a

thought before getting into the specifics.

From the GCD I understand that:

We don't release much because it requires a lot of work to make them,

but your proposal is make more of them, making the process easier,

clearer and more effective, but still requiring some coordination and

work (two things we might lack a lot in our community).

All this because releasing more often is better for:

- a shorter first guix pull

- substitutes maintenance

- promotion (features, excitement, documentation...)

From here I'm trying to take a lazier approach that is to step

backwards a little bit and think about what a release actually is.

And I wonder: what is preventing us from embracing our master branch and

making the whole process fully automatic?

It's not a rhetorical question, I actually mean it.

We already have a News system that lists the major changes since the

previous guix pull and everybody is in master already (that's how this

software works!). Could we just create the release artifacts with an

automatic process that is launched every N days or N commits?

That process would cover the three points properly if our master branch

was more or less stable, which it is or at least we are supposing it is

every single time we `guix pull`, and if we had an up-to-date

documentation, which we should have anyway. Maybe the excitement and

feature communication is not as well covered but we could make some

release notes from the News we have like in any other guix pull, and

point to blog posts that we have been writing as the features were

implemented (maybe write more of them?).

I'm not proposing it as a practical solution (well, maybe I am!), but as

a thought process to find where the rough corners are and what are we

*really* trying to solve with the process. If we could just generate the

release artifacts from a script, then it's not just that our releases

are slow, but something else. Get what I mean?

That would be for me the ideal world, where our software is stable

enough to be released by itself just because we want to provide a

shorter first `guix pull`. Or is it something else that we are providing?

How stupid it is what I'm saying here?

Sometimes, if something feels like a lot to do, because it is important,

the solution is not to put more resources on it, but to make it less

important, let it happen more often and don't pay as much as attention

to it.

My feelings here are we don't really release much because we already

bought the rolling-release and we just don't think about the release

that much. If we lived for two years and a half without a release, maybe

we are right and the releases are not that important.

Should we make them more important or less important?

Somehow what I'm trying to say here is if we need an exceptional effort

(meaning releases are an exception) for every release or if we should

bet more on the everyday work and let the rest happen. This might give

us some relief about the obligation to make releases but also some extra

motivation to be exceptionally good every single day of the year.

I don't know.

Steve, you asked for my thoughts, and here they are: probably not what

you expected (:

The proposal feels very good though, this was just my overall impression.

Best,

Ekaitz

On 2025-05-09 14:53, Steve George wrote:

Hello Ekaitz,

Am Sat, May 10, 2025 at 12:59:32AM +0200 schrieb Ekaitz Zarraga:

thanks for your contribution, which brings up some interesting thoughts;

they sound provocative, but I find it useful to step out of the box and

ask the question: "do we need releases at all?". (Which goes a little

bit beyond what you actually suggested.) And one possible outcome of our

GCDs is that in the end, we decide the problem they try to solve is not

really a problem, but the GCD process has allowed us to come to this

joint conclusion and thus to move forward as a project.

Indeed if we have lived without releases for a long time, it is because

the rolling model makes them less pressing: As long as one can install

any Guix version at all, one can do a "guix pull" afterwards and be

up to date.

An automatic release process would solve some of the problems that

motivated this proposal: Debian could package the latest release no matter

how it was obtained; "guix pull" would start from a point closer to the

current master branch; and so on.

What is added by a manual release process, in my opinion, is quality

control. While the master branch is supposed to be in perfect shape all

the time, it actually is not:

- Sometimes there are breaking changes with problems only discovered

afterwards. For instance, the move to a non-privileged daemon caused

problems which are being solved now. Hopefully such a breaking change

would not make it into a release due to the freezing period.

- Ungrafting is a big issue that would be done during a release, and

the past has shown that it cannot be done completely automatically

(sometimes things break when ungrafting). Currently on a high-speed

Internet line it may take more time to graft the packages than to

download them.

- Recently when updating a package and checking which dependent packages

it would break, I noticed that several of them (!) had not been built

for years (!), and nobody had taken the time to fix or remove them.

Filing removal requests resulted in them being fixed or removed, and

a better quality of Guix (in a very small niche) and easier

maintenance: now doing a "guix build -P 1 this-package" actually tells

whether this-package update breaks anything or not.

These are things we *could* do any time, but which are probably not much

fun, and so they are not done. Crafting manual releases means we *must*

address such problems and face our quality issues.

This could also be a first step towards an additional stable branch,

which people have called for, on which security updates and (to be

discussed) limited package updates could be made. This is outside the

scope of this GCD, but I think that quality based releases on a certain

schedule are a prerequisite.

Clearly we could not (or would not like to) do security updates on a

branch as old as our 1.4 release; and it would also not work in your

alternative model in which, if I understand it correctly, releases would

be made essentially by putting a 3 digit version number periodically on

git commits, which would essentially be a purely rolling model.

Andreas

Hi Steve

Thanks for the effort you put into this, I just wanted to add my

thoughts when reading it...

Should this not be done on a separate release branch as soon as we start

with the release? There seems to be no need to freeze master as soon as

we branch off a release branch. Or did I understand something wrong?

On 2025-05-10 11:15, Andreas Enge wrote:

So, there it goes!

You answered my question really clearly: We don't actually *need* to

make the releases manually, but we need the stability that process gives

us, specially for ungrafting.

My proposal was the most radical I could think about: just don't have a

release process. Or as you put it "put a three digit version number in

git commits". But the idea was to think about the grey, adding some

black to the white the GCD proposed.

So, now, realistically speaking, we are not ready for total automation

and we should make a release process. That I agree with, and we could

use the process to try to slowly make the process lighter until it

barely exists, which would at some point let us make releases more often

and with lower effort.

The question now is how do we achieve that. You point the goal of the

release process is the quality control. Now I wonder if there's any way

to relief the release of some of that weight (or all of it), being a

little bit more cautious during the rest of the year.

I know that makes every day less fun, but I'm thinking on how could we

share the responsibility to make the work of those that are going to

make the release as light as possible.

And this takes me to the actual specifics of the GCD:

I think one of the reasons we don't have a release for that long time is

the lack of people taking care of it. The GCD has a plan about it, but

it relies on having people involved in the process.

I'm a little bit pessimistic about how many people would get involved in

that, or better said: I'm worried that the very same people would be the

ones that get involved in the process over and over again.

That's why I'm trying to find a way to make everybody get involved in

the process in their everyday work, so the actual release process is not

that hard and makes it more likely to people to join. The way I have to

think about it is to imagine a future when releases can be automatic,

and think about what is preventing us from having that now.

I like the GCD, I think it's thoughtful and well organized, but it might

lack some of that: let's see how it went and try to make it lighter and

lighter for the future.

Maybe adding that is just a matter of publishing some

blogpost/survey/... after the first release is done using this process

where people share ideas on how we could implement improvements in our

everyday lives. After that, I suppose more GCDs would be proposed: a

long-lived stable branch, a full-automation proposal, better CI/CD

process, proper package testing... Whatever that is so we keep the wheel

rolling.

There's already some of that in the GCD: package sets are a very nice

way to make sure we are specially careful with some packages, and that's

something we can do every single day.

Does this make more sense now?

Thanks Andreas for your response,

Ekaitz

Hi Steve,

Steve George <steve@futurile.net> writes:

If a Guix release is a point in time snapshot of a rolling

release, and the first `guix pull' after

installation puts you back into the rolling release model, I don’t

think more frequent releases address this need.

It also causes user confusion becasue the assumption is that the

release is what they should be using. We get a good number of

folks in #guix reading the 1.4.0 manual, which doesn’t accurately

reflect the current state of things.

I think it’d be better to align the initial release with the

schedule we want to keep, so if we plan for a November release,

plan to release every November.

I’m not sure what the difference is between the installer and

system ISO image is, could you elaborate please?

The 1.4.0 release artifacts are[1]:

- Installer image for i686 and x86_64.

- QCow image for x86_64.

- Binary for i686, x86_64, armhf, aarch64, and powerpc64e.

- Source tarball.

Are the binaries and source tarballs "additional release

artifacts?"

I think it’s worth considering doing this the other way around:

instead of freezing master, cut a release branch and cherry-pick

fixes into it as needed. I don’t expect that development on

non-release features will stop during the freeze, which means

we’ll have a large backlog of work to merge once the freeze ends;

this is a thing Guix has historically not been good at working

through in a timely manner.

A release branch would also support longer-term stable releases,

if we wanted to do that.

The downside is that it’s more work to cherry-pick fixes between

branches, and there’s the potential for merge conflicts.

This could prove troublesome, as the current Guix approach is to

update packages to the version containing the fix. Are you

thinking that we’d maintain that, or adopt a Debian style of

backporting fixes where possible?

This is going to be difficult to manage, especially for

contributions from those new to Guix development.

Thank you for starting the discussion!

-- Ian

Hi Ian,

Ian Eure <ian@retrospec.tv> writes:

I think that currently this isn't achievable very well. If release and

master are diverging branches, and they will be if work is in both of

them, then if users install the system from that, then pull, and reconfigure,

their forward update check will fail as it expects the new commit to be

descendant of the old one, and it won't be. That would be causing confusion.

Regards

Rutherther

Hi Rutherther,

Rutherther <rutherther@ditigal.xyz> writes:

Hmm, good point, I think you’re right.

-- Ian

Hi Ian and Rutherther,

On Sun, May 11 2025, Rutherther wrote:

Could the monorepo be broken up in such a way that release work might

take place in one part while regular development continues in the

others?

The release team would focus on each part in turn, going back if needed,

and would block regular contributions while there.

The release would be the pin to the high-quality commits in each part of

the code base.

Kind regards

Felix

Hi Ian and Rutherther,

On Sun, May 11 2025, Rutherther wrote:

Sorry to double up.

From a technical point of view, I think it would be superior to have

package functions that accept a version (i.e. not variables like now)

and define releases and the current development "branch" by the package

versions they pull in.

There would be no conflict between release work and regular development

activity.

Services would also have to be versioned.

Kind regards

Felix

Hi Felix,

On 11 May, Felix Lechner via Guix-patches via wrote:

(...)

There's lots of interesting approaches we could take, advice from more experienced Guix people than me (sponsors) was to try and keep the GCD to a single change. I've seen it myself that we've had lots of great conversations, but for a small volunteer team it's difficult to make large systemic changes. So this is definitely a "pragmatic" GCD which doesn't require big code changes, and even as (Reza pointed out) distinctly avoids creating a dependency on any new functionality being implemented.

Thanks,

Steve / Futurile

On Fri, May 9, 2025 at 5:55 PM Steve George <steve@futurile.net> wrote:

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!

Performance of the teams workflow is integral to this proposal. We can

barely get a handful of teams processed in a month, and now we propose

allowing all teams a go within a four week window. And it seems to me

the biggest issue with the teams workflow is the indeterminate nature

of moving to the head of the queue. This proposal synchronizes many

activities to an annual process for which the volunteer developers may

likewise not be available.

### 2. Notify teams of upcoming release

Make sure all teams are aware of the upcoming release. This gives

them 4 weeks

to undertake any large transitions or major changes.

The removal of any broken package:

Packages or services that do not build for the Primary

architectures as part of a release

would be removed from the archive using Guix's deprecation policy.

Yes, those teams are involved if packages or the release scripts are

broken? I'm with Ekaitz on this one, the process to build the release

artifacts should be automated. We already do this for the binary,

which is why I have not had to install a 2.5+ year old system :)

I see Andreas' response that we need a big release hullabaloo to rally

around since tidying up and testing the release is "probably not much

fun". But this process simply codifies the pre-teams workflow that did

not work. And while I certainly welcome this discussion, I don't see

this as a whole qualifying as a GCD (from 001: "A change may be deemed

*significant* when it could only be reverted at a high cost or, for

technical changes, when it has the potential to disrupt user scripts

and programs or user workflows").

This proposal simply takes the processes which are performing poorly

and stuffs them into a very manual annual release process. Ungrafting

can and should be coordinated on feature branches. We need better

methods to identify, track, and notify users of their broken packages.

The teams workflow needs to be clarified (QA vs CI) and coordinated

(thanks, Andreas!) and possibly preemptive.

We tested codeberg before the GCD to switch over. We should likewise

test this release schedule before codifying in a GCD.

Greg

Hi Greg,

Greg Hogan <code@greghogan.com> writes:

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.

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.

Regards

Rutherther

On Mon, May 12, 2025 at 12:23 PM Rutherther <rutherther@ditigal.xyz> wrote:

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@1.4.0-36.0772d36

guile-gnutls@4.0.0

gnutls@3.8.3

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?

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.

On Mon, May 12, 2025 at 01:11:15PM -0400, Greg Hogan wrote:

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

files.

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.

--

Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

Greg Hogan <code@greghogan.com> writes:

Yeah, which means users cannot pull from 1.4.0

See this thread https://lists.gnu.org/archive/html/guix-devel/2025-04/msg00205.html

I don't know why not. I would also think it's good way to mitigate

issues like this. But my main point was meant to be that I think issues

like that will happen in the future as well, so having old releases

means users have to deal with them more often.

SWH should be used even without substitutes to my knowledge.

Hello Ekaitz,

Am Sat, May 10, 2025 at 01:04:18PM +0200 schrieb Ekaitz Zarraga:

I think this is something we agree upon: Things should be as automatic

as possible, if we can make machines do the work for us, this would be

perfect!

But clearly this is not easy. Given past problems with CI and QA, we see

that there are not enough people working on automation, and that the

problems are complex.

Indeed, the idea is to have a turn-over, which is partially spelt out in

the proposal. If everybody takes part twice and there is a renewal of

half of the people every time, we would avoid that people get burnt out

and still pass on experiences with the process.

Good point, which maybe should not be a part of this GCD, but a subject

of further thought: How can we make our life easier? How can we improve

the quality of Guix? When Ludovic added the deprecation policy to the

manual, I suppose that was something he had in mind. Similarly it is the

goal of the Codeberg migration.

The GCD contains step 14: "Release retrospective". That covers your

point, in my opinion.

But more fundamentally, I think it is not realistic to end up with a

fully automatic procedure. In the end Guix is a social endeavour (lots

of people working together towards a common goal), and I think we need

social processes to reach our goals. For instance, when merging team

branches, we somehow need to negotiate the order; individual teams will

look at their branches and try to advance them, but sometimes it may be

better to let another branch go to the front. Similarly for a release,

decisions will have to be made. Packages may have to be dropped, the

latest release of desktop environment X which is almost, but not quite,

ready may have to be excluded, and so on. Having a team to coordinate

this, and also invested to take unpopular decisions, is necessary in my

opinion.

Also I think we need a period of manual testing. As Vagrant said,

sometimes packaging for Debian, for instance, reveals problems that we

had not seen before. Or asking people to try an installation on an

exotic architecture.

Andreas

Hello Greg,

I am having some trouble following your argumentation; in the beginning

of your different postings I got the impression that you did not see

a need for releases, since one could always do a "guix pull". But then

you end with:

Am Mon, May 12, 2025 at 01:11:15PM -0400 schrieb Greg Hogan:

So I am definitely not getting your point! With the goal of moving forward,

could you try to reformulate your ideas? Are there concrete points we could

improve in the GCD, or do you think it should simply be dropped as not

relevant to the real problem? If we missed it, what is the real problem?

As to automation, I made a few arguments in my reply to Ekaitz, so I will

not repeat them here.

Andreas

On Tue, May 13, 2025 at 9:11 AM Andreas Enge <andreas@enge.fr> wrote:

Hi Andreas,

There may be some confusion in terms. The GCD states "there are

currently over 30,000 packages in the archive" and "Guix would still

make all packages and services part of a release (the entire

archive)". And when I look up the definition of archive I see

references to "historical documents" and "preservation".

If a release is build artifacts plus every package in working order

then I find that to be a Herculean task. There is of course tremendous

value in this because on every contribution the developer must

investigate whether build failures are newly caused or preexisting (or

ephemeral or system dependent). I fully support this attempt, I just

think we should first attempt to get every package in working order

before codifying this annual process in a GCD.

If a release is simply build artifacts, then we are already automating

part of this process. I count 10 builds of the binary release across

March and April:

https://ci.guix.gnu.org/search?query=guix-binary

Can we not similarly automate creation of the ISO and QCOW2 artifacts?

Then, as you note, these need to be manually tested and blessed as a

release. But I don't see why the ancillary packages need to be in

working order to cut a new release.

It would be nice to make your teams coordinator position official.

Considering the number of ideas for improving the teams workflow, we

are probably due for a GCD. And I think that is the right process, to

have the GCD deliberate the lessons learned rather than speculate

beforehand.

Does this clarify? I see this proposal as trying to 1) manually fix 2)

all of Guix's problems in 3) a shortened time window, shrinking what

we are unable to maintain in 12 months into a few weeks (the only

thing missing is closing all issues during the release cycle).

And maybe it works! Maybe the 10x and 100x contributors, including the

sponsors of this GCD, will happily fix everything and make this

happen. I can accept that. But why not just do that already? Are the

core developers not empowered? Too deferential? What improvements does

this GCD offer other than a process to "encourage and excite"?

Greg

Hi Greg,

thanks for clarifying, this is indeed very helpful.

Am Tue, May 13, 2025 at 11:03:02AM -0400 schrieb Greg Hogan:

I think the release proposal tries to reach some middle ground between

these. There is supposed to be a set of "important" packages which

should build (or be removed, so that the users get what the description

says), the "package sets". These are not yet really defined, and doing

so is given as a task for the release team (no 05, "package set

finalisation"). They would block a release.

The remaining close to 30000 ones will be shipped ("released") whether

they build or not; it is clear we will never reach a 100% perfect

distribution (and I think it is a task for the teams to more

aggressively remove packages in their realm that do not work, which

should not be postponed and left to the release team).

I agree that the GCD is a bit ambiguous about this and in particular the

removal procedure; it mentions the "deprecation policy", but this takes

a month in itself, so is probably not compatible with the tight release

schedule.

So as a practical example, I suppose we will define a desktop

environment package set; gnome will certainly be a part of it, and maybe

something else (xfce? sway?), but probably neiter lxqt nor kde. Then if

lxqt does not build, the release team would not care. If gnome does not

build, the release team would push the gnome team to repair it. In

theory gnome could be removed from the release, but I find it difficult

to imagine, although it would be possible as a last resort, together

with an entry in the release announcement. More likely, we will all push

very hard to get gnome in. But probably renounce at a last minute

transition to a newer gnome version.

Definitely not all problems, but we hope at least some!

This is the hope, that "encourage and excite" will make the difference

during a release cycle. Clearly we cannot all be excited all the time :)

Andreas

Hi,

sex 09 mai 2025 �s 13:53:39 (1746809619), steve@futurile.net enviou:

First of all, thanks for this initiative, we're certainly in need of a more

structured and reliable release process. I have no experience doing guix

(or any distro) release, so take or drop my comments as you see fit.

I'm not sure a GCD is the proper way to tackle the release issue. As we say

here in the global south - where November is spring :) - "you are putting the

cart before the oxen", meaning its the oxen that should be dragging the cart,

not the other way around.

Since we've been having problems producing a release for the past years, I feel

that aiming to shorten the release time span before even having had a release

might not be the best way to achieve the proposed goal. What happens if we

approve this GCD, but then no one assumes the roles of a release team? How

could we "enforce" this GCD on a volunteer project?

Wouldn't it be better to first establish and organize a release team, with the

goal of releasing v. 1.5.0 as soon as possible and with the secondary goal

of establishing/documenting a release process/schedule for future releases?

IMO, this does not require a GCD, "just" people volunteering to the work at

hand.

In a sense, I agree with other comments here that maybe we should treat

releases as something less disruptive of our normal activities. So, instead

of aiming to mimick what other - larger and more resourceful - distros do, we

could aim to do it in a way that is compatible with our own routines and

resources.

What I envision is something like:

1. The release team focuses mainly on the artifacts. Those should routinely

be automatically built, regardless if we are about to release;

2. The relase team keeps a watchful eye on CI/QA for the build status of main

architectures and packages needed to build the installer and images for those;

3. Once some major changes (linux-lts, gnome, toolchain, etc) hit master and

CI shows that those are good and the successful build percentage is on a

historical high on CI/QA for the major architectues, the release team proposes

a new release to guix-devel;

4. Once proposed, any other major changes (anything that currently warrants

a separate branch) are delayed for two weeks;

5. During these two weeks, the release team has the authority to revert any

breaking changes (new build failures) commited to master and everyone is

invited to test the latest beta-release artifacts;

6. If no release critical bugs are found, the relase team adds a commit

tagging the new release with a news entry and a blog post summarizing the

main changes since the last release and publishes the artifacts;

7. If release critical bugs are found and cannot be fixed in time, the

release proposal is withdrawn and people are invited to work on the rc-bugs

and major changes can be again merged to master. Go back to item 3, but a

new release proposal can only be made if the already rc-bugs are fixed and

the major changes that were delayed at the time of the last proposal had the

opportunity to be merged.

Does that make any sense?

Cheers

Hi Steve,

Thank you very much for all the effort you put into research, analysis

and comming up with this very detailed proccess proposal.

I'm a very slow reader, so I went through the whole GCD, but only

briefly skimmed the discussions in this thread. Will share my overall

thoughts below.

Slow guix pull is a technical problem, not organizational, while we can

work around it by including checkout and auth cache into iso and

releasing often, ideally the guix pull itself and its speed should be

improved, not the release cycle introduced.

The similiar for quality control. We have a huge number of contributors

and very small number of maintainers and there can be a bottleneck here.

Also we have very blurry maintanance responsibility for any particular

package or group of packages. So, we can definitely improve in this

area as well. By asking release team for commitment we just push those

duties and responsibilities to release managers and engineers (which can

be viable strategy, but I'm not sure). I also have concerncs on the

amount of commitment and effort required by a volunteering release team.

My intuition suggests to radically reduce the scope and complexity of

the release process and focus only on producing fresh live system and a

few other artifacts. We can just ensure that live system and standalone

package manager work properly and people can boot it/install via apt in

Debian/etc. After that they anyway make guix pull/time-machine, so we

probably don't need to make a release commit from which iso is built to

have all the packages in a perfect working shape.

I actually have much more thoughts, but I think those above are most

relevant and hope clear and useful. Appreciate your work!

Hey folks,

Steve George <steve@futurile.net> writes:

it happens to the best of us ;-). Thanks for working on this!

I think that this is a good point to make, but at the same time we may

not want to have other projects to direct our release cadence. Not

because we don't want to play along, but rather because it causes undue

stress and adds arbitrary deadlines that are hard to work around

w.r.t. our current volunteer group of contributors.

My two cents: focus only on minimal, perhaps extended in such a way that

this is a system that after the first reboot allows one to run guix

pull.

Ditto for 'foreign-guix': any version of guix that doesn't burn down the

house on updating itself seems like it would be 'enough', and still a

strict improvement over the current situation.

This makes a lot of sense to me, although I could be centered around

'functional' breakage w.r.t. allowing the installation to update itself

past any major issues via guix pull (+ guix system reconfigure or

equivalent).

Thanks again for the detailed analysis and proposal,

- Jelle

Hi all,

Thanks for all the feedback on the initial proposal.

I've integrated it into the GCD so attached is a revised version. I think it's ready to move to the Discussion Period (minimum 30 days from today).

A short summary of the changes in this version:

- Rename staging to integration branch with suggestion of next-master [Zheng Junjie]

- Add benefit of updated distribution through other package managers [Rutherther]

- Remove reference to faster initial git pull [Rutherther]

- Move target annual release to June [Rutherther]

- Reduce freeze period by breaking it up into stages [Rutherther & others]

- updates freeze (week 8->12), hard freeze (week 10-12)

- Identify pacakge sets earlier [Vagrant]

- Reword template plan to show weeks [Vagrant]

- Add alternative release target weeks to plan [Vagrant]

- Identify 'at risk' packages earlier [Greg / Andreas]

- Make automation a goal of the Release process & release team [Greg / Ekaitz / reza]

- Reduce the scope of package sets [Jelle / Efraim]

- Provide more clarity on dealing issues in package sets [Rurtherther]

- Try to clarify options around RC bugs and package build failures

- Try to clarify purpose of release project plan as a template

I would love to know if this improves things from any feedback that you gave?

As well as any other thoughts, comments or ideas on how to improve this GCD!

Steve / Futurile

Steve George <steve@futurile.net> writes:

Hi Steve,

Thanks for this great GCD!

I assume the GCD would end after June, so will there be a july/august

release or will we have to wait for a year?

Few comments below.

Have a great day,

Noé

implementing*

No space between ] and (

What happens in 6 years when there are no new release managers

available, can we reuse someone?

On 22 May, Efraim Flashner wrote:

(...)

(...)

Yes, fair enough that's more specific and clear. Added it.

(...)

Given that the main purpose of the 'release-branch' is to track the final release artifacts I think we can do it either way around.

So, either:

- do work in master and sync to release at the end

- or work in release and sync to master at the end

I've updated to your scheme and tried to provide a short explanation, without lengthing this area too much!

(...)

Done.

It also speaks to Jelle's point, if the project doesn't have the volunteers to complete the release then we can just move on.

Steve / Futurile

Hi Noé,

On 22 May, Noé Lopez wrote:

(...)

(...)

Asking other developers about timing the general sense was that asking volunteers to contribute to a release over July/August wouldn't work because everyone is on holiday (and hopefully doing something better than staring at their screen!).

Rather than wait a year I proposed:

Essentially, this would mean we'd start working on a release in the Autumn.

(...)

I wasn't suggesting a strict rotation where you can only do it once out of the X committers that we have. The new person is still a volunteer from the pool of committers. The idea of the "rotation" is to prevent it becoming one persons permanent chore and because of the 'bus-factor' risk. I expect that there will be a subset of active contributors who are interested/willing/able to work on a release, so the 'release manager' role will probably rotate around amongst that group - but not all contributors.

In principle, if we did get a lot of automation the RM role wouldn't have to be a committer, but as I understand it at the moment it does.

Fixed the other typos - thanks for going through it in detail, appreciated!

Steve / Futurile

Hi guys :)

Z572 <z572@z572.online> writes:

I am in favour of a naming scheme which reflects the time it was created. It might even

be sufficient to use just a year prefix since we assume there is only one created per year

(per release).

Have a good day :)

Olivier

Hi Olivier

On Thu, Jun 05, 2025 at 04:22:43AM +0000, Olivier Rojon wrote:

(...)

(...)

Just to make sure it's clear, this is the name for a branch that would be used for 8 weeks where major changes would be held. This is so that we don't destabilise our main branch ahead of a new release. The reason Z572 was concerned about reusing the name 'staging' is that this was previously tried, and this branch became long-lived and it was hard to merge it back into the main branch.

I was trying to think of a name that would imply that this branch would *only* be around for a few weeks. So suggested the month it was merging back in - to prevent it becoming long-lived. I don't think we should call it by the year as that might encourage our previous problem! What do you think, does that make sense?

Thanks,

Steve / Futurile

Ah, then there was a misunderstanding on my side, sorry. It's funny how you can misread

stuff that's clearly stated when it's early in the morning :D

Steve George <steve@futurile.net> writes:

Hi,

I share the concerns others have already described, particularly:

On Fri, Jun 6, 2025, at 12:41 AM, Liam Hupfer wrote:

To me, it seems important to clearly identify who is the audience for Guix releases and what use releases are meant to serve.

I primarily use Guix as installed through the Debian packaging, so, to me, foreign distro packagers are obviously an important audience! Some form of Guix System installer also seems important, but I'd hope to hear more from interested people about what use-cases releases, as opposed to snapshot installers from CI, serve in that context.

This discussion calls to mind that the Nix folks (IIUC) have a release cycle for their daemon that's different from that for their package set. From my perspective, the daemon and other software developed by Guix are the essential part of a release. Narrowing the scope and defining the audience might make it feasible to provide relevant security backports, an extremely valuable improvement.

Overall, I also think this concept of "package sets" should be simplified and refined, or indeed replaced by existing concepts like teams and manifests.

For Guix on a foreign distro, "kernels, boot loaders, [and] filesystems" don't actually seem relevant as part of the release.

For the installer use case, again, I think it would help to clearly articulate the audience and purpose of releases. For example, one possibility (which may or may not make sense) might be, "A user who does not have command-line experience should be able to install Guix, boot the installed system, and use Emacs-Guix to execute `M-x guix-pull`." One reason that possibility might not make sense is that I'm not sure how completely Emacs-Guix replaces the need for command-line experience. If Guix effectively requires command-line experience already, I'm not sure *any* desktop environment should be a release-critical package. (To be clear, I think it's very valuable to support users who don't use the command line, I just think we should be clear about whether we currently do or not.)

With the context in mind that a better release process wouldn't replace the recommendation for an immediate `guix pull`, I also think the discussion of timing with respect to other distros and desktop environments is backwards. If Guix releases in June, packages of Guix in Ubuntu LTS (April of even-numbered years) and Debian Stable (c. summer of odd-numbered years) will be 10+ months old at time of release. The proposed benefit of getting a more recent desktop into a Guix release seems minimal: users on foreign distros will not use it at all, and Guix System users who follow our recommendation will use it only until their first `guix pull`. It would seem better to release in November or January to get an up-to-date Guix into LTS distros.

Hope this is useful,

Philip

Hi,

On Sat, Jun 7, 2025, at 9:00 AM, Steve George wrote:

My point here is that the versions of Gnome, KDE, etc. in a release of the Guix *installer* do not affect desktop Guix users after their first `guix pull && guix system reconfigure`. No matter how old the installer is, running those commands will always get the latest (packaged) version of the desktop, along with everything else. The Guix package archive operates on a rolling-release basis, which this GCD does not propose to change. Therefore, we will still recommend that users run `guix pull` as soon as possible on installation and regularly thereafter: it is the only way to get security updates, for example. So, if a release installer includes an older version of some desktop, I would expect it to be updated by the first reboot.

Trying to get the latest and greatest desktop *before* the first reboot seems like a low priority to me. Additionally, I would hope decoupling the release cycle from the desktop teams' updates, which are significant undertakings, would reduce the friction of regular releases.

In contrast, the version of Guix in an LTS distro package is likely to be in use for a couple years.

Overall, since Guix will continue to work most like a rolling-release distro, the effort of a fixed release seems to me to require an especially compelling justification to meet a need of carefully restricted scope. I can see that justification for occasional especially-thoroughly-tested versions of Guix itself and the Guix System installer. But I don't see a benefit to widening the scope beyond packages needed to install the system and run `guix pull && guix system reconfigure`. In fact, if a release prominently announced features like updated desktops (as a Debian release might), I can see some concern into misleading users into thinking that they should stay on the "released version" and not receive security updates and bugfixes.

Philip

Hi,

--> YES <--

I see that the best effort of rapid refresh of the packages for

particular collections are already practiced in the project e.g. R

refresh by Ricardo.

From that experience I may say that it's much, much easier to keep hand

on pulse of upstream than spend weeks (Golang, the most of th Python,

Ruby, PHP, JavaScript, Perl, Java...) in endless effort to balance

too-much-dated-versions chains.

As we split efforts among teams already I think it's the next logical

step to agree on sort of predictable refresh schedule among them. The

only one constrain is a long waiting time in the queue e.g. go-team and

r-updates were waiting for about 2 months while were tested and ready to

be merged, I hope it something we may discuss in the separate thread.

The version tag of the Guix itself would benefit downstream packages

e.g. in Debian and would bring much nicer user experience, as for now I

noticed complains form foreign distro users on the need to way hours

even days before the first 'guix pull' is completed.

Workload pressure may be relaxed as well, as I mentioned above, it's

much easer to auto refresh and build recent version than resolve dated

package version dilemma, the same position here - yes it would need some

effort to keep on pace in a reasonable cadence with upstream but

comparing with amount of efforts required to bring from the older

version should be easier.

From the user experience (mostly complains on Mastodon), the stopping

point to select Guix over Nix is - dated versions for my lovely packages

stack, with understandable claim Guix has a much smaller team and

package maintenance is a hard task in general.

I've noticed in other projects - a version comparison in package

description with upstream [1] (available from the package manager and

current upstream).

Other one is a package refresh ration (it requires quite a lot of time

to collect [2]), for example how to answer this question for

commiter/contributer: If I need to list packages which defendant count

is less than 4 and refresh them all how can I do it quick?

More metadata for the package [3] which would help in maintenance or

addressing issues to the particular team which would be visible for the

user/contributor.

List of dependent packages [4], packages using <this> [5] in the first place.

I try to keep Astro collection on the latest available versions where

possible and submit new packages and refreshes on each 20th of the month

and merge by the end of the month nearly 2y already, there are 200+ in

(gnu packages astronomy) and a few in other modules, it takes me up to

5-8h per month for that task: package some new ones from the planned [6]

list and refresh present ones where possible. Some tasks are required a

long loop, jumping to python-team to refresh lower level packages.

It's my personal preference, as I see it's easy for me to run "guix

refresh -s module:astronomy" and work through the whole collection than

resolving conflicts in dated version after n+1 months.

I can contribute some time "to drive a refresh train to the final depot"

(c) Simon Tournier, periodically.

Hoping my position is clear ^.^ sorry for the long read.

1. https://blends.debian.org/astro/tasks/python3

2. https://issues.guix.gnu.org/74268

3. https://packages.gentoo.org/packages/sci-astronomy/stellarium

4. https://aur.archlinux.org/packages/stellarium

5. https://www.juliapackages.com/packages/astrobase

6. https://git.sr.ht/~hellseher/ffab/tree/main/item/TODO.md

---

Oleg

On Fri, May 09, 2025 at 01:53:39PM +0100, Steve George wrote:

First, my sincere thanks to you for making the effort to analyze the

situation, make a proposal, and shepherd the discussion.

Releases have always been a pain point for Guix, at least since I joined

around 2015. Of course, they seemed to get much harder as the codebase

and our ambitions grew. Now we have a binary for the package manager,

the source tarball, VMs, an installer image, desktops that we aim to

support, a variety of CPU types, two operating systems (Linux and Hurd),

etc. It's a huge amount of work on top of the Guix-specific difficulties

--- functional package management is tricky here --- that relate to

making a release.

In the past, we were able to freeze for a week here and there, but the

Guix project was much smaller and able to coordinate as a group, with

only a few committers, so it wasn't as hard to imagine a freeze as it is

now. We'd freeze for a few days and extend to a week when we had

trouble. Maybe it sounds crazy to freeze for 9 weeks, but compare us to

Debian or Linux. It's not necessary to deploy updates every minute of

the day. Git is decentralized and we all know how to use it.

Compare Guix releases to what's happened for TLS and web security since

Let's Encrypt automated the issuance and renewal of X.509 certificates.

That went from a manual, infrequent, expensive, and error-prone process

to something that is easy, automatic, and basically required for a web

site. TLS is everywhere now. Part of that process was a drastic

reduction in scope of what SSL / TLS meant. It used to be that an SSL

connection told you something about the people behind the web site. Only

trustworthy and capable organizations used SSL (banks, etc). There were

tiers of certificates that somehow vouched for the web site. I'm not

sure if younger people realize the depth of that change. Let's Encrypt

said, "No, the certificate only means that the person that controls the

DNS name is serving you the data - nothing else. The connection is

confidential and authentic". It's purely a cryptographic construct now,

and TLS is ubiquitous. Nobody's bank account is getting hacked by a

rogue wifi network anymore.

BIG POINT:

Similarly, I recommend we make releases more automatic and more frequent

by reducing their scope. Until our capabilities grow to the point that

we can actually regularly create a bunch of release artifacts that have

been well tested for a bunch of platforms, let's figure out how to make

the minimum viable release from which users can install Guix and then

instantiate whatever it is they need.

We'd need to be creative here, from a technical point of view. I don't

know what this minimal release artifact is.

All the different CPU platforms, the Hurd, the desktops, the VMs...

people need to step up. The release team should not be validating that

stuff. The release needs to install a working Guix on Debian and Fedora.

Needs to install a bootable console on x86_64-linux (no, let's not ask

users to run `guix system init`). And maybe aarch64. But I wish we had

statistics of substitute downloads, to understand what people are

actually using. We should be bold.

People love releases. Releases are an occasion to celebrate. People make

t-shirts, stickers, have a drink on IRC, in Brussels, Bordeaux, and

Paris, and hopefully other places (any New Yorkers reading this???).

This kind of hoopla can entice people to join our project, and in the

long run we may gain the capability to do big complicated releases with

a bunch of artifacts again.

Also, our old releases work until they don't. We want SWH to save us

from bitrot, but our packages keep fighting us with little time bombs

that break the build after certain dates. We need releases to keep Guix

buildable for new installations. Guix is a build-from-source distro,

although we hide that well.

Personally I'm not sure we need a GCD here. The same leadership required

to issue a release is needed to land a controversial and disruptive

change. And making releases is not controversial or significantly

disruptive. I'd say you can just start planning the release now, Steve :)

Leo

Hi Steve,

Thanks for the hard work on this crucial aspect of the project.

Some wondered about the indented audience of releases. To me it’s quite

clear that it’s manifold: there’s public relation, yes, but also

downstream packagers as mentioned, and perhaps more importantly, any new

person installing Guix, be it standalone or on another distro. Starting

today from 1.4.0 makes for a terribly bad user experience.

Some more specific comments:

Perhaps I overlooked it, but it’s not clear to me how package sets

affect the release process.

I would expect things like “package set X must successfully build on all

Primary Architectures at time of release”, “package set Y is provided on

a best-effort basis”, or things along these lines.

For previous releases, there were really two package sets of sorts,

although that wasn’t formally specified:

• Packages that the Guix System installer would offer had two build on

the two architectures for which images were provided (i686-linux and

x86_64-linux). That includes core packages but also things like

Xfce, GNOME, Tor, ntpd, and other things that can be selected from

the dialog boxes of the installer.

This is ‘%system-packages’ in ‘etc/manifests/release.scm’.

• “Core” packages that anyone may wish to install on any of the

architectures supported by Guix (not Guix System).

This was ‘%base-packages’ in

https://codeberg.org/guix/guix/src/commit/12d00767f036029f1f5738de644d4972db374f4f/etc/manifests/release.scm

(not sure why it’s not there anymore).

The former had to be build on x86_64-linux and i686-linux; the latter

had to build on all architectures listed in ‘SUPPORTED_SYSTEMS’ in

‘Makefile.am’, and also listed in the manual:

https://guix.gnu.org/manual/devel/en/html_node/GNU-Distribution.html

I would tend to formalize on these two package sets and associated

requirements.

This omits two important things:

• The binary tarball, used to install on top of another distro, for

all “supported architectures” (Primary and Alternative).

• The source tarball, as produced by ‘make dist’ (target audience is

primarily downstream packagers, such as Debian).

Reducing toil will be a matter of defining “supported architectures” in

a reasonable way.

I really like this section!

This raises the question of who will nominate the team. But perhaps

that’s a problem mostly for the first release (Nov. 2025) since after

that passing on the torch will be easier?

s/guix-dev/`guix-devel`/

In the past, what we did was to create a ‘version-1.4.0’ (or similar)

branch one or two weeks before release and would let ‘master’ live its

life, avoiding both total freeze and unintentional breakage while we’re

close to release (only people working on the release would commit to

that version branch).

The version branch would be prioritized by ci.guix.gnu.org too.

It’s very similar to what you wrote here but by keeping the default

unchanged for developers not part of the Release Team, it may prove to

work better.

According to the deprecation policy, this can be done anytime but takes

at least one month.

Overall I like what the GCD lays out. Perhaps there will be adjustments

to be made here and there but it looks sensible to me.

I expect that a big chunk of the work before the November release will

be streamlining the process, in particular ensuring that a developer can

make a release without having too many privileges or a

multi-architecture build farm at home.

Thank you!

Ludo’.