Received: (at 78332) by debbugs.gnu.org; 10 May 2025 09:43:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 10 05:43:06 2025
Received: from localhost ([127.0.0.1]:43997 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDgjZ-000644-Hk
for submit <at> debbugs.gnu.org; Sat, 10 May 2025 05:43:06 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:50928)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <steve@HIDDEN>)
id 1uDgjW-000637-Mz
for 78332 <at> debbugs.gnu.org; Sat, 10 May 2025 05:43:04 -0400
Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com)
by mailtransmit05.runbox.com with esmtps (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93)
(envelope-from <steve@HIDDEN>) id 1uDgjP-006Az4-CH
for 78332 <at> debbugs.gnu.org; Sat, 10 May 2025 11:42:55 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=futurile.net; s=selector1; h=In-Reply-To:Content-Type:MIME-Version:
References:Message-ID:Subject:Cc:To:From:Date;
bh=5gPNryseR8c3pf7W3A3OPUBY7YtMcMY6PZAanfXh/OU=; b=gtnGrDKKsVtkRGL2dOad4h7HF1
RQjdeRCYNC0PWrm+5ybOTrJj2PT9wCvhHwpCZqqFmigEcd2cOLQKMR8gMgd2vYBfHYwjVQcVPANwD
cwIu3kMDUvYDpvSRMvXp5mPqFpHgGQLCe2NDj62UWV40vAh4nTT+9AbQxW0gflMV71FL+oZVRmnux
uxQyVVJq4lqPe1PrFnKms6+VJiJePmltHe0JMsxTH3OFajTwnhISLkANhFpf3B8V6Nyb9NaeeAKsS
ndIfKHxBqq64Tqc9Z5mVf38l3K5g9zpKcZcaIOAptYeSICWGnZXIkoiWoz0wHforygjy0AYJ3bCP5
x3fW/o2Q==;
Received: from [10.9.9.72] (helo=submission01.runbox)
by mailtransmit02.runbox with esmtp (Exim 4.86_2)
(envelope-from <steve@HIDDEN>)
id 1uDgjO-0003Oz-PJ; Sat, 10 May 2025 11:42:54 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)]
(TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
id 1uDgjE-00CQiK-UH; Sat, 10 May 2025 11:42:45 +0200
Date: Sat, 10 May 2025 10:42:43 +0100
From: Steve George <steve@HIDDEN>
To: Vagrant Cascadian <vagrant@HIDDEN>
Subject: Re: GCD005: Regular and efficient releases
Message-ID: <fgc57qffjxkfbqq5paewtef2tnsnr5kqrh2jw53btuehocly27@ubjbk5vtq5q2>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
<8734ddpnu7.fsf@wireframe>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="e34lbz5dj6eqvo3s"
Content-Disposition: inline
In-Reply-To: <8734ddpnu7.fsf@wireframe>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 78332
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--e34lbz5dj6eqvo3s
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: GCD005: Regular and efficient releases
MIME-Version: 1.0
Hi Vagrant,
On 9 May, Vagrant Cascadian wrote:
> On 2025-05-09, Steve George wrote:
> > 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! ...
>=20
> Thanks for nudging this forward! :)
(...)=20
Thanks for your active interest and commenting!
(...)
> > - Debian: Every 2 years (not time fixed), with about six months of pack=
age
> > updates freeze before the release while bugs are ironed out.
>=20
> Maybe more like 4 or 5 months, but who's counting? :)
>=20
> Notably, Debian has time based freezes, and releases "quando paratus
> est" ... e.g. when it is ready (e.g. no major blockers to release).
>=20
> 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.
(...)
I researched various other distributions release strategies to make sure my=
recollections were up to date (linked to my codeberg account). Echoing you=
r comment here I noticed that Fedora has come up with an interesting elemen=
t - they are still time-based but they have "buffer weeks with early and la=
ter release targets" [0]
They run a 10 week release project (they have full-time devs), and then hav=
e four possible release weeks, so it gives them quite a nice landing zone. =
The still have the benefits of a consistent release cadence, but have some =
of the time to do "no major blockers to release". It's easy to see in their=
current step-by-step plan:
https://fedorapeople.org/groups/schedule/f-43/f-43-key-tasks.html
Conceptually, do you think adding something that provides 3-4 landing zone =
weeks would be useful?=20
> > Many desktop distributions release every six months to align with the m=
ajor
> > desktop environments (GNOME/KDE) who release two or three times a year.=
This is
> > why Nix (May/November) and Ubuntu (April/October) align their releases.
> ...
> > This GCD proposes an annual release cycle, with releases **in May**.
> >
> > To move onto this cycle the first release would be a little later: aimi=
ng for
> > the **November of 2025**, with a short cycle to release in May 2026.
>=20
> 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. :/
>=20
> A yearly release cycle would at least allow Debian to provide backports
> of guix more reliably, at least...
>=20
> 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!
(...)
I think here you're +1 on an annual release as it would allow for backports.
In terms of the Debian freeze is moving to June for Guix any better/worse, =
(Rutherther suggested it), or it's just anything in $SPRING?
I guess there will always be a bit of a log-jam if the whole of the communi=
ty is somewhat aligning. In this case Debian is both a distribution (like G=
uix) aligning on a $SPRING release, and a downstream that Guix is trying to=
get into.
{upstream projects} -> {guix/fedora/ubuntu/debian} -> {downstream into De=
bian}
> > ## Package Sets
> ...
> > Guix is both a package manager that can be hosted on other Linux distri=
butions,
> > and a Linux distribution. Limiting the range of packages that receive =
attention
> > is consequently more complicated. Guix already has manifests to track w=
hich
> > packages are used by [Guix System's installer](https://git.savannah.gnu=
=2Eorg/cgit/guix.git/tree/etc/manifests/release.scm)
> > , so this proposal extends that concept.
> >
> > For this proposal Guix would identify key package sets which would rece=
ive the
> > most attention for QA'ing a release.
> >
> > The package sets would be:
> >
> > * minimal: packages required to boot and install a minimal Guix or Guix=
System
> > install. This would include the guix daemon, kernels, boot loaders,
> > file-systems and minimal utilities.
>=20
> This seems a reasonable broad-strokes starting point, nice!
>=20
>=20
> > * standard: packages that create a core installation for all other
> > uses.
>=20
> I fail to see a distinction between minimal and standard, perhaps due to
> "core installation", so this perhaps could use a bit more elaboration.
>=20
The package sets are a starting point, we don't have them, so the specific =
detail could change as this is worked through.
This set-up is a pared-back version of what we worked with in Ubuntu [1]. A=
FAIK this concept comes from Debian (seeds).
We had a minimal 'package set' that was used for all variants (e.g. used in=
the desktop and server install). Then `standard` was the next block-up wit=
h the minimum core utils for a non-X install.
Maybe having both is over-complicated for a first pass.
> > * desktop: provides the packages necessary for a desktop. This would i=
nclude
> > things like X11/Wayland, desktop environments, key applications and the=
mes.
>=20
> 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...
Agreed.
My perspective on 'package sets' is that they should be kept as small as re=
asonably possible, because once something is in then it's difficult to remo=
ve it since users 'workflow [2] will come to rely on it. Of course, what is=
"reasonable" is up for debate within the group, and it's part of each Rele=
ase Teams project to consider it.
We currently have kind of defacto selection of desktops in:
https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm
To avoid derailing the conversation around the GCD I would defer to the Rel=
ease Project to discuss the precise definitions of the `package sets`.
>=20
> > * server: provides packages and services for a server. This would incl=
ude
> > standard server packages and services.
>=20
> What are "standard server packages and services" ?
>=20
=46rom the Guix User Survey we know that roughly a third of Guix System use=
rs use it as a server [3]. But, our teams are actually set-up by file-kinda=
-build-system-type. So there's a dissonance between users usage-scenarios a=
nd our internal organisation. Package sets might allow us to align these tw=
o since we can have teams that are sponsoring (using Greg's terminology) di=
fferent packages in the package set.
As we don't have popcon I don't know what's popular with users, but I was t=
hinking of things like Web server, Mail, etc
>
> > * hosted: provides packages and services which are necessary in hosted =
usage.
>=20
> What are these?
(...)
This is the weakest one as I have no clue. I was thinking that we need to r=
eflect a unique part of Guix which is that we are not just a GNU/Linux dist=
ribution but also a hosted (foreign) package manager. If there are packages=
that are required/popular when using in a hosted set-up, then they would b=
e in this package set.
You've caught me trying to slide it past, because I couldn't actually think=
of any at the time heh :-)
(...)=20
> > ## Release artifacts
> >
> > Using the primary architecture tier and the package sets would involve =
creating
> > the following release artifacts:
> >
> > - GNU Guix System ISO image
> > - GNU Guix System QCOW2 image
> > - GNU Guix installer
> >
> > Again in an effort to reduce developer toil, additional release artifac=
ts could
> > be created but would not be part of the formal release testing and erro=
rs would
> > not block a release.
>=20
> Do we currently have all these for x86_64-linux and aarch64-linux, the
> two proposed primary architectures?
>=20
According to https://guix.gnu.org/en/download/ we have:
- GNU Guix System ISO image -> x86_64 (no AArch64)
- GNU Guix System QCOW2 image -> x86_64 (no AArch64)
- GNU Guix 1.4.0 installer (called binary on that page) -> x86_64 & aarch64
> > # Drawbacks and open issues
> >
> > There's no particular drawback to attempting regular release. It shoul=
d be
> > noted that the project is entirely dependent on volunteers so it may be=
that
> > contributors don't have enough time available to achieve regular releas=
es. If
> > that's the case we would revert back to irregular releases.
> >
> > There are various improvements that could be made to this process over =
time,
> > but no known issues.
>=20
> 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. :)
>
Yes, I will add some text hear about the freeze window. In my mind it's a n=
ecessary element if we want releases, there's no free lunch.
> > # Appendix 1: Release Project Time-line
> >
> > To illustrate the major steps of a release project this is a rough time=
-line.
> > The aim is for a 12 week active release project, with the first one usi=
ng 16
> > weeks in total to give teams time to prepare.
>=20
> Ambitious, but may as well aim high!
>=20
(...)
Yes, and to be explicit there is a trade-off in what we can expect in _qual=
ity_ vs developer morale.
On the one side, asking a volunteer project to work on a release for a long=
time is likely to lead to a loss of motivation. I'm sure we can all think =
of release projects that have been "toil" and bad for morale. So, keeping i=
t to a reasonably short, focused and high energy project seems the best way=
to have a positive result.
On the other side quality takes time. We're trying to release a Linux distr=
ibution that works on (a) a range of hardware (b) other distributions as a =
hosted package manager) (c) for different use-cases such as desktop and ser=
ver, (c) provides delcarative services for configuring everything - this is=
a really large amount of work.=20
So bearing that all in mind, having a reasonably tight project and trying t=
o minimise the testing scenarios/areas of concern seems the right trade-off.
> > The current outline builds from our current [release document](https://=
git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
> >
> > | Week of Project | Event |
> > | --- | --- |
> > | -5 | Nominate a release team |
> > | -4 | Notify teams of upcoming release |
> > | 01 | Release project start |
> > | 04 | Toolchain and transition freeze |
> > | 05 | Package set finalisation |
> > | 06 | Initial testing |
> > | 08 | Updates freeze |
> > | 08 | Breaking changes to staging |
> > | 08 | Ungraft master branch |
> > | 09 | Bugs and documentation focus |
> > | 09 | Branch and tag release branch |
> > | 09 | Testing and hard freeze |
> > | 10 | Release candidate |
> > | 12 | Final release |
> > | 13 | Staging merged to master |
> > | 14 | Release retrospective |
> > | 15+| Relax - it's done! |
>=20
> 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!
Ah, so it was actually a time-table showing the weeks of the project plan.
And the second one (below) is a numbered list of the steps. I will change i=
t to remove the numbers, and I'll put the weeks in brackets.
>
> > ### 1. Nominate a release team
> (a.k.a. ### -5.)
>=20
> > ### 4. Toolchain and transition freeze
> > No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runti=
mes
> > (e.g. java). There should be no changes that will cause major transiti=
ons.
> ...
> > No alterations to the Guix daemon or modules are accepted after this po=
int.
> > Packages and services in the 'minimal' package set should not be altere=
d.
> >
> > ### 5. Package set finalisation
> > Specify the package sets for this release. Identify all packages and t=
heir
> > inputs so that a full manifest for the release is created.
>=20
> It seems like you would need to clarify the toolchain package set the
> week prior.
>
Yes, agreed it's wrong. I'll adjust it to a bit earlier. We have 5 weeks be=
fore the release starts to bike-shed the package sets.
> > ### 7. Updates freeze
> > Major package updates are frozen on 'master' as the focus is on fixing =
any
> > blocking packages. Security updates still go to 'master'.
>=20
> Yay! This should also give the build farms a chance to "catch up" with
> builds.
>=20
Also AIUI we have world-rebuild with the ungraft. This is not my area of co=
mpetence so I'm hoping Andreas, Ludo, Efraim and others will comment about =
this area if the discussion develops ...=20
>
> > ### 8. Breaking changes to staging
> > To avoid a period of time where teams can't commit breaking changes, th=
ese are
> > sent to a new 'staging' branch, rather than directly to master. The ma=
ster
> > branch slows down from this week.
> ...
> > Team branches can still be folded into the release branch as long as ch=
anges are
> > minor package upgrades.
>=20
> If they are minor package upgrades, do you even need a team branch?
>=20
No, and generally the length of the freeze and where things go is something=
we need to debate. I want to avoid a big discussion about our team branche=
s, but I think we all know there are concerns.=20
> > ### 11. Branch and tag release branch
> > The master branch is tagged and a new release branch is created.
> >
> > * master branch: security only.
> > * release branch: security updates as normal. Only RC blocking bugs.
> >
> > Only security updates go to the master branch from week 9->13. All oth=
er
> > changes stay in a team branch or go to the `staging` branch. The focus =
on the
> > release branch is to stabilise so only RC bugs should be pushed.
>=20
> Spell out "RC" at least once in the document, presumably "Release
> Critical"?
Yes, Release Critical.
I had this in the Release team responsibilities: "communicate with the rele=
ase team and wider developers status and blockers"
I'll finesse the wording.
>=20
> > ### 13. Release candidate
> > Release artifacts are created for the release candidate. There's a fin=
al 2
> > weeks of testing with these artifacts.
>=20
> Not sure how you cram two weeks into week 13! (or... is that week 10?)
> :)
>
Heh! Using my terrible weeks it would be week 10 "release candidate", and t=
hen "final release" is week 12.
> > If there are no release blocking bugs discovered then the releas uses
> ^^ release ^^
> > these artifacts. If bugs are found/fixed then release artifacts are
> > regenerated as needed.
Thanks!
>
> As a downstream packager of Guix for Debian, I would appreciate
> (pre)release candidates be included earlier in the process somehow.
>=20
> Maybe even in sync with a weekly cadence in line with this release
> process?
>=20
> I usually do find bugs in the process of packaging Guix for Debian, and
> it would be nice to more easily catch those earlier.
(...)
I don't know how complex it would be to do that, but it makes sense. In wee=
k 6 we do "initial testing" which means we have to generate the release art=
ifacts, so assuming it's not too complicated we could then do a weekly cade=
nce from there.
> > ### 14. Final release
> > Final release is announced and new release artifacts are published.
>=20
> Yay!
>=20
>=20
> Thanks again, really glad to see some good thoughts and energy go into
> this!
Your welcome, look forward to follow-up comments on the topics above =3D-)
Steve / Futurile
[0] https://docs.fedoraproject.org/en-US/releases/
[1] https://wiki.ubuntu.com/SeedManagement
[2] https://xkcd.com/1172/
[3] https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024=
-the-results-part-2/
--e34lbz5dj6eqvo3s
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQIB6x23+hDA21fWHn1HUoW3O5vpwUCaB8fkgAKCRD1HUoW3O5v
p71CAP9rOrDl/23gbMCastSlDw89O4cGDgiV0o0m5wOvWcAUSwEA6yTMBqvzz2hs
Ubs7TN7kfndN/+rjC5DjO5XlDOXmgAk=
=L79l
-----END PGP SIGNATURE-----
--e34lbz5dj6eqvo3s--
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.Received: (at 78332) by debbugs.gnu.org; 10 May 2025 09:15:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 10 05:15:18 2025 Received: from localhost ([127.0.0.1]:43730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uDgIg-0004Mh-9f for submit <at> debbugs.gnu.org; Sat, 10 May 2025 05:15:18 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:38186) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <andreas@HIDDEN>) id 1uDgId-0004Gh-7L for 78332 <at> debbugs.gnu.org; Sat, 10 May 2025 05:15:16 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id C996320A; Sat, 10 May 2025 11:15:08 +0200 (CEST) Authentication-Results: hera.aquilenet.fr; none X-Virus-Scanned: Debian amavis at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavis, port 10024) with ESMTP id As0VqturYSTL; Sat, 10 May 2025 11:15:07 +0200 (CEST) Received: from jurong (176-179-191-150.abo.bbox.fr [176.179.191.150]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 5381A195; Sat, 10 May 2025 11:15:07 +0200 (CEST) Date: Sat, 10 May 2025 11:15:05 +0200 From: Andreas Enge <andreas@HIDDEN> To: Ekaitz Zarraga <ekaitz@HIDDEN> Subject: Re: GCD005: Regular and efficient releases Message-ID: <aB8ZGWUXd7zIPxnA@jurong> References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz> <6599e0d9-ce75-470d-bcbc-511da7aedf66@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6599e0d9-ce75-470d-bcbc-511da7aedf66@HIDDEN> X-Rspamd-Queue-Id: C996320A X-Spamd-Result: default: False [-9.57 / 15.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM(-2.97)[-0.990]; MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Action: no action X-Spamd-Bar: --------- X-Rspamd-Server: hera X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78332 Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello Ekaitz, Am Sat, May 10, 2025 at 12:59:32AM +0200 schrieb Ekaitz Zarraga: > Steve, you asked for my thoughts, and here they are: probably not what you > expected (: 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
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.Received: (at 78332) by debbugs.gnu.org; 9 May 2025 22:59:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 18:59:49 2025 Received: from localhost ([127.0.0.1]:41166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uDWh1-0001vx-VW for submit <at> debbugs.gnu.org; Fri, 09 May 2025 18:59:49 -0400 Received: from dane.soverin.net ([2a10:de80:1:4092:b9e9:229e:0:1]:41433) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <ekaitz@HIDDEN>) id 1uDWgv-0001vR-US for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 18:59:45 -0400 Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4ZvPZs6hFYzyYc; Fri, 9 May 2025 22:59:33 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4ZvPZs2j4BzPP; Fri, 9 May 2025 22:59:33 +0000 (UTC) Authentication-Results: smtp.soverin.net; dkim=pass (2048-bit key; unprotected) header.d=elenq.tech header.i=@elenq.tech header.a=rsa-sha256 header.s=soverin1 header.b=Hn2i5Uhr; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elenq.tech; s=soverin1; t=1746831573; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Z6zxfVTkN+ggAYwtyeVsdKM5MdJ+gpdjjqE3Uf0vwqg=; b=Hn2i5UhrlK/n4E+fvAQIBubfXmffnLu++iG6VogigJ5qD0HakqabuBJSJHvN77wBIycyG/ clQDGFByWPVyrlcu1z+tGWAM/Zkxcs2jpHhMXPB9ca03G3Coouq9lPEkI7MC4cMfjfnVRM cKfz1Tvim4vKiyh+Vr5TSrOfeJb8rW8Fy26WLzn26EagpOYlPLtZHKC2JfGeFq0ukAlfw8 5FLNtFBTy9bxlj2NB4GJ5sKCwdR7Py/CyqLLKDMbEM232mAdE3gabmft7gw65dflKHHKZJ QubGMWMpHMuepT921A4yk80l1V9kYJPhpmCgesURExGgwhOmGD6g4Ia1+2nMFA== X-CM-Envelope: MS4xfAeVRlSdy+zsYKsu3WJU6drpHN0Wr0LUrDuXpGoKD0PII+eitYOi25ALjmKrmj1J6+SxH9bzx273EPKCwdUn8LEHQ/eLfMtBgnZKTOOnuvGvX4yqqmxT FwsfjAxxfTr1/Aor7BX/5qyu3OCqdcSzEDxMJVVjSw39zuuX9D6stj2PsdePgLiD5eqPGcSInBNf0j92bKCgaNTcIWpWCikBRSHQg/pxSprgQLZRuaPTuIns YHAwtmh6+3e3B7XOIv38ZA== X-CM-Analysis: v=2.4 cv=d/oPyQjE c=1 sm=1 tr=0 ts=681e88d5 a=h3XoKhqn/SjcKs+fSIIrUg==:117 a=h3XoKhqn/SjcKs+fSIIrUg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=mDV3o1hIAAAA:8 a=SXzkmgPmAAAA:8 a=wTKzBlDhAAAA:8 a=kZaChOJbAAAA:8 a=KcFWP1huAAAA:20 a=KSb9T-wMAAAA:8 a=NEAV23lmAAAA:8 a=jrZFapw2SavYqMD0SL8A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=mAwK7uJ10rcA:10 a=5fH2sR7PB14A:10 a=uFQJuopWmF0A:10 a=EWLf6cg6Bh5aS0AxDgDu:22 a=ConqOrKQ8jGlcadNvAVz:22 a=m_bGliP6fJEUYRQkq_sd:22 a=KF4VuIdXkMyp4E_ug72i:22 a=yPy0HX4kI4LsAlP3oO-2:22 Message-ID: <6599e0d9-ce75-470d-bcbc-511da7aedf66@HIDDEN> Date: Sat, 10 May 2025 00:59:32 +0200 MIME-Version: 1.0 Subject: Re: GCD005: Regular and efficient releases To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz> Content-Language: en-US, es-ES, eu From: Ekaitz Zarraga <ekaitz@HIDDEN> Autocrypt: addr=ekaitz@HIDDEN; keydata= xsFNBGcvh/QBEACePF16wEeQaqfJNgeaSQB6ty6PzLaYtl8UVApPSCF1PYNEhDtxQOOpBXeu k6h68cjhRX7hmug8mAraXotw4aG4Z3kbUro4fzXOYW3rCi/mAm5NFXLUmBX3E1AV1pcD8hDA 5s3LeGzfTo4xRGTW4zTzxGEyrvbChkVib7wTSk52a/WkFas6l3sXnepF8HmIEOWkwQcYdcuo gaNDFP1kjZYvqfKJXmCZnY+lC8Zfe/vlD/x8FZQYBQ5xgXIfbSR0xlRz/XIHfJv6j+3myUUr 2UKMku1dkjlkhNkyfw+RypQzmbJ0oJ4bk76/ju0nnlN65/LvyeTVUh/2O2VnPnZ49keL8sqr APXF4di4pWT+/mPxfoEtiSDtjyzbr8+ajcwLa4SSKLlexqjZj8X6R4tt31Rf/Pliwe4TdPmd 2leE3BIJl9bAuslEvd5tqZ1oa3Zfb62tvpaJCRYMtOEWuGkYdyrwTW7UXJPQpam4X7WoW2jW c5aTpAnpnqIPzaWJmua1lGQjEXgt4xvVdhVmZq32fkTy/rXw9l5a+XU7N4/Zz8AR/0xO+UBc Q1J+wHADjL8Q0v0tZLEaiWL72AsxN3GMWNPXWAplaTPUNPUlNK0JPHwhTX/cQVkIc9avSKc3 BeUofC96d13I7QmRjQ0gcBaLtV9lMOuYwbC+6tb70x2fQsI3bwARAQABzSJFa2FpdHogWmFy cmFnYSA8ZWthaXR6QGVsZW5xLnRlY2g+wsGUBBMBCAA+FiEEXb4j05BTZSZ/jMdq/blSvT9z VtYFAmcvh/QCGwMFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ/blSvT9zVtbW CRAAkbla35s8RKhQBweqwEcdYDV2Zpt16OgENymjLs/qhh7Y9WgWZ0YraSNYDGCt6lemhior vrXX48+yZC98c8ZgCrr4Hmt8i/6TvJqVhwlZ9//3W/z/YuYDtUPBzRHgwM8tejiXmNqYM8lF Jg64pQaczmGAR29Xf0WTQegSociBSUg9eC7BS74Uh7UbHCgytyretoKmqJAp8SKE/Czt5x4R lXKVgGawzg1GerriwnNbudy0eyl1q0Pn7Q+K+tQ14EPDAM+QsGR/fBV4a3uYP6sBF+SdM+DO LX5MRVbWJ8O3kLmbAKQeLgSLlnYydMY/mTvjgxMAakfGCA4q69gmyDSB0fzAUm3c1JV5VwIo 63rykiOEB/k2m4aiiujH5kOC86sjb273+XXWlOhOEO/vKHHdAh+B7dnEEYUPXnUEMQ23PaF4 22u7C62kw3yH/krKr60t5FxcqNWtCOxEWc0WMZw12Q3Gw8+9oA5DI/f4gjlGvQiQWqj6dvoX vIDmifr0R3sTi6xh+udu2Rp8PsKOW8ZRyQ0/VOiwzBfQkf4PFowaiRp8LnkjLEVft6ruuA1h awO2SKKJ8WpgZPw5oMigZR5DgbunxMD4BcqmD7bSoTRV/ljx1I8UgAaQLPqVVnLt31iENtLv 43kPHl56AbYpAzcvf8nGU3KPhGOoByyuyph4RYDOwU0EZy+H9AEQANc9vw7DnBeNGKhq1Bg5 oiGII7npGXCChe7PB6CJjkvN6n1kXrvBYsaORXvZJPNgmBTKu/ETGYS0t0YeGlI4WTOK9dgB /7T8dngRmrGjPmZjryzfk18tXnJq0zoLixLizDT3FqV4jOG5KjPTxQvpdBMiX9oX4Je2OMqF d14fopLGav0rW7Fh5p83OSREpXbJUJJiUaH3p9U9Ss8IBHzr669PViAqe09EfxL/L0l1JIFj HQjJcg01PUXZAW6aPtd7q6eNCSLTXYPiDRQe2GdRUcB7WfqCogR/LEpzLLcd0NkxCnc0T6da rq2Dupt8rvQ95L4/cOGVcDUDOGE6U92XCkaCvUQkypxQCGKSEjbTFoLRG/4JQj0pAWSaqxPS 7hkTFql4qUAdRwzHN1ib6XedcFfqHSy2Mk5ttW8DaBGKhCm7Mn6+4smXENHSuQxCqHlCQ2m+ 9ogpbxavNVfAblE/ucxyfyo6FlDbGHEG3Yu5296kUPT7PqZLiR3KetMPJfCLY2jVPio3t4tD s7Sj41sG5aIwEApb0Zoz3bPBt5O5GUoPFnXyjO306WLxXrM2tjY38jwHxF1Qvs3HQTJgRei2 g3D3KiiR27cXXs/8lrr8tblr5J1tE4TaQCea5lDuEgTCDLnlcopoYcKpFAUBGQtzcNkudT9w sM2nf9y6INcUE3FlABEBAAHCwXwEGAEIACYWIQRdviPTkFNlJn+Mx2r9uVK9P3NW1gUCZy+H 9AIbDAUJA8JnAAAKCRD9uVK9P3NW1td1D/4xx8AbDKAKx9ezT6GdTZbK6FS66qRQCEzTa5MX ZCEogASOla71CB10l5fFtsRWCtNQLzmgwkFwhdxyjqendDgacc5v/71NBb5KpKni6wDJMeiG s3Lq3ZgWfHte3NZ99iSH+La3aBSFbCloJ/Yf/MJBkzrm1sTTKcgF9/i0pzkume5vtpKRDjjS z4abHu7qk4Sgi5gwWpoKFTT38q6nLP+9SUla3JJjNqU3gvn8kwv6KDMKc4marnSp/c+5O6E+ lNrxMdD0n8+io/Bf/UEI6BU8F7JshPq732bHN1NzUXvgMd4cNsAlvsWM8UCKZ4/usFl1euMM FOvnadZinsTHpXhahJzkYWA7nAKbCoNNq9LPtWxfjHsIfhs+QQafF31Pw+jqHqruB4tH0eiL abrz7kejaZvJdVipNIzRUWYnpP+18khep2UtT1n9VNs6QNb4cHPsoe+s4ga4ZK/klCdEhLya XtbcaNEHb7NZUOBj3HhKFgIY8PD1AptAObHjsUNF5+jfEnl+5WjwyTZTIgDRiOrwn8LWOANQ 0JpR69t06uJwmiogQgnlYe36YFaauHGQZFa+L+R2zgnGn8TnR4C3tH7gNAef9+PKqgmJT5pN IkFzlDmZi05E9xzhj4WQ/OOsqU64eHL2PaDk+2TdfrzNwNFbkABJ+C7BHNAytQ6h9cpUbg== In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spampanel-Class: ham X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78332 Cc: 78332 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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: > 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 > > > title: Regular and efficient releases > id: 005 > status: draft > discussion: https://issues.guix.gnu.org/78332 > authors: Steve George > sponsors: Andreas Enge, Ludovic Courtès, Efraim Flashner > date: <date when the discussion period starts> > SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later > --- > > # Summary > > Guix doesn't have regular release cycle which has led to infrequent new > releases. Sporadic releases are detrimental for our users, contributors and > the project. This GCD proposes we implement an annual release cadence and > simplify the release process to make releases easier. > > The project currently releases new versions of Guix on an ad hoc frequency. > The 1.4.0 release happened in December 2022 [^1], which is almost 2.5 years > ago, at the time of writing. > > The weaknesses in this release strategy are: > > 1. No clarity on when the next Guix release is. > 2. Releases are complex and toil for developers. > 3. Rolling updates aren't suitable for all users. > > This GCD proposes the following combined solution: > > 1. Regular releases: switch to a time-based release of Guix every year. > 2. Efficient releases: use *package sets* and *supported architectures* to > reduce the scope of work required to create a Guix release. > > The benefits will be: > > 1. New installations of Guix will be better because installation media and > manuals will be up to date, and the initial 'guix pull' will be faster. > 2. Package installation will improve for all users. Packages will be ungrafted > during each release cycle. > 3. Package quality will improve for all users, because regular releases will > provide a cadence for focusing on our quality. > 4. A regular cadence for promoting the project to potential users. Helping us > to inform more people about the benefits of using GNU Guix! > 5. A regular release cycle is a rallying point for our contributors giving them a > consistent calendar of when to focus on releases versus other hacking. > > Adding a slower-moving branch akin to Nix's stable could be an eventual goal as > it would increase Guix's suitability for some users and use-cases [^2]. However, > this GCD only sets out to implement regular releases which is a substantial > change that would be a big improvement for our users. > > > # Motivation > > Releases are important for any Free Software project because they update the > user experience and are a focal point for excitement [^3]. Regular releases > help us to improve the quality of our software by bringing focus, and > exercising regular usage scenarios (e.g. testing the installer). > > The majority of distributions follow time-based releases, six months is a > common cycle time. For further comparison see the research on the > [release strategies of distributions] (https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt) > . A summary is: > > - NixOS: releases every six months (May/November), both rolling release and > slower stable branch. > - OpenSUSE: rolling release, slow-roll release and fixed releases. > - Ubuntu: every six months, with 9 months maintenance. LTS releases every > 2 years. > - Debian: Every 2 years (not time fixed), with about six months of package > updates freeze before the release while bugs are ironed out. > > As a rolling release Guix immediately provides the latest improvements to > users. Consequently, it could be argued that releases are unnecessary. > However, they provide a focal point for the project to undertake additional > testing and stabilisation across the repository. They also ensure we update > installation media, documentation, themes and web site. > > A specific issue caused by irregular releases is that new users/installs face a > significant first "guix pull". This provides a poor initial user experience, > and in some cases may even deter users [^4]. Additionally, it requires the > project to keep old substitutes on our servers. > > Regular releases are also good for casual users because they provide an > opportunity for us to promote new features and improvements. For prospective > users promotional activity about the release means they are more likely to hear > about capabilities that will attract them to experiment with Guix. > > Many desktop distributions release every six months to align with the major > desktop environments (GNOME/KDE) who release two or three times a year. This is > why Nix (May/November) and Ubuntu (April/October) align their releases. > > Since Guix is used [extensively as a desktop] (https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/) > it would make sense to align with these upstream releases. However, given that > Guix is a volunteer project that doesn't have the practise of releasing it's > unrealistic to move to two releases a year. Something along these lines could > be a future goal [^5]. > > This GCD proposes an annual release cycle, with releases **in May**. > > To move onto this cycle the first release would be a little later: aiming for > the **November of 2025**, with a short cycle to release in May 2026. > > > ## Package Sets > > There are currently over 30,000 packages in the archive, it's unrealistic for > all packages to receive the same amount of QA effort for a release. > > Many other distributions focus attention on the critical parts of their > repository by identifying those packages that are required for a particular > user-case. For example, Arch Linux limits their efforts to a specific > repository (called "main"). Ubuntu identifies various seeds for specific > use-cases which determines their maintained packages; other packages outside > these sets do not receive security updates. > > Guix is both a package manager that can be hosted on other Linux distributions, > and a Linux distribution. Limiting the range of packages that receive attention > is consequently more complicated. Guix already has manifests to track which > packages are used by [Guix System's installer](https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm) > , so this proposal extends that concept. > > For this proposal Guix would identify key package sets which would receive the > most attention for QA'ing a release. > > The package sets would be: > > * minimal: packages required to boot and install a minimal Guix or Guix System > install. This would include the guix daemon, kernels, boot loaders, > file-systems and minimal utilities. > * standard: packages that create a core installation for all other uses. > * desktop: provides the packages necessary for a desktop. This would include > things like X11/Wayland, desktop environments, key applications and themes. > * server: provides packages and services for a server. This would include > standard server packages and services. > * hosted: provides packages and services which are necessary in hosted usage. > > Guix would still make all packages and services part of a release (the entire > archive), but only those in the `package sets` could block a release due to a > significant bug. The goal would be for this to be as small a set of packages > as reasonably possible. It would mean that developers could focus on the > critical packages and services during a release. As an example, this would > mean that a major issue in the Linux kernel could block a release, but not an > issue in a game. > > > ## Platforms and Architecture tiers > > Guix is built and maintained on multiple different architectures, and two > kernels (Linux, GNU Hurd). As the goal of the project is to maximise user > freedom this variety is significant and is a key motivator for developers. > > However, with limited resources (developer and CI) we want to make it as > efficient as possible to create a release. The more toil involved in a release > the less likely developers are to work on it. > > The [2025 Guix User Survey](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-2/) > showed that 98% of users were on x86_64 and 19% on AArch64. Consequently, the > proposal is the following tiers: > > - Primary architectures: > - Architectures: x86_64, AArch64 > - Kernel: Linux > - Coverage: all packages and services that are not explicitly platform > specific must work to be included in the archive. > - Package status: package updates should build for this architecture. If a > package update is broken it must not be pushed to users (e.g. master). > - Security: all packages that are maintained upstream receive updates > > - Alternative architectures > - Architectures: all others > - Kernel: Linux, Hurd > - Coverage: all packages and services that are not explicitly platform > specific may build > - Package status: package updates should work for this architecture. > Updates that do not build for this architecure, but do build for a primary > architecture may be pushed to users. > - Security: no commitment to providing security updates for this architecture. > > 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. > > > ## Release artifacts > > Using the primary architecture tier and the package sets would involve creating > the following release artifacts: > > - GNU Guix System ISO image > - GNU Guix System QCOW2 image > - GNU Guix installer > > Again in an effort to reduce developer toil, additional release artifacts could > be created but would not be part of the formal release testing and errors would > not block a release. > > > ## Release team and project > > A regular release cycle should galvanise all Guix developers to work on our > releases. But, to ensure there are sufficient people involved a call will be > put out to create a specific release team for each release project. We would > expect the final release team to be around four-six members. The release team > will work together to fix issues and test the various release artifacts. The > expectation is that the release projects will be as short as possible, around > a 12 week commitment with each team member having a few hours a week to take > part. > > To manage the release it's proposed that each release will have a Release Manager > role. The role of the Release Manager is to: > > - co-ordinate the release project > - communicate with the release team and wider developers status and blockers > - arbitrate changes to release blocking bugs, package sets and release > artifacts > - influence and assist teams to resolve problems > - define the release artifacts and create them > - encourage and excite **everyone to create and test the release** > > The Release Management role is likely to require the most effort, so it will > be rotated and consist of two people from the release team. For each release > there would be a primary person and a secondary person in the role. The > primary person is new to the role. The secondary person has previously done it > and is mentoring the new person. The impact of this is that each new release > manager is agreeing to take responsibility during two release cycles. > This system is modelled on the [Nix release management](https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt/nix-release-mgmt.md) > approach. > > One of the release team will take on the role of Release Advocate [^6]. They > will take responsibility for preparing the release announcement and > coordinating the creation of content to promote the new release (e.g. web site) > This role can be done by any member of the Guix community who has sufficient > interest. > > The final release team is: > > - a new Release Manager > - a returning Release Manager > - up to 4 other members, one of whom acts as the Release Advocate > > The Release Managers of each release will create and communicate a release > project plan setting out the stages and dates for each stage. To try and > galvanise the Guix development team to focus on the release it's envisioned > that a release project will be about 12 weeks. See Appendix 1: Release Project > Time-line for an example. > > In order to improve knowledge transfer and reduce the toil of doing releases > the Release Managers for a release will document the release process. There is > inspiration for this in [NixOS's release wiki](https://nixos.github.io/release-wiki/Home.html) > and we already have detailed [release documentation](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org) > . > > > # Cost of Reverting > > If regular releases were not successful then the project would switch back to > irregular releases. There would be no impact for exiting users as they will > be tracking the rolling release's master branch. > > If the project is able to successfully undertake regular releases then over > time it may be possible to undertake full releases every six months or some > other release cadence. > > > # Drawbacks and open issues > > There's no particular drawback to attempting regular release. It should be > noted that the project is entirely dependent on volunteers so it may be that > contributors don't have enough time available to achieve regular releases. If > that's the case we would revert back to irregular releases. > > There are various improvements that could be made to this process over time, > but no known issues. > > > # Appendix 1: Release Project Time-line > > To illustrate the major steps of a release project this is a rough time-line. > The aim is for a 12 week active release project, with the first one using 16 > weeks in total to give teams time to prepare. > > The current outline builds from our current [release document](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org) > > | Week of Project | Event | > | --- | --- | > | -5 | Nominate a release team | > | -4 | Notify teams of upcoming release | > | 01 | Release project start | > | 04 | Toolchain and transition freeze | > | 05 | Package set finalisation | > | 06 | Initial testing | > | 08 | Updates freeze | > | 08 | Breaking changes to staging | > | 08 | Ungraft master branch | > | 09 | Bugs and documentation focus | > | 09 | Branch and tag release branch | > | 09 | Testing and hard freeze | > | 10 | Release candidate | > | 12 | Final release | > | 13 | Staging merged to master | > | 14 | Release retrospective | > | 15+| Relax - it's done! | > > ### 1. Nominate a release team > Nominate a release team with two Release Managers (1 is the previous RM), and > up to 4 other people who will work on the release. Put out a call for a Release > Advocate who can be anyone in the Guix community who's willing. > > ### 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. > > ### 3. Release project start > Start the project with weekly updates to guix-dev and regular meetings of the > release team. Encourage participation in testing and identifying bugs from > the community. > > ### 4. Toolchain and transition freeze > No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtimes > (e.g. java). There should be no changes that will cause major transitions. > > Debian defines a transition as one where a change in one package causes changes > in another, the most common being a library. This isn't suitable for Guix since > any change in an input causes a change in another package. Nonetheless, any > change that alters a significant number of packages should be carefully > considered and updates that cause other packages to break should be rejected. > > No alterations to the Guix daemon or modules are accepted after this point. > Packages and services in the 'minimal' package set should not be altered. > > ### 5. Package set finalisation > Specify the package sets for this release. Identify all packages and their > inputs so that a full manifest for the release is created. > > ### 6. Initial testing > An initial testing sprint to look at packages, services, install media and > upgrade testing. This should identify: > > * packages or services that may need to be removed because they fail on a > primary architecture > * packages and services in the package sets install and can be used > * installation artifacts can be created and used > * example system definitions can be used > * system upgrades > > A build failure of a package or service will result in it being identified for > removal. A build failure of a package or service that's in a package set will > be marked as a blocker for the release. > > ### 7. Updates freeze > Major package updates are frozen on 'master' as the focus is on fixing any > blocking packages. Security updates still go to 'master'. > > ### 8. Breaking changes to staging > To avoid a period of time where teams can't commit breaking changes, these are > sent to a new 'staging' branch, rather than directly to master. The master > branch slows down from this week. > > This concept comes from the Nix project where they flow big changes into a > staging branch while they do release stabilisation to prevent big flows of > breaking changes into master which broke one of their releases [^7]. > > Team branches can still be folded into the release branch as long as changes are > minor package upgrades. > > ### 9. Ungraft master branch > Guix master is ungrafted to minimise the difference with users of the release > initial 'guix pull' experience. > > ### 10. Bugs and documentation focus > The master branch should be quiet at this point as everyone should focus on > testing and resolving any bugs. New documentation can also be done. > > ### 11. Branch and tag release branch > The master branch is tagged and a new release branch is created. > > * master branch: security only. > * release branch: security updates as normal. Only RC blocking bugs. > > Only security updates go to the master branch from week 9->13. All other > changes stay in a team branch or go to the `staging` branch. The focus on the > release branch is to stabilise so only RC bugs should be pushed. > > ### 12. Testing and Hard Freeze > RC bugs and issues should be solved for the release branch. > > Only changes that will fix a non-building package, or a bug in a package are > allowed. Ideally avoid new upstream versions, but it's acceptable to use a new > minor upstream version to solve a bug. > > Any non-building packages are removed. > > ### 13. Release candidate > Release artifacts are created for the release candidate. There's a final 2 > weeks of testing with these artifacts. If there are no release blocking bugs > discovered then the releas uses these artifacts. If bugs are found/fixed then > release artifacts are regenerated as needed. > > ### 14. Final release > Final release is announced and new release artifacts are published. > > ### 15. Staging merged to master > If there were any breaking changes placed onto the `staging` branch then these > can be merged into the `master` branch at this point. The master branch then > continues as normal. > > ### 16. Release retrospective > A retrospective is undertaken by the release team to understand how the release > process can be improved to make it more reliable for users and easier/efficient > for developers. > > ### 17. Relax! > The release has been cut, everyone is now excited, and hopefully all is well. > Take some time off from release work! There's some time built-in here to > relax and get back to other hacking before it's time to start again with the > next release. > > --- > > [^1]: https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/ > > [^2]: Examples of distributions that have cadences for different users and screnarios > are Nix's stable branch, OpenSUSE's SlowRoll branch and Ubuntu's LTS > (Long Term Support) releases. > > [^3]: the aspect of creating news and excitement for casual users is well-known > in the FOSS community. An example from > [GNOME's earlier days](https://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html). > > [^4]: GuixDays 2025 release discussion brought up examples of Guix not being > used to teach users because the initial pull was so slow that the > teaching session would have completed before 'guix pull' would finish. > We know guix pull being slow was identified by users as a challenge. > > [^5]: OpenSuse has a [SlowRoll branch](https://en.opensuse.org/Portal:Slowroll) > where they release a smaller set of package updates on a monthly basis. > This is an interesting innovation as it allows users to still benefit from > a rolling release but at a slower rate of change (fewer regressions). > They are also not dropping too far behind the rolling release, so there's > not as much maintenance for OpenSUSE developers dealing with an out of > date release branch and having to backport software. > > [^6]: Nix has the concept of a [Release Editor](https://nixos.github.io/release-wiki/Release-Editors.html) > who is responsible for improving the legibility of the release notes. Our > version extends the idea to make sure other artifacts and activities that > promote the release happen. > > [^7]: https://github.com/NixOS/rfcs/blob/master/rfcs/0085-nixos-release-stablization.md >
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.Received: (at 78332) by debbugs.gnu.org; 9 May 2025 21:55:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 17:55:15 2025 Received: from localhost ([127.0.0.1]:40784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uDVgY-0006YV-GR for submit <at> debbugs.gnu.org; Fri, 09 May 2025 17:55:14 -0400 Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:40426) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <steve@HIDDEN>) id 1uDVgV-0006Vw-2y for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 17:55:12 -0400 Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <steve@HIDDEN>) id 1uDVgN-004oSL-TI; Fri, 09 May 2025 23:55:03 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=futurile.net; s=selector1; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=nSbM0cLMKSPInxZI2qnso/Q6m9j1+6vd+sUwfaX8Qk0=; b=AwCg5C/bhjjzJNklJwtH+u89/d LxpBhe1AUkjUWXkvuoYJufyG9TKyEKPrIzPy/rslCKuRFjoSi6nozIucB2CegV2bcT8aWiEsPBJqa Pa6eNwPksdNT9Ky5YvUc2sRIyoFD5Qofgd+ZqpNqAMCSU3GjxVKvw91jANPulpOYKdVQmekdrYsN/ c/GiDrMl8th7pWbSBmKd5H5bJjc0l2tIM0ac3ApuLZ6+ehxOea7G4MWFBHs2S+jM4KoW4ZHOUtFB+ MSqusf5F8XDIl+wnYhiIOpsUqjVNUgGGvrpCJQAGnbiViO3rQhebHk0niz5tyxgmz42mSRA3P85II Pd5/8Y+A==; Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from <steve@HIDDEN>) id 1uDVgN-00030V-AV; Fri, 09 May 2025 23:55:03 +0200 Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)] (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93) id 1uDVgD-008x0G-GH; Fri, 09 May 2025 23:54:53 +0200 Date: Fri, 9 May 2025 22:54:52 +0100 From: Steve George <steve@HIDDEN> To: Greg Hogan <code@HIDDEN> Subject: Re: GCD005: Regular and efficient releases Message-ID: <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj> References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz> <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78332 Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Hi Greg, On 9 May, Greg Hogan wrote: > On Fri, May 9, 2025 at 8:54 AM Steve George <steve@HIDDEN> wrote: > > > [...] > > Adding a slower-moving branch akin to Nix's stable could be an eventual goal as > > it would increase Guix's suitability for some users and use-cases [^2]. However, > > this GCD only sets out to implement regular releases which is a substantial > > change that would be a big improvement for our users. > [...] > > 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. 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. > 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. (...) 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. > 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. > 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! > 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). 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. > 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. 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
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 21:24:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 17:24:55 2025
Received: from localhost ([127.0.0.1]:40562 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDVDC-0004e0-BG
for submit <at> debbugs.gnu.org; Fri, 09 May 2025 17:24:55 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:35502)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <steve@HIDDEN>)
id 1uDVD8-0004dg-Pi
for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 17:24:52 -0400
Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com)
by mailtransmit04.runbox.com with esmtps (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93)
(envelope-from <steve@HIDDEN>) id 1uDVD1-004nQZ-LB
for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 23:24:43 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=futurile.net; s=selector1; h=In-Reply-To:Content-Type:MIME-Version:
References:Message-ID:Subject:Cc:To:From:Date;
bh=F2WyEQLBsEv7h7Jwm4jasFAhuSthJrMO4xceo8uBOdk=; b=uwJg3S7DM0I6iG49UjpNV/axgu
mgi4MYivDLnkOA284dqe20l8V/4bP2FGoRnn3E7xjwTj5S5d/VAlZMBo/patauNbOowvbvFHD4HPL
A+mnD38cMnAfWHfZZHb0+p6zetjyafiGH1SlWMkkHBji5bdhrffTzOfwQsf/rBDEgY5HiYbKLKNWd
XAgUw5ufVkxhg1AreftU44Q4UMWBIpR8qzBROtMK8+Zg908nn60kCYQsRZIBptUs+yK5Jfxa2AsG6
WN7mYVMh5UrNZQAs/Gk/KoSf1SpahGBWt7VWdAZH6TIdy9TTH18/7H9ahwWI1nypAapjnDOBE+t3P
cfcKeRqw==;
Received: from [10.9.9.74] (helo=submission03.runbox)
by mailtransmit02.runbox with esmtp (Exim 4.86_2)
(envelope-from <steve@HIDDEN>)
id 1uDVD1-0000cW-4S; Fri, 09 May 2025 23:24:43 +0200
Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)]
(TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
id 1uDVCn-008q7B-FA; Fri, 09 May 2025 23:24:29 +0200
Date: Fri, 9 May 2025 22:24:28 +0100
From: Steve George <steve@HIDDEN>
To: Rutherther <rutherther@HIDDEN>
Subject: Re: GCD005: Regular and efficient releases
Message-ID: <l4armgnciaep33iazyscmv4jkxseklak3kusrvaaxfbdhgerih@d36lugi75wbp>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
<87bjs1x4p9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87bjs1x4p9.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 78332
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
On 9 May, Rutherther wrote:
>
> Hi Steve,
>
> thanks for this. I have a few notes left in the text, but generally I
> like this.
(...)
Thanks for the supportive comment, appreciate it and the detailed thoughts below.
> 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?
(...)
AIUI the project did 1.2.0->1.3.0->1.4.0. There isn't a proposal to change the numbering of the releases. I don't think it's _required_ to change it to implement this GDC.
Equally I'm very comfortable with yyyy.mm, perhaps something to discuss within the group?
> 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?
(...)
Always a risk! To keep the scope of this proposal realistic it only impacts the release artifacts so the installers. After an initial 'guix pull' the user will be back the rolling release of master. Consequently, for anything that goes "horribly wrong" the question is whether it's within the long-term "release artifacts", if it is then I agree the Release Team could re-roll the artefacts and label as a new minor release. I would leave it to the Release Team's discretion.
> Steve George <steve@HIDDEN> writes:
(...)
> > The benefits will be:
> >
> > 1. New installations of Guix will be better because installation media and
> > manuals will be up to date, and the initial 'guix pull' will be faster.
>
> 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 agree the initial pull is a significant problem. Nicolas Graves told me at Guix Days 2025 of Andrew Tropin talking about not using Guix in a lab set-up because the initial pull was so significant that the lab would have finished before it had completed!
Some solutions were discussed at Guix Days 2025 which (e.g. shallow copies, using a checkout cache, finding different ways to chain the commit auth) I think we should prioritise. IF that happened, THEN we'd be in the situation where releasing new artefacts improves the user experience both at initial install and initial usage.
(...)
> > As a rolling release Guix immediately provides the latest improvements to
> > users. Consequently, it could be argued that releases are unnecessary.
> > However, they provide a focal point for the project to undertake additional
> > testing and stabilisation across the repository. They also ensure we update
> > installation media, documentation, themes and web site.
>
> 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?
(...)
Agreed, I can add that.
Perhaps Vagrant can comment on the postive (or negative) aspects of having a regular release from Guix when packaging Guix for a distribution (Debian).
> > Many desktop distributions release every six months to align with the major
> > desktop environments (GNOME/KDE) who release two or three times a year. This is
> > why Nix (May/November) and Ubuntu (April/October) align their releases.
> >
> > Since Guix is used [extensively as a desktop] (https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/)
> > it would make sense to align with these upstream releases. However, given that
> > Guix is a volunteer project that doesn't have the practise of releasing it's
> > unrealistic to move to two releases a year. Something along these lines could
> > be a future goal [^5].
> >
> > This GCD proposes an annual release cycle, with releases **in May**.
>
> 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?
(...)
The number of people we have working on Guix, and the bandwidth they have "as volunteers" is the constraint we're working with. In a context where our archive is very large compared to those that many core teams work on (see extended notes on other distributions I put togeher). The balance I've tried to strike is how to make a concrete step forward in predictability/stability without having unrealistic expectations on what we can achieve. I hope that's clear in the GCD!
Given those constraints a practical step forward it to introduce `package sets` which limit the amount of work around a release. This doesn't directly address whether a particular desktop is up to date, but it does mean we don't spend time fixing parts of the package archive that don't directly lead to an installed system (the example I use is games).
The Release Team would have to work in conjunction with the Teams on the package sets, there's initial work here:
https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm
There's a possible secondary "focus" benefit where we'd all know that we're targeting $SPRING for a release, so the whole group would (I hope) pay attention on the key packages in the package sets.
I have no strong feel on when in the $SPRING it is, so if the group wants June then great.
(...)
> > # Appendix 1: Release Project Time-line
> >
> > To illustrate the major steps of a release project this is a rough time-line.
> > The aim is for a 12 week active release project, with the first one using 16
> > weeks in total to give teams time to prepare.
> >
> > The current outline builds from our current [release document](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
> >
> > | Week of Project | Event |
> > | --- | --- |
> > | -5 | Nominate a release team |
> > | -4 | Notify teams of upcoming release |
> > | 01 | Release project start |
> > | 04 | Toolchain and transition freeze |
> > | 05 | Package set finalisation |
> > | 06 | Initial testing |
> > | 08 | Updates freeze |
> > | 08 | Breaking changes to staging |
> > | 08 | Ungraft master branch |
> > | 09 | Bugs and documentation focus |
> > | 09 | Branch and tag release branch |
> > | 09 | Testing and hard freeze |
> > | 10 | Release candidate |
> > | 12 | Final release |
> > | 13 | Staging merged to master |
> > | 14 | Release retrospective |
> > | 15+| Relax - it's done! |
(...)
> > ### 4. Toolchain and transition freeze
> > No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtimes
> > (e.g. java). There should be no changes that will cause major transitions.
>
> 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.
(...)
This sets out a specific freeze period where we wouldn't make those changes once a year, so 9 weeks in a year for major transitions.
It's somewhat arguable about how quickly we're making transition changes at the moment. Look at the available versions of toolchains from Perl, Python and these are taking 3-4 months on team branches.
If we were in a position where we regularly had transitions ready to go ("if they were ready") then we could look at ways to shorten.
To avoid developers feeling blocked up toolchain/transition changes can go to a <staging or some-name> branch.
(...)
> > Debian defines a transition as one where a change in one package causes changes
> > in another, the most common being a library. This isn't suitable for Guix since
> > any change in an input causes a change in another package. Nonetheless, any
> > change that alters a significant number of packages should be carefully
> > considered and updates that cause other packages to break should be rejected.
> >
> > No alterations to the Guix daemon or modules are accepted after this point.
>
> 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.
I'll amend that to say 'Guix daemon' as this is still the same concept about breaking changes.
In _all cases_ security updates will still be allowed as we don't want to negatively impact users.
New updates and packages keep flowing through master until 'Updates freeze' (week 8).
>
> > Packages and services in the 'minimal' package set should not be altered.
> >
> > ### 5. Package set finalisation
> > Specify the package sets for this release. Identify all packages and their
> > inputs so that a full manifest for the release is created.
> >
> > ### 6. Initial testing
> > An initial testing sprint to look at packages, services, install media and
> > upgrade testing. This should identify:
> >
> > * packages or services that may need to be removed because they fail on a
> > primary architecture
>
> 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 in the minimal package set should not be altered', so I think
> it should be mentioned it doesn't apply to those packages.
>
In terms of a package that works on one primary architecture but not on another the Release Team would have some options on how to mitigate:
1. Fix it to work on both architectures
2. Promote an alternative for that architecture
3. Document as a limitation, with a workaround in the release notes
4. Remove it from the archive
In part the discussion should be about whether it's a regression or a case where package 'foo' has never worked on that architecture. I would leave it to the Release Team to make a case-by-case decision.
If the decision was to remove the package note that it would go through the current Deprecation Policy which notifies and gives developers a two months to pick up the package.
The section earlier about the Platforms and Architecture tiers should lay this out clearly - anything I can improve there to make it clearer?
> > * packages and services in the package sets install and can be used
> > * installation artifacts can be created and used
> > * example system definitions can be used
> > * system upgrades
> >
> > A build failure of a package or service will result in it being identified for
> > removal. A build failure of a package or service that's in a package set will
> > be marked as a blocker for the release.
> >
> > ### 7. Updates freeze
> > Major package updates are frozen on 'master' as the focus is on fixing any
> > blocking packages. Security updates still go to 'master'.
>
> So 5 weeeks. (I am counting the retrospective week btw)
> Maybe the text should mention how many weeks the freeze is for so it's
> easier to orient? It seems important to me.
From 'Updates Freeze' (week 8) to 'Staging merged to master' (week 13) so 5 weeks in this plan. For those 5 weeks updates would go to the team branches or to 'staging'. After staging is merged (week 13) then team branches can be merged into master and we proceed as normal.
The main thing is how short a time period can we do this in, since we'd only have from week 8->10 to ungraft the master branch, do the release branch, test the release and fix any RC bugs.
The balance is a window that lets us focus on the release without divergence that would destabilise, versus a long closed window which is bad for our rolling release. Given the volunteer nature of the team, 5 weeks seemed about right but we can iterate this as we learn.
In my mind this project plan is an initial one, and then as we move forward from release to release each Release Team can iterate and improve.
> >
> > ### 8. Breaking changes to staging
> > To avoid a period of time where teams can't commit breaking changes, these are
> > sent to a new 'staging' branch, rather than directly to master. The master
> > branch slows down from this week.
> >
> > This concept comes from the Nix project where they flow big changes into a
> > staging branch while they do release stabilisation to prevent big flows of
> > breaking changes into master which broke one of their releases [^7].
>
> Nix doesn't use staging because of that, they use it always, mostly
> because the CI cannot build the whole package set. They don't use
> grafts, so there are world rebuilds like two times a month, when the
> staging merges to master, and they do that only if staging has already
> been built so that people get substitutes.
>
> I think this is a misunderstanding, the linked text states that breaking
> changes shouldn't be merged to staging branch, not to master branch. In
> turn, it also isn't merged to master branch, because staging is merged
> there, quite regularly. This can be most easily seen from the table they
> have with affected branches mentioned.
>
> So while I agree with the general motion that changes should be merged
> somewhere else, it's not right to state Nix does this.
Overloaded use of "staging" - I should have used a different branch name.
> By the way, since you linked it already, citing their drawbacks
>
> Citing from [^7]:
> > Breaking changes to Release Critical Packages will have to wait a
> > maximum of 4 weeks to be merged into staging. Other breaking changes
> > targeting staging will have to wait a maximum of 2 weeks to be merged.
> > Staging-next iterations will follow a 1 week development cycle during
> > the release timeline. Breaking changes to Release Critical Packages
> > will not appear in master for around 7 weeks (4 weeks being disallowed
> > to be merged to staging, 1 week for last staging-next during ZHF, ~2
> > weeks average in staging-next). Pull requests which are able to target
> > master will not be interrupted d
Their RFC is worth reading, I found it really interesting. It's definitely a balancing act between wanting to do stabilisation and meanwhile teams want to move forward. If too many changes flow in then the whole release is destabilised, equally how long a closed window makes sense!
> So they do have 7 week period to not merge anything critical to master,
> that's less than what is proposed here. I think it should be kept to as
> low number as reasonably possible. That probably have to be analyzed,
> and I think the longer time from bigger projects, like GNOME, the more
> time to prepare to it even before the release schedule kicks in.
(...)
For everyone else who isn't as aware (as you are) of Nix's details:
1. I encourage you to read their release wiki which covers many of the aspects they are trying to balance: https://nixos.github.io/release-wiki/Release-Editors.html
2. I worked up a summary of Nix's release strategy (as I understood it): https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt/nix-release-mgmt.md
I would also love PR's on the release management notes to fix things etc! I covered Nix, Arch and Ubuntu - I also have some raw notes on Fedora if anyone's interested.
I agree with as "low as possible", I've been cautious because it's a small volunteer team - I'm open to what the group thinks.
> Back to Steve's message:
> >
> > Team branches can still be folded into the release branch as long as changes are
> > minor package upgrades.
> >
> > ### 9. Ungraft master branch
> > Guix master is ungrafted to minimise the difference with users of the release
> > initial 'guix pull' experience.
>
> Could you clarify what this means?
Someone more experienced that me should address this aspect in all it's gory details!
> > ### 10. Bugs and documentation focus
> > The master branch should be quiet at this point as everyone should focus on
> > testing and resolving any bugs. New documentation can also be done.
> >
> > ### 11. Branch and tag release branch
> > The master branch is tagged and a new release branch is created.
> >
> > * master branch: security only.
> > * release branch: security updates as normal. Only RC blocking bugs.
> >
> > Only security updates go to the master branch from week 9->13. All other
> > changes stay in a team branch or go to the `staging` branch. The focus on the
> > release branch is to stabilise so only RC bugs should be pushed.
>
> Am I reading correctly, no updates whatsoever for 4/5 weeks!! :O
> Shouldn't this at least only affect the packages in the package sets?
> Even so, feels like too long.
(...)
Correct, only security to master for 5 weeks.
Since we have to degraft the whole of the tree, cut a release, test that it installs as a Linux distro, and that it installs as a package manager on the popular Linux distros - this time will fly!
I actually don't have a fixed view on the window, so open to what the group thinks is achievable!
Steve / Futurile
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 19:49:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 15:49:09 2025
Received: from localhost ([127.0.0.1]:40167 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDTiW-0007P1-Vy
for submit <at> debbugs.gnu.org; Fri, 09 May 2025 15:49:09 -0400
Received: from cascadia.aikidev.net ([173.255.214.101]:38814)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <vagrant@HIDDEN>)
id 1uDTiS-0007O9-4H
for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 15:49:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=debian.org;
s=1.vagrant.user; t=1746820137;
bh=V/M6AF5iNxhvTr9LDxOlrMOjyHvvOkNyNqApczmAetE=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=a+T0woYYPM/RsgqAPUZifyk8wKi/flWrR0xmMeE3T0Hc7g8TAxqTpa1feEHP8kbDZ
quLfYzbNmLuDpktAWFjIj1ApIq4oiKKzNjwQtkCGhbUolBd6Nl+JahjYFt3r+39Mul
WhSZtqPLqNw0veUZ+GYGM46p1SGrgSBiaMdizaR020Q2QU0ky6mUU9kX4sow88aMvM
3S1mEmVH8R/Jk1QszMTJg94RSD0fvPB0GhlMVw90+zp6TktArjOVcX5RH7jvV2b2Si
yC8nQXAiK2q1g7qNJM07rCQ/RuE6+UEfYA9/PALxcfHUezXWsKnMJJmYehJMeQdgHn
8TDzkbTc7L4Zg==
Received: from localhost (unknown [IPv6:2600:3c01:e000:21:7:77:0:50])
by cascadia.aikidev.net (Postfix) with ESMTPSA id 6972F8335;
Fri, 9 May 2025 12:48:57 -0700 (PDT)
From: Vagrant Cascadian <vagrant@HIDDEN>
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Subject: Re: GCD005: Regular and efficient releases
In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
Date: Fri, 09 May 2025 12:48:32 -0700
Message-ID: <8734ddpnu7.fsf@wireframe>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78332
Cc: 78332 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
On 2025-05-09, Steve George wrote:
> 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! ...
Thanks for nudging this forward! :)
> # Summary
>
> Guix doesn't have regular release cycle which has led to infrequent new
> releases. Sporadic releases are detrimental for our users, contributors and
> the project. This GCD proposes we implement an annual release cadence and
> simplify the release process to make releases easier.
>
> The project currently releases new versions of Guix on an ad hoc frequency.
> The 1.4.0 release happened in December 2022 [^1], which is almost 2.5 years
> ago, at the time of writing.
>
> The weaknesses in this release strategy are:
>
> 1. No clarity on when the next Guix release is.
> 2. Releases are complex and toil for developers.
> 3. Rolling updates aren't suitable for all users.
>
> This GCD proposes the following combined solution:
>
> 1. Regular releases: switch to a time-based release of Guix every year.
> 2. Efficient releases: use *package sets* and *supported architectures* to
> reduce the scope of work required to create a Guix release.
>
> The benefits will be:
>
> 1. New installations of Guix will be better because installation media and
> manuals will be up to date, and the initial 'guix pull' will be faster.
> 2. Package installation will improve for all users. Packages will be ungrafted
> during each release cycle.
> 3. Package quality will improve for all users, because regular releases will
> provide a cadence for focusing on our quality.
> 4. A regular cadence for promoting the project to potential users. Helping us
> to inform more people about the benefits of using GNU Guix!
> 5. A regular release cycle is a rallying point for our contributors giving them a
> consistent calendar of when to focus on releases versus other hacking.
>
> Adding a slower-moving branch akin to Nix's stable could be an eventual goal as
> it would increase Guix's suitability for some users and use-cases [^2]. However,
> this GCD only sets out to implement regular releases which is a substantial
> change that would be a big improvement for our users.
>
>
> # Motivation
>
> Releases are important for any Free Software project because they update the
> user experience and are a focal point for excitement [^3]. Regular releases
> help us to improve the quality of our software by bringing focus, and
> exercising regular usage scenarios (e.g. testing the installer).
>
> The majority of distributions follow time-based releases, six months is a
> common cycle time. For further comparison see the research on the
> [release strategies of distributions] (https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt)
> . A summary is:
...
> - Debian: Every 2 years (not time fixed), with about six months of package
> updates freeze before the release while bugs are ironed out.
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.
> Many desktop distributions release every six months to align with the major
> desktop environments (GNOME/KDE) who release two or three times a year. This is
> why Nix (May/November) and Ubuntu (April/October) align their releases.
...
> This GCD proposes an annual release cycle, with releases **in May**.
>
> To move onto this cycle the first release would be a little later: aiming for
> the **November of 2025**, with a short cycle to release in May 2026.
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!
> ## Package Sets
...
> Guix is both a package manager that can be hosted on other Linux distributions,
> and a Linux distribution. Limiting the range of packages that receive attention
> is consequently more complicated. Guix already has manifests to track which
> packages are used by [Guix System's installer](https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm)
> , so this proposal extends that concept.
>
> For this proposal Guix would identify key package sets which would receive the
> most attention for QA'ing a release.
>
> The package sets would be:
>
> * minimal: packages required to boot and install a minimal Guix or Guix System
> install. This would include the guix daemon, kernels, boot loaders,
> file-systems and minimal utilities.
This seems a reasonable broad-strokes starting point, nice!
> * standard: packages that create a core installation for all other
> uses.
I fail to see a distinction between minimal and standard, perhaps due to
"core installation", so this perhaps could use a bit more elaboration.
> * desktop: provides the packages necessary for a desktop. This would include
> things like X11/Wayland, desktop environments, key applications and themes.
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...
> * server: provides packages and services for a server. This would include
> standard server packages and services.
What are "standard server packages and services" ?
> * hosted: provides packages and services which are necessary in hosted usage.
What are these?
> ## Platforms and Architecture tiers
>
> Guix is built and maintained on multiple different architectures, and two
> kernels (Linux, GNU Hurd). As the goal of the project is to maximise user
> freedom this variety is significant and is a key motivator for developers.
...
> - Primary architectures:
> - Architectures: x86_64, AArch64
> - Kernel: Linux
> - Coverage: all packages and services that are not explicitly platform
> specific must work to be included in the archive.
> - Package status: package updates should build for this architecture. If a
> package update is broken it must not be pushed to users (e.g. master).
> - Security: all packages that are maintained upstream receive updates
>
> - Alternative architectures
> - Architectures: all others
> - Kernel: Linux, Hurd
> - Coverage: all packages and services that are not explicitly platform
> specific may build
> - Package status: package updates should work for this architecture.
> Updates that do not build for this architecure, but do build for a primary
> architecture may be pushed to users.
> - Security: no commitment to providing security updates for this architecture.
>
> 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.
Sounds reasonable.
> ## Release artifacts
>
> Using the primary architecture tier and the package sets would involve creating
> the following release artifacts:
>
> - GNU Guix System ISO image
> - GNU Guix System QCOW2 image
> - GNU Guix installer
>
> Again in an effort to reduce developer toil, additional release artifacts could
> be created but would not be part of the formal release testing and errors would
> not block a release.
Do we currently have all these for x86_64-linux and aarch64-linux, the
two proposed primary architectures?
> # Drawbacks and open issues
>
> There's no particular drawback to attempting regular release. It should be
> noted that the project is entirely dependent on volunteers so it may be that
> contributors don't have enough time available to achieve regular releases. If
> that's the case we would revert back to irregular releases.
>
> There are various improvements that could be made to this process over time,
> but no known issues.
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. :)
> # Appendix 1: Release Project Time-line
>
> To illustrate the major steps of a release project this is a rough time-line.
> The aim is for a 12 week active release project, with the first one using 16
> weeks in total to give teams time to prepare.
Ambitious, but may as well aim high!
> The current outline builds from our current [release document](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
>
> | Week of Project | Event |
> | --- | --- |
> | -5 | Nominate a release team |
> | -4 | Notify teams of upcoming release |
> | 01 | Release project start |
> | 04 | Toolchain and transition freeze |
> | 05 | Package set finalisation |
> | 06 | Initial testing |
> | 08 | Updates freeze |
> | 08 | Breaking changes to staging |
> | 08 | Ungraft master branch |
> | 09 | Bugs and documentation focus |
> | 09 | Branch and tag release branch |
> | 09 | Testing and hard freeze |
> | 10 | Release candidate |
> | 12 | Final release |
> | 13 | Staging merged to master |
> | 14 | Release retrospective |
> | 15+| Relax - it's done! |
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!
> ### 1. Nominate a release team
(a.k.a. ### -5.)
> ### 4. Toolchain and transition freeze
> No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtimes
> (e.g. java). There should be no changes that will cause major transitions.
...
> No alterations to the Guix daemon or modules are accepted after this point.
> Packages and services in the 'minimal' package set should not be altered.
>
> ### 5. Package set finalisation
> Specify the package sets for this release. Identify all packages and their
> inputs so that a full manifest for the release is created.
It seems like you would need to clarify the toolchain package set the
week prior.
> ### 7. Updates freeze
> Major package updates are frozen on 'master' as the focus is on fixing any
> blocking packages. Security updates still go to 'master'.
Yay! This should also give the build farms a chance to "catch up" with
builds.
> ### 8. Breaking changes to staging
> To avoid a period of time where teams can't commit breaking changes, these are
> sent to a new 'staging' branch, rather than directly to master. The master
> branch slows down from this week.
...
> Team branches can still be folded into the release branch as long as changes are
> minor package upgrades.
If they are minor package upgrades, do you even need a team branch?
> ### 11. Branch and tag release branch
> The master branch is tagged and a new release branch is created.
>
> * master branch: security only.
> * release branch: security updates as normal. Only RC blocking bugs.
>
> Only security updates go to the master branch from week 9->13. All other
> changes stay in a team branch or go to the `staging` branch. The focus on the
> release branch is to stabilise so only RC bugs should be pushed.
Spell out "RC" at least once in the document, presumably "Release
Critical"?
> ### 13. Release candidate
> Release artifacts are created for the release candidate. There's a final 2
> weeks of testing with these artifacts.
Not sure how you cram two weeks into week 13! (or... is that week 10?)
:)
> If there are no release blocking bugs discovered then the releas uses
^^ release ^^
> these artifacts. If bugs are found/fixed then release artifacts are
> regenerated as needed.
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.
> ### 14. Final release
> Final release is announced and new release artifacts are published.
Yay!
Thanks again, really glad to see some good thoughts and energy go into
this!
live well,
vagrant
--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCaB5cEAAKCRDcUY/If5cW
qmcvAQChBe2Pej7p14rBcXiOdwid8XY6WaWoFEQfQyoVG1xzCQD/Y5VLsm/EUiVe
n6fVTQIqIrqhnT7Q/O15iBhrDtaAEQk=
=njw/
-----END PGP SIGNATURE-----
--=-=-=--
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 16:18:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 12:18:32 2025
Received: from localhost ([127.0.0.1]:38799 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDQQh-0005KW-Rx
for submit <at> debbugs.gnu.org; Fri, 09 May 2025 12:18:32 -0400
Received: from mail.z572.online ([88.99.160.180]:58090)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <z572@HIDDEN>) id 1uDQQe-0005KK-JG
for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 12:18:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=z572.online; s=me;
t=1746807922;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=MgLhXdr/4pHrCjsdnK8ch6Biw+JCKYxF9ap4ksD7rUQ=;
b=FbAKdQpNqqfSuDKm2LfgaigjCrqiO7wG6xW5JR5R/NWa6eXbzdpWlH6Kfi1CueuelKng4l
QghXwe/GBxYVlKsEpgqfrDUyflReD93IPIuAFqXxL3vRwTiVah+EDzidn20LBsSzPRtkMI
cZuGyRVs5ns7229LKACD4CiicJxo3GY=
Received: from m (<unknown> [61.174.159.83])
by mail.z572.online (OpenSMTPD) with ESMTPSA id 229419da
(TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
Fri, 9 May 2025 16:25:21 +0000 (UTC)
From: Z572 <z572@HIDDEN>
To: Steve George <steve@HIDDEN>
Subject: Re: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of
GCD005 'Regular and efficient releases'.
In-Reply-To: <gqowz5fh4txxxaubcttltsao6atw7u6ryedp2aorsnyjmsios5@hqn5shp2fqfj>
(Steve George's message of "Fri, 9 May 2025 15:01:05 +0100")
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
<87msbmj5hp.fsf@HIDDEN>
<gqowz5fh4txxxaubcttltsao6atw7u6ryedp2aorsnyjmsios5@hqn5shp2fqfj>
User-Agent: mu4e 1.12.9; emacs 30.0.92
Date: Sat, 10 May 2025 00:18:15 +0800
Message-ID: <87ecwxkbaw.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Steve George <steve@HIDDEN> writes: > On 9 May, Z572
wrote: >> Steve George <steve@HIDDEN> writes: >> >> > + >> > +### 8.
Breaking changes to staging >> > +To avoid a period of time where teams can't
commit breaking changes, these [...]
Content analysis details: (2.5 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: z572.online (online)]
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.99.160.180 listed in bl.score.senderscore.com]
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.99.160.180 listed in sa-trusted.bondedsender.org]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
X-Debbugs-Envelope-To: 78332
Cc: 78332 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Steve George <steve@HIDDEN> writes: > On 9 May, Z572
wrote: >> Steve George <steve@HIDDEN> writes: >> >> > + >> > +### 8.
Breaking changes to staging >> > +To avoid a period of time where teams can't
commit breaking changes, these [...]
Content analysis details: (2.5 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.99.160.180 listed in bl.score.senderscore.com]
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.99.160.180 listed in sa-trusted.bondedsender.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: z572.online (online)]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Steve George <steve@HIDDEN> writes:
> On 9 May, Z572 wrote:
>> Steve George <steve@HIDDEN> writes:
>>=20
>> > +
>> > +### 8. Breaking changes to staging
>> > +To avoid a period of time where teams can't commit breaking changes, =
these are
>> > +sent to a new 'staging' branch, rather than directly to master. The =
master
>>=20
>> 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.
>>=20
>
> 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.
I don't have any idea, 202509-next-master might be good, I don't know
what others think
--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEfr6klGDOXiwIdX/bO1qpk+Gi3/AFAmgeKscACgkQO1qpk+Gi
3/BMOxAArqq/sgyKGq2EAJORvj8wAmHP0UZaQpRCXLXhKOaKJ1gdGToegbaM46PC
YZRx/FGHuVqyWGwEJRK/veEucAWw08zrtQURgtERkGyrYHPWRYbrhLaSp0m8qIDt
uIc15UseErWTOBYn7/9q28b8iK7t3BcU7sH/71bNgLq/aZqfgF5P7x2oe1vLxJr/
XKLj9Ujk6EqJESDt7JbcANqleIrW4ASvxbgXL12CDvY9ylctEl3E01HAHYdRRiBS
Zdbp4sD82vB47+857thScxE5dLQn6DhsqamkJ5UKpYtX8y9UcmMCdjMls+Gx9KhK
KbMk35vC/jbrpKku0lZ2PRm9FKd2jBtCzRyR85L3B+A8ukGhaGDmL8gLSIJc+gvp
NTSDZJcMtcUg4nVtkkqDfoltjzQzUklYDFG3cgsV7Uamt/wCqLLopHL99BaIeEYJ
FkqiwI6RZkqeTXKvnFUpvP252ihjSUfcNM4ie92idfCdOFuNa7obd5yowchfUOgf
uKJ5LmNJ7BpJyt4vwimy5CMqiB5T6xt8uVrn5qOMzILYhslt5tj6w6uPI3oS2se9
1z/Jcwp7+m/MMHbeRyD7EWQi5ZfC2Fda02LQh6VmgAGI/bERutYft+Cnr9kyFksq
vqlrjs2gqzkf1bQixuC7iPlJBDaT38wvNUt1oFz6HNwFCfjGG/Q=
=9wAj
-----END PGP SIGNATURE-----
--=-=-=--
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.Received: (at 78332) by debbugs.gnu.org; 9 May 2025 15:35:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 11:35:24 2025 Received: from localhost ([127.0.0.1]:38560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uDPkx-0002pT-Ff for submit <at> debbugs.gnu.org; Fri, 09 May 2025 11:35:24 -0400 Received: from mail-ot1-x32b.google.com ([2607:f8b0:4864:20::32b]:47293) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <code@HIDDEN>) id 1uDPks-0002p8-8g for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 11:35:19 -0400 Received: by mail-ot1-x32b.google.com with SMTP id 46e09a7af769-72b82c8230aso782334a34.2 for <78332 <at> debbugs.gnu.org>; Fri, 09 May 2025 08:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=greghogan-com.20230601.gappssmtp.com; s=20230601; t=1746804912; x=1747409712; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=N0/LgziI4FiRN55zZAOGR3AzYgFLKa5Vz0EfpTdqImU=; b=dtYLgAuQYKb3fJpczMhjGf6iIJwafXxEkYt5KZmzWLLqXDbtsqXI5n+IbE+jgQI3QV kTovOiEGFmCxqTVBU86+5JQG+VeJPNUCNKtSTxYbURZyAGEMamcGYDMkXDE+51QKFrK5 DqmSA08LVLStmEyNT1+L+cJHF7Xk9Zg3e/P8nOHpwKbCJAL9ndqLsBxTgTx8RmLDD6B4 3ITEtjzVlvqrV04Lq+prWdT+mmjMjkTcxAw3NCjlxko5MP8VSuWl8MNuTvqk0GEH8bC8 6s6fwvq5iHcQ2GTGr3il28tc3096VDXZVfreWU+AU6Qda7I/9ZgiIHmKY4dAxasKO9vT 6nBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746804912; x=1747409712; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=N0/LgziI4FiRN55zZAOGR3AzYgFLKa5Vz0EfpTdqImU=; b=MNK9AEjeBIIqXEuKU3ZCpjH2VpeaBXu5oBgV3TCzHgvE7roWE3uLBuO12atU/a4Glo lGkY3LxIHiIt+GSzJMc+SZws7rtDZ+eal4r2UplwvdmH2n5TxJOawIPtPhj9nb8eJsP6 htRyKjs+DGFoavX4eOEw8FmQ7VwQJ9wWfX96CWA1MsULVA5rjz3v0yuzcrIVa//gjNB9 Av4TtxKanGPKDbykPnEczxKVzbWAMHmUYKmEzIqzQlC9P+cbZbLc0m1AfMvqJNCEth+J WReYRrjjyR8Fvn01ym6IQsppaCm5En5NUCu5l+y86obYl2wliR0BWZ2O3vqcXx48vmyb jwOw== X-Forwarded-Encrypted: i=1; AJvYcCXV85fgrzKf3ZIfRUm2g7LMiouZUDmkoyUu5gln/aIdyeXCQEhyn/VyTHwSbK1ysLoBI6Od3g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxhRH/iYh1ko/lOguscFvC/jVTd8Yd98zbntieC8mcDFTKft/D1 TguQg6i6AblwHQV5QDVh1dDED4fvwYqQZye0Ff9tQKUlaR4PSGcvSXStKxejbVOu1ye1deedlrl dbDoUhN3UUGQILR4blLYhtLcf4Zl/R46HdqCH/g== X-Gm-Gg: ASbGncsIIbOvKhKZZqqrPYvzrmzjsJSmrX4oVOY6c+M75xTEQJc/zN5FtO0SJfR7vTd lMs+HZ0axCqpTcvbmQRe5MBRYtIByhLjvpcPc1q3U+QqjQ3/2ZOX5l9DXWfQb0BEZPLUJpFgaYg O9RaUiYZz7ZlsQ7/SaQ3lHgwHFnCaacntX X-Google-Smtp-Source: AGHT+IHqgzFYl8AsNgwVdCwTxn/UHLwaQLnt24Ph190w4yv/+ZkCgZMMh5VNFki+sUkeFj27vStCgnjlIM24jEbfFD8= X-Received: by 2002:a05:6830:925:b0:727:3439:5bec with SMTP id 46e09a7af769-73226a192d7mr2857179a34.15.1746804912274; Fri, 09 May 2025 08:35:12 -0700 (PDT) MIME-Version: 1.0 References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz> In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz> From: Greg Hogan <code@HIDDEN> Date: Fri, 9 May 2025 11:35:01 -0400 X-Gm-Features: ATxdqUH4Ux3AAZRp-S9qu8glB5tnUWdxP9GgKEhxKPU86z2HlAJkqxzoMDGipqg Message-ID: <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN> Subject: Re: GCD005: Regular and efficient releases To: Steve George <steve@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78332 Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Fri, May 9, 2025 at 8:54=E2=80=AFAM Steve George <steve@HIDDEN> wr= ote: > [...] > Adding a slower-moving branch akin to Nix's stable could be an eventual g= oal as > it would increase Guix's suitability for some users and use-cases [^2]. = However, > this GCD only sets out to implement regular releases which is a substanti= al > change that would be a big improvement for our users. [...] 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
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.Received: (at 78332) by debbugs.gnu.org; 9 May 2025 14:32:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 10:32:14 2025 Received: from localhost ([127.0.0.1]:38290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uDOlq-0007Qt-05 for submit <at> debbugs.gnu.org; Fri, 09 May 2025 10:32:14 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:44428) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <andreas@HIDDEN>) id 1uDOll-0007Qb-5C for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 10:32:10 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id C2B976C9; Fri, 9 May 2025 16:32:01 +0200 (CEST) Authentication-Results: hera.aquilenet.fr; none X-Virus-Scanned: Debian amavis at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavis, port 10024) with ESMTP id yvK7fqzjYTaG; Fri, 9 May 2025 16:32:01 +0200 (CEST) Received: from jurong (176-179-191-150.abo.bbox.fr [176.179.191.150]) by hera.aquilenet.fr (Postfix) with ESMTPSA id DA7CB1E4; Fri, 9 May 2025 16:31:59 +0200 (CEST) Date: Fri, 9 May 2025 16:31:58 +0200 From: Andreas Enge <andreas@HIDDEN> To: Rutherther <rutherther@HIDDEN> Subject: Re: GCD005: Regular and efficient releases Message-ID: <aB4R3k_NrIWxN-kh@jurong> References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz> <87bjs1x4p9.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bjs1x4p9.fsf@HIDDEN> X-Rspamd-Queue-Id: C2B976C9 X-Spamd-Result: default: False [5.40 / 15.00]; SPAM_FLAG(5.00)[]; NEURAL_SPAM(3.00)[1.000]; BAYES_HAM(-3.00)[99.99%]; MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[] X-Spamd-Bar: +++++ X-Rspamd-Action: greylist X-Rspamd-Server: hera X-Spam-Level: ***** X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78332 Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 14:02:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 10:02:48 2025
Received: from localhost ([127.0.0.1]:38191 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDOJK-0005m7-4Z
for submit <at> debbugs.gnu.org; Fri, 09 May 2025 10:02:47 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::]:35244 helo=mail.ditigal.xyz)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <rutherther@HIDDEN>)
id 1uDOJA-0005lc-Ph
for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 10:02:38 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id c5ea8920
(TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO);
Fri, 9 May 2025 14:02:29 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Subject: Re: GCD005: Regular and efficient releases
In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
Date: Fri, 09 May 2025 16:02:26 +0200
Message-ID: <87bjs1x4p9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
i=@ditigal.xyz; q=dns/txt; s=20240917; t=1746799349; h=from : to : cc
: subject : in-reply-to : references : date : message-id :
mime-version : content-type : content-transfer-encoding : from;
bh=3ojDVn/V1kB0DOG01kteXavgpYYlq3JNayJNlT+9f2Y=;
b=gh75RDfCPIwwNdxbL4cPX1GfMdZS0uGEqhQYsltiD1ILzXFGf6DAmLgZBOk8t+smlhrfl
o6EbI6dkgjzIWTO5m4AeuF1asa+28urWFYRXKnbczmWIAS3EFF5LC5xrc5b1U6A85AQ+Wpg
CX7VVCo7X3liK/STYaB0c1gGU7DGSX0=
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: 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?
Content analysis details: (2.5 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
X-Debbugs-Envelope-To: 78332
Cc: 78332 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: 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?
Content analysis details: (2.5 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: ditigal.xyz (xyz)]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
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@HIDDEN> writes:
> Hi all,
>
> It's been ~2.5 years since the last Guix release, which led me to think w=
e should do another one! Initially, I was just going to see if anyone wante=
d 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=C3=A8s and Efraim Flashner for thei=
r initial comments and insights. They've agreed to sponsor it - which means=
they agree with the general direction (but not necessarily with all aspect=
s), 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
> title: Regular and efficient releases
> id: 005
> status: draft
> discussion: https://issues.guix.gnu.org/78332
> authors: Steve George
> sponsors: Andreas Enge, Ludovic Court=C3=A8s, Efraim Flashner
> date: <date when the discussion period starts>
> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
> ---
>
> # Summary
>
> Guix doesn't have regular release cycle which has led to infrequent new
> releases. Sporadic releases are detrimental for our users, contributors a=
nd
> the project. This GCD proposes we implement an annual release cadence and
> simplify the release process to make releases easier.
>
> The project currently releases new versions of Guix on an ad hoc frequenc=
y.
> The 1.4.0 release happened in December 2022 [^1], which is almost 2.5 yea=
rs
> ago, at the time of writing.
>
> The weaknesses in this release strategy are:
>
> 1. No clarity on when the next Guix release is.
> 2. Releases are complex and toil for developers.
> 3. Rolling updates aren't suitable for all users.
>
> This GCD proposes the following combined solution:
>
> 1. Regular releases: switch to a time-based release of Guix every year.
> 2. Efficient releases: use *package sets* and *supported architectures* to
> reduce the scope of work required to create a Guix release.
>
> The benefits will be:
>
> 1. New installations of Guix will be better because installation media and
> manuals will be up to date, and the initial 'guix pull' will be faster.
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 authentica=
ted.
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 ma=
de.
> 2. Package installation will improve for all users. Packages will be ung=
rafted
> during each release cycle.
> 3. Package quality will improve for all users, because regular releases w=
ill
> provide a cadence for focusing on our quality.
> 4. A regular cadence for promoting the project to potential users. Helpi=
ng us
> to inform more people about the benefits of using GNU Guix!
> 5. A regular release cycle is a rallying point for our contributors givin=
g them a
> consistent calendar of when to focus on releases versus other hacking.
>
> Adding a slower-moving branch akin to Nix's stable could be an eventual g=
oal as
> it would increase Guix's suitability for some users and use-cases [^2]. =
However,
> this GCD only sets out to implement regular releases which is a substanti=
al
> change that would be a big improvement for our users.
>
>
> # Motivation
>
> Releases are important for any Free Software project because they update =
the
> user experience and are a focal point for excitement [^3]. Regular relea=
ses
> help us to improve the quality of our software by bringing focus, and
> exercising regular usage scenarios (e.g. testing the installer).
>
> The majority of distributions follow time-based releases, six months is a
> common cycle time. For further comparison see the research on the
> [release strategies of distributions] (https://codeberg.org/futurile/guix=
-org/src/branch/master/release-mgmt)
> . A summary is:
>
> - NixOS: releases every six months (May/November), both rolling release a=
nd
> slower stable branch.
> - OpenSUSE: rolling release, slow-roll release and fixed releases.
> - Ubuntu: every six months, with 9 months maintenance. LTS releases every
> 2 years.
> - Debian: Every 2 years (not time fixed), with about six months of package
> updates freeze before the release while bugs are ironed out.
>
> As a rolling release Guix immediately provides the latest improvements to
> users. Consequently, it could be argued that releases are unnecessary.
> However, they provide a focal point for the project to undertake addition=
al
> testing and stabilisation across the repository. They also ensure we upd=
ate
> installation media, documentation, themes and web site.
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?
>
> A specific issue caused by irregular releases is that new users/installs =
face a
> significant first "guix pull". This provides a poor initial user experien=
ce,
> and in some cases may even deter users [^4]. Additionally, it requires the
> project to keep old substitutes on our servers.
>
> Regular releases are also good for casual users because they provide an
> opportunity for us to promote new features and improvements. For prospec=
tive
> users promotional activity about the release means they are more likely t=
o hear
> about capabilities that will attract them to experiment with Guix.
>
> Many desktop distributions release every six months to align with the maj=
or
> desktop environments (GNOME/KDE) who release two or three times a year. T=
his is
> why Nix (May/November) and Ubuntu (April/October) align their releases.
>
> Since Guix is used [extensively as a desktop] (https://guix.gnu.org/en/bl=
og/2025/guix-user-and-contributor-survey-2024-the-results-part-1/)
> it would make sense to align with these upstream releases. However, give=
n that
> Guix is a volunteer project that doesn't have the practise of releasing i=
t's
> unrealistic to move to two releases a year. Something along these lines c=
ould
> be a future goal [^5].
>
> This GCD proposes an annual release cycle, with releases **in May**.
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 mon=
th?
Or for a better approach: is there a specific list of packages that
would be targeted so it can be used for the decision?
>
> To move onto this cycle the first release would be a little later: aiming=
for
> the **November of 2025**, with a short cycle to release in May 2026.
>
>
> ## Package Sets
>
> There are currently over 30,000 packages in the archive, it's unrealistic=
for
> all packages to receive the same amount of QA effort for a release.
>
> Many other distributions focus attention on the critical parts of their
> repository by identifying those packages that are required for a particul=
ar
> user-case. For example, Arch Linux limits their efforts to a specific
> repository (called "main"). Ubuntu identifies various seeds for specific
> use-cases which determines their maintained packages; other packages outs=
ide
> these sets do not receive security updates.
>
> Guix is both a package manager that can be hosted on other Linux distribu=
tions,
> and a Linux distribution. Limiting the range of packages that receive at=
tention
> is consequently more complicated. Guix already has manifests to track whi=
ch
> packages are used by [Guix System's installer](https://git.savannah.gnu.o=
rg/cgit/guix.git/tree/etc/manifests/release.scm)
> , so this proposal extends that concept.
>
> For this proposal Guix would identify key package sets which would receiv=
e the
> most attention for QA'ing a release.
>
> The package sets would be:
>
> * minimal: packages required to boot and install a minimal Guix or Guix S=
ystem
> install. This would include the guix daemon, kernels, boot loaders,
> file-systems and minimal utilities.
> * standard: packages that create a core installation for all other uses.
> * desktop: provides the packages necessary for a desktop. This would inc=
lude
> things like X11/Wayland, desktop environments, key applications and theme=
s.
> * server: provides packages and services for a server. This would include
> standard server packages and services.
> * hosted: provides packages and services which are necessary in hosted us=
age.
>
> Guix would still make all packages and services part of a release (the en=
tire
> archive), but only those in the `package sets` could block a release due =
to a
> significant bug. The goal would be for this to be as small a set of pack=
ages
> as reasonably possible. It would mean that developers could focus on the
> critical packages and services during a release. As an example, this wou=
ld
> mean that a major issue in the Linux kernel could block a release, but no=
t an
> issue in a game.
>
>
> ## Platforms and Architecture tiers
>
> Guix is built and maintained on multiple different architectures, and two
> kernels (Linux, GNU Hurd). As the goal of the project is to maximise user
> freedom this variety is significant and is a key motivator for developers.
>
> However, with limited resources (developer and CI) we want to make it as
> efficient as possible to create a release. The more toil involved in a r=
elease
> the less likely developers are to work on it.
>
> The [2025 Guix User Survey](https://guix.gnu.org/en/blog/2025/guix-user-a=
nd-contributor-survey-2024-the-results-part-2/)
> showed that 98% of users were on x86_64 and 19% on AArch64. Consequently=
, the
> proposal is the following tiers:
>
> - Primary architectures:
> - Architectures: x86_64, AArch64
> - Kernel: Linux
> - Coverage: all packages and services that are not explicitly platform
> specific must work to be included in the archive.
> - Package status: package updates should build for this architecture. =
If a
> package update is broken it must not be pushed to users (e.g. master).
> - Security: all packages that are maintained upstream receive updates
>
> - Alternative architectures
> - Architectures: all others
> - Kernel: Linux, Hurd
> - Coverage: all packages and services that are not explicitly platform
> specific may build
> - Package status: package updates should work for this architecture.
> Updates that do not build for this architecure, but do build for a pr=
imary
> architecture may be pushed to users.
> - Security: no commitment to providing security updates for this archit=
ecture.
>
> Packages or services that do not build for the Primary architectures as p=
art of
> a release would be removed from the archive using Guix's deprecation poli=
cy.
>
>
> ## Release artifacts
>
> Using the primary architecture tier and the package sets would involve cr=
eating
> the following release artifacts:
>
> - GNU Guix System ISO image
> - GNU Guix System QCOW2 image
> - GNU Guix installer
>
> Again in an effort to reduce developer toil, additional release artifacts=
could
> be created but would not be part of the formal release testing and errors=
would
> not block a release.
>
>
> ## Release team and project
>
> A regular release cycle should galvanise all Guix developers to work on o=
ur
> releases. But, to ensure there are sufficient people involved a call wil=
l be
> put out to create a specific release team for each release project. We w=
ould
> expect the final release team to be around four-six members. The release =
team
> will work together to fix issues and test the various release artifacts. =
The
> expectation is that the release projects will be as short as possible, ar=
ound
> a 12 week commitment with each team member having a few hours a week to t=
ake
> part.
>
> To manage the release it's proposed that each release will have a Release=
Manager
> role. The role of the Release Manager is to:=20
>
> - co-ordinate the release project
> - communicate with the release team and wider developers status and block=
ers
> - arbitrate changes to release blocking bugs, package sets and release
> artifacts
> - influence and assist teams to resolve problems
> - define the release artifacts and create them
> - encourage and excite **everyone to create and test the release**
>
> The Release Management role is likely to require the most effort, so it w=
ill
> be rotated and consist of two people from the release team. For each rel=
ease
> there would be a primary person and a secondary person in the role. The
> primary person is new to the role. The secondary person has previously d=
one it
> and is mentoring the new person. The impact of this is that each new rel=
ease
> manager is agreeing to take responsibility during two release cycles.
> This system is modelled on the [Nix release management](https://codeberg.=
org/futurile/guix-org/src/branch/master/release-mgmt/nix-release-mgmt.md)
> approach.
>
> One of the release team will take on the role of Release Advocate [^6]. =
They
> will take responsibility for preparing the release announcement and=20
> coordinating the creation of content to promote the new release (e.g. web=
site)
> This role can be done by any member of the Guix community who has suffici=
ent
> interest.
>
> The final release team is:
>
> - a new Release Manager
> - a returning Release Manager
> - up to 4 other members, one of whom acts as the Release Advocate
>
> The Release Managers of each release will create and communicate a release
> project plan setting out the stages and dates for each stage. To try and
> galvanise the Guix development team to focus on the release it's envision=
ed
> that a release project will be about 12 weeks. See Appendix 1: Release Pr=
oject
> Time-line for an example.
>
> In order to improve knowledge transfer and reduce the toil of doing relea=
ses
> the Release Managers for a release will document the release process. Th=
ere is
> inspiration for this in [NixOS's release wiki](https://nixos.github.io/re=
lease-wiki/Home.html)
> and we already have detailed [release documentation](https://git.savannah=
.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
> .
>
>
> # Cost of Reverting
>
> If regular releases were not successful then the project would switch bac=
k to
> irregular releases. There would be no impact for exiting users as they w=
ill
> be tracking the rolling release's master branch.
>
> If the project is able to successfully undertake regular releases then ov=
er
> time it may be possible to undertake full releases every six months or so=
me
> other release cadence.
>
>
> # Drawbacks and open issues
>
> There's no particular drawback to attempting regular release. It should =
be
> noted that the project is entirely dependent on volunteers so it may be t=
hat
> contributors don't have enough time available to achieve regular releases=
. If
> that's the case we would revert back to irregular releases.
>
> There are various improvements that could be made to this process over ti=
me,
> but no known issues.
>
>
> # Appendix 1: Release Project Time-line
>
> To illustrate the major steps of a release project this is a rough time-l=
ine.
> The aim is for a 12 week active release project, with the first one using=
16
> weeks in total to give teams time to prepare.
>
> The current outline builds from our current [release document](https://gi=
t.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
>
> | Week of Project | Event |
> | --- | --- |
> | -5 | Nominate a release team |
> | -4 | Notify teams of upcoming release |
> | 01 | Release project start |
> | 04 | Toolchain and transition freeze |
> | 05 | Package set finalisation |
> | 06 | Initial testing |
> | 08 | Updates freeze |
> | 08 | Breaking changes to staging |
> | 08 | Ungraft master branch |
> | 09 | Bugs and documentation focus |
> | 09 | Branch and tag release branch |
> | 09 | Testing and hard freeze |
> | 10 | Release candidate |
> | 12 | Final release |
> | 13 | Staging merged to master |
> | 14 | Release retrospective |
> | 15+| Relax - it's done! |
>
> ### 1. Nominate a release team
> Nominate a release team with two Release Managers (1 is the previous RM),=
and
> up to 4 other people who will work on the release. Put out a call for a R=
elease
> Advocate who can be anyone in the Guix community who's willing.
>
> ### 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.
>
> ### 3. Release project start
> Start the project with weekly updates to guix-dev and regular meetings of=
the
> release team. Encourage participation in testing and identifying bugs fr=
om
> the community.
>
> ### 4. Toolchain and transition freeze
> No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtimes
> (e.g. java). There should be no changes that will cause major transition=
s.
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.
>
> Debian defines a transition as one where a change in one package causes c=
hanges
> in another, the most common being a library. This isn't suitable for Gui=
x since
> any change in an input causes a change in another package. Nonetheless, =
any
> change that alters a significant number of packages should be carefully
> considered and updates that cause other packages to break should be rejec=
ted.
>
> No alterations to the Guix daemon or modules are accepted after this poin=
t.
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.
> Packages and services in the 'minimal' package set should not be altered.
>
> ### 5. Package set finalisation
> Specify the package sets for this release. Identify all packages and the=
ir
> inputs so that a full manifest for the release is created.
>
> ### 6. Initial testing
> An initial testing sprint to look at packages, services, install media and
> upgrade testing. This should identify:
>
> * packages or services that may need to be removed because they fail on a
> primary architecture
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 in the minimal package set should not be altered', so I think
it should be mentioned it doesn't apply to those packages.
> * packages and services in the package sets install and can be used
> * installation artifacts can be created and used
> * example system definitions can be used
> * system upgrades
>
> A build failure of a package or service will result in it being identifie=
d for
> removal. A build failure of a package or service that's in a package set=
will
> be marked as a blocker for the release.
>
> ### 7. Updates freeze
> Major package updates are frozen on 'master' as the focus is on fixing any
> blocking packages. Security updates still go to 'master'.
So 5 weeeks. (I am counting the retrospective week btw)
Maybe the text should mention how many weeks the freeze is for so it's
easier to orient? It seems important to me.
>
> ### 8. Breaking changes to staging
> To avoid a period of time where teams can't commit breaking changes, thes=
e are
> sent to a new 'staging' branch, rather than directly to master. The mast=
er
> branch slows down from this week.
>
> This concept comes from the Nix project where they flow big changes into a
> staging branch while they do release stabilisation to prevent big flows of
> breaking changes into master which broke one of their releases [^7].
Nix doesn't use staging because of that, they use it always, mostly
because the CI cannot build the whole package set. They don't use
grafts, so there are world rebuilds like two times a month, when the
staging merges to master, and they do that only if staging has already
been built so that people get substitutes.
I think this is a misunderstanding, the linked text states that breaking
changes shouldn't be merged to staging branch, not to master branch. In
turn, it also isn't merged to master branch, because staging is merged
there, quite regularly. This can be most easily seen from the table they
have with affected branches mentioned.
So while I agree with the general motion that changes should be merged
somewhere else, it's not right to state Nix does this.
By the way, since you linked it already, citing their drawbacks
Citing from [^7]:
> Breaking changes to Release Critical Packages will have to wait a
> maximum of 4 weeks to be merged into staging. Other breaking changes
> targeting staging will have to wait a maximum of 2 weeks to be merged.
> Staging-next iterations will follow a 1 week development cycle during
> the release timeline. Breaking changes to Release Critical Packages
> will not appear in master for around 7 weeks (4 weeks being disallowed
> to be merged to staging, 1 week for last staging-next during ZHF, ~2
> weeks average in staging-next). Pull requests which are able to target
> master will not be interrupted d
So they do have 7 week period to not merge anything critical to master,
that's less than what is proposed here. I think it should be kept to as
low number as reasonably possible. That probably have to be analyzed,
and I think the longer time from bigger projects, like GNOME, the more
time to prepare to it even before the release schedule kicks in.
Back to Steve's message:
>
> Team branches can still be folded into the release branch as long as chan=
ges are
> minor package upgrades.
>
> ### 9. Ungraft master branch
> Guix master is ungrafted to minimise the difference with users of the rel=
ease
> initial 'guix pull' experience.
Could you clarify what this means?
>
> ### 10. Bugs and documentation focus
> The master branch should be quiet at this point as everyone should focus =
on
> testing and resolving any bugs. New documentation can also be done.
>
> ### 11. Branch and tag release branch
> The master branch is tagged and a new release branch is created.
>
> * master branch: security only.
> * release branch: security updates as normal. Only RC blocking bugs.
>
> Only security updates go to the master branch from week 9->13. All other
> changes stay in a team branch or go to the `staging` branch. The focus on=
the
> release branch is to stabilise so only RC bugs should be pushed.
Am I reading correctly, no updates whatsoever for 4/5 weeks!! :O
Shouldn't this at least only affect the packages in the package sets?
Even so, feels like too long.
>
> ### 12. Testing and Hard Freeze
> RC bugs and issues should be solved for the release branch.
>
> Only changes that will fix a non-building package, or a bug in a package =
are
> allowed. Ideally avoid new upstream versions, but it's acceptable to use=
a new
> minor upstream version to solve a bug.
>
> Any non-building packages are removed.
>
> ### 13. Release candidate
> Release artifacts are created for the release candidate. There's a final=
2
> weeks of testing with these artifacts. If there are no release blocking =
bugs
> discovered then the releas uses these artifacts. If bugs are found/fixed=
then
> release artifacts are regenerated as needed.
>
> ### 14. Final release
> Final release is announced and new release artifacts are published.
>
> ### 15. Staging merged to master
> If there were any breaking changes placed onto the `staging` branch then =
these
> can be merged into the `master` branch at this point. The master branch =
then
> continues as normal.
>
> ### 16. Release retrospective
> A retrospective is undertaken by the release team to understand how the r=
elease
> process can be improved to make it more reliable for users and easier/eff=
icient
> for developers.
>
> ### 17. Relax!
> The release has been cut, everyone is now excited, and hopefully all is w=
ell.
> Take some time off from release work! There's some time built-in here to
> relax and get back to other hacking before it's time to start again with =
the
> next release.
>
> ---
>
> [^1]: https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/
>
> [^2]: Examples of distributions that have cadences for different users an=
d screnarios
> are Nix's stable branch, OpenSUSE's SlowRoll branch and Ubuntu's LTS
> (Long Term Support) releases.
>
> [^3]: the aspect of creating news and excitement for casual users is well=
-known
> in the FOSS community. An example from=20
> [GNOME's earlier days](https://mail.gnome.org/archives/gnome-hacker=
s/2002-June/msg00041.html).
>
> [^4]: GuixDays 2025 release discussion brought up examples of Guix not be=
ing
> used to teach users because the initial pull was so slow that the
> teaching session would have completed before 'guix pull' would fini=
sh.
> We know guix pull being slow was identified by users as a challenge.
>
> [^5]: OpenSuse has a [SlowRoll branch](https://en.opensuse.org/Portal:Slo=
wroll)
> where they release a smaller set of package updates on a monthly ba=
sis.
> This is an interesting innovation as it allows users to still benef=
it from
> a rolling release but at a slower rate of change (fewer regressions=
).
> They are also not dropping too far behind the rolling release, so t=
here's
> not as much maintenance for OpenSUSE developers dealing with an out=
of
> date release branch and having to backport software.
>
> [^6]: Nix has the concept of a [Release Editor](https://nixos.github.io/r=
elease-wiki/Release-Editors.html)
> who is responsible for improving the legibility of the release note=
s. Our
> version extends the idea to make sure other artifacts and activitie=
s that
> promote the release happen.
>
> [^7]: https://github.com/NixOS/rfcs/blob/master/rfcs/0085-nixos-release-s=
tablization.md
Regards
Rutherther
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.Received: (at 78332) by debbugs.gnu.org; 9 May 2025 14:01:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 10:01:38 2025 Received: from localhost ([127.0.0.1]:38183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uDOID-0005jA-Ug for submit <at> debbugs.gnu.org; Fri, 09 May 2025 10:01:38 -0400 Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:48544) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <steve@HIDDEN>) id 1uDOI8-0005iI-1K for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 10:01:33 -0400 Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <steve@HIDDEN>) id 1uDOHy-003oeI-Rz for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 16:01:22 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=futurile.net; s=selector1; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=NtvSdkiGbGtIF/UsFaYWgKO5hCscT16wx8e/FAHdNgU=; b=STpRtiJPQUMAyQts/cI1lB7HPx DLjNyzlpbzvWfiOlPkiA/iJiLE2btBl0Ik+p2yFfM1QdCMtvFCtH2WduIPPFNWL858D3as9bUoNSl wZMsW0k/lFoptXCHGXfwPsG9eF+5Q8dIoimrEZeBY3RJYVuBCZFmZ4eF/6QICvK+sXD1kb5NHmR3R ajpBwYW7zMFb7MsC+I/0yfvCPUWbwkJzplbXwwVQ2na3iuioHwl3j3xKEVz92VpHa4AFVci30KwD6 YBDJq5aCsYMvNZpOkM6yxYhFb/qp/ZYxmKduAyG+rVxjeRpJcQXVjhAexYop8wtNOBQMVFM3eF4tc TQ/nSfwQ==; Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from <steve@HIDDEN>) id 1uDOHy-0004lg-7R; Fri, 09 May 2025 16:01:22 +0200 Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)] (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93) id 1uDOHi-007DFV-SD; Fri, 09 May 2025 16:01:06 +0200 Date: Fri, 9 May 2025 15:01:05 +0100 From: Steve George <steve@HIDDEN> To: Z572 <z572@HIDDEN> Subject: Re: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'. Message-ID: <gqowz5fh4txxxaubcttltsao6atw7u6ryedp2aorsnyjmsios5@hqn5shp2fqfj> References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN> <87msbmj5hp.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ycyk6w2ibb6dad7f" Content-Disposition: inline In-Reply-To: <87msbmj5hp.fsf@HIDDEN> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78332 Cc: 78332 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) --ycyk6w2ibb6dad7f Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'. MIME-Version: 1.0 On 9 May, Z572 wrote: > Steve George <steve@HIDDEN> writes: >=20 > > + > > +### 8. Breaking changes to staging > > +To avoid a period of time where teams can't commit breaking changes, t= hese are > > +sent to a new 'staging' branch, rather than directly to master. The m= aster >=20 > 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. >=20 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. --ycyk6w2ibb6dad7f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQIB6x23+hDA21fWHn1HUoW3O5vpwUCaB4KoAAKCRD1HUoW3O5v p1qbAP0cpOdajjsn7DuEYqqmJjPdWUKYtt8WnK9TRVp36mwqOQEA/lTRGGle4Z9v 1CPjRUWBwoTzKOZyJZu5s/I+7wKk/gg= =ldNZ -----END PGP SIGNATURE----- --ycyk6w2ibb6dad7f--
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 13:09:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 09:09:21 2025
Received: from localhost ([127.0.0.1]:36695 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDNTd-0007fp-IM
for submit <at> debbugs.gnu.org; Fri, 09 May 2025 09:09:21 -0400
Received: from mail.z572.online ([88.99.160.180]:59048)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <z572@HIDDEN>) id 1uDNTZ-0007fW-Vp
for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 09:09:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=z572.online; s=me;
t=1746796571;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=mPLWyrRnzQvlshm/KoTdcVzO9PicduuZWwV9mp0kcjU=;
b=sp2oqgXNqNn+BJcRLxX6ADqYOYgrg6cnewUEWdYIi3gpBZXoZQ9BoM/9OoKpQllZA2SRqn
bnHX1/iRcqklVUJJ5M3iJmfSXvdMOBFTdiIISz+AuekIdeG6rx1GPpYK4ADPWaov1SnMy+
/YEK2fbv799dNTv5jolbH88+0K0uozo=
Received: from m (<unknown> [61.174.159.83])
by mail.z572.online (OpenSMTPD) with ESMTPSA id a5b09864
(TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
Fri, 9 May 2025 13:16:11 +0000 (UTC)
From: Z572 <z572@HIDDEN>
To: Steve George <steve@HIDDEN>
Subject: Re: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of
GCD005 'Regular and efficient releases'.
In-Reply-To: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
(Steve George's message of "Fri, 9 May 2025 13:19:40 +0100")
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
User-Agent: mu4e 1.12.9; emacs 30.0.92
Date: Fri, 09 May 2025 21:09:06 +0800
Message-ID: <87msbmj5hp.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Steve George <steve@HIDDEN> writes: > + > +### 8.
Breaking
changes to staging > +To avoid a period of time where teams can't commit
breaking changes, these are > +sent to a new 'staging' branch, rather than
directly to master. The maste [...]
Content analysis details: (2.5 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.99.160.180 listed in bl.score.senderscore.com]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: z572.online (online)]
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.99.160.180 listed in sa-accredit.habeas.com]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
X-Debbugs-Envelope-To: 78332
Cc: 78332 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Steve George <steve@HIDDEN> writes: > + > +### 8. Breaking
changes to staging > +To avoid a period of time where teams can't commit
breaking changes, these are > +sent to a new 'staging' branch, rather than
directly to master. The maste [...]
Content analysis details: (2.5 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.99.160.180 listed in sa-trusted.bondedsender.org]
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.99.160.180 listed in bl.score.senderscore.com]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: z572.online (online)]
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
--=-=-=
Content-Type: text/plain
Steve George <steve@HIDDEN> writes:
> +
> +### 8. Breaking changes to staging
> +To avoid a period of time where teams can't commit breaking changes, these are
> +sent to a new 'staging' branch, rather than directly to master. The master
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.
--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEfr6klGDOXiwIdX/bO1qpk+Gi3/AFAmgd/nIACgkQO1qpk+Gi
3/DfEA//cYo/iaUbPaIyCh8eHRORCgAkKrvvf6trwjpdXS53LIwZuLczrekXV97s
v+E7g6pf/aKwVDzRCY/EbraYAZFOL3faKBlDrCPBt6e1yJviUk+qFUoaqSpSuK63
fx8ulWstSf9htyWsNosF49opGKRlQGVcka/fufcxYurvJXTFdF0PSGwTOI5G0Dll
rOI1a6ff4EBL8Kav+Ry1rtfZFzsXcscBdRfSihCDdvLwWvr+EU+mSRKWs1xzMiN2
AlkwfL0mTTkkuU/kvjNKx5fuJkrEihD763dKlfFZS82ncxk6NGWiGSjoKehDNFB0
H046v6Mzr0kteJB3sjEpp7R2CHON03AnqViLZsGteCKkjLYBs5EQVw8seNbCAmPg
8wxsFdNJ/TDXiOfjNEcrDV+48yLMe7W/XEnjNjePIIeNSTvYvRr6hJugJGbtYcAi
C8hfl0VMDYJszh471IkSqPO3ieHqpxqhwSy8bPXaN58O4stqvfmsqC1IR74jm6+L
WcFyJVJEDDEP/sj1nPLrZYVX6AnN1J1z/n9ic9dIZsJS0sgHr4hW8lcQEc8ZtHbY
KZXXDKgpVMZ+oGAgNp//oUQOFl3gVEN36eztrcX8F5IqFyAIftCTL21pAhgqJQNh
i05cl/eoMs6oYvTKf83iUiaFhNdUBU3pOfLEHZAOJrwKfZPdmts=
=ABA6
-----END PGP SIGNATURE-----
--=-=-=--
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 12:54:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 08:54:08 2025
Received: from localhost ([127.0.0.1]:36619 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uDNEq-0006oY-Df
for submit <at> debbugs.gnu.org; Fri, 09 May 2025 08:54:08 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:52988)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <steve@HIDDEN>)
id 1uDNEl-0006na-4u
for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 08:54:01 -0400
Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com)
by mailtransmit05.runbox.com with esmtps (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93)
(envelope-from <steve@HIDDEN>) id 1uDNEd-003dDB-Nu
for 78332 <at> debbugs.gnu.org; Fri, 09 May 2025 14:53:51 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=futurile.net; s=selector1; h=Content-Transfer-Encoding:Content-Type:
MIME-Version:Message-ID:Subject:Cc:To:From:Date;
bh=3cspWSu9NAhGEApPRbw5KNwz6/xzgOl1yScHS2qlNbY=; b=FfcCdRq+DZrwoPPhQX7I1mSa5k
rpkAWg/Egg25uUQjzIDGcCQ+9hzksZZtHFL3nBNes2XqQfULe3AFPcbibhpaBSOmrX8O16PJDqXCu
ZxEwYP6K7fL7MDFD9d4iUnafMqkboJHHK4YpHrlpE/XUpDAvZHbRqt1wXqly8QjQdiOxOSg500CKM
oXPKqDR8rBAHMoMaCtfcmyXXy5MCCKDZDGzZthMtGvbvPTyPcfdqQ2JU0jAHiJchLeTjcp188y5/X
pzFMkhMMibKD5WjEbUhwhqgcM2GZVPAAgKTmYX+RMb5UgUyYAofcua59bcevqwK7sLnZ9/F3EdETT
hhDQnAaA==;
Received: from [10.9.9.72] (helo=submission01.runbox)
by mailtransmit03.runbox with esmtp (Exim 4.86_2)
(envelope-from <steve@HIDDEN>)
id 1uDNEc-0006d4-QO; Fri, 09 May 2025 14:53:51 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)]
(TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
id 1uDNES-007Q05-As; Fri, 09 May 2025 14:53:40 +0200
Date: Fri, 9 May 2025 13:53:39 +0100
From: Steve George <steve@HIDDEN>
To: guix-devel@HIDDEN
Subject: GCD005: Regular and efficient releases
Message-ID: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2rssowefmwbcnshe"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 78332
Cc: 78332 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--2rssowefmwbcnshe
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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
--2rssowefmwbcnshe
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
title: Regular and efficient releases
id: 005
status: draft
discussion: https://issues.guix.gnu.org/78332
authors: Steve George
sponsors: Andreas Enge, Ludovic Courtès, Efraim Flashner
date: <date when the discussion period starts>
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
---
# Summary
Guix doesn't have regular release cycle which has led to infrequent new
releases. Sporadic releases are detrimental for our users, contributors and
the project. This GCD proposes we implement an annual release cadence and
simplify the release process to make releases easier.
The project currently releases new versions of Guix on an ad hoc frequency.
The 1.4.0 release happened in December 2022 [^1], which is almost 2.5 years
ago, at the time of writing.
The weaknesses in this release strategy are:
1. No clarity on when the next Guix release is.
2. Releases are complex and toil for developers.
3. Rolling updates aren't suitable for all users.
This GCD proposes the following combined solution:
1. Regular releases: switch to a time-based release of Guix every year.
2. Efficient releases: use *package sets* and *supported architectures* to
reduce the scope of work required to create a Guix release.
The benefits will be:
1. New installations of Guix will be better because installation media and
manuals will be up to date, and the initial 'guix pull' will be faster.
2. Package installation will improve for all users. Packages will be ungrafted
during each release cycle.
3. Package quality will improve for all users, because regular releases will
provide a cadence for focusing on our quality.
4. A regular cadence for promoting the project to potential users. Helping us
to inform more people about the benefits of using GNU Guix!
5. A regular release cycle is a rallying point for our contributors giving them a
consistent calendar of when to focus on releases versus other hacking.
Adding a slower-moving branch akin to Nix's stable could be an eventual goal as
it would increase Guix's suitability for some users and use-cases [^2]. However,
this GCD only sets out to implement regular releases which is a substantial
change that would be a big improvement for our users.
# Motivation
Releases are important for any Free Software project because they update the
user experience and are a focal point for excitement [^3]. Regular releases
help us to improve the quality of our software by bringing focus, and
exercising regular usage scenarios (e.g. testing the installer).
The majority of distributions follow time-based releases, six months is a
common cycle time. For further comparison see the research on the
[release strategies of distributions] (https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt)
. A summary is:
- NixOS: releases every six months (May/November), both rolling release and
slower stable branch.
- OpenSUSE: rolling release, slow-roll release and fixed releases.
- Ubuntu: every six months, with 9 months maintenance. LTS releases every
2 years.
- Debian: Every 2 years (not time fixed), with about six months of package
updates freeze before the release while bugs are ironed out.
As a rolling release Guix immediately provides the latest improvements to
users. Consequently, it could be argued that releases are unnecessary.
However, they provide a focal point for the project to undertake additional
testing and stabilisation across the repository. They also ensure we update
installation media, documentation, themes and web site.
A specific issue caused by irregular releases is that new users/installs face a
significant first "guix pull". This provides a poor initial user experience,
and in some cases may even deter users [^4]. Additionally, it requires the
project to keep old substitutes on our servers.
Regular releases are also good for casual users because they provide an
opportunity for us to promote new features and improvements. For prospective
users promotional activity about the release means they are more likely to hear
about capabilities that will attract them to experiment with Guix.
Many desktop distributions release every six months to align with the major
desktop environments (GNOME/KDE) who release two or three times a year. This is
why Nix (May/November) and Ubuntu (April/October) align their releases.
Since Guix is used [extensively as a desktop] (https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/)
it would make sense to align with these upstream releases. However, given that
Guix is a volunteer project that doesn't have the practise of releasing it's
unrealistic to move to two releases a year. Something along these lines could
be a future goal [^5].
This GCD proposes an annual release cycle, with releases **in May**.
To move onto this cycle the first release would be a little later: aiming for
the **November of 2025**, with a short cycle to release in May 2026.
## Package Sets
There are currently over 30,000 packages in the archive, it's unrealistic for
all packages to receive the same amount of QA effort for a release.
Many other distributions focus attention on the critical parts of their
repository by identifying those packages that are required for a particular
user-case. For example, Arch Linux limits their efforts to a specific
repository (called "main"). Ubuntu identifies various seeds for specific
use-cases which determines their maintained packages; other packages outside
these sets do not receive security updates.
Guix is both a package manager that can be hosted on other Linux distributions,
and a Linux distribution. Limiting the range of packages that receive attention
is consequently more complicated. Guix already has manifests to track which
packages are used by [Guix System's installer](https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm)
, so this proposal extends that concept.
For this proposal Guix would identify key package sets which would receive the
most attention for QA'ing a release.
The package sets would be:
* minimal: packages required to boot and install a minimal Guix or Guix System
install. This would include the guix daemon, kernels, boot loaders,
file-systems and minimal utilities.
* standard: packages that create a core installation for all other uses.
* desktop: provides the packages necessary for a desktop. This would include
things like X11/Wayland, desktop environments, key applications and themes.
* server: provides packages and services for a server. This would include
standard server packages and services.
* hosted: provides packages and services which are necessary in hosted usage.
Guix would still make all packages and services part of a release (the entire
archive), but only those in the `package sets` could block a release due to a
significant bug. The goal would be for this to be as small a set of packages
as reasonably possible. It would mean that developers could focus on the
critical packages and services during a release. As an example, this would
mean that a major issue in the Linux kernel could block a release, but not an
issue in a game.
## Platforms and Architecture tiers
Guix is built and maintained on multiple different architectures, and two
kernels (Linux, GNU Hurd). As the goal of the project is to maximise user
freedom this variety is significant and is a key motivator for developers.
However, with limited resources (developer and CI) we want to make it as
efficient as possible to create a release. The more toil involved in a release
the less likely developers are to work on it.
The [2025 Guix User Survey](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-2/)
showed that 98% of users were on x86_64 and 19% on AArch64. Consequently, the
proposal is the following tiers:
- Primary architectures:
- Architectures: x86_64, AArch64
- Kernel: Linux
- Coverage: all packages and services that are not explicitly platform
specific must work to be included in the archive.
- Package status: package updates should build for this architecture. If a
package update is broken it must not be pushed to users (e.g. master).
- Security: all packages that are maintained upstream receive updates
- Alternative architectures
- Architectures: all others
- Kernel: Linux, Hurd
- Coverage: all packages and services that are not explicitly platform
specific may build
- Package status: package updates should work for this architecture.
Updates that do not build for this architecure, but do build for a primary
architecture may be pushed to users.
- Security: no commitment to providing security updates for this architecture.
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.
## Release artifacts
Using the primary architecture tier and the package sets would involve creating
the following release artifacts:
- GNU Guix System ISO image
- GNU Guix System QCOW2 image
- GNU Guix installer
Again in an effort to reduce developer toil, additional release artifacts could
be created but would not be part of the formal release testing and errors would
not block a release.
## Release team and project
A regular release cycle should galvanise all Guix developers to work on our
releases. But, to ensure there are sufficient people involved a call will be
put out to create a specific release team for each release project. We would
expect the final release team to be around four-six members. The release team
will work together to fix issues and test the various release artifacts. The
expectation is that the release projects will be as short as possible, around
a 12 week commitment with each team member having a few hours a week to take
part.
To manage the release it's proposed that each release will have a Release Manager
role. The role of the Release Manager is to:
- co-ordinate the release project
- communicate with the release team and wider developers status and blockers
- arbitrate changes to release blocking bugs, package sets and release
artifacts
- influence and assist teams to resolve problems
- define the release artifacts and create them
- encourage and excite **everyone to create and test the release**
The Release Management role is likely to require the most effort, so it will
be rotated and consist of two people from the release team. For each release
there would be a primary person and a secondary person in the role. The
primary person is new to the role. The secondary person has previously done it
and is mentoring the new person. The impact of this is that each new release
manager is agreeing to take responsibility during two release cycles.
This system is modelled on the [Nix release management](https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt/nix-release-mgmt.md)
approach.
One of the release team will take on the role of Release Advocate [^6]. They
will take responsibility for preparing the release announcement and
coordinating the creation of content to promote the new release (e.g. web site)
This role can be done by any member of the Guix community who has sufficient
interest.
The final release team is:
- a new Release Manager
- a returning Release Manager
- up to 4 other members, one of whom acts as the Release Advocate
The Release Managers of each release will create and communicate a release
project plan setting out the stages and dates for each stage. To try and
galvanise the Guix development team to focus on the release it's envisioned
that a release project will be about 12 weeks. See Appendix 1: Release Project
Time-line for an example.
In order to improve knowledge transfer and reduce the toil of doing releases
the Release Managers for a release will document the release process. There is
inspiration for this in [NixOS's release wiki](https://nixos.github.io/release-wiki/Home.html)
and we already have detailed [release documentation](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
.
# Cost of Reverting
If regular releases were not successful then the project would switch back to
irregular releases. There would be no impact for exiting users as they will
be tracking the rolling release's master branch.
If the project is able to successfully undertake regular releases then over
time it may be possible to undertake full releases every six months or some
other release cadence.
# Drawbacks and open issues
There's no particular drawback to attempting regular release. It should be
noted that the project is entirely dependent on volunteers so it may be that
contributors don't have enough time available to achieve regular releases. If
that's the case we would revert back to irregular releases.
There are various improvements that could be made to this process over time,
but no known issues.
# Appendix 1: Release Project Time-line
To illustrate the major steps of a release project this is a rough time-line.
The aim is for a 12 week active release project, with the first one using 16
weeks in total to give teams time to prepare.
The current outline builds from our current [release document](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
| Week of Project | Event |
| --- | --- |
| -5 | Nominate a release team |
| -4 | Notify teams of upcoming release |
| 01 | Release project start |
| 04 | Toolchain and transition freeze |
| 05 | Package set finalisation |
| 06 | Initial testing |
| 08 | Updates freeze |
| 08 | Breaking changes to staging |
| 08 | Ungraft master branch |
| 09 | Bugs and documentation focus |
| 09 | Branch and tag release branch |
| 09 | Testing and hard freeze |
| 10 | Release candidate |
| 12 | Final release |
| 13 | Staging merged to master |
| 14 | Release retrospective |
| 15+| Relax - it's done! |
### 1. Nominate a release team
Nominate a release team with two Release Managers (1 is the previous RM), and
up to 4 other people who will work on the release. Put out a call for a Release
Advocate who can be anyone in the Guix community who's willing.
### 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.
### 3. Release project start
Start the project with weekly updates to guix-dev and regular meetings of the
release team. Encourage participation in testing and identifying bugs from
the community.
### 4. Toolchain and transition freeze
No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtimes
(e.g. java). There should be no changes that will cause major transitions.
Debian defines a transition as one where a change in one package causes changes
in another, the most common being a library. This isn't suitable for Guix since
any change in an input causes a change in another package. Nonetheless, any
change that alters a significant number of packages should be carefully
considered and updates that cause other packages to break should be rejected.
No alterations to the Guix daemon or modules are accepted after this point.
Packages and services in the 'minimal' package set should not be altered.
### 5. Package set finalisation
Specify the package sets for this release. Identify all packages and their
inputs so that a full manifest for the release is created.
### 6. Initial testing
An initial testing sprint to look at packages, services, install media and
upgrade testing. This should identify:
* packages or services that may need to be removed because they fail on a
primary architecture
* packages and services in the package sets install and can be used
* installation artifacts can be created and used
* example system definitions can be used
* system upgrades
A build failure of a package or service will result in it being identified for
removal. A build failure of a package or service that's in a package set will
be marked as a blocker for the release.
### 7. Updates freeze
Major package updates are frozen on 'master' as the focus is on fixing any
blocking packages. Security updates still go to 'master'.
### 8. Breaking changes to staging
To avoid a period of time where teams can't commit breaking changes, these are
sent to a new 'staging' branch, rather than directly to master. The master
branch slows down from this week.
This concept comes from the Nix project where they flow big changes into a
staging branch while they do release stabilisation to prevent big flows of
breaking changes into master which broke one of their releases [^7].
Team branches can still be folded into the release branch as long as changes are
minor package upgrades.
### 9. Ungraft master branch
Guix master is ungrafted to minimise the difference with users of the release
initial 'guix pull' experience.
### 10. Bugs and documentation focus
The master branch should be quiet at this point as everyone should focus on
testing and resolving any bugs. New documentation can also be done.
### 11. Branch and tag release branch
The master branch is tagged and a new release branch is created.
* master branch: security only.
* release branch: security updates as normal. Only RC blocking bugs.
Only security updates go to the master branch from week 9->13. All other
changes stay in a team branch or go to the `staging` branch. The focus on the
release branch is to stabilise so only RC bugs should be pushed.
### 12. Testing and Hard Freeze
RC bugs and issues should be solved for the release branch.
Only changes that will fix a non-building package, or a bug in a package are
allowed. Ideally avoid new upstream versions, but it's acceptable to use a new
minor upstream version to solve a bug.
Any non-building packages are removed.
### 13. Release candidate
Release artifacts are created for the release candidate. There's a final 2
weeks of testing with these artifacts. If there are no release blocking bugs
discovered then the releas uses these artifacts. If bugs are found/fixed then
release artifacts are regenerated as needed.
### 14. Final release
Final release is announced and new release artifacts are published.
### 15. Staging merged to master
If there were any breaking changes placed onto the `staging` branch then these
can be merged into the `master` branch at this point. The master branch then
continues as normal.
### 16. Release retrospective
A retrospective is undertaken by the release team to understand how the release
process can be improved to make it more reliable for users and easier/efficient
for developers.
### 17. Relax!
The release has been cut, everyone is now excited, and hopefully all is well.
Take some time off from release work! There's some time built-in here to
relax and get back to other hacking before it's time to start again with the
next release.
---
[^1]: https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/
[^2]: Examples of distributions that have cadences for different users and screnarios
are Nix's stable branch, OpenSUSE's SlowRoll branch and Ubuntu's LTS
(Long Term Support) releases.
[^3]: the aspect of creating news and excitement for casual users is well-known
in the FOSS community. An example from
[GNOME's earlier days](https://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html).
[^4]: GuixDays 2025 release discussion brought up examples of Guix not being
used to teach users because the initial pull was so slow that the
teaching session would have completed before 'guix pull' would finish.
We know guix pull being slow was identified by users as a challenge.
[^5]: OpenSuse has a [SlowRoll branch](https://en.opensuse.org/Portal:Slowroll)
where they release a smaller set of package updates on a monthly basis.
This is an interesting innovation as it allows users to still benefit from
a rolling release but at a slower rate of change (fewer regressions).
They are also not dropping too far behind the rolling release, so there's
not as much maintenance for OpenSUSE developers dealing with an out of
date release branch and having to backport software.
[^6]: Nix has the concept of a [Release Editor](https://nixos.github.io/release-wiki/Release-Editors.html)
who is responsible for improving the legibility of the release notes. Our
version extends the idea to make sure other artifacts and activities that
promote the release happen.
[^7]: https://github.com/NixOS/rfcs/blob/master/rfcs/0085-nixos-release-stablization.md
--2rssowefmwbcnshe--
guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.Received: (at submit) by debbugs.gnu.org; 9 May 2025 12:21:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 09 08:21:01 2025 Received: from localhost ([127.0.0.1]:36458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uDMim-0004uA-0n for submit <at> debbugs.gnu.org; Fri, 09 May 2025 08:21:01 -0400 Received: from lists.gnu.org ([2001:470:142::17]:53846) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <steve@HIDDEN>) id 1uDMig-0004ta-GP for submit <at> debbugs.gnu.org; Fri, 09 May 2025 08:20:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <steve@HIDDEN>) id 1uDMiV-0005hO-M5 for guix-patches@HIDDEN; Fri, 09 May 2025 08:20:39 -0400 Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <steve@HIDDEN>) id 1uDMiL-0000vs-HX for guix-patches@HIDDEN; Fri, 09 May 2025 08:20:38 -0400 Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <steve@HIDDEN>) id 1uDMiG-003bEl-In for guix-patches@HIDDEN; Fri, 09 May 2025 14:20:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=futurile.net; s=selector1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=xJ0lDGiZRjZ/WNQxf3KMeRlGCgkSYHqHVis4g4zPGD0=; b=SirnCcLnvZsduKdmg+pwBvMZUg CW0mT6gZz8inEvAxBukVgstZV81XsRMSQL6quY1chqRaFg5jli4Y63Cx3VXOXtCM/we+6uQ6NxlDn vYIDEJymCZuj26HfYdEYZr8YLuy1IEsr5TKVV3THRrLfN9FYSrY21IgiYNopzi2/+wsLQvfwtBYmD IekaqDFKMU4Gz0jYd54dIatOz117eSzeI4tP/Ycc6t8hI7kdi/XwWP2u1zmno0cvRBvcnXm1kTHbW ZjRQ+SLPrcVjLBN+OM0jlc+zInFDscgCktT15syVq4CvDWx7j0CKpiKj4dSQv9q0t7UcXbvLnS5qf IM3/3VPA==; Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from <steve@HIDDEN>) id 1uDMiG-0004Wd-92 for guix-patches@HIDDEN; Fri, 09 May 2025 14:20:24 +0200 Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)] (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93) id 1uDMho-007GcX-3I; Fri, 09 May 2025 14:19:56 +0200 From: Steve George <steve@HIDDEN> To: guix-patches@HIDDEN Subject: [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'. Date: Fri, 9 May 2025 13:19:40 +0100 Message-ID: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN> X-Mailer: git-send-email 2.49.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Received-SPF: permerror client-ip=2a0c:5a00:149::25; envelope-from=steve@HIDDEN; helo=mailtransmit04.runbox.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_TEMPERROR=0.01, T_SPF_PERMERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit Cc: Steve George <steve@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) * 005-regular-releases: New file. --- 005-regular-releases.md | 449 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 449 insertions(+) create mode 100644 005-regular-releases.md diff --git a/005-regular-releases.md b/005-regular-releases.md new file mode 100644 index 0000000..c9fb0ac --- /dev/null +++ b/005-regular-releases.md @@ -0,0 +1,449 @@ +title: Regular and efficient releases +id: 005 +status: draft +discussion: https://issues.guix.gnu.org/<number assigned by issue tracker> +authors: Steve George +sponsors: Andreas Enge, Ludovic Courtès, Efraim Flashner +date: <date when the discussion period starts> +SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later +--- + +# Summary + +Guix doesn't have regular release cycle which has led to infrequent new +releases. Sporadic releases are detrimental for our users, contributors and +the project. This GCD proposes we implement an annual release cadence and +simplify the release process to make releases easier. + +The project currently releases new versions of Guix on an ad hoc frequency. +The 1.4.0 release happened in December 2022 [^1], which is almost 2.5 years +ago, at the time of writing. + +The weaknesses in this release strategy are: + +1. No clarity on when the next Guix release is. +2. Releases are complex and toil for developers. +3. Rolling updates aren't suitable for all users. + +This GCD proposes the following combined solution: + +1. Regular releases: switch to a time-based release of Guix every year. +2. Efficient releases: use *package sets* and *supported architectures* to +reduce the scope of work required to create a Guix release. + +The benefits will be: + +1. New installations of Guix will be better because installation media and + manuals will be up to date, and the initial 'guix pull' will be faster. +2. Package installation will improve for all users. Packages will be ungrafted + during each release cycle. +3. Package quality will improve for all users, because regular releases will + provide a cadence for focusing on our quality. +4. A regular cadence for promoting the project to potential users. Helping us + to inform more people about the benefits of using GNU Guix! +5. A regular release cycle is a rallying point for our contributors giving them a + consistent calendar of when to focus on releases versus other hacking. + +Adding a slower-moving branch akin to Nix's stable could be an eventual goal as +it would increase Guix's suitability for some users and use-cases [^2]. However, +this GCD only sets out to implement regular releases which is a substantial +change that would be a big improvement for our users. + + +# Motivation + +Releases are important for any Free Software project because they update the +user experience and are a focal point for excitement [^3]. Regular releases +help us to improve the quality of our software by bringing focus, and +exercising regular usage scenarios (e.g. testing the installer). + +The majority of distributions follow time-based releases, six months is a +common cycle time. For further comparison see the research on the +[release strategies of distributions] (https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt) +. A summary is: + +- NixOS: releases every six months (May/November), both rolling release and +slower stable branch. +- OpenSUSE: rolling release, slow-roll release and fixed releases. +- Ubuntu: every six months, with 9 months maintenance. LTS releases every +2 years. +- Debian: Every 2 years (not time fixed), with about six months of package +updates freeze before the release while bugs are ironed out. + +As a rolling release Guix immediately provides the latest improvements to +users. Consequently, it could be argued that releases are unnecessary. +However, they provide a focal point for the project to undertake additional +testing and stabilisation across the repository. They also ensure we update +installation media, documentation, themes and web site. + +A specific issue caused by irregular releases is that new users/installs face a +significant first "guix pull". This provides a poor initial user experience, +and in some cases may even deter users [^4]. Additionally, it requires the +project to keep old substitutes on our servers. + +Regular releases are also good for casual users because they provide an +opportunity for us to promote new features and improvements. For prospective +users promotional activity about the release means they are more likely to hear +about capabilities that will attract them to experiment with Guix. + +Many desktop distributions release every six months to align with the major +desktop environments (GNOME/KDE) who release two or three times a year. This is +why Nix (May/November) and Ubuntu (April/October) align their releases. + +Since Guix is used [extensively as a desktop] (https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-1/) +it would make sense to align with these upstream releases. However, given that +Guix is a volunteer project that doesn't have the practise of releasing it's +unrealistic to move to two releases a year. Something along these lines could +be a future goal [^5]. + +This GCD proposes an annual release cycle, with releases **in May**. + +To move onto this cycle the first release would be a little later: aiming for +the **November of 2025**, with a short cycle to release in May 2026. + + +## Package Sets + +There are currently over 30,000 packages in the archive, it's unrealistic for +all packages to receive the same amount of QA effort for a release. + +Many other distributions focus attention on the critical parts of their +repository by identifying those packages that are required for a particular +user-case. For example, Arch Linux limits their efforts to a specific +repository (called "main"). Ubuntu identifies various seeds for specific +use-cases which determines their maintained packages; other packages outside +these sets do not receive security updates. + +Guix is both a package manager that can be hosted on other Linux distributions, +and a Linux distribution. Limiting the range of packages that receive attention +is consequently more complicated. Guix already has manifests to track which +packages are used by [Guix System's installer](https://git.savannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm) +, so this proposal extends that concept. + +For this proposal Guix would identify key package sets which would receive the +most attention for QA'ing a release. + +The package sets would be: + +* minimal: packages required to boot and install a minimal Guix or Guix System +install. This would include the guix daemon, kernels, boot loaders, +file-systems and minimal utilities. +* standard: packages that create a core installation for all other uses. +* desktop: provides the packages necessary for a desktop. This would include +things like X11/Wayland, desktop environments, key applications and themes. +* server: provides packages and services for a server. This would include +standard server packages and services. +* hosted: provides packages and services which are necessary in hosted usage. + +Guix would still make all packages and services part of a release (the entire +archive), but only those in the `package sets` could block a release due to a +significant bug. The goal would be for this to be as small a set of packages +as reasonably possible. It would mean that developers could focus on the +critical packages and services during a release. As an example, this would +mean that a major issue in the Linux kernel could block a release, but not an +issue in a game. + + +## Platforms and Architecture tiers + +Guix is built and maintained on multiple different architectures, and two +kernels (Linux, GNU Hurd). As the goal of the project is to maximise user +freedom this variety is significant and is a key motivator for developers. + +However, with limited resources (developer and CI) we want to make it as +efficient as possible to create a release. The more toil involved in a release +the less likely developers are to work on it. + +The [2025 Guix User Survey](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-2/) +showed that 98% of users were on x86_64 and 19% on AArch64. Consequently, the +proposal is the following tiers: + +- Primary architectures: + - Architectures: x86_64, AArch64 + - Kernel: Linux + - Coverage: all packages and services that are not explicitly platform + specific must work to be included in the archive. + - Package status: package updates should build for this architecture. If a + package update is broken it must not be pushed to users (e.g. master). + - Security: all packages that are maintained upstream receive updates + +- Alternative architectures + - Architectures: all others + - Kernel: Linux, Hurd + - Coverage: all packages and services that are not explicitly platform + specific may build + - Package status: package updates should work for this architecture. + Updates that do not build for this architecure, but do build for a primary + architecture may be pushed to users. + - Security: no commitment to providing security updates for this architecture. + +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. + + +## Release artifacts + +Using the primary architecture tier and the package sets would involve creating +the following release artifacts: + +- GNU Guix System ISO image +- GNU Guix System QCOW2 image +- GNU Guix installer + +Again in an effort to reduce developer toil, additional release artifacts could +be created but would not be part of the formal release testing and errors would +not block a release. + + +## Release team and project + +A regular release cycle should galvanise all Guix developers to work on our +releases. But, to ensure there are sufficient people involved a call will be +put out to create a specific release team for each release project. We would +expect the final release team to be around four-six members. The release team +will work together to fix issues and test the various release artifacts. The +expectation is that the release projects will be as short as possible, around +a 12 week commitment with each team member having a few hours a week to take +part. + +To manage the release it's proposed that each release will have a Release Manager +role. The role of the Release Manager is to: + +- co-ordinate the release project +- communicate with the release team and wider developers status and blockers +- arbitrate changes to release blocking bugs, package sets and release + artifacts +- influence and assist teams to resolve problems +- define the release artifacts and create them +- encourage and excite **everyone to create and test the release** + +The Release Management role is likely to require the most effort, so it will +be rotated and consist of two people from the release team. For each release +there would be a primary person and a secondary person in the role. The +primary person is new to the role. The secondary person has previously done it +and is mentoring the new person. The impact of this is that each new release +manager is agreeing to take responsibility during two release cycles. +This system is modelled on the [Nix release management](https://codeberg.org/futurile/guix-org/src/branch/master/release-mgmt/nix-release-mgmt.md) +approach. + +One of the release team will take on the role of Release Advocate [^6]. They +will take responsibility for preparing the release announcement and +coordinating the creation of content to promote the new release (e.g. web site) +This role can be done by any member of the Guix community who has sufficient +interest. + +The final release team is: + +- a new Release Manager +- a returning Release Manager +- up to 4 other members, one of whom acts as the Release Advocate + +The Release Managers of each release will create and communicate a release +project plan setting out the stages and dates for each stage. To try and +galvanise the Guix development team to focus on the release it's envisioned +that a release project will be about 12 weeks. See Appendix 1: Release Project +Time-line for an example. + +In order to improve knowledge transfer and reduce the toil of doing releases +the Release Managers for a release will document the release process. There is +inspiration for this in [NixOS's release wiki](https://nixos.github.io/release-wiki/Home.html) +and we already have detailed [release documentation](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org) +. + + +# Cost of Reverting + +If regular releases were not successful then the project would switch back to +irregular releases. There would be no impact for exiting users as they will +be tracking the rolling release's master branch. + +If the project is able to successfully undertake regular releases then over +time it may be possible to undertake full releases every six months or some +other release cadence. + + +# Drawbacks and open issues + +There's no particular drawback to attempting regular release. It should be +noted that the project is entirely dependent on volunteers so it may be that +contributors don't have enough time available to achieve regular releases. If +that's the case we would revert back to irregular releases. + +There are various improvements that could be made to this process over time, +but no known issues. + + +# Appendix 1: Release Project Time-line + +To illustrate the major steps of a release project this is a rough time-line. +The aim is for a 12 week active release project, with the first one using 16 +weeks in total to give teams time to prepare. + +The current outline builds from our current [release document](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org) + +| Week of Project | Event | +| --- | --- | +| -5 | Nominate a release team | +| -4 | Notify teams of upcoming release | +| 01 | Release project start | +| 04 | Toolchain and transition freeze | +| 05 | Package set finalisation | +| 06 | Initial testing | +| 08 | Updates freeze | +| 08 | Breaking changes to staging | +| 08 | Ungraft master branch | +| 09 | Bugs and documentation focus | +| 09 | Branch and tag release branch | +| 09 | Testing and hard freeze | +| 10 | Release candidate | +| 12 | Final release | +| 13 | Staging merged to master | +| 14 | Release retrospective | +| 15+| Relax - it's done! | + +### 1. Nominate a release team +Nominate a release team with two Release Managers (1 is the previous RM), and +up to 4 other people who will work on the release. Put out a call for a Release +Advocate who can be anyone in the Guix community who's willing. + +### 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. + +### 3. Release project start +Start the project with weekly updates to guix-dev and regular meetings of the +release team. Encourage participation in testing and identifying bugs from +the community. + +### 4. Toolchain and transition freeze +No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtimes +(e.g. java). There should be no changes that will cause major transitions. + +Debian defines a transition as one where a change in one package causes changes +in another, the most common being a library. This isn't suitable for Guix since +any change in an input causes a change in another package. Nonetheless, any +change that alters a significant number of packages should be carefully +considered and updates that cause other packages to break should be rejected. + +No alterations to the Guix daemon or modules are accepted after this point. +Packages and services in the 'minimal' package set should not be altered. + +### 5. Package set finalisation +Specify the package sets for this release. Identify all packages and their +inputs so that a full manifest for the release is created. + +### 6. Initial testing +An initial testing sprint to look at packages, services, install media and +upgrade testing. This should identify: + +* packages or services that may need to be removed because they fail on a + primary architecture +* packages and services in the package sets install and can be used +* installation artifacts can be created and used +* example system definitions can be used +* system upgrades + +A build failure of a package or service will result in it being identified for +removal. A build failure of a package or service that's in a package set will +be marked as a blocker for the release. + +### 7. Updates freeze +Major package updates are frozen on 'master' as the focus is on fixing any +blocking packages. Security updates still go to 'master'. + +### 8. Breaking changes to staging +To avoid a period of time where teams can't commit breaking changes, these are +sent to a new 'staging' branch, rather than directly to master. The master +branch slows down from this week. + +This concept comes from the Nix project where they flow big changes into a +staging branch while they do release stabilisation to prevent big flows of +breaking changes into master which broke one of their releases [^7]. + +Team branches can still be folded into the release branch as long as changes are +minor package upgrades. + +### 9. Ungraft master branch +Guix master is ungrafted to minimise the difference with users of the release +initial 'guix pull' experience. + +### 10. Bugs and documentation focus +The master branch should be quiet at this point as everyone should focus on +testing and resolving any bugs. New documentation can also be done. + +### 11. Branch and tag release branch +The master branch is tagged and a new release branch is created. + +* master branch: security only. +* release branch: security updates as normal. Only RC blocking bugs. + +Only security updates go to the master branch from week 9->13. All other +changes stay in a team branch or go to the `staging` branch. The focus on the +release branch is to stabilise so only RC bugs should be pushed. + +### 12. Testing and Hard Freeze +RC bugs and issues should be solved for the release branch. + +Only changes that will fix a non-building package, or a bug in a package are +allowed. Ideally avoid new upstream versions, but it's acceptable to use a new +minor upstream version to solve a bug. + +Any non-building packages are removed. + +### 13. Release candidate +Release artifacts are created for the release candidate. There's a final 2 +weeks of testing with these artifacts. If there are no release blocking bugs +discovered then the releas uses these artifacts. If bugs are found/fixed then +release artifacts are regenerated as needed. + +### 14. Final release +Final release is announced and new release artifacts are published. + +### 15. Staging merged to master +If there were any breaking changes placed onto the `staging` branch then these +can be merged into the `master` branch at this point. The master branch then +continues as normal. + +### 16. Release retrospective +A retrospective is undertaken by the release team to understand how the release +process can be improved to make it more reliable for users and easier/efficient +for developers. + +### 17. Relax! +The release has been cut, everyone is now excited, and hopefully all is well. +Take some time off from release work! There's some time built-in here to +relax and get back to other hacking before it's time to start again with the +next release. + +--- + +[^1]: https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/ + +[^2]: Examples of distributions that have cadences for different users and screnarios + are Nix's stable branch, OpenSUSE's SlowRoll branch and Ubuntu's LTS + (Long Term Support) releases. + +[^3]: the aspect of creating news and excitement for casual users is well-known + in the FOSS community. An example from + [GNOME's earlier days](https://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html). + +[^4]: GuixDays 2025 release discussion brought up examples of Guix not being + used to teach users because the initial pull was so slow that the + teaching session would have completed before 'guix pull' would finish. + We know guix pull being slow was identified by users as a challenge. + +[^5]: OpenSuse has a [SlowRoll branch](https://en.opensuse.org/Portal:Slowroll) + where they release a smaller set of package updates on a monthly basis. + This is an interesting innovation as it allows users to still benefit from + a rolling release but at a slower rate of change (fewer regressions). + They are also not dropping too far behind the rolling release, so there's + not as much maintenance for OpenSUSE developers dealing with an out of + date release branch and having to backport software. + +[^6]: Nix has the concept of a [Release Editor](https://nixos.github.io/release-wiki/Release-Editors.html) + who is responsible for improving the legibility of the release notes. Our + version extends the idea to make sure other artifacts and activities that + promote the release happen. + +[^7]: https://github.com/NixOS/rfcs/blob/master/rfcs/0085-nixos-release-stablization.md + -- 2.49.0
Steve George <steve@HIDDEN>:guix-patches@HIDDEN.
Full text available.guix-patches@HIDDEN:bug#78332; Package guix-patches.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.