GNU logs - #78332, boring messages

Message sent to guix-patches@HIDDEN:

Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 12:21:02 +0000
Resent-Message-ID: <handler.78332.B.174679326118874 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 78332 <at> debbugs.gnu.org
Cc: Steve George <steve@HIDDEN>
From: Steve George <steve@HIDDEN>
Date: Fri,  9 May 2025 13:19:40 +0100
Message-ID: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
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-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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Steve George <steve@HIDDEN>
Subject: bug#78332: Acknowledgement ([PATCH 1/1] 005-regular-releases:
 Initial draft of GCD005 'Regular and efficient releases'.)
Message-ID: <handler.78332.B.174679326118874.ack <at> debbugs.gnu.org>
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
X-Gnu-PR-Message: ack 78332
X-Gnu-PR-Package: guix-patches
X-Gnu-PR-Keywords: patch
Reply-To: 78332 <at> debbugs.gnu.org
Date: Fri, 09 May 2025 12:21:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 guix-patches@HIDDEN

If you wish to submit further information on this problem, please
send it to 78332 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
78332: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78332
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to guix-patches@HIDDEN:

Subject: [bug#78332] GCD005: Regular and efficient releases
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
In-Reply-To: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 12:55:02 +0000
Resent-Message-ID: <handler.78332.B78332.174679524926206 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Date: Fri, 9 May 2025 13:53:39 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2rssowefmwbcnshe"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--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--

Message sent to guix-patches@HIDDEN:

Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Z572 <z572@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 13:10:01 +0000
Resent-Message-ID: <handler.78332.B78332.174679616229505 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Steve George <steve@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
From: Z572 <z572@HIDDEN>
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"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
 
 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-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 14:02:01 +0000
Resent-Message-ID: <handler.78332.B78332.174679929822025 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Z572 <z572@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174679929822025
          (code B ref 78332); Fri, 09 May 2025 14:02:01 +0000
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 14:01:38 +0000
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>
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-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--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Rutherther <rutherther@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 14:03:01 +0000
Resent-Message-ID: <handler.78332.B78332.174679936822209 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174679936822209
          (code B ref 78332); Fri, 09 May 2025 14:03:01 +0000
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 14:02:48 +0000
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>
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-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

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Andreas Enge <andreas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 14:33:01 +0000
Resent-Message-ID: <handler.78332.B78332.174680113428579 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Rutherther <rutherther@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174680113428579
          (code B ref 78332); Fri, 09 May 2025 14:33:01 +0000
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 14:32:14 +0000
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>
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-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

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Greg Hogan <code@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 15:36:01 +0000
Resent-Message-ID: <handler.78332.B78332.174680492410884 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174680492410884
          (code B ref 78332); Fri, 09 May 2025 15:36:01 +0000
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 15:35:24 +0000
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Z572 <z572@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 16:19:02 +0000
Resent-Message-ID: <handler.78332.B78332.174680751220496 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174680751220496
          (code B ref 78332); Fri, 09 May 2025 16:19:02 +0000
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 16:18:32 +0000
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>
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-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-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Vagrant Cascadian <vagrant@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 19:50:01 +0000
Resent-Message-ID: <handler.78332.B78332.174682015028464 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174682015028464
          (code B ref 78332); Fri, 09 May 2025 19:50:01 +0000
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 19:49:10 +0000
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>
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-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-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 21:25:01 +0000
Resent-Message-ID: <handler.78332.B78332.174682589517862 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Rutherther <rutherther@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174682589517862
          (code B ref 78332); Fri, 09 May 2025 21:25:01 +0000
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 21:24:55 +0000
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>
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-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

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 21:56:02 +0000
Resent-Message-ID: <handler.78332.B78332.174682771525231 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Greg Hogan <code@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174682771525231
          (code B ref 78332); Fri, 09 May 2025 21:56:02 +0000
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 21:55:15 +0000
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>
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-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

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Ekaitz Zarraga <ekaitz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 09 May 2025 23:00:02 +0000
Resent-Message-ID: <handler.78332.B78332.17468315897442 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17468315897442
          (code B ref 78332); Fri, 09 May 2025 23:00:02 +0000
Received: (at 78332) by debbugs.gnu.org; 9 May 2025 22:59:49 +0000
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
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-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
>

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Andreas Enge <andreas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 10 May 2025 09:16:02 +0000
Resent-Message-ID: <handler.78332.B78332.174686851816788 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Ekaitz Zarraga <ekaitz@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174686851816788
          (code B ref 78332); Sat, 10 May 2025 09:16:02 +0000
Received: (at 78332) by debbugs.gnu.org; 10 May 2025 09:15:18 +0000
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>
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-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

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 10 May 2025 09:44:02 +0000
Resent-Message-ID: <handler.78332.B78332.174687018623322 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Vagrant Cascadian <vagrant@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174687018623322
          (code B ref 78332); Sat, 10 May 2025 09:44:02 +0000
Received: (at 78332) by debbugs.gnu.org; 10 May 2025 09:43:06 +0000
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>
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-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--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: reza <reza@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 10 May 2025 10:57:01 +0000
Resent-Message-ID: <handler.78332.B78332.174687457519205 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>,  guix-devel@HIDDEN <guix-devel@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org <78332 <at> debbugs.gnu.org>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174687457519205
          (code B ref 78332); Sat, 10 May 2025 10:57:01 +0000
Received: (at 78332) by debbugs.gnu.org; 10 May 2025 10:56:15 +0000
Received: from localhost ([127.0.0.1]:44456 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uDhsM-0004zg-8w
	for submit <at> debbugs.gnu.org; Sat, 10 May 2025 06:56:15 -0400
Received: from a2-86.smtp-out.eu-west-1.amazonses.com ([54.240.2.86]:35467)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_CBC_SHA1:128)
 (Exim 4.84_2) (envelope-from
 <01020196b9d67d65-4ddf4f05-f643-4607-8337-af969cb8b074-000000@HIDDEN>)
 id 1uDhsI-0004zL-Ao
 for 78332 <at> debbugs.gnu.org; Sat, 10 May 2025 06:56:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
 s=h7sbm3vky7w3jot2soxe5tb4n2dbsnpe; d=housseini.me; t=1746874564;
 h=Subject:From:To:Cc:Date:Mime-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Message-Id;
 bh=JQSkAFa0DCqpbGMCEgmQkDVerKRorX+CdiTGjblrk0E=;
 b=Yb894d2zLMX7LnvCSJphvsGUeVziKySoyg9kN3Aj1F/qIXEPqqmn3VfYoMtJKSiN
 wrIGTUAWNrwtwLxVCdPsUoH3YrAa3qiLrWZXYW5MkpVpyNXyoLRUsDdDt2RED19zjpu
 9gAtZ3uUutP8bkZwz88N6jYnoYsugi0ZHZXoIKBw=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
 s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn; d=amazonses.com; t=1746874564;
 h=Subject:From:To:Cc:Date:Mime-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References:Message-Id:Feedback-ID;
 bh=JQSkAFa0DCqpbGMCEgmQkDVerKRorX+CdiTGjblrk0E=;
 b=NlnqZlITSAMqqor42WW+dvsv8tk00ZRKsUkSpTpKXN2zmJ15A4YeUzQ75J31f/52
 Cgvjw+WDhCVfUrH2K14g4B4Hl+4KWYLNgzaqk7AYkkqX44K9ocTc+EyooGnFctahIRd
 jXFsxYdYH3x4DDRHnoRMWXRUaIPR0N1lXjM4aZX8=
From: reza <reza@HIDDEN>
Date: Sat, 10 May 2025 10:56:03 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz> 
 <87y0v468gj.fsf@HIDDEN>
X-Mailer: Amazon WorkMail
Thread-Index: AQHbwNzuoeH1Fas4T7qrZ14yCBlbhgABMOWLAC9MNhM=
Thread-Topic: GCD005: Regular and efficient releases
X-Wm-Sent-Timestamp: 1746874563
Message-ID: <01020196b9d67d65-4ddf4f05-f643-4607-8337-af969cb8b074-000000@HIDDEN>
Feedback-ID: ::1.eu-west-1.b24dn6frgCi6dh20skzbuMRr7UL8M6Soir/3ogtEjHQ=:AmazonSES
X-SES-Outgoing: 2025.05.10-54.240.2.86
X-Spam-Score: 0.0 (/)
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=0D=0A=0D=0AThanks for the effort you put into this, I just wante=
d to add my=0D=0Athoughts when reading it...=0D=0A=0D=0A> Hi all,=0D=0A>=0D=
=0A> It's been ~2.5 years since the last Guix release, which led me to th=
ink we should do another one! Initially, I was just going to see if anyon=
e wanted to create a release project. But, before I knew it I was writing=
 a GCD! ...=0D=0A>=0D=0A> Below you'll find a proposal for moving to a re=
gular release cycle.=0D=0A>=0D=0A> Thanks to Andreas Enge, Ludovic Court=C3=
=A8s 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 di=
scussion to move us towards a consensus on whether it's a good proposal.=0D=
=0A>=0D=0A> This is a **draft** submission so I look forward to your cons=
ideration of it, thoughts and comments.=0D=0A>=0D=0A> Thanks,=0D=0A>=0D=0A=
> Steve / Futurile=0D=0A> title: Regular and efficient releases=0D=0A> id=
: 005=0D=0A> status: draft=0D=0A> discussion: https://issues.guix.gnu.org=
/78332=0D=0A> authors: Steve George=0D=0A> sponsors: Andreas Enge, Ludovi=
c Court=C3=A8s, Efraim Flashner=0D=0A> date: <date when the discussion pe=
riod starts>=0D=0A> SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-=
invariants-or-later=0D=0A> ---=0D=0A>=0D=0A> # Summary=0D=0A>=0D=0A> Guix=
 doesn't have regular release cycle which has led to infrequent new=0D=0A=
> releases. Sporadic releases are detrimental for our users, contributors=
 and=0D=0A> the project.  This GCD proposes we implement an annual releas=
e cadence and=0D=0A> simplify the release process to make releases easier=
=2E=0D=0A>=0D=0A> The project currently releases new versions of Guix on =
an ad hoc frequency.=0D=0A> The 1.4.0 release happened in December 2022 [=
^1], which is almost 2.5 years=0D=0A> ago, at the time of writing.=0D=0A>=
=0D=0A> The weaknesses in this release strategy are:=0D=0A>=0D=0A> 1. No =
clarity on when the next Guix release is.=0D=0A> 2. Releases are complex =
and toil for developers.=0D=0A> 3. Rolling updates aren't suitable for al=
l users.=0D=0A>=0D=0A> This GCD proposes the following combined solution:=
=0D=0A>=0D=0A> 1. Regular releases: switch to a time-based release of Gui=
x every year.=0D=0A> 2. Efficient releases: use *package sets* and *suppo=
rted architectures* to=0D=0A> reduce the scope of work required to create=
 a Guix release.=0D=0A>=0D=0A> The benefits will be:=0D=0A>=0D=0A> 1. New=
 installations of Guix will be better because installation media and=0D=0A=
>    manuals will be up to date, and the initial 'guix pull' will be fast=
er.=0D=0A> 2. Package installation will improve for all users.  Packages =
will be ungrafted=0D=0A>    during each release cycle.=0D=0A> 3. Package =
quality will improve for all users, because regular releases will=0D=0A> =
   provide a cadence for focusing on our quality.=0D=0A> 4. A regular cad=
ence for promoting the project to potential users.  Helping us=0D=0A>    =
to inform more people about the benefits of using GNU Guix!=0D=0A> 5. A r=
egular release cycle is a rallying point for our contributors giving them=
 a=0D=0A>    consistent calendar of when to focus on releases versus othe=
r hacking.=0D=0A>=0D=0A> Adding a slower-moving branch akin to Nix's stab=
le could be an eventual goal as=0D=0A> it would increase Guix's suitabili=
ty for some users and use-cases [^2].  However,=0D=0A> this GCD only sets=
 out to implement regular releases which is a substantial=0D=0A> change t=
hat would be a big improvement for our users.=0D=0A>=0D=0A>=0D=0A> # Moti=
vation=0D=0A>=0D=0A> Releases are important for any Free Software project=
 because they update the=0D=0A> user experience and are a focal point for=
 excitement [^3].  Regular releases=0D=0A> help us to improve the quality=
 of our software by bringing focus, and=0D=0A> exercising regular usage s=
cenarios (e.g. testing the installer).=0D=0A>=0D=0A> The majority of dist=
ributions follow time-based releases, six months is a=0D=0A> common cycle=
 time.  For further comparison see the research on the=0D=0A> [release st=
rategies of distributions] (https://codeberg.org/futurile/guix-org/src/br=
anch/master/release-mgmt)=0D=0A> . A summary is:=0D=0A>=0D=0A> - NixOS: r=
eleases every six months (May/November), both rolling release and=0D=0A> =
slower stable branch.=0D=0A> - OpenSUSE: rolling release, slow-roll relea=
se and fixed releases.=0D=0A> - Ubuntu: every six months, with 9 months m=
aintenance. LTS releases every=0D=0A> 2 years.=0D=0A> - Debian: Every 2 y=
ears (not time fixed), with about six months of package=0D=0A> updates fr=
eeze before the release while bugs are ironed out.=0D=0A>=0D=0A> As a rol=
ling release Guix immediately provides the latest improvements to=0D=0A> =
users.  Consequently, it could be argued that releases are unnecessary.=0D=
=0A> However, they provide a focal point for the project to undertake add=
itional=0D=0A> testing and stabilisation across the repository.  They als=
o ensure we update=0D=0A> installation media, documentation, themes and w=
eb site.=0D=0A>=0D=0A> A specific issue caused by irregular releases is t=
hat new users/installs face a=0D=0A> significant first "guix pull". This =
provides a poor initial user experience,=0D=0A> and in some cases may eve=
n deter users [^4]. Additionally, it requires the=0D=0A> project to keep =
old substitutes on our servers.=0D=0A>=0D=0A> Regular releases are also g=
ood for casual users because they provide an=0D=0A> opportunity for us to=
 promote new features and improvements.  For prospective=0D=0A> users pro=
motional activity about the release means they are more likely to hear=0D=
=0A> about capabilities that will attract them to experiment with Guix.=0D=
=0A>=0D=0A> Many desktop distributions release every six months to align =
with the major=0D=0A> desktop environments (GNOME/KDE) who release two or=
 three times a year. This is=0D=0A> why Nix (May/November) and Ubuntu (Ap=
ril/October) align their releases.=0D=0A>=0D=0A> Since Guix is used [exte=
nsively as a desktop] (https://guix.gnu.org/en/blog/2025/guix-user-and-co=
ntributor-survey-2024-the-results-part-1/)=0D=0A> it would make sense to =
align with these upstream releases.  However, given that=0D=0A> Guix is a=
 volunteer project that doesn't have the practise of releasing it's=0D=0A=
> unrealistic to move to two releases a year. Something along these lines=
 could=0D=0A> be a future goal [^5].=0D=0A>=0D=0A> This GCD proposes an a=
nnual release cycle, with releases **in May**.=0D=0A>=0D=0A> To move onto=
 this cycle the first release would be a little later: aiming for=0D=0A> =
the **November of 2025**, with a short cycle to release in May 2026.=0D=0A=
>=0D=0A>=0D=0A> ## Package Sets=0D=0A>=0D=0A> There are currently over 30=
,000 packages in the archive, it's unrealistic for=0D=0A> all packages to=
 receive the same amount of QA effort for a release.=0D=0A>=0D=0A> Many o=
ther distributions focus attention on the critical parts of their=0D=0A> =
repository by identifying those packages that are required for a particul=
ar=0D=0A> user-case.  For example, Arch Linux limits their efforts to a s=
pecific=0D=0A> repository (called "main").  Ubuntu identifies various see=
ds for specific=0D=0A> use-cases which determines their maintained packag=
es; other packages outside=0D=0A> these sets do not receive security upda=
tes.=0D=0A>=0D=0A> Guix is both a package manager that can be hosted on o=
ther Linux distributions,=0D=0A> and a Linux distribution.  Limiting the =
range of packages that receive attention=0D=0A> is consequently more comp=
licated. Guix already has manifests to track which=0D=0A> packages are us=
ed by [Guix System's installer](https://git.savannah.gnu.org/cgit/guix.gi=
t/tree/etc/manifests/release.scm)=0D=0A> , so this proposal extends that =
concept.=0D=0A>=0D=0A> For this proposal Guix would identify key package =
sets which would receive the=0D=0A> most attention for QA'ing a release.=0D=
=0A>=0D=0A> The package sets would be:=0D=0A>=0D=0A> * minimal: packages =
required to boot and install a minimal Guix or Guix System=0D=0A> install=
=2E  This would include the guix daemon, kernels, boot loaders,=0D=0A> fi=
le-systems and minimal utilities.=0D=0A> * standard: packages that create=
 a core installation for all other uses.=0D=0A> * desktop: provides the p=
ackages necessary for a desktop.  This would include=0D=0A> things like X=
11/Wayland, desktop environments, key applications and themes.=0D=0A> * s=
erver: provides packages and services for a server.  This would include=0D=
=0A> standard server packages and services.=0D=0A> * hosted: provides pac=
kages and services which are necessary in hosted usage.=0D=0A>=0D=0A> Gui=
x would still make all packages and services part of a release (the entir=
e=0D=0A> archive), but only those in the `package sets` could block a rel=
ease due to a=0D=0A> significant bug.  The goal would be for this to be a=
s small a set of packages=0D=0A> as reasonably possible.  It would mean t=
hat developers could focus on the=0D=0A> critical packages and services d=
uring a release.  As an example, this would=0D=0A> mean that a major issu=
e in the Linux kernel could block a release, but not an=0D=0A> issue in a=
 game.=0D=0A>=0D=0A>=0D=0A> ## Platforms and Architecture tiers=0D=0A>=0D=
=0A> Guix is built and maintained on multiple different architectures, an=
d two=0D=0A> kernels (Linux, GNU Hurd).  As the goal of the project is to=
 maximise user=0D=0A> freedom this variety is significant and is a key mo=
tivator for developers.=0D=0A>=0D=0A> However, with limited resources (de=
veloper and CI) we want to make it as=0D=0A> efficient as possible to cre=
ate a release.  The more toil involved in a release=0D=0A> the less likel=
y developers are to work on it.=0D=0A>=0D=0A> The [2025 Guix User Survey]=
(https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-=
the-results-part-2/)=0D=0A> showed that 98% of users were on x86_64 and 1=
9% on AArch64.  Consequently, the=0D=0A> proposal is the following tiers:=
=0D=0A>=0D=0A> - Primary architectures:=0D=0A>   - Architectures: x86_64,=
 AArch64=0D=0A>   - Kernel: Linux=0D=0A>   - Coverage: all packages and s=
ervices that are not explicitly platform=0D=0A>     specific must work to=
 be included in the archive.=0D=0A>   - Package status: package updates s=
hould build for this architecture.  If a=0D=0A>     package update is bro=
ken it must not be pushed to users (e.g. master).=0D=0A>   - Security: al=
l packages that are maintained upstream receive updates=0D=0A>=0D=0A> - A=
lternative architectures=0D=0A>   - Architectures: all others=0D=0A>   - =
Kernel: Linux, Hurd=0D=0A>   - Coverage: all packages and services that a=
re not explicitly platform=0D=0A>     specific may build=0D=0A>   - Packa=
ge status: package updates should work for this architecture.=0D=0A>     =
Updates that do not build for this architecure, but do build for a primar=
y=0D=0A>     architecture may be pushed to users.=0D=0A>   - Security: no=
 commitment to providing security updates for this architecture.=0D=0A>=0D=
=0A> Packages or services that do not build for the Primary architectures=
 as part of=0D=0A> a release would be removed from the archive using Guix=
's deprecation policy.=0D=0A>=0D=0A>=0D=0A> ## Release artifacts=0D=0A>=0D=
=0A> Using the primary architecture tier and the package sets would invol=
ve creating=0D=0A> the following release artifacts:=0D=0A>=0D=0A> - GNU G=
uix System ISO image=0D=0A> - GNU Guix System QCOW2 image=0D=0A> - GNU Gu=
ix installer=0D=0A>=0D=0A> Again in an effort to reduce developer toil, a=
dditional release artifacts could=0D=0A> be created but would not be part=
 of the formal release testing and errors would=0D=0A> not block a releas=
e.=0D=0A>=0D=0A>=0D=0A> ## Release team and project=0D=0A>=0D=0A> A regul=
ar release cycle should galvanise all Guix developers to work on our=0D=0A=
> releases.  But, to ensure there are sufficient people involved a call w=
ill be=0D=0A> put out to create a specific release team for each release =
project.  We would=0D=0A> expect the final release team to be around four=
-six members. The release team=0D=0A> will work together to fix issues an=
d test the various release artifacts. The=0D=0A> expectation is that the =
release projects will be as short as possible, around=0D=0A> a 12 week co=
mmitment with each team member having a few hours a week to take=0D=0A> p=
art.=0D=0A>=0D=0A> To manage the release it's proposed that each release =
will have a Release Manager=0D=0A> role. The role of the Release Manager =
is to:=20=0D=0A>=0D=0A> - co-ordinate the release project=0D=0A> - commun=
icate with the release team and wider developers status and blockers=0D=0A=
> - arbitrate changes to release blocking bugs, package sets and release=0D=
=0A>   artifacts=0D=0A> - influence and assist teams to resolve problems=0D=
=0A> - define the release artifacts and create them=0D=0A> - encourage an=
d excite **everyone to create and test the release**=0D=0A>=0D=0A> The Re=
lease Management role is likely to require the most effort, so it will=0D=
=0A> be rotated and consist of two people from the release team.  For eac=
h release=0D=0A> there would be a primary person and a secondary person i=
n the role.  The=0D=0A> primary person is new to the role.  The secondary=
 person has previously done it=0D=0A> and is mentoring the new person.  T=
he impact of this is that each new release=0D=0A> manager is agreeing to =
take responsibility during two release cycles.=0D=0A> This system is mode=
lled on the [Nix release management](https://codeberg.org/futurile/guix-o=
rg/src/branch/master/release-mgmt/nix-release-mgmt.md)=0D=0A> approach.=0D=
=0A>=0D=0A> One of the release team will take on the role of Release Advo=
cate [^6].  They=0D=0A> will take responsibility for preparing the releas=
e announcement and=20=0D=0A> coordinating the creation of content to prom=
ote the new release (e.g. web site)=0D=0A> This role can be done by any m=
ember of the Guix community who has sufficient=0D=0A> interest.=0D=0A>=0D=
=0A> The final release team is:=0D=0A>=0D=0A> - a new Release Manager=0D=0A=
> - a returning Release Manager=0D=0A> - up to 4 other members, one of wh=
om acts as the Release Advocate=0D=0A>=0D=0A> The Release Managers of eac=
h release will create and communicate a release=0D=0A> project plan setti=
ng out the stages and dates for each stage.  To try and=0D=0A> galvanise =
the Guix development team to focus on the release it's envisioned=0D=0A> =
that a release project will be about 12 weeks. See Appendix 1: Release Pr=
oject=0D=0A> Time-line for an example.=0D=0A>=0D=0A> In order to improve =
knowledge transfer and reduce the toil of doing releases=0D=0A> the Relea=
se Managers for a release will document the release process.  There is=0D=
=0A> inspiration for this in [NixOS's release wiki](https://nixos.github.=
io/release-wiki/Home.html)=0D=0A> and we already have detailed [release d=
ocumentation](https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree=
/doc/release.org)=0D=0A> .=0D=0A>=0D=0A>=0D=0A> # Cost of Reverting=0D=0A=
>=0D=0A> If regular releases were not successful then the project would s=
witch back to=0D=0A> irregular releases.  There would be no impact for ex=
iting users as they will=0D=0A> be tracking the rolling release's master =
branch.=0D=0A>=0D=0A> If the project is able to successfully undertake re=
gular releases then over=0D=0A> time it may be possible to undertake full=
 releases every six months or some=0D=0A> other release cadence.=0D=0A>=0D=
=0A>=0D=0A> # Drawbacks and open issues=0D=0A>=0D=0A> There's no particul=
ar drawback to attempting regular release.  It should be=0D=0A> noted tha=
t the project is entirely dependent on volunteers so it may be that=0D=0A=
> contributors don't have enough time available to achieve regular releas=
es.  If=0D=0A> that's the case we would revert back to irregular releases=
=2E=0D=0A>=0D=0A> There are various improvements that could be made to th=
is process over time,=0D=0A> but no known issues.=0D=0A>=0D=0A>=0D=0A> # =
Appendix 1: Release Project Time-line=0D=0A>=0D=0A> To illustrate the maj=
or steps of a release project this is a rough time-line.=0D=0A> The aim i=
s for a 12 week active release project, with the first one using 16=0D=0A=
> weeks in total to give teams time to prepare.=0D=0A>=0D=0A> The current=
 outline builds from our current [release document](https://git.savannah.=
gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)=0D=0A>=0D=0A> | W=
eek of Project | Event |=0D=0A> | --- | --- |=0D=0A> | -5 | Nominate a re=
lease team |=0D=0A> | -4 | Notify teams of upcoming release |=0D=0A> | 01=
 | Release project start |=0D=0A> | 04 | Toolchain and transition freeze =
|=0D=0A> | 05 | Package set finalisation |=0D=0A> | 06 | Initial testing =
|=0D=0A> | 08 | Updates freeze |=0D=0A> | 08 | Breaking changes to stagin=
g |=0D=0A> | 08 | Ungraft master branch |=0D=0A> | 09 | Bugs and document=
ation focus |=0D=0A> | 09 | Branch and tag release branch |=0D=0A> | 09 |=
 Testing and hard freeze |=0D=0A> | 10 | Release candidate |=0D=0A> | 12 =
| Final release |=0D=0A> | 13 | Staging merged to master |=0D=0A> | 14 | =
Release retrospective |=0D=0A> | 15+| Relax - it's done! |=0D=0A>=0D=0A> =
### 1. Nominate a release team=0D=0A> Nominate a release team with two Re=
lease Managers (1 is the previous RM), and=0D=0A> up to 4 other people wh=
o will work on the release. Put out a call for a Release=0D=0A> Advocate =
who can be anyone in the Guix community who's willing.=0D=0A>=0D=0A> ### =
2. Notify teams of upcoming release=0D=0A> Make sure all teams are aware =
of the upcoming release.  This gives them 4 weeks=0D=0A> to undertake any=
 large transitions or major changes.=0D=0A>=0D=0A> ### 3. Release project=
 start=0D=0A> Start the project with weekly updates to guix-dev and regul=
ar meetings of the=0D=0A> release team.  Encourage participation in testi=
ng and identifying bugs from=0D=0A> the community.=0D=0A>=0D=0A> ### 4. T=
oolchain and transition freeze=0D=0A> No major changes to toolchains (e.g=
=2E gcc-toolchain, rust-1.xx) or runtimes=0D=0A> (e.g. java).  There shou=
ld be no changes that will cause major transitions.=0D=0A>=0D=0A> Debian =
defines a transition as one where a change in one package causes changes=0D=
=0A> in another, the most common being a library.  This isn't suitable fo=
r Guix since=0D=0A> any change in an input causes a change in another pac=
kage.  Nonetheless, any=0D=0A> change that alters a significant number of=
 packages should be carefully=0D=0A> considered and updates that cause ot=
her packages to break should be rejected.=0D=0A>=0D=0A> No alterations to=
 the Guix daemon or modules are accepted after this point.=0D=0A> Package=
s and services in the 'minimal' package set should not be=0D=0A> altered.=
=0D=0A=0D=0AShould this not be done on a separate release branch as soon =
as we start=0D=0Awith the release=3F There seems to be no need to freeze =
master as soon as=0D=0Awe branch off a release branch. Or did I understan=
d something wrong=3F=0D=0A>=0D=0A> ### 5. Package set finalisation=0D=0A>=
 Specify the package sets for this release.  Identify all packages and th=
eir=0D=0A> inputs so that a full manifest for the release is created.=0D=0A=
>=0D=0A> ### 6. Initial testing=0D=0A> An initial testing sprint to look =
at packages, services, install media and=0D=0A> upgrade testing. This sho=
uld identify:=0D=0A>=0D=0A> * packages or services that may need to be re=
moved because they fail on a=0D=0A>   primary architecture=0D=0A> * packa=
ges and services in the package sets install and can be used=0D=0A> * ins=
tallation artifacts can be created and used=0D=0A> * example system defin=
itions can be used=0D=0A> * system upgrades=0D=0A>=0D=0A> A build failure=
 of a package or service will result in it being identified for=0D=0A> re=
moval.  A build failure of a package or service that's in a package set w=
ill=0D=0A> be marked as a blocker for the release.=0D=0A>=0D=0A> ### 7. U=
pdates freeze=0D=0A> Major package updates are frozen on 'master' as the =
focus is on fixing any=0D=0A> blocking packages.  Security updates still =
go to 'master'.=0D=0A>=0D=0A> ### 8. Breaking changes to staging=0D=0A> T=
o avoid a period of time where teams can't commit breaking changes, these=
 are=0D=0A> sent to a new 'staging' branch, rather than directly to maste=
r.  The master=0D=0A> branch slows down from this week.=0D=0A>=0D=0A> Thi=
s concept comes from the Nix project where they flow big changes into a=0D=
=0A> staging branch while they do release stabilisation to prevent big fl=
ows of=0D=0A> breaking changes into master which broke one of their relea=
ses [^7].=0D=0A>=0D=0A> Team branches can still be folded into the releas=
e branch as long as changes are=0D=0A> minor package upgrades.=0D=0A>=0D=0A=
> ### 9. Ungraft master branch=0D=0A> Guix master is ungrafted to minimis=
e the difference with users of the release=0D=0A> initial 'guix pull' exp=
erience.=0D=0A>=0D=0A> ### 10. Bugs and documentation focus=0D=0A> The ma=
ster branch should be quiet at this point as everyone should focus on=0D=0A=
> testing and resolving any bugs.  New documentation can also be done.=0D=
=0A>=0D=0A> ### 11. Branch and tag release branch=0D=0A> The master branc=
h is tagged and a new release branch is created.=0D=0A>=0D=0A> * master b=
ranch: security only.=0D=0A> * release branch: security updates as normal=
=2E Only RC blocking bugs.=0D=0A>=0D=0A> Only security updates go to the =
master branch from week 9->13.  All other=0D=0A> changes stay in a team b=
ranch or go to the `staging` branch. The focus on the=0D=0A> release bran=
ch is to stabilise so only RC bugs should be pushed.=0D=0A>=0D=0A> ### 12=
=2E Testing and Hard Freeze=0D=0A> RC bugs and issues should be solved fo=
r the release branch.=0D=0A>=0D=0A> Only changes that will fix a non-buil=
ding package, or a bug in a package are=0D=0A> allowed.  Ideally avoid ne=
w upstream versions, but it's acceptable to use a new=0D=0A> minor upstre=
am version to solve a bug.=0D=0A>=0D=0A> Any non-building packages are re=
moved.=0D=0A>=0D=0A> ### 13. Release candidate=0D=0A> Release artifacts a=
re created for the release candidate.  There's a final 2=0D=0A> weeks of =
testing with these artifacts.  If there are no release blocking bugs=0D=0A=
> discovered then the releas uses these artifacts.  If bugs are found/fix=
ed then=0D=0A> release artifacts are regenerated as needed.=0D=0A>=0D=0A>=
 ### 14. Final release=0D=0A> Final release is announced and new release =
artifacts are published.=0D=0A>=0D=0A> ### 15. Staging merged to master=0D=
=0A> If there were any breaking changes placed onto the `staging` branch =
then these=0D=0A> can be merged into the `master` branch at this point.  =
The master branch then=0D=0A> continues as normal.=0D=0A>=0D=0A> ### 16. =
Release retrospective=0D=0A> A retrospective is undertaken by the release=
 team to understand how the release=0D=0A> process can be improved to mak=
e it more reliable for users and easier/efficient=0D=0A> for developers.=0D=
=0A>=0D=0A> ### 17. Relax!=0D=0A> The release has been cut, everyone is n=
ow excited, and hopefully all is well.=0D=0A> Take some time off from rel=
ease work!  There's some time built-in here to=0D=0A> relax and get back =
to other hacking before it's time to start again with the=0D=0A> next rel=
ease.=0D=0A>=0D=0A> ---=0D=0A>=0D=0A> [^1]: https://guix.gnu.org/en/blog/=
2022/gnu-guix-1.4.0-released/=0D=0A>=0D=0A> [^2]: Examples of distributio=
ns that have cadences for different users and screnarios=0D=0A>       are=
 Nix's stable branch, OpenSUSE's SlowRoll branch and Ubuntu's LTS=0D=0A> =
      (Long Term Support) releases.=0D=0A>=0D=0A> [^3]: the aspect of cre=
ating news and excitement for casual users is well-known=0D=0A>       in =
the FOSS community. An example from=20=0D=0A>       [GNOME's earlier days=
](https://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html).=
=0D=0A>=0D=0A> [^4]: GuixDays 2025 release discussion brought up examples=
 of Guix not being=0D=0A>       used to teach users because the initial p=
ull was so slow that the=0D=0A>       teaching session would have complet=
ed before 'guix pull' would finish.=0D=0A>       We know guix pull being =
slow was identified by users as a challenge.=0D=0A>=0D=0A> [^5]: OpenSuse=
 has a [SlowRoll branch](https://en.opensuse.org/Portal:Slowroll)=0D=0A> =
      where they release a smaller set of package updates on a monthly ba=
sis.=0D=0A>       This is an interesting innovation as it allows users to=
 still benefit from=0D=0A>       a rolling release but at a slower rate o=
f change (fewer regressions).=0D=0A>       They are also not dropping too=
 far behind the rolling release, so there's=0D=0A>       not as much main=
tenance for OpenSUSE developers dealing with an out of=0D=0A>       date =
release branch and having to backport software.=0D=0A>=0D=0A> [^6]: Nix h=
as the concept of a [Release Editor](https://nixos.github.io/release-wiki=
/Release-Editors.html)=0D=0A>       who is responsible for improving the =
legibility of the release notes.  Our=0D=0A>       version extends the id=
ea to make sure other artifacts and activities that=0D=0A>       promote =
the release happen.=0D=0A>=0D=0A> [^7]: https://github.com/NixOS/rfcs/blo=
b/master/rfcs/0085-nixos-release-stablization.md=0D=0A=0D=0AI am missing =
the automation aspect a little in this GCD. As I understand=0D=0Athe rele=
ase take so long because there is a lot of manual effort=0D=0Ainvolved in=
 doing one. I think it is worthwhile to also work towards=0D=0Amore autom=
ation in preparing a release and testing it. I have by no=0D=0Ameans a lo=
t of insight into doing a release but my impression is that=0D=0Aautomati=
on could drastically improve the time to relase.=0D=0A=0D=0AThanks again!=
=0D=0A=0D=0ABest,=0D=0AReza=0D=0A

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Ekaitz Zarraga <ekaitz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 10 May 2025 11:05:02 +0000
Resent-Message-ID: <handler.78332.B78332.174687506921061 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Andreas Enge <andreas@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174687506921061
          (code B ref 78332); Sat, 10 May 2025 11:05:02 +0000
Received: (at 78332) by debbugs.gnu.org; 10 May 2025 11:04:29 +0000
Received: from localhost ([127.0.0.1]:44504 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uDi0K-0005Tc-Lb
	for submit <at> debbugs.gnu.org; Sat, 10 May 2025 07:04:29 -0400
Received: from dane.soverin.net ([185.233.34.149]:37595)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <ekaitz@HIDDEN>) id 1uDi0H-0005Sz-M9
 for 78332 <at> debbugs.gnu.org; Sat, 10 May 2025 07:04:27 -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))
 (No client certificate requested)
 by dane.soverin.net (Postfix) with ESMTPS id 4Zvjg73PzJzyYQ;
 Sat, 10 May 2025 11:04:19 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by
 soverin.net (Postfix) with ESMTPSA id 4Zvjg65lfDzKP; 
 Sat, 10 May 2025 11:04:18 +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=csmH660c; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elenq.tech; s=soverin1;
 t=1746875059;
 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=Q8DfoP1kL7s8mc4e2OtFGDhinXuq2TrvzdZ2GRn7Rlc=;
 b=csmH660cHgSO+//EZ/TBMJNDvmO5uFeE18R7crAOqc7KCYgR2QE22Tzrxiqg+QksEo1lpQ
 CvmCydhzb93RyWyEWPXVaqBVO87l2YFAxrqqZ2OZppUxZweY+NtP/eYK4WIrfsEZilAy8j
 DIwOloxQnKt6GV6ZacI57bJZmoXaxhTE/V0H5ThTg1GPA7qpbJRUBHP4zZk4DcGVr87kfb
 52aPstQO6obtBBY3i90/xubwTmsnPIYYiImwOqw/ZRefYRLKoKIUYHTB1kysLdd4mf6qIH
 DNH6I13WwgcSboxs/347E0Yn/2EPm0B9uj26YVDcLDWw5EC19BG5c1w8sOch/w==
X-CM-Envelope: MS4xfLIBVcuJtjy7UNvHNQx9i5lZEO410cwfpNuNIzDfjUmurkhyNxCTYCyMsDH+YWPYtWA1dArC83iWQ4Od1riM8kDC5cbOwUPKmFu+bd8YROZvE4LMeKYM
 NhJuTI60HpwDf+JGqu+CVZB3xUPvoYTXuDl8Q1Br55vlvbe0fl+1XfZDikPtUQI7oRpg+14GtBcpVtf5xNklBK3zsfvoPw72zOHOYZraYLbAro/6p/sKTMUQ
 /ZyNGt5s2ZvcA3nTdqubf8NBxPvCKijJ9uoGAsQxVz4=
X-CM-Analysis: v=2.4 cv=d/oPyQjE c=1 sm=1 tr=0 ts=681f32b3
 a=h3XoKhqn/SjcKs+fSIIrUg==:117 a=h3XoKhqn/SjcKs+fSIIrUg==:17
 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10
 a=1OsDy3GxzoLBKwe72YoA:9 a=QEXdDO2ut3YA:10 a=yPy0HX4kI4LsAlP3oO-2:22
Message-ID: <a0140074-92f7-4e7b-9c58-24dfd075088a@HIDDEN>
Date: Sat, 10 May 2025 13:04:18 +0200
MIME-Version: 1.0
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <6599e0d9-ce75-470d-bcbc-511da7aedf66@HIDDEN> <aB8ZGWUXd7zIPxnA@jurong>
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: <aB8ZGWUXd7zIPxnA@jurong>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spampanel-Class: ham
X-Spam-Score: -0.7 (/)
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 2025-05-10 11:15, Andreas Enge wrote:
> 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
> 

So, there it goes!

You answered my question really clearly: We don't actually *need* to 
make the releases manually, but we need the stability that process gives 
us, specially for ungrafting.

My proposal was the most radical I could think about: just don't have a 
release process. Or as you put it "put a three digit version number in 
git commits". But the idea was to think about the grey, adding some 
black to the white the GCD proposed.

So, now, realistically speaking, we are not ready for total automation 
and we should make a release process. That I agree with, and we could 
use the process to try to slowly make the process lighter until it 
barely exists, which would at some point let us make releases more often 
and with lower effort.

The question now is how do we achieve that. You point the goal of the 
release process is the quality control. Now I wonder if there's any way 
to relief the release of some of that weight (or all of it), being a 
little bit more cautious during the rest of the year.

I know that makes every day less fun, but I'm thinking on how could we 
share the responsibility to make the work of those that are going to 
make the release as light as possible.

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

I think one of the reasons we don't have a release for that long time is 
the lack of people taking care of it. The GCD has a plan about it, but 
it relies on having people involved in the process.

I'm a little bit pessimistic about how many people would get involved in 
that, or better said: I'm worried that the very same people would be the 
ones that get involved in the process over and over again.

That's why I'm trying to find a way to make everybody get involved in 
the process in their everyday work, so the actual release process is not 
that hard and makes it more likely to people to join. The way I have to 
think about it is to imagine a future when releases can be automatic, 
and think about what is preventing us from having that now.

I like the GCD, I think it's thoughtful and well organized, but it might 
lack some of that: let's see how it went and try to make it lighter and 
lighter for the future.

Maybe adding that is just a matter of publishing some 
blogpost/survey/... after the first release is done using this process 
where people share ideas on how we could implement improvements in our 
everyday lives. After that, I suppose more GCDs would be proposed: a 
long-lived stable branch, a full-automation proposal, better CI/CD 
process, proper package testing... Whatever that is so we keep the wheel 
rolling.

There's already some of that in the GCD: package sets are a very nice 
way to make sure we are specially careful with some packages, and that's 
something we can do every single day.

Does this make more sense now?

Thanks Andreas for your response,
Ekaitz

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 10 May 2025 17:10:03 +0000
Resent-Message-ID: <handler.78332.B78332.174689694225705 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: reza <reza@HIDDEN>
Cc: "guix-devel@HIDDEN" <guix-devel@HIDDEN>, "78332 <at> debbugs.gnu.org" <78332 <at> debbugs.gnu.org>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174689694225705
          (code B ref 78332); Sat, 10 May 2025 17:10:03 +0000
Received: (at 78332) by debbugs.gnu.org; 10 May 2025 17:09:02 +0000
Received: from localhost ([127.0.0.1]:49376 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uDnh7-0006gS-Ei
	for submit <at> debbugs.gnu.org; Sat, 10 May 2025 13:09:02 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:52090)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uDnh3-0006gA-QG
 for 78332 <at> debbugs.gnu.org; Sat, 10 May 2025 13:09:00 -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 1uDngw-0079qj-Ju
 for 78332 <at> debbugs.gnu.org; Sat, 10 May 2025 19:08:50 +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=4kCak0Dthl9tRnJt1vCEY4p/gXaC/kLDNn7mBDU5vBE=; b=O/Lnk+j9/VxhC0WUzyoNfi+Ywz
 JW0qAHu/eLXzaffH2+FSI4wQX2TgIvY0tpvzU5CkUQ9GhIJ/0RRJ6THHIPQOTmKubf1BIPG8GOSgv
 ee4e4GS35LeC2EYTnfGEjs1Ynrq0eWEzX/7eGAP8p1m1iisaOj15X55Qx+TRT/oeqQleMm84yTkeB
 b/finKmbcDL5oWVq6wKt4ULPSp5mDI1NJhgVveShXNsB4XD2KO+moFGQP8Ni1enMWPyAOATJ3vxqD
 qJ87rq13go/ZJR0DYeLJkeLls4+49QqCaJdvb/eh1zV9UDbVe55EJlsYOyL/AjNxZk35+PKuQwEDE
 3jZGtYWQ==;
Received: from [10.9.9.73] (helo=submission02.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uDngv-0004Fg-SD; Sat, 10 May 2025 19:08:50 +0200
Received: by submission02.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uDngu-00E5ts-GN; Sat, 10 May 2025 19:08:48 +0200
Date: Sat, 10 May 2025 18:08:47 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <fs5f2nwfhsnr4qbld6hbexkbdacal5rcjdayjp2i6zsjxygs67@4abdernkt2e2>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87y0v468gj.fsf@HIDDEN>
 <01020196b9d67d65-4ddf4f05-f643-4607-8337-af969cb8b074-000000@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <01020196b9d67d65-4ddf4f05-f643-4607-8337-af969cb8b074-000000@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Reza,

On 10 May, reza wrote:
> Hi Steve
> 
> Thanks for the effort you put into this, I just wanted to add my
> thoughts when reading it...
(...)

Appreciate you reading it and taking the time to send your thoughts!

(...)
> > ### 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.
> 
> Should this not be done on a separate release branch as soon as we start
> with the release? There seems to be no need to freeze master as soon as
> we branch off a release branch. Or did I understand something wrong?
(...)

It definitely _can_ be done that way, it wouldn't be my preference.

In my experience, if we want the whole group to focus on doing a great release then branching off as late as possible is the best option. The social signal is that "we're all focusing on creating a release now". As we know people have different motivations and priorities, if everyone isn't focused on the release, then there's a tendancy for people to keep hacking (introducing lots of changes etc) and that can make creating a release very difficult as new instability is brought into the archive.

We kind of had a version of this a few months ago when Ludo asked for volunteers to work on doing a release 

From a technical perspective, the later that we branch off from master the better since that limits the divergence between what's in the release and what package versions the user gets when they do a 'guix pull'. It's also, I think, quite difficult managing multiple branches, so I would limit the over-head as much as possible.

That all said, it's definitely possible to branch earlier and then do everything that way. In a way that's the "Debian" approach of having a "testing" branch and then moving it towards a release. So if the group wanted to try that approach ...

(...)
> I am missing the automation aspect a little in this GCD. As I understand
> the release take so long because there is a lot of manual effort
> involved in doing one. I think it is worthwhile to also work towards
> more automation in preparing a release and testing it. I have by no
> means a lot of insight into doing a release but my impression is that
> automation could drastically improve the time to relase.
(...)

The main piece of automation that limits our ability to do a release is to do with the architectures and `make dist`. See this thread from February:

https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00184.html

The commercial distro's do have a lot of release automation that goes beyond the common tools (e.g. CA/QA/Bugtracker). At least when I was involved we had a lot of automation for automating package updates, complex hardware testing, installation testing, and various forms of upgrade testing. This short section from OpenSUSE's 'Factory development model' might give you some ideas:

https://en.opensuse.org/openSUSE:Factory_development_model#Development_Process_Overview

But, please note that the the core work of creating a release - packaging, testing packages install/work, integration between packages (services in Guix), testing the release and solving bugs - is mostly developer effort (even for RedHat or Canonical).

I personally, think we should focus on the foundations of our developer experience first and automate in that area.  Things like QA, visibility into package build/regressions, automated updates of packages. We have some of these things, and the Codeberg migration may help us improve in other areas. Here's a great example from Gentoo (similar type of volunteer distribution to Guix) of tying everything together in a clear way:

https://packages.gentoo.org/packages/mail-client/neomutt

It's true then that this GCD does not suggest any automation. It's trying to move forward through organisational (project plan) and some technical (reducing work through package sets/supported architectures).  I would love to see the project improve developer tooling - it's important - but not specific to releases. For example, I would love to see automated update testing [0] where some of the base work has already been done.

Do you have any particular areas where you think "automation" would improve releases? And/or (outside of the GCD) do you see the value of improving our developer tooling?

Steve / Futurile

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

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Ian Eure <ian@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 11 May 2025 19:20:01 +0000
Resent-Message-ID: <handler.78332.B78332.174699114731153 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174699114731153
          (code B ref 78332); Sun, 11 May 2025 19:20:01 +0000
Received: (at 78332) by debbugs.gnu.org; 11 May 2025 19:19:07 +0000
Received: from localhost ([127.0.0.1]:42378 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uECCY-00086P-NO
	for submit <at> debbugs.gnu.org; Sun, 11 May 2025 15:19:07 -0400
Received: from fout-b6-smtp.messagingengine.com ([202.12.124.149]:48385)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ian@HIDDEN>) id 1uECCT-00085b-Rb
 for 78332 <at> debbugs.gnu.org; Sun, 11 May 2025 15:19:04 -0400
Received: from phl-compute-02.internal (phl-compute-02.phl.internal
 [10.202.2.42])
 by mailfout.stl.internal (Postfix) with ESMTP id 4CF6B11400BB;
 Sun, 11 May 2025 15:18:56 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-02.internal (MEProxy); Sun, 11 May 2025 15:18:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h=
 cc:cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to; s=fm2; t=1746991136;
 x=1747077536; bh=7H56isd06Qiom9/NwBVzqam+XQhXPS2Snu50XcSJmmU=; b=
 CoVSdZtDPnLKF6jvzYDeow+WwnZ+qm3qudaomnLC64RZSZ2a3JF1aTb2A+5M5IHn
 vVWatSockhCwxGrrttHkj1Rmphvjte5pMfh7fIEzdf17Js8G6ogk37ieC7TByqco
 eZ18mfxvTipHiviomppXtzO8atGfohmoTVYI+PFTVzKlaloaWS5ZN1CLl4QOQU45
 jnleZPZdIG5i+neo2ZLuB2SkxrDPy0wmA8YpvTo+LuvPGJz+Ij3Jos0Yxvvq/p64
 LR8ZWb3wrCXCJk+r/w/DUT6dxOudCv+Eud0EK7DKvOHnGwz2NWodElnrGnWnD5cJ
 U2KaycIS2FdFa5pLT1VzQw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1746991136; x=
 1747077536; bh=7H56isd06Qiom9/NwBVzqam+XQhXPS2Snu50XcSJmmU=; b=W
 q1r5JGlCzSVjeMZKp85PtTzeXdEarql6AcvldB7K0GEx9wtsGrKcZk2ee2I4hgYZ
 0Vfpg9kBusSTWZSNJvOVGaWFeBkwcLugMB95j8bGh6UKzjFrsd2I07tcZlLE995/
 ZOU08IqaExVVNA5YyCAuAy9/qRGep2Y8Ga3jbZ3Hup4Z4ZBpd72cAZFFcVBqCpKm
 p3OVBRLAmynK+kRCnZP/tbmc/S5+Lp9SwWuvpvYEfpHn9fNRA+aLybhgBoJmG0oY
 XN0AvagQEQVyq1NSJqLBqMxdK1rA6B9RagCxfqqYeawyBQKr/lanaWtKwKIVR+48
 Q/u3srfY2eQg5+sF//Krg==
X-ME-Sender: <xms:H_ggaLgW2HkPU3jf5gCDvNCFlxiiGgtWBStrEPxkucOzvZ5p9U1k9A>
 <xme:H_ggaIAYAc9VvIf-R5snojCHBlN9ETl9bAZjyo9QUVgkWjwSbpK2vZddeDymjjqxs
 cG80fqfJqutvotNRw>
X-ME-Received: <xmr:H_ggaLHG2qy7jaU46dv1CH58o0KWDGK-T7LLbHmf8Fhb94qOzEmgL6G0n8Z8xZG91ivRut-1hAFXyYHUosrnzVoYQO9AISYw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvleelvddtucetufdoteggodetrf
 dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
 pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
 gvnhhtshculddquddttddmnecujfgurhephffvvefujghffgffkfggtgfgsehtqhertddt
 reejnecuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvh
 eqnecuggftrfgrthhtvghrnhepveeuleeugedujeeukefhhffhlefgjeehfeffhefgffel
 keevkeeutdegkeelgeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg
 hilhhfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeef
 pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeejkeeffedvseguvggssghughhsrd
 hgnhhurdhorhhgpdhrtghpthhtohepghhuihigqdguvghvvghlsehgnhhurdhorhhgpdhr
 tghpthhtohepshhtvghvvgesfhhuthhurhhilhgvrdhnvght
X-ME-Proxy: <xmx:H_ggaIQLuRWBrVYH86HvppqIiktcAT7ElrpcqocsjeLfrQMZ0bcHVQ>
 <xmx:H_ggaIxDFtLCMFoquNYzrPqy2FIHwvUDzR5bmFimtN5hLU4jvMluog>
 <xmx:H_ggaO4mIaIEXcjMbCh3pn2oCq69hvvFZbv9StGC3lUyEM33BFRHxw>
 <xmx:H_ggaNz4HIvPBb7_M_tY0ol0UrpGtNn0yMcLPs9kCjLxcmNijYKInw>
 <xmx:IPggaLRi1_K-kxlEYXUBqpA3ZapM7CS4kkEaUhqM21WPjYPloMBiCJrS>
Feedback-ID: id9014242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 11 May 2025 15:18:55 -0400 (EDT)
From: Ian Eure <ian@HIDDEN>
In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 (Steve George's message of "Fri, 9 May 2025 13:53:39 +0100")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Sun, 11 May 2025 12:18:54 -0700
Message-ID: <87frhb5529.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
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 Steve,

Steve George <steve@HIDDEN> writes:

> 3. Rolling updates aren't suitable for all users.

If a Guix release is a point in time snapshot of a rolling=20
release, and the first `guix pull' after
installation puts you back into the rolling release model, I don=E2=80=99t=
=20
think more frequent releases address this need.


> Adding a slower-moving branch akin to Nix's stable could be an=20
> eventual goal as
> it would increase Guix's suitability for some users and=20
> use-cases [^2].  However,
> this GCD only sets out to implement regular releases which is a=20
> substantial
> change that would be a big improvement for our users.


> A specific issue caused by irregular releases is that new=20
> users/installs face a
> significant first "guix pull". This provides a poor initial user=20
> experience,
> and in some cases may even deter users [^4]. Additionally, it=20
> requires the
> project to keep old substitutes on our servers.

It also causes user confusion becasue the assumption is that the=20
release is what they should be using.  We get a good number of=20
folks in #guix reading the 1.4.0 manual, which doesn=E2=80=99t accurately=20
reflect the current state of things.

> This GCD proposes an annual release cycle, with releases **in=20
> May**.
>
> To move onto this cycle the first release would be a little=20
> later: aiming for
> the **November of 2025**, with a short cycle to release in May=20
> 2026.

I think it=E2=80=99d be better to align the initial release with the=20
schedule we want to keep, so if we plan for a November release,=20
plan to release every November.


> ## Release artifacts
>
> Using the primary architecture tier and the package sets would=20
> involve creating
> the following release artifacts:
>
> - GNU Guix System ISO image
> - GNU Guix System QCOW2 image
> - GNU Guix installer

I=E2=80=99m not sure what the difference is between the installer and=20
system ISO image is, could you elaborate please?


> Again in an effort to reduce developer toil, additional release=20
> artifacts could
> be created but would not be part of the formal release testing=20
> and errors would
> not block a release.

The 1.4.0 release artifacts are[1]:

- Installer image for i686 and x86_64.
- QCow image for x86_64.
- Binary for i686, x86_64, armhf, aarch64, and powerpc64e.
- Source tarball.

Are the binaries and source tarballs "additional release=20
artifacts?"


> ### 4. Toolchain and transition freeze
> No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx)=20
> or runtimes
> (e.g. java).  There should be no changes that will cause major=20
> transitions.
>
> Debian defines a transition as one where a change in one package=20
> causes changes
> in another, the most common being a library.  This isn't=20
> suitable for Guix since
> any change in an input causes a change in another package.=20
> Nonetheless, any
> change that alters a significant number of packages should be=20
> carefully
> considered and updates that cause other packages to break should=20
> be rejected.
>
> No alterations to the Guix daemon or modules are accepted after=20
> this point.
> Packages and services in the 'minimal' package set should not be=20
> altered.

I think it=E2=80=99s worth considering doing this the other way around:=20
instead of freezing master, cut a release branch and cherry-pick=20
fixes into it as needed.  I don=E2=80=99t expect that development on=20
non-release features will stop during the freeze, which means=20
we=E2=80=99ll have a large backlog of work to merge once the freeze ends;=20
this is a thing Guix has historically not been good at working=20
through in a timely manner.

A release branch would also support longer-term stable releases,=20
if we wanted to do that.

The downside is that it=E2=80=99s more work to cherry-pick fixes between=20
branches, and there=E2=80=99s the potential for merge conflicts.


> ### 7. Updates freeze
> Major package updates are frozen on 'master' as the focus is on=20
> fixing any
> blocking packages.  Security updates still go to 'master'.

This could prove troublesome, as the current Guix approach is to=20
update packages to the version containing the fix.  Are you=20
thinking that we=E2=80=99d maintain that, or adopt a Debian style of=20
backporting fixes where possible?

> ### 8. Breaking changes to staging
> To avoid a period of time where teams can't commit breaking=20
> changes, these are
> sent to a new 'staging' branch, rather than directly to master.=20
> The master
> branch slows down from this week.

This is going to be difficult to manage, especially for=20
contributions from those new to Guix development.

Thank you for starting the discussion!

  -- Ian

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Rutherther <rutherther@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 11 May 2025 20:39:04 +0000
Resent-Message-ID: <handler.78332.B78332.174699589523787 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Ian Eure <ian@HIDDEN>, Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174699589523787
          (code B ref 78332); Sun, 11 May 2025 20:39:04 +0000
Received: (at 78332) by debbugs.gnu.org; 11 May 2025 20:38:15 +0000
Received: from localhost ([127.0.0.1]:43809 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEDR8-0006Bb-SW
	for submit <at> debbugs.gnu.org; Sun, 11 May 2025 16:38:15 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::]:43448 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 1uEDR5-0006BD-G0
 for 78332 <at> debbugs.gnu.org; Sun, 11 May 2025 16:38:12 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id f27adfb7
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); 
 Sun, 11 May 2025 20:38:04 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
In-Reply-To: <87frhb5529.fsf@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87frhb5529.fsf@HIDDEN>
Date: Sun, 11 May 2025 22:38:02 +0200
Message-ID: <87y0v2993p.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=1746995884; h=from : to : cc
 : subject : in-reply-to : references : date : message-id :
 mime-version : content-type : content-transfer-encoding : from;
 bh=Bi1thtEMTKyPoNgyNZYvd8g07TqGju9/2EUizO+z+N8=;
 b=ZlDC+XqJ/g2clIgbbqJmbYcsss0wXt8R4R8nl8s2AUIDAc2QoBSwPrGnbreJFiT9Snfuc
 d7XGAdaZi6XLWXMGnbHHLS5+O+6gMIU1lJHbrHO/5bCnF70PF8W3Iv1+vwlfbbYMfhP98Nc
 SGonTaLzUMqev5grwbkgG4he6EPYcCc=
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 Ian, Ian Eure <ian@HIDDEN> writes: > > I think =?UTF-8?Q?it=E2=80=99s?=
    worth considering doing this the other way around: > instead of freezing
   master, cut a release branch and cherry-pick > fixes into it as needed. I
   =?UTF-8?Q?don=E2=80=99t?= expect that development on [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
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 Ian, Ian Eure <ian@HIDDEN> writes: > > I think =?UTF-8?Q?it=E2=80=99s?=
    worth considering doing this the other way around: > instead of freezing
   master, cut a release branch and cherry-pick > fixes into it as needed. I
   =?UTF-8?Q?don=E2=80=99t?= expect that development on [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  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 Ian,

Ian Eure <ian@HIDDEN> writes:

>
> I think it=E2=80=99s worth considering doing this the other way around:=20
> instead of freezing master, cut a release branch and cherry-pick=20
> fixes into it as needed.  I don=E2=80=99t expect that development on=20
> non-release features will stop during the freeze, which means=20
> we=E2=80=99ll have a large backlog of work to merge once the freeze ends;=
=20
> this is a thing Guix has historically not been good at working=20
> through in a timely manner.
>
> A release branch would also support longer-term stable releases,=20
> if we wanted to do that.
>
> The downside is that it=E2=80=99s more work to cherry-pick fixes between=
=20
> branches, and there=E2=80=99s the potential for merge conflicts.

I think that currently this isn't achievable very well. If release and
master are diverging branches, and they will be if work is in both of
them, then if users install the system from that, then pull, and reconfigur=
e,
their forward update check will fail as it expects the new commit to be
descendant of the old one, and it won't be. That would be causing confusion.

Regards
Rutherther

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Ian Eure <ian@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 01:51:02 +0000
Resent-Message-ID: <handler.78332.B78332.174701460225326 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Rutherther <rutherther@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174701460225326
          (code B ref 78332); Mon, 12 May 2025 01:51:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 01:50:02 +0000
Received: from localhost ([127.0.0.1]:48484 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEIIr-0006aE-Ku
	for submit <at> debbugs.gnu.org; Sun, 11 May 2025 21:50:02 -0400
Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]:47037)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ian@HIDDEN>) id 1uEIIo-0006Zi-DB
 for 78332 <at> debbugs.gnu.org; Sun, 11 May 2025 21:49:59 -0400
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfhigh.stl.internal (Postfix) with ESMTP id B8E5525400E3;
 Sun, 11 May 2025 21:49:52 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-03.internal (MEProxy); Sun, 11 May 2025 21:49:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h=
 cc:cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to; s=fm2; t=1747014592;
 x=1747100992; bh=g/gK/AyglAfhJVZ63dLdcEcBb5rwl3ZGAeXeE3Aex94=; b=
 e7DcBnNRM5gkEg7Q+dKFppKAPoDmvw1YPb15z6UqazrhYHeFybN2Rc+ovt21ByDU
 4oNj+z9TO6Rfjj0ymfx1Kdhutu2KGSSEBKy7WFeXb5n7vZSULi6wMufngw1Pvmh1
 Lu7hs0wS6QkGKPIYAkUfkCQZ3W0AIU4sTeQBv4strTUGCpupiFK9Y0YeCaiwqLEb
 44offyEaDWJp7D2/6xdZKx+BxtjvNe5/C9Qdkp+XkiLej1f8EYrG/sDv4MR1Shra
 v3QcM9+kCQnIyjv0syG2l5Uk5UHQoN9VCliKZTWB51uWhLanwOmquSmQwwLR99ZV
 fBSkzxxqzDu5FXoNRDazGw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1747014592; x=
 1747100992; bh=g/gK/AyglAfhJVZ63dLdcEcBb5rwl3ZGAeXeE3Aex94=; b=Y
 0usNYCyEK7B2J17z11I3spFRRXV5ZyJkeA2Y5Aqw23BOBMehkA9i4INoaC+k4rlZ
 R6+/w0SEmWI41ofjvGyHVu17OpA0Jq8di6lgjDa19nLtw3IvvNfLwNvlr5gNYwDF
 shoukzFkin53shnRJt3TbhdHWGuXf4fQzFam3tklz/uX2go0cwmFZCtP6nz4o9TA
 WKJbmGOlT1xsrjgVAAJuuuAk22lP1huZ40hOr+sZFVMuSBU5y5r0mYa8v6uqZBv0
 68CMLfWjWMITbepIOvodb1eeyRAqYVq7lMBQ4rwgcR2FDXzjwTeTSef+B3LL8rL0
 RxMzyoMT5e456Scyll8cw==
X-ME-Sender: <xms:wFMhaK1HxIpqlTe5aVmIjxUGSDcy_XxdI-Y1yuMDBdXvtwZX8QcCjw>
 <xme:wFMhaNEOas-regJxKbdT0I4ukIJQnblhnD2r6bEuycsjAeU4B_Aze1vBgZUMyP-C5
 TrOti7rWa6oXh_Elw>
X-ME-Received: <xmr:wFMhaC5thHfD09V4MiEis9EW-DJdtj7e12l9jR16EiG6xLwE-rBklScb-nLC_-1UYFwDBWjCn6iuTnMGZbdomp4sYG8Y1KPw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvleelleekucetufdoteggodetrf
 dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
 pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
 gvnhhtshculddquddttddmnecujfgurhephffvvefujghffgffkfggtgfgsehtqhertddt
 reejnecuhfhrohhmpefkrghnucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvh
 eqnecuggftrfgrthhtvghrnhepveeuleeugedujeeukefhhffhlefgjeehfeffhefgffel
 keevkeeutdegkeelgeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg
 hilhhfrhhomhepihgrnhesrhgvthhrohhsphgvtgdrthhvpdhnsggprhgtphhtthhopeeg
 pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeejkeeffedvseguvggssghughhsrd
 hgnhhurdhorhhgpdhrtghpthhtohepghhuihigqdguvghvvghlsehgnhhurdhorhhgpdhr
 tghpthhtohepshhtvghvvgesfhhuthhurhhilhgvrdhnvghtpdhrtghpthhtoheprhhuth
 hhvghrthhhvghrseguihhtihhgrghlrdighiii
X-ME-Proxy: <xmx:wFMhaL08xayCek6uUePStKiWp70QcCASRjRFoJbA-85dOISnbgjvtA>
 <xmx:wFMhaNFuDOXa0IE9G4z6SxZ6bLPdvGOudbYDonDu4YuzmSDe54Zryw>
 <xmx:wFMhaE-RbZndRLL3vI2gYd4Z-ECDeX4Z0tiuVAULi13H-pJTbijU3g>
 <xmx:wFMhaClqpa3o18s-xgA-H2HYiamb-Lde-gqeCy9ShpR0tsPaFYdweA>
 <xmx:wFMhaPmcxyZdLtsxJ26EwcEkST7z8Re5XijtImGxTb_-IBh8nJMbAoNC>
Feedback-ID: id9014242:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 11 May 2025 21:49:51 -0400 (EDT)
From: Ian Eure <ian@HIDDEN>
In-Reply-To: <87y0v2993p.fsf@HIDDEN> (rutherther@HIDDEN's message of
 "Sun, 11 May 2025 22:38:02 +0200")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87frhb5529.fsf@HIDDEN> <87y0v2993p.fsf@HIDDEN>
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Sun, 11 May 2025 18:49:49 -0700
Message-ID: <87a57i7g3m.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.3 (+)
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 Rutherther, Rutherther <rutherther@HIDDEN> writes:
    > Ian Eure <ian@HIDDEN> writes: > >> >> I think =?UTF-8?Q?it=E2=80=99s?= worth considering
    doing this the other way around: >> instead of freezing master, cut a release
    branch and >> cherry-pick >> fixes into it [...] 
 
 Content analysis details:   (1.3 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.
                            [202.12.124.159 listed in bl.score.senderscore.com]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [202.12.124.159 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
  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.
                             [202.12.124.159 listed in sa-accredit.habeas.com]
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: 0.3 (/)

Hi Rutherther,

Rutherther <rutherther@HIDDEN> writes:

> Ian Eure <ian@HIDDEN> writes:
>
>>
>> I think it=E2=80=99s worth considering doing this the other way around:=
=20
>> instead of freezing master, cut a release branch and=20
>> cherry-pick=20
>> fixes into it as needed.  I don=E2=80=99t expect that development on=20
>> non-release features will stop during the freeze, which means=20
>> we=E2=80=99ll have a large backlog of work to merge once the freeze=20
>> ends;=20
>> this is a thing Guix has historically not been good at working=20
>> through in a timely manner.
>>
>> A release branch would also support longer-term stable=20
>> releases,=20
>> if we wanted to do that.
>>
>> The downside is that it=E2=80=99s more work to cherry-pick fixes=20
>> between=20
>> branches, and there=E2=80=99s the potential for merge conflicts.
>
> I think that currently this isn't achievable very well. If=20
> release and
> master are diverging branches, and they will be if work is in=20
> both of
> them, then if users install the system from that, then pull, and=20
> reconfigure,
> their forward update check will fail as it expects the new=20
> commit to be
> descendant of the old one, and it won't be. That would be=20
> causing confusion.

Hmm, good point, I think you=E2=80=99re right.

 -- Ian

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Felix Lechner <felix.lechner@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 03:17:01 +0000
Resent-Message-ID: <handler.78332.B78332.174701981010576 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Rutherther <rutherther@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>, Ian Eure <ian@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174701981010576
          (code B ref 78332); Mon, 12 May 2025 03:17:01 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 03:16:50 +0000
Received: from localhost ([127.0.0.1]:48774 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEJes-0002kW-7H
	for submit <at> debbugs.gnu.org; Sun, 11 May 2025 23:16:50 -0400
Received: from sail-ipv4.us-core.com ([208.82.101.137]:51054)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <felix.lechner@HIDDEN>)
 id 1uEJep-0002kL-FC
 for 78332 <at> debbugs.gnu.org; Sun, 11 May 2025 23:16:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=2017; bh=r//BNXHhM44JT/u
 vLQTTXOuxZ6pTIv2pPI2ElmRH5es=;
 h=date:references:in-reply-to:subject:
 cc:to:from; d=lease-up.com; b=nA5+AeB7xBWkPu0Buia9axIlH5HMnVth5RdV2tRz
 Il4jG4tuXXx0+dGuh/N/3dNKDbt4mSrp14UMigJIB8WdRR8sYg+rOc0GM+dRsiFpvCyWdv
 PKrNrdWDF0j6qbMCazNZ1zxR6EhqIjSxbVu7JacjpeYvyQ9qdaXJnMLnPOUvQ=
Received: by sail-ipv4.us-core.com (OpenSMTPD) with ESMTPSA id df895c0a
 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); 
 Mon, 12 May 2025 03:16:43 +0000 (UTC)
From: Felix Lechner <felix.lechner@HIDDEN>
In-Reply-To: <87y0v2993p.fsf@HIDDEN> (rutherther@HIDDEN's message of
 "Sun, 11 May 2025 22:38:02 +0200")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87frhb5529.fsf@HIDDEN> <87y0v2993p.fsf@HIDDEN>
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Sun, 11 May 2025 20:16:43 -0700
Message-ID: <87bjryjz6s.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
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 Ian and Rutherther,

On Sun, May 11 2025, Rutherther wrote:

> If release and master are diverging branches

Could the monorepo be broken up in such a way that release work might
take place in one part while regular development continues in the
others?

The release team would focus on each part in turn, going back if needed,
and would block regular contributions while there.

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

Kind regards
Felix

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Felix Lechner <felix.lechner@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 03:36:01 +0000
Resent-Message-ID: <handler.78332.B78332.174702095114482 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Rutherther <rutherther@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>, Ian Eure <ian@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174702095114482
          (code B ref 78332); Mon, 12 May 2025 03:36:01 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 03:35:51 +0000
Received: from localhost ([127.0.0.1]:48849 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEJxG-0003lV-KK
	for submit <at> debbugs.gnu.org; Sun, 11 May 2025 23:35:50 -0400
Received: from sail-ipv4.us-core.com ([208.82.101.137]:32968)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <felix.lechner@HIDDEN>)
 id 1uEJxD-0003lF-QS
 for 78332 <at> debbugs.gnu.org; Sun, 11 May 2025 23:35:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=2017; bh=mjvdhGgNfy+A5Tg
 rI6jtzu0kJSY12pe/WLC8WIEPUHg=;
 h=date:references:in-reply-to:subject:
 cc:to:from; d=lease-up.com; b=aJsJ79lCe7icwlOXgrMoWOdpaZQVKvqsiqsmpKoV
 rkB8XrV/FonBqoHokUaYjJ2QNY1QbBkDRkUD/MLGSIAhUKdEmP76K/Rxjw0OaqpWe/8hoj
 AX4LyGJ8jPVnaCZTmXRLRQnrn319edtXY+8DlPvyAh6XLflaY62GbGVCcORyQ=
Received: by sail-ipv4.us-core.com (OpenSMTPD) with ESMTPSA id 4e65678b
 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); 
 Mon, 12 May 2025 03:35:44 +0000 (UTC)
From: Felix Lechner <felix.lechner@HIDDEN>
In-Reply-To: <87y0v2993p.fsf@HIDDEN> (rutherther@HIDDEN's message of
 "Sun, 11 May 2025 22:38:02 +0200")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87frhb5529.fsf@HIDDEN> <87y0v2993p.fsf@HIDDEN>
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Sun, 11 May 2025 20:35:44 -0700
Message-ID: <875xi6jyb3.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
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 Ian and Rutherther,

On Sun, May 11 2025, Rutherther wrote:

> If release and master are diverging branches

Sorry to double up.

From a technical point of view, I think it would be superior to have
package functions that accept a version (i.e. not variables like now)
and define releases and the current development "branch" by the package
versions they pull in.

There would be no conflict between release work and regular development
activity.

Services would also have to be versioned.

Kind regards
Felix

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 10:10:02 +0000
Resent-Message-ID: <handler.78332.B78332.174704459230989 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Ian Eure <ian@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174704459230989
          (code B ref 78332); Mon, 12 May 2025 10:10:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 10:09:52 +0000
Received: from localhost ([127.0.0.1]:50462 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEQ6Z-00083h-CB
	for submit <at> debbugs.gnu.org; Mon, 12 May 2025 06:09:52 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:49466)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uEQ6V-00083L-Io
 for 78332 <at> debbugs.gnu.org; Mon, 12 May 2025 06:09:49 -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 1uEQ6N-00BoKP-PA; Mon, 12 May 2025 12:09:39 +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=bVfpZwRxcTVv909iG2Ff82i7DfbEYrjgYJkQ7IoD0w4=; b=RgGgK7bR/2C8dz+Tz1ZDCCpPPk
 sSNLF+e6J3y8G3b58ZOljGLogKFxP1JprJ8PJpXdZJ9bKoy0EimJSfXKeWb/4bHZ2O/PD2QD6rhSQ
 LzGwxbauiPq8TxyMR5wGTF8i5gjEnOFmmzoXBRQfQ3cKFau8bo3p1lZrqNCHWiUYDna40/I3cmu6b
 /gRZ8FjBqK4Pij/iRTCwoXX7dV3UvCle/NtTTkaJmdv3ZyhUBACxWD0UAKWZ+naPzm8I1hSLCn2En
 nw5Hh0DWGmN2ESuj8y90BUL5DHKhotpLVXD8yTPzp3ZnEvK6p3xT7xmQVGu9zTo8dUejVSx3EOtMc
 3NkZJfPw==;
Received: from [10.9.9.74] (helo=submission03.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uEQ6M-00006p-Vg; Mon, 12 May 2025 12:09:39 +0200
Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uEQ66-006v7l-Hd; Mon, 12 May 2025 12:09:22 +0200
Date: Mon, 12 May 2025 11:09:21 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <hy2p7yhcsl5o4p3as77ne2ffqzzslikuvdmir6t3gyqo3fw5zm@gcslqzch3i2p>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87frhb5529.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87frhb5529.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Ian,

On 11 May, Ian Eure wrote:
> Hi Steve,
> 
> Steve George <steve@HIDDEN> writes:
> 
> > 3. Rolling updates aren't suitable for all users.
> 
> If a Guix release is a point in time snapshot of a rolling release, and the
> first `guix pull' after
> installation puts you back into the rolling release model, I don’t think
> more frequent releases address this need.
(...)

Yes, so this GCD doesn't resolve any issues with the rolling release not being suitable for all users (problem 3). An earlier version did, but following input from the sponsors I cut the GCD down to focus it and make it easeir to implement - one change at a time! That's why it refers to the idea that in future we could implement slower moving branches, or something else - something along those lines would resolve that issue - but it's out of scope for this GCD.

This GCD focuses on problem (1) and (2) only.

Rereading it this morning, it's not clear, so I will alter the paragraph to make it clear. Thanks!


> > 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.
> 
> 
> > 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.
> 
> It also causes user confusion becasue the assumption is that the release is
> what they should be using.  We get a good number of folks in #guix reading
> the 1.4.0 manual, which doesn’t accurately reflect the current state of
> things.
> 

Agreed.


> > 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.
> 
> I think it’d be better to align the initial release with the schedule we
> want to keep, so if we plan for a November release, plan to release every
> November.
> 

An annual spring release would be better due to alignment in the ecosystem around stabilisation: it's beneficial to get the additional stabilisiation that the commercial distro's do and RHEL/LTS's always do a spring release [0]. I outlined this a bit more elsewhere in the thread, but can go into more detail.

I personally would like us to do a release before $SPRING 2026. Doing releases more often, should help us get better at them, automate them (see comments from Ekaitz/Reza), so hopefully doing a November and then a $SPRING would be achievable.

I would give shifting to a $SPRING time-frame, priority over doing the November one if it was an absolute choice, as I think that time of year is optimal. 


> > ## 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
> 
> I’m not sure what the difference is between the installer and system ISO
> image is, could you elaborate please?
> 

AIUI we have two install paths (product?), one is installing 'Guix System' as a Linux distribution, the other is installing 'Guix' (package manager) on a foreign distribution. For a release we update both. So 'GNU Guix installer' was refering to the Guix as a package manager, and the other two were 'Guix System'.
> > 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.
> 
> The 1.4.0 release artifacts are[1]:
> 
> - Installer image for i686 and x86_64.
> - QCow image for x86_64.
> - Binary for i686, x86_64, armhf, aarch64, and powerpc64e.
> - Source tarball.
> 
> Are the binaries and source tarballs "additional release artifacts?"
> 

Yes, good catch. I'll add 'GNU Guix Source tarball', I believe that the existing 'GNU GUIX installer' covers the binary point.

This section is covering the minimum created artifacts, which would be the focus of developer work and testing. Nothing stops additional artifacts being created - for example the latest downloads page (https://guix.gnu.org/en/download/latest/) has a Pinebook Pro image.

(...)
> > ### 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.
> 
> I think it’s worth considering doing this the other way around: instead of
> freezing master, cut a release branch and cherry-pick fixes into it as
> needed.  I don’t expect that development on non-release features will stop
> during the freeze, which means we’ll have a large backlog of work to merge
> once the freeze ends; this is a thing Guix has historically not been good at
> working through in a timely manner.
> 
> A release branch would also support longer-term stable releases, if we
> wanted to do that.
> 
> The downside is that it’s more work to cherry-pick fixes between branches,
> and there’s the potential for merge conflicts.
(...)

In the context of doing a release I think we _could_ cut the release branch earlier in the project. Rutherther also brought this up. It's definitely a trade-off. I selected to stay on the master branch for as long as possible because (a) the group has had difficulty with long-running branches, (b) the social signal of doing a release, for a few weeks we all focus on it. I agree we may block up with items to go to master, though given our current velocity a 5 week freeze doesn't seem that big to me.

I think that Efraim has an idea that would also try to reduce the freeze time - which I think is along the lines of what you're outlining Ian - Efraim do you want to chime in here?

I agree a release branch would also support some form of longer-term stable branch. I don't think doing it that way is a necessary precursor for this GCD, but I do take the point! For now I would keep the idea of maintaining two branches outside the scope of this GCD.


> > ### 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'.
> 
> This could prove troublesome, as the current Guix approach is to update
> packages to the version containing the fix.  Are you thinking that we’d
> maintain that, or adopt a Debian style of backporting fixes where possible?
(...)

We'd maintain our current approach as we are ultimately a rolling release.

My point here was to hold us for a couple of weeks only pushing 'security' issues to the branch, so that the whole of the team can focus on testing the release and fixing release-critical bugs on the 'release' branch. For devs that don't want to focus on the release they can continue to push to their team-branches and/or the "staging" (z572 thinks this sould be called something else).

> > ### 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 is going to be difficult to manage, especially for contributions from
> those new to Guix development.

We already have this problem in the sense that new contributors send contributions against master, and a lot of work is actually against team-branches. For example, people send package updates for rust/python and we already have them in rust-team/python-team branches. I agree it's difficult to manage as it will be a "new thing".

> Thank you for starting the discussion!
(...)

It sounds like you're broadly in favour, but the main improvement would be flipping the branches around.

Thanks for the input!

Steve / Futurile


[0] Ubuntu/Canonical LTS's are always the April release. RedHat is a bit less clear to me, but RHEL 9 was in May, and they've announced that RHEL 10 is mid-2025 so I _think_ they are also on a spring release cycle 
 - https://www.redhat.com/en/blog/red-hat-enterprise-linux-10-beta-now-available - mentions "to release a new major edition every three years .... RHEL 10, due to reach general availability in mid-2025"
 - https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux - RH9 May 2022, RH8 May 2019

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 10:17:02 +0000
Resent-Message-ID: <handler.78332.B78332.174704497832613 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Felix Lechner <felix.lechner@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Rutherther <rutherther@HIDDEN>, Ian Eure <ian@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174704497832613
          (code B ref 78332); Mon, 12 May 2025 10:17:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 10:16:18 +0000
Received: from localhost ([127.0.0.1]:50497 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEQCn-0008Tv-Sr
	for submit <at> debbugs.gnu.org; Mon, 12 May 2025 06:16:18 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:41710)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uEQCl-0008Tb-Jd
 for 78332 <at> debbugs.gnu.org; Mon, 12 May 2025 06:16:16 -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 1uEQCc-00BwCI-2j; Mon, 12 May 2025 12:16:06 +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=ki9hrQkdQsnFGdGYgCIdQNoNDm+WJg9FlDgIvxW0Cgo=; b=wvxE69FfW96qsRPvbS06Yc8SnP
 aJgrvkIBTs6iAsRhDg2zi2s6S0ndjjoZrBc3xSI9poB19ua+1piA7CRt1wDEa8ayr6Kb1XoqkfvWu
 PsiiKD6MePgk+LMd2K+k4uXdIQ/HWGmKCbdEOhXww4BNxZxwsIPrjE1Lqv4BaoD3x8Zs8uId3QSaC
 XF17zHMtpbs0gEPBL6q2eLy+PmprMx2M0L5c0XWT8qk2A1THTZufc0UMoIcscLUea71c56/FhlbHJ
 qRnKEkQsU8dTEbj7ago/6s5VwSXddLxGsH6VTzmvSMLVZgUrh2+wlf0GEb9sSOHITeq8SfhEuvAs/
 i2aIxH4A==;
Received: from [10.9.9.72] (helo=submission01.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uEQCZ-0000eE-W8; Mon, 12 May 2025 12:16:04 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uEQCX-007EGl-OG; Mon, 12 May 2025 12:16:01 +0200
Date: Mon, 12 May 2025 11:16:00 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <izqwz32rmde6tsbd3qljhqdl6tkojnqrc6kscrziqo6wnpfbjj@7y4ynujbkpiz>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87frhb5529.fsf@HIDDEN> <87y0v2993p.fsf@HIDDEN>
 <875xi6jyb3.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <875xi6jyb3.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Felix,

On 11 May, Felix Lechner via Guix-patches via wrote:
> Hi Ian and Rutherther,
> 
> On Sun, May 11 2025, Rutherther wrote:
> 
> > If release and master are diverging branches
> 
> Sorry to double up.
> 
> From a technical point of view, I think it would be superior to have
> package functions that accept a version (i.e. not variables like now)
> and define releases and the current development "branch" by the package
> versions they pull in.
> 
> There would be no conflict between release work and regular development
> activity.
> 
> Services would also have to be versioned.
(...) 

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

Thanks,

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Efraim Flashner <efraim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 12:39:02 +0000
Resent-Message-ID: <handler.78332.B78332.17470535178354 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Ian Eure <ian@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17470535178354
          (code B ref 78332); Mon, 12 May 2025 12:39:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 12:38:37 +0000
Received: from localhost ([127.0.0.1]:51190 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uESQW-0002Ae-0n
	for submit <at> debbugs.gnu.org; Mon, 12 May 2025 08:38:37 -0400
Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:44226)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <efraim.flashner@HIDDEN>)
 id 1uESQQ-0002AG-PV
 for 78332 <at> debbugs.gnu.org; Mon, 12 May 2025 08:38:32 -0400
Received: by mail-ed1-x536.google.com with SMTP id
 4fb4d7f45d1cf-5fbee322ddaso8210834a12.0
 for <78332 <at> debbugs.gnu.org>; Mon, 12 May 2025 05:38:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1747053505; x=1747658305; darn=debbugs.gnu.org;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender:from:to
 :cc:subject:date:message-id:reply-to;
 bh=IE7mEiQQJPQn8ZPnsUmyv/AeV7XrbyFeNTyQGgjYgOo=;
 b=OdSXoYr6twlduAn6sHoAT8UFYzOnbD8Y7MPFKrjg6CMN32Pmvg2abijHmIqGfmxtt/
 8dOcfggLO51MKMdZ1LU6EE94VwodCMeyjtTjNUdAA+5KBJ9pjQWb30jrcIpS0n7nzu15
 6/ve9Q1u7R4vpzWn3pCJpm9wxYA5aViCd9Y5DT2iSQEO2PTCyVeF1eefuWFxEmE3UKtb
 +A/kY8qSenRfEoE4q5qHzNy7YeF1m2AvMLm4wQtPwUB/R+4aLV3z3hbU3WnOiq49gop9
 iYUF8ni5HB84DiWmsnV9t88Dn9Fyr0N2+vCZ9tmYWsakrgAXqnPWIUMyrnBMdg1utr3K
 qh9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1747053505; x=1747658305;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=IE7mEiQQJPQn8ZPnsUmyv/AeV7XrbyFeNTyQGgjYgOo=;
 b=Jn5Wh3e9QL+ChJGSwzR981PL7dMfemw7jDleKPaL8ZFTQYs4QgDlczkKCfLiaBAuyI
 eWwQygcDCH87un/2xUJunlOOhLHqFOLRhqQQPokT1qm231rCZxea3eFubQiV15uM4wwK
 T3DNYEah72kEWLs4FZXjQHdkctcpkhBIiBLlQNiQXC4cxt3oJO3dFTdRPwojpXrYPhI4
 XCH2eI5H5yv0GqZetRh8dWNb3eiFB3FJOiEET/nyR/iBra93M2147hpkha1tHXIUAbto
 h7MZr4VMblQnzmDQ7PDADLlDyAQRKFYm+jN3DEA7CXEqSNnhJm22jCnVdR64GlTF+AaC
 fiwQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCUGcSi5j0bnq59lqdlXez9vvDUAeIYRQ0rUh3jL506AkZP7yEcNf02hOQXJ+Gw30eOBYWx+hg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzpG0sP5M/+MDULSuxPKqmiUgvmyqKthp2FWQ7bGNLKPOArE5fc
 AJ+L9aEP0aCjGSiCxPJ8rB1VOWfOLt01Sy3/P2WsYknU02iOVjZY
X-Gm-Gg: ASbGncvvUzxaGPf8Jgwj4eVLLEaJUehbL4aV9h9pTFgcohaCtTXG9FRCSrFW+0PvD7H
 xi7PiS+94AB6YjnmBmFvVV7YHwGUBc6AOpF2xq/u+QgNr/JcnQn4UtvGngVYGXPLeB5rzQARg9u
 D5Ae93CPrsNFTtRmpxDLJEfWUZewJAkuML6ItXwyQYxlpyoK1rvgfydM5h3FXw5fo3EN0MgG/E/
 yaaJT4v6ivC3AbTXfxyxyUe5XLTQnEZYL2OKwH/sQCQZkqwyY+0Xypr/CmtDApC/tRszPRhoBcm
 /seJR73fukBWcSSRpDOluUcrG7dqlRpaKysjo5QOUHb3raoHZOw=
X-Google-Smtp-Source: AGHT+IFkPawYmuC2OgL4C9I0kikdRGRGj939n8pBvzydaRBfE4wALLmhFQapot19vQLh21WUHmCCkQ==
X-Received: by 2002:a05:6402:849:b0:5fc:7c45:770 with SMTP id
 4fb4d7f45d1cf-5fca07932a8mr11509609a12.20.1747053504251; 
 Mon, 12 May 2025 05:38:24 -0700 (PDT)
Received: from localhost ([46.210.233.169]) by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5fc9cc26521sm5669152a12.18.2025.05.12.05.38.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 05:38:23 -0700 (PDT)
Date: Mon, 12 May 2025 15:38:20 +0300
From: Efraim Flashner <efraim@HIDDEN>
Message-ID: <aCHrvMvMq6AcAeMs@X1>
Mail-Followup-To: Steve George <steve@HIDDEN>,
 Ian Eure <ian@HIDDEN>, guix-devel@HIDDEN,
 78332 <at> debbugs.gnu.org
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87frhb5529.fsf@HIDDEN>
 <hy2p7yhcsl5o4p3as77ne2ffqzzslikuvdmir6t3gyqo3fw5zm@gcslqzch3i2p>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="iNZIRXbuNd/iijpn"
Content-Disposition: inline
In-Reply-To: <hy2p7yhcsl5o4p3as77ne2ffqzzslikuvdmir6t3gyqo3fw5zm@gcslqzch3i2p>
x-ms-reactions: disallow
X-PGP-Key-ID: 0x41AAE7DCCA3D8351
X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc
X-PGP-Fingerprint: A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
X-Spam-Score: 0.0 (/)
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 (-)


--iNZIRXbuNd/iijpn
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 12, 2025 at 11:09:21AM +0100, Steve George wrote:
> Hi Ian,
>=20
> On 11 May, Ian Eure wrote:
> > Hi Steve,
> >=20
> > Steve George <steve@HIDDEN> writes:
> >=20
> > > 3. Rolling updates aren't suitable for all users.
> >=20
> > If a Guix release is a point in time snapshot of a rolling release, and=
 the
> > first `guix pull' after
> > installation puts you back into the rolling release model, I don=E2=80=
=99t think
> > more frequent releases address this need.
> (...)
>=20
> Yes, so this GCD doesn't resolve any issues with the rolling release not =
being suitable for all users (problem 3). An earlier version did, but follo=
wing input from the sponsors I cut the GCD down to focus it and make it eas=
eir to implement - one change at a time! That's why it refers to the idea t=
hat in future we could implement slower moving branches, or something else =
- something along those lines would resolve that issue - but it's out of sc=
ope for this GCD.
>=20
> This GCD focuses on problem (1) and (2) only.
>=20
> Rereading it this morning, it's not clear, so I will alter the paragraph =
to make it clear. Thanks!
>=20
>=20
> > > Adding a slower-moving branch akin to Nix's stable could be an eventu=
al
> > > 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.
> >=20
> >=20
> > > A specific issue caused by irregular releases is that new users/insta=
lls
> > > 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.
> >=20
> > It also causes user confusion becasue the assumption is that the releas=
e is
> > what they should be using.  We get a good number of folks in #guix read=
ing
> > the 1.4.0 manual, which doesn=E2=80=99t accurately reflect the current =
state of
> > things.
> >=20
>=20
> Agreed.

I think we can change the links on the website so that the manual points
to the latest manual and then one with /$release-version/ in the URL
would be the one associated with that release specifically.  Over the
past 2 years that it's been brought up no combination of people have
been brave enough to create a patch for the maintenance repo and to
apply the patch.

>=20
> > > This GCD proposes an annual release cycle, with releases **in May**.
> > >=20
> > > 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.
> >=20
> > I think it=E2=80=99d be better to align the initial release with the sc=
hedule we
> > want to keep, so if we plan for a November release, plan to release eve=
ry
> > November.
> >=20
>=20
> An annual spring release would be better due to alignment in the ecosyste=
m around stabilisation: it's beneficial to get the additional stabilisiatio=
n that the commercial distro's do and RHEL/LTS's always do a spring release=
 [0]. I outlined this a bit more elsewhere in the thread, but can go into m=
ore detail.
>=20
> I personally would like us to do a release before $SPRING 2026. Doing rel=
eases more often, should help us get better at them, automate them (see com=
ments from Ekaitz/Reza), so hopefully doing a November and then a $SPRING w=
ould be achievable.
>=20
> I would give shifting to a $SPRING time-frame, priority over doing the No=
vember one if it was an absolute choice, as I think that time of year is op=
timal.=20

We debated quickly what month might work well and we ended up any
release is better than no release, so we figured we'd leave it.
Before/after February runs into FOSDEM and we don't want to race FOSDEM
for a release or be in freeze while people have Big Ideas=E2=84=A2.  Likewi=
se
August is difficult for many Europeans when they have off from work, so
we didn't want to overlap with that month either.

>=20
> > > ## Release artifacts
> > >=20
> > > Using the primary architecture tier and the package sets would involve
> > > creating
> > > the following release artifacts:
> > >=20
> > > - GNU Guix System ISO image
> > > - GNU Guix System QCOW2 image
> > > - GNU Guix installer
> >=20
> > I=E2=80=99m not sure what the difference is between the installer and s=
ystem ISO
> > image is, could you elaborate please?

The ISO and the QCOW2 image are almost identical, but the ISO is more of
a live image for actual hardware and the QCOW2 image is for VMs.  The
installer is the installer.

Combining a couple of different ideas, I think we should add aarch64
images that uses grub-efi and starts with an offset of 16MB (as
suggested by vagrant), and hopefully that'll work for at least some
machines.  We can always tweak it later.

>=20
> AIUI we have two install paths (product?), one is installing 'Guix System=
' as a Linux distribution, the other is installing 'Guix' (package manager)=
 on a foreign distribution. For a release we update both. So 'GNU Guix inst=
aller' was refering to the Guix as a package manager, and the other two wer=
e 'Guix System'.
> > > 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.
> >=20
> > The 1.4.0 release artifacts are[1]:
> >=20
> > - Installer image for i686 and x86_64.
> > - QCow image for x86_64.
> > - Binary for i686, x86_64, armhf, aarch64, and powerpc64e.
> > - Source tarball.
> >=20
> > Are the binaries and source tarballs "additional release artifacts?"
> >=20
>=20
> Yes, good catch. I'll add 'GNU Guix Source tarball', I believe that the e=
xisting 'GNU GUIX installer' covers the binary point.
>=20
> This section is covering the minimum created artifacts, which would be th=
e focus of developer work and testing. Nothing stops additional artifacts b=
eing created - for example the latest downloads page (https://guix.gnu.org/=
en/download/latest/) has a Pinebook Pro image.

I'd also like to point out that I think at this point only Chris Baines
has direct access to all the machines we support, so IMO it goes without
saying that the release team would likely need to delegate creation of
the release artifacts for some architectures to someone with the
machine.  Of course if we have 2 someones then we can compare the built
artifacts.

> (...)
> > > ### 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.
> > >=20
> > > Debian defines a transition as one where a change in one package caus=
es
> > > 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. Nonetheles=
s,
> > > any
> > > change that alters a significant number of packages should be careful=
ly
> > > considered and updates that cause other packages to break should be
> > > rejected.
> > >=20
> > > 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.
> >=20
> > I think it=E2=80=99s worth considering doing this the other way around:=
 instead of
> > freezing master, cut a release branch and cherry-pick fixes into it as
> > needed.  I don=E2=80=99t expect that development on non-release feature=
s will stop
> > during the freeze, which means we=E2=80=99ll have a large backlog of wo=
rk to merge
> > once the freeze ends; this is a thing Guix has historically not been go=
od at
> > working through in a timely manner.
> >=20
> > A release branch would also support longer-term stable releases, if we
> > wanted to do that.
> >=20
> > The downside is that it=E2=80=99s more work to cherry-pick fixes betwee=
n branches,
> > and there=E2=80=99s the potential for merge conflicts.
> (...)
>=20
> In the context of doing a release I think we _could_ cut the release bran=
ch earlier in the project. Rutherther also brought this up. It's definitely=
 a trade-off. I selected to stay on the master branch for as long as possib=
le because (a) the group has had difficulty with long-running branches, (b)=
 the social signal of doing a release, for a few weeks we all focus on it. =
I agree we may block up with items to go to master, though given our curren=
t velocity a 5 week freeze doesn't seem that big to me.
>=20
> I think that Efraim has an idea that would also try to reduce the freeze =
time - which I think is along the lines of what you're outlining Ian - Efra=
im do you want to chime in here?
>=20
> I agree a release branch would also support some form of longer-term stab=
le branch. I don't think doing it that way is a necessary precursor for thi=
s GCD, but I do take the point! For now I would keep the idea of maintainin=
g two branches outside the scope of this GCD.

We historically haven't done well with freezes (see for example the
v0.9.0 tag in the git repo), and Free Software projects often loose a
lot of steam if a freeze is too long.  My idea was to freeze master for
about 2 weeks where everyone really just fixes packages that don't build
or are otherwise broken.  Then we'd branch off the release branch and
focus on release related work there and sync back regularly with master
as needed/possible.  The release would be cut from the release branch,
master would be merged into the release branch, and then the release
branch would be pushed to the master branch.  Then the two branches
converge and any new commits are downstream from either the regularly
rolling process or the release commit.

>=20
> > > ### 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
> > This could prove troublesome, as the current Guix approach is to update
> > packages to the version containing the fix.  Are you thinking that we=
=E2=80=99d
> > maintain that, or adopt a Debian style of backporting fixes where possi=
ble?
> (...)
>=20
> We'd maintain our current approach as we are ultimately a rolling release.
>=20
> My point here was to hold us for a couple of weeks only pushing 'security=
' issues to the branch, so that the whole of the team can focus on testing =
the release and fixing release-critical bugs on the 'release' branch. For d=
evs that don't want to focus on the release they can continue to push to th=
eir team-branches and/or the "staging" (z572 thinks this sould be called so=
mething else).

The aim is to to say "this package is at x.y. We can fix something by
going to x.y+1 or we can go all the way to x.y+25". Normally we'd go for
the big jump and fix things that break, here we'd aim for as small as
possible to try to keep everything working and not need to fix (as many)
broken packages.

> > > ### 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.
> >=20
> > This is going to be difficult to manage, especially for contributions f=
rom
> > those new to Guix development.
>=20
> We already have this problem in the sense that new contributors send cont=
ributions against master, and a lot of work is actually against team-branch=
es. For example, people send package updates for rust/python and we already=
 have them in rust-team/python-team branches. I agree it's difficult to man=
age as it will be a "new thing".
>=20
> > Thank you for starting the discussion!
> (...)
>=20
> It sounds like you're broadly in favour, but the main improvement would b=
e flipping the branches around.
>=20
> Thanks for the input!
>=20
> Steve / Futurile
>=20
>=20
> [0] Ubuntu/Canonical LTS's are always the April release. RedHat is a bit =
less clear to me, but RHEL 9 was in May, and they've announced that RHEL 10=
 is mid-2025 so I _think_ they are also on a spring release cycle=20
>  - https://www.redhat.com/en/blog/red-hat-enterprise-linux-10-beta-now-av=
ailable - mentions "to release a new major edition every three years .... R=
HEL 10, due to reach general availability in mid-2025"
>  - https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux - RH9 May 2022,=
 RH8 May 2019
>=20
>=20

--=20
Efraim Flashner   <efraim@HIDDEN>   =D7=90=D7=A4=D7=A8=D7=99=D7=9D =
=D7=A4=D7=9C=D7=A9=D7=A0=D7=A8
GPG key =3D A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

--iNZIRXbuNd/iijpn
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmgh67kACgkQQarn3Mo9
g1HQTQ/8CdXHYNCHHM6cr6bZYEQSLbs3+w/dOO+FKykZKSyukUmxPhsSCfXy/hOm
sA0asKJxE8tMIFkD5azEl/hcx/iiXElalcnPQtg8fQBXMOsqDXj+tDCleLfK1sTb
qRE1ZCSbQSKap+liK4eSOXti5AoCzFEPF33uSlwodHhM+a7QEfb7QBdBGzfOJWAI
cfnXw6kallh+/SIzqYtC36B/v1SS85VvSu9+q8enY3OcFinR3Xc86XwMpXw0U5Le
IdHgxX0cA9u5/1MRFc7ULG1CMQiuhvESNXFDmyJNxGLEV6+Wv/ko+qAtk22UjJY3
4vhSQGrHptE+i1VkzM0MyyJ2ENzowV/AZP/tXY2jYLra+fCYWuawutpLirwOmPIi
XbF48+LZRAHCQe9GVyfup/YcoSivvIFY/ClmABlbIsspjMARMpmpVXTRYTUSwJF2
mlV00U0nyFCUBiZWrkt7RdROX7f2woZp2clpwKjd9MRkUSVHJEQxeCbjaUfiFC0c
64sl8ZGpPxeMIu6ehz6XPcrr71ZiQxacfkE2UrLHd9gIFdqj/LpbuUN3E7jDzhPy
OesIWOhxWLKgpS2C2LgkOq91Qefaam5hH9xQ4cY1lEItmOH+lvc778aO+C+S7qwm
y1qPYqJwJWqcuX/6rbyOKisBLSXP34CaJsKUFmwLX3EFkXJlyWM=
=/c2f
-----END PGP SIGNATURE-----

--iNZIRXbuNd/iijpn--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Greg Hogan <code@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 15:36:02 +0000
Resent-Message-ID: <handler.78332.B78332.17470641057017 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17470641057017
          (code B ref 78332); Mon, 12 May 2025 15:36:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 15:35:05 +0000
Received: from localhost ([127.0.0.1]:54130 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEVBJ-0001p7-0p
	for submit <at> debbugs.gnu.org; Mon, 12 May 2025 11:35:05 -0400
Received: from mail-ot1-x330.google.com ([2607:f8b0:4864:20::330]:60800)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <code@HIDDEN>)
 id 1uEVBG-0001oM-ND
 for 78332 <at> debbugs.gnu.org; Mon, 12 May 2025 11:35:03 -0400
Received: by mail-ot1-x330.google.com with SMTP id
 46e09a7af769-731e277a6b0so4338800a34.1
 for <78332 <at> debbugs.gnu.org>; Mon, 12 May 2025 08:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=greghogan-com.20230601.gappssmtp.com; s=20230601; t=1747064097; x=1747668897;
 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=WPF+74z6se6HhxyDokRUykSEQgIDl/D1V/G4o0hviws=;
 b=x4UDZCJS7MNqYRgmp/AO8pd9ipSkf9IO9YvawlzsRv6fS/Z65p+HZeBxfhhi2Zxhyn
 eFMA6r6F1vdP/e0phty0+tDa9rXHRKUR1W+npnm4jdZJf9rSPWOp2rcNQ5Kd0yLDsY/Y
 xeROXClRa7fOFttJE7F1PmSSZ0nwEGQf0qbBcy3Gyob58B1xJ/ALw2pFdFKFkIjblqN7
 fbJgZO/fC5Tz5LDoL/VC83t86ktE2QgqXguW/TnloOmFSCcLXqOydIapxDzIcEPYGSkg
 tB+HxDKrm+jL1kgEQTKVawEP8/0jhsBo4cczYuLjiKpcRRLNb8GmZGWS4Xacq6fZZ6Bu
 H9Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1747064097; x=1747668897;
 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=WPF+74z6se6HhxyDokRUykSEQgIDl/D1V/G4o0hviws=;
 b=mvXs48BT3EvGbVh107X2JcRxJcRHp2oqDV/PHbdYpd02w3SXUyWNuzCmG7/M450ed/
 dVIzJqeliGbcLWg0rOinX95swUbUtmawYF/kgM2RfZ1qsTl2kwY/E6dHk0NawJD5ZC7m
 UghQELR70L0+4za9pZm+5eK/hrGybVPqq+p15Khmv1TbKvNOmRLN6BkN6OhAeF4dZ7dd
 AcYTBpqxNPPgnMOh5Kzpl88oAn7lWJz/SMf9y4ifDYD4de9Zlmegeu4XpMf1Iii/wKma
 HrKvmfXbXs45f5phzsjKd+ox42iR4gDUa17nL+Y0JS5DKRGD6r7Zd5aDvoJ1aXxW1TDa
 w3Jw==
X-Forwarded-Encrypted: i=1;
 AJvYcCXBC8oCow5PQzIPd0Ujk43zn7JX/JveG8ou6yeaeoe+WCvXAR0YuTePixEmCnw9euZgRc+6Cw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yw031rebyYC5tYmUR+v6+laEucC07pGT29l8Tn7aONabE3GDEwB
 30/HWTdnXn7DaSe/P3p7kwi993Ye48mMjScjX9u3yECg2zJYvIRiFXHV35N38f5lbG5xG0jJ5NL
 l0tWzCpyYI418ak933pov36SSG1DA24cG3Qyq8g==
X-Gm-Gg: ASbGncsTxEoqkzqTfrg+g8gIaxEkZdy9AMjZ8AuB5KFoYac/AqsmbMyqyh93EdbTXDl
 N/Kb1PVIIXLyc5gB0udAJi2UH6lK+eWJRrXCgxySx0npJd1M8Z2v6qRSbvaytcNTdtPrQTyQCAZ
 lrrncVI2Q2fib3eZN5YwunmWVOM3d6/Ouy
X-Google-Smtp-Source: AGHT+IFyPI95VZ1SWX64/u12QAFWWWMpMzm7BCI2duKg8HJsfkrwP1Oy5zVBzTZwg1n/zjZye/x5aLXT3aaGRq2Xbt8=
X-Received: by 2002:a05:6830:2696:b0:727:2f79:ce33 with SMTP id
 46e09a7af769-73226b372e8mr8486637a34.28.1747064096550; Mon, 12 May 2025
 08:34:56 -0700 (PDT)
MIME-Version: 1.0
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN>
 <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj>
In-Reply-To: <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj>
From: Greg Hogan <code@HIDDEN>
Date: Mon, 12 May 2025 11:34:44 -0400
X-Gm-Features: AX0GCFtgHzjHeKpx0YxQuX-bx6qmpLXT-munE9TwscqVVJN6EFhacge05u0uWaw
Message-ID: <CA+3U0Z=dzaT+_hJCA6oyi6DnLCXoW3KrsZmxcjZAcrJEHN3a2A@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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 5:55=E2=80=AFPM Steve George <steve@HIDDEN> wr=
ote:
>
> I hope the initial user experience wouldn't be to "break on the user's fi=
rst pull", since with annual releases we wouldn't have release artefacts th=
at 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 bran=
ch, but purposefully have kept the GCD more limited. For now focusing on th=
e step forward of regular releases.

I have not updated a 2.5+ year old Guix system, but what is the issue
here? How is this any different from updating a week old system? If
the archive contains broken packages then the user upgrade experience
will fail just the same. And clearing the archive of broken packages
also breaks user manifests!

> > 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 thi=
s GCD let's keep it out of the remit. Perhaps a separate discussion or sepa=
rate GCD!

Performance of the teams workflow is integral to this proposal. We can
barely get a handful of teams processed in a month, and now we propose
allowing all teams a go within a four week window. And it seems to me
the biggest issue with the teams workflow is the indeterminate nature
of moving to the head of the queue. This proposal synchronizes many
activities to an annual process for which the volunteer developers may
likewise not be available.

    ### 2. Notify teams of upcoming release
    Make sure all teams are aware of the upcoming release.  This gives
them 4 weeks
    to undertake any large transitions or major changes.

> > 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 i=
t's overstating it in some way. In my mind I think the release is a checkpo=
int where we can use the package sets and the project plan focus to do what=
 we should be doing using our existing process.

The removal of any broken package:

    Packages or services that do not build for the Primary
architectures as part of a release
    would be removed from the archive using Guix's deprecation policy.

> > 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 tim=
e 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 e=
nvironments [1]. I don't think this can be done by 3-4 volunteers, there ha=
s to be some co-ordination and energy from all teams - we are a small team =
after all!

Yes, those teams are involved if packages or the release scripts are
broken? I'm with Ekaitz on this one, the process to build the release
artifacts should be automated. We already do this for the binary,
which is why I have not had to install a 2.5+ year old system :)

I see Andreas' response that we need a big release hullabaloo to rally
around since tidying up and testing the release is "probably not much
fun". But this process simply codifies the pre-teams workflow that did
not work. And while I certainly welcome this discussion, I don't see
this as a whole qualifying as a GCD (from 001: "A change may be deemed
*significant* when it could only be reverted at a high cost or, for
technical changes, when it has the potential to disrupt user scripts
and programs or user workflows").

This proposal simply takes the processes which are performing poorly
and stuffs them into a very manual annual release process. Ungrafting
can and should be coordinated on feature branches. We need better
methods to identify, track, and notify users of their broken packages.
The teams workflow needs to be clarified (QA vs CI) and coordinated
(thanks, Andreas!) and possibly preemptive.

We tested codeberg before the GCD to switch over. We should likewise
test this release schedule before codifying in a GCD.

Greg

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Rutherther <rutherther@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 16:25:01 +0000
Resent-Message-ID: <handler.78332.B78332.174706704216463 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Greg Hogan <code@HIDDEN>, Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174706704216463
          (code B ref 78332); Mon, 12 May 2025 16:25:01 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 16:24:02 +0000
Received: from localhost ([127.0.0.1]:54298 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEVwf-0004HA-5q
	for submit <at> debbugs.gnu.org; Mon, 12 May 2025 12:24:01 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::]:46792 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 1uEVwb-0004Go-5b
 for 78332 <at> debbugs.gnu.org; Mon, 12 May 2025 12:23:58 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 4995984a
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); 
 Mon, 12 May 2025 16:23:49 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
In-Reply-To: <CA+3U0Z=dzaT+_hJCA6oyi6DnLCXoW3KrsZmxcjZAcrJEHN3a2A@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN>
 <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj>
 <CA+3U0Z=dzaT+_hJCA6oyi6DnLCXoW3KrsZmxcjZAcrJEHN3a2A@HIDDEN>
Date: Mon, 12 May 2025 18:23:47 +0200
Message-ID: <87tt5pajcc.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=1747067029; h=from : to : cc
 : subject : in-reply-to : references : date : message-id :
 mime-version : content-type : content-transfer-encoding : from;
 bh=KdJZdcstZLLuCxooxD48+YKVn2w2Gxn19XogSmFBz5Y=;
 b=qFxleFZLY/Rn6Q8KBk3C6G7jeRXaLrjpe5JCEulhJbK85zpZ7zEyKb0C/71Qx/el6Na/k
 aGpkUa3YdY1tMhldheZrwlNtkD85XjVzjhrPUgFC9Ngek6KR0/duqbYfQcSfcwQYV0IFUXz
 YCt3ucQHbPFYrsx7RC1Z3+UiuLblJbQ=
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 Greg, Greg Hogan <code@HIDDEN> writes: > On Fri,
    May 9, 2025 at =?UTF-8?Q?5:55=E2=80=AFPM?= Steve George <steve@HIDDEN> wrote: >> >> I
    hope the initial user experience wouldn't be to "break on the user's first
    pull", since with annual releases we woul [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
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 Greg, Greg Hogan <code@HIDDEN> writes: > On Fri,
    May 9, 2025 at =?UTF-8?Q?5:55=E2=80=AFPM?= Steve George <steve@HIDDEN> wrote: >> >> I
    hope the initial user experience wouldn't be to "break on the user's first
    pull", since with annual releases we woul [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  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 Greg,

Greg Hogan <code@HIDDEN> writes:

> On Fri, May 9, 2025 at 5:55=E2=80=AFPM Steve George <steve@HIDDEN> =
wrote:
>>
>> I hope the initial user experience wouldn't be to "break on the user's f=
irst pull", since with annual releases we wouldn't have release artefacts t=
hat 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 bra=
nch, but purposefully have kept the GCD more limited. For now focusing on t=
he step forward of regular releases.
>
> I have not updated a 2.5+ year old Guix system, but what is the issue
> here? How is this any different from updating a week old system? If
> the archive contains broken packages then the user upgrade experience
> will fail just the same. And clearing the archive of broken packages
> also breaks user manifests!

There isn't an issue as long as you use substitutes. But if you decided
you won't, then there is an issue currently. Specifically there is a
misbehaving mirror crysys.hu that returns 200, but returns page not
found html page. That means packages like gnutls aren't building. For
people that are installing Guix from their system's package manager,
they will get hit by this unless they actively activate the substitutes.

This points to a more general problem that can be happening in the
future, it can be misbehaving mirrors or pages that aren't handled well
by Guix and lead to non-buildable software. As long as pages behave as
they should, everything should be fine, ie. SWH gets triggered on
missing repositories, subsequent mirror urls are used, etc. But
misbehaving pages are always going to cause issues.

Apart from that there has been a mistake made in generation of the 1.4.0
iso, the iso has used a local channel url, /home/ludo/..., so now if you
install from the iso, your system will have this path in the
channels.scm provenance file. Then if you do not pull at all, but
reconfigure right away, you will get an error that /home/ludo/... is not
found. That is because of the forward update check that is going to try
to check if your current commit is descendant of the previous one.
(I think that the check should have a way to abort early if no
commits have changed btw)
Mistakes like that will probably be happening with new releases
as well. Though this one should be impossible already - the url is going
to be replaced in the operating-system from install.scm.

The more releases the faster issues like this can get resolved, and not
confuse the users.

Regards
Rutherther

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Greg Hogan <code@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 17:12:02 +0000
Resent-Message-ID: <handler.78332.B78332.174706989925728 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Rutherther <rutherther@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174706989925728
          (code B ref 78332); Mon, 12 May 2025 17:12:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 17:11:39 +0000
Received: from localhost ([127.0.0.1]:54473 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEWgk-0006gt-CU
	for submit <at> debbugs.gnu.org; Mon, 12 May 2025 13:11:38 -0400
Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]:58635)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <code@HIDDEN>)
 id 1uEWgf-0006gS-8H
 for 78332 <at> debbugs.gnu.org; Mon, 12 May 2025 13:11:35 -0400
Received: by mail-ot1-x332.google.com with SMTP id
 46e09a7af769-72c16e658f4so2377408a34.1
 for <78332 <at> debbugs.gnu.org>; Mon, 12 May 2025 10:11:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=greghogan-com.20230601.gappssmtp.com; s=20230601; t=1747069887; x=1747674687;
 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=vwbE7LuebATZQtaH60vBcy6MC6Ym2may5kwf56EMwJE=;
 b=M0XCELeixnByCWnTM6MpvlcOOfIaZvbpiSQYpuyt9PGK3kUV0E+pm707ZqYGiqwSoo
 a5WbuRrNQNW8eFi9Vjsaq/mPlg44WH8qNY7aOveDZWIl2RBdiCVPpqIkxMNEJFs4f4lQ
 JRW91QrIyVa9IWTd8juORWurxvxdkP/SNvpTUxEJR8kBeltu3GTOKPyXlOS1IaZh1iNQ
 zO/U1O48gtw3lUZSsmaA8OqBSN6tFduwcLMu/S9v4WlQMm5NDtGzjrFXNjDPNkreTLqT
 bKnh6gwrPcZilX6GmKiB8sgJMbi4BkfAic2LUImJVX34tHUicw0b6BV/N372eSkY5Xl0
 YEjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1747069887; x=1747674687;
 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=vwbE7LuebATZQtaH60vBcy6MC6Ym2may5kwf56EMwJE=;
 b=OKtMar9uR9OE08s7X0/sS/EDWZc7MuwdTh8TN+/NsVPew1c3jK5Du/B7ztaW98VbnI
 WgFDR67pgsEPI+lAQnG0ksBG5FWU2NFPd1+SIMGb3q3u/mKAGcmp8g295150DcngztXC
 jlsJEE8SCoP6vE0zeaGbS77LECXuQoOaYouhBhfL1bCtHkNekHkwEpBYarXzapmRAC9r
 6rzqtxZRIPrwfTjVj/Dxqr3MGGc1Ft1uCt8uGrqVPiUuczovRdVoxd7JDRbaP1SqwLfk
 kmVrjRR8UVU0b8x/Z3WtMbCx9sX+DDWD/6gtrvZ+DtWzjmmL0BZEFLGwkp2lKU1b3dpR
 VpeA==
X-Forwarded-Encrypted: i=1;
 AJvYcCU3+ufSZKDNY3Pr3trWS8oYPG7gR9BIika+V5lEfIT/weWOCVQNNGXFv8GHXfpH0c5qVVj1Mg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yy5DOTlBNy63BDUzEh1s8Jli62ztO1U4JazEppcoYjx1mEgLrTz
 unZ3gbVuDqMZ1FAMAiulSwdir+YEWrlNECeCGEUK0j8wb/iRgzwsC6mma4q+NuuryzzT5owHLXY
 iBUgHYG8KAFxVNGiFHOUtU+NBZq18/8/2jdjiEQ==
X-Gm-Gg: ASbGncvjsHgbG0XS14M7ouhdItDODeQQ5AIUbIMwoSWeO1TAR4JXVtuZNXAm5dz3Cbc
 +uE3Oz6qOvRE5q+UviCtbhSpFyI4DAZx2qXIrfCEIlKVBF5nxPWx45fJgrnrfdSlG4yp/ZMLB8b
 5n7yXlEdNA5PRrKdpghEqXuHpSgvvCM8b5DFPIUoKDSCg=
X-Google-Smtp-Source: AGHT+IG7V3+crBCTWKr5+b9Uxy0yxW1op1Zf+1Ei4wKBntppSW3LFDwLRrxhr0ayVu4YdOVnoG1LKHfdMT1QRQGqHzU=
X-Received: by 2002:a05:6830:9ca:b0:72b:9d8d:5881 with SMTP id
 46e09a7af769-73226b319afmr9186173a34.28.1747069887198; Mon, 12 May 2025
 10:11:27 -0700 (PDT)
MIME-Version: 1.0
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN>
 <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj>
 <CA+3U0Z=dzaT+_hJCA6oyi6DnLCXoW3KrsZmxcjZAcrJEHN3a2A@HIDDEN>
 <87tt5pajcc.fsf@HIDDEN>
In-Reply-To: <87tt5pajcc.fsf@HIDDEN>
From: Greg Hogan <code@HIDDEN>
Date: Mon, 12 May 2025 13:11:15 -0400
X-Gm-Features: AX0GCFtew_njiJ2CLgQosQhZ2FYywbRx6J2BDKP_6ZIk2LunwDc-5muj8bWJDZc
Message-ID: <CA+3U0Zk8WCvJ+YPKoSwvYeGQTxuqaM5zWNSdZVsBWboS86VWVw@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 2.0 (++)
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:  On Mon, May 12, 2025 at =?UTF-8?Q?12:23=E2=80=AFPM?= Rutherther <rutherther@HIDDEN>
    wrote: > > Hi Greg, > > Greg Hogan <code@HIDDEN> writes: > > > On
   Fri, May 9, 2025 at =?UTF-8?Q?5:55=E2=80=AFPM?= Steve George <steve@futuri [...] 
 
 Content analysis details:   (2.0 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 SPF_NONE               SPF: sender does not publish an SPF Record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [2607:f8b0:4864:20:0:0:0:332 listed in]
                             [list.dnswl.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 Mon, May 12, 2025 at 12:23=E2=80=AFPM Rutherther <rutherther@HIDDEN=
> wrote:
>
> Hi Greg,
>
> Greg Hogan <code@HIDDEN> writes:
>
> > On Fri, May 9, 2025 at 5:55=E2=80=AFPM Steve George <steve@HIDDEN=
> wrote:
> >>
> >> I hope the initial user experience wouldn't be to "break on the user's=
 first pull", since with annual releases we wouldn't have release artefacts=
 that are 2.5 years out of date. And, we'd also degraft regularly which wou=
ld be beneficial for all users.
> >>
> >> As you can tell I would _love_ us to be able to have a slower moving b=
ranch, but purposefully have kept the GCD more limited. For now focusing on=
 the step forward of regular releases.
> >
> > I have not updated a 2.5+ year old Guix system, but what is the issue
> > here? How is this any different from updating a week old system? If
> > the archive contains broken packages then the user upgrade experience
> > will fail just the same. And clearing the archive of broken packages
> > also breaks user manifests!
>
> There isn't an issue as long as you use substitutes. But if you decided
> you won't, then there is an issue currently. Specifically there is a
> misbehaving mirror crysys.hu that returns 200, but returns page not
> found html page. That means packages like gnutls aren't building. For
> people that are installing Guix from their system's package manager,
> they will get hit by this unless they actively activate the substitutes.
>
> This points to a more general problem that can be happening in the
> future, it can be misbehaving mirrors or pages that aren't handled well
> by Guix and lead to non-buildable software. As long as pages behave as
> they should, everything should be fine, ie. SWH gets triggered on
> missing repositories, subsequent mirror urls are used, etc. But
> misbehaving pages are always going to cause issues.

So for the (small?) subset of users (myself included) who do not
enable substitutes, then for the small set of packages provided
pre-built with the installation ...

>> guix depends on gnutls
guix@HIDDEN
guile-gnutls@HIDDEN
gnutls@HIDDEN

Can we not retry mirrors on checksum mismatch? And differentiate
between binary substitutes and sources? The latter are strongly hashed
and therefore no different from patches or the package code itself.
Does use of SWH require substitutes to be enabled?

> Apart from that there has been a mistake made in generation of the 1.4.0
> iso, the iso has used a local channel url, /home/ludo/..., so now if you
> install from the iso, your system will have this path in the
> channels.scm provenance file. Then if you do not pull at all, but
> reconfigure right away, you will get an error that /home/ludo/... is not
> found. That is because of the forward update check that is going to try
> to check if your current commit is descendant of the previous one.
> (I think that the check should have a way to abort early if no
> commits have changed btw)
> Mistakes like that will probably be happening with new releases
> as well. Though this one should be impossible already - the url is going
> to be replaced in the operating-system from install.scm.
>
> The more releases the faster issues like this can get resolved, and not
> confuse the users.

I think we should release more often (multiple times per year) and
also add checks like building  release artifacts and bootstrapping
systems with clocks set into the future to detect another major
annoyance: timebombs. Anything which can be automated.

> Regards
> Rutherther

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Efraim Flashner <efraim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 17:29:01 +0000
Resent-Message-ID: <handler.78332.B78332.174707090228761 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Greg Hogan <code@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Rutherther <rutherther@HIDDEN>, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174707090228761
          (code B ref 78332); Mon, 12 May 2025 17:29:01 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 17:28:22 +0000
Received: from localhost ([127.0.0.1]:54526 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEWwv-0007To-HI
	for submit <at> debbugs.gnu.org; Mon, 12 May 2025 13:28:22 -0400
Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]:43461)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <efraim.flashner@HIDDEN>)
 id 1uEWwq-0007TR-RX
 for 78332 <at> debbugs.gnu.org; Mon, 12 May 2025 13:28:18 -0400
Received: by mail-ej1-x62f.google.com with SMTP id
 a640c23a62f3a-ad21a5466f6so650532166b.1
 for <78332 <at> debbugs.gnu.org>; Mon, 12 May 2025 10:28:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1747070891; x=1747675691; darn=debbugs.gnu.org;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender:from:to
 :cc:subject:date:message-id:reply-to;
 bh=Rq9Dcz25pM4JUvjGCeQAdUkzToYdWr9dGetikSEBnA0=;
 b=OiS7fdBcbPy3XDy8CjUQUY5OF6YMLmzTkwsEPOU5YGewWxuFMB9cuh+k41HVnAo+I1
 LN1IWDTpb6+bqR9eg2KsVPCRDcXZwZiUKUNzLhdKm0GwS6Zi9NcTKmT7GvM1UwAl8DRC
 TzvXnLJpY/mQcV8SKXoQS4/zoUx6du3JOadQGwzigY+EtUxSgbCea2kxyVXeIp4U/YKL
 sBfU4Jldd+9TQGtmendA/BvfhHeZgrEe7hrI+MD+8pPljwkRlYnOklKQ0hZeiXEtU8J8
 1EmslVOZQFbAb5oBhPYOSX5aAAylfQLGs4vwUl0SYCpJS+2vsQrkouyhmXylubDbeuj2
 zczg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1747070891; x=1747675691;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=Rq9Dcz25pM4JUvjGCeQAdUkzToYdWr9dGetikSEBnA0=;
 b=hWlrQ5kvVv9rTrD9Fdw+ui1Byoqq0JF8PnFQP7QNC87V3M6jN438Z28sv/dB9CBFyS
 cqgwVSnnJuLSGOT/6ONhEGLZZik3kjclL7lm5JJsyTGdvel6oQ8R5d9R8SPNafyKB/9w
 szOPnabM6xd0ferZ1lXuK8hC4fLnTLMXFSARdoRtkMgkem7Hmp7VXcNwuptSHkCsgyuf
 0dU4TH+je75Zde3zWQCly8oInRovqO7U4SaT9sdM12iThC6cAePP1A5SReunvwuVG1jB
 NCM+bTn+u7R1zO+SIQk0AUe86Szzq0rdRo9r04L4mwqdFDFJtETdYhDHbaYw+Mk6ibi4
 ZMJA==
X-Forwarded-Encrypted: i=1;
 AJvYcCXU6Z9hk2GXJasgRfb0GYZqzgo8B6ZubSb7RNvqY45/z2XnS0iS1y9C61S63fwLdzzRm8JdXA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxApD4+xgrc35Glv//gOdQzupmQ4aQe9Y2noxp5cA9xAMFmW1P6
 0JAh5wKS33JXUbMXErw68LNdTm2Y0Xp0CCvDq8hwlJd1S0ntsgTL
X-Gm-Gg: ASbGncsAzJgDRrks0xmjNko7Jb/8LBu9G361HiIi0GndvObNdsqKrbjFX0AaDaA6l/A
 bsvzgG66ps21to1VccMs8FWjsQg6QGzgA2GMX2kUz4RRGN4itnH2C2JQ+W3X1EwsUGtJjC2g9Ln
 4k/lgha/W7Xvl1rUWfvsAv7Ufq374VR6BOFyC3131+lZX0+fTYfDpxMQxrDvG29Z/1CFkXupcoX
 xEsT/925dhqJa8VN1HGZ6U/fs1vvcI+LIY90L5aD+4a55BOTUQIjHMjorOIbfhb/c7E/jP47JHo
 S4SM70tjPajognxZ9bl+I86RO6GYftsbsBOaS17csybEKOYFhn4=
X-Google-Smtp-Source: AGHT+IHZwMnxWmfVdcYh4+hgeXJkmQ0X3F2K8gCvkL8UPQSIS23eVHLDeVowokUUSoRWl0vcuJ1TdQ==
X-Received: by 2002:a17:907:9692:b0:ac7:b231:9554 with SMTP id
 a640c23a62f3a-ad4d4dfcf0emr31881766b.11.1747070890301; 
 Mon, 12 May 2025 10:28:10 -0700 (PDT)
Received: from localhost ([141.226.15.142]) by smtp.gmail.com with ESMTPSA id
 a640c23a62f3a-ad238b66188sm460994066b.173.2025.05.12.10.28.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 12 May 2025 10:28:09 -0700 (PDT)
Date: Mon, 12 May 2025 20:28:08 +0300
From: Efraim Flashner <efraim@HIDDEN>
Message-ID: <aCIvqABgKwj8SJnN@3900XT>
Mail-Followup-To: Greg Hogan <code@HIDDEN>,
 Rutherther <rutherther@HIDDEN>,
 Steve George <steve@HIDDEN>, guix-devel@HIDDEN,
 78332 <at> debbugs.gnu.org
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN>
 <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj>
 <CA+3U0Z=dzaT+_hJCA6oyi6DnLCXoW3KrsZmxcjZAcrJEHN3a2A@HIDDEN>
 <87tt5pajcc.fsf@HIDDEN>
 <CA+3U0Zk8WCvJ+YPKoSwvYeGQTxuqaM5zWNSdZVsBWboS86VWVw@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="bhvDS/AOsraOZy9M"
Content-Disposition: inline
In-Reply-To: <CA+3U0Zk8WCvJ+YPKoSwvYeGQTxuqaM5zWNSdZVsBWboS86VWVw@HIDDEN>
X-PGP-Key-ID: 0x41AAE7DCCA3D8351
X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc
X-PGP-Fingerprint: A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
X-Spam-Score: 2.0 (++)
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:  On Mon, May 12, 2025 at 01:11:15PM -0400, Greg Hogan wrote:
    > On Mon, May 12, 2025 at =?UTF-8?Q?12:23=E2=80=AFPM?= Rutherther <rutherther@HIDDEN>
   wrote: > > > > Hi Greg, > > > > Greg Hogan <code@HIDDEN> wri [...] 
 
 Content analysis details:   (2.0 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (efraim.flashner[at]gmail.com)
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [2a00:1450:4864:20:0:0:0:62f listed in]
                             [list.dnswl.org]
  0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
                             EnvelopeFrom freemail headers are
                             different
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 (+)


--bhvDS/AOsraOZy9M
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

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

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

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

> > Regards
> > Rutherther
>=20

--=20
Efraim Flashner   <efraim@HIDDEN>   =D7=90=D7=A4=D7=A8=D7=99=D7=9D =
=D7=A4=D7=9C=D7=A9=D7=A0=D7=A8
GPG key =3D A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

--bhvDS/AOsraOZy9M
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmgiL6gACgkQQarn3Mo9
g1GyTBAAnStgLpDT6DiwbVLXVKJjpDHxx7NP1QbUWZ1OmTQYNoIPRXb47/oZ70aB
N+0XzB95kyxBXL1wf+kmsEb2kOMLwr+by8pOEaR7F8/dtzUh5gJ4YqTnVSTaFLHr
Ua8KtbP0oYGrJjrXqtKD+IZ5wx+Pl5W/nmgzTvie+hm7fz34bEx37yU41qkJyViA
uCJHZnxmNXA4ntk712ndw16ndeIynqNUSU41gP3HwEzAJu4qM6od9NvKNYGGqQwg
FsaqL1028V92Z8qMLcKSs7FMss5wRYYZKCh5nsW11MFEr1N18aK097QBkRc22Axz
TmJnPlIeAi3XtHKOzKqm1/aF7Xwx4pJ4H29tOve0PMe5yeTZ0Eoznartzdvwqu73
ZBfFmHDVtJa5H464JGBFVLKhoGjmIcYTrmywTdofIeOpRaGDXmyfIrGkFuI1owR2
/0uj/FLSOdZWEx1on4HfUW+SFkPCOL9S3Kgg1UeGkEAUwr3KMUhC3SYzeFkHwAa+
TWzmH0/B3QUz198XhElO6W29UBkLGqK3zhZ7EHtWVnyi7vQyZ2kVxbGIc2wltcy/
xEEW7YALzLo1ESFmZKAqUXbFqaSbpfl2SMp0qZVRdXAsDqqV5DItb0LcR0RCrjkG
azyXuKpZjw5uOdSsNDu8YTjY0eMxj/43Yk2T+SaDJRAWqgKxBY8=
=XXRz
-----END PGP SIGNATURE-----

--bhvDS/AOsraOZy9M--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Rutherther <rutherther@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 12 May 2025 17:34:02 +0000
Resent-Message-ID: <handler.78332.B78332.174707118629782 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Greg Hogan <code@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174707118629782
          (code B ref 78332); Mon, 12 May 2025 17:34:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 May 2025 17:33:06 +0000
Received: from localhost ([127.0.0.1]:54549 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEX1V-0007kI-TM
	for submit <at> debbugs.gnu.org; Mon, 12 May 2025 13:33:06 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::]:39550 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 1uEX1Q-0007je-RF
 for 78332 <at> debbugs.gnu.org; Mon, 12 May 2025 13:33:03 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 4f25261f
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); 
 Mon, 12 May 2025 17:32:53 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
In-Reply-To: <CA+3U0Zk8WCvJ+YPKoSwvYeGQTxuqaM5zWNSdZVsBWboS86VWVw@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN>
 <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj>
 <CA+3U0Z=dzaT+_hJCA6oyi6DnLCXoW3KrsZmxcjZAcrJEHN3a2A@HIDDEN>
 <87tt5pajcc.fsf@HIDDEN>
 <CA+3U0Zk8WCvJ+YPKoSwvYeGQTxuqaM5zWNSdZVsBWboS86VWVw@HIDDEN>
Date: Mon, 12 May 2025 19:32:51 +0200
Message-ID: <87plgdag58.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=1747071173; h=from : to : cc
 : subject : in-reply-to : references : date : message-id :
 mime-version : content-type : content-transfer-encoding : from;
 bh=z/xvVY3BOkyk9nDfUeIBlNNN6iNV18demuM5D7v3Hgs=;
 b=hFrhwtV9/lON/F72dzEYfr/uqH1Usrzvw+0iMXkHf5WF1VUd+WibGJKZMp9Cw+zplfKIF
 RtNkIi1bJxGSXpc2I9th+Ey1+w8G71Cc/jftVsbcpGVOKCFoIEWkY023E3YTmSmAuFHcsvQ
 1tfPX96EJ7nCrPR1eiOsZOPG2mUaVps=
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:  Greg Hogan <code@HIDDEN> writes: > On Mon, May 12,
   2025 at =?UTF-8?Q?12:23=E2=80=AFPM?= Rutherther <rutherther@HIDDEN> wrote: > > So for the
    (small?) subset of users (myself included) who do not > enable substitutes,
    then for the small set of pac [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
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:  Greg Hogan <code@HIDDEN> writes: > On Mon, May 12,
   2025 at =?UTF-8?Q?12:23=E2=80=AFPM?= Rutherther <rutherther@HIDDEN> wrote: > > So for the
    (small?) subset of users (myself included) who do not > enable substitutes,
    then for the small set of pac [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  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

Greg Hogan <code@HIDDEN> writes:

> On Mon, May 12, 2025 at 12:23=E2=80=AFPM Rutherther <rutherther@HIDDEN=
yz> wrote:
>
> So for the (small?) subset of users (myself included) who do not
> enable substitutes, then for the small set of packages provided
> pre-built with the installation ...
>
>>> guix depends on gnutls
> guix@HIDDEN
> guile-gnutls@HIDDEN
> gnutls@HIDDEN

Yeah, which means users cannot pull from 1.4.0
See this thread https://lists.gnu.org/archive/html/guix-devel/2025-04/msg00=
205.html

>
> Can we not retry mirrors on checksum mismatch?=20

I don't know why not. I would also think it's good way to mitigate
issues like this. But my main point was meant to be that I think issues
like that will happen in the future as well, so having old releases
means users have to deal with them more often.

> Does use of SWH require substitutes to be enabled?

SWH should be used even without substitutes to my knowledge.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Andreas Enge <andreas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 13 May 2025 12:57:02 +0000
Resent-Message-ID: <handler.78332.B78332.174714099517474 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Ekaitz Zarraga <ekaitz@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174714099517474
          (code B ref 78332); Tue, 13 May 2025 12:57:02 +0000
Received: (at 78332) by debbugs.gnu.org; 13 May 2025 12:56:35 +0000
Received: from localhost ([127.0.0.1]:58609 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEpBS-0004Xj-5A
	for submit <at> debbugs.gnu.org; Tue, 13 May 2025 08:56:34 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:33918)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <andreas@HIDDEN>) id 1uEpBN-0004XR-Va
 for 78332 <at> debbugs.gnu.org; Tue, 13 May 2025 08:56:30 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 784B44F5;
 Tue, 13 May 2025 14:56:23 +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 6vQfPw-5wl7k; Tue, 13 May 2025 14:56:21 +0200 (CEST)
Received: from jurong (176-179-191-150.abo.bbox.fr [176.179.191.150])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 422EC639;
 Tue, 13 May 2025 14:56:19 +0200 (CEST)
Date: Tue, 13 May 2025 14:56:17 +0200
From: Andreas Enge <andreas@HIDDEN>
Message-ID: <aCNBcdRUBBYEb7mm@jurong>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <6599e0d9-ce75-470d-bcbc-511da7aedf66@HIDDEN>
 <aB8ZGWUXd7zIPxnA@jurong>
 <a0140074-92f7-4e7b-9c58-24dfd075088a@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a0140074-92f7-4e7b-9c58-24dfd075088a@HIDDEN>
X-Rspamd-Action: no action
X-Rspamd-Server: hera
X-Rspamd-Queue-Id: 784B44F5
X-Spamd-Bar: -----
X-Spamd-Result: default: False [-5.59 / 15.00]; BAYES_HAM(-3.00)[100.00%];
 NEURAL_HAM(-2.99)[-0.997]; 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-Spam-Score: 0.0 (/)
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 01:04:18PM +0200 schrieb Ekaitz Zarraga:
> So, now, realistically speaking, we are not ready for total automation and
> we should make a release process. That I agree with, and we could use the
> process to try to slowly make the process lighter until it barely exists,
> which would at some point let us make releases more often and with lower
> effort.
> (...) I'm thinking on how could we share
> the responsibility to make the work of those that are going to make the
> release as light as possible.

I think this is something we agree upon: Things should be as automatic
as possible, if we can make machines do the work for us, this would be
perfect!

But clearly this is not easy. Given past problems with CI and QA, we see
that there are not enough people working on automation, and that the
problems are complex.

> I'm a little bit pessimistic about how many people would get involved in
> that, or better said: I'm worried that the very same people would be the
> ones that get involved in the process over and over again.

Indeed, the idea is to have a turn-over, which is partially spelt out in
the proposal. If everybody takes part twice and there is a renewal of
half of the people every time, we would avoid that people get burnt out
and still pass on experiences with the process.

> That's why I'm trying to find a way to make everybody get involved in the
> process in their everyday work, so the actual release process is not that
> hard and makes it more likely to people to join.

Good point, which maybe should not be a part of this GCD, but a subject
of further thought: How can we make our life easier? How can we improve
the quality of Guix? When Ludovic added the deprecation policy to the
manual, I suppose that was something he had in mind. Similarly it is the
goal of the Codeberg migration.

> I like the GCD, I think it's thoughtful and well organized, but it might
> lack some of that: let's see how it went and try to make it lighter and
> lighter for the future.

The GCD contains step 14: "Release retrospective". That covers your
point, in my opinion.


But more fundamentally, I think it is not realistic to end up with a
fully automatic procedure. In the end Guix is a social endeavour (lots
of people working together towards a common goal), and I think we need
social processes to reach our goals. For instance, when merging team
branches, we somehow need to negotiate the order; individual teams will
look at their branches and try to advance them, but sometimes it may be
better to let another branch go to the front. Similarly for a release,
decisions will have to be made. Packages may have to be dropped, the
latest release of desktop environment X which is almost, but not quite,
ready may have to be excluded, and so on. Having a team to coordinate
this, and also invested to take unpopular decisions, is necessary in my
opinion.

Also I think we need a period of manual testing. As Vagrant said,
sometimes packaging for Debian, for instance, reveals problems that we
had not seen before. Or asking people to try an installation on an
exotic architecture.

Andreas

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Andreas Enge <andreas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 13 May 2025 13:13:02 +0000
Resent-Message-ID: <handler.78332.B78332.174714192320268 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Greg Hogan <code@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Rutherther <rutherther@HIDDEN>, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174714192320268
          (code B ref 78332); Tue, 13 May 2025 13:13:02 +0000
Received: (at 78332) by debbugs.gnu.org; 13 May 2025 13:12:03 +0000
Received: from localhost ([127.0.0.1]:58638 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uEpQQ-0005Gf-Ai
	for submit <at> debbugs.gnu.org; Tue, 13 May 2025 09:12:02 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:53046)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <andreas@HIDDEN>) id 1uEpQN-0005GI-1C
 for 78332 <at> debbugs.gnu.org; Tue, 13 May 2025 09:11:59 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 0C61694;
 Tue, 13 May 2025 15:11:53 +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 YdpWKEXT1GJB; Tue, 13 May 2025 15:11:52 +0200 (CEST)
Received: from jurong (176-179-191-150.abo.bbox.fr [176.179.191.150])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id E952187;
 Tue, 13 May 2025 15:11:50 +0200 (CEST)
Date: Tue, 13 May 2025 15:11:49 +0200
From: Andreas Enge <andreas@HIDDEN>
Message-ID: <aCNFFWE9AuiKAgfQ@jurong>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN>
 <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj>
 <CA+3U0Z=dzaT+_hJCA6oyi6DnLCXoW3KrsZmxcjZAcrJEHN3a2A@HIDDEN>
 <87tt5pajcc.fsf@HIDDEN>
 <CA+3U0Zk8WCvJ+YPKoSwvYeGQTxuqaM5zWNSdZVsBWboS86VWVw@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+3U0Zk8WCvJ+YPKoSwvYeGQTxuqaM5zWNSdZVsBWboS86VWVw@HIDDEN>
X-Rspamd-Action: no action
X-Rspamd-Server: hera
X-Rspamd-Queue-Id: 0C61694
X-Spamd-Bar: ---------
X-Spamd-Result: default: False [-9.56 / 15.00]; REPLY(-4.00)[];
 NEURAL_HAM(-2.99)[-0.998]; BAYES_HAM(-2.97)[99.86%];
 MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.10)[text/plain];
 RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[];
 MIME_TRACE(0.00)[0:+]; RCPT_COUNT_FIVE(0.00)[5];
 TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[];
 RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[];
 ARC_NA(0.00)[]
X-Spam-Score: 0.0 (/)
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 Greg,

I am having some trouble following your argumentation; in the beginning
of your different postings I got the impression that you did not see
a need for releases, since one could always do a "guix pull". But then
you end with:

Am Mon, May 12, 2025 at 01:11:15PM -0400 schrieb Greg Hogan:
> I think we should release more often (multiple times per year)

So I am definitely not getting your point! With the goal of moving forward,
could you try to reformulate your ideas? Are there concrete points we could
improve in the GCD, or do you think it should simply be dropped as not
relevant to the real problem? If we missed it, what is the real problem?

As to automation, I made a few arguments in my reply to Ekaitz, so I will
not repeat them here.

Andreas

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Greg Hogan <code@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 13 May 2025 15:04:01 +0000
Resent-Message-ID: <handler.78332.B78332.174714860411128 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Andreas Enge <andreas@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Rutherther <rutherther@HIDDEN>, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174714860411128
          (code B ref 78332); Tue, 13 May 2025 15:04:01 +0000
Received: (at 78332) by debbugs.gnu.org; 13 May 2025 15:03:24 +0000
Received: from localhost ([127.0.0.1]:60883 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uErAB-0002tQ-HI
	for submit <at> debbugs.gnu.org; Tue, 13 May 2025 11:03:23 -0400
Received: from mail-oo1-xc2f.google.com ([2607:f8b0:4864:20::c2f]:49514)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <code@HIDDEN>)
 id 1uErA8-0002t8-O6
 for 78332 <at> debbugs.gnu.org; Tue, 13 May 2025 11:03:21 -0400
Received: by mail-oo1-xc2f.google.com with SMTP id
 006d021491bc7-6021e3daeabso2676146eaf.3
 for <78332 <at> debbugs.gnu.org>; Tue, 13 May 2025 08:03:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=greghogan-com.20230601.gappssmtp.com; s=20230601; t=1747148595; x=1747753395;
 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=dhGaJ9OnJhjqRVbu3l9zFKt/VOg2Dm/buLpF8MeN5gc=;
 b=BRGBmXCtsy6+PGdJ+rsxzz5GusbGg3s6FIirCgED+kgdPvRa2RJdFVnacHkWaO+l3/
 +dflzjUfK8COx3Y3TKdaHcIlnADwo7ps9uRLHiouFSbB8ArdXGXp6AMDggWhtYF+gLud
 Jwd4CATkQblmdKIc+cOLzQafgm9JRKjL3DY9W7l57AL0rXCooG6yxM64jEJ7gGpLB4pV
 SrSzv2a4IpfSDwTYWBZcvCFkPH2IUwLUEDwqRpUVTou0vjf4GmPuqUdBOjwtye/0JgMM
 Fkcf5dUibG3gvjEdK9N/TgqHhzzbANyCf9yFwvWXqkGWxqgOPF9xiWHwRjbpGtOghpan
 cUkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1747148595; x=1747753395;
 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=dhGaJ9OnJhjqRVbu3l9zFKt/VOg2Dm/buLpF8MeN5gc=;
 b=Ctj4y0ipLrV6XBV9gi8ZN1fXkrRpu/aBgxkheV57iAO3WXPLiI9Qmo4wczfoPH6D7+
 1qDmvAnPTZ1YP8QftOeguH5T7arbeI8IvU0eF8ob2DTJGFlO0QUFygFUvMIPukXsBsEU
 e1HN8dx/iZcVk1/mbfamxIOmn94RaandEsfzMhnQE0OmU6fXE+JsfqGF6ty1rm6gG7Ja
 4lK+xLkKcSbF9o3Wvw7CU9r0rKrl2UoSnKIw7yyQjZ9Uj4OvN1AKFestvLEFmPEILBtc
 72wAdDQHgFQsRH0dwjFtJBfHVXQsN2HzKq0EYVTh0lFp7QLTyLFNsxj9YR3XRbb+QNXc
 Kqog==
X-Forwarded-Encrypted: i=1;
 AJvYcCXYLbSudj3gJtjWRCheAJNaHBKLgWIjFf3rEIlTSsKki03PymjVy4NR87BHpYEBDvMQaEacRA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxOENxlf1Buk43kQytGaAD6mO4ZXn7lcLynzP8qfxPB5PVAKUWd
 FXXdMe63iMdhMoXgyY4G+wTUoghPqqQAxG45OFlxaOM9qbg2Gt10BGrEQ2ibBYUtG2XfTXXb4r5
 QwmVSoeBlxMMz85nG9wXbdo+FZcr1I7lY+gEBlZ9B/gg+KKYT
X-Gm-Gg: ASbGncv+yqjVw6CTYs13KI+RlY/YdDHWa/DdaeverP9naO8wF7aBKnmgkRNUc4fV2MO
 eljC30SJCWKhQ++KYyAUNLU6wF7TBJO/dN7b+pv3HseyFj0cRmSjIN1Z5LwP+6C+C/6Z3ZWOZjp
 LqX6b4Fu8IqXSbJw7Feh7dUxu/sgxrNJ78
X-Google-Smtp-Source: AGHT+IHz+PBjP9Bd1FkOODfXwJBleu3c6ziosVLNCIsKWf9beOC3eQwqV6bdQBs2JL6cFutJZrGg0Jdp+YIVab3Ewts=
X-Received: by 2002:a05:6871:3326:b0:2c1:e9a3:3ab3 with SMTP id
 586e51a60fabf-2dba45c6337mr10534069fac.33.1747148594529; Tue, 13 May 2025
 08:03:14 -0700 (PDT)
MIME-Version: 1.0
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN>
 <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj>
 <CA+3U0Z=dzaT+_hJCA6oyi6DnLCXoW3KrsZmxcjZAcrJEHN3a2A@HIDDEN>
 <87tt5pajcc.fsf@HIDDEN>
 <CA+3U0Zk8WCvJ+YPKoSwvYeGQTxuqaM5zWNSdZVsBWboS86VWVw@HIDDEN>
 <aCNFFWE9AuiKAgfQ@jurong>
In-Reply-To: <aCNFFWE9AuiKAgfQ@jurong>
From: Greg Hogan <code@HIDDEN>
Date: Tue, 13 May 2025 11:03:02 -0400
X-Gm-Features: AX0GCFt5TcLYnIr8DRYMem7lC2OvhRG1UCpJ3PXhfOgtpIHOPi0HlqzM9TYJa-E
Message-ID: <CA+3U0ZmtbgvDXM_Q9jZM03hVHn7zpnmRhCf2b2pP=u_vmOLBXg@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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 Tue, May 13, 2025 at 9:11=E2=80=AFAM Andreas Enge <andreas@HIDDEN> wrot=
e:
>
> Hello Greg,
>
> I am having some trouble following your argumentation; in the beginning
> of your different postings I got the impression that you did not see
> a need for releases, since one could always do a "guix pull". But then
> you end with:

Hi Andreas,

There may be some confusion in terms. The GCD states "there are
currently over 30,000 packages in the archive" and "Guix would still
make all packages and services part of a release (the entire
archive)". And when I look up the definition of archive I see
references to "historical documents" and "preservation".

If a release is build artifacts plus every package in working order
then I find that to be a Herculean task. There is of course tremendous
value in this because on every contribution the developer must
investigate whether build failures are newly caused or preexisting (or
ephemeral or system dependent). I fully support this attempt, I just
think we should first attempt to get every package in working order
before codifying this annual process in a GCD.

If a release is simply build artifacts, then we are already automating
part of this process. I count 10 builds of the binary release across
March and April:
  https://ci.guix.gnu.org/search?query=3Dguix-binary

Can we not similarly automate creation of the ISO and QCOW2 artifacts?
Then, as you note, these need to be manually tested and blessed as a
release. But I don't see why the ancillary packages need to be in
working order to cut a new release.

> For instance, when merging team branches, we somehow need to negotiate th=
e order; individual teams will look at their branches and try to advance th=
em, but sometimes it may be better to let another branch go to the front.

It would be nice to make your teams coordinator position official.
Considering the number of ideas for improving the teams workflow, we
are probably due for a GCD. And I think that is the right process, to
have the GCD deliberate the lessons learned rather than speculate
beforehand.

> Am Mon, May 12, 2025 at 01:11:15PM -0400 schrieb Greg Hogan:
> > I think we should release more often (multiple times per year)
>
> So I am definitely not getting your point! With the goal of moving forwar=
d,
> could you try to reformulate your ideas? Are there concrete points we cou=
ld
> improve in the GCD, or do you think it should simply be dropped as not
> relevant to the real problem? If we missed it, what is the real problem?

Does this clarify? I see this proposal as trying to 1) manually fix 2)
all of Guix's problems in 3) a shortened time window, shrinking what
we are unable to maintain in 12 months into a few weeks (the only
thing missing is closing all issues during the release cycle).

And maybe it works! Maybe the 10x and 100x contributors, including the
sponsors of this GCD, will happily fix everything and make this
happen. I can accept that. But why not just do that already? Are the
core developers not empowered? Too deferential? What improvements does
this GCD offer other than a process to "encourage and excite"?

Greg

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Andreas Enge <andreas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 13 May 2025 15:55:03 +0000
Resent-Message-ID: <handler.78332.B78332.174715167032180 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Greg Hogan <code@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Rutherther <rutherther@HIDDEN>, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174715167032180
          (code B ref 78332); Tue, 13 May 2025 15:55:03 +0000
Received: (at 78332) by debbugs.gnu.org; 13 May 2025 15:54:30 +0000
Received: from localhost ([127.0.0.1]:32785 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uErxe-0008My-1L
	for submit <at> debbugs.gnu.org; Tue, 13 May 2025 11:54:30 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:49684)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <andreas@HIDDEN>) id 1uErxZ-0008MW-VJ
 for 78332 <at> debbugs.gnu.org; Tue, 13 May 2025 11:54:27 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 654735F5;
 Tue, 13 May 2025 17:54:19 +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 1NeCSqKZ7EOy; Tue, 13 May 2025 17:54:18 +0200 (CEST)
Received: from jurong (176-179-191-150.abo.bbox.fr [176.179.191.150])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 102DD5D2;
 Tue, 13 May 2025 17:54:17 +0200 (CEST)
Date: Tue, 13 May 2025 17:54:16 +0200
From: Andreas Enge <andreas@HIDDEN>
Message-ID: <aCNrKOtzF5pBa9no@jurong>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <CA+3U0Zm54=1rCSOjum0aBV7pHgaUgJd7Vb-9j3UBEa3pJ4Vjhw@HIDDEN>
 <n27cpfnbzut4hswe6rdp4tncuvy45pnfyhafquwef3xheui46s@nb6zwm5mfibj>
 <CA+3U0Z=dzaT+_hJCA6oyi6DnLCXoW3KrsZmxcjZAcrJEHN3a2A@HIDDEN>
 <87tt5pajcc.fsf@HIDDEN>
 <CA+3U0Zk8WCvJ+YPKoSwvYeGQTxuqaM5zWNSdZVsBWboS86VWVw@HIDDEN>
 <aCNFFWE9AuiKAgfQ@jurong>
 <CA+3U0ZmtbgvDXM_Q9jZM03hVHn7zpnmRhCf2b2pP=u_vmOLBXg@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+3U0ZmtbgvDXM_Q9jZM03hVHn7zpnmRhCf2b2pP=u_vmOLBXg@HIDDEN>
X-Rspamd-Action: no action
X-Rspamd-Server: hera
X-Rspamd-Queue-Id: 654735F5
X-Spamd-Bar: ---------
X-Spamd-Result: default: False [-9.60 / 15.00]; REPLY(-4.00)[];
 BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM(-3.00)[-0.999];
 MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.10)[text/plain];
 RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[];
 MIME_TRACE(0.00)[0:+]; RCPT_COUNT_FIVE(0.00)[5];
 TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[];
 RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[];
 ARC_NA(0.00)[]
X-Spam-Score: 0.0 (/)
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 Greg,

thanks for clarifying, this is indeed very helpful.

Am Tue, May 13, 2025 at 11:03:02AM -0400 schrieb Greg Hogan:
> There may be some confusion in terms. The GCD states "there are
> currently over 30,000 packages in the archive" and "Guix would still
> make all packages and services part of a release (the entire
> archive)". And when I look up the definition of archive I see
> references to "historical documents" and "preservation".
> (...)
> If a release is simply build artifacts, then we are already automating
> part of this process. I count 10 builds of the binary release across
> March and April:
>   https://ci.guix.gnu.org/search?query=guix-binary

I think the release proposal tries to reach some middle ground between
these. There is supposed to be a set of "important" packages which
should build (or be removed, so that the users get what the description
says), the "package sets". These are not yet really defined, and doing
so is given as a task for the release team (no 05, "package set
finalisation"). They would block a release.

The remaining close to 30000 ones will be shipped ("released") whether
they build or not; it is clear we will never reach a 100% perfect
distribution (and I think it is a task for the teams to more
aggressively remove packages in their realm that do not work, which
should not be postponed and left to the release team).

I agree that the GCD is a bit ambiguous about this and in particular the
removal procedure; it mentions the "deprecation policy", but this takes
a month in itself, so is probably not compatible with the tight release
schedule.

So as a practical example, I suppose we will define a desktop
environment package set; gnome will certainly be a part of it, and maybe
something else (xfce? sway?), but probably neiter lxqt nor kde. Then if
lxqt does not build, the release team would not care. If gnome does not
build, the release team would push the gnome team to repair it. In
theory gnome could be removed from the release, but I find it difficult
to imagine, although it would be possible as a last resort, together
with an entry in the release announcement. More likely, we will all push
very hard to get gnome in. But probably renounce at a last minute
transition to a newer gnome version.

> Does this clarify? I see this proposal as trying to 1) manually fix 2)
> all of Guix's problems in 3) a shortened time window, shrinking what
> we are unable to maintain in 12 months into a few weeks (the only
> thing missing is closing all issues during the release cycle).

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

> And maybe it works! Maybe the 10x and 100x contributors, including the
> sponsors of this GCD, will happily fix everything and make this
> happen. I can accept that. But why not just do that already? Are the
> core developers not empowered? Too deferential? What improvements does
> this GCD offer other than a process to "encourage and excite"?

This is the hope, that "encourage and excite" will make the difference 
during a release cycle. Clearly we cannot all be excited all the time :)

Andreas

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: =?UTF-8?Q?Andr=C3=A9?= Batista <nandre@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 16 May 2025 20:03:02 +0000
Resent-Message-ID: <handler.78332.B78332.174742574921036 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174742574921036
          (code B ref 78332); Fri, 16 May 2025 20:03:02 +0000
Received: (at 78332) by debbugs.gnu.org; 16 May 2025 20:02:29 +0000
Received: from localhost ([127.0.0.1]:41126 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uG1GG-0005T4-L5
	for submit <at> debbugs.gnu.org; Fri, 16 May 2025 16:02:29 -0400
Received: from mx1.riseup.net ([198.252.153.129]:41682)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <nandre@HIDDEN>) id 1uG1GD-0005S6-HH
 for 78332 <at> debbugs.gnu.org; Fri, 16 May 2025 16:02:26 -0400
Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mx1.riseup.net (Postfix) with ESMTPS id 4ZzdK74hMrzDq8b;
 Fri, 16 May 2025 20:02:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1747425739; bh=VwpEsF6GUfsI8cJKooWH2O7nYu51ZuXodr5jWXBbqs4=;
 h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
 b=ZPG1LbXjI8y/dVplaxUoCI0g/ruhu80EQEoc7m6vdwtCNwyMqTT12trFljDLankP6
 4mlwCu8FIvtWLj6J3U4s9F7s5QDVfLYvIWSdpWLQWyZJJe0ePe0bWdPIrgN6ZRECzG
 AlWMWkyIjP4eX5/cqH7bsQKjNTkGrchJBYjfCXb0=
X-Riseup-User-ID: 188D6ED8EBA7933064B9DF253B06AF735DB9CA23A2A7590B8C49312872712810
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4ZzdK64DLtzFw9Y;
 Fri, 16 May 2025 20:02:18 +0000 (UTC)
Date: Fri, 16 May 2025 17:02:12 -0300
From: =?UTF-8?Q?Andr=C3=A9?= Batista <nandre@HIDDEN>
Message-ID: <aCeZxK0-0dbsc6kb@andel>
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
 <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
X-Spam-Score: -0.7 (/)
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,

sex 09 mai 2025 �s 13:53:39 (1746809619), steve@HIDDEN enviou:
> 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.
> 

First of all, thanks for this initiative, we're certainly in need of a more
structured and reliable release process.  I have no experience doing guix
(or any distro) release, so take or drop my comments as you see fit.

I'm not sure a GCD is the proper way to tackle the release issue.  As we say
here in the global south - where November is spring :) - "you are putting the
cart before the oxen", meaning its the oxen that should be dragging the cart,
not the other way around.

Since we've been having problems producing a release for the past years, I feel
that aiming to shorten the release time span before even having had a release
might not be the best way to achieve the proposed goal.  What happens if we
approve this GCD, but then no one assumes the roles of a release team?  How
could we "enforce" this GCD on a volunteer project?

Wouldn't it be better to first establish and organize a release team, with the
goal of releasing v. 1.5.0 as soon as possible and with the secondary goal
of establishing/documenting a release process/schedule for future releases?
IMO, this does not require a GCD, "just" people volunteering to the work at
hand.

In a sense, I agree with other comments here that maybe we should treat
releases as something less disruptive of our normal activities.  So, instead
of aiming to mimick what other - larger and more resourceful - distros do, we
could aim to do it in a way that is compatible with our own routines and
resources.

What I envision is something like:

1.  The release team focuses mainly on the artifacts.  Those should routinely
be automatically built, regardless if we are about to release;

2.  The relase team keeps a watchful eye on CI/QA for the build status of main
architectures and packages needed to build the installer and images for those;

3.  Once some major changes (linux-lts, gnome, toolchain, etc) hit master and
CI shows that those are good and the successful build percentage is on a
historical high on CI/QA for the major architectues, the release team proposes
a new release to guix-devel;

4.  Once proposed, any other major changes (anything that currently warrants
a separate branch) are delayed for two weeks;

5.  During these two weeks, the release team has the authority to revert any
breaking changes (new build failures) commited to master and everyone is
invited to test the latest beta-release artifacts;

6.  If no release critical bugs are found, the relase team adds a commit
tagging the new release with a news entry and a blog post summarizing the
main changes since the last release and publishes the artifacts;

7.  If release critical bugs are found and cannot be fixed in time, the
release proposal is withdrawn and people are invited to work on the rc-bugs
and major changes can be again merged to master.  Go back to item 3, but a
new release proposal can only be made if the already rc-bugs are fixed and
the major changes that were delayed at the time of the last proposal had the
opportunity to be merged.

Does that make any sense?

Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Andrew Tropin <andrew@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 18 May 2025 06:29:02 +0000
Resent-Message-ID: <handler.78332.B78332.174754972113828 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, 78332 <at> debbugs.gnu.org
Cc: Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174754972113828
          (code B ref 78332); Sun, 18 May 2025 06:29:02 +0000
Received: (at 78332) by debbugs.gnu.org; 18 May 2025 06:28:41 +0000
Received: from localhost ([127.0.0.1]:54304 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uGXVj-0003af-MM
	for submit <at> debbugs.gnu.org; Sun, 18 May 2025 02:28:41 -0400
Received: from out-174.mta1.migadu.com ([2001:41d0:203:375::ae]:44290)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <andrew@HIDDEN>) id 1uGXVe-0003a7-LM
 for 78332 <at> debbugs.gnu.org; Sun, 18 May 2025 02:28:34 -0400
X-Report-Abuse: Please report any abuse attempt to abuse@HIDDEN and
 include these headers.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trop.in; s=key1;
 t=1747549703;
 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=pXC2Jr7JZpGn71WPxYkD3+2y/mS6yWZMao+hwgVIjRc=;
 b=ZVqOMuF9vJ+T/jRXQMSy+lpotm6ZV4u3cmsrVsNsMVPXEhKgsIfibfXdJgR4h2K125/rRo
 /+h+P1v5cIM144aMw9c0Lj5Y/xlhn7oRRAPesxWpCvmzQKiAO1MVSlO1MkClw0JHQ1c+dm
 9iiogo4UayRdb3oQZOiIBVhbu3KoAy8UxV8XpkTY8S23ikBBw9FyQ3kh7131NQZPogPnWF
 mYW0yw6J3MdsRXV0vzMHgtAfNq73+eVVwpa7DIYuztdPGy57E7UmRy1lTSCj8DbV6wN2k7
 35CHtOahAa4EL6JCKQ1x4M30qFwJK4W3PGiowyLsbVmzgHcHrkStoFSYFb/LVA==
From: Andrew Tropin <andrew@HIDDEN>
In-Reply-To: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
Date: Sun, 18 May 2025 13:27:59 +0700
Message-ID: <87ikly5t74.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Migadu-Flow: FLOW_OUT
X-Spam-Score: -0.0 (/)
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; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi Steve,

Thank you very much for all the effort you put into research, analysis
and comming up with this very detailed proccess proposal.

I'm a very slow reader, so I went through the whole GCD, but only
briefly skimmed the discussions in this thread.  Will share my overall
thoughts below.

Slow guix pull is a technical problem, not organizational, while we can
work around it by including checkout and auth cache into iso and
releasing often, ideally the guix pull itself and its speed should be
improved, not the release cycle introduced.

The similiar for quality control.  We have a huge number of contributors
and very small number of maintainers and there can be a bottleneck here.
Also we have very blurry maintanance responsibility for any particular
package or group of packages.  So, we can definitely improve in this
area as well. By asking release team for commitment we just push those
duties and responsibilities to release managers and engineers (which can
be viable strategy, but I'm not sure).  I also have concerncs on the
amount of commitment and effort required by a volunteering release team.

My intuition suggests to radically reduce the scope and complexity of
the release process and focus only on producing fresh live system and a
few other artifacts.  We can just ensure that live system and standalone
package manager work properly and people can boot it/install via apt in
Debian/etc.  After that they anyway make guix pull/time-machine, so we
probably don't need to make a release commit from which iso is built to
have all the packages in a perfect working shape.

I actually have much more thoughts, but I think those above are most
relevant and hope clear and useful.  Appreciate your work!

> * 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 tracke=
r>
> +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 =
and
> +the project.  This GCD proposes we implement an annual release cadence a=
nd
> +simplify the release process to make releases easier.
> +
> +The project currently releases new versions of Guix on an ad hoc frequen=
cy.
> +The 1.4.0 release happened in December 2022 [^1], which is almost 2.5 ye=
ars
> +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 a=
nd
> +   manuals will be up to date, and the initial 'guix pull' will be faste=
r.
> +2. Package installation will improve for all users.  Packages will be un=
grafted
> +   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.  Help=
ing us
> +   to inform more people about the benefits of using GNU Guix!
> +5. A regular release cycle is a rallying point for our contributors givi=
ng 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 substant=
ial
> +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 rele=
ases
> +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/gui=
x-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 packa=
ge
> +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 additio=
nal
> +testing and stabilisation across the repository.  They also ensure we up=
date
> +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 experie=
nce,
> +and in some cases may even deter users [^4]. Additionally, it requires t=
he
> +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 prospe=
ctive
> +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 ma=
jor
> +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/b=
log/2025/guix-user-and-contributor-survey-2024-the-results-part-1/)
> +it would make sense to align with these upstream releases.  However, giv=
en 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: aimin=
g 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 unrealisti=
c 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 particu=
lar
> +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 out=
side
> +these sets do not receive security updates.
> +
> +Guix is both a package manager that can be hosted on other Linux distrib=
utions,
> +and a Linux distribution.  Limiting the range of packages that receive a=
ttention
> +is consequently more complicated. Guix already has manifests to track wh=
ich
> +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 recei=
ve 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 in=
clude
> +things like X11/Wayland, desktop environments, key applications and them=
es.
> +* server: provides packages and services for a server.  This would inclu=
de
> +standard server packages and services.
> +* hosted: provides packages and services which are necessary in hosted u=
sage.
> +
> +Guix would still make all packages and services part of a release (the e=
ntire
> +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 pac=
kages
> +as reasonably possible.  It would mean that developers could focus on the
> +critical packages and services during a release.  As an example, this wo=
uld
> +mean that a major issue in the Linux kernel could block a release, but n=
ot 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 us=
er
> +freedom this variety is significant and is a key motivator for developer=
s.
> +
> +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.  Consequentl=
y, 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 p=
rimary
> +    architecture may be pushed to users.
> +  - Security: no commitment to providing security updates for this archi=
tecture.
> +
> +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 pol=
icy.
> +
> +
> +## Release artifacts
> +
> +Using the primary architecture tier and the package sets would involve c=
reating
> +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 artifact=
s could
> +be created but would not be part of the formal release testing and error=
s 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 wi=
ll 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, a=
round
> +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 Releas=
e 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 bloc=
kers
> +- 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 re=
lease
> +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 re=
lease
> +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. we=
b site)
> +This role can be done by any member of the Guix community who has suffic=
ient
> +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 relea=
se
> +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 envisio=
ned
> +that a release project will be about 12 weeks. See Appendix 1: Release P=
roject
> +Time-line for an example.
> +
> +In order to improve knowledge transfer and reduce the toil of doing rele=
ases
> +the Release Managers for a release will document the release process.  T=
here is
> +inspiration for this in [NixOS's release wiki](https://nixos.github.io/r=
elease-wiki/Home.html)
> +and we already have detailed [release documentation](https://git.savanna=
h.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
> +.
> +
> +
> +# Cost of Reverting
> +
> +If regular releases were not successful then the project would switch ba=
ck 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 o=
ver
> +time it may be possible to undertake full releases every six months or s=
ome
> +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 release=
s.  If
> +that's the case we would revert back to irregular releases.
> +
> +There are various improvements that could be made to this process over t=
ime,
> +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 usin=
g 16
> +weeks in total to give teams time to prepare.
> +
> +The current outline builds from our current [release document](https://g=
it.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 o=
f the
> +release team.  Encourage participation in testing and identifying bugs f=
rom
> +the community.
> +
> +### 4. Toolchain and transition freeze
> +No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtim=
es
> +(e.g. java).  There should be no changes that will cause major transitio=
ns.
> +
> +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 Gu=
ix 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 reje=
cted.
> +
> +No alterations to the Guix daemon or modules are accepted after this poi=
nt.
> +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 th=
eir
> +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 a=
nd
> +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 identifi=
ed for
> +removal.  A build failure of a package or service that's in a package se=
t 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 a=
ny
> +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, the=
se are
> +sent to a new 'staging' branch, rather than directly to master.  The mas=
ter
> +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 cha=
nges are
> +minor package upgrades.
> +
> +### 9. Ungraft master branch
> +Guix master is ungrafted to minimise the difference with users of the re=
lease
> +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 o=
n 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 us=
e 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 fina=
l 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/fixe=
d 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/ef=
ficient
> +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 a=
nd screnarios
> +      are Nix's stable branch, OpenSUSE's SlowRoll branch and Ubuntu's L=
TS
> +      (Long Term Support) releases.
> +
> +[^3]: the aspect of creating news and excitement for casual users is wel=
l-known
> +      in the FOSS community. An example from=20
> +      [GNOME's earlier days](https://mail.gnome.org/archives/gnome-hacke=
rs/2002-June/msg00041.html).
> +
> +[^4]: GuixDays 2025 release discussion brought up examples of Guix not b=
eing
> +      used to teach users because the initial pull was so slow that the
> +      teaching session would have completed before 'guix pull' would fin=
ish.
> +      We know guix pull being slow was identified by users as a challeng=
e.
> +
> +[^5]: OpenSuse has a [SlowRoll branch](https://en.opensuse.org/Portal:Sl=
owroll)
> +      where they release a smaller set of package updates on a monthly b=
asis.
> +      This is an interesting innovation as it allows users to still bene=
fit from
> +      a rolling release but at a slower rate of change (fewer regression=
s).
> +      They are also not dropping too far behind the rolling release, so =
there's
> +      not as much maintenance for OpenSUSE developers dealing with an ou=
t 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 not=
es.  Our
> +      version extends the idea to make sure other artifacts and activiti=
es that
> +      promote the release happen.
> +
> +[^7]: https://github.com/NixOS/rfcs/blob/master/rfcs/0085-nixos-release-=
stablization.md
> +

=2D-=20
Best regards,
Andrew Tropin

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmgpfe8ACgkQIgjSCVjB
3rD0wQ//Uxq96fUqDymORUv7aY2ZWFqAPwrg/GLK35EDj/Sg1jd/JxwDA/5+oi9i
JTAqy4PtWJ5ugj0KQTixRIOw7Ydd4AfJhZUw3k4M9n4zpnrArjbn14GpdVe5gmjf
ozh9hwfHWTcIDHc6sRwSQaUvZvoDvXYtCXHNUT/aBKnAzRc7zJAHdQdqEFAT7/8Z
2nB2oGZHfsTxGOrLaoJtJFPWDfi+ASWKYnjiVdehTtkRVUcQP3qDcRt4m2ya+ZYC
4cAKVy0IFKvaNjJeLRzlr9OCX75I+931j5C96T3YD9K/ac1e+jH0hvleMGDtdvmb
xZ+OhV9kDbkXILpv4PFt4ak2Oc+PWBXJSzHlqZ0T+HtosLcwY4XQ2zCxXYAnvIDx
xS40mmYFxsrEVwLw0IhbkS+Ec5du6GrBZS9InncYWb6XvWfIkd+aIeSDn54VVSAx
utr/XYobWMd61rtPl5zYI+I6JqAp39ppUPjfPbsebVLK4KDW8Z5xhWqxDJ+KXVLL
Z37jtk9tt7qM+2pK6fdkMbn4Zuk8Zo/y2q7/cQFwkhFAKUDdVvdr++VxYkg0OCwO
eYvEL3AZWi7Uv2YYbzyhFJoVD1GSIy0Jl2LZCTpeEry+r7U2C/Fp/RrNsPAIWS83
6zdkqzoCPCP9p74DnoeJCNUmDGzhDwrhZgWDwFxsEQgK0a20Tps=
=4Ic+
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Jelle Licht <jlicht@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 19 May 2025 13:05:01 +0000
Resent-Message-ID: <handler.78332.B78332.174765987216251 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174765987216251
          (code B ref 78332); Mon, 19 May 2025 13:05:01 +0000
Received: (at 78332) by debbugs.gnu.org; 19 May 2025 13:04:32 +0000
Received: from localhost ([127.0.0.1]:39424 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uH0AR-0004Dz-JB
	for submit <at> debbugs.gnu.org; Mon, 19 May 2025 09:04:32 -0400
Received: from mail3.fsfe.org ([31.24.147.90]:53850)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <jlicht@HIDDEN>) id 1uH0AN-0004DH-Qu
 for 78332 <at> debbugs.gnu.org; Mon, 19 May 2025 09:04:29 -0400
From: Jelle Licht <jlicht@HIDDEN>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsfe.org; s=2023072501;
 t=1747659866;
 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=vq1tEBJcz/MkK0aSuYbw48CoS34EnNJwfnxYjqY8DWs=;
 b=p8YpAXQoYzHmtL57V/NFT1DV1Yl6uorp3Rm7oO+KC67y0/dNJn0TaC1PkSK08mFvk49NAk
 LE/lRh6ZM8bC2amJ2ptjzUlHtOBOPSXQuKi0bXf1ymsQ74vQNbra5CUrKad6esyDR9b1Sd
 is80102gRLGSgqIDuxBdZOn6qg+nnM4=
In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
Date: Mon, 19 May 2025 15:04:23 +0200
Message-ID: <87ecwkzr8o.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -5.0 (-----)
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: -6.0 (------)


Hey folks,

Steve George <steve@HIDDEN> writes:

> 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! ...

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

>[snip]
> 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.

I think that this is a good point to make, but at the same time we may
not want to have other projects to direct our release cadence. Not
because we don't want to play along, but rather because it causes undue
stress and adds arbitrary deadlines that are hard to work around
w.r.t. our current volunteer group of contributors.

> 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.

My two cents: focus only on minimal, perhaps extended in such a way that
this is a system that after the first reboot allows one to run guix
pull.

Ditto for 'foreign-guix': any version of guix that doesn't burn down the
house on updating itself seems like it would be 'enough', and still a
strict improvement over the current situation.

> 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.

This makes a lot of sense to me, although I could be centered around
'functional' breakage w.r.t. allowing the installation to update itself
past any major issues via guix pull (+ guix system reconfigure or
equivalent).

> [snip]

Thanks again for the detailed analysis and proposal,
- Jelle

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 21 May 2025 17:12:02 +0000
Resent-Message-ID: <handler.78332.B78332.174784746629349 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174784746629349
          (code B ref 78332); Wed, 21 May 2025 17:12:02 +0000
Received: (at 78332) by debbugs.gnu.org; 21 May 2025 17:11:06 +0000
Received: from localhost ([127.0.0.1]:51557 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uHmy2-0007c4-Pr
	for submit <at> debbugs.gnu.org; Wed, 21 May 2025 13:11:05 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:34840)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uHmxj-0007Ym-OU
 for 78332 <at> debbugs.gnu.org; Wed, 21 May 2025 13:10:50 -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 1uHmxb-003he1-UG; Wed, 21 May 2025 19:10:31 +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=sTdPgXZELyVqqxaOMmNC2+jGaqbCtD0wQgXhoS1UC3E=; b=ZpBYys7W4BqpInxstsIEO10eJz
 hFO7+g7jDsutstsgRhEjDQMq8PM3imqZHEQhTUFHPvQgO3mhgnCxlmJP0thZjn9SoeHubkDEGehVn
 DGgHfa3keyuMoW/Ccrlco48A79gn8buyh2LRy+ceS8e6B3Kg9PtT2d4ZKFbG9K9JDlHu6uh7masjH
 JPsLzas9MDe/vN0DEW/uNxIHrhJHi8cLhv+I39Bi3CIvPxXF98ceZpBizLagYguqDZbUJ9JkLniFy
 KvFqXngYwdlaPE5iau1e+e5tqG3H5UTOhvzLbaFFuN2jbTipkS1+iSP3USoIm1oJr/4aYvMhAFBM8
 a/jZ97QQ==;
Received: from [10.9.9.72] (helo=submission01.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uHmxb-0003Un-8o; Wed, 21 May 2025 19:10:31 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uHmxL-00GQ96-KV; Wed, 21 May 2025 19:10:15 +0200
Date: Wed, 21 May 2025 18:10:13 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="537qryiazqle5ae2"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
X-Spam-Score: -0.7 (/)
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 (-)


--537qryiazqle5ae2
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

Hi all,

Thanks for all the feedback on the initial proposal.

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

A short summary of the changes in this version:

  - Rename staging to integration branch with suggestion of next-master [Zheng Junjie]
  - Add benefit of updated distribution through other package managers [Rutherther]
  - Remove reference to faster initial git pull [Rutherther]
  - Move target annual release to June [Rutherther]
  - Reduce freeze period by breaking it up into stages [Rutherther & others]
      - updates freeze (week 8->12), hard freeze (week 10-12)
  - Identify pacakge sets earlier [Vagrant]
  - Reword template plan to show weeks [Vagrant]
  - Add alternative release target weeks to plan [Vagrant]
  - Identify 'at risk' packages earlier [Greg / Andreas]
  - Make automation a goal of the Release process & release team [Greg / Ekaitz / reza]
  - Reduce the scope of package sets [Jelle / Efraim]
  - Provide more clarity on dealing issues in package sets [Rurtherther]
  - Try to clarify options around RC bugs and package build failures
  - Try to clarify purpose of release project plan as a template

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

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

Steve / Futurile


--537qryiazqle5ae2
Content-Type: text/markdown; charset=utf-8
Content-Disposition: attachment; filename="005-regular-releases.md"
Content-Transfer-Encoding: 8bit

title: Regular and efficient releases
id: 005
status: submitted
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 a 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 for solving the challenges
associated with #1. and #2. above:

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.  Create a
rotating *Release Team* who will organise each release, with the goal of
*automating releases* wherever possible.

The benefits will be:

1. New installations of Guix will be better because installation media and
   manuals will be up to date.  The version of Guix distributed through other
   Linux distributions will also be more recent.
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.

This GCD doesn't attempt to address the challenge that rolling updates aren't
suitable for all users (#3. above).  Adding a slower-moving branch akin to
Nix's stable could be an eventual goal [^2].  However, this GCD aims a single
achievable change by implementng 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 4-5 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 June**.

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 June 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
use-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 and services 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 each successive Release Team would identify key packages which
would receive the most Quality Assurance (QA) attention in that 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
the smallest set required for the initial environment.

Guix would still make all packages and services part of a release (the entire
archive).  Guix teams would be asked to test the parts of the archive that they
look after. But, only Release Critical bugs in the `package sets` would block
a release.

Packages within the `packages sets` must build on the primary architectures
(see definition lower).  As part of the release's QA contributors would be asked
to test these packages.

Where a significant issue is found within a package or service that's part of
a `package set` the Release Team would work to resolve the problem. This could
involve (but isn't limited to) fixing the underlying issue, documenting it as
a limitation in the release notes or promoting an alternative and removing the
broken package from the archive using the Deprecation Policy.

Given the constraints on developers the overal aim of the `package sets` would
be for them to be as small a set of packages and services 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.

The project would like to achieve releases with the minimum amount of effort
by developers.  Consequently, a goal for each Release Team is to find ways to
**automate releases** reducing the toil of successive releases.

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 release
  critical bugs
- 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 Manager 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
Template 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.

Appendix 1: Release Project Template sets out a proposed time-line and major
steps to be undertaken by the project to release a new version of Guix.  It
proposes freezing master while the team focuses on releasing the new version
of Guix. Specifically, a major updates freeze (week 8->12), and a hard freeze
(week 10->12).  The drawback of this approach is that it would slow the
velocity of changes.  During this period contributors would have to keep
updates on team branches, or use an alternative temporary branch.  Each Release
Team will iterate and improve the release process, so it's possible that this
freeze period will be reduced, changed, or removed over successive releases.

There are various improvements that could be made to the release strategy over
time, such as adding an additional slower release cadence.


# Appendix 1: Release Project Template

To show the major steps of a release this release project template is a starting
point.  After each successive release the Release Team will undertake a
retrospective and will document improvements that can be made to the release
process and areas to automate to improve efficiency.

The aim in this template 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 |
| 03 | Package set finalisation |
| 04 | Toolchain and transition freeze |
| 06 | Initial testing |
| 08 | Major updates freeze |
| 08 | Breaking changes to next-master |
| 08 | Ungraft master branch |
| 09 | Bugs and documentation focus |
| 09 | Branch and tag release branch |
| 10 | Testing and hard freeze |
| 10 | Release candidate |
| 12 | Final release target |
| 14 | Alternative release target #1 |
| 16 | Alternative release target #2 |
| +1 | Integration branch merged to master |
| +2 | Release retrospective |
| +2 | Relax - it's done! |

### Nominate a release team (week -5)
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.

### Notify teams of upcoming release (week -4)
Make sure all teams are aware of the upcoming release.  This gives them 4 weeks
to undertake any large transitions or major changes.

### Release project start (week 01)
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.

### Package set finalisation (week 03)
Specify the package sets for this release.  The Release Team will identify all
packages and their inputs so that a full manifest for the release is created.

Packages that do not build for the primary architectures so could be risk of
removal will be identified and developers will be notified following the
Deprecation Policy.

### Toolchain and transition freeze (week 04)
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 are accepted after this point.  Packages
and services in the 'minimal' package set should not be altered.

### Initial testing (week 06)
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

Update the list of packages that's at risk of being deprecated following their
identification in `Package set finalisation`: see if these build failures have
been resolved.

A build failure of a package or service that's in a package set will be marked
as a blocker for the release: Release Team to make determination on response.

### Major updates freeze (week 08)
Major package updates are frozen on 'master' as the focus is on fixing any
blocking packages.  **Security updates still go to 'master'**.

All major changes not related to the release remain on team-branches.

Team branches can still be folded into the release branch as long as changes are
minor package upgrades.

### Breaking changes to an integration branch (week 08)
If there are major breaking changes that must be moved from a team branch an
integration branch will be created. For example `next-master`, this will be
short-lived, existing only until after the release.

The master branch slows down from this week until the release.

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].

### Ungraft master branch (week 08)
Guix master is ungrafted to minimise the difference with users of the release
initial 'guix pull' experience.

### Bugs and documentation focus (week 09)
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.

### Branch and tag release branch (week 09)
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 this point.  All other
changes stay in a team branch or go to an integration branch.  The focus on the
release branch is to stabilise so only resolutions to bugs should be pushed.

### Testing and Hard Freeze (week 10)
Release Crictical (RC) bugs and issues should be solved for the release branch.

Only changes that will fix a non-building package, or a RC bug in a
package/service 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 using the Deprecation Policy.

Call for testing from all developers and users: goal is to test the main
installation use-cases and packages within the `package sets`.

### Release candidate (week 10)
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 release uses these artifacts.  If bugs are found/fixed then
release artifacts are regenerated as needed.

### Final release target (week 12)
Final release is targeted for this date. All planning and work should be done
to this date.

The new release is announced and new release artifacts are published.

If the Release Team determines that release has Release Critical bugs without
workarounds they may move the release to Alternative release target #2.
The concept of buffer weeks to ensure the release balances time and quality
comes from [Fedora's release plan](https://docs.fedoraproject.org/en-US/releases/lifecycle/#_release_dates)

### Alternative release target #1 (week 14)
This release target date may be used if the Release Team determines that there
were Release Critical bugs without workarounds at the Final release target
date.

If the Release Team determines that release has Release Critical bugs without
workarounds at this date they may move the release to Alternative release
target #2.

### Alternative release target #2 (week 16)
This release target date may be used if the Release Team determines that there
are Release Critical bugs without workarounds at one of the previous target 
dates.

If the Release Team determines that the release has Release Critical bugs
without workarounds they may move the release to an alternative date or cancel
the release.

### Integration branch merged to master (release +1 week)
If there were any breaking changes placed onto the integration branch
(e.g. `next-master`) then these can be merged into the `master` branch at this
point.  The master branch then continues as normal.

### Release retrospective (release +2 weeks)
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.

### Relax! (release +2 weeks)
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


--537qryiazqle5ae2--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Efraim Flashner <efraim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 22 May 2025 07:16:01 +0000
Resent-Message-ID: <handler.78332.B78332.17478981315450 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17478981315450
          (code B ref 78332); Thu, 22 May 2025 07:16:01 +0000
Received: (at 78332) by debbugs.gnu.org; 22 May 2025 07:15:31 +0000
Received: from localhost ([127.0.0.1]:59324 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uI09F-0001Pk-M8
	for submit <at> debbugs.gnu.org; Thu, 22 May 2025 03:15:31 -0400
Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:55430)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <efraim.flashner@HIDDEN>)
 id 1uI09B-0001PL-8t
 for 78332 <at> debbugs.gnu.org; Thu, 22 May 2025 03:15:23 -0400
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43cf257158fso58329705e9.2
 for <78332 <at> debbugs.gnu.org>; Thu, 22 May 2025 00:15:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1747898115; x=1748502915; darn=debbugs.gnu.org;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender:from:to
 :cc:subject:date:message-id:reply-to;
 bh=hb8Ghx+qcwe1MtVH431uVB41aFLZUl8lsZCWN7OiGks=;
 b=AqrBU9PmxWNnXax7ZpjBEov2/uSthqCrZXUX7hQ9ZznHmdQNhkqTVXHBuaSgK2wAYh
 G9j741pGI/bYpsBpj0wzlYS/ZIIvnJJCcJtuvdcIVs8VPgfJZ0vE+NVJk8qlDU83X0va
 25tJN4eB2OXvEmjSwcGGivyCxNwPTP8kKQkZwzOwrf8zR17NQTyETo8rYImR8wSOC5KD
 jPzX+nNRsnCQKPX9vzhiUsu47Kyi4zgWdVWLfaSStB7sKVZ+ydJyRMQJCRf5cYcECRER
 TpRnGELBkcqqqJGat4HNdYn6j1XqQQT2BfkyY7erAJAVqxna9eJ1QDhc3+eeH9P81USY
 zFZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1747898115; x=1748502915;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=hb8Ghx+qcwe1MtVH431uVB41aFLZUl8lsZCWN7OiGks=;
 b=UYGhcTxPWSVHCPdky97zeen0xMFTB7kXI/O7RLlkEild1NgGYFuVo3sSgyyKKFOpS7
 wPW47mKZlRhMgbpBL6xgSOKSso923U/5fy3KJ3vp3u9HEHliTLM+6ozNY6//nDnAAmok
 pEpj7WV0LWV/8UfjVwd+/YDv2ueezED5y4O5N0eQnWFo1rep2loUuVqiQ77uXbzpVpXE
 maItTQpFRmYONB6286Burnx9uGQoz1o+tcvbpcZlTA9QhNx4YAs2BFO+nCfgykUvCEgJ
 AajoxA8sguj44DdW1JaI5OL5YaIczgAMiSsNTQyOC00xvyBuXDiw1ui/Z3rh1MNRC3Ie
 TL4w==
X-Forwarded-Encrypted: i=1;
 AJvYcCW6+R66Fh2De3cdKD1+t7bDp+MBdq6f16pucnD9s2CBcOlwzxUsMAJXlDjRjBqSdn+n64a1Xw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxFMS3ThUUrTpYBPGL3x3PFFmXgvVP5GoW4X7RQhApi1bHSO+FB
 U9tMi5rHhTOjRQkT136rjbQgpAF/JifUnWgtYGwjR/HeiexKvKvuO8qNHfxzOfN5
X-Gm-Gg: ASbGncv/+e1gLVOxXOrVOxa0+rWavwDt4x4Kp32YDKtkdvMLU4hAs0ni5jqxpCS1tJo
 5qM/GzeyAc5zarCeJbkhKxlc4tUKjulnu0kPueGXvc4hgGhE43HlwHlazDY0gxer/cQ7JuAwN56
 9Yx8xd1wCojo2ruw9Xf6bONjJBO1q0QqZLcyvk3UOlns3C55QJtPuwdua/riMomYq5VjBKvwKbO
 6PpqfPsXgnU6TJoWAobimYkx//yNI7Onl4c6pbtIxcD8e4gJAXWFMHzvv06M61QzwwNxmd6+7qO
 K0Gdr0KGxkE3zpnfctVs49+oqzuY3fHmW7AzrhR4idp8RhIwkC4=
X-Google-Smtp-Source: AGHT+IFpy3/WJtBfEW4ehJDAJbn8psUd8s2JQ4+nV4ZHbjHyko8jcpZFhLQOl4MSndjkmb8ms7JyWQ==
X-Received: by 2002:a05:600c:3d0b:b0:43c:f513:9591 with SMTP id
 5b1f17b1804b1-442feff05b7mr224381045e9.14.1747898114400; 
 Thu, 22 May 2025 00:15:14 -0700 (PDT)
Received: from localhost ([141.226.12.183]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-447f6b29619sm100022455e9.7.2025.05.22.00.15.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 22 May 2025 00:15:13 -0700 (PDT)
Date: Thu, 22 May 2025 10:15:12 +0300
From: Efraim Flashner <efraim@HIDDEN>
Message-ID: <aC7PAHZ9lHox0scM@3900XT>
Mail-Followup-To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN,
 78332 <at> debbugs.gnu.org
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="RAJiTbFY4KtR67ea"
Content-Disposition: inline
In-Reply-To: <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
X-PGP-Key-ID: 0x41AAE7DCCA3D8351
X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc
X-PGP-Fingerprint: A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
X-Spam-Score: 0.0 (/)
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 (-)


--RAJiTbFY4KtR67ea
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 21, 2025 at 06:10:13PM +0100, Steve George wrote:
> Hi all,
>=20
> Thanks for all the feedback on the initial proposal.
>=20
> I've integrated it into the GCD so attached is a revised version. I think=
 it's ready to move to the Discussion Period (minimum 30 days from today).
>=20
> A short summary of the changes in this version:
>=20
>   - Rename staging to integration branch with suggestion of next-master [=
Zheng Junjie]
>   - Add benefit of updated distribution through other package managers [R=
utherther]
>   - Remove reference to faster initial git pull [Rutherther]
>   - Move target annual release to June [Rutherther]
>   - Reduce freeze period by breaking it up into stages [Rutherther & othe=
rs]
>       - updates freeze (week 8->12), hard freeze (week 10-12)
>   - Identify pacakge sets earlier [Vagrant]
>   - Reword template plan to show weeks [Vagrant]
>   - Add alternative release target weeks to plan [Vagrant]
>   - Identify 'at risk' packages earlier [Greg / Andreas]
>   - Make automation a goal of the Release process & release team [Greg / =
Ekaitz / reza]
>   - Reduce the scope of package sets [Jelle / Efraim]
>   - Provide more clarity on dealing issues in package sets [Rurtherther]
>   - Try to clarify options around RC bugs and package build failures
>   - Try to clarify purpose of release project plan as a template
>=20
> I would love to know if this improves things from any feedback that you g=
ave?
>=20
> As well as any other thoughts, comments or ideas on how to improve this G=
CD!
>=20
> Steve / Futurile
>=20

> title: Regular and efficient releases
> id: 005
> status: submitted
> 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
> ---
>=20
> # Summary
>=20
> Guix doesn't have a 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.
>=20
> 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.
>=20
> The weaknesses in this release strategy are:
>=20
> 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.
>=20
> This GCD proposes the following combined solution for solving the challen=
ges
> associated with #1. and #2. above:
>=20
> 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.  Create a
> rotating *Release Team* who will organise each release, with the goal of
> *automating releases* wherever possible.
>=20
> The benefits will be:
>=20
> 1. New installations of Guix will be better because installation media and
>    manuals will be up to date.  The version of Guix distributed through o=
ther
>    Linux distributions will also be more recent.
> 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.
>=20
> This GCD doesn't attempt to address the challenge that rolling updates ar=
en't
> suitable for all users (#3. above).  Adding a slower-moving branch akin to
> Nix's stable could be an eventual goal [^2].  However, this GCD aims a si=
ngle
> achievable change by implementng regular releases which is a substantial =
change
> that would be a big improvement for our users.
>=20
>=20
> # Motivation
>=20
> 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).
>=20
> 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:
>=20
> - 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 4-5 months of package
> updates freeze before the release while bugs are ironed out.
>=20
> 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.
>=20
> 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.

I think the guix pull issue isn't related to the release cadence but due
to the size of the git repo and the number of authenticated commits.
There's definitely work to be done to speed up the first guix pull, but
I don't think it belongs in this GCD.  How about:

A specific issue caused by irregular releases is the time-bombs which
exist in a number of packages and their test suites.  People installing
=66rom a release tarball often find that important packages fail to build,
making their initial attempts to use Guix unnecessarily hard.  There are
also the issues of disappearing upstream sources and the need to keep
old substitutes on our servers.

People using Guix on a foreign distro also often use the guix-daemon as
packaged by that distribution.  This means that any daemon related
changes, such as a change in the compression algorithm of the
substitutes or changing substitute servers can only be considered
complete after the guix-daemon has been updated in those distributions
as well.

> 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.
>=20
> 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.  =
This is
> why Nix (May/November) and Ubuntu (April/October) align their releases.
>=20
> 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 =
could
> be a future goal [^5].
>=20
> This GCD proposes an annual release cycle, with releases **in June**.
>=20
> 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 June 2026.
>=20
>=20
> ## Package Sets
>=20
> 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.
>=20
> Many other distributions focus attention on the critical parts of their
> repository by identifying those packages that are required for a particul=
ar
> use-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.
>=20
> Guix is both a package manager that can be hosted on other Linux distribu=
tions,
> and a Linux distribution.  Limiting the range of packages and services th=
at
> receive attention is consequently more complicated.  Guix already has man=
ifests
> to track which packages are used by [Guix System's installer](https://git=
=2Esavannah.gnu.org/cgit/guix.git/tree/etc/manifests/release.scm)
> , so this proposal extends that concept.
>=20
> For this proposal each successive Release Team would identify key package=
s which
> would receive the most Quality Assurance (QA) attention in that release.
>=20
> The package sets would be:
>=20
> * 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
> the smallest set required for the initial environment.
>=20
> Guix would still make all packages and services part of a release (the en=
tire
> archive).  Guix teams would be asked to test the parts of the archive tha=
t they
> look after. But, only Release Critical bugs in the `package sets` would b=
lock
> a release.
>=20
> Packages within the `packages sets` must build on the primary architectur=
es
> (see definition lower).  As part of the release's QA contributors would b=
e asked
> to test these packages.
>=20
> Where a significant issue is found within a package or service that's par=
t of
> a `package set` the Release Team would work to resolve the problem. This =
could
> involve (but isn't limited to) fixing the underlying issue, documenting i=
t as
> a limitation in the release notes or promoting an alternative and removin=
g the
> broken package from the archive using the Deprecation Policy.
>=20
> Given the constraints on developers the overal aim of the `package sets` =
would
> be for them to be as small a set of packages and services as reasonably p=
ossible.
> It would mean that developers could focus on the critical packages and se=
rvices
> during a release.  As an example, this would mean that a major issue in t=
he
> Linux kernel could block a release, but not an issue in a game.
>=20
>=20
> ## Platforms and Architecture tiers
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=20
> - 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
>=20
> - 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.
>=20
> 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.
>=20
>=20
> ## Release artifacts
>=20
> Using the primary architecture tier and the package sets would involve cr=
eating
> the following release artifacts:
>=20
> - GNU Guix System ISO image
> - GNU Guix System QCOW2 image
> - GNU Guix installer
>=20
> 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.
>=20
>=20
> ## Release team and project
>=20
> 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.
>=20
> The project would like to achieve releases with the minimum amount of eff=
ort
> by developers.  Consequently, a goal for each Release Team is to find way=
s to
> **automate releases** reducing the toil of successive releases.
>=20
> 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 relea=
se
>   critical bugs
> - 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**
>=20
> The Release Manager 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 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.
>=20
> 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 suffici=
ent
> interest.
>=20
> The final release team is:
>=20
> - a new Release Manager
> - a returning Release Manager
> - up to 4 other members, one of whom acts as the Release Advocate
>=20
> 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
> Template for an example.
>=20
> 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=
=2Egnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
> .
>=20
>=20
> # Cost of Reverting
>=20
> 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.
>=20
> 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.
>=20
>=20
> # Drawbacks and open issues
>=20
> 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=
=2E  If
> that's the case we would revert back to irregular releases.
>=20
> Appendix 1: Release Project Template sets out a proposed time-line and ma=
jor
> steps to be undertaken by the project to release a new version of Guix.  =
It
> proposes freezing master while the team focuses on releasing the new vers=
ion
> of Guix. Specifically, a major updates freeze (week 8->12), and a hard fr=
eeze
> (week 10->12).  The drawback of this approach is that it would slow the
> velocity of changes.  During this period contributors would have to keep
> updates on team branches, or use an alternative temporary branch.  Each R=
elease
> Team will iterate and improve the release process, so it's possible that =
this
> freeze period will be reduced, changed, or removed over successive releas=
es.
>=20
> There are various improvements that could be made to the release strategy=
 over
> time, such as adding an additional slower release cadence.
>=20
>=20
> # Appendix 1: Release Project Template
>=20
> To show the major steps of a release this release project template is a s=
tarting
> point.  After each successive release the Release Team will undertake a
> retrospective and will document improvements that can be made to the rele=
ase
> process and areas to automate to improve efficiency.
>=20
> The aim in this template is for a 12 week active release project, with th=
e first
> one using 16 weeks in total to give teams time to prepare.
>=20
> The current outline builds from our current [release document](https://gi=
t.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org)
>=20
> | Week of Project | Event |
> | --- | --- |
> | -5 | Nominate a release team |
> | -4 | Notify teams of upcoming release |
> | 01 | Release project start |
> | 03 | Package set finalisation |
> | 04 | Toolchain and transition freeze |
> | 06 | Initial testing |
> | 08 | Major updates freeze |
> | 08 | Breaking changes to next-master |
> | 08 | Ungraft master branch |
> | 09 | Bugs and documentation focus |
> | 09 | Branch and tag release branch |
> | 10 | Testing and hard freeze |
> | 10 | Release candidate |
> | 12 | Final release target |
> | 14 | Alternative release target #1 |
> | 16 | Alternative release target #2 |
> | +1 | Integration branch merged to master |
> | +2 | Release retrospective |
> | +2 | Relax - it's done! |
>=20
> ### Nominate a release team (week -5)
> 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.
>=20
> ### Notify teams of upcoming release (week -4)
> Make sure all teams are aware of the upcoming release.  This gives them 4=
 weeks
> to undertake any large transitions or major changes.
>=20
> ### Release project start (week 01)
> 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.
>=20
> ### Package set finalisation (week 03)
> Specify the package sets for this release.  The Release Team will identif=
y all
> packages and their inputs so that a full manifest for the release is crea=
ted.
>=20
> Packages that do not build for the primary architectures so could be risk=
 of
> removal will be identified and developers will be notified following the
> Deprecation Policy.
>=20
> ### Toolchain and transition freeze (week 04)
> 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.
>=20
> 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.
>=20
> No alterations to the Guix daemon are accepted after this point.  Packages
> and services in the 'minimal' package set should not be altered.
>=20
> ### Initial testing (week 06)
> An initial testing sprint to look at packages, services, install media and
> upgrade testing. This should identify:
>=20
> * 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
>=20
> Update the list of packages that's at risk of being deprecated following =
their
> identification in `Package set finalisation`: see if these build failures=
 have
> been resolved.
>=20
> A build failure of a package or service that's in a package set will be m=
arked
> as a blocker for the release: Release Team to make determination on respo=
nse.
>=20
> ### Major updates freeze (week 08)
> Major package updates are frozen on 'master' as the focus is on fixing any
> blocking packages.  **Security updates still go to 'master'**.
>=20
> All major changes not related to the release remain on team-branches.
>=20
> Team branches can still be folded into the release branch as long as chan=
ges are
> minor package upgrades.
>=20
> ### Breaking changes to an integration branch (week 08)
> If there are major breaking changes that must be moved from a team branch=
 an
> integration branch will be created. For example `next-master`, this will =
be
> short-lived, existing only until after the release.
>=20
> The master branch slows down from this week until the release.
>=20
> 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].
>=20
> ### Ungraft master branch (week 08)
> Guix master is ungrafted to minimise the difference with users of the rel=
ease
> initial 'guix pull' experience.
>=20
> ### Bugs and documentation focus (week 09)
> 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.
>=20
> ### Branch and tag release branch (week 09)
> The master branch is tagged and a new release branch is created.
>=20
> * master branch: security only.
> * release branch: security updates as normal. Only RC blocking bugs.
>=20
> Only security updates go to the master branch from this point.  All other
> changes stay in a team branch or go to an integration branch.  The focus =
on the
> release branch is to stabilise so only resolutions to bugs should be push=
ed.

I'm still not entirely sure about the branches.
release-branch: security, RC bugs and where the release is prepared
master branch: security only
next-master: everything that would've gone to master

Looking at some of the other bits of appendix 1 I'm better able to wrap
my head around something like:

release-branch: where the release is prepared, with merges from master
master branch: security and RC bugs
next-master: everything that would've gone to master

> ### Testing and Hard Freeze (week 10)
> Release Crictical (RC) bugs and issues should be solved for the release b=
ranch.
>=20
> Only changes that will fix a non-building package, or a RC bug in a
> package/service are allowed.  Ideally avoid new upstream versions, but it=
's
> acceptable to use a new minor upstream version to solve a bug.
>=20
> Any non-building packages are removed using the Deprecation Policy.

perhaps add: As always, packages can be un-deprecated at a later date.

> Call for testing from all developers and users: goal is to test the main
> installation use-cases and packages within the `package sets`.
>=20
> ### Release candidate (week 10)
> 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 release uses these artifacts.  If bugs are found/fixe=
d then
> release artifacts are regenerated as needed.
>=20
> ### Final release target (week 12)
> Final release is targeted for this date. All planning and work should be =
done
> to this date.
>=20
> The new release is announced and new release artifacts are published.
>=20
> If the Release Team determines that release has Release Critical bugs wit=
hout
> workarounds they may move the release to Alternative release target #2.
> The concept of buffer weeks to ensure the release balances time and quali=
ty
> comes from [Fedora's release plan](https://docs.fedoraproject.org/en-US/r=
eleases/lifecycle/#_release_dates)
>=20
> ### Alternative release target #1 (week 14)
> This release target date may be used if the Release Team determines that =
there
> were Release Critical bugs without workarounds at the Final release target
> date.
>=20
> If the Release Team determines that release has Release Critical bugs wit=
hout
> workarounds at this date they may move the release to Alternative release
> target #2.
>=20
> ### Alternative release target #2 (week 16)
> This release target date may be used if the Release Team determines that =
there
> are Release Critical bugs without workarounds at one of the previous targ=
et=20
> dates.
>=20
> If the Release Team determines that the release has Release Critical bugs
> without workarounds they may move the release to an alternative date or c=
ancel
> the release.

I do like that there's a built-in "release or pass" time period where we
can punt on the release and try again at another date.  We don't want
the possibility of a freeze dragging on for months.

> ### Integration branch merged to master (release +1 week)
> If there were any breaking changes placed onto the integration branch
> (e.g. `next-master`) then these can be merged into the `master` branch at=
 this
> point.  The master branch then continues as normal.
>=20
> ### Release retrospective (release +2 weeks)
> 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.
>=20
> ### Relax! (release +2 weeks)
> 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.
>=20
> ---
>=20
> [^1]: https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/
>=20
> [^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.
>=20
> [^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).
>=20
> [^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.
>=20
> [^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.
>=20
> [^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.
>=20
> [^7]: https://github.com/NixOS/rfcs/blob/master/rfcs/0085-nixos-release-s=
tablization.md
>=20


--=20
Efraim Flashner   <efraim@HIDDEN>   =D7=90=D7=A4=D7=A8=D7=99=D7=9D =
=D7=A4=D7=9C=D7=A9=D7=A0=D7=A8
GPG key =3D A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

--RAJiTbFY4KtR67ea
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmguzvwACgkQQarn3Mo9
g1EwqA//elN6mHe1dECbhI1e9I+hGj08d62WiFL2uC+ZlCoLk0B6/orbFgeurP/5
xrAJEMEyRrhgSh3vBn9JvOzLbToxsvnYX5S4+E9/CnqNBUYJdoMkqXEQXti2RSMM
sY+PmOHym4cjWb3HKmP8aA2ja++vuBu0aahMjOL6tj3Bas9QOOhBrG1ZsW7qAiIP
8GjlIwgWsZ5zv9/Kwybk6d2dDiKYzGTucLhSQ4Qjuc9csTMbPwpuhGuvxQP/6btE
BQYvFf07GqMUjHjArt0xFKrB41s/zWkgIjTUPWvdOEcmj0rLo0t4a5NIpO//3rIE
B6AAYL8dyn548MDFlEZ4yUobOzvijOHM8gOrgLgoVRnH7UWghLd5QLVFkylo/s6p
v/zTY7wgwacNZEB00aia+x03jT4vU8NLZ3y5swgR+WPW6kpEWSjL3g427lNQ2NBo
yAKAj2nYjlKzIqt7JxSj7fkySxgO7bVoW98jswnRg8mI+kNJT2GcQOODgDejZ+P3
CyLhyulxqHLQ3PNoGx9sE5Ea4koDpFggXKmoKxtUxETXjc+2RPenG9Yckce3nL/y
f8PLddm6WlUkCJeQjUwHbpJsC52XgjlC4AfKRzzbNhweTkZjXxcjMM35Q0HowvwJ
V7ikHgaNdsNM+PPR+1D60mQ5ZdI3IMN8oQ4/hp7WEUUJh7y8dX8=
=fYPZ
-----END PGP SIGNATURE-----

--RAJiTbFY4KtR67ea--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: =?UTF-8?Q?No=C3=A9?= Lopez <noelopez@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 22 May 2025 08:57:06 +0000
Resent-Message-ID: <handler.78332.B78332.174790416428368 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174790416428368
          (code B ref 78332); Thu, 22 May 2025 08:57:06 +0000
Received: (at 78332) by debbugs.gnu.org; 22 May 2025 08:56:04 +0000
Received: from localhost ([127.0.0.1]:59776 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uI1iY-0007N9-Or
	for submit <at> debbugs.gnu.org; Thu, 22 May 2025 04:56:03 -0400
Received: from smtp5-g21.free.fr ([2a01:e0c:1:1599::14]:47646)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <noelopez@HIDDEN>) id 1uI1iR-0007Mo-Uc
 for 78332 <at> debbugs.gnu.org; Thu, 22 May 2025 04:55:55 -0400
Received: from localhost (unknown [IPv6:2a01:e0a:990:a960:7ef2:8027:a4aa:1083])
 (Authenticated sender: noelopez@HIDDEN)
 by smtp5-g21.free.fr (Postfix) with ESMTPSA id A2D1060140;
 Thu, 22 May 2025 10:55:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr;
 s=smtp-20201208; t=1747904149;
 bh=Mwfv1VShQwbk5qbKm63sxvKoIYOI0Kl9ltfESu2oYe8=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=r4AZOtM5N6eqOSZ08KkqHpfrFN0xUNZdHhH3G+Qx/goMmsL6n0yRemWVz8k7jmwOV
 iEGXpfo1PJphwSshONDat8jEim8/ncbinnjDF4XkLFiHnZbQo+2VMfIV7G0YXUc058
 AR6iaVr/oo9GjzyTTBwUfbxYkOZ4fKhf+uIvQ5IG+A7fdjsPHmofqmhL+9q9OdHxdS
 vIRKK2C1t2pEU8rakfRkOj9LUxt3VcoJGaezcxVAcoGx0aRUBK/H3xtkD512hwPeaA
 DEwv84i7A/Nkc1H33e53If+xePWXHsTYkLKMgWY0c0qkhv/aMUjjXeevw1iJhDaZIV
 1zCgZfhY/83Mg==
From: =?UTF-8?Q?No=C3=A9?= Lopez <noelopez@HIDDEN>
In-Reply-To: <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
Date: Thu, 22 May 2025 10:55:42 +0200
Message-ID: <87ldqpxbw1.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Score: -0.0 (/)
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; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Steve George <steve@HIDDEN> writes:

> Hi all,
>
> Thanks for all the feedback on the initial proposal.
>
> I've integrated it into the GCD so attached is a revised version. I think=
 it's ready to move to the Discussion Period (minimum 30 days from today).
>
> A short summary of the changes in this version:
>
>   - Rename staging to integration branch with suggestion of next-master [=
Zheng Junjie]
>   - Add benefit of updated distribution through other package managers [R=
utherther]
>   - Remove reference to faster initial git pull [Rutherther]
>   - Move target annual release to June [Rutherther]
>   - Reduce freeze period by breaking it up into stages [Rutherther & othe=
rs]
>       - updates freeze (week 8->12), hard freeze (week 10-12)
>   - Identify pacakge sets earlier [Vagrant]
>   - Reword template plan to show weeks [Vagrant]
>   - Add alternative release target weeks to plan [Vagrant]
>   - Identify 'at risk' packages earlier [Greg / Andreas]
>   - Make automation a goal of the Release process & release team [Greg / =
Ekaitz / reza]
>   - Reduce the scope of package sets [Jelle / Efraim]
>   - Provide more clarity on dealing issues in package sets [Rurtherther]
>   - Try to clarify options around RC bugs and package build failures
>   - Try to clarify purpose of release project plan as a template
>
> I would love to know if this improves things from any feedback that you g=
ave?
>
> As well as any other thoughts, comments or ideas on how to improve this G=
CD!
>

Hi Steve,

Thanks for this great GCD!

I assume the GCD would end after June, so will there be a july/august
release or will we have to wait for a year?

Few comments below.

Have a great day,
No=C3=A9

> Steve / Futurile
>
> title: Regular and efficient releases
> id: 005
> status: submitted
> 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 a 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 for solving the challen=
ges
> associated with #1. and #2. above:
>
> 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.  Create a
> rotating *Release Team* who will organise each release, with the goal of
> *automating releases* wherever possible.
>
> The benefits will be:
>
> 1. New installations of Guix will be better because installation media and
>    manuals will be up to date.  The version of Guix distributed through o=
ther
>    Linux distributions will also be more recent.
> 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.
>
> This GCD doesn't attempt to address the challenge that rolling updates ar=
en't
> suitable for all users (#3. above).  Adding a slower-moving branch akin to
> Nix's stable could be an eventual goal [^2].  However, this GCD aims a si=
ngle
> achievable change by implementng regular releases which is a
> substantial change

implementing*

> 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)

No space between ] and (

> .  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 4-5 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.
>
> 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.  =
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/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 =
could
> be a future goal [^5].
>
> This GCD proposes an annual release cycle, with releases **in June**.
>
> 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 June 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
> use-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 and services th=
at
> receive attention is consequently more complicated.  Guix already has man=
ifests
> 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 each successive Release Team would identify key package=
s which
> would receive the most Quality Assurance (QA) attention in that 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
> the smallest set required for the initial environment.
>
> Guix would still make all packages and services part of a release (the en=
tire
> archive).  Guix teams would be asked to test the parts of the archive tha=
t they
> look after. But, only Release Critical bugs in the `package sets` would b=
lock
> a release.
>
> Packages within the `packages sets` must build on the primary architectur=
es
> (see definition lower).  As part of the release's QA contributors would b=
e asked
> to test these packages.
>
> Where a significant issue is found within a package or service that's par=
t of
> a `package set` the Release Team would work to resolve the problem. This =
could
> involve (but isn't limited to) fixing the underlying issue, documenting i=
t as
> a limitation in the release notes or promoting an alternative and removin=
g the
> broken package from the archive using the Deprecation Policy.
>
> Given the constraints on developers the overal aim of the `package sets` =
would
> be for them to be as small a set of packages and services as reasonably p=
ossible.
> It would mean that developers could focus on the critical packages and se=
rvices
> during a release.  As an example, this would mean that a major issue in t=
he
> 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 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.
>
> The project would like to achieve releases with the minimum amount of eff=
ort
> by developers.  Consequently, a goal for each Release Team is to find way=
s to
> **automate releases** reducing the toil of successive releases.
>
> 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 relea=
se
>   critical bugs
> - 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 Manager 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 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
> 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
>

What happens in 6 years when there are no new release managers
available, can we reuse someone?

> 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
> Template 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.
>
> Appendix 1: Release Project Template sets out a proposed time-line and ma=
jor
> steps to be undertaken by the project to release a new version of Guix.  =
It
> proposes freezing master while the team focuses on releasing the new vers=
ion
> of Guix. Specifically, a major updates freeze (week 8->12), and a hard fr=
eeze
> (week 10->12).  The drawback of this approach is that it would slow the
> velocity of changes.  During this period contributors would have to keep
> updates on team branches, or use an alternative temporary branch.  Each R=
elease
> Team will iterate and improve the release process, so it's possible that =
this
> freeze period will be reduced, changed, or removed over successive releas=
es.
>
> There are various improvements that could be made to the release strategy=
 over
> time, such as adding an additional slower release cadence.
>
>
> # Appendix 1: Release Project Template
>
> To show the major steps of a release this release project template is a s=
tarting
> point.  After each successive release the Release Team will undertake a
> retrospective and will document improvements that can be made to the rele=
ase
> process and areas to automate to improve efficiency.
>
> The aim in this template is for a 12 week active release project, with th=
e 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 |
> | 03 | Package set finalisation |
> | 04 | Toolchain and transition freeze |
> | 06 | Initial testing |
> | 08 | Major updates freeze |
> | 08 | Breaking changes to next-master |
> | 08 | Ungraft master branch |
> | 09 | Bugs and documentation focus |
> | 09 | Branch and tag release branch |
> | 10 | Testing and hard freeze |
> | 10 | Release candidate |
> | 12 | Final release target |
> | 14 | Alternative release target #1 |
> | 16 | Alternative release target #2 |
> | +1 | Integration branch merged to master |
> | +2 | Release retrospective |
> | +2 | Relax - it's done! |
>
> ### Nominate a release team (week -5)
> 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.
>
> ### Notify teams of upcoming release (week -4)
> Make sure all teams are aware of the upcoming release.  This gives them 4=
 weeks
> to undertake any large transitions or major changes.
>
> ### Release project start (week 01)
> 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.
>
> ### Package set finalisation (week 03)
> Specify the package sets for this release.  The Release Team will identif=
y all
> packages and their inputs so that a full manifest for the release is crea=
ted.
>
> Packages that do not build for the primary architectures so could be risk=
 of
> removal will be identified and developers will be notified following the
> Deprecation Policy.
>
> ### Toolchain and transition freeze (week 04)
> 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.
>
> 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 are accepted after this point.  Packages
> and services in the 'minimal' package set should not be altered.
>
> ### Initial testing (week 06)
> 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
>
> Update the list of packages that's at risk of being deprecated following =
their
> identification in `Package set finalisation`: see if these build failures=
 have
> been resolved.
>
> A build failure of a package or service that's in a package set will be m=
arked
> as a blocker for the release: Release Team to make determination on respo=
nse.
>
> ### Major updates freeze (week 08)
> Major package updates are frozen on 'master' as the focus is on fixing any
> blocking packages.  **Security updates still go to 'master'**.
>
> All major changes not related to the release remain on team-branches.
>
> Team branches can still be folded into the release branch as long as chan=
ges are
> minor package upgrades.
>
> ### Breaking changes to an integration branch (week 08)
> If there are major breaking changes that must be moved from a team branch=
 an
> integration branch will be created. For example `next-master`, this will =
be
> short-lived, existing only until after the release.
>
> The master branch slows down from this week until the release.
>
> 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].
>
> ### Ungraft master branch (week 08)
> Guix master is ungrafted to minimise the difference with users of the rel=
ease
> initial 'guix pull' experience.
>
> ### Bugs and documentation focus (week 09)
> 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.
>
> ### Branch and tag release branch (week 09)
> 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 this point.  All other
> changes stay in a team branch or go to an integration branch.  The focus =
on the
> release branch is to stabilise so only resolutions to bugs should be push=
ed.
>
> ### Testing and Hard Freeze (week 10)
> Release Crictical (RC) bugs and issues should be solved for the release b=
ranch.
>
> Only changes that will fix a non-building package, or a RC bug in a
> package/service 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 using the Deprecation Policy.
>
> Call for testing from all developers and users: goal is to test the main
> installation use-cases and packages within the `package sets`.
>
> ### Release candidate (week 10)
> 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 release uses these artifacts.  If bugs are found/fixe=
d then
> release artifacts are regenerated as needed.
>
> ### Final release target (week 12)
> Final release is targeted for this date. All planning and work should be =
done
> to this date.
>
> The new release is announced and new release artifacts are published.
>
> If the Release Team determines that release has Release Critical bugs wit=
hout
> workarounds they may move the release to Alternative release target #2.
> The concept of buffer weeks to ensure the release balances time and quali=
ty
> comes from [Fedora's release plan](https://docs.fedoraproject.org/en-US/r=
eleases/lifecycle/#_release_dates)
>
> ### Alternative release target #1 (week 14)
> This release target date may be used if the Release Team determines that =
there
> were Release Critical bugs without workarounds at the Final release target
> date.
>
> If the Release Team determines that release has Release Critical bugs wit=
hout
> workarounds at this date they may move the release to Alternative release
> target #2.
>
> ### Alternative release target #2 (week 16)
> This release target date may be used if the Release Team determines that =
there
> are Release Critical bugs without workarounds at one of the previous targ=
et=20
> dates.
>
> If the Release Team determines that the release has Release Critical bugs
> without workarounds they may move the release to an alternative date or c=
ancel
> the release.
>
> ### Integration branch merged to master (release +1 week)
> If there were any breaking changes placed onto the integration branch
> (e.g. `next-master`) then these can be merged into the `master` branch at=
 this
> point.  The master branch then continues as normal.
>
> ### Release retrospective (release +2 weeks)
> 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.
>
> ### Relax! (release +2 weeks)
> 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

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQHFBAEBCAAvFiEEXVTPJVeyOOiNwYCiLSIyQQq3QEMFAmgu5o8RHG5vZWxvcGV6
QGZyZWUuZnIACgkQLSIyQQq3QEPTqwv9Gq0/euKnA1bZmx5VQDiTjlb0sUkKWXsM
sie5i/72F+t9p9MpkDgBlCYhUpJh98RW5FbqEY0pvaju260eMUQLZK1Daap0a9AV
aWKkIGyEF9aHppbHAtA3DImwpJtMGqnZLed8kfhbLCfJ3HmHQfj+8MB09LnC+i68
Q2N083RcwlyUHl7gbTmpZyI6gJ6t9qnTGNgW161yUqtNWxmtym81Z/e3nWHxViQM
eXRCMO+79vcIGL+ZIKPkS4zl34wz7nQNEZWchIM535pCrFxOT+1FQv0kBARhLpDl
BxpN9hFB6jVLGm62OnDDH+xoDR9bGRqshx7aBvIydgpGGwtJRe9t6sJXMJ79ggIo
B4OSfjnVkdUvBSWw/Z4kZZ5zZ9D4fBUce9uew1L4Ii/6D9ko9EcLB1kBAEMiTgCv
welPitUZ0HO6NVzHMoWd5IaOV2idN2V8Et/I2UXMiHtepf2yYodzIpaz2jtaQO2y
4tdTWcl5zlH/tyx2cDMSgVUY50ym7Oaq
=lxSX
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 22 May 2025 09:12:01 +0000
Resent-Message-ID: <handler.78332.B78332.17479051174531 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17479051174531
          (code B ref 78332); Thu, 22 May 2025 09:12:01 +0000
Received: (at 78332) by debbugs.gnu.org; 22 May 2025 09:11:57 +0000
Received: from localhost ([127.0.0.1]:59967 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uI1y0-0001B1-BQ
	for submit <at> debbugs.gnu.org; Thu, 22 May 2025 05:11:56 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:35316)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uI1xx-0001Ah-8D
 for 78332 <at> debbugs.gnu.org; Thu, 22 May 2025 05:11:53 -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 1uI1xq-005QGZ-Ul
 for 78332 <at> debbugs.gnu.org; Thu, 22 May 2025 11:11:46 +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:To:From:Date;
 bh=+1oUSMck6LUm2oJoMPQZT95e/nEDkotC7PNljMRLeWY=; b=v9985M1IXNgTwr0L6SHmWeoUaK
 LtyGITrMZD2xsQFDz75V26ct8aKXNSeH4Be2cs++i18fBNhv1tX15BMHvvb2/eEEskPYx0yXWFGbu
 cU6jP4GooHb2Jxbim4vuxcaXzHS+3om6Y9hJ0Bm2Z1aw429Pgdhcze8xSNET1tYzNAvPmrLCl/lbM
 vXJnOnxQrHqumXdg3lcezGjOxx+wV21CBk3+dum7jcWBQPULh+Y3ohrb4XcU9smNzHWZ8rxta+lZ5
 KMGInts3407n74PrFQAn1g5RcyJmjXbwbNONUTs5A/j4O9A9hZIIMBXa1XX5F2CuYFQZjnrhta5YR
 QFUiTJxw==;
Received: from [10.9.9.73] (helo=submission02.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uI1xq-0007pu-G1; Thu, 22 May 2025 11:11:46 +0200
Received: by submission02.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uI1xk-005bkw-0M; Thu, 22 May 2025 11:11:40 +0200
Date: Thu, 22 May 2025 10:11:38 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <6ihlri4vbh5wyes72lted4aog4rgsvknwfd2mmob7jocfvdna3@eopgziwcqu6g>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <aC7PAHZ9lHox0scM@3900XT>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="v444wg3dxcxv7rn6"
Content-Disposition: inline
In-Reply-To: <aC7PAHZ9lHox0scM@3900XT>
X-Spam-Score: -0.7 (/)
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 (-)


--v444wg3dxcxv7rn6
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 (submitted)
MIME-Version: 1.0

On 22 May, Efraim Flashner wrote:
> On Wed, May 21, 2025 at 06:10:13PM +0100, Steve George wrote:
(...)
> > A specific issue caused by irregular releases is that new users/install=
s face a
> > significant first "guix pull". This provides a poor initial user experi=
ence,
> > and in some cases may even deter users [^4]. Additionally, it requires =
the
> > project to keep old substitutes on our servers.
>=20
> I think the guix pull issue isn't related to the release cadence but due
> to the size of the git repo and the number of authenticated commits.
> There's definitely work to be done to speed up the first guix pull, but
> I don't think it belongs in this GCD.  How about:
>=20
> A specific issue caused by irregular releases is the time-bombs which
> exist in a number of packages and their test suites.  People installing
> from a release tarball often find that important packages fail to build,
> making their initial attempts to use Guix unnecessarily hard.  There are
> also the issues of disappearing upstream sources and the need to keep
> old substitutes on our servers.
>=20
> People using Guix on a foreign distro also often use the guix-daemon as
> packaged by that distribution.  This means that any daemon related
> changes, such as a change in the compression algorithm of the
> substitutes or changing substitute servers can only be considered
> complete after the guix-daemon has been updated in those distributions
> as well.
(...)

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

(...)
> > ### Branch and tag release branch (week 09)
> > The master branch is tagged and a new release branch is created.
> >=20
> > * master branch: security only.
> > * release branch: security updates as normal. Only RC blocking bugs.
> >=20
> > Only security updates go to the master branch from this point.  All oth=
er
> > changes stay in a team branch or go to an integration branch.  The focu=
s on the
> > release branch is to stabilise so only resolutions to bugs should be pu=
shed.
>=20
> I'm still not entirely sure about the branches.
> release-branch: security, RC bugs and where the release is prepared
> master branch: security only
> next-master: everything that would've gone to master
>=20
> Looking at some of the other bits of appendix 1 I'm better able to wrap
> my head around something like:
>=20
> release-branch: where the release is prepared, with merges from master
> master branch: security and RC bugs
> next-master: everything that would've gone to master

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

So, either:

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

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

(...)
> > ### Testing and Hard Freeze (week 10)
> > Release Crictical (RC) bugs and issues should be solved for the release=
 branch.
> >=20
> > Only changes that will fix a non-building package, or a RC bug in a
> > package/service are allowed.  Ideally avoid new upstream versions, but =
it's
> > acceptable to use a new minor upstream version to solve a bug.
> >=20
> > Any non-building packages are removed using the Deprecation Policy.
>=20
> perhaps add: As always, packages can be un-deprecated at a later date.
>=20

Done.

> > ### Alternative release target #2 (week 16)
> > This release target date may be used if the Release Team determines tha=
t there
> > are Release Critical bugs without workarounds at one of the previous ta=
rget=20
> > dates.
> >=20
> > If the Release Team determines that the release has Release Critical bu=
gs
> > without workarounds they may move the release to an alternative date or=
 cancel
> > the release.
>=20
> I do like that there's a built-in "release or pass" time period where we
> can punt on the release and try again at another date.  We don't want
> the possibility of a freeze dragging on for months.
>=20

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

Steve / Futurile


--v444wg3dxcxv7rn6
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQIB6x23+hDA21fWHn1HUoW3O5vpwUCaC7qSQAKCRD1HUoW3O5v
p7UqAQCLJ8ikywJG9MdPKs8jrrkiWQMq0K3PgeSiYdkguuOU2gD+M3IuAkd3fmrq
UENk1ee4dFqIqozlZ87d50L9CZEgIwY=
=upTt
-----END PGP SIGNATURE-----

--v444wg3dxcxv7rn6--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 22 May 2025 09:38:01 +0000
Resent-Message-ID: <handler.78332.B78332.174790663010229 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: =?UTF-8?Q?No=C3=A9?= Lopez <noelopez@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174790663010229
          (code B ref 78332); Thu, 22 May 2025 09:38:01 +0000
Received: (at 78332) by debbugs.gnu.org; 22 May 2025 09:37:10 +0000
Received: from localhost ([127.0.0.1]:60068 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uI2MP-0002es-Ot
	for submit <at> debbugs.gnu.org; Thu, 22 May 2025 05:37:10 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:47248)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uI2MI-0002da-VY
 for 78332 <at> debbugs.gnu.org; Thu, 22 May 2025 05:37:06 -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 1uI2MB-005cCW-4Q; Thu, 22 May 2025 11:36: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=1nr9AzAodNFDsTfy5QGVj1mm4mKZRQk9OuVU+RmkfGI=; b=Zay1h+itgbnH8NVHn08LW2/Put
 D8yL7g+qKlresAGDlnfEDGdiSCrH0EE9P6QbjDmqZ2Uk+0sQYCNnbKDb2SkoFAzWkNXKEaLoHefCx
 pcPZHq1UVnCOuCrXoo80zqrXlESre6sfIJq3MVgTZTDxKyjzP0nUFLpE5cil0fQlWnDVsnbC/WfKg
 D51Bf+StlqkF1HXh90k5xI+Bp+k3e0gCOTqa6+M0V7ajesSexo+bbm0ngom2wL/m4ZZE/8fMnoOJH
 Ml04YmZbDJ2XFz1RpxTgDzHhYN9rBI7Y0lzxhSMlxm8OFWJyqPaDQJnL/Sjvl+X3NFlXnnAf/kiLs
 JAGb1Mrg==;
Received: from [10.9.9.72] (helo=submission01.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uI2MA-0005Qp-Ky; Thu, 22 May 2025 11:36: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 1uI2M7-003qBX-PT; Thu, 22 May 2025 11:36:51 +0200
Date: Thu, 22 May 2025 10:36:50 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <jvwqegcfdkoi4etv23lki5e3ana42bxdeoc34f5vbnwfobonjx@7k5soohkbfjx>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87ldqpxbw1.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="d5rjokogrwqpg4gu"
Content-Disposition: inline
In-Reply-To: <87ldqpxbw1.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 (-)


--d5rjokogrwqpg4gu
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 (submitted)
MIME-Version: 1.0

Hi No=C3=A9,

On 22 May, No=C3=A9 Lopez wrote:
> Steve George <steve@HIDDEN> writes:
(...)=20
> Hi Steve,
>=20
> Thanks for this great GCD!
>=20
> I assume the GCD would end after June, so will there be a july/august
> release or will we have to wait for a year?
(...)

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

Rather than wait a year I proposed:

> > This GCD proposes an annual release cycle, with releases **in June**.
> >
> > 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 June 2026.

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

(...)
> > The Release Manager role is likely to require the most effort, so it wi=
ll be
> > rotated and consist of two people from the release team.  For each rele=
ase
> > 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 r=
elease
> > manager is agreeing to take responsibility during two release cycles.
> > This system is modelled on the [Nix release management](https://codeber=
g.org/futurile/guix-org/src/branch/master/release-mgmt/nix-release-mgmt.md)
> > approach.
>=20
> What happens in 6 years when there are no new release managers
> available, can we reuse someone?
=20
I wasn't suggesting a strict rotation where you can only do it once out of =
the X committers that we have. The new person is still a volunteer from the=
 pool of committers. The idea of the "rotation" is to prevent it becoming o=
ne persons permanent chore and because of the 'bus-factor' risk. I expect t=
hat there will be a subset of active contributors who are interested/willin=
g/able to work on a release, so the 'release manager' role will probably ro=
tate around amongst that group - but not all contributors.

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

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

Steve / Futurile

--d5rjokogrwqpg4gu
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHQEABYKAB0WIQQIB6x23+hDA21fWHn1HUoW3O5vpwUCaC7wMQAKCRD1HUoW3O5v
px8IAPdJPlQHMBvnrGJsA6b0nCfapNomQmUpkYRPPlpHd2akAP9hffbTpfY9lB4t
RW2SMGRVmLNJL5/dtT1i+90GbqWiBg==
=eYfW
-----END PGP SIGNATURE-----

--d5rjokogrwqpg4gu--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 22 May 2025 10:03:01 +0000
Resent-Message-ID: <handler.78332.B78332.174790813117882 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Jelle Licht <jlicht@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174790813117882
          (code B ref 78332); Thu, 22 May 2025 10:03:01 +0000
Received: (at 78332) by debbugs.gnu.org; 22 May 2025 10:02:11 +0000
Received: from localhost ([127.0.0.1]:60265 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uI2kc-0004eA-10
	for submit <at> debbugs.gnu.org; Thu, 22 May 2025 06:02:11 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:42988)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uI2kW-0004cw-Ku
 for 78332 <at> debbugs.gnu.org; Thu, 22 May 2025 06:02:05 -0400
Received: from mailtransmit03.runbox ([10.9.9.163] 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 1uI2kN-005fGB-SA; Thu, 22 May 2025 12:01: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=J+ZyK+Sd0ffmHXRRRLk6zwgWgJokfQlCYo3zdGxSkPo=; b=fEONSOANcoqrbRHDLtkmUZiHsN
 s6GamYYa4ujcHlrklfX9w2WLMmCrlylbElgv+9PmvwGHFSBde1BsS8c4fsoNYwkjyZZtVibJKovaL
 3UAd5pbJgrhhTl5Zwp5/PpOc5KYIMMaGjrI3Ytil6Isoyt5usIF0VhnKHqk05jovbNuyk6zBiymUg
 xB5im6yKLmlSCFQMqAWcgwNAyFDv9rQ0mmDu5PQ9ALc9uTNnCoRtIRIwdUpe7DawTrHx8/8tp+j2Y
 gvWMy6Z0m3rEJZw5Cx9EOlsaErBTwA+qRn514wWQO6kzzYwggGZSwHVArDMgP5UMyaqinXejUFR75
 fLL6wEqQ==;
Received: from [10.9.9.72] (helo=submission01.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uI2kM-0003SS-Pj; Thu, 22 May 2025 12:01:55 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uI2k7-003y7f-6Q; Thu, 22 May 2025 12:01:39 +0200
Date: Thu, 22 May 2025 11:01:38 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <3sq2ks4qfahmuo5jph6uq7wrttg2odsr6ck4xb6khssvfutewp@6h3fjptzk55v>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87ecwkzr8o.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87ecwkzr8o.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 19 May, Jelle Licht wrote:
(...) 
> Steve George <steve@HIDDEN> writes:
(...) 
> >[snip]
> > 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.
> 
> I think that this is a good point to make, but at the same time we may
> not want to have other projects to direct our release cadence. Not
> because we don't want to play along, but rather because it causes undue
> stress and adds arbitrary deadlines that are hard to work around
> w.r.t. our current volunteer group of contributors.
> 
> > 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.
(...)

I think you're pointing right to the heart of this proposal, and the main thing we should think about! 

I'm trying to create an intent, a rallying-cry, an impetus for the project's active contributors to attempt and prioritise doing annual releases.  I believe it will help our existing users, potential new users and the project itself, for the reasons I set out in the Motivation section.

But, as you point out we are a volunteer project - maybe "we" don't want to work on releases; find it stressful; or don't have enough participants. I have tried to reflect this at various points, and in the 'Cost of Reverting'. At an individual level none of our contributors _have_ to work on a release, they can continue to work in their team-branches.

So yeah, I agree everyone should think about whether they want to try out annual releases. I also think that the only way to find out if it's positive (a goal) or negative (stressful) is to try it out. If it doesn't work for everyone we simply return back to releasing when we want to.

(...)
> > ## 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.
> 
> My two cents: focus only on minimal, perhaps extended in such a way that
> this is a system that after the first reboot allows one to run guix
> pull.
> 
> Ditto for 'foreign-guix': any version of guix that doesn't burn down the
> house on updating itself seems like it would be 'enough', and still a
> strict improvement over the current situation.
(...)

Yeah, both you and Efraim suggested this, I removed server/hosted from the list in the latest version. I've also focused it on the minimal experience.

I tried not to get too far into the weeds with "release criteria" definitions or similar.

(...)
> > 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.
> 
> This makes a lot of sense to me, although I could be centered around
> 'functional' breakage w.r.t. allowing the installation to update itself
> past any major issues via guix pull (+ guix system reconfigure or
> equivalent).
> 
> > [snip]
> 
> Thanks again for the detailed analysis and proposal,

To reflect your comment and some others I've reworded a bit throughout to try and express the focus on the initial install and initial experience: what _has_ to work for someone to install Guix and it not break. There could be more detail but I'm trying to resist the GCD becoming even longer. Also, I think the GCD should be about the main "design" and the implementers (each release team) have the flexibility to make specific decisions.

Thanks for going through it - appreciate it - and hope the later version reflects your comments above!

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 22 May 2025 10:59:02 +0000
Resent-Message-ID: <handler.78332.B78332.17479115242257 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: =?UTF-8?Q?Andr=C3=A9?= Batista <nandre@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17479115242257
          (code B ref 78332); Thu, 22 May 2025 10:59:02 +0000
Received: (at 78332) by debbugs.gnu.org; 22 May 2025 10:58:44 +0000
Received: from localhost ([127.0.0.1]:60720 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uI3dL-0000aK-Cg
	for submit <at> debbugs.gnu.org; Thu, 22 May 2025 06:58:44 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:55288)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uI3dF-0000Zz-KX
 for 78332 <at> debbugs.gnu.org; Thu, 22 May 2025 06:58:39 -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 1uI3d6-005mQ2-Th
 for 78332 <at> debbugs.gnu.org; Thu, 22 May 2025 12:58:28 +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=OVfuvpfe/lpHmW5xpsutJ3ZyTdHDWyPR7P0zl65QB8s=; b=ghpWZsrxAygxUxc/SlDPAVHWgV
 fjD+Zav6Is9erA8Bx7TRiqIx27rICk64WJs/fdSRThs7ahjw2+56gaMEvpF7VS5VVl8mcqEmCmMzr
 EhgH09JhhTLyhb4o+iJx4ifLzhGLZ1abhwExOnKO5jCNscs1fCbPoC9LHkwu1BC6HSBC+HvPKCnIM
 b1MPcWBDCNHlKk5GuGFLa7+BcSPqx1DqoWJEa9uzyPnHFLljtRLjITriLfatTdchwJ7ACL1WaQeML
 2XTlmOl9X78o1rQEoTz9r9vGN5ybQVvNOxAqHh0C36qsXdsO0ybQxY55/AFwXw/aBNMDbgLkW7gZz
 J+bglJ3Q==;
Received: from [10.9.9.74] (helo=submission03.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uI3d6-0003nh-BB; Thu, 22 May 2025 12:58:28 +0200
Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uI3cy-005jiu-Cv; Thu, 22 May 2025 12:58:20 +0200
Date: Thu, 22 May 2025 11:58:19 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <i6jf2pa3hkshvyv7rsslfhglffejno5wmitun5xdbozdyvm4ld@hhmmsjqky4ql>
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
 <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <aCeZxK0-0dbsc6kb@andel>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <aCeZxK0-0dbsc6kb@andel>
X-Spam-Score: -0.7 (/)
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 André,

Appreciate you going through it and more broadly suggesting how you think a release system could work.

On 16 May, André Batista wrote:
> Hi,
> 
> sex 09 mai 2025 às 13:53:39 (1746809619), steve@HIDDEN enviou:
> > 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.
> > 
> 
> First of all, thanks for this initiative, we're certainly in need of a more
> structured and reliable release process.  I have no experience doing guix
> (or any distro) release, so take or drop my comments as you see fit.
> 
> I'm not sure a GCD is the proper way to tackle the release issue.  As we say
> here in the global south - where November is spring :) - "you are putting the
> cart before the oxen", meaning its the oxen that should be dragging the cart,
> not the other way around.
> 
> Since we've been having problems producing a release for the past years, I feel
> that aiming to shorten the release time span before even having had a release
> might not be the best way to achieve the proposed goal.  What happens if we
> approve this GCD, but then no one assumes the roles of a release team?  How
> could we "enforce" this GCD on a volunteer project?
> 
> Wouldn't it be better to first establish and organize a release team, with the
> goal of releasing v. 1.5.0 as soon as possible and with the secondary goal
> of establishing/documenting a release process/schedule for future releases?
> IMO, this does not require a GCD, "just" people volunteering to the work at
> hand.
(...)

I want to take on the underlying reason for why I believe we should have a GCD.

Like you point out I initially intended to "just do a release". - I was going to email guix-devel asking "who wants to work on a release".

Then I realised that there'd been a few attempts at this in the last 2.5 years, and previously the project had infrequent releases compared to the vast majority of distributions. That changed my mind.

I submitted the GCD because I'm trying to get us as a group to think about whether we want to do regular releases. The GCD lets us choose whether we're motivated to prioritise achieving releases.

The specific details of whether it's annual, whether it's in May or June, whether we use a particular branching strategy - all sit on the foundation of whether "as a project" our goal is to release new versions regularly.

Explicitly, what this means is that _all team members_ value regular releases: it's not about what 4 people in a release team do, it's about having a goal as a project.

This does not mean that any individual volunteer has to actively work on a specific release. Of course, I hope that more people across the team would be excited by the idea of a release and contribute, not just leave it to the 4 people in the 'release team' to try and fix everything. Nonetheless, some people aren't interested in actively working on releases, which isn't a problem. But, at a mimimum adding a public cadence means that everyone has the clarity that we value regular releases and therefore there there are impacts at certain times - for example, developers can't destabilise a release by shipping something major a day before a final release.

If releasing regularly is priority goal for a project, I believe time-based releases are the best choice because:

* clear goal - everyone knows that in $DATE there's a release so know's what to work on.
* rhythm - naturally you work on big changes at the start of the cycle, and smaller ones close to the end.
* efficiency - you get better at what you do often: if we want to "automate" releases we can only find what works if we actually "do" releases.

Having worked in a time-based system I can honestly say that if you care about shipping something to users it's absolutely the best way.

The new version of the GCD integrates the comments about aiming for automation, that you and a few others made. Everyone has different experiences with releases and different definitions of what quality level is acceptable - overall the later version tries to minimise the work, but I will say "it builds" is not the same as "it works" for a distribution, at a minimum some humans will have to actually test the installer and first user-experience.  I added a kinda-sorta version of what you/Vagrant mentioned where if we're not in a releasable state then we move forward to a later target date - helping to balance quality and time-based discipline. I also added a goal of automation to the overall GCD and to the release-teams responsibilities in-line with what you/Greg/Ekaitz requested.

Hope this explains the thinking a bit more, and that the new version somewhat reflects your comments,

Steve / Futurile














> In a sense, I agree with other comments here that maybe we should treat
> releases as something less disruptive of our normal activities.  So, instead
> of aiming to mimick what other - larger and more resourceful - distros do, we
> could aim to do it in a way that is compatible with our own routines and
> resources.
> 
> What I envision is something like:
> 
> 1.  The release team focuses mainly on the artifacts.  Those should routinely
> be automatically built, regardless if we are about to release;
> 
> 2.  The relase team keeps a watchful eye on CI/QA for the build status of main
> architectures and packages needed to build the installer and images for those;
> 
> 3.  Once some major changes (linux-lts, gnome, toolchain, etc) hit master and
> CI shows that those are good and the successful build percentage is on a
> historical high on CI/QA for the major architectues, the release team proposes
> a new release to guix-devel;
> 
> 4.  Once proposed, any other major changes (anything that currently warrants
> a separate branch) are delayed for two weeks;
> 
> 5.  During these two weeks, the release team has the authority to revert any
> breaking changes (new build failures) commited to master and everyone is
> invited to test the latest beta-release artifacts;
> 
> 6.  If no release critical bugs are found, the relase team adds a commit
> tagging the new release with a news entry and a blog post summarizing the
> main changes since the last release and publishes the artifacts;
> 
> 7.  If release critical bugs are found and cannot be fixed in time, the
> release proposal is withdrawn and people are invited to work on the rc-bugs
> and major changes can be again merged to master.  Go back to item 3, but a
> new release proposal can only be made if the already rc-bugs are fixed and
> the major changes that were delayed at the time of the last proposal had the
> opportunity to be merged.
> 
> Does that make any sense?
> 
> Cheers

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Olivier Rojon <o.rojon@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 05 Jun 2025 04:24:07 +0000
Resent-Message-ID: <handler.78332.B78332.174909738428425 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Z572 <z572@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174909738428425
          (code B ref 78332); Thu, 05 Jun 2025 04:24:07 +0000
Received: (at 78332) by debbugs.gnu.org; 5 Jun 2025 04:23:04 +0000
Received: from localhost ([127.0.0.1]:56944 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uN284-0007Nx-CX
	for submit <at> debbugs.gnu.org; Thu, 05 Jun 2025 00:23:03 -0400
Received: from mout01.posteo.de ([185.67.36.65]:53839)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <o.rojon@HIDDEN>)
 id 1uN27y-0007MX-5G
 for 78332 <at> debbugs.gnu.org; Thu, 05 Jun 2025 00:22:57 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 130CF240027
 for <78332 <at> debbugs.gnu.org>; Thu,  5 Jun 2025 06:22:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1749097366; bh=BMtTHCbTA718GqXtSiIng3s5QUWRNrVzg217o5CCZIU=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=sDVkWC8+SUviPxQC58cORhYFepAQa9VN6RK0DIYjEe5Abxl/ozvCXGhg0VAht5ZRv
 qSkH4TZhqibSMou/uqwsNN5hqk4tLx0PMKWDRipROeRzf8pI1r8/GnvVyZDs8HpA7z
 wqYaUdEmEbXFjSw9Ir76IeqkV8CLfv7ptpaB96qO0tmsuf7xaKD5DUm7E4w7KHpX7v
 JLbzUa/P//qUcHienuYbzU2k8ISJFd9fTW9KXf8sK/lJBnJGVoLBFGOfYlV7VzToyh
 KV3c11AdSAiHEmBMbf2Xk29HUYnR9yR7inURN7ULF9WsSkt2KCHuL8JAEQxycn+xTv
 7RMIF7iBcGrfQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4bCWWn1yCBz6tsb;
 Thu,  5 Jun 2025 06:22:45 +0200 (CEST)
From: Olivier Rojon <o.rojon@HIDDEN>
In-Reply-To: <87ecwxkbaw.fsf@HIDDEN> (z572@HIDDEN's message of "Sat, 
 10 May 2025 00:18:15 +0800")
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
 <87msbmj5hp.fsf@HIDDEN>
 <gqowz5fh4txxxaubcttltsao6atw7u6ryedp2aorsnyjmsios5@hqn5shp2fqfj>
 <87ecwxkbaw.fsf@HIDDEN>
Date: Thu, 05 Jun 2025 04:22:43 +0000
Message-ID: <87iklaq0ks.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.3 (/)
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.3 (-)

Hi guys :)

Z572 <z572@HIDDEN> writes:

> 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 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.
>>> 
>>
>> 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

I am in favour of a naming scheme which reflects the time it was created.  It might even
be sufficient to use just a year prefix since we assume there is only one created per year
(per release).

Have a good day :)
Olivier

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 05 Jun 2025 22:35:02 +0000
Resent-Message-ID: <handler.78332.B78332.174916289123500 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Olivier Rojon <o.rojon@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org, Z572 <z572@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174916289123500
          (code B ref 78332); Thu, 05 Jun 2025 22:35:02 +0000
Received: (at 78332) by debbugs.gnu.org; 5 Jun 2025 22:34:51 +0000
Received: from localhost ([127.0.0.1]:38869 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uNJAg-00066y-Lr
	for submit <at> debbugs.gnu.org; Thu, 05 Jun 2025 18:34:50 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:49400)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uNJAd-00066S-4G
 for 78332 <at> debbugs.gnu.org; Thu, 05 Jun 2025 18:34:48 -0400
Received: from mailtransmit03.runbox ([10.9.9.163] 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 1uNJAU-00CK7A-4r; Fri, 06 Jun 2025 00:34:38 +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=VsT+yTsOG7rwFvfB/V9JhB1/v9pmYOauZzYca+qlEmM=; b=Cr8L7Lppd+qPa6JG6ulllwcozn
 seOELNqO0SxyhmIY6G50uLwfN0FxGkUHzoANOqoWAzNtDmOV9h9ug7v4JWSgMLd02Qy6wfU66Cubn
 xMlvKdNYviNXBMhADOYPQ9xiN0yjSuojY6Nj3PThJAkXOTmyJSojhsJ6mBrARvVtcya/2XXUNEKWJ
 iqqUXeqDF3VVbTz0MY593lCn0Lq5iCwrkfRNQ/6LlEffN2pCOUeKRYX6V8s+utu/as3dxpeITa/78
 IbTIZBKle7EF8jMdkLwFOhwk9UsellfMLMVYGiBrBGdMKbW8OttcVzCdA1t239NDcgkhua+o6SXG/
 2AJtHo+Q==;
Received: from [10.9.9.73] (helo=submission02.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uNJAT-00060l-KD; Fri, 06 Jun 2025 00:34:37 +0200
Received: by submission02.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uNJAO-0052wq-JZ; Fri, 06 Jun 2025 00:34:32 +0200
Date: Thu, 5 Jun 2025 23:34:31 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <hlz25z24i4p66sq6p2ae7gda4uq5hou6lmrijk7zttl6d2lvcy@wtzhwdsfwsmt>
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
 <87msbmj5hp.fsf@HIDDEN>
 <gqowz5fh4txxxaubcttltsao6atw7u6ryedp2aorsnyjmsios5@hqn5shp2fqfj>
 <87ecwxkbaw.fsf@HIDDEN> <87iklaq0ks.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87iklaq0ks.fsf@HIDDEN>
X-Spam-Score: 1.3 (+)
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 Olivier On Thu, Jun 05, 2025 at 04:22:43AM +0000, Olivier
 Rojon wrote: (...) > Z572 <z572@HIDDEN> writes: > >>> I think we may
 need to change the name. We used the name staging before > >>> switching
 to [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [2a0c:5a00:149:0:0:0:0:25 listed in] [list.dnswl.org]
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: z572.online (online)]
 0.0 T_SPF_PERMERROR        SPF: test of record failed (permerror)
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: 0.3 (/)

Hi Olivier

On Thu, Jun 05, 2025 at 04:22:43AM +0000, Olivier Rojon wrote:
(...)
> Z572 <z572@HIDDEN> writes:
> >>> I think we may need to change the name. We used the name staging before
> >>> switching to the team-based process. If we reuse this name, it may cause
> >>> confusion for later users when searching for information.
> >>> 
> >>
> >> 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
> 
> I am in favour of a naming scheme which reflects the time it was created.  It might even
> be sufficient to use just a year prefix since we assume there is only one created per year
> (per release).
(...)

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

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

Thanks,

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Olivier Rojon <o.rojon@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 06 Jun 2025 04:08:02 +0000
Resent-Message-ID: <handler.78332.B78332.17491828419658 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org, Z572 <z572@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17491828419658
          (code B ref 78332); Fri, 06 Jun 2025 04:08:02 +0000
Received: (at 78332) by debbugs.gnu.org; 6 Jun 2025 04:07:21 +0000
Received: from localhost ([127.0.0.1]:40560 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uNOMT-0002Vi-Ad
	for submit <at> debbugs.gnu.org; Fri, 06 Jun 2025 00:07:21 -0400
Received: from mout01.posteo.de ([185.67.36.65]:58753)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <o.rojon@HIDDEN>)
 id 1uNOMK-0002VH-1x
 for 78332 <at> debbugs.gnu.org; Fri, 06 Jun 2025 00:07:17 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 77DC5240027
 for <78332 <at> debbugs.gnu.org>; Fri,  6 Jun 2025 06:07:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1749182825; bh=KkJioL5nJAOgqGTXbdk1QADjD3g/eJjRcjA0jo7W+g8=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=T34kSj7iMlo+EV5TxXwF0OX2Fqv8ON+Rq+dbnUH3Mo/9D4xagBo4kaRNhlqeogYkf
 odl1lruzYuz9AeW16xZvXhs2YkyJEEnwfsrofa08QZkgjp4n0+sShyn0h/AnH9PSPm
 UtDJD1F4E2AQo66wJoHWX6SaVsNF5Sp5eXPyV4s+hsFESZAlSqdlO4c34tMEyJoN30
 6Awxkzfo8t/jMYJ8hKpig6nOO31GAHtttf6rDHe3ZyZv/tC74kifNky6OSj5TIRoQ7
 Qd4dTOnXgmM8YF1/rSAhzNMlc4Y0a7TcJi9RJDqYsQLLIM8sgb7jrbEh0Gx4qf9F9Z
 INmG6FVGgvy3g==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4bD77D4ysKz9rxL;
 Fri,  6 Jun 2025 06:07:04 +0200 (CEST)
From: Olivier Rojon <o.rojon@HIDDEN>
In-Reply-To: <hlz25z24i4p66sq6p2ae7gda4uq5hou6lmrijk7zttl6d2lvcy@wtzhwdsfwsmt>
 (Steve George's message of "Thu, 5 Jun 2025 23:34:31 +0100")
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
 <87msbmj5hp.fsf@HIDDEN>
 <gqowz5fh4txxxaubcttltsao6atw7u6ryedp2aorsnyjmsios5@hqn5shp2fqfj>
 <87ecwxkbaw.fsf@HIDDEN> <87iklaq0ks.fsf@HIDDEN>
 <hlz25z24i4p66sq6p2ae7gda4uq5hou6lmrijk7zttl6d2lvcy@wtzhwdsfwsmt>
Date: Fri, 06 Jun 2025 04:07:03 +0000
Message-ID: <87bjr1wm1k.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.3 (/)
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.3 (-)

Ah, then there was a misunderstanding on my side, sorry. It's funny how you can misread
stuff that's clearly stated when it's early in the morning :D

Steve George <steve@HIDDEN> writes:

> Hi Olivier
>
> On Thu, Jun 05, 2025 at 04:22:43AM +0000, Olivier Rojon wrote:
> (...)
>> Z572 <z572@HIDDEN> writes:
>> >>> I think we may need to change the name. We used the name staging before
>> >>> switching to the team-based process. If we reuse this name, it may cause
>> >>> confusion for later users when searching for information.
>> >>> 
>> >>
>> >> 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
>> 
>> I am in favour of a naming scheme which reflects the time it was created.  It might even
>> be sufficient to use just a year prefix since we assume there is only one created per year
>> (per release).
> (...)
>
> Just to make sure it's clear, this is the name for a branch that would be used for 8 weeks
> where major changes would be held. This is so that we don't destabilise our main branch
> ahead of a new release. The reason Z572 was concerned about reusing the name 'staging' is
> that this was previously tried, and this branch became long-lived and it was hard to merge
> it back into the main branch.
>
> I was trying to think of a name that would imply that this branch would *only* be around
> for a few weeks. So suggested the month it was merging back in - to prevent it becoming
> long-lived. I don't think we should call it by the year as that might encourage our
> previous problem! What do you think, does that make sense?
>
> Thanks,
>
> Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Liam Hupfer <liam@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 06 Jun 2025 04:42:01 +0000
Resent-Message-ID: <handler.78332.B78332.174918490017611 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174918490017611
          (code B ref 78332); Fri, 06 Jun 2025 04:42:01 +0000
Received: (at 78332) by debbugs.gnu.org; 6 Jun 2025 04:41:40 +0000
Received: from localhost ([127.0.0.1]:40701 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uNOtf-0004Zy-AN
	for submit <at> debbugs.gnu.org; Fri, 06 Jun 2025 00:41:40 -0400
Received: from out-178.mta1.migadu.com ([95.215.58.178]:22471)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <liam@HIDDEN>) id 1uNOtc-0004ZH-7J
 for 78332 <at> debbugs.gnu.org; Fri, 06 Jun 2025 00:41:37 -0400
X-Report-Abuse: Please report any abuse attempt to abuse@HIDDEN and
 include these headers.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpfr.net; s=key1;
 t=1749184888;
 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=gps5aSPjcd2DRTB3X8nlFnISnKJsJJFQUschA5/fFM0=;
 b=fRy7t9jPj0PbYSgm/0APIkyOxzzsI8XDLTlzcs7oSMl9J+paXyuslfPd2RL4UudIWDealx
 NymsBcmegIzWs1xi8NnsTugZP2fYD+t1wh7dsDqSE9SJl3RaVHwWRqdQUH9H9hVLxxOue8
 DGplZQhiuTGSYPZbsveGMxxEimXQSYYMw9rutBuQjBC9e16odsHtLTWeXouMfgSDLMhp+9
 EM/OQ+lgUVwgxO8DmMOwE31lkyUd6XLLprA85EbNvqZJK1R006nrbExzay8y47hm7XJjw+
 aoDnCFMF6REJS1IoiBA/3JzBe0633B7C06MKmk3xmNSogYY9XsDzcS76wPz8gA==
From: Liam Hupfer <liam@HIDDEN>
In-Reply-To: <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
Date: Thu, 05 Jun 2025 23:41:22 -0500
Message-ID: <874iwtpjm5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Migadu-Flow: FLOW_OUT
X-Spam-Score: -0.7 (/)
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 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Steve, Guix,

First, thanks for moving the discussion forward here! Release discipline
is one of the marks differentiating a toy project and a serious one.

I am not a regular contributor yet but am an active user and list lurker
and have some impressions of current pain points. I also hang around
Nixpkgs and contribute there (mainly helping with the Guix package and
services) so I have some familiarity with their processes.

I tend to agree with Andrew=E2=80=99s feedback
(<https://yhetil.org/guix-patches/87ikly5t74.fsf@HIDDEN>) and others; we
need to be very judicious about imposing processes in this GCD that the
volunteer community can=E2=80=99t properly support yet. As discussed, while
regular releases are a useful marketing tool, we have to avoid giving
the impression that users should stay on releases. For the foreseeable
future stable branches are out of scope, so these releases only exist to
provide a base for new installations and a rollback target of last
resort. Good to see the revisions moving in this direction.

I agree with others=E2=80=99 feedback that we should be conservative with t=
he
scope at first to avoid imposing on general progress. We should limit
ourselves to only what is necessary for foreign distros to ship Guix and
a base Guix System installer.

The GCD doesn=E2=80=99t discuss tagging conventions but it came up in
discussion. Even if we move to a strict time-based schedule as is
proposed, I am a bit concerned about calver since it gives users the
impression of stable branches based on how other distros (NixOS, Ubuntu)
use calver. Sticking with semver until we can support stable branches
feels worth considering.

I do like the =E2=80=9Cwhen it is ready=E2=80=9D model Vagrant mentions fro=
m Debian.
Once we agree to start the release process, readiness of a minimum
viable package set can dictate the time to release. I=E2=80=99m not opposed=
 to
the landing zones you wrote down but I also don=E2=80=99t think they=E2=80=
=99re
necessary to make explicit. If a bug considered release blocking exists,
the release will be postponed until it is fixed (a tautology, I guess).
Nothing wrong with having a planned schedule but it can be kept simple
and we can note that it=E2=80=99s not a guarantee.

> 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
> the smallest set required for the initial environment.

Is standard necessary? What=E2=80=99s the difference between minimal and
standard? These proposed sets seems to overlap with the teams concept
somewhat. Either the package is release-critical or it isn=E2=80=99t, and t=
here
seems to be consensus that a functioning initial installation with a
graphical DE is critical. Can we simply define one =E2=80=9Crelease set=E2=
=80=9D?
Actually, based on the freezes you discuss later, maybe one =E2=80=9Cbuild =
set=E2=80=9D
for toolchains and Guix, etc, and one =E2=80=9Crelease set=E2=80=9D encompa=
ssing the
build set as well as the (closure of) critical top level applications
like editors and DEs?

>   - Coverage: all packages and services that are not explicitly platform
>     specific must work to be included in the archive.

So any package or service in the entire repository that doesn=E2=80=99t bui=
ld on
a primary arch must be removed before the release? Based on how Nixpkgs
ZHF goes I=E2=80=99m not sure this is realistic. Do you mean packages and
services in the release set? There are a lot of random leaf packages
that aren=E2=80=99t release critical but can become unmaintained as time pa=
sses.
As more services are added this is likely to become the case there too.
I=E2=80=99m not sure the release team should be burdened with hunting all t=
hese
down. A time-based best-effort cleanup period like ZHF every release is
certainly valuable, though.

>   - 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

These points don=E2=80=99t seem related to releases but rather general poli=
cies
about master? I guess you are defining the architecture tier concept
here but this was confusing to me at first in the context of reading the
GCD as a whole.

> # Appendix 1: Release Project Template

I know the appendix is just an example (=E2=80=9Cnon-normative=E2=80=9D in =
spec
parlance) but I feel like it warrants review if it=E2=80=99s going into the=
 GCD
as reference material. We should keep it concise and can get more
elaborate when planning the first release after the GCD is approved.

I do not think the major updates freeze and hard freeze are both
necessary. I think given the discussion on limiting the scope of a
release effort, we don=E2=80=99t need to bother with freezing all major upd=
ates
in week 8 for all packages, just the ones in the closure of the release
set. If particular maintainers want to keep shipping R or Haskell or
Emacs package ecosystem updates during the release we should let them
IMO, trying to approach a pristine full package set is not feasible yet
and we don=E2=80=99t want to encourage people to stay on tags anyway. An
informal cleanup period seems fine but a formal global freeze seems to
impose too much on niche package ecosystems maintained by volunteers
that ultimately won=E2=80=99t affect the release artifacts.

> | -5 | Nominate a release team |
> | -4 | Notify teams of upcoming release |
> | 01 | Release project start |

The use of negative indices gets confusing when the start is week 1. Is
there a week 0 or not? IMO the NixOS example where release week is 0 is
intuitive. Countdown to release!

> ### Toolchain and transition freeze (week 04)
> 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.

> Debian defines a transition as one where a change in one package causes
> changes in another, the most common being a library. This isn=E2=80=99t s=
uitable for
> Guix since any change in an input causes a change in another package.
> Nonetheless, any change that alters a significant number of packages shou=
ld be
> carefully considered and updates that cause other packages to break shoul=
d be
> rejected.

If Debian defines the term =E2=80=9Ctransition=E2=80=9D in a way that makes=
 it
meaningless for Guix, we shouldn=E2=80=99t reuse it. I don=E2=80=99t find i=
t a very
intuitive term anyway. Maybe =E2=80=9Cmass rebuild=E2=80=9D? I know I=E2=80=
=99ve seen that term
before in Guix contexts. Regardless, I don=E2=80=99t think restricting mass
rebuilds for 8 weeks is viable. If we focus on the release set as is
being discussed I don=E2=80=99t think we need to care about mass Haskell or=
 R or
Emacs rebuilds.

> 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 [^6].

The proposed branching model is not that similar to Nixpkgs, I think. In
Nixpkgs they don=E2=80=99t bother with a next-master because master is only
restricted for ~3 weeks.

While merges to and from the Nixpkgs staging branch are affected by the
release process, the branch itself is not really tied to release
stabilization. It is for grouping mass rebuilds and is used outside of
release time too. I think we should drop the reference since next-master
as it is proposed here is not really related to the Nixpkgs staging
branch.

IMO we should drop the discussion of this next-master integration branch
from the GCD and revisit it if it seems necessary during a release. In
the context of the proposal to not freeze non-release critical package
ecosystems it makes sense to me, anyway.

> * release branch: regularly merged from master, tracks the release artifa=
cts.
> * master branch: receives security and resolutions of RC bugs.
> * next-master: everything that normally goes to master.

Why is the release branch created while master is still frozen for 3
weeks?

Sorry for the scattered email. Hopefully you find some of it valuable.
Thanks again for your work on this!

=E2=80=94Liam

PS: I took a look at the release manifest you mentioned and was
surprised to see how many options the installer proposes in
%system-packages. IMO we should feel empowered to drop quite a few of
those when preparing a release. Emacs, Vim, and Nano should be in the
release set but not EXWM, Ratpoison or Awesome. Anyone who wants to
install a WM can expected to have their first Guix system generation be
VT only or a more mainstream DE (or guix pull from a foreign distro and
build their own installer if desired). WMs can certainly be added to the
installer if interested parties choose to test them during the release
cycle but should not block the release once the release set is ready
(Bash, OpenSSH, GNOME, wpa-supplicant, etc). We can remove any broken
options from the installer before tagging. Ideally we should have
VM-based automated testing of any DEs offered in the installer as well.

PPS: Another release-related issue that isn=E2=80=99t discussed is backport=
ing
critical patches. We didn=E2=80=99t backport patches for CVEs and tag 1.4.x
releases; distro maintainers had to apply them from blog posts. The blog
posts were helpful but that=E2=80=99s not how bug fixes should be shipped! I
help out with the Nix package and we=E2=80=99re carrying five patches now, =
four
of which are for CVEs. Maybe this is to prevent divergence where guix
pull thinks you are downgrading but we should look into how to handle
that better. Maybe patch releases can ship with the SHA for the latest
commit on master containing equivalent security patches embedded
somewhere in the Guix modules so =E2=80=98guix pull=E2=80=99 can treat that=
 as the point
of comparison for downgrade warnings instead of the tag commit itself?

--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: "Philip McGrath" <philip@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 06 Jun 2025 19:15:01 +0000
Resent-Message-ID: <handler.78332.B78332.174923729011584 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: "Liam Hupfer" <liam@HIDDEN>, "Steve George" <steve@HIDDEN>, "Brian Cully" <guix-devel@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174923729011584
          (code B ref 78332); Fri, 06 Jun 2025 19:15:01 +0000
Received: (at 78332) by debbugs.gnu.org; 6 Jun 2025 19:14:50 +0000
Received: from localhost ([127.0.0.1]:45179 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uNcWg-00030l-67
	for submit <at> debbugs.gnu.org; Fri, 06 Jun 2025 15:14:50 -0400
Received: from fhigh-b1-smtp.messagingengine.com ([202.12.124.152]:48005)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <philip@HIDDEN>)
 id 1uNcWa-00030E-BE
 for 78332 <at> debbugs.gnu.org; Fri, 06 Jun 2025 15:14:48 -0400
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfhigh.stl.internal (Postfix) with ESMTP id C4CC92540100;
 Fri,  6 Jun 2025 15:14:38 -0400 (EDT)
Received: from phl-imap-01 ([10.202.2.91])
 by phl-compute-03.internal (MEProxy); Fri, 06 Jun 2025 15:14:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 philipmcgrath.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:subject
 :subject:to:to; s=fm1; t=1749237278; x=1749323678; bh=HxuzPBzVPG
 fE1fYeh+YyPXBzWgwEKRvoTc6D/gaeX7Q=; b=TwHlRkKz47ekOG5aFeRqYLkVIK
 5QwDcPEUHga1J1pd1kq003lWYrZALa5o74YRkpCIKcYxdYBGYxwhFJLiNrvXS3N+
 9hb/aTwppm5l2woidfK2e16wUf5vCeqF49zr1Lo2tTyCHf++1bkxa3T5FAs0Lp33
 B0ZTCVDX0FWH9yYGTpl3ETRuShA32e9pZkL0zLcjYcSyMHB7WBUAS/itbed9ebEy
 JSHSJah8SJonUCbVHOLLsjctYULAURwX6mjuyrWfE10aBMOfmUzymoKUp7hi5JT7
 8L8SZbrD21lXp8K3UvQDZCj+8NLrHEemAowUligC3f8YFuflx06+0O/tuiCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1749237278; x=
 1749323678; bh=HxuzPBzVPGfE1fYeh+YyPXBzWgwEKRvoTc6D/gaeX7Q=; b=U
 5/rEdUkSEZp6Rmf9hs+ag80UWqyWr0ZgO+VEWSv32D8KJ8GYI/obvVZHohJwodzU
 b2V574cBaGYqaY1L5g365VtnKo0phbugItMmYrMfTkOANy+HGjP0TW3RPvq++PFD
 BG3zcU7E6jN/dunTl/iviuYHn/S4un4X12Scas9THcNMNJtIEndb65RlTidotBqi
 llVDQymN9Dxtnqx+Wjus6pDsBKtSafZIUoriSwP2db9utLtxFcP7fbnpxhju3XM2
 EvB+Tn26aiTyc95ElATzHQMnIPZuQGMCIQkxSwksCTRF2NviL4rjVANf20XA5MzL
 yUpgZ8CouAEues86A2kOQ==
X-ME-Sender: <xms:HT5DaOmIenie4sr1Sbh1Jf5rGeVjO5Hb-N-jK-tIaAZ5UVbcp6-3Kg>
 <xme:HT5DaF297-9JRwlJmbBQQ5RZcYXSYvyPfDtFLBdibpA9GdwGLspioBypedK5on9Lt
 mf6vAYfnhhFisr9ZKo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdehgeelucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgfgsehtqhertdertdej
 necuhfhrohhmpedfrfhhihhlihhpucfotgfirhgrthhhfdcuoehphhhilhhiphesphhhih
 hlihhpmhgtghhrrghthhdrtghomheqnecuggftrfgrthhtvghrnhepteeliefftddtveel
 fedtleegueejudekjeefvdejiedtieduffegjedtvdetffelnecuffhomhgrihhnpeihhh
 gvthhilhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl
 fhhrohhmpehphhhilhhiphesphhhihhlihhpmhgtghhrrghthhdrtghomhdpnhgspghrtg
 hpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjeekfeefvdesuggv
 sggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehsthgvvhgvsehfuhhtuhhrihhlvg
 drnhgvthdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdrohhrghdprhgtphht
 thhopehlihgrmheshhhpfhhrrdhnvght
X-ME-Proxy: <xmx:HT5DaMqGUbwuU95fkuD2XP4-Tl1lh4Vn8GXHu-CnTfxJpnSHN2zRrg>
 <xmx:HT5DaClM6yA6aJNcYSEIUuA3djKSR11B-LoEtGUg1-Q40hfXhD2WlA>
 <xmx:HT5DaM0HrGpuskwJOppr6FXkmCpPgwr8MVnxO1645jS_ACoPLjYVwg>
 <xmx:HT5DaJscJHKFS3udPrh4CzH6WTGUpux7SR3MpQPe2Og80ZDbgL4oLQ>
 <xmx:Hj5DaJSAUvjcKxlUN-ucXhE9LlsIu4P3G7ASM7_wUrdfeWQNof1GxO4y>
Feedback-ID: i2b1146f3:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501)
 id 9941118C0062; Fri,  6 Jun 2025 15:14:37 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: T766667b5681f14b5
Date: Fri, 06 Jun 2025 15:13:30 -0400
From: "Philip McGrath" <philip@HIDDEN>
Message-Id: <dfeb265a-208b-48d5-93c3-5381a4eee76b@HIDDEN>
In-Reply-To: <874iwtpjm5.fsf@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
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,

I share the concerns others have already described, particularly:

On Fri, Jun 6, 2025, at 12:41 AM, Liam Hupfer wrote:
> I tend to agree with Andrew=E2=80=99s feedback
> (<https://yhetil.org/guix-patches/87ikly5t74.fsf@HIDDEN>) and others;=
 we
> need to be very judicious about imposing processes in this GCD that the
> volunteer community can=E2=80=99t properly support yet. As discussed, =
while
> regular releases are a useful marketing tool, we have to avoid giving
> the impression that users should stay on releases. For the foreseeable
> future stable branches are out of scope, so these releases only exist =
to
> provide a base for new installations and a rollback target of last
> resort. Good to see the revisions moving in this direction.
>
> I agree with others=E2=80=99 feedback that we should be conservative w=
ith the
> scope at first to avoid imposing on general progress. We should limit
> ourselves to only what is necessary for foreign distros to ship Guix a=
nd
> a base Guix System installer.
>

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

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

> PPS: Another release-related issue that isn=E2=80=99t discussed is bac=
kporting
> critical patches. We didn=E2=80=99t backport patches for CVEs and tag =
1.4.x
> releases; distro maintainers had to apply them from blog posts. The bl=
og
> posts were helpful but that=E2=80=99s not how bug fixes should be ship=
ped! I
> help out with the Nix package and we=E2=80=99re carrying five patches =
now, four
> of which are for CVEs. Maybe this is to prevent divergence where guix
> pull thinks you are downgrading but we should look into how to handle
> that better. Maybe patch releases can ship with the SHA for the latest
> commit on master containing equivalent security patches embedded
> somewhere in the Guix modules so =E2=80=98guix pull=E2=80=99 can treat=
 that as the point
> of comparison for downgrade warnings instead of the tag commit itself?

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

>> The package sets would be:
>>
>> * minimal: packages required to boot and install a minimal Guix or Gu=
ix 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 us=
es.
>> * desktop: provides the packages necessary for a desktop.  This would=
 include
>> the smallest set required for the initial environment.
>
> Is standard necessary? What=E2=80=99s the difference between minimal a=
nd
> standard? These proposed sets seems to overlap with the teams concept
> somewhat. Either the package is release-critical or it isn=E2=80=99t, =
and there
> seems to be consensus that a functioning initial installation with a
> graphical DE is critical. Can we simply define one =E2=80=9Crelease se=
t=E2=80=9D?
> Actually, based on the freezes you discuss later, maybe one =E2=80=9Cb=
uild set=E2=80=9D
> for toolchains and Guix, etc, and one =E2=80=9Crelease set=E2=80=9D en=
compassing the
> build set as well as the (closure of) critical top level applications
> like editors and DEs?
>
> ...
>
> PS: I took a look at the release manifest you mentioned and was
> surprised to see how many options the installer proposes in
> %system-packages. IMO we should feel empowered to drop quite a few of
> those when preparing a release. Emacs, Vim, and Nano should be in the
> release set but not EXWM, Ratpoison or Awesome. Anyone who wants to
> install a WM can expected to have their first Guix system generation be
> VT only or a more mainstream DE (or guix pull from a foreign distro and
> build their own installer if desired). WMs can certainly be added to t=
he
> installer if interested parties choose to test them during the release
> cycle but should not block the release once the release set is ready
> (Bash, OpenSSH, GNOME, wpa-supplicant, etc). We can remove any broken
> options from the installer before tagging. Ideally we should have
> VM-based automated testing of any DEs offered in the installer as well.
>

Overall, I also think this concept of "package sets" should be simplifie=
d and refined, or indeed replaced by existing concepts like teams and ma=
nifests.

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

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

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

Hope this is useful,
Philip

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 07 Jun 2025 12:04:02 +0000
Resent-Message-ID: <handler.78332.B78332.174929782518772 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Liam Hupfer <liam@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174929782518772
          (code B ref 78332); Sat, 07 Jun 2025 12:04:02 +0000
Received: (at 78332) by debbugs.gnu.org; 7 Jun 2025 12:03:45 +0000
Received: from localhost ([127.0.0.1]:47192 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uNsH2-0004sf-DO
	for submit <at> debbugs.gnu.org; Sat, 07 Jun 2025 08:03:45 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:44182)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uNsGx-0004sI-Vh
 for 78332 <at> debbugs.gnu.org; Sat, 07 Jun 2025 08:03:42 -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 1uNsGp-00GgtS-GP
 for 78332 <at> debbugs.gnu.org; Sat, 07 Jun 2025 14:03:31 +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=ZIk8da2LoPM+fQIKS33ZZ/I0n3CGXD3hB89q6Jq+DvA=; b=OKxF0oSwro+qxIMmt/cPVIvIQV
 DBXYRz6C9bgRZx0/PHvkrfiIb5jOG+7nWtGHshTEUIsxwBEALcMlO+Di99Qbt/56bsBYOkbWcUKCi
 5Kowji3h8w8qNCG+kssNI1FG+BPk6/e6rJwfCZmFIPIobmEWhdH5CzQQGi6a5rcdTlSXIyICuqEX7
 LVg3jVUIsm2KBoOAcyWGQ47wvm5KfR68IQNL20CwqvqE2ghQLM+k4CPmvr9npPx73qgBEabnG+MJZ
 GVFjTtnFVMBYRnAXFrm8csrxJRzjIlqpecpFMazgeW+OqgVMA9Krg/s6Za4uZryVvuCrOvaI9TfzK
 G0LzI/RQ==;
Received: from [10.9.9.74] (helo=submission03.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uNsGo-0006U6-UM; Sat, 07 Jun 2025 14:03:31 +0200
Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uNsGV-00FjFg-TO; Sat, 07 Jun 2025 14:03:12 +0200
Date: Sat, 7 Jun 2025 13:03:10 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <r6f5xzc27hclbvb3xhaxaxmtya5ty2rled5eyv7kz65qywjncx@xvp4ke3mofl7>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <874iwtpjm5.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Liam,

On Thu, Jun 05, 2025 at 11:41:22PM -0500, Liam Hupfer wrote:
> Hi Steve, Guix,
> 
> First, thanks for moving the discussion forward here! Release discipline
> is one of the marks differentiating a toy project and a serious one.
> 
> I am not a regular contributor yet but am an active user and list lurker
> and have some impressions of current pain points. I also hang around
> Nixpkgs and contribute there (mainly helping with the Guix package and
> services) so I have some familiarity with their processes.

It's really valuable to have other perspectives, so thanks for getting involved in the discussion. We're new to trying the GCD process, so getting input and learning how we move towards consensus are all part of it.

> I tend to agree with Andrew’s feedback
> (<https://yhetil.org/guix-patches/87ikly5t74.fsf@HIDDEN>) and others; we
> need to be very judicious about imposing processes in this GCD that the
> volunteer community can’t properly support yet. As discussed, while
> regular releases are a useful marketing tool, we have to avoid giving
> the impression that users should stay on releases. For the foreseeable
> future stable branches are out of scope, so these releases only exist to
> provide a base for new installations and a rollback target of last
> resort. Good to see the revisions moving in this direction.
(...)

I whole heartedly agree with not "[imposing] processes ... that the volunteer community can't properly support yet".

I really want to remove your word "imposing" because no contributor will be *forced* to be involved in working on a release - I want to make sure that's 100% clear - nothing is being imposed. If an individual developer isn't motivated to work on releases that is totally fine and acceptable: the only thing they're really being asked is "not to prevent others" from working on a release.

Aside from that, I agree that _any_ change in our processes brings risk that we don't know if we can "properly support". We don't know if we have enough "volunteer community" time/energy to do annual releases.

One way to consider that risk is to think about whether a GCD is irreversible (a one-day door). Trying 'regular releases' is not a one-way door. We can try it out, and if it turns out that we can't manage it as a project we'll simply fall back to our current process of irregular releases.

I would strongly advocate for us to have an experimental mind-set, where we generally lean towards the changes proposed in GCDs. If we aren't willing to try out a different <whatever>, we'll get the same result. And, really the only way to learn is to try something out and find out - we can iterate from there!

We should be "judicious"  and thoughtful (so I'm not calling for chaos!), but I do want to encourage us to be positive about trying different approaches (particularly if they're reversible).

(...)
> I agree with others’ feedback that we should be conservative with the
> scope at first to avoid imposing on general progress. We should limit
> ourselves to only what is necessary for foreign distros to ship Guix and
> a base Guix System installer.
> 
> The GCD doesn’t discuss tagging conventions but it came up in
> discussion. Even if we move to a strict time-based schedule as is
> proposed, I am a bit concerned about calver since it gives users the
> impression of stable branches based on how other distros (NixOS, Ubuntu)
> use calver. Sticking with semver until we can support stable branches
> feels worth considering.
> 
> I do like the “when it is ready” model Vagrant mentions from Debian.
> Once we agree to start the release process, readiness of a minimum
> viable package set can dictate the time to release. I’m not opposed to
> the landing zones you wrote down but I also don’t think they’re
> necessary to make explicit. If a bug considered release blocking exists,
> the release will be postponed until it is fixed (a tautology, I guess).
> Nothing wrong with having a planned schedule but it can be kept simple
> and we can note that it’s not a guarantee.
(...)

Many distribution teams used to work on the "when it is ready" model. But, release projects are famously exhausting for distribution teams. Most projects have struggled to ship and burnt out teams.

Time-based releases came about to basically reprioritise "ship it" over features. At some point in every release project you have to say "we've done all we can on features, now we test and then we ship it". From my experience, if a release team can't ship, their chances of shipping start decreasing rapidly. So overall, I would say if we can't ship in X attempts (landing zones) let the team decide what to do - in all probability they will be best to disband and try again later.

I wouldn't be in favour of going to "when it is ready", but adding some flexibility through "landing zones" seems like a good bit of flexiblity that can account for the challenges of 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
> > the smallest set required for the initial environment.
> 
> Is standard necessary? What’s the difference between minimal and
> standard? These proposed sets seems to overlap with the teams concept
> somewhat. Either the package is release-critical or it isn’t, and there
> seems to be consensus that a functioning initial installation with a
> graphical DE is critical. Can we simply define one “release set”?
> Actually, based on the freezes you discuss later, maybe one “build set”
> for toolchains and Guix, etc, and one “release set” encompassing the
> build set as well as the (closure of) critical top level applications
> like editors and DEs?

Heh! You really set me thinking here trying to figure out why distributions split like this.

For the record, Efraim's the only person working on this and right now the "release" set your suggesting is what we'll land up with. 

So, why have I tried to split it like this?

First, we have to have a concept separate from a "Team", because we're not "imposing" a requirement on a Team to delivery for a release: if the installer uses some Python libraries we do *not require* the Python team to package, test, deliver etc.

We need some way to separately track what's in the release so we can test it and reduce the amount of work we're covering. I split it into "minimal" and "desktop" because we have at least two scenarios:

1. Minimal: guix installed on a hosted distribution, minimal guix installed as Linux distribution
2. Desktop: Guix installed as a Linux distribution with a specific DE

This is mostly about the testing and focus of the Release Team's attention. Having a minimal/desktop split makes it easier to add other testing scenarios (e.g. minimal->"server"). However, right now Efraim's work is doing what you suggest.

> >   - Coverage: all packages and services that are not explicitly platform
> >     specific must work to be included in the archive.
> 
> So any package or service in the entire repository that doesn’t build on
> a primary arch must be removed before the release? Based on how Nixpkgs
> ZHF goes I’m not sure this is realistic. Do you mean packages and
> services in the release set? There are a lot of random leaf packages
> that aren’t release critical but can become unmaintained as time passes.
> As more services are added this is likely to become the case there too.
> I’m not sure the release team should be burdened with hunting all these
> down. A time-based best-effort cleanup period like ZHF every release is
> certainly valuable, though.

The context for me is that we have a lot of broken packages and the release is a sensible time to look at them. The Survey showed that, out of date and broken packages are a big problem for users, so my thinking was that during a release project it's natural to reduce our scope by going through the process of notifying Developers that packages will be removed.

We don't actually have that much knowledge about Nix's processes and approach. How do you see ZHF working and do you have any thoughts/knowledge on how Nix deals with broken packages practically?

(...)
> >   - 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
> 
> These points don’t seem related to releases but rather general policies
> about master? I guess you are defining the architecture tier concept
> here but this was confusing to me at first in the context of reading the
> GCD as a whole.
(...)

I put in both package sets and the architecture section as ways to reduce the scope of a release. So my goal was to figure out ways to reduce the friction of doing a release. Hypothetically, a release requires us to test every package on all archectures - obviously that doesn't actually happen! So how can we be explicit about what the Release Team must work on - one way is to say "we don't work on or test these packages" (package sets) and an additional way is to say "we don't work on or test these packages" (architectures). 

> > # Appendix 1: Release Project Template
> 
> I know the appendix is just an example (“non-normative” in spec
> parlance) but I feel like it warrants review if it’s going into the GCD
> as reference material. We should keep it concise and can get more
> elaborate when planning the first release after the GCD is approved.
> 
> I do not think the major updates freeze and hard freeze are both
> necessary. I think given the discussion on limiting the scope of a
> release effort, we don’t need to bother with freezing all major updates
> in week 8 for all packages, just the ones in the closure of the release
> set. If particular maintainers want to keep shipping R or Haskell or
> Emacs package ecosystem updates during the release we should let them
> IMO, trying to approach a pristine full package set is not feasible yet
> and we don’t want to encourage people to stay on tags anyway. An
> informal cleanup period seems fine but a formal global freeze seems to
> impose too much on niche package ecosystems maintained by volunteers
> that ultimately won’t affect the release artifacts.
(...)

In general, the "freeze" has had the most negative attention.

I will say my personal experience having working on a lot of releases is that the main thing that prevents a release of a Linux distribution is a developer committing somethig that breaks the entire archive a few days before the release. There's an example from NixOS in their document, Debian famously has had it, at Ubuntu I can think of two instances. 

> > | -5 | Nominate a release team |
> > | -4 | Notify teams of upcoming release |
> > | 01 | Release project start |
> 
> The use of negative indices gets confusing when the start is week 1. Is
> there a week 0 or not? IMO the NixOS example where release week is 0 is
> intuitive. Countdown to release!
> 

Yeah, I'll change this, you're right "Countdown to release!"

> > ### Toolchain and transition freeze (week 04)
> > 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.
> 
> If Debian defines the term “transition” in a way that makes it
> meaningless for Guix, we shouldn’t reuse it. I don’t find it a very
> intuitive term anyway. Maybe “mass rebuild”? I know I’ve seen that term
> before in Guix contexts. Regardless, I don’t think restricting mass
> rebuilds for 8 weeks is viable. If we focus on the release set as is
> being discussed I don’t think we need to care about mass Haskell or R or
> Emacs rebuilds.
> 
> > 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 [^6].
> 
> The proposed branching model is not that similar to Nixpkgs, I think. In
> Nixpkgs they don’t bother with a next-master because master is only
> restricted for ~3 weeks.
> 
> While merges to and from the Nixpkgs staging branch are affected by the
> release process, the branch itself is not really tied to release
> stabilization. It is for grouping mass rebuilds and is used outside of
> release time too. I think we should drop the reference since next-master
> as it is proposed here is not really related to the Nixpkgs staging
> branch.
> 
> IMO we should drop the discussion of this next-master integration branch
> from the GCD and revisit it if it seems necessary during a release. In
> the context of the proposal to not freeze non-release critical package
> ecosystems it makes sense to me, anyway.
> 
> > * release branch: regularly merged from master, tracks the release artifacts.
> > * master branch: receives security and resolutions of RC bugs.
> > * next-master: everything that normally goes to master.
> 
> Why is the release branch created while master is still frozen for 3
> weeks?
(...)

This is from Efraim who believes it will be easier to merge from master into a release branch. It's essentially designed to do what you're suggesting by limiting the time period of any freeze on master, while ensuring the artefacts from the release aren't going to be broken on first pull.

> Sorry for the scattered email. Hopefully you find some of it valuable.
> Thanks again for your work on this!

I didn't address all your points, but thanks for the detailed feedback! Maybe you'll be interested on working on the first Release Team <hint> <hint> ;-))

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 07 Jun 2025 13:01:02 +0000
Resent-Message-ID: <handler.78332.B78332.174930122430058 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Philip McGrath <philip@HIDDEN>
Cc: Brian Cully <guix-devel@HIDDEN>, 78332 <at> debbugs.gnu.org, Liam Hupfer <liam@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174930122430058
          (code B ref 78332); Sat, 07 Jun 2025 13:01:02 +0000
Received: (at 78332) by debbugs.gnu.org; 7 Jun 2025 13:00:24 +0000
Received: from localhost ([127.0.0.1]:47312 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uNt9r-0007oj-8T
	for submit <at> debbugs.gnu.org; Sat, 07 Jun 2025 09:00:24 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:51676)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uNt9n-0007mt-Uy
 for 78332 <at> debbugs.gnu.org; Sat, 07 Jun 2025 09:00:21 -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 1uNt9f-00GpC0-DE; Sat, 07 Jun 2025 15:00:11 +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=+ZD+k31zGo9KqExV/R6D0/6EktnX3eHozR7hAYygn20=; b=1bJyKRz2DBOHITEnsPa/weYvms
 L7IxhBfTGwAx4Nub+STKpMwVMummd4H2KMZ4sOlOSWGQQQ71zRuayXe4jmwy+DSMEG2+GZPB9sFqB
 Hhxa4xqyPni6cXkB2SqXr33HOn7UgAzXDZrT4b30EM94h1m9wtucqwy4oLO4oyg/+6ym/ejR/g9Wy
 5cysoplY+VpPFritZrq8XjF2gPAZt1uQhNH0tXvz7SARFgVt5zcelOaJDjqrpV037TJmVkmML0t2F
 ai5sRX3QSSzthEpmngqgW76C/8gx8NDB5IgJnDDXqE3OjW37Y1Bxs13aS1bw6qX91wrvi/qitQZTW
 IMcA5ymw==;
Received: from [10.9.9.72] (helo=submission01.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uNt9e-0002Nk-TX; Sat, 07 Jun 2025 15:00:11 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uNt9e-00FTtU-1k; Sat, 07 Jun 2025 15:00:10 +0200
Date: Sat, 7 Jun 2025 14:00:00 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <um5uo2vnap6ilbehnbk5du4wd4teoobjnd4h5qzkwaklc75jbh@cmj67azvl5i3>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
 <dfeb265a-208b-48d5-93c3-5381a4eee76b@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <dfeb265a-208b-48d5-93c3-5381a4eee76b@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Philip,

Thank-you for the comments.

On Fri, Jun 06, 2025 at 03:13:30PM -0400, Philip McGrath wrote:
> Hi,
> 
> I share the concerns others have already described, particularly:
> 
> On Fri, Jun 6, 2025, at 12:41 AM, Liam Hupfer wrote:
> > I tend to agree with Andrew’s feedback
> > (<https://yhetil.org/guix-patches/87ikly5t74.fsf@HIDDEN>) and others; we
> > need to be very judicious about imposing processes in this GCD that the
> > volunteer community can’t properly support yet. As discussed, while
> > regular releases are a useful marketing tool, we have to avoid giving
> > the impression that users should stay on releases. For the foreseeable
> > future stable branches are out of scope, so these releases only exist to
> > provide a base for new installations and a rollback target of last
> > resort. Good to see the revisions moving in this direction.
> >
> > I agree with others’ feedback that we should be conservative with the
> > scope at first to avoid imposing on general progress. We should limit
> > ourselves to only what is necessary for foreign distros to ship Guix and
> > a base Guix System installer.
> >
> 
> To me, it seems important to clearly identify who is the audience for Guix releases and what use releases are meant to serve.
(...)

I answered the underlying "concern" in my email back to Liam (please see that): it directly addresses why this proposed change doesn't "impose work" on all developers. Also, that this GCD is "reversible" so if we can't achive regular releases there's no harm done and we fall-back to our current situation. That's why I think this is a "low risk" GCD.

On the topic of identifying "audience" and "use-cases" we do have some data (from the Survey) that tells us who our users are and what they care about. Looking at the history of the project it seems that wide-ranging discussions struggle to achieve consensus or land-up off-track (see previous discsussions about releases, archive structure changes, etc). So I think the GCD process (with the goal of consensus) is going to work best if we discuss small chunks with concrete outcomes that we can directly work towards consensus. Lower down you bring up users that install Guix from a distribution package, I believe the best way we can address that sort of "audience need" through the GCD is to concretely propose somthing - for example a GCD to separate the Guix daemon's timing.


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

I believe (from hanging out in IRC) that the main use-case for our current "release" installers (e.g. ones on the Web site) is by new adopters of Guix.

The Survey showed that about 50% adopt Guix as a distro, and 36% as a hosted package manager. Unfortunately, we don't have data on whether users use the "Guix package" from inside their distribution or whether they install through the binary installer on the Guix side.


(...)
> > PPS: Another release-related issue that isn’t discussed is backporting
> > critical patches. We didn’t backport patches for CVEs and tag 1.4.x
> > releases; distro maintainers had to apply them from blog posts. The blog
> > posts were helpful but that’s not how bug fixes should be shipped! I
> > help out with the Nix package and we’re carrying five patches now, four
> > of which are for CVEs. Maybe this is to prevent divergence where guix
> > pull thinks you are downgrading but we should look into how to handle
> > that better. Maybe patch releases can ship with the SHA for the latest
> > commit on master containing equivalent security patches embedded
> > somewhere in the Guix modules so ‘guix pull’ can treat that as the point
> > of comparison for downgrade warnings instead of the tag commit itself?
> 
> This discussion calls to mind that the Nix folks (IIUC) have a release cycle for their daemon that's different from that for their package set. From my perspective, the daemon and other software developed by Guix are the essential part of a release. Narrowing the scope and defining the audience might make it feasible to provide relevant security backports, an extremely valuable improvement.

Agreed, it's a really nice approach. I would like to know more about what the Nix project has learnt so that we can see if it's applicable to Guix.

I avoided suggesting any changes to the archive model as my understanding is that previous attempts failed. So I focused this GCD only on things that would make release easier.

If we move forward on this GCD, then I think we should have a look at this kind of separation, this could give us the flexibility to satisfy the timign challenges.


> >> 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
> >> the smallest set required for the initial environment.
> >
> > Is standard necessary? What’s the difference between minimal and
> > standard? These proposed sets seems to overlap with the teams concept
> > somewhat. Either the package is release-critical or it isn’t, and there
> > seems to be consensus that a functioning initial installation with a
> > graphical DE is critical. Can we simply define one “release set”?
> > Actually, based on the freezes you discuss later, maybe one “build set”
> > for toolchains and Guix, etc, and one “release set” encompassing the
> > build set as well as the (closure of) critical top level applications
> > like editors and DEs?
> >
> > ...
> >
> > PS: I took a look at the release manifest you mentioned and was
> > surprised to see how many options the installer proposes in
> > %system-packages. IMO we should feel empowered to drop quite a few of
> > those when preparing a release. Emacs, Vim, and Nano should be in the
> > release set but not EXWM, Ratpoison or Awesome. Anyone who wants to
> > install a WM can expected to have their first Guix system generation be
> > VT only or a more mainstream DE (or guix pull from a foreign distro and
> > build their own installer if desired). WMs can certainly be added to the
> > installer if interested parties choose to test them during the release
> > cycle but should not block the release once the release set is ready
> > (Bash, OpenSSH, GNOME, wpa-supplicant, etc). We can remove any broken
> > options from the installer before tagging. Ideally we should have
> > VM-based automated testing of any DEs offered in the installer as well.
> >
> 
> Overall, I also think this concept of "package sets" should be simplified and refined, or indeed replaced by existing concepts like teams and manifests.
> 
> For Guix on a foreign distro, "kernels, boot loaders, [and] filesystems" don't actually seem relevant as part of the release.
> 
> For the installer use case, again, I think it would help to clearly articulate the audience and purpose of releases. For example, one possibility (which may or may not make sense) might be, "A user who does not have command-line experience should be able to install Guix, boot the installed system, and use Emacs-Guix to execute `M-x guix-pull`." One reason that possibility might not make sense is that I'm not sure how completely Emacs-Guix replaces the need for command-line experience. If Guix effectively requires command-line experience already, I'm not sure *any* desktop environment should be a release-critical package. (To be clear, I think it's very valuable to support users who don't use the command line, I just think we should be clear about whether we currently do or not.)
> 
> With the context in mind that a better release process wouldn't replace the recommendation for an immediate `guix pull`, I also think the discussion of timing with respect to other distros and desktop environments is backwards. If Guix releases in June, packages of Guix in Ubuntu LTS (April of even-numbered years) and Debian Stable (c. summer of odd-numbered years) will be 10+ months old at time of release. The proposed benefit of getting a more recent desktop into a Guix release seems minimal: users on foreign distros will not use it at all, and Guix System users who follow our recommendation will use it only until their first `guix pull`. It would seem better to release in November or January to get an up-to-date Guix into LTS distros.
(...)

This one is interesting to me as I'm in the same situation as you. I mostly use Guix on top of other distributions. But, the difficulty is we can't satisfy the timing of the two needs:

1. Guix installed *from* a distribution package, hosted on top of another distribution
2. Guix as a Linux distribution

We are both an upstream (for a distro to package Guix) and a downstream (for us to package upstream software into packages).

The Survey showed that about 50% adopt Guix as a distro, and 36% as a hosted package manager. So, overall I think the timing leans towards making it easier for Guix to be a Linux distro.

It sounds like the longer-term solution is what you note above - Nix's approach of doing with separate daemon releases - we shoul consider that in a follow-up GCD.

Thanks!

Steve

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: "Philip McGrath" <philip@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 07 Jun 2025 19:36:01 +0000
Resent-Message-ID: <handler.78332.B78332.174932493421702 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: "Steve George" <steve@HIDDEN>
Cc: Brian Cully <guix-devel@HIDDEN>, 78332 <at> debbugs.gnu.org, Liam Hupfer <liam@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174932493421702
          (code B ref 78332); Sat, 07 Jun 2025 19:36:01 +0000
Received: (at 78332) by debbugs.gnu.org; 7 Jun 2025 19:35:34 +0000
Received: from localhost ([127.0.0.1]:49666 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uNzKH-0005dx-MO
	for submit <at> debbugs.gnu.org; Sat, 07 Jun 2025 15:35:34 -0400
Received: from fhigh-b7-smtp.messagingengine.com ([202.12.124.158]:60189)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <philip@HIDDEN>)
 id 1uNzKF-0005di-Vw
 for 78332 <at> debbugs.gnu.org; Sat, 07 Jun 2025 15:35:32 -0400
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 3543725400F1;
 Sat,  7 Jun 2025 15:35:26 -0400 (EDT)
Received: from phl-imap-01 ([10.202.2.91])
 by phl-compute-03.internal (MEProxy); Sat, 07 Jun 2025 15:35:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 philipmcgrath.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:subject
 :subject:to:to; s=fm1; t=1749324926; x=1749411326; bh=HEOLs7zhMA
 A/3vepYWCzB+B41gfIfgoBrPR3a41Utco=; b=L0RopfKPigNGFwgh8TBP4YMIRS
 ZcEUI5ooMDOJ67AijI4GrG1ASoBSDE79yKN0aDh7gPvRNfW0ySThrXfUmZbMO0SX
 N9at+Bx8M2r3JmWzLouNrPRnKucvEA3wNYWJf1O+cMhfatOXvQql/0TRn1ZgnCLI
 pdopyUGMELI0Eif267l8WN90uVWykY+PJbC50GHadmWsmg5BWP5aQbrrnJTOzf/B
 PSBHHQIcsUmq6uSLQAudUYg7UDaAFzAUFOGR7BgcXlhPl7xJDQlMmykiHXl4TSqd
 TD66rHVX+8q4eidRzS9z3gWoZwATmEteKhh27/+OCgzFSQacm/yFtf/2s7ZQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1749324926; x=
 1749411326; bh=HEOLs7zhMAA/3vepYWCzB+B41gfIfgoBrPR3a41Utco=; b=o
 bmhllO8fPgC13k8FQkRGmBvcEbjmJF4lLWrwFhLATitODeSIVTTGBK9eZLFRp8sT
 Ib2ezaIjK0BFOyQM0UFM6a8qUPSuhBgRjLrKVwkbFvOWzMfsSQvWj5V3eRwr1Skp
 DZb72zdWphZput7mKU2W9M3M0GnetsXhiJXUSx+zvn1Ixk2BVuDuIW3hM5wtgEzj
 c/Kcna/68x/WO8Iv6tA849YijYLJX+gvyU7LKFOobt14YG0Hn/F4W+IFOYM/uT42
 XAGIEWPXwj7enL1yvX8JDBbDDvt0zIP046gxLDzWFvkKt9rB3ivSx0wmT24hBzzy
 JM5XFoUIf/ccvf7JeftDw==
X-ME-Sender: <xms:fZREaHksWT8s1wu26-66o52d-1I9PmLozRZ7Hr19m6NRDotAsHybQw>
 <xme:fZREaK3Bbkxlw1mADEmsdqCAXYUmc0OFCXXhbj9GmeYfHuIhqe52Fui7dB3dYu0ki
 z17fP-GRm_wpDmmAhI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdeileehucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddt
 necuhfhrohhmpedfrfhhihhlihhpucfotgfirhgrthhhfdcuoehphhhilhhiphesphhhih
 hlihhpmhgtghhrrghthhdrtghomheqnecuggftrfgrthhtvghrnhepjeffgfelffeuhefh
 ledvudeujeduvdefuddvfeekiedvvdeuhfdvhfetleefvdeinecuvehluhhsthgvrhfuih
 iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpsehphhhilhhiphhm
 tghgrhgrthhhrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuth
 dprhgtphhtthhopeejkeeffedvseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthht
 ohepshhtvghvvgesfhhuthhurhhilhgvrdhnvghtpdhrtghpthhtohepghhuihigqdguvg
 hvvghlsehgnhhurdhorhhgpdhrtghpthhtoheplhhirghmsehhphhfrhdrnhgvth
X-ME-Proxy: <xmx:fZREaNo8BpbgbgzXZamll2XNO72B2uGVdwHBFfQqiDDgxtr6-RlrxA>
 <xmx:fZREaPkwL-UwUvgOGnsdslSAkCzyUO3VH5e7S-VEBLKhPV31cBER-w>
 <xmx:fZREaF1U50o643OOI5acE9V6jo7Z6xt5Pz5G42bzfJ3YRFF8IFMkgw>
 <xmx:fZREaOsV7aYyB7TiFIqTOL-cNxVCPbK13NWBVhTUpP-ukqitLOpLJw>
 <xmx:fpREaORVHeA5gR0ZVnG9KGQkEB0fYBPw3NQaDsHzALCz_MqrE0ve9PUX>
Feedback-ID: i2b1146f3:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501)
 id 4A64018C0062; Sat,  7 Jun 2025 15:35:25 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: T766667b5681f14b5
Date: Sat, 07 Jun 2025 15:35:04 -0400
From: "Philip McGrath" <philip@HIDDEN>
Message-Id: <0908c85a-debb-4b70-b8f4-170cfcf82521@HIDDEN>
In-Reply-To: <um5uo2vnap6ilbehnbk5du4wd4teoobjnd4h5qzkwaklc75jbh@cmj67azvl5i3>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
 <dfeb265a-208b-48d5-93c3-5381a4eee76b@HIDDEN>
 <um5uo2vnap6ilbehnbk5du4wd4teoobjnd4h5qzkwaklc75jbh@cmj67azvl5i3>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
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,

On Sat, Jun 7, 2025, at 9:00 AM, Steve George wrote:
> But, the difficulty is 
> we can't satisfy the timing of the two needs:
>
> 1. Guix installed *from* a distribution package, hosted on top of 
> another distribution
> 2. Guix as a Linux distribution
>
> We are both an upstream (for a distro to package Guix) and a downstream 
> (for us to package upstream software into packages).
>
> The Survey showed that about 50% adopt Guix as a distro, and 36% as a 
> hosted package manager. So, overall I think the timing leans towards 
> making it easier for Guix to be a Linux distro.
>

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

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

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

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

Philip

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
In-Reply-To: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
Resent-From: Sharlatan Hellseher <sharlatanus@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 08 Jun 2025 09:45:02 +0000
Resent-Message-ID: <handler.78332.B78332.174937588115115 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 78332 <at> debbugs.gnu.org
Cc: steve@HIDDEN
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174937588115115
          (code B ref 78332); Sun, 08 Jun 2025 09:45:02 +0000
Received: (at 78332) by debbugs.gnu.org; 8 Jun 2025 09:44:41 +0000
Received: from localhost ([127.0.0.1]:50741 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOCa0-0003vi-EC
	for submit <at> debbugs.gnu.org; Sun, 08 Jun 2025 05:44:40 -0400
Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:54386)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <sharlatanus@HIDDEN>)
 id 1uOCZx-0003vS-EM
 for 78332 <at> debbugs.gnu.org; Sun, 08 Jun 2025 05:44:39 -0400
Received: by mail-wr1-x436.google.com with SMTP id
 ffacd0b85a97d-3a4f78ebec8so2023189f8f.0
 for <78332 <at> debbugs.gnu.org>; Sun, 08 Jun 2025 02:44:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749375871; x=1749980671; darn=debbugs.gnu.org;
 h=mime-version:message-id:date:subject:cc:to:from:from:to:cc:subject
 :date:message-id:reply-to;
 bh=1ntnBqWzu/SLjbqyLjA8377Z3j4XVtPTDuHCOYUgPM4=;
 b=PdqQ/B8+OfkRQELu3qo0+9wykmxcNH9hVqtXGABJBCTsuckYaf7dgbdkGowU8eJ309
 hQU9fx7YJ8Wme1deOKxg2AfU3xzBa3R49Xy0R0S8wR/Au6CVuMH/F1g8VHyifkIQYUEV
 xZQEfYfLCgvQxKkzjUV1GkSVyaic1u8DnbwHgxD6h3Idk/ByX1CkYXnSR7egez/DSVBy
 C3B1AMxCS6yd8oe1pFpFH91IENul34tkhsFX25yeLQooEhs7KHp/c89jbHVWZiRGmcWM
 rp+/a6ndN2GrkGDE0BZP54wwVkyt6nABnvpD0q87QHlWUd2PUIBmVu9KO9aoNR269u19
 r0JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749375871; x=1749980671;
 h=mime-version:message-id:date:subject:cc:to:from:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=1ntnBqWzu/SLjbqyLjA8377Z3j4XVtPTDuHCOYUgPM4=;
 b=kILpXYiQjV74bCGOMsOb24bXRfo3m9huubWI5pc92oi/9VU6CXYxaskDQPutd3o8GS
 QsqZps72+8og72VZh0XMN605Xrc3hgOIt0494hJTXdM1GoeItO1dcAYWpqSPf2EUqA6Z
 e6oDa0A1ac1Edz6WdmjnHTzzHETZR416143F2oUh3AuP/Sanmk60QONsoS7LL4anNJkQ
 TKLGILdf0KG8v/p5ADjy9jyY0NiwfN//OZBIQRZE8rwLs7WDcsPsQWJRREMue5rIsH4c
 S1qFYYWFT2YS4+ctKUikhutLGi5FYZ/WvxZvWJp95yWb7Uo04PLrWMylNmaiguOFz9aQ
 XA7w==
X-Gm-Message-State: AOJu0YwEUW72HC5UvqiGI6LowVH8w8bD2zqU34AuJbc240ihjIYWZzri
 Ov/BB1HDJ3xmPsOalKzyho2bMsu9nO5az56EDrtaXt0HI9fL6Ufbq9lU
X-Gm-Gg: ASbGncus8KYAanDoCXddKYkGQJoye7ialmgVNReDmGzcmToZNu6yNJVm7FcmV+K3gB8
 EjATEi7z0ubmzJnjdmCYYWMeHe0QKniackhyWwTuqX4SCRTmCp0QjTw5/KATQFHeBrroTQhtR4j
 EVvKKGcl6hnDwVW3Qbq4N3HDCJfaTx/xXelv9+aGtRtcYq618LYn0BG4BFnmVm/zhvwY/wkVp15
 qMSDPFPw/3XqFRbv1iUw382DafuRS4l7/A35zKhH3L/PIXKRmqX4MS5gwIJ63DBDS3V5QNsadro
 i13LjC1EWyD/Z823onFvuqQ6qwWIlP6DYr2DYtC4dFEJ8UXOXo60GzklbXYl1AtJTVIMJpx2B7M
 dZ1JT4hJllDCZfK+lPVUjSnKI04+NcagJA1OmwQ==
X-Google-Smtp-Source: AGHT+IHBG0+YCkgod1MfdN2fInw8YoxI3eb+wjZcxMkSFAvomCTmZVGRcYvEjwIznvUTZh/jLqXtmw==
X-Received: by 2002:a05:6000:240b:b0:3a4:f8fa:9c94 with SMTP id
 ffacd0b85a97d-3a531caa070mr7995937f8f.13.1749375870918; 
 Sun, 08 Jun 2025 02:44:30 -0700 (PDT)
Received: from guxtil (cpc100684-bagu15-2-0-cust967.1-3.cable.virginm.net.
 [86.8.111.200]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a53244f516sm6730360f8f.74.2025.06.08.02.44.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 08 Jun 2025 02:44:29 -0700 (PDT)
From: Sharlatan Hellseher <sharlatanus@HIDDEN>
Date: Sun, 08 Jun 2025 10:44:25 +0100
Message-ID: <87tt4q4lfq.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: 0.0 (/)
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
Content-Transfer-Encoding: quoted-printable


Hi,

* Vote

=2D-> YES <--

* Reasoning

I see that the best effort of rapid refresh of the packages for
particular collections are already practiced in the project e.g. R
refresh by Ricardo.

From=20that experience I may say that it's much, much easier to keep hand
on pulse of upstream than spend weeks (Golang, the most of th Python,
Ruby, PHP, JavaScript, Perl, Java...) in endless effort to balance
too-much-dated-versions chains.

As we split efforts among teams already I think it's the next logical
step to agree on sort of predictable refresh schedule among them. The
only one constrain is a long waiting time in the queue e.g. go-team and
r-updates were waiting for about 2 months while were tested and ready to
be merged, I hope it something we may discuss in the separate thread.

The version tag of the Guix itself would benefit downstream packages
e.g. in Debian and would bring much nicer user experience, as for now I
noticed complains form foreign distro users on the need to way hours
even days before the first 'guix pull' is completed.

Workload pressure may be relaxed as well, as I mentioned above, it's
much easer to auto refresh and build recent version than resolve dated
package version dilemma, the same position here - yes it would need some
effort to keep on pace in a reasonable cadence with upstream but
comparing with amount of efforts required to bring from the older
version should be easier.

From=20the user experience (mostly complains on Mastodon), the stopping
point to select Guix over Nix is - dated versions for my lovely packages
stack, with understandable claim Guix has a much smaller team and
package maintenance is a hard task in general.

* Features and tooling

I've noticed in other projects - a version comparison in package
description with upstream [1] (available from the package manager and
current upstream).

Other one is a package refresh ration (it requires quite a lot of time
to collect [2]), for example how to answer this question for
commiter/contributer: If I need to list packages which defendant count
is less than 4 and refresh them all how can I do it quick?

More metadata for the package [3] which would help in maintenance or
addressing issues to the particular team which would be visible for the
user/contributor.

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

* My experiance

I try to keep Astro collection on the latest available versions where
possible and submit new packages and refreshes on each 20th of the month
and merge by the end of the month nearly 2y already, there are 200+ in
(gnu packages astronomy) and a few in other modules, it takes me up to
5-8h per month for that task: package some new ones from the planned [6]
list and refresh present ones where possible. Some tasks are required a
long loop, jumping to python-team to refresh lower level packages.

It's my personal preference, as I see it's easy for me to run "guix
refresh -s module:astronomy" and work through the whole collection than
resolving conflicts in dated version after n+1 months.

I can contribute some time "to drive a refresh train to the final depot"
(c) Simon Tournier, periodically.

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

1. <https://blends.debian.org/astro/tasks/python3>
2. <https://issues.guix.gnu.org/74268>
3. <https://packages.gentoo.org/packages/sci-astronomy/stellarium>
4. <https://aur.archlinux.org/packages/stellarium>
5. <https://www.juliapackages.com/packages/astrobase>
6. <https://git.sr.ht/~hellseher/ffab/tree/main/item/TODO.md>

=2D--
Oleg

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJKBAEBCgA0FiEEmEeB3micIcJkGAhndtcnv/Ys0rUFAmhFW3kWHHNoYXJsYXRh
bnVzQGdtYWlsLmNvbQAKCRB21ye/9izStXE4D/sGwrXvBuwyQ2sxU/+o2zHNCUEa
XFVnJHmAYtIVMizYe06uxrFEVUixUJxE/OWWOZkOh5LtVPPOOxMbQ8JaclO59zB/
wQjjf+bm54sFB4n6/V0dE9ZqcoVMLGar2vksAWeEIPUFBQxK7g5kzRVEH8TF3KJ3
4BzivS5b2q3PDzCf7yrdfJ+6vHCjY1miubmoqMkhu/QNb01TN2Utf/nXeWeUmgfY
98wMUZr/9Vz3pRwlmsGNpjhJs+sUa93XDTRCudOa9yWL5wfrsJwlJoN68oPz5aRO
u8zDhQ6XuttKup7DVFpqvD7WlMSbxd/EBEAkF7dU8OTiFWfwk0T8N81qFzZo3pUg
NU5556+vTg2eY79ZkjLDlG6nNPvwUEWyo8LYVMNWAiwPOh8CjJ8CrRVWhVa+hP0u
4dePkJNeFihIUkT7R91ny6MxXQ3hLVzJztQRC21mD3Q9HjvKZZUUbsWah06A7FBM
LUyiG1P7tTj6ztIhWZIZ0qMaEuY9G6gPTtaJ5Ul5qvQMH/R3UbyJKZkyLYwwQzCs
5ve0gwUeawuraL4xQBnY5iSUwZXwp272uUIWVPyru91RzefVD3s28Mfq7KSssd98
E1tG2vKocsdg5EbH5iJmqGGdryhwKBtrzhM+7aZctF9D9kuLy6/iYmGBp4kICv+s
GKGdtYEbxAOqLSRohg==
=I48S
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Leo Famulari <leo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 09 Jun 2025 02:26:02 +0000
Resent-Message-ID: <handler.78332.B78332.174943593313029 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174943593313029
          (code B ref 78332); Mon, 09 Jun 2025 02:26:02 +0000
Received: (at 78332) by debbugs.gnu.org; 9 Jun 2025 02:25:33 +0000
Received: from localhost ([127.0.0.1]:53411 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOSCa-0003O4-V4
	for submit <at> debbugs.gnu.org; Sun, 08 Jun 2025 22:25:33 -0400
Received: from fout-a7-smtp.messagingengine.com ([103.168.172.150]:33015)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <leo@HIDDEN>) id 1uOSCR-0003Ni-Sl
 for 78332 <at> debbugs.gnu.org; Sun, 08 Jun 2025 22:25:30 -0400
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.phl.internal (Postfix) with ESMTP id 110511380330;
 Sun,  8 Jun 2025 22:25:18 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-01.internal (MEProxy); Sun, 08 Jun 2025 22:25:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name;
 h=cc:cc:content-type:content-type:date:date:from:from
 :in-reply-to:in-reply-to:message-id:mime-version:references
 :reply-to:subject:subject:to:to; s=mesmtp; t=1749435918; x=
 1749522318; bh=OytVIzc1bNnpjwiN96kTVvf97LQbt+qGPEVutMxtJNE=; b=W
 LkWpAaiWzE87JhxE9G38RuyEGti4wAgBnYuM/jbCrC2ijqfa+/MRTA0U3MSCXfRn
 OMZWApUZoRQizVDrk7A6MNUGATmF2KkYWwY3Oykc+1ofHJJ33T+TxAOUH5rMd7eO
 m3ulEZUe6ptSaYh+P7q+fHx0WyZ74hX1oxE5JdF1lQ=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:subject:subject:to
 :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
 1749435918; x=1749522318; bh=OytVIzc1bNnpjwiN96kTVvf97LQbt+qGPEV
 utMxtJNE=; b=owBqOVrQryw2ofv6iwugAhIX1JQ/MCwMVQG3CRrlNJQxtp60L0M
 Y84S02Iwb9JSwelJOF9T7jbtKdsdeC0Uze8CQlhpb3RG8/rbFLDp0oM6WVY6gZ2B
 K5QtNaQ8TbR8Tp2jejXjNQYcauxqbdhrJO61zgeGR8A6ooCpPoQi2iX6K+OMvSt8
 zbqSIp7dfXhsntV06fdAY5fqW4q6Vx+YkZqtArqpgY58/RgeUuWMpmmoRgFuUC7/
 6e84nltwZdSkedl5Qo2+SOFeA82AAWKu/dNSuulCGytoy9ji+XErWPpANBaLEiMC
 AAKgI1ZTuBPOGWZGLexSHcUYrIQY9gOLn7w==
X-ME-Sender: <xms:DUZGaIfop2xur9wJGxrx1eupFyJ2-3FP_2c31CeNMgk5Xc8b-L5Vyg>
 <xme:DUZGaKNn0dTJ_cb4I68rw66dAUtz-0eA-h9MeaTbNLwNxP2r9C7vRZux83anwDHPL
 nm7VCQy0zGKa5tW6A>
X-ME-Received: <xmr:DUZGaJjq6Zu459-uW5--ohti35ENsuT_SaICIJjOcJdQft09AQrA2A2YwaJLa0mdjmQhnzN4qfvL2SWiaXz59dHf>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdekieelucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh
 htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvden
 ucfhrhhomhepnfgvohcuhfgrmhhulhgrrhhiuceolhgvohesfhgrmhhulhgrrhhirdhnrg
 hmvgeqnecuggftrfgrthhtvghrnhepieetudehfeekueefleegudfhjefgleehfeeluefh
 feffgfeuudelhedvjeelieetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe
 hmrghilhhfrhhomheplhgvohesfhgrmhhulhgrrhhirdhnrghmvgdpnhgspghrtghpthht
 ohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshhtvghvvgesfhhuthhurh
 hilhgvrdhnvghtpdhrtghpthhtohepjeekfeefvdesuggvsggsuhhgshdrghhnuhdrohhr
 gh
X-ME-Proxy: <xmx:DUZGaN_eYORXnFZGwrZObnWIILeUDOA-EsiwW4numes3Q72vNoeZXA>
 <xmx:DUZGaEsDU1n0Aw0qXcT6uODxbnuGMBntZvgT-QCaaAD080TEtE8IZQ>
 <xmx:DUZGaEFlWDHZOxXAR03weWtIAVqWP1X2Tx22LKAqBYM1RaNbkBXffQ>
 <xmx:DUZGaDMUJZb7Yx71sMazThxfTwdxejNc0lr1pWuhjL9kJv7CaWecmQ>
 <xmx:DkZGaFNTpDL1miZmuFyr1EURK3SERn2OdF-cXs462L8b9b8uFobJP0KW>
Feedback-ID: i819c4023:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 8 Jun 2025 22:25:17 -0400 (EDT)
Date: Sun, 8 Jun 2025 22:25:09 -0400
From: Leo Famulari <leo@HIDDEN>
Message-ID: <aEZGBdDWK27slg7u@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
X-Spam-Score: -0.7 (/)
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 Fri, May 09, 2025 at 01:53:39PM +0100, Steve George wrote:
> Below you'll find a proposal for moving to a regular release cycle.

First, my sincere thanks to you for making the effort to analyze the
situation, make a proposal, and shepherd the discussion.

Releases have always been a pain point for Guix, at least since I joined
around 2015. Of course, they seemed to get much harder as the codebase
and our ambitions grew. Now we have a binary for the package manager,
the source tarball, VMs, an installer image, desktops that we aim to
support, a variety of CPU types, two operating systems (Linux and Hurd),
etc. It's a huge amount of work on top of the Guix-specific difficulties
--- functional package management is tricky here --- that relate to
making a release.

In the past, we were able to freeze for a week here and there, but the
Guix project was much smaller and able to coordinate as a group, with
only a few committers, so it wasn't as hard to imagine a freeze as it is
now. We'd freeze for a few days and extend to a week when we had
trouble. Maybe it sounds crazy to freeze for 9 weeks, but compare us to
Debian or Linux. It's not necessary to deploy updates every minute of
the day. Git is decentralized and we all know how to use it.

Compare Guix releases to what's happened for TLS and web security since
Let's Encrypt automated the issuance and renewal of X.509 certificates.
That went from a manual, infrequent, expensive, and error-prone process
to something that is easy, automatic, and basically required for a web
site. TLS is everywhere now. Part of that process was a drastic
reduction in scope of what SSL / TLS meant. It used to be that an SSL
connection told you something about the people behind the web site. Only
trustworthy and capable organizations used SSL (banks, etc).  There were
tiers of certificates that somehow vouched for the web site. I'm not
sure if younger people realize the depth of that change. Let's Encrypt
said, "No, the certificate only means that the person that controls the
DNS name is serving you the data - nothing else. The connection is
confidential and authentic". It's purely a cryptographic construct now,
and TLS is ubiquitous. Nobody's bank account is getting hacked by a
rogue wifi network anymore.

BIG POINT:

Similarly, I recommend we make releases more automatic and more frequent
by reducing their scope. Until our capabilities grow to the point that
we can actually regularly create a bunch of release artifacts that have
been well tested for a bunch of platforms, let's figure out how to make
the minimum viable release from which users can install Guix and then
instantiate whatever it is they need.

We'd need to be creative here, from a technical point of view. I don't
know what this minimal release artifact is.

All the different CPU platforms, the Hurd, the desktops, the VMs...
people need to step up. The release team should not be validating that
stuff. The release needs to install a working Guix on Debian and Fedora.
Needs to install a bootable console on x86_64-linux (no, let's not ask
users to run `guix system init`). And maybe aarch64. But I wish we had
statistics of substitute downloads, to understand what people are
actually using. We should be bold.

People love releases. Releases are an occasion to celebrate. People make
t-shirts, stickers, have a drink on IRC, in Brussels, Bordeaux, and
Paris, and hopefully other places (any New Yorkers reading this???).
This kind of hoopla can entice people to join our project, and in the
long run we may gain the capability to do big complicated releases with
a bunch of artifacts again.

Also, our old releases work until they don't. We want SWH to save us
from bitrot, but our packages keep fighting us with little time bombs
that break the build after certain dates. We need releases to keep Guix
buildable for new installations. Guix is a build-from-source distro,
although we hide that well.

Personally I'm not sure we need a GCD here. The same leadership required
to issue a release is needed to land a controversial and disruptive
change. And making releases is not controversial or significantly
disruptive. I'd say you can just start planning the release now, Steve :)

Leo

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 09 Jun 2025 13:35:04 +0000
Resent-Message-ID: <handler.78332.B78332.174947609326904 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174947609326904
          (code B ref 78332); Mon, 09 Jun 2025 13:35:04 +0000
Received: (at 78332) by debbugs.gnu.org; 9 Jun 2025 13:34:53 +0000
Received: from localhost ([127.0.0.1]:54411 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOceI-0006za-CB
	for submit <at> debbugs.gnu.org; Mon, 09 Jun 2025 09:34:52 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:40626)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uOceF-0006yi-ON
 for 78332 <at> debbugs.gnu.org; Mon, 09 Jun 2025 09:34:48 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1uOce9-0000Fa-4L; Mon, 09 Jun 2025 09:34:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=apFNqDw3ROcFCwTQ2YFrgalgaryARPHjPuVWgyLmT20=; b=qak9SVXdU5KVlB8p+7Jb
 suigaeaPUXgHyi42p96+K2XEWLufuhPKFrwN1H9FCtpJl7SSq+odYaQuL7JhXLTBUE5Ai57tRWXn4
 mCHWuTLItyg/X3KCe9gz9zeixd7x405wl90Y1pTFefVI+A9NFbbG+HTGqLl4us7GOYgochm/GKTSR
 eS2l4GCFLpIrXNUEVewG724J4ZmohGNgjWXJH/kwbmt6Rt8dFUcbn+qIcRNwf58DtWJ8vvs65PxZD
 tMl5omgFBueoDnzR9xQOR+1//fb+eZsInpk5ZmA9MxeET33zoHYA3jf4qJa3E5707J38ShPVNFSwu
 QzA4krYxxJtjlA==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 (Steve George's message of "Wed, 21 May 2025 18:10:13 +0100")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
User-Agent: mu4e 1.12.11; emacs 29.4
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Primidi 21 Prairial an 233 de la =?UTF-8?Q?R=C3=A9volution,?= jour du Barbeau
Date: Mon, 09 Jun 2025 15:34:26 +0200
Message-ID: <87o6ux82e5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
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: -3.3 (---)

Hi Steve,

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

Some wondered about the indented audience of releases.  To me it=E2=80=99s =
quite
clear that it=E2=80=99s manifold: there=E2=80=99s public relation, yes, but=
 also
downstream packagers as mentioned, and perhaps more importantly, any new
person installing Guix, be it standalone or on another distro.  Starting
today from 1.4.0 makes for a terribly bad user experience.

Some more specific comments:

> The package sets would be:
>=20
> * 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.

Perhaps I overlooked it, but it=E2=80=99s not clear to me how package sets
affect the release process.

I would expect things like =E2=80=9Cpackage set X must successfully build o=
n all
Primary Architectures at time of release=E2=80=9D, =E2=80=9Cpackage set Y i=
s provided on
a best-effort basis=E2=80=9D, or things along these lines.

For previous releases, there were really two package sets of sorts,
although that wasn=E2=80=99t formally specified:

  =E2=80=A2 Packages that the Guix System installer would offer had two bui=
ld on
    the two architectures for which images were provided (i686-linux and
    x86_64-linux).  That includes core packages but also things like
    Xfce, GNOME, Tor, ntpd, and other things that can be selected from
    the dialog boxes of the installer.

    This is =E2=80=98%system-packages=E2=80=99 in =E2=80=98etc/manifests/re=
lease.scm=E2=80=99.

  =E2=80=A2 =E2=80=9CCore=E2=80=9D packages that anyone may wish to install=
 on any of the
    architectures supported by Guix (not Guix System).

    This was =E2=80=98%base-packages=E2=80=99 in
    <https://codeberg.org/guix/guix/src/commit/12d00767f036029f1f5738de644d=
4972db374f4f/etc/manifests/release.scm>
    (not sure why it=E2=80=99s not there anymore).

The former had to be build on x86_64-linux and i686-linux; the latter
had to build on all architectures listed in =E2=80=98SUPPORTED_SYSTEMS=E2=
=80=99 in
=E2=80=98Makefile.am=E2=80=99, and also listed in the manual:

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

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

> ## Release artifacts
>=20
> Using the primary architecture tier and the package sets would involve cr=
eating
> the following release artifacts:
>=20
> - GNU Guix System ISO image
> - GNU Guix System QCOW2 image
> - GNU Guix installer

This omits two important things:

  =E2=80=A2 The binary tarball, used to install on top of another distro, f=
or
    all =E2=80=9Csupported architectures=E2=80=9D (Primary and Alternative).

  =E2=80=A2 The source tarball, as produced by =E2=80=98make dist=E2=80=99 =
(target audience is
    primarily downstream packagers, such as Debian).

Reducing toil will be a matter of defining =E2=80=9Csupported architectures=
=E2=80=9D in
a reasonable way.

> ## Release team and project

I really like this section!

> ### 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.

This raises the question of who will nominate the team.  But perhaps
that=E2=80=99s a problem mostly for the first release (Nov. 2025) since aft=
er
that passing on the torch will be easier?

> ### 3. Release project start
> Start the project with weekly updates to guix-dev and regular meetings of=
 the

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

> ### 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.

In the past, what we did was to create a =E2=80=98version-1.4.0=E2=80=99 (o=
r similar)
branch one or two weeks before release and would let =E2=80=98master=E2=80=
=99 live its
life, avoiding both total freeze and unintentional breakage while we=E2=80=
=99re
close to release (only people working on the release would commit to
that version branch).

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

It=E2=80=99s very similar to what you wrote here but by keeping the default
unchanged for developers not part of the Release Team, it may prove to
work better.

> ### 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.
>=20
> Any non-building packages are removed.

According to the deprecation policy, this can be done anytime but takes
at least one month.

Overall I like what the GCD lays out.  Perhaps there will be adjustments
to be made here and there but it looks sensible to me.

I expect that a big chunk of the work before the November release will
be streamlining the process, in particular ensuring that a developer can
make a release without having too many privileges or a
multi-architecture build farm at home.

Thank you!

Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 10 Jun 2025 07:30:02 +0000
Resent-Message-ID: <handler.78332.B78332.174954058023591 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Leo Famulari <leo@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174954058023591
          (code B ref 78332); Tue, 10 Jun 2025 07:30:02 +0000
Received: (at 78332) by debbugs.gnu.org; 10 Jun 2025 07:29:40 +0000
Received: from localhost ([127.0.0.1]:60404 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOtQS-00068R-2a
	for submit <at> debbugs.gnu.org; Tue, 10 Jun 2025 03:29:40 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:56320)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uOtQN-00067i-OU
 for 78332 <at> debbugs.gnu.org; Tue, 10 Jun 2025 03:29:37 -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 1uOtQE-006nTS-UD
 for 78332 <at> debbugs.gnu.org; Tue, 10 Jun 2025 09:29:26 +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=/wbGpqOmc07Qn00+9ApSneyRhBXQf6Zivl2vbwtIi5k=; b=oi6MBzGZpO8bsZBPkzXsl9vQY4
 YvTZGroZccClazlwnqos+lN9B2XGJlkqO7UaVPTiUhFsbUC1UPaMyJRCYmLoHgvD7FWqtZN2fCDc2
 d3S7TKcbxgLZdhpAJkhiyYPaojaazlRfvBmU5isefeVvTu+c3QXA8E2bSUbJYkMEMGOPWuOJEm9an
 mKnUh7bV0hMYoqlD2kYapQY8945Y0YmP+zW5DVntCdfZLMNDTQmXh2M2G9DJkUtpACvq2GpgPik5B
 wAY9LOM6qd9f/YdutwqqA5rOnYmlODOhz7XW5to5KAiEddNIJo6FSHUNkLxAsGoQO79tYW6FIzUm3
 zSZYYa3Q==;
Received: from [10.9.9.74] (helo=submission03.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uOtQE-0005EU-8n; Tue, 10 Jun 2025 09:29:26 +0200
Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uOtQ2-000khG-Bq; Tue, 10 Jun 2025 09:29:14 +0200
Date: Tue, 10 Jun 2025 08:29:13 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <w7igu5yaiot64672pmpmmxgxcesvfc4m2oas5s6rpvhb7lfhhs@lxtqwfrz4ddh>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <aEZGBdDWK27slg7u@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <aEZGBdDWK27slg7u@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Leo,

On Sun, Jun 08, 2025 at 10:25:09PM -0400, Leo Famulari wrote:
> On Fri, May 09, 2025 at 01:53:39PM +0100, Steve George wrote:
(...) 
> Releases have always been a pain point for Guix, at least since I joined
> around 2015.

Thanks for the feedback, it's really useful to have input from a longer time-frame in the project. 

At the end you said:

> Personally I'm not sure we need a GCD here. The same leadership required
> to issue a release is needed to land a controversial and disruptive
> change. And making releases is not controversial or significantly
> disruptive.

I kind of agree, and actually I started writing a release plan and then landed up writing a GCD.

The reason I changed path is because I saw a lot of discussions and calls for a release at different times within the project. But we didn't manage as a group to make it happen. For me, that points to us not be aligned as a group and not prioritising releases.

So the purpose of the GCD is that as a group we say "we want to do regular releases" and the impact is that we'll work together to do so: for those that don't want to work on a release the ask is not to do anything that makes creating a release more difficult.


(...) 
> Compare Guix releases to what's happened for TLS and web security since
> Let's Encrypt automated the issuance and renewal of X.509 certificates.
> That went from a manual, infrequent, expensive, and error-prone process
> to something that is easy, automatic, and basically required for a web
> site. TLS is everywhere now. Part of that process was a drastic
> reduction in scope of what SSL / TLS meant. It used to be that an SSL


> Similarly, I recommend we make releases more automatic and more frequent
> by reducing their scope. Until our capabilities grow to the point that
> we can actually regularly create a bunch of release artifacts that have
> been well tested for a bunch of platforms, let's figure out how to make
> the minimum viable release from which users can install Guix and then
> instantiate whatever it is they need.
> 
> We'd need to be creative here, from a technical point of view. I don't
> know what this minimal release artifact is.
(...)

I absolutely agree that we get better at what we practise, so if we release more we can learn and iterate - we'll improve.

It's a great thought experiment of what we would do differently. This is one area where my previous experiences probably doesn't help as I'm a bit "stuck" on the level quality and work that a good release has to have in it. Yeah, it's an interesting question of what a "minimum viable release" would look like from a project and user perspective.

The GCD basically said "reduce complexity by" focusing on:

- fewer packages than the whole archive
- fewer architectures
- fewer release artefacts

I've added a focus on automation in the GCD - your framing is a good way to really think about this.


> All the different CPU platforms, the Hurd, the desktops, the VMs...
> people need to step up. The release team should not be validating that
> stuff. The release needs to install a working Guix on Debian and Fedora.
> Needs to install a bootable console on x86_64-linux (no, let's not ask
> users to run `guix system init`). And maybe aarch64. But I wish we had
> statistics of substitute downloads, to understand what people are
> actually using. We should be bold.
> 
> People love releases. Releases are an occasion to celebrate. People make
> t-shirts, stickers, have a drink on IRC, in Brussels, Bordeaux, and
> Paris, and hopefully other places (any New Yorkers reading this???).
> This kind of hoopla can entice people to join our project, and in the
> long run we may gain the capability to do big complicated releases with
> a bunch of artifacts again.
(...)

Yeah, it would be great to have some of that love for the project!


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

Hah hah hah!

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 11 Jun 2025 12:27:02 +0000
Resent-Message-ID: <handler.78332.B78332.174964482111714 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Philip McGrath <philip@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174964482111714
          (code B ref 78332); Wed, 11 Jun 2025 12:27:02 +0000
Received: (at 78332) by debbugs.gnu.org; 11 Jun 2025 12:27:01 +0000
Received: from localhost ([127.0.0.1]:47964 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPKXk-00032q-3h
	for submit <at> debbugs.gnu.org; Wed, 11 Jun 2025 08:27:00 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:38804)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uPKXg-00032T-Di
 for 78332 <at> debbugs.gnu.org; Wed, 11 Jun 2025 08:26:58 -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 1uPKXZ-00ALEY-KQ; Wed, 11 Jun 2025 14:26:49 +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=PkxDJ7A1fq5GbF05hMy/pdwhjguz+VZzUhpTOFNwXXc=; b=YBdhvNRAGSGtK4hdM0gyG8FUkv
 Ohv008/aSJHDawSQBJuMDrBxlXGgo06UcfZaxP/VEETzNP2MysdyEV7ZUM7jg+K/Os2Y+yyAFjfhf
 cFlnBtu/IeBMXE6a+VRah06FiCPPNcPWH6Q/GWor0JLgz0Yhrd6Ow1bmD+t8GYiRx4GhKFCQZJ21B
 LDnkAhdep5kCksDfKisH23Wi+ILJNmzb/ulfdjC9Rc9bUCiCJ4H1ZHUOCROcLZWRmjL/uBAoziT4/
 HX4qau39DNvRHrb/1Pg9FNx0Y4V553eOr7/aEUvb55rBLLKUkCRK1NAleJWYmn63yU3I1KeVUKMnx
 OPugRpEw==;
Received: from [10.9.9.73] (helo=submission02.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uPKXZ-0006nq-3F; Wed, 11 Jun 2025 14:26:49 +0200
Received: by submission02.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uPKXT-009iLw-SU; Wed, 11 Jun 2025 14:26:44 +0200
Date: Wed, 11 Jun 2025 13:26:42 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87o6ux82e5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87o6ux82e5.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Ludo,

Thanks for the feedback and insights.

On Mon, Jun 09, 2025 at 03:34:26PM +0200, Ludovic Courtès wrote:
> Hi Steve,
> 
> Thanks for the hard work on this crucial aspect of the project.
> 
> Some wondered about the indented audience of releases.  To me it’s quite
> clear that it’s manifold: there’s public relation, yes, but also
> downstream packagers as mentioned, and perhaps more importantly, any new
> person installing Guix, be it standalone or on another distro.  Starting
> today from 1.4.0 makes for a terribly bad user experience.
> 
> Some more specific comments:
> 
> > 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.
> 
> Perhaps I overlooked it, but it’s not clear to me how package sets
> affect the release process.
> 
> I would expect things like “package set X must successfully build on all
> Primary Architectures at time of release”, “package set Y is provided on
> a best-effort basis”, or things along these lines.

Maybe it's a bit too diffuse in what is a long document, it says:

"Packages within the `package sets` must build on the primary architectures (see definition lower).  As part of the release's QA contributors would be asked to these these packages."

Practically:

1. Package sets build on the primary architecture. All other packages are "best effort". 
2. Testing and manual QA is only on package sets on the primary architecture.
3. Release artefacts are only made from packages within the packages sets and on the primary architectures. 


> For previous releases, there were really two package sets of sorts,
> although that wasn’t formally specified:
> 
>   • Packages that the Guix System installer would offer had two build on
>     the two architectures for which images were provided (i686-linux and
>     x86_64-linux).  That includes core packages but also things like
>     Xfce, GNOME, Tor, ntpd, and other things that can be selected from
>     the dialog boxes of the installer.
> 
>     This is ‘%system-packages’ in ‘etc/manifests/release.scm’.
> 
>   • “Core” packages that anyone may wish to install on any of the
>     architectures supported by Guix (not Guix System).
> 
>     This was ‘%base-packages’ in
>     <https://codeberg.org/guix/guix/src/commit/12d00767f036029f1f5738de644d4972db374f4f/etc/manifests/release.scm>
>     (not sure why it’s not there anymore).
> 
> The former had to be build on x86_64-linux and i686-linux; the latter
> had to build on all architectures listed in ‘SUPPORTED_SYSTEMS’ in
> ‘Makefile.am’, and also listed in the manual:
> 
>   https://guix.gnu.org/manual/devel/en/html_node/GNU-Distribution.html
> 
> I would tend to formalize on these two package sets and associated
> requirements.
(...)

Thanks for the context, that really helps. I believe the version Efraim's been working on is here:

https://codeberg.org/guix/guix/src/commit/15e19a2d9206da8d1fe26f93573a41f16998462c/etc/manifests/release.scm

The main goal is to focus attention during testing, particularly as there's always some level of manual testing by a Release Team. Efraim's version still has the %system-packages, and what I would propose is to tighen it up further:

- %system_packages (what I called minimal): requirements for the installer including a default graphical desktop.
- %desktop_packages (what I called desktop): additional graphical desktops, other options like NTP and Tor. 

The Release Team would focus testing on the things on the installer's critical path. In Efraim's version there's actually three sets - %bootloader_packages, %filesystem_packages and %system_packages. Anyway, these all MUST work because they align with the installers defaults. Failures in these packages are release critical bugs.

Practically this means testing the end-to-end install process of Guix System with these defaults on (a) primary architectures (x86 and AArch64), also through KVM (QCow2 image), and tested on the major foreign distribution's (e.g. Debian, Fedora, Ubuntu).

Non-default packages that are in the installer (but not a default option) go into (a new) %desktop_packages. These get the next layer of testing, these SHOULD work as we shouldn't ship something we know is broken, but it's less critical. We're assuming that each Team is shipping things that work, and it's 'reasonable efforts' for the Release Team to try and check that the installer works for them.

This focuses attention by reducing the scope that the release team "must" test.

I also proposed a "minimal" group which would be "packages required to boot and install a minimal Guix or Guix System". Is it the same idea as %base_packages? I'm wondering if we should separate "Guix installed as a packge manager" into it's own package set. In the long run this would be a building lock that allow us to align with Philip's suggestion of following a more Nix-packages / Nix OS separation of releases. What do you think?


> > ## 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
> 
> This omits two important things:
> 
>   • The binary tarball, used to install on top of another distro, for
>     all “supported architectures” (Primary and Alternative).
(...)

OK, I can add them to the GCD.

Just to clarify terms, I'm looking at the download page (https://guix.gnu.org/en/download/)

What you're calling the "binary tarball" is that on the download page as the third option labeled "GNU Guix 1.4.0 Binary"?  I thought that was what I was calling the "GNU Guix installer".


>   • The source tarball, as produced by ‘make dist’ (target audience is
>     primarily downstream packagers, such as Debian).
> 

On the download page this is defined as "GNU Guix 1.4.0 Source". I will add this.

We don't have anything about the downstream Debian/Fedora packages. Philip McGrath mentioned this as an important path and I agree. Since we don't create the packages I'm not sure what to do here. Ideally, we'd work with the packagers to co-ordinate with them, but as a project we don't actually create them.


> Reducing toil will be a matter of defining “supported architectures” in
> a reasonable way.
> 
> > ## Release team and project
> 
> I really like this section!
> 
> > ### 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.
> 
> This raises the question of who will nominate the team.  But perhaps
> that’s a problem mostly for the first release (Nov. 2025) since after
> that passing on the torch will be easier?

At Guix Days (2025) there was a big discussion about releasing. Efraim nominated himself as the first "Release Manager".

I'm sure that there are others in the group would also be interested, there was a good discussion in December. I'm sure that Andreas and I would be excited to work on it!

And, I'm assuming _you_ are mentoring us all ;-))


> > ### 3. Release project start
> > Start the project with weekly updates to guix-dev and regular meetings of the
> 
> s/guix-dev/`guix-devel`/
> 

Thanks

> > ### 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.
> 
> In the past, what we did was to create a ‘version-1.4.0’ (or similar)
> branch one or two weeks before release and would let ‘master’ live its
> life, avoiding both total freeze and unintentional breakage while we’re
> close to release (only people working on the release would commit to
> that version branch).
> 
> The version branch would be prioritized by ci.guix.gnu.org too.
> 
> It’s very similar to what you wrote here but by keeping the default
> unchanged for developers not part of the Release Team, it may prove to
> work better.
> 
> > ### 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.
> 
> According to the deprecation policy, this can be done anytime but takes
> at least one month.
(...)

Understood. I have it now that in week 3 we identify things to be removed and notify everyone. In week 10 they are removed, so there's been a good long period of notification.


> Overall I like what the GCD lays out.  Perhaps there will be adjustments
> to be made here and there but it looks sensible to me.
> 
> I expect that a big chunk of the work before the November release will
> be streamlining the process, in particular ensuring that a developer can
> make a release without having too many privileges or a
> multi-architecture build farm at home.
(...)

Agreed, the real work is not the actual GCD heh heh =-)

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Efraim Flashner <efraim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 11 Jun 2025 13:42:02 +0000
Resent-Message-ID: <handler.78332.B78332.17496492944915 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, Philip McGrath <philip@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17496492944915
          (code B ref 78332); Wed, 11 Jun 2025 13:42:02 +0000
Received: (at 78332) by debbugs.gnu.org; 11 Jun 2025 13:41:34 +0000
Received: from localhost ([127.0.0.1]:48541 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPLht-0001HA-0N
	for submit <at> debbugs.gnu.org; Wed, 11 Jun 2025 09:41:34 -0400
Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:42323)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <efraim.flashner@HIDDEN>)
 id 1uPLhm-0001Ge-HY
 for 78332 <at> debbugs.gnu.org; Wed, 11 Jun 2025 09:41:30 -0400
Received: by mail-wm1-x32e.google.com with SMTP id
 5b1f17b1804b1-451e2f0d9c2so8327385e9.1
 for <78332 <at> debbugs.gnu.org>; Wed, 11 Jun 2025 06:41:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749649280; x=1750254080; darn=debbugs.gnu.org;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender:from:to
 :cc:subject:date:message-id:reply-to;
 bh=54Mle2g3pBwPXMfTxw+FQHpluPvO0rFdoB5k0OvRgLY=;
 b=R0netTd8+OWFk25Hac9BCYN624+MJlufPA+iTzd+sOhIYvyJKdIgxkHQ5erVveERHt
 hGHTQk74fG5BBko1NSSbwkeoxqvMFTJW2DZYak9HOUw8FmW8a7RS/HULkPF+VGRFL4ly
 cQOTe7OMUZUt0Vnx148ZqGLoio6qNTqxaxTTn8YSJcgI/T7FJ6v7r9dDwvjaMqCgCTWK
 C/CJ5Mp7QurgSdBOMdC69T0Xt9RFYkxnIlf+/i0gB9G/Ci+hcGzReZoPAu9FwEeKXxL3
 rne6ncW/8dUkdYwAyS/pLkOLP2262JdIT003s2GJhvdy+mj0gPGSTlB+/b8KOs8ikgzL
 XM4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749649280; x=1750254080;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=54Mle2g3pBwPXMfTxw+FQHpluPvO0rFdoB5k0OvRgLY=;
 b=WmDaMlimSgsSQPWPm5imfUmBPPAH85L1Y85qRYUUu1NdmEZzmBFuL1snEYk0o2+14z
 AidJjhF6TSe0GZadpLqkwYEIIRkd6oJnDfTPJLiPvu1sMcs4u8m8qcIei0VLdutPZabQ
 ZNq+csBSp56zfCHcDsCa0EPZ54V+dqR7hp19apFRc+X5A7oT1rV+P2nqkEqEYkr3hPj3
 EvOSsvfEA0skPfLxyvu3yXM523u24lF1vBmUYwk30wyZawh7PQImaCbG2lTJAH5h6p/r
 2FDrfKV8TG1xtVjjTf1ysnV9C8t00WTeFhPryPkAgwkm1gGhHLEYYK1SH3ANDPdRw/RD
 EOGQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCVqPr8FShSlorUHoreI4M1MEbZCCzt50j4hbqyl0o43a9x7EdwROahCEfhw6/GxIItNXj/mPQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzF/lcF4S67vCSruXO3c1FRvNhAlhYHvexp4Ud1ZgPT3bLH7VvT
 r5EUkDKMloiCe3jqNhM104llXBfzckf+4kQoCyB5qGNzpdK3GOkia5ujdxgoAMRI
X-Gm-Gg: ASbGncvlzi9e3zEgpDcQ2MO280hgE7PRRgGFlaokLbCnvURiiOauFBGVKJrXFNdA5L+
 yHxUHa1XCa83t6kxEUYupW9E/RZQUf64ekVvJXkBo1nOCgGw92ZKDpU0BKzZ0EpILklHu4YXAbx
 ebGWQ/6m2e1y9ljHoIShTDl0IGn890KspKYkNSyOgyuXxgAsKsQVIxLYgU4t9LjaL++G5N8SzLa
 CD5i3FiVdZ0EG1bzU9xCOWHl8pouSXiz2Ooey/GxAoPfsMJusTVP0ErHiUjS+CfuhX1WEIoi5ts
 eJX5dBVOU4wUvJnpuCG5/Wiib5shVysc8pckvjV+lgRWCBy7abJ2hXzdd1+o
X-Google-Smtp-Source: AGHT+IGpjsTmQrIOaUJfnYDj+WFgsz5TUPwH39tJ3SwX8n24CPez3JjxhXjlKKkKGppuJ1Cto+nORA==
X-Received: by 2002:a05:600c:1c1b:b0:450:c9e3:91fe with SMTP id
 5b1f17b1804b1-4532400d34fmr32765695e9.0.1749649279553; 
 Wed, 11 Jun 2025 06:41:19 -0700 (PDT)
Received: from localhost ([141.226.13.68]) by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-45325228c2esm21796815e9.37.2025.06.11.06.41.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 11 Jun 2025 06:41:18 -0700 (PDT)
Date: Wed, 11 Jun 2025 16:41:16 +0300
From: Efraim Flashner <efraim@HIDDEN>
Message-ID: <aEmHfDluw6ZSCQ12@3900XT>
Mail-Followup-To: Steve George <steve@HIDDEN>,
 Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, guix-devel@HIDDEN,
 78332 <at> debbugs.gnu.org, Philip McGrath <philip@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87o6ux82e5.fsf@HIDDEN>
 <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="ZYHnpxisCp11mTn4"
Content-Disposition: inline
In-Reply-To: <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
X-PGP-Key-ID: 0x41AAE7DCCA3D8351
X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc
X-PGP-Fingerprint: A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
X-Spam-Score: 0.1 (/)
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: -0.9 (/)


--ZYHnpxisCp11mTn4
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 11, 2025 at 01:26:42PM +0100, Steve George wrote:
>=20
> Hi Ludo,
>=20
> Thanks for the feedback and insights.
>=20
> On Mon, Jun 09, 2025 at 03:34:26PM +0200, Ludovic Court=C3=A8s wrote:
> > Hi Steve,
> >=20
> > Thanks for the hard work on this crucial aspect of the project.
> >=20
> > Some wondered about the indented audience of releases.  To me it=E2=80=
=99s quite
> > clear that it=E2=80=99s manifold: there=E2=80=99s public relation, yes,=
 but also
> > downstream packagers as mentioned, and perhaps more importantly, any new
> > person installing Guix, be it standalone or on another distro.  Starting
> > today from 1.4.0 makes for a terribly bad user experience.
> >=20
> > Some more specific comments:
> >=20
> > > The package sets would be:
> > >=20
> > > * minimal: packages required to boot and install a minimal Guix or Gu=
ix 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 us=
es.
> > > * desktop: provides the packages necessary for a desktop.  This would=
 include
> > > things like X11/Wayland, desktop environments, key applications and t=
hemes.
> > > * server: provides packages and services for a server.  This would in=
clude
> > > standard server packages and services.
> > > * hosted: provides packages and services which are necessary in hoste=
d usage.
> >=20
> > Perhaps I overlooked it, but it=E2=80=99s not clear to me how package s=
ets
> > affect the release process.
> >=20
> > I would expect things like =E2=80=9Cpackage set X must successfully bui=
ld on all
> > Primary Architectures at time of release=E2=80=9D, =E2=80=9Cpackage set=
 Y is provided on
> > a best-effort basis=E2=80=9D, or things along these lines.
>=20
> Maybe it's a bit too diffuse in what is a long document, it says:
>=20
> "Packages within the `package sets` must build on the primary architectur=
es (see definition lower).  As part of the release's QA contributors would =
be asked to these these packages."
>=20
> Practically:
>=20
> 1. Package sets build on the primary architecture. All other packages are=
 "best effort".=20
> 2. Testing and manual QA is only on package sets on the primary architect=
ure.
> 3. Release artefacts are only made from packages within the packages sets=
 and on the primary architectures.=20
>=20
>=20
> > For previous releases, there were really two package sets of sorts,
> > although that wasn=E2=80=99t formally specified:
> >=20
> >   =E2=80=A2 Packages that the Guix System installer would offer had two=
 build on
> >     the two architectures for which images were provided (i686-linux and
> >     x86_64-linux).  That includes core packages but also things like
> >     Xfce, GNOME, Tor, ntpd, and other things that can be selected from
> >     the dialog boxes of the installer.
> >=20
> >     This is =E2=80=98%system-packages=E2=80=99 in =E2=80=98etc/manifest=
s/release.scm=E2=80=99.
> >=20
> >   =E2=80=A2 =E2=80=9CCore=E2=80=9D packages that anyone may wish to ins=
tall on any of the
> >     architectures supported by Guix (not Guix System).
> >=20
> >     This was =E2=80=98%base-packages=E2=80=99 in
> >     <https://codeberg.org/guix/guix/src/commit/12d00767f036029f1f5738de=
644d4972db374f4f/etc/manifests/release.scm>
> >     (not sure why it=E2=80=99s not there anymore).
> >=20
> > The former had to be build on x86_64-linux and i686-linux; the latter
> > had to build on all architectures listed in =E2=80=98SUPPORTED_SYSTEMS=
=E2=80=99 in
> > =E2=80=98Makefile.am=E2=80=99, and also listed in the manual:
> >=20
> >   https://guix.gnu.org/manual/devel/en/html_node/GNU-Distribution.html
> >=20
> > I would tend to formalize on these two package sets and associated
> > requirements.
> (...)

(define %base-packages
  ;; Packages that must be substitutable on all the platforms Guix supports.
  (map specification->package
       '("bootstrap-tarballs" "gcc-toolchain" "nss-certs"
         "openssh" "emacs" "vim" "python" "guile" "guix")))

I realize that they are important packages, but they're all packages
that, if they broke, we would've noticed anyway (perhaps not
bootstrap-tarballs).  And then we had special cases for armhf and for
the hurd since we had a bunch of packages which didn't build.  There
were also the cross-build packages which I moved to a separate manifest,
which I expanded from the small list to all of the %base-packages list
used in Guix System, with a special-case for the hurd to remove some
Linux specific ones.

> Thanks for the context, that really helps. I believe the version Efraim's=
 been working on is here:
>=20
> https://codeberg.org/guix/guix/src/commit/15e19a2d9206da8d1fe26f93573a41f=
16998462c/etc/manifests/release.scm
>=20
> The main goal is to focus attention during testing, particularly as there=
's always some level of manual testing by a Release Team. Efraim's version =
still has the %system-packages, and what I would propose is to tighen it up=
 further:
>=20
> - %system_packages (what I called minimal): requirements for the installe=
r including a default graphical desktop.
> - %desktop_packages (what I called desktop): additional graphical desktop=
s, other options like NTP and Tor.=20
>=20
> The Release Team would focus testing on the things on the installer's cri=
tical path. In Efraim's version there's actually three sets - %bootloader_p=
ackages, %filesystem_packages and %system_packages. Anyway, these all MUST =
work because they align with the installers defaults. Failures in these pac=
kages are release critical bugs.

(ins)efraim@3900XT ~/workspace/guix$ time ./pre-inst-env guix weather -m ./=
etc/manifests/release.scm
computing 258 package derivations for x86_64-linux...
looking for 303 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org =E2=98=80
  100.0% substitutes available (303 out of 303)
  982.7 MiB of nars (compressed)
  3,145.6 MiB on disk (uncompressed)
  0.018 seconds per request (5.6 seconds in total)
  54.1 requests per second
  (continuous integration information unavailable)
looking for 303 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org =E2=98=80
  100.0% substitutes available (303 out of 303)
  at least 1,988.3 MiB of nars (compressed)
  3,145.8 MiB on disk (uncompressed)
  0.007 seconds per request (1.6 seconds in total)
  146.2 requests per second

(ins)efraim@3900XT ~/workspace/guix$ time ./pre-inst-env guix weather --sys=
tem=3Daarch64-linux -m ./etc/manifests/release.scm
computing 257 package derivations for aarch64-linux...
looking for 302 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org =E2=98=80
  82.8% substitutes available (250 out of 302)
  863.8 MiB of nars (compressed)
  3,403.9 MiB on disk (uncompressed)
  0.053 seconds per request (15.9 seconds in total)
  19.0 requests per second
  (continuous integration information unavailable)
looking for 302 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org =E2=9B=88
  48.7% substitutes available (147 out of 302)
  at least 287.9 MiB of nars (compressed)
  815.4 MiB on disk (uncompressed)
  0.004 seconds per request (1.2 seconds in total)
  260.5 requests per second

100% on x86_64 (and has been every time I've checked recently). I'm not
sure how much is waiting for rebuilds on aarch64 or how much needs
fixing.  Currently it's bcachefs-static, xfce, mate, gnome, and some
u-boot packages.

> Practically this means testing the end-to-end install process of Guix Sys=
tem with these defaults on (a) primary architectures (x86 and AArch64), als=
o through KVM (QCow2 image), and tested on the major foreign distribution's=
 (e.g. Debian, Fedora, Ubuntu).
>=20
> Non-default packages that are in the installer (but not a default option)=
 go into (a new) %desktop_packages. These get the next layer of testing, th=
ese SHOULD work as we shouldn't ship something we know is broken, but it's =
less critical. We're assuming that each Team is shipping things that work, =
and it's 'reasonable efforts' for the Release Team to try and check that th=
e installer works for them.
>=20
> This focuses attention by reducing the scope that the release team "must"=
 test.

I think if we cut down the installer to a Blessed Configuration=E2=84=A2 th=
en we
could even see about shipping substitutes for those components in the
image itself, which would make the install much nicer.

> I also proposed a "minimal" group which would be "packages required to bo=
ot and install a minimal Guix or Guix System". Is it the same idea as %base=
_packages? I'm wondering if we should separate "Guix installed as a packge =
manager" into it's own package set. In the long run this would be a buildin=
g lock that allow us to align with Philip's suggestion of following a more =
Nix-packages / Nix OS separation of releases. What do you think?

The %base-packages in the packages section of the OS config is the same
%base-packages I pulled in for release.scm.

Right now I'm only seeing guix in the "guix as package manager" set.

>=20
> > > ## Release artifacts
> > >=20
> > > Using the primary architecture tier and the package sets would involv=
e creating
> > > the following release artifacts:
> > >=20
> > > - GNU Guix System ISO image
> > > - GNU Guix System QCOW2 image
> > > - GNU Guix installer
> >=20
> > This omits two important things:
> >=20
> >   =E2=80=A2 The binary tarball, used to install on top of another distr=
o, for
> >     all =E2=80=9Csupported architectures=E2=80=9D (Primary and Alternat=
ive).
> (...)
>=20
> OK, I can add them to the GCD.
>=20
> Just to clarify terms, I'm looking at the download page (https://guix.gnu=
=2Eorg/en/download/)
>=20
> What you're calling the "binary tarball" is that on the download page as =
the third option labeled "GNU Guix 1.4.0 Binary"?  I thought that was what =
I was calling the "GNU Guix installer".
>=20
>=20
> >   =E2=80=A2 The source tarball, as produced by =E2=80=98make dist=E2=80=
=99 (target audience is
> >     primarily downstream packagers, such as Debian).
> >=20
>=20
> On the download page this is defined as "GNU Guix 1.4.0 Source". I will a=
dd this.
>=20
> We don't have anything about the downstream Debian/Fedora packages. Phili=
p McGrath mentioned this as an important path and I agree. Since we don't c=
reate the packages I'm not sure what to do here. Ideally, we'd work with th=
e packagers to co-ordinate with them, but as a project we don't actually cr=
eate them.
>=20
>=20
> > Reducing toil will be a matter of defining =E2=80=9Csupported architect=
ures=E2=80=9D in
> > a reasonable way.
> >=20
> > > ## Release team and project
> >=20
> > I really like this section!
> >=20
> > > ### 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.
> >=20
> > This raises the question of who will nominate the team.  But perhaps
> > that=E2=80=99s a problem mostly for the first release (Nov. 2025) since=
 after
> > that passing on the torch will be easier?
>=20
> At Guix Days (2025) there was a big discussion about releasing. Efraim no=
minated himself as the first "Release Manager".
>=20
> I'm sure that there are others in the group would also be interested, the=
re was a good discussion in December. I'm sure that Andreas and I would be =
excited to work on it!
>=20
> And, I'm assuming _you_ are mentoring us all ;-))

I assumed it was really volunteer vs voluntold.

> > > ### 3. Release project start
> > > Start the project with weekly updates to guix-dev and regular meeting=
s of the
> >=20
> > s/guix-dev/`guix-devel`/
> >=20
>=20
> Thanks
>=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
> > > branch slows down from this week.
> >=20
> > In the past, what we did was to create a =E2=80=98version-1.4.0=E2=80=
=99 (or similar)
> > branch one or two weeks before release and would let =E2=80=98master=E2=
=80=99 live its
> > life, avoiding both total freeze and unintentional breakage while we=E2=
=80=99re
> > close to release (only people working on the release would commit to
> > that version branch).
> >=20
> > The version branch would be prioritized by ci.guix.gnu.org too.
> >=20
> > It=E2=80=99s very similar to what you wrote here but by keeping the def=
ault
> > unchanged for developers not part of the Release Team, it may prove to
> > work better.
> >=20
> > > ### 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 pack=
age are
> > > allowed.  Ideally avoid new upstream versions, but it's acceptable to=
 use a new
> > > minor upstream version to solve a bug.
> > >=20
> > > Any non-building packages are removed.
> >=20
> > According to the deprecation policy, this can be done anytime but takes
> > at least one month.
> (...)
>=20
> Understood. I have it now that in week 3 we identify things to be removed=
 and notify everyone. In week 10 they are removed, so there's been a good l=
ong period of notification.
>=20
>=20
> > Overall I like what the GCD lays out.  Perhaps there will be adjustments
> > to be made here and there but it looks sensible to me.
> >=20
> > I expect that a big chunk of the work before the November release will
> > be streamlining the process, in particular ensuring that a developer can
> > make a release without having too many privileges or a
> > multi-architecture build farm at home.
> (...)
>=20
> Agreed, the real work is not the actual GCD heh heh =3D-)
>=20
> Steve / Futurile
>=20

--=20
Efraim Flashner   <efraim@HIDDEN>   =D7=90=D7=A4=D7=A8=D7=99=D7=9D =
=D7=A4=D7=9C=D7=A9=D7=A0=D7=A8
GPG key =3D A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

--ZYHnpxisCp11mTn4
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmhJh3kACgkQQarn3Mo9
g1HH5BAAvMYFJb549V8fwMUHDvzx5fvj05rNLw4y2BTfW8aRB4S6kyBud+qetcrn
VW6ltC9BP5+3qfqKGNWbpnckbQq6Js3nopbZLo/P0K4DSBzODWt6hIrmpdJ5CPQh
HcXBVaipwLPSX/wlbrLWrMUMegVkpp/yQuH4OjUa+6Z8CcZegM4EAwfXsXaYqD3L
7PDh2pAGN9ek08dApJjQK3RsGTSlNVuC+3cuOMQM52SGw8VpBIHIIKw9QgQLFW2Z
GtRgDD1AWjr1sPdPvzzZzTNrf/iYD9i7t+lTOgwQH9UvjQfjtv62cCZs5TdCxiv2
a74dUz4CfC+S/iK6z5n3HyRloW1T8zJWkEaJ+awMehYwV1FTP7G5pbrWlgOEm86+
8Sfr110a6D6V8MxOlBJrVAboQZXMdyI7O5pU1LZExie8jTFAFMh3bryauoaIO6rW
HDbV10SF0Df7zPrUIRTSqkq4+ycBw1z9QSIPosAoATqT0EdW6nXxSDn4mWOnql4z
rcaeW7Zixxqe9rFRwaHnLHBU9quB7OWR0UoQhbPNWMO47ItRS+Sa4en7+13j2+QQ
4uaC28hRbphkLzDCgdjGH1wT5KHGlYH+FITvgjiN0vSYlR6IbfBlo1uo/t+bnaT8
/LaQ58AD4BtC3Y10WZXl1I1Y1gYUa9u1uO62fNCWEGW9q7IliBU=
=+s1m
-----END PGP SIGNATURE-----

--ZYHnpxisCp11mTn4--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 11 Jun 2025 21:00:06 +0000
Resent-Message-ID: <handler.78332.B78332.17496755679376 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Philip McGrath <philip@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17496755679376
          (code B ref 78332); Wed, 11 Jun 2025 21:00:06 +0000
Received: (at 78332) by debbugs.gnu.org; 11 Jun 2025 20:59:27 +0000
Received: from localhost ([127.0.0.1]:52244 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPSXf-0002RA-Ck
	for submit <at> debbugs.gnu.org; Wed, 11 Jun 2025 16:59:27 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:41574)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uPSXc-0002QI-KV
 for 78332 <at> debbugs.gnu.org; Wed, 11 Jun 2025 16:59:25 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1uPSXW-0002iO-3o; Wed, 11 Jun 2025 16:59:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=VUNdwReZnb3SuAbbkxy6Ayn/0r4CrgNCs7ulhqmce7E=; b=RuuRep4Ynw8tIIDsH4OF
 p0+ZrqBqDa/vttPZ+dkJF56YwBdWoT4tMxyI/iTLJtzWyAPRCxR53ctYRL0KYu0TskePdL817K+rN
 Wkmxg/0FoWR0Ay8glg9l9H03KtMkH0P4JwUv77vbRJy7Y3LssieOBw3p7VrGbZHjUEq/XU56lF6lA
 x6RHe/W3fFG2TapEDAAHa9u0RcFVRKmRWcMK7Bxhbq51Ha7IEzHc4LGrsgW/3QbBsngaf48q7z42P
 5PpAXYh1n+O9woPSY0UfTOG/XsnoMpGV5e+P9kRGljM4COanmMcg/4TAemskgygaslcoRY4+By1IV
 tBGBQVazz60vWA==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <aEmHfDluw6ZSCQ12@3900XT> (Efraim Flashner's message of "Wed, 11
 Jun 2025 16:41:16 +0300")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87o6ux82e5.fsf@HIDDEN>
 <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
 <aEmHfDluw6ZSCQ12@3900XT>
User-Agent: mu4e 1.12.11; emacs 29.4
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Tridi 23 Prairial an 233 de la =?UTF-8?Q?R=C3=A9volution,?= jour du
 =?UTF-8?Q?Ch=C3=A8vrefeuille?=
Date: Wed, 11 Jun 2025 22:47:42 +0200
Message-ID: <877c1igg41.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
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: -3.3 (---)

Hello,

Efraim Flashner <efraim@HIDDEN> writes:

>> >   =E2=80=A2 =E2=80=9CCore=E2=80=9D packages that anyone may wish to in=
stall on any of the
>> >     architectures supported by Guix (not Guix System).
>> >=20
>> >     This was =E2=80=98%base-packages=E2=80=99 in
>> >     <https://codeberg.org/guix/guix/src/commit/12d00767f036029f1f5738d=
e644d4972db374f4f/etc/manifests/release.s

[...]

> (define %base-packages
>   ;; Packages that must be substitutable on all the platforms Guix suppor=
ts.
>   (map specification->package
>        '("bootstrap-tarballs" "gcc-toolchain" "nss-certs"
>          "openssh" "emacs" "vim" "python" "guile" "guix")))
>
> I realize that they are important packages, but they're all packages
> that, if they broke, we would've noticed anyway (perhaps not
> bootstrap-tarballs).

It=E2=80=99s not just about checking they=E2=80=99re not broken (you=E2=80=
=99re right we=E2=80=99d have
noticed, at least on the popular architectures), it=E2=80=99s also about
ensuring that substitutes are available for them.

That was the spirit of the =E2=80=98assert-binaries-available=E2=80=99 Make=
file target.
And that, in practice, often turned out to be difficult to achieve,
especially for Arm.

Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 11 Jun 2025 21:00:08 +0000
Resent-Message-ID: <handler.78332.B78332.17496755749406 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Philip McGrath <philip@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17496755749406
          (code B ref 78332); Wed, 11 Jun 2025 21:00:08 +0000
Received: (at 78332) by debbugs.gnu.org; 11 Jun 2025 20:59:34 +0000
Received: from localhost ([127.0.0.1]:52247 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPSXl-0002Re-TH
	for submit <at> debbugs.gnu.org; Wed, 11 Jun 2025 16:59:34 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:41582)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uPSXe-0002QV-3z
 for 78332 <at> debbugs.gnu.org; Wed, 11 Jun 2025 16:59:27 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1uPSXY-0002ij-Gv; Wed, 11 Jun 2025 16:59:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=ZPNsHtsJ7mmzCrb19az0oqOCGO3fMlmVCgSpa+zYfKs=; b=lNVsaHVbQ9DiIw3RFtER
 imPlWyrPUaez/bHzDZCZeucW4H4PiJSlOZUb7FJP3TU7VCi7UK9Th+Ij7eUI6FZpHrfCFJ5PWhI4T
 LE0HW4/LrpT6NlSaCayafZPDnH7qIr7O0JGc0acdz6pjpn7E7u81D5vX2Ps7pYstb6mO/m7AWMec5
 VNLsldVKsCKI4ndaVvDiFdEwxOFKjn+h5MzmfxCkPM0I9IHMMW6SY8gL7p0qUv3In+VN7KRe61fB5
 mXYVDTqPIo3iN18Tg8/jElnEpRr0AbdxcffUBkImDD/tG+fLqSFwqNppU25g5yASyKLMuMyISpLbL
 NGnKdNqy4u6WUQ==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
 (Steve George's message of "Wed, 11 Jun 2025 13:26:42 +0100")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87o6ux82e5.fsf@HIDDEN>
 <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
User-Agent: mu4e 1.12.11; emacs 29.4
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Tridi 23 Prairial an 233 de la =?UTF-8?Q?R=C3=A9volution,?= jour du
 =?UTF-8?Q?Ch=C3=A8vrefeuille?=
Date: Wed, 11 Jun 2025 22:58:44 +0200
Message-ID: <87sek6f117.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
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: -3.3 (---)

Hi Steve,

Steve George <steve@HIDDEN> writes:

>> Perhaps I overlooked it, but it=E2=80=99s not clear to me how package se=
ts
>> affect the release process.
>>=20
>> I would expect things like =E2=80=9Cpackage set X must successfully buil=
d on all
>> Primary Architectures at time of release=E2=80=9D, =E2=80=9Cpackage set =
Y is provided on
>> a best-effort basis=E2=80=9D, or things along these lines.
>
> Maybe it's a bit too diffuse in what is a long document, it says:
>
> "Packages within the `package sets` must build on the primary
> architectures (see definition lower).  As part of the release's QA
> contributors would be asked to these these packages."

Right.  I guess my question is more: why do we define 5 package sets if
in the end the same requirements apply to all of them?

My thought, mostly encoded in =E2=80=98etc/manifests/release.scm=E2=80=99, =
is that we
can probably have two package sets with slightly different requirements.

BTW, there=E2=80=99s one thing the document doesn=E2=80=99t mentioned but w=
hich is/was
captured by =E2=80=98release.scm=E2=80=99, and that=E2=80=99s cross-compila=
tion.  There=E2=80=99s a
small selection of packages that we want to be able to cross-compile
from x86_64-linux to a small selection of target triplets (i586-pc-gnu,
aarch64-linux-gnu, etc.).  But=E2=80=A6 maybe we can leave it out of the GC=
D?

> The main goal is to focus attention during testing, particularly as
> there's always some level of manual testing by a Release
> Team. Efraim's version still has the %system-packages, and what I
> would propose is to tighen it up further:
>
> - %system_packages (what I called minimal): requirements for the installe=
r including a default graphical desktop.
> - %desktop_packages (what I called desktop): additional graphical desktop=
s, other options like NTP and Tor.=20
>
> The Release Team would focus testing on the things on the installer's
> critical path. In Efraim's version there's actually three sets -
> %bootloader_packages, %filesystem_packages and
> %system_packages. Anyway, these all MUST work because they align with
> the installers defaults. Failures in these packages are release
> critical bugs.
>
> Practically this means testing the end-to-end install process of Guix
> System with these defaults on (a) primary architectures (x86 and
> AArch64), also through KVM (QCow2 image), and tested on the major
> foreign distribution's (e.g. Debian, Fedora, Ubuntu).

OK.

> Non-default packages that are in the installer (but not a default
> option) go into (a new) %desktop_packages. These get the next layer of
> testing, these SHOULD work as we shouldn't ship something we know is
> broken, but it's less critical. We're assuming that each Team is
> shipping things that work, and it's 'reasonable efforts' for the
> Release Team to try and check that the installer works for them.
>
> This focuses attention by reducing the scope that the release team "must"=
 test.
>
> I also proposed a "minimal" group which would be "packages required to
> boot and install a minimal Guix or Guix System". Is it the same idea
> as %base_packages?

I think so.

> I'm wondering if we should separate "Guix installed as a packge
> manager" into it's own package set. In the long run this would be a
> building lock that allow us to align with Philip's suggestion of
> following a more Nix-packages / Nix OS separation of releases. What do
> you think?

The NixOS/Nixpkgs distinction doesn=E2=80=99t really exist anymore (it used=
 to
be two separate repos but the two are necessarily tightly coupled), so
I=E2=80=99m not sure what the suggestion is.

>> > ## Release artifacts
>> >=20
>> > Using the primary architecture tier and the package sets would involve=
 creating
>> > the following release artifacts:
>> >=20
>> > - GNU Guix System ISO image
>> > - GNU Guix System QCOW2 image
>> > - GNU Guix installer
>>=20
>> This omits two important things:
>>=20
>>   =E2=80=A2 The binary tarball, used to install on top of another distro=
, for
>>     all =E2=80=9Csupported architectures=E2=80=9D (Primary and Alternati=
ve).
> (...)
>
> OK, I can add them to the GCD.
>
> Just to clarify terms, I'm looking at the download page (https://guix.gnu=
.org/en/download/)
>
> What you're calling the "binary tarball" is that on the download page
> as the third option labeled "GNU Guix 1.4.0 Binary"?

Yes.

> I thought that was what I was calling the "GNU Guix installer".

Oh sorry.  To me =E2=80=9Cinstaller=E2=80=9D refers to the Guix System inst=
allation user
interface on the ISO.

>>   =E2=80=A2 The source tarball, as produced by =E2=80=98make dist=E2=80=
=99 (target audience is
>>     primarily downstream packagers, such as Debian).
>>=20
>
> On the download page this is defined as "GNU Guix 1.4.0 Source". I will a=
dd this.

Yes.

> We don't have anything about the downstream Debian/Fedora
> packages. Philip McGrath mentioned this as an important path and I
> agree. Since we don't create the packages I'm not sure what to do
> here. Ideally, we'd work with the packagers to co-ordinate with them,
> but as a project we don't actually create them.

Right, there=E2=80=99s not much we can do: they=E2=80=99re maintained by ot=
hers.  Our
job though is to make sure they can take the source tarball (or a
checkout) and work from there.

> At Guix Days (2025) there was a big discussion about releasing. Efraim
> nominated himself as the first "Release Manager".
>
> I'm sure that there are others in the group would also be interested,
> there was a good discussion in December. I'm sure that Andreas and I
> would be excited to work on it!

Ah yes, excellent.

> And, I'm assuming _you_ are mentoring us all ;-))

Sure, I=E2=80=99ll do my best and maybe Maxim can share his experience too.

Thanks!

Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 12 Jun 2025 19:10:02 +0000
Resent-Message-ID: <handler.78332.B78332.174975534729336 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174975534729336
          (code B ref 78332); Thu, 12 Jun 2025 19:10:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 Jun 2025 19:09:07 +0000
Received: from localhost ([127.0.0.1]:60534 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPnIQ-0007ct-41
	for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 15:09:07 -0400
Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:61654)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>)
 id 1uPnIN-0007cI-GK
 for 78332 <at> debbugs.gnu.org; Thu, 12 Jun 2025 15:09:04 -0400
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-43cfe63c592so15667355e9.2
 for <78332 <at> debbugs.gnu.org>; Thu, 12 Jun 2025 12:09:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749755337; x=1750360137; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
 :reply-to; bh=j0YGh7IUWLW1vCWlvrN7B4L6D1RKjDl8TYhvwzpNaMs=;
 b=NWBkbB/g17OEaRzcxWr3qKzlV6rZbxt+U+CHs9ZXEHaVktP9vPBb6NnOVTZv5D54lE
 +GmTcTfzEVWBMjq8e8rY8OaoqqTMA40TDTuE1HjCY3XnI85vDJvF38vYVp90Cdc6pHRj
 Zh97TdcJ19J9o8S1oP8hcvX3U9sOrb1qDcUdAGxT8gE3KXSr7BvSKr9NPyidFBArIHEo
 sDNaV2xCXgslP6dCzvKG+k9cw1maAkXPAR8t1Wyb5+Fc7ss2NKImmpJXjbvsV1RShlDD
 JBcqSl+aO6n2WqfPzaI/LWFW0TwkkNf9yndQ1rQ2QEr21VprABEqAunBb4xkeeYhKMj8
 o16A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749755337; x=1750360137;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=j0YGh7IUWLW1vCWlvrN7B4L6D1RKjDl8TYhvwzpNaMs=;
 b=LfNuahIvMst0jIzPsC5O01jnt6AYyj5SFyQjrU/bhfu/I8hBslPjbeedg5xSNoaN4v
 dKLthwuEIr23he8eH1fh4baOojyM39EH3MRTebhuEdv3WNn4uuZCQCfGWUyRZsA5QSU2
 /j/Cr4NmSmb85tWW7HZ9mNT0XgL0H2spD3AETdD4hbdMm/lCoB/KitoG4ODX1tp8udZr
 G3aCpmMPmccXxwVda9kXNmU8dT09j/1N2WuZk6qXkWVByz6mUSwx0eBu+++AiFBQl/21
 AdqX5LaNJpnqZcKXBWt9nOYbvQV+dCStTYHhV5uDHhFA939l8mr4pAZQz7tJJmn58hwk
 hHVQ==
X-Gm-Message-State: AOJu0YwCvO9kfklOw72zdVyz1u2At7Tgl6X7Wap0zpc15h7tx+Fpb6c8
 mlEd6iLKSOhYg+kfajOZeTh08nwgmvZ/kdHbME0FvYCvhPs2fAoWN3r4Z/upzA==
X-Gm-Gg: ASbGnctiEbs3N+jCTPA9c8nwLaT2/fBGbUS6WhrM1MkjLdhzCzzv73dafSr1xVJkM/u
 DMc5Ww7O6jhzoT50PNjI0BizaeAHZ/xFXAEzOuwtunMgs209gNJtxg/ATd+fqeeOnfTeBQ1VFQa
 CgXBwtTEt6O/4/U+i8qZdhn4GWe0qpgCS4DUJXtOtRAfPUptxuggTNlzm64Z8uHmmTtk/8eIp3f
 AoH1L0toKRbKt1HgLsORkWHsJQoaF86XWD0lEyClSLdkdO75yGxOJuMnH78ooCVkfjiEE2S8b3o
 UCCvEl7qSCot4l8CkM1bXN1Bsv7mvDxECfFD6dEQy4uMEfli+BzgdmaiI96NfSI6OJWB0It9jP/
 F11ivfuwlOygB08KGA8BmE3o=
X-Google-Smtp-Source: AGHT+IHX73Yj7ONSOe8+A2X6nFlSPrbAAxhgkBBNf0pUNx9lMuonPhSQr0GT2qGgEB3RlI3ixawjVg==
X-Received: by 2002:a05:6000:2505:b0:3a4:d8f2:d9d with SMTP id
 ffacd0b85a97d-3a56873e9fdmr357030f8f.38.1749755336888; 
 Thu, 12 Jun 2025 12:08:56 -0700 (PDT)
Received: from lili (nat-dsi-209.net.univ-paris-diderot.fr. [81.194.30.209])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568a54d7fsm157899f8f.18.2025.06.12.12.08.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 12:08:56 -0700 (PDT)
From: Simon Tournier <zimon.toutoune@HIDDEN>
In-Reply-To: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
Date: Thu, 12 Jun 2025 21:08:54 +0200
Message-ID: <87y0tw22wp.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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,

Thanks for this proposal!

Well, I=E2=80=99ve not commented yet because I=E2=80=99m very doubtful that=
 releasing
more often can be solved with a GCD.  I mean, yeah we all would like
more releases, and then?  :-)  Look, on February, we were all in the
same room and we all agreed that we had to work on releasing soon and
we cooked a plan to make it happen.  But the release has not come yet=E2=80=
=A6

Do not take me wrong.  I do not want to be the pessimistic one cutting
the positive circle trying to move forward.  As I wrote many times over
the years, yeah for sure, releasing more often would be more than great!

Somehow, I think that =E2=80=9Cregular and efficient release=E2=80=9C is a =
good target
but considering the current situation, I=E2=80=99m doubtful we will be able=
 to
go in only one go =E2=80=93 just by deciding from the top and writing down a
planning.

Instead, I think we need two intermediary steps:

 (1) Clarify what means being a member of a team.
 (2) Clarify the branching model; especially how to deal with grafts.

To me, they are requirements before being able to have regular releases.

Therefore, I read this GCD as setting the goal in order to address the
well known blockers as (1+2) and, only after, we will be able to have
regular releases without burning out.

Moreover, I think it=E2=80=99s difficult to find the right balance between
volunteering work and commitments.  Today, make a release is a piece of
work.  For sure, it=E2=80=99s possible to smooth the things and automatize =
with
various helpers etc. but if it=E2=80=99s not done yet, maybe it=E2=80=99s b=
ecause it=E2=80=99s
not trivial or maybe even more work than the =E2=80=98piece of work=E2=80=
=99 itself. :-)

Yes, I=E2=80=99m convinced that committing to have =E2=80=9Cregular release=
s=E2=80=9D will
improve all the releasing process over the next releases.  For sure!
And it=E2=80=99s probably by making such commitment that the releasing proc=
ess
will be improved.  But we are not there yet, IMHO, so it=E2=80=99s still a =
piece
of work and it=E2=80=99ll still remain one for some release cycles.

Therefore, the core of this proposal appears to me what is the bar?

Until now, the bar was high.  Maybe, one way to release more often is to
decrease the bar so it=E2=80=99s easier to pass it and then we can rise it =
up,
by incremental improvements.  This is the section about Package Sets,
Tiers and Release Artifacts.

To me, that=E2=80=99s the key.

And concretely, who is ready to commit for 12 weeks (maybe 2 times) as
Release Manager?

All that said, some comments hoping it might improve the bootstrap of
=E2=80=9Cregular releases=E2=80=9D. :-)


> ## Package Sets

[...]

> 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.

I understand the meaning however it=E2=80=99s unclear to me.  Instead, I pr=
opose
that the Release Team defines when they start their cycle which packages
the release will support.

Somehow, each package set should be defined by a manifest file.  Here
you picked 5 use-cases, so the Release Team lists the packages in the
manifests minimal.scm, standard.scm, desktop.scm, server.scm and
hosted.scm.  These manifests are considered as blockers.

If one package from one manifest fails and it=E2=80=99s hard to fix, then i=
t can
be excluded; i.e., moved from Tier to another Tier.

It also would help in monitoring the CI outside the release period.


> ## Platforms and Architecture 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

This does not read as the rolling release, does it? :-)

I propose:

        - Tier 1:
          - Architectures: x86_64, AArch64
          - Kernel: Linux
          - Coverage: defined by package sets.

        - Tier 2:
          - Architectures: all others
          - Kernel: Linux
          - Coverage: defined by package sets.

        - Tier 3:
          - Architectures: all
          - Kernel: Linux, Hurd
          - Coverage: all packages

For a release, Tier 1 must be all green; Tier 2 should be green; Tier 3
as good as possible.

Obviously, we can add more Tier than only 3.  The main idea here is to
define what is Tier (=3D list of architectures, kernel, package coverage)
and what expects when this Tier in a release.

Well, maybe we could add a =E2=80=9Cservice coverage=E2=80=9D.


> ## Release team and project

[...]

> 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

Hum, 2 times 12 weeks of commitment?  That=E2=80=99s something! :-)

For sure, back up the Release Manager with 2 people is a very good idea;
especially about knowledge transfer.  Cool!

If the primary Release Manager is not able to keep the commitment (busy
by life, away from keyboard, unexpected event, etc.), then the secondary
Release Manager takes the floor.  Right?  But then, this =E2=80=9Cabsent=E2=
=80=9D
primary Release Manager, does they become the next secondary Release
Manager?

Moreover, what does it happen if the both Release Manager are not
responding?  Do we delay the time to find two new Release Managers?  Or
is it two of the other members?

The other question: what does it happen if the Release Team is not able
to fix a blocker?  Do we delay until the fix?  Do we drop the blocker?
Who decides?  What is the process for making such decision?


> # 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.

Well, I do not have the answer and my honest question is: Is it more
detrimental to have irregular^W no release since years! than to
communicate on regular releases and fail?


> # Appendix 1: Release Project Time-line

[...]

> ### 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.

Who nominates?  How?

Who decides if 7 people volunteer to be the next release team?  Hum, it
will not happen, but still. :-)

The converse, what does it happen if no one volunteer?  IIUC, the
primary Release Manager becomes the next secondary Release Manager, so
what does it happen if there is no one who volunteers to be the next
primary volunteer?

What does it happen if after the release, the primary Release Manager
steps down and do not become the next secondary Release Manager?


> ### 9. Ungraft master branch
> Guix master is ungrafted to minimise the difference with users of the rel=
ease
> initial 'guix pull' experience.

This will take more than one week, I guess. :-)  For sure, more than few
hours in the week.

I think this needs to be done by each team all over the changes
independently of the release process.  As said above, I think we should
clarify what a team does.  For instance, if a team introduces a graft,
then this very same team must open a branch that ungrafts and then merge
this branch as soon as possible; independently of the release.

Somehow, we removed core-updates but we have never defined a clear
strategy for ungrafting.  Well, that=E2=80=99s outside the scope of this GCD
but, IMHO, the success of this GCD depends on how to deal with grafts.


All in all, let me know if you need a wording proposal from me about
some of my comments.

Cheers,
simon

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 12 Jun 2025 21:31:02 +0000
Resent-Message-ID: <handler.78332.B78332.17497638192054 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Sharlatan Hellseher <sharlatanus@HIDDEN>, 78332 <at> debbugs.gnu.org
Cc: steve@HIDDEN
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17497638192054
          (code B ref 78332); Thu, 12 Jun 2025 21:31:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 Jun 2025 21:30:19 +0000
Received: from localhost ([127.0.0.1]:32988 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPpV4-0000Wx-36
	for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 17:30:18 -0400
Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:57579)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>)
 id 1uPpV1-0000TV-QS
 for 78332 <at> debbugs.gnu.org; Thu, 12 Jun 2025 17:30:16 -0400
Received: by mail-wr1-x42a.google.com with SMTP id
 ffacd0b85a97d-3a4ef2c2ef3so1287674f8f.2
 for <78332 <at> debbugs.gnu.org>; Thu, 12 Jun 2025 14:30:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749763809; x=1750368609; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
 :reply-to; bh=6fCyYoY+J72LoJUl8mB4QM1+VfyXVL5VzMbX8xExZSo=;
 b=cGdleP+gGT/dgSOYIfx85ZuUrOrGp2U+FcAiUSzcBXDr4AD3NYmeObr5EH1/wfntC2
 iCZP9HsCC0swpU0mZAW5MqtN0ZtgEDPP8cBIYpv79Op4uN9rFou0STkUJnH/2imTFnWP
 8VQNSEy1HgJ/wDqhTNe7joT70gJPy7qSUW6Z+i2omCV4M1CQEnPqAUnetGh6vbFPhnu0
 4qsfChhIup8pt+3Rd0dc03Jd7LVJP2DAvbyi/LIlSA+Ouv5Q0U8Yr3uG1VsO18/oJdU3
 H1LeeW52MmcsfA1/BgwV/JZDBMlSEI0JPXbHTIWajpKRKacKr7h3+dou2hg4Qzzye3bq
 pkJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749763809; x=1750368609;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=6fCyYoY+J72LoJUl8mB4QM1+VfyXVL5VzMbX8xExZSo=;
 b=hFHvRCzu/cKFFaIVza6wZf6BpBWPbzF1xdT3ekAOKriO7jL1E1PRjBKBkbnXSxUQ0L
 8TNSVyOW2adXvYDmLThXXPUYMc2cNNPIvwZFvEKon0NKDGE1FSQnPdSD1wx+oEhkaVXR
 mbP5aMl4AUj7EOhKQPnP9Hf1/lsMNtSjZRm+IRoCCn1QBdgkNkdVjQ2CC2WRtRTahY2F
 wgvmBlNw3v6ZreY+eijdZV+V/Vllijj7+IOkJu6SxccAdMzYxIiy1l7c72Uy9JP9WMLF
 iBdvqDsif3QA4PVezXk+nBuVPuh/ecL/IyjjpISfATZRLDkzSoMaRDo7zdJQg8uCBi1C
 HX4g==
X-Forwarded-Encrypted: i=1;
 AJvYcCUX+ZfsQ2bIVFqTXzZ3JVyuyvqOJjoPc50riCaj0BRhZCOBlPosJfeThZSaevP9RaKMMDkGpQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyjTArONAT64ilC/GL0Vy1CMllGrKZl608ta4AiGhlG7WYGf/uq
 j3vNC3K5YRIhtQvNdzLJ1SIPuIAKbpagGktn3yfxvLhuQ+G3n/fnMOGB
X-Gm-Gg: ASbGncux0PAd8prRv8e0OD6PKwMtN46NVhSmbJBk4G6dRwIL8YU0x062g6k+4mdlmbs
 jcX83b/oiF8XEulehhNUh0TMx6Xbs7VIzvonqGfDPwPVuLCmPHun/pVaTJedhG8P1MSfBDQlHWH
 ctx7GJ5K5YAnmQkf7u+Nj2UV0eMMBaYIiJ+x9dg5jiDr4/jqPMA44F+JKkU0QUvVTDIkTmee3fA
 Xr+UYjsMRHcsiMnaKpMFfXE0x4pMmi6lXFEdGO3Wzj4EHy3OzyxL4U7M8frMCpY58fHT8nv74ZJ
 zwGmK1ivpy4RtomrkX0Gpw8nysVZhHxtTwJRkPqZvgdMcsLY9MHRULYiX29eKACM/o8ZZLhOgip
 743nY9HXrvIrGmuA58XTrbwc=
X-Google-Smtp-Source: AGHT+IFxRmMGgQ0DYIWsNO7FWtN0q57LESJd06kq656+2W0L/NjHyiYZ0IWNfbcUBpWdtp5qQBm4RA==
X-Received: by 2002:a05:6000:144f:b0:3a4:e706:52f5 with SMTP id
 ffacd0b85a97d-3a5686f4674mr698006f8f.13.1749763809101; 
 Thu, 12 Jun 2025 14:30:09 -0700 (PDT)
Received: from lili (nat-dsi-209.net.univ-paris-diderot.fr. [81.194.30.209])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e24420csm31655055e9.20.2025.06.12.14.30.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 14:30:08 -0700 (PDT)
From: Simon Tournier <zimon.toutoune@HIDDEN>
In-Reply-To: <87tt4q4lfq.fsf@HIDDEN>
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
 <87tt4q4lfq.fsf@HIDDEN>
Date: Thu, 12 Jun 2025 22:45:00 +0200
Message-ID: <87v7p01ygj.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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 Oleg,

On Sun, 08 Jun 2025 at 10:44, Sharlatan Hellseher <sharlatanus@HIDDEN> w=
rote:

> It's my personal preference, as I see it's easy for me to run "guix
> refresh -s module:astronomy" and work through the whole collection than
> resolving conflicts in dated version after n+1 months.

When keeping up to date the astronomy package set, do you introduce
grafts?  If yes, later what=E2=80=99s your process for removing them?  If a=
ny. :-)

> I can contribute some time "to drive a refresh train to the final depot"
> (c) Simon Tournier, periodically.

Euh, what did I say? :-)

Cheers,
simon

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] approximated popcon? (was Re: GCD005: Regular and efficient releases)
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 12 Jun 2025 21:31:02 +0000
Resent-Message-ID: <handler.78332.B78332.17497638262076 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, Vagrant Cascadian <vagrant@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17497638262076
          (code B ref 78332); Thu, 12 Jun 2025 21:31:02 +0000
Received: (at 78332) by debbugs.gnu.org; 12 Jun 2025 21:30:26 +0000
Received: from localhost ([127.0.0.1]:32992 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPpVC-0000XO-3H
	for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 17:30:26 -0400
Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:43231)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>)
 id 1uPpV3-0000UV-1N
 for 78332 <at> debbugs.gnu.org; Thu, 12 Jun 2025 17:30:17 -0400
Received: by mail-wr1-x435.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so1734259f8f.0
 for <78332 <at> debbugs.gnu.org>; Thu, 12 Jun 2025 14:30:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749763811; x=1750368611; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
 :reply-to; bh=L45c3q0BSWsxr39AFTMK6gVQsMx/soACGjoSXUXKpw8=;
 b=DWUuZJ+Iuo+yX2gDxgC7UFqAonFuGPsJ+DFdAc1zxuyGYGRwNg80qQziZ8j9TBdTqO
 44Krg+MUi+8F+IU+6qu44qqZX48l9ToEvLfEp2Lvoe278/YUyA3jGDeed/uCr2wcNuQs
 DqnKpTHQ1yETWngczIFCAQWXSfkpEtXsagsiYk6YqVb+wp1cejHFY93CxsGtDlpSVe27
 R2PBIs9/InNUr9gMwVprs0BfgauTXusQh4GhHk28wsNggzxT+Kd+YC+HCM/q6U+lO4O/
 YcrT1+qxthuScN+mFOxIkjfmLEqgwR9y7If+nPZCiGJrxeiFrTr1vb7ZNIJKcpAGsIqj
 XPjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749763811; x=1750368611;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=L45c3q0BSWsxr39AFTMK6gVQsMx/soACGjoSXUXKpw8=;
 b=loNKJ4deKxVegi2fT+JTDUZ46hzRpww3a38q6NtWFNpVBw5dXT8y2hOd//f9lzFxgj
 4IfNy4uA4Nkpr37azH91db2tgBVXYZAuyJJTXfoOH3gweo/d5jLLZhhV3IeyM1FCE0wy
 UGkeafPJBPEjINLixkagjiQ+jWmddgltjVGGkAQoVOfLOcJyEzGnmc5ckBwDwM3fMtA/
 hkNgp/30Br8Slk03y/JmbuE6WUMQoEhzs9iF4pcw7EqulsIOCzPZOdju2rdsdZuhTjAl
 dAeXGgOW7aRVTNjgHhOX+5dfanRsX1D4EC/0cbgDt2xL4gzXrM8pg5uxvc3Qm1Sqg2d/
 XEqg==
X-Forwarded-Encrypted: i=1;
 AJvYcCWxRkRQrMsUzmdl5sgRHD548mj+/6R967GGQWEUD1PqYVMkcSNITWLwi8e4Z/PpOKqJ92s3gw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yw4Ga3HOb8M+4y7T5e9eWA0Pg/aFFRShd3lH0ffCD0AABtvmXjB
 nA+G8EUrZ0rImrKZVZ35yfxe7DLVhwOxM1P0+WnQLZ0B1QkYJVYIV34kLWLneQ==
X-Gm-Gg: ASbGnctdUvVTLFlmeJAShPaEFJ+tsPRm6p4te3+VRwSBEN6FH3NEpiR2Vk/JWn7Fbel
 68D6hPt7Ud0RuwCONBF9PmoMcONQz4PyPefCgeAuagRvkew6jbZhaAy0NdqMG2aeg7xbe5Fq7SL
 9IRh8JCEEqJXx84m2PKGYTK4zYLLsGXJRsKtX3iCkoZ8wOFIz8MXJ/dsE0tlKr08NjhUvNrFp1d
 5xsO7jx9LbwaJj9NbxQcLm7iQmHWxl052vp9/C9jhmAzeEoApXXjzU/Sqs8ONzkJT6r0IX20F/M
 r/qze+xJWyTY56uzXj480tYCSB/DmX7ldKRhAs14AOILnfthY/VRoGnJ5PJiQWmPfV+x0gz/1XS
 UQRktvRbXuQ73FJeEZMpbmcM=
X-Google-Smtp-Source: AGHT+IFleIZC6UJn/Tc0YKliHKOlZucR3kNG/neqSjpipZy5FXfx4r37POzQ41L9bwKK26x/6ni9cQ==
X-Received: by 2002:a05:6000:25c7:b0:3a5:5136:bd25 with SMTP id
 ffacd0b85a97d-3a56a2bb97dmr87807f8f.1.1749763810542; 
 Thu, 12 Jun 2025 14:30:10 -0700 (PDT)
Received: from lili (nat-dsi-209.net.univ-paris-diderot.fr. [81.194.30.209])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568b087a9sm422252f8f.55.2025.06.12.14.30.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 14:30:10 -0700 (PDT)
From: Simon Tournier <zimon.toutoune@HIDDEN>
In-Reply-To: <fgc57qffjxkfbqq5paewtef2tnsnr5kqrh2jw53btuehocly27@ubjbk5vtq5q2>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <8734ddpnu7.fsf@wireframe>
 <fgc57qffjxkfbqq5paewtef2tnsnr5kqrh2jw53btuehocly27@ubjbk5vtq5q2>
Date: Thu, 12 Jun 2025 22:59:57 +0200
Message-ID: <87plf81xrm.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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,

> As we don't have popcon I don't know what's popular with users

Once I heard a Debian Developer says: the aim of popcon isn=E2=80=99t to ta=
ke
less care of unpopular packages but the contrary.  It allows to know
that this package in appearance useless and/or outdated is still used by
one user so it=E2=80=99s a motivation to still maintain its availability.

Although hard when the resource is constrained, I like the
reasoning. :-)

Aside, maybe we could have a rough idea of some popular packages by
looking at the queries in the substitutes cache.

Guix sysadmin, is it doable?

Cheers,
simon

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 12 Jun 2025 21:31:03 +0000
Resent-Message-ID: <handler.78332.B78332.17497638262082 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Leo Famulari <leo@HIDDEN>, Steve George <steve@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17497638262082
          (code B ref 78332); Thu, 12 Jun 2025 21:31:03 +0000
Received: (at 78332) by debbugs.gnu.org; 12 Jun 2025 21:30:26 +0000
Received: from localhost ([127.0.0.1]:32994 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPpVC-0000XR-Ec
	for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 17:30:26 -0400
Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:61847)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>)
 id 1uPpV3-0000V7-Pw
 for 78332 <at> debbugs.gnu.org; Thu, 12 Jun 2025 17:30:18 -0400
Received: by mail-wm1-x32c.google.com with SMTP id
 5b1f17b1804b1-45305c280a3so6409655e9.3
 for <78332 <at> debbugs.gnu.org>; Thu, 12 Jun 2025 14:30:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749763812; x=1750368612; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
 :reply-to; bh=AaK3NEvJc22ZhgJmy96BiKyBqaJwljaDsZsh2TyG+/c=;
 b=GA8g18c+OygLpmZ7NjsaBvi84br+ClR9X6A0L9P2MtZGypO3jNXIX4FMwkx4Iw0Vov
 O2Vk/b7IWrm5qDzW59pBQBKdY22pgbb/TFipDXUVbhFQkr8L2ijPStKU4QVhga1diAfX
 He1x81aOxnFZxMtsWvQCPHczaU8T38nM6qu6x3SDG08KteLz5E6I2KhfaMi83tlhSNOw
 XYrylyTK8O3z9wxg1hy6D4W8yMHCIrhANVwOWyekhuzMu5x4u2FSbIkjNi91Sr6JSI2h
 L6Xm3ap19EoeOHRvHsi7CMEnyS8njiA+fV43Q4gpasPj7Q3tQnPcIjsvfn9Ep9TtF6d1
 Y5MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749763812; x=1750368612;
 h=content-transfer-encoding:mime-version:message-id:date:references
 :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=AaK3NEvJc22ZhgJmy96BiKyBqaJwljaDsZsh2TyG+/c=;
 b=HTeS/nDM6FHnvAJoNNgBtgeCp6TTx+bw3A3IsN5RCVX/sTOU28+Vb1D+Lwqkycts+u
 WXaycFpjfV+dnnkBWSwqLwlT8xiPmj0zO3V5SHfZO7YfYFsQQ9PELoFUG6IE4ybnZn99
 vO3gqzzbLr5jfTI5ebnrkWHumqiWrR6q3U2UZz26nI4IF9TDOCdb4+ltXw9oxb2L/inT
 hbABeY0g9f1iJmGCKT02CABYRK/yv4gQdhCV6mmX80HWM4lNHw2bKj16ua5ftr1Uj1HP
 8Eo0AUoQKzq1W3KoTJdkhoUcmcQm/X66wffPBMfROvF5+Cb7CwnXK+NhRGFyebdQK5ke
 9nyA==
X-Gm-Message-State: AOJu0YylpSWLQSSZCcOdEt731YUVkWTl1WePMBHR20eQ4ac177KMPVmO
 9X6unpb7c99jX19wlFYds4Uyj+qIjNlCugyYcbAnfXCK+iOmreC/sTcLQIHc2A==
X-Gm-Gg: ASbGncuZLxtU79/BMRaPLLOsZBCglgp0oGSs3/rpvPijq0MRj0CDc8vF3d3iFNFdYH4
 e/cPwS7fnhTRw+H5uzxo6aRXkbBU2aHfKbuWtyAEtfXfF0unOzCftA5RECANLlz0qMD/5xnvoI5
 3gi3RbkVI8zhDSxXV82lj6rwg/7TMhYalgI2XHxxlzslnnERwlLob4nLXGV4Y1Yx11yQMCMNZol
 8vWAoLZAPq5J6WuEEehv6bOWc7x7RzxKX4QtxPn8NeZj9fuxV/DS4oIUIi5r+mDx0I8USmyRPug
 S007Q7rPmoF9m5U/UHnW6xf7MAWfN96qJ4oTtN3ktlfGGAm42M8Gb/IXUAQsri4BmiorEi8A7kn
 +64cCODF6cWSivWzqyOXJDvE=
X-Google-Smtp-Source: AGHT+IH7JWmaERAv7N4sb7iMy4cpNU0L0rILP37mUi5fHdKTQfiSIigSP1J+0VQZZy8Syd7MZY5rMg==
X-Received: by 2002:a5d:588a:0:b0:3a5:2694:d75f with SMTP id
 ffacd0b85a97d-3a56875d675mr730790f8f.52.1749763811626; 
 Thu, 12 Jun 2025 14:30:11 -0700 (PDT)
Received: from lili (nat-dsi-209.net.univ-paris-diderot.fr. [81.194.30.209])
 by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568b087a9sm422296f8f.55.2025.06.12.14.30.11
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 12 Jun 2025 14:30:11 -0700 (PDT)
From: Simon Tournier <zimon.toutoune@HIDDEN>
In-Reply-To: <aEZGBdDWK27slg7u@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <aEZGBdDWK27slg7u@HIDDEN>
Date: Thu, 12 Jun 2025 23:30:07 +0200
Message-ID: <87jz5g1wdc.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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,

On Sun, 08 Jun 2025 at 22:25, Leo Famulari <leo@HIDDEN> wrote:

> Also, our old releases work until they don't. We want SWH to save us
> from bitrot, but our packages keep fighting us with little time bombs
> that break the build after certain dates. We need releases to keep Guix
> buildable for new installations. Guix is a build-from-source distro,
> although we hide that well.

Oh that significantly rises the bar! :-)

This could be some =E2=80=9CTier X=E2=80=9C meaning cross your fingers! ;-)

Well, if we define a scale of Tiers:

 1. Tier 1: this restricted package set runs on Linux x86_64;
 2. Tier 2: Tier 1 + these other package set;
 3. Tier 3: this restricted package set runs on Linux arm;
 4. Tier 4: etc.
 5. Tier 5: Hurd, best effort
 6. Tier 6: etc.
    =E2=80=A6
    Tier X: full rebuild from binary seeds and fetching source code from
            Software Heritage; cross your fingers!

And having a Tier with a different physical date, etc.

I mean, this kind of thing could be part of some horizon for the next
next next =E2=80=A6 next release.  It sends the signal =E2=80=9Cwe care abo=
ut long term
and we do thing that might last=E2=80=9D.=20=20

Cheers,
simon

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 13 Jun 2025 14:24:02 +0000
Resent-Message-ID: <handler.78332.B78332.174982463419083 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Simon Tournier <zimon.toutoune@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org, Leo Famulari <leo@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174982463419083
          (code B ref 78332); Fri, 13 Jun 2025 14:24:02 +0000
Received: (at 78332) by debbugs.gnu.org; 13 Jun 2025 14:23:54 +0000
Received: from localhost ([127.0.0.1]:47051 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5Jx-0004xi-GB
	for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:23:53 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:45598)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uQ5Jt-0004wA-Sa
 for 78332 <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:23:51 -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 1uQ5Jj-00GY0O-Kg; Fri, 13 Jun 2025 16:23:39 +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=lAGGxb9EHMbUwagpG04ZgG8s2oZJzloAWsbdlN262q8=; b=oyoZw/pu/9p3JXHj2Gz7K5WEDg
 JBEN5JrrQ6MoaeLb0girvISJ+OPG/k+8ev4B/HHd80I1CuBwAIgHSrK3eWBfnnpKW1axesYhxSt//
 GdEZC+7QXXTT+ySLN8YYuumb+35m4XbXTkUVaJf9NhnFOnPDHzOxxclU+e6mSptAeZYGkS+u7ck3/
 jkQWZoSNu5YiGf0nRf36pJX6sCZOBIHUgyApjE/YC7CgHD2YfW3mjaTkGPQoyWIIADGN1UCu+QUJL
 k/2JQuDJDhoZ40GdNzwTRNqZDV27S4NBvbcQJE3w5eIrcd6YeFBPmqR8/niTN3KZJeyefTFHm1Uce
 eQaWj72g==;
Received: from [10.9.9.73] (helo=submission02.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uQ5Ji-00010P-Ul; Fri, 13 Jun 2025 16:23:39 +0200
Received: by submission02.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uQ5JK-004vGp-1p; Fri, 13 Jun 2025 16:23:14 +0200
Date: Fri, 13 Jun 2025 15:23:13 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <l5b24e4ki25qqsfjl3xmw2vjir5yb7wi2oel74wj2t5litj76h@ktq34bk5siuz>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <aEZGBdDWK27slg7u@HIDDEN> <87jz5g1wdc.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87jz5g1wdc.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Thu, Jun 12, 2025 at 11:30:07PM +0200, Simon Tournier wrote:
> On Sun, 08 Jun 2025 at 22:25, Leo Famulari <leo@HIDDEN> wrote:
> 
> > Also, our old releases work until they don't. We want SWH to save us
> > from bitrot, but our packages keep fighting us with little time bombs
> > that break the build after certain dates. We need releases to keep Guix
> > buildable for new installations. Guix is a build-from-source distro,
> > although we hide that well.
> 
> Oh that significantly rises the bar! :-)
> 
> This could be some “Tier X“ meaning cross your fingers! ;-)
> 
> Well, if we define a scale of Tiers:
> 
>  1. Tier 1: this restricted package set runs on Linux x86_64;
>  2. Tier 2: Tier 1 + these other package set;
>  3. Tier 3: this restricted package set runs on Linux arm;
>  4. Tier 4: etc.
>  5. Tier 5: Hurd, best effort
>  6. Tier 6: etc.
>     …
>     Tier X: full rebuild from binary seeds and fetching source code from
>             Software Heritage; cross your fingers!
> 
> And having a Tier with a different physical date, etc.
> 
> I mean, this kind of thing could be part of some horizon for the next
> next next … next release.  It sends the signal “we care about long term
> and we do thing that might last”.  
(...)

This is definitely something that could be done over time, if we had people interested in it. At the moment Nix seems to operate 6 tiers, and they have similar ideas about different forms of guarantees.

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: "Leo Famulari" <leo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 13 Jun 2025 14:47:02 +0000
Resent-Message-ID: <handler.78332.B78332.174982601125432 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: zimoun <zimon.toutoune@HIDDEN>, "Steve George" <steve@HIDDEN>, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174982601125432
          (code B ref 78332); Fri, 13 Jun 2025 14:47:02 +0000
Received: (at 78332) by debbugs.gnu.org; 13 Jun 2025 14:46:51 +0000
Received: from localhost ([127.0.0.1]:47494 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5gA-0006c8-N2
	for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:46:50 -0400
Received: from fout-b6-smtp.messagingengine.com ([202.12.124.149]:57657)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <leo@HIDDEN>) id 1uQ5g8-0006bn-Ik
 for 78332 <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:46:49 -0400
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
 [10.202.2.41])
 by mailfout.stl.internal (Postfix) with ESMTP id E9A6C114011D;
 Fri, 13 Jun 2025 10:46:42 -0400 (EDT)
Received: from phl-imap-18 ([10.202.2.89])
 by phl-compute-01.internal (MEProxy); Fri, 13 Jun 2025 10:46:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name;
 h=cc:cc:content-transfer-encoding:content-type:content-type
 :date:date:from:from:in-reply-to:in-reply-to:message-id
 :mime-version:references:reply-to:subject:subject:to:to; s=
 mesmtp; t=1749826002; x=1749912402; bh=ztGYR4XAvKUkFZDgd3f9erqQq
 i/V9FWY9zQ72dclip8=; b=tZsOyEWfQpq/xWDvtGptten7asgDwyQNhU4grIDzR
 K3cSsb1HMV1LC3LN57UKDh6FcHa63nF6Jbk/kYGOQ3L12ro8LFlkcZgGHsrAMIqh
 FYWa5Z8TVeV8OJm6HG9HBACpYpKGDb5/PrD906QiEB3ZwvXK4+3NAFZVyRAkDf/9
 uQ=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1749826002; x=
 1749912402; bh=ztGYR4XAvKUkFZDgd3f9erqQqi/V9FWY9zQ72dclip8=; b=E
 MJXVArOaU0mJxqQHP9/xc29rBlWXTd7tevqi4fxpCmPAeD5f46XEqfGWPki0P+tp
 2vR1DyyqL+rhKfSzc/9NcBK2eX09iMSV5PHhGi0xSpO7BLDCi7UwoYdOGwX+qmx1
 2RJ3Yv8B8t35L3HdPcsQ1C+OjtPVxevHe28owz40fx9i+R/iqLDMo/14yZ93Qe79
 RplobZzMqXzWEpEXmsZOiwbOjA9A+1CFJ8FSOBT5HARJSD+BVD1iKpKmLfhe2Ioa
 4yiSESXVSek074qdkZ/v9+5+jcX4Qd79oDd1VKFP6PisnITwEcIQhUuFWr38uaZg
 AWthCqSadtL8rSdC3wJPg==
X-ME-Sender: <xms:0jlMaKoiYQDwYc48h2dKY_MSjFz64KNmfcx4lO2Yk5CKKIkYMxdxbQ>
 <xme:0jlMaIqaLhfwTkPBFrcPVVITNNxD6VtMj0OEx8lGam3U8TSdiHk0wu4CwZ4xt8K73
 Tr9a8tLtz_mV5nd3Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddukedvvdcutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
 uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
 hnthhsucdlqddutddtmdenucfjughrpefoggffhffvvefkjghfufgtgfesthejredtredt
 tdenucfhrhhomhepfdfnvghoucfhrghmuhhlrghrihdfuceolhgvohesfhgrmhhulhgrrh
 hirdhnrghmvgeqnecuggftrfgrthhtvghrnhepledtteelleevueevfeetieffudeikeev
 ueduieeufeehteeiueejveduueelfefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrg
 hrrghmpehmrghilhhfrhhomheplhgvohesfhgrmhhulhgrrhhirdhnrghmvgdpnhgspghr
 tghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjeekfeefvdesug
 gvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehsthgvvhgvsehfuhhtuhhrihhl
 vgdrnhgvthdprhgtphhtthhopeiiihhmohhnrdhtohhuthhouhhnvgesghhmrghilhdrtg
 homhdprhgtphhtthhopehguhhigidquggvvhgvlhesghhnuhdrohhrgh
X-ME-Proxy: <xmx:0jlMaPMgSNhcbwQfcI5SAz3WZGOKq6oI01qU7KmPlMSzFlIg_LmZ_w>
 <xmx:0jlMaJ7FN0PnOpEWr_go7aYzNORctKl9T4kqnEwDhD37yeuwHHKafQ>
 <xmx:0jlMaJ7cNihAbXpAZaM_i2ByrImFPS_NxmYJsLYN7LhaUNEEOBGE0w>
 <xmx:0jlMaJh_IFBbQ938tW4PXCk9ar5tDnzyIZr0gS3CfnqRNgG2o5X9cg>
 <xmx:0jlMaM1ASgeDuyWcqg2zU_l63zKqsKFC66x7lY4H06N4KptYpAdBW7_z>
Feedback-ID: i819c4023:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501)
 id 6877615C0080; Fri, 13 Jun 2025 10:46:42 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: T9671f8a29106682c
Date: Fri, 13 Jun 2025 10:46:18 -0400
From: "Leo Famulari" <leo@HIDDEN>
Message-Id: <96857ba3-bb96-4ab6-8298-680a94d95702@HIDDEN>
In-Reply-To: <87y0tw22wp.fsf@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87y0tw22wp.fsf@HIDDEN>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
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 Thu, Jun 12, 2025, at 15:08, Simon Tournier wrote:
> For instance, if a team introduces a graft,
> then this very same team must open a branch that ungrafts and then merge
> this branch as soon as possible; independently of the release.

+1

We have the resources to do this and there's no reason to not be doing it. Ungrafting rarely breaks anything so it should be easy.

Grafting uses energy and disk space on every user's computer.

The build farm has plenty of unused capacity to ungraft, at least on x86_64, which is the only platform that seems to be widely used (there's some evidence that aarch64 has multiple users).

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Andreas Enge <andreas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 13 Jun 2025 18:31:01 +0000
Resent-Message-ID: <handler.78332.B78332.174983945919929 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Liam Hupfer <liam@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174983945919929
          (code B ref 78332); Fri, 13 Jun 2025 18:31:01 +0000
Received: (at 78332) by debbugs.gnu.org; 13 Jun 2025 18:30:59 +0000
Received: from localhost ([127.0.0.1]:50381 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ9B5-0005BN-4l
	for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 14:30:59 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:39730)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <andreas@HIDDEN>) id 1uQ9B1-0005Az-Ha
 for 78332 <at> debbugs.gnu.org; Fri, 13 Jun 2025 14:30:56 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 2DFA81A99;
 Fri, 13 Jun 2025 20:30:49 +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 GPNShQpFAsH6; Fri, 13 Jun 2025 20:30:48 +0200 (CEST)
Received: from jurong (176-179-191-150.abo.bbox.fr [176.179.191.150])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 2AC6E19D9;
 Fri, 13 Jun 2025 20:30:46 +0200 (CEST)
Date: Fri, 13 Jun 2025 20:30:45 +0200
From: Andreas Enge <andreas@HIDDEN>
Message-ID: <aExuVXb_qmj6VJ2Y@jurong>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
 <r6f5xzc27hclbvb3xhaxaxmtya5ty2rled5eyv7kz65qywjncx@xvp4ke3mofl7>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <r6f5xzc27hclbvb3xhaxaxmtya5ty2rled5eyv7kz65qywjncx@xvp4ke3mofl7>
X-Rspamd-Server: hera
X-Rspamd-Queue-Id: 2DFA81A99
X-Spamd-Result: default: False [-5.60 / 15.00]; BAYES_HAM(-3.00)[99.99%];
 NEURAL_HAM(-3.00)[-0.999]; 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-Rspamd-Action: no action
X-Spamd-Bar: -----
X-Spam-Score: 0.0 (/)
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 (-)

Am Sat, Jun 07, 2025 at 01:03:10PM +0100 schrieb Steve George:
> One way to consider that risk is to think about whether a GCD is irreversible (a one-day door). Trying 'regular releases' is not a one-way door. We can try it out, and if it turns out that we can't manage it as a project we'll simply fall back to our current process of irregular releases.

I think you put it very mildly; the real problem of our current process
is that it apparently has turned into "no releases"... This for me is
the most important motivation for this GCD, we need some momentum to
turn around this inertia.

Andreas

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Andreas Enge <andreas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 13 Jun 2025 19:03:01 +0000
Resent-Message-ID: <handler.78332.B78332.174984136129376 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Simon Tournier <zimon.toutoune@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174984136129376
          (code B ref 78332); Fri, 13 Jun 2025 19:03:01 +0000
Received: (at 78332) by debbugs.gnu.org; 13 Jun 2025 19:02:41 +0000
Received: from localhost ([127.0.0.1]:51080 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ9fi-0007da-Sn
	for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 15:02:41 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:40794)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <andreas@HIDDEN>) id 1uQ9fd-0007c3-MI
 for 78332 <at> debbugs.gnu.org; Fri, 13 Jun 2025 15:02:35 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 33C1A2EB;
 Fri, 13 Jun 2025 21:02:26 +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 zaLnCmcXXJaS; Fri, 13 Jun 2025 21:02:25 +0200 (CEST)
Received: from jurong (176-179-191-150.abo.bbox.fr [176.179.191.150])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 724301E0;
 Fri, 13 Jun 2025 21:02:18 +0200 (CEST)
Date: Fri, 13 Jun 2025 21:02:16 +0200
From: Andreas Enge <andreas@HIDDEN>
Message-ID: <aEx1uJekR8ILrWOd@jurong>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87y0tw22wp.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87y0tw22wp.fsf@HIDDEN>
X-Rspamd-Server: hera
X-Rspamd-Queue-Id: 33C1A2EB
X-Spamd-Result: default: False [1.52 / 15.00]; BAYES_HAM(-3.00)[100.00%];
 NEURAL_SPAM(2.62)[0.874]; SUSPICIOUS_RECIPS(1.50)[];
 MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.10)[text/plain];
 FREEMAIL_ENVRCPT(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+];
 FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[];
 RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_THREE(0.00)[4];
 FREEMAIL_TO(0.00)[gmail.com]; FROM_HAS_DN(0.00)[];
 TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[];
 TAGGED_RCPT(0.00)[]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]
X-Spam-Level: *
X-Rspamd-Action: no action
X-Spamd-Bar: +
X-Spam-Score: 0.0 (/)
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 Simon,

Am Thu, Jun 12, 2025 at 09:08:54PM +0200 schrieb Simon Tournier:
> Instead, I think we need two intermediary steps:
>  (1) Clarify what means being a member of a team.
>  (2) Clarify the branching model; especially how to deal with grafts.

these are definitely good points, and I like your suggestion of coupling
grafting with ungrafting commits on a separate (team) branch. But I do
not think these steps are necessary prerequisites to defining a release
process, but rather orthogonal.

> Until now, the bar was high.  Maybe, one way to release more often is to
> decrease the bar so it’s easier to pass it and then we can rise it up,
> by incremental improvements.  This is the section about Package Sets,
> Tiers and Release Artifacts.

I would also say that the GCD is part of that, or more precisely, of
defining a bar: The release team gets more concrete goals than just
"release" - personally, I think I could dare and try to get onto the
release team if this GCD (or a variant) gets adopted, while I would not
even know where to start in the current situation. Also, the goal is to
give some power to the release team to make unpopular decisions, which
people do not dare enough to take right now.

> If the primary Release Manager is not able to keep the commitment (busy
> by life, away from keyboard, unexpected event, etc.), then the secondary
> Release Manager takes the floor.  Right?  But then, this “absent”
> primary Release Manager, does they become the next secondary Release
> Manager?
> Moreover, what does it happen if the both Release Manager are not
> responding?  Do we delay the time to find two new Release Managers?  Or
> is it two of the other members?
> The other question: what does it happen if the Release Team is not able
> to fix a blocker?  Do we delay until the fix?  Do we drop the blocker?
> Who decides?  What is the process for making such decision?
> Who decides if 7 people volunteer to be the next release team?  Hum, it
> will not happen, but still. :-)

I think that your list of "what if" questions is not very helpful, as
ultimately not limited to this GCD, but quintessential to all efforts of
a group of volunteers. What happens if we find too many people wanting
to do the work? Well, I suppose we can work something out, like some of
them being on the first release team, and others on the next one. More
realistically, what happens if not enough people want to do the work?
As said above, part of the goal of this GCD is to lower the bar so that
more people are willing to contribute. For instance, you wonder who
would engage for twice 12 weeks. I think the situation is much worse
right now - someone who volunteers to "do a release" is up for an
unknown amount of work over some unknown time; doing something "time
based" and not "when it is ready" is supposed to lower the burden.
(As an example: "Request for merging core-packages-team branch" happened
five months ago, and we still do not see the end of it after about 20 weeks.)
What happens if nobody does the work, the release team does not respond?
Well then, we will not have a release, but that would not be different
from the current situation, would it?

Andreas

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 13 Jun 2025 20:13:03 +0000
Resent-Message-ID: <handler.78332.B78332.174984556417134 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Andreas Enge <andreas@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174984556417134
          (code B ref 78332); Fri, 13 Jun 2025 20:13:03 +0000
Received: (at 78332) by debbugs.gnu.org; 13 Jun 2025 20:12:44 +0000
Received: from localhost ([127.0.0.1]:52654 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQAlX-0004SD-N5
	for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 16:12:44 -0400
Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:60714)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>)
 id 1uQAlV-0004Rg-Im
 for 78332 <at> debbugs.gnu.org; Fri, 13 Jun 2025 16:12:42 -0400
Received: by mail-wm1-x333.google.com with SMTP id
 5b1f17b1804b1-451dbe494d6so32662495e9.1
 for <78332 <at> debbugs.gnu.org>; Fri, 13 Jun 2025 13:12:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749845555; x=1750450355; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=GqHhu5rRJzdod8auGgJtabX1gyK44kLOHQ39H0RwjKE=;
 b=N9fLdJfWjv3OA3CyG9HVABjtqtaImAUdcy+dlLJM23l19kxuWxZ3Xi/0A/UNJJ7tXQ
 9ljSJ+sQ4lSmxU8KPYTXCxUK8Z9/natxDrVe8U41RTdS5XiZRvlEFiTXsV22qbnv/zqR
 5r6HZUfDEMGUvCaWpTFuxc/blmVcDsP5GaODC9aqgyX/FE7QGP52RSsl8ks8vlS30Y5R
 bLAL4UWw67zOBZBkITxDdh1CF5zC9I/hx3M31HRXivgnLBcp2KvIf198yLFSzPqRPLwG
 Hz4FsbpPr5QkVUW5b9dB+FVbftnMZLztP8ylqYTE5zUOcRmJIJUq/40KjceT8RongePb
 pJ3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749845555; x=1750450355;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=GqHhu5rRJzdod8auGgJtabX1gyK44kLOHQ39H0RwjKE=;
 b=vfM+23clZfSvOuyFc+NDS6MuHTS0V3di/14m6ZGDgctYHCF/IwBgjLQSr+vx6BOUJS
 IgESmGCWXwKhZR8WBZQvvwy1DrUSN+SyoY+Cp7+7fIRGYTUNyb3ktbajTcrKstDS8RNL
 g2Hz9kKZkAlej6EToVWG8Mm9Ry/YNPXeu4ueoMfs30AVfH125dBnl7lDE9pfxf7L4EJe
 Y0nN49lwFpiy/GRZzchz3Xn+dLkhSTI7qlCZ5K8ZVoGJKYf2PX/6yA10MY/hNNPWPiIw
 iennJERm/O8anFi74wXGJ62ISBDfDEK0T1QYVooj+hIOhFEmB1kJrHcDZviq7xenlAeP
 vCGw==
X-Forwarded-Encrypted: i=1;
 AJvYcCUnUOtAxP5sj2NMwhlt5XnJ2fQClWKyiZz5tsg9pluiINqqi5KkMRcrtetUzRZ4blqPLZD/Rg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yxl1Qf1NqWhDFiyuPC7cis7I9LMwAk8n8A78B7SJQGHsEkeA6vJ
 jUTuADjTE6YwcqtxUF+4hQ5HPpvpKWaWj4dYtEdDpFBO/+EQ5qdJgELp
X-Gm-Gg: ASbGncvpjMw6WF3ZopRC8zsmANEUHD7undZXVyOtz7WmyJxuMnXjZYksWeVwa/pBzqa
 nzFcZgPiKKFHV1g0Fl/hMFFd6YRRWeOGDM06XV1Nm7yOTpgaZT12pTUT9Idj4RXdnm1Te6hM2YE
 Df66JjexLvpQI0HmQFx1f6xKNe96GaPcGt9NYaHP7W55tJxmDEBpBg+ZO9g33fhXhSGC9LKsir4
 Ysu4RjfHRnz+GLroMRtPNAyw+ryCDeNPBI+f6dP61vgqVqY66dEwsfh+JLNmL+Sj3hxrptM367T
 r8nUKVug6znC7YzH5WGuSNx/70FlOI+28LzSRxWK3pN4ujfKFgW46h0KDyKgBRI0Yn9THVShYHm
 sOsrNKZR+AQy/kY+V0qk3dD0=
X-Google-Smtp-Source: AGHT+IG0WU/zofdjxQIjjGqiMvKMmsQdvc2MHEqpZ0d33kWLqxW2aNdllc8kFgzT2qa/WxefEdDE4g==
X-Received: by 2002:a05:600c:1c92:b0:43c:f44c:72a6 with SMTP id
 5b1f17b1804b1-4533ca94ed3mr9973705e9.2.1749845555029; 
 Fri, 13 Jun 2025 13:12:35 -0700 (PDT)
Received: from lili (nat-dsi-209.net.univ-paris-diderot.fr. [81.194.30.209])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4532e14f283sm62007565e9.27.2025.06.13.13.12.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 13 Jun 2025 13:12:34 -0700 (PDT)
From: Simon Tournier <zimon.toutoune@HIDDEN>
In-Reply-To: <aEx1uJekR8ILrWOd@jurong> (Andreas Enge's message of "Fri, 13 Jun
 2025 21:02:16 +0200")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87y0tw22wp.fsf@HIDDEN> <aEx1uJekR8ILrWOd@jurong>
Date: Fri, 13 Jun 2025 22:12:20 +0200
Message-ID: <87cyb7l7tn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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 Andreas,

On Fri, 13 Jun 2025 at 21:02, Andreas Enge <andreas@HIDDEN> wrote:
> Am Thu, Jun 12, 2025 at 09:08:54PM +0200 schrieb Simon Tournier:

>> Instead, I think we need two intermediary steps:
>>  (1) Clarify what means being a member of a team.
>>  (2) Clarify the branching model; especially how to deal with grafts.
>
> these are definitely good points, and I like your suggestion of coupling
> grafting with ungrafting commits on a separate (team) branch. But I do
> not think these steps are necessary prerequisites to defining a release
> process, but rather orthogonal.

Yes I agree it=E2=80=99s orthogonal, but still a requirement if we want that
this proposal becomes actionable (have regular releases, concretely).

Let stretch a bit the picture. :-)  Today, each team updates their scope
and they do independently of the others.  The result: it=E2=80=99s almost
impossible to follow and being able to stabilize.

And stabilizing is another word for releasing. :-)

Before, it was small enough to say: Ok, although we still have a stream
of changes, the people who wanted to release fixed themselves the
remaining issues.

Today, that=E2=80=99s almost impossible to =E2=80=9Cfix themselves=E2=80=9D=
 considering the
volume.  That=E2=80=99s one of the reason why we are so reluctant to jump i=
n the
release process over the past two and half year.

If before entering the 12 weeks Release Period and the Teams have not
polished their state, then we will burn out.

IMHO, the success to be able to release once a year every year is mainly
conditioned by the policies we have on the Teams.

Obviously, we can first define the Release part and then define the
Teams.  The former seems a great motivation for the later. :-)

To say it explicitly, I think this GCD 005 can only be actionable if it
comes with another companion GCD about the Teams.

So yes I agree it=E2=80=99s orthogonal, but still a requirement, IMHO. :-)


> I think that your list of "what if" questions is not very helpful

What I want to raise is that =E2=80=9Cregular=E2=80=9D implies to reduce the
=E2=80=9Cimprovisation=E2=80=9D, kind of.

Again, 12 weeks (3 months) of continuous commitment is something.  And
it appears to me better to have beforehand some =E2=80=9Crules=E2=80=9C in =
case it=E2=80=99s not
smooth as expected.  Else it will not be regular, IMHO.

What I would like to clarify is what are the =E2=80=9Cduties=E2=80=9D befor=
ehand and how
we act if they are fulfilled =E2=80=93 no big deal =E2=80=93 it=E2=80=99s o=
nly to avoid the
situations where =E2=80=9Cwe do not know=E2=80=9D and try to figure out som=
ething.

To me, if we want to have something regular, we should reduce the cases
where we have to think about theses unexpected corner cases, because
when trying to figure out, the real work is not done.  Somehow. :-)

Cheers,
simon

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 13 Jun 2025 20:29:04 +0000
Resent-Message-ID: <handler.78332.B78332.174984652623492 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Andreas Enge <andreas@HIDDEN>
Cc: "guix-devel@HIDDEN" <guix-devel@HIDDEN>, "78332 <at> debbugs.gnu.org" <78332 <at> debbugs.gnu.org>, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174984652623492
          (code B ref 78332); Fri, 13 Jun 2025 20:29:04 +0000
Received: (at 78332) by debbugs.gnu.org; 13 Jun 2025 20:28:46 +0000
Received: from localhost ([127.0.0.1]:52889 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQB0z-000661-7U
	for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 16:28:45 -0400
Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]:54681)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>)
 id 1uQB0w-00064d-MN
 for 78332 <at> debbugs.gnu.org; Fri, 13 Jun 2025 16:28:39 -0400
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-5534edc646dso2591149e87.1
 for <78332 <at> debbugs.gnu.org>; Fri, 13 Jun 2025 13:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749846512; x=1750451312; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:references:in-reply-to
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=a4YuahrFcGF3bivAv3ggf7rmD522ORclp7eQOzlpa7k=;
 b=aO8sMHWPUg2dbexSVMqQpbK8YgSItKB0cIha447hoPmg97FjOzS67vH4v4s+iuwBup
 o+XWJqFDdrnigroRG7Nr11UxWrLMPNOmNhvY/Ot9pHjXi7nf7kAd0MXvQxSzm2gVI5K1
 1Xg2VTUagdN0nPlM5o+WoWHVdmns+1NlsZWa8lQIK8LnWdX89uRfUgw6I2YC7RSbSy/R
 p3FBR6O9KtdGcz4WPYKZyGAuJZUcaGwmHo6+yDjaqqO4vUqfg4BavjO8UttZFi5YncpA
 Y9ph9/4uRv1KZByqfN4xPtguJdn7NRd8zhkPuscdpZtA95BJ4TE2Kgy/hU+kTVau2smL
 n2ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749846512; x=1750451312;
 h=cc:to:subject:message-id:date:from:references:in-reply-to
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=a4YuahrFcGF3bivAv3ggf7rmD522ORclp7eQOzlpa7k=;
 b=T/T8ztMTyrzo6JQ28H1iWLejzK6cU6vyON6Us/qJ5QCM+jkkqE086WcNVaZ351wZqm
 0N9TlREoxuHLJIGARN9dRWnl+mP1krFCJanlIoguiSAOs9VPvXMx+Sn7Ko1/08RfeoiS
 0IWqk0zmSoNm5v+YZg+okHVc493zyawJEZGnso7hS9hFu2ZUA5epkOX+ANFa/L8MjDYr
 elFLCDQUnkeuBjTnBb7lDCdvButQME3a+s/RJd6vW02j6gTYBF6yr0temj+Qz7Iq38XZ
 kDh74NQDT/9pi4x6TXOFcNnZcZq2W6MFNO9i1zux1lIZkkju1KHW5eQDlWRPp+XF0jK1
 jN5A==
X-Forwarded-Encrypted: i=1;
 AJvYcCVckWDwgjCPRe3gvD2I8shuXCYrVgs2oVucY7ylgN6ESJIlPxv5RTlgc+tmzWZjLs5RZF1LHw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yx8fLYkxAktgWVMydv9NV1Sf4FkDinBAVadznZ1nZPXmzbkzCPy
 AmlUyJJQARPglkd7KsyAJGnSVHOfGcq2tDZ9ylQ5Qh22WggYhtj2nKGb8oo3f7Iwvi1+weS5fWA
 XSfJmxHEuhQ9lUSy8zUa5H8+O1ypbJYk=
X-Gm-Gg: ASbGnctiMWd6XLBgMCOgiLUcyMlBlmyj4+ihuYzM0bfWbaMMuNT9a6oNg0oevx7Vtjs
 CeX+aND/Tjt2r46D+W6HAf+XEvr8QqLZBHQ4UrrVdWVCID3sojewwBTs+FxKU7O+ei7Dt/s1hSz
 ML0WuRoHOvKkEYXiPTAsal5E1l3aMeh0/x3B/QMvAcbg==
X-Google-Smtp-Source: AGHT+IEKUGRWxNhzqzRUtGZ3lZ+u0S8reHFzoua0jctV/m66QEcCVDPcGhNqR+qE4miI+f2wvOoRfY3K8/6+hWOVXGo=
X-Received: by 2002:a05:6512:3da6:b0:553:5d00:be84 with SMTP id
 2adb3069b0e04-553b6f2bec6mr158629e87.34.1749846512181; Fri, 13 Jun 2025
 13:28:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab2:1184:0:b0:22d:f4f1:1dd7 with HTTP; Fri, 13 Jun 2025
 13:28:31 -0700 (PDT)
In-Reply-To: <87cyb7l7tn.fsf@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87y0tw22wp.fsf@HIDDEN> <aEx1uJekR8ILrWOd@jurong>
 <87cyb7l7tn.fsf@HIDDEN>
From: Simon Tournier <zimon.toutoune@HIDDEN>
Date: Fri, 13 Jun 2025 22:28:31 +0200
X-Gm-Features: AX0GCFsV5N180Hb3u2a0kNWEw0UfxTHzAmdqSvJJlYL1NqrcH4zGHuoxY5-NeUc
Message-ID: <CAJ3okZ05B5Pq2M2CZpAS18VOdsyx2_rxj0FY8zMAO+OQ8CDBBQ@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000c52670063779e318"
X-Spam-Score: 0.0 (/)
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 (-)

--000000000000c52670063779e318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Typo: **not** fulfilled. :-)

On Friday, 13 June 2025, Simon Tournier <zimon.toutoune@HIDDEN> wrote:

> Hi Andreas,
>
> On Fri, 13 Jun 2025 at 21:02, Andreas Enge <andreas@HIDDEN> wrote:
> > Am Thu, Jun 12, 2025 at 09:08:54PM +0200 schrieb Simon Tournier:
>
> >> Instead, I think we need two intermediary steps:
> >>  (1) Clarify what means being a member of a team.
> >>  (2) Clarify the branching model; especially how to deal with grafts.
> >
> > these are definitely good points, and I like your suggestion of couplin=
g
> > grafting with ungrafting commits on a separate (team) branch. But I do
> > not think these steps are necessary prerequisites to defining a release
> > process, but rather orthogonal.
>
> Yes I agree it=E2=80=99s orthogonal, but still a requirement if we want t=
hat
> this proposal becomes actionable (have regular releases, concretely).
>
> Let stretch a bit the picture. :-)  Today, each team updates their scope
> and they do independently of the others.  The result: it=E2=80=99s almost
> impossible to follow and being able to stabilize.
>
> And stabilizing is another word for releasing. :-)
>
> Before, it was small enough to say: Ok, although we still have a stream
> of changes, the people who wanted to release fixed themselves the
> remaining issues.
>
> Today, that=E2=80=99s almost impossible to =E2=80=9Cfix themselves=E2=80=
=9D considering the
> volume.  That=E2=80=99s one of the reason why we are so reluctant to jump=
 in the
> release process over the past two and half year.
>
> If before entering the 12 weeks Release Period and the Teams have not
> polished their state, then we will burn out.
>
> IMHO, the success to be able to release once a year every year is mainly
> conditioned by the policies we have on the Teams.
>
> Obviously, we can first define the Release part and then define the
> Teams.  The former seems a great motivation for the later. :-)
>
> To say it explicitly, I think this GCD 005 can only be actionable if it
> comes with another companion GCD about the Teams.
>
> So yes I agree it=E2=80=99s orthogonal, but still a requirement, IMHO. :-=
)
>
>
> > I think that your list of "what if" questions is not very helpful
>
> What I want to raise is that =E2=80=9Cregular=E2=80=9D implies to reduce =
the
> =E2=80=9Cimprovisation=E2=80=9D, kind of.
>
> Again, 12 weeks (3 months) of continuous commitment is something.  And
> it appears to me better to have beforehand some =E2=80=9Crules=E2=80=9C i=
n case it=E2=80=99s not
> smooth as expected.  Else it will not be regular, IMHO.
>
> What I would like to clarify is what are the =E2=80=9Cduties=E2=80=9D bef=
orehand and how
> we act if they are fulfilled =E2=80=93 no big deal =E2=80=93 it=E2=80=99s=
 only to avoid the
> situations where =E2=80=9Cwe do not know=E2=80=9D and try to figure out s=
omething.
>
> To me, if we want to have something regular, we should reduce the cases
> where we have to think about theses unexpected corner cases, because
> when trying to figure out, the real work is not done.  Somehow. :-)
>
> Cheers,
> simon
>

--000000000000c52670063779e318
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Typo: **not** fulfilled. :-)<br><br>On Friday, 13 June 2025, Simon Tournier=
 &lt;<a href=3D"mailto:zimon.toutoune@HIDDEN">zimon.toutoune@HIDDEN</=
a>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andreas,<br>
<br>
On Fri, 13 Jun 2025 at 21:02, Andreas Enge &lt;<a href=3D"mailto:andreas@en=
ge.fr">andreas@HIDDEN</a>&gt; wrote:<br>
&gt; Am Thu, Jun 12, 2025 at 09:08:54PM +0200 schrieb Simon Tournier:<br>
<br>
&gt;&gt; Instead, I think we need two intermediary steps:<br>
&gt;&gt;=C2=A0 (1) Clarify what means being a member of a team.<br>
&gt;&gt;=C2=A0 (2) Clarify the branching model; especially how to deal with=
 grafts.<br>
&gt;<br>
&gt; these are definitely good points, and I like your suggestion of coupli=
ng<br>
&gt; grafting with ungrafting commits on a separate (team) branch. But I do=
<br>
&gt; not think these steps are necessary prerequisites to defining a releas=
e<br>
&gt; process, but rather orthogonal.<br>
<br>
Yes I agree it=E2=80=99s orthogonal, but still a requirement if we want tha=
t<br>
this proposal becomes actionable (have regular releases, concretely).<br>
<br>
Let stretch a bit the picture. :-)=C2=A0 Today, each team updates their sco=
pe<br>
and they do independently of the others.=C2=A0 The result: it=E2=80=99s alm=
ost<br>
impossible to follow and being able to stabilize.<br>
<br>
And stabilizing is another word for releasing. :-)<br>
<br>
Before, it was small enough to say: Ok, although we still have a stream<br>
of changes, the people who wanted to release fixed themselves the<br>
remaining issues.<br>
<br>
Today, that=E2=80=99s almost impossible to =E2=80=9Cfix themselves=E2=80=9D=
 considering the<br>
volume.=C2=A0 That=E2=80=99s one of the reason why we are so reluctant to j=
ump in the<br>
release process over the past two and half year.<br>
<br>
If before entering the 12 weeks Release Period and the Teams have not<br>
polished their state, then we will burn out.<br>
<br>
IMHO, the success to be able to release once a year every year is mainly<br=
>
conditioned by the policies we have on the Teams.<br>
<br>
Obviously, we can first define the Release part and then define the<br>
Teams.=C2=A0 The former seems a great motivation for the later. :-)<br>
<br>
To say it explicitly, I think this GCD 005 can only be actionable if it<br>
comes with another companion GCD about the Teams.<br>
<br>
So yes I agree it=E2=80=99s orthogonal, but still a requirement, IMHO. :-)<=
br>
<br>
<br>
&gt; I think that your list of &quot;what if&quot; questions is not very he=
lpful<br>
<br>
What I want to raise is that =E2=80=9Cregular=E2=80=9D implies to reduce th=
e<br>
=E2=80=9Cimprovisation=E2=80=9D, kind of.<br>
<br>
Again, 12 weeks (3 months) of continuous commitment is something.=C2=A0 And=
<br>
it appears to me better to have beforehand some =E2=80=9Crules=E2=80=9C in =
case it=E2=80=99s not<br>
smooth as expected.=C2=A0 Else it will not be regular, IMHO.<br>
<br>
What I would like to clarify is what are the =E2=80=9Cduties=E2=80=9D befor=
ehand and how<br>
we act if they are fulfilled =E2=80=93 no big deal =E2=80=93 it=E2=80=99s o=
nly to avoid the<br>
situations where =E2=80=9Cwe do not know=E2=80=9D and try to figure out som=
ething.<br>
<br>
To me, if we want to have something regular, we should reduce the cases<br>
where we have to think about theses unexpected corner cases, because<br>
when trying to figure out, the real work is not done.=C2=A0 Somehow. :-)<br=
>
<br>
Cheers,<br>
simon<br>
</blockquote>

--000000000000c52670063779e318--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] release manifest buildability
Resent-From: Efraim Flashner <efraim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 15 Jun 2025 11:56:01 +0000
Resent-Message-ID: <handler.78332.B78332.174998852619254 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Philip McGrath <philip@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.174998852619254
          (code B ref 78332); Sun, 15 Jun 2025 11:56:01 +0000
Received: (at 78332) by debbugs.gnu.org; 15 Jun 2025 11:55:26 +0000
Received: from localhost ([127.0.0.1]:56153 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQlxM-00050L-PL
	for submit <at> debbugs.gnu.org; Sun, 15 Jun 2025 07:55:25 -0400
Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:43181)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <efraim.flashner@HIDDEN>)
 id 1uQlxJ-0004wh-PH
 for 78332 <at> debbugs.gnu.org; Sun, 15 Jun 2025 07:55:22 -0400
Received: by mail-wr1-x42b.google.com with SMTP id
 ffacd0b85a97d-3a4e742dc97so3002167f8f.0
 for <78332 <at> debbugs.gnu.org>; Sun, 15 Jun 2025 04:55:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1749988515; x=1750593315; darn=debbugs.gnu.org;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:to:from:date:sender:from:to:cc
 :subject:date:message-id:reply-to;
 bh=8/NXNz4IPFONGRbSvHF0PLBrNIAwlDDHxP/7XnT3c6Y=;
 b=jqiXfR5TvYvgsPWkFWenXU5F0YeugelEADfiTixKw9KcQTNzRtJxnzNRllX2syc32i
 2K9MgTUxWkyvF+gysIaRcA24jCsw7WKK/SZdfclCjOqnfxdmuXUcuhPXvJqnBg2wumey
 LloFymAMupIH7gudgKOAixXlxhZJHgKL/yB9KHE99BCtK+0qOX6SmWX5gsCSkMfunXCl
 wjh+ylcc/h3qrgpQjZT1jL8BwgIr43sOVjPFrmZ0ik0po99oq/A5SF+CKu1wKAQWVV6k
 kXRRL64FdrEL+KHv9dgW7B681oSJ3/gki+joeSL5rzmDOV1WEF0OUPCP/Jxhad3eIHnh
 P+8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1749988515; x=1750593315;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:to:from:date:sender
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=8/NXNz4IPFONGRbSvHF0PLBrNIAwlDDHxP/7XnT3c6Y=;
 b=ZIDONAIZ1A4+qZRiozf3pBUpGb4R919YR0lnjWdiD2X73NOn2xpNQIrJNf1SDbV7dd
 vTCpmira/WlveNHMdrtHt2JhMu9nJEVJmrSiu9ZOOlaz41rrP1j3yIFHnbiGqV5DkJS/
 RGijVObLMVpDzvzqYh0+4ZaBtV0Iz5ojFO6ElTt/5a2pVAheSKpcw8V5ZRG4bQRCtlhE
 YR8ZDMJvSj1wYw/bFtxLQpi0OvcNiy0JkunAxA8f64mr4595h14ihE43R0inVFDGLhhn
 U7yLk0VAOuuKOVlQNAJeFeJ1/2W2IrB3JAN5YB5mWJz0DI/gEJSJdCgneWD2jzAI/p3A
 oU4Q==
X-Forwarded-Encrypted: i=1;
 AJvYcCVOsfNWkyHYPfBpVcF5p1QnJKBcUJgRJn8Wu7fZwg75d/gYYJn6OmckRQzxTsyKa+Qp2y0EbQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yzp/L+37V1A9ZjQlvopqc7/i5ULPOwP5H7leMDpKD2gIDN0SXhp
 vC2ZzdwhGsFFnRYkvvrmzp+JzXjUvg5scZQlOb52EzaotvFCsQilSmrmRWf2P1Sk
X-Gm-Gg: ASbGncsBA1Bvz9D5fto6KY4ZnzjQyWU4aeGVxJehhNYXNDtAGHiX7hTVxg0di9TVtwr
 xplBkqqg/V4GLYNk5PKjx5k7B17cFTC84e6Vc7l975aG/y/iKGqOyOeKCabYrYQj2j3tdrLYZAl
 q4EfvPHjoDzt6BMYMDiDaEI1LKM7kZLFZw3cSaK0EfKp6ZLfNhkX/9dSJLwSAWsIIZyQ2L+YxaN
 l1k/hSE32GXH5xILzajRqYYh238JEHdEL1dOYXa2ir1Y/yz0CFBaUU+ete1JfL+AD5MhmSB3Di6
 GvZHThWhLT6fC5SuviqZGV16tSnwPczxSt1l0cBVeBJeazrFgxv0pdeE1pNZ3gsXDrcAh/Y=
X-Google-Smtp-Source: AGHT+IFvDGvAgYedx95K30I0vwcRixlISp/OZM0FlROTUsGvZt3GPospnNeJsPFI0PgV1qPlvCZbGQ==
X-Received: by 2002:a05:6000:18a8:b0:3a4:ed9a:7016 with SMTP id
 ffacd0b85a97d-3a56d84889bmr6361538f8f.26.1749988515323; 
 Sun, 15 Jun 2025 04:55:15 -0700 (PDT)
Received: from localhost ([141.226.13.68]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a568a543d9sm7455409f8f.5.2025.06.15.04.55.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 15 Jun 2025 04:55:14 -0700 (PDT)
Date: Sun, 15 Jun 2025 14:55:13 +0300
From: Efraim Flashner <efraim@HIDDEN>
Message-ID: <aE60oYBNncct3HRa@3900XT>
Mail-Followup-To: Steve George <steve@HIDDEN>,
 Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, guix-devel@HIDDEN,
 78332 <at> debbugs.gnu.org, Philip McGrath <philip@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87o6ux82e5.fsf@HIDDEN>
 <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
 <aEmHfDluw6ZSCQ12@3900XT>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="wQsHk7Jq1dHL3p+S"
Content-Disposition: inline
In-Reply-To: <aEmHfDluw6ZSCQ12@3900XT>
X-PGP-Key-ID: 0x41AAE7DCCA3D8351
X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc
X-PGP-Fingerprint: A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
X-Spam-Score: 0.1 (/)
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: -0.9 (/)


--wQsHk7Jq1dHL3p+S
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I'm responding to my own message here to give a follow-up on my
progress:

On Wed, Jun 11, 2025 at 04:41:16PM +0300, Efraim Flashner wrote:
=20
> (ins)efraim@3900XT ~/workspace/guix$ time ./pre-inst-env guix weather -m =
=2E/etc/manifests/release.scm
> computing 258 package derivations for x86_64-linux...
> looking for 303 store items on https://bordeaux.guix.gnu.org...
> https://bordeaux.guix.gnu.org =E2=98=80
>   100.0% substitutes available (303 out of 303)
>   982.7 MiB of nars (compressed)
>   3,145.6 MiB on disk (uncompressed)
>   0.018 seconds per request (5.6 seconds in total)
>   54.1 requests per second
>   (continuous integration information unavailable)
> looking for 303 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org =E2=98=80
>   100.0% substitutes available (303 out of 303)
>   at least 1,988.3 MiB of nars (compressed)
>   3,145.8 MiB on disk (uncompressed)
>   0.007 seconds per request (1.6 seconds in total)
>   146.2 requests per second

(ins)efraim@3900XT ~/workspace/guix$ time ./pre-inst-env guix weather -m ./=
etc/manifests/release.scm
computing 258 package derivations for x86_64-linux...
looking for 303 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org =E2=98=80
  100.0% substitutes available (303 out of 303)
  981.1 MiB of nars (compressed)
  3,129.4 MiB on disk (uncompressed)
  0.012 seconds per request (3.5 seconds in total)
  86.7 requests per second
  (continuous integration information unavailable)
looking for 303 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org =E2=98=80
  100.0% substitutes available (303 out of 303)
  at least 1,983.2 MiB of nars (compressed)
  3,129.3 MiB on disk (uncompressed)
  0.010 seconds per request (1.3 seconds in total)
  95.0 requests per second

> (ins)efraim@3900XT ~/workspace/guix$ time ./pre-inst-env guix weather --s=
ystem=3Daarch64-linux -m ./etc/manifests/release.scm
> computing 257 package derivations for aarch64-linux...
> looking for 302 store items on https://bordeaux.guix.gnu.org...
> https://bordeaux.guix.gnu.org =E2=98=80
>   82.8% substitutes available (250 out of 302)
>   863.8 MiB of nars (compressed)
>   3,403.9 MiB on disk (uncompressed)
>   0.053 seconds per request (15.9 seconds in total)
>   19.0 requests per second
>   (continuous integration information unavailable)
> looking for 302 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org =E2=9B=88
>   48.7% substitutes available (147 out of 302)
>   at least 287.9 MiB of nars (compressed)
>   815.4 MiB on disk (uncompressed)
>   0.004 seconds per request (1.2 seconds in total)
>   260.5 requests per second

(ins)efraim@3900XT ~/workspace/guix$ time ./pre-inst-env guix weather --sys=
tem=3Daarch64-linux -m ./etc/manifests/release.scm
computing 257 package derivations for aarch64-linux...
looking for 302 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org =E2=98=80
  82.8% substitutes available (250 out of 302)
  864.3 MiB of nars (compressed)
  3,405.2 MiB on disk (uncompressed)
  0.017 seconds per request (5.1 seconds in total)
  58.7 requests per second
  (continuous integration information unavailable)
looking for 302 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org =E2=9B=88
  45.7% substitutes available (138 out of 302)
  at least 229.2 MiB of nars (compressed)
  617.3 MiB on disk (uncompressed)
  0.004 seconds per request (0.7 seconds in total)
  228.3 requests per second

> 100% on x86_64 (and has been every time I've checked recently). I'm not
> sure how much is waiting for rebuilds on aarch64 or how much needs
> fixing.  Currently it's bcachefs-static, xfce, mate, gnome, and some
> u-boot packages.

Still 100% on x86_64 and the substitutes available for aarch64 haven't
gotten any better.

(ins)efraim@3900XT ~/workspace/guix$ time ./pre-inst-env guix build --no-gr=
afts --system=3Daarch64-linux -m ./etc/manifests/release.scm -n
substitute: looking for substitutes on 'https://bordeaux.guix.gnu.org'... 1=
00.0%
substitute: looking for substitutes on 'https://ci.guix.gnu.org'... 100.0%
substitute: looking for substitutes on 'https://cuirass.genenetwork.org'...=
 100.0%
substitute: looking for substitutes on 'http://guix.genenetwork.org'... 100=
=2E0%
substitute: looking for substitutes on 'https://guix.tobias.gr'... 100.0%
The following derivations would be built:
  /gnu/store/rg000i2bf7fy0najxm4l2vzs2yxl41gl-sbsigntools-0.9.5.drv
  /gnu/store/rp5hwwjal27lqscgw4228z664l6sr69v-efitools-1.9.2.drv
  /gnu/store/m2s2gr1irz50b2lscs5bh3sngj2qhq15-u-boot-sandbox-2025.01.drv
  /gnu/store/9h67k1p5hljx5g0hgrs0j6zyq372y03c-u-boot-ts7970-q-2g-1000mhz-c-=
2015.04_3-0.0880916.drv
  /gnu/store/l82dg6cmgkak262xbv78kz55w27jzcc0-u-boot-nintendo-nes-classic-e=
dition-2018.11.drv

So sbsigntools -> efitools -> u-boot-sandbox and then the 2 old u-boot
packages.  I think that's the equivalent of 297/302 for 98.3%.

--=20
Efraim Flashner   <efraim@HIDDEN>   =D7=90=D7=A4=D7=A8=D7=99=D7=9D =
=D7=A4=D7=9C=D7=A9=D7=A0=D7=A8
GPG key =3D A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

--wQsHk7Jq1dHL3p+S
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmhOtJ0ACgkQQarn3Mo9
g1EAIw//Xhgh1tQpdcYPajS5IRSb0T30GuvPJvrr06KgqgIHYkdXB1tIk8G9AT9c
9N32Vo8ktPhAz/zdhgDOvgLFhGyAihcYCz98BfSgxkPR1rrHbNFoai3JpPUUqLSC
l1YTUBXwFsxrEToCCHL7kv9lp6d7GN9+BHBjUa5/i/7Z+JsTRZNM/e7DjFO8Jnoh
M20EFvxe+ICWfTLOTuo2rLksbYfhg9/+6wi0AgcIyTueDR4NyBomFl9ZIpGrcP/6
G7IAfWSGZMbiWf+4WiyQLYyW6nenO9WFJpgjhnszqE+gKdaxvfkCp0VbjM3mgy6D
/AgmMlPVoUzHzKibGqFqnRfg5RdjjAE/XzgI7Y755WR48i1FNl5o0SmhrCH64fsG
bVHJvuGioYHc1Pc6CCGq9qHBVMc1AVc/CKo+/iORWt9ZQYYY/2ksUcnO1euRVpjk
LtGUSQWLlczbj5frgrx8D8myl5A4IBcxGcm+hZH/HU9F9JOtMtCFEq6hskKGGklz
WoufJkOGGaUFSSuPJs5g3lVS6Jl2YRVK8ARPiWgyg3aLZEQ5Sab6v5AL4Mga7+3w
yk7ta4t4sz1WmJKp0r/Smm3G3idhcDYQq1Oh8J6gQMc5XAJBWHOywcFvv9Ql8hAq
McVfP15EsuGUEnEFe+ebAOB7Gn+LVYFQU8lX3oITz5tzzFoFxnw=
=JmYX
-----END PGP SIGNATURE-----

--wQsHk7Jq1dHL3p+S--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Olivier Rojon <o.rojon@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 18 Jun 2025 04:53:02 +0000
Resent-Message-ID: <handler.78332.B78332.175022238127000 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175022238127000
          (code B ref 78332); Wed, 18 Jun 2025 04:53:02 +0000
Received: (at 78332) by debbugs.gnu.org; 18 Jun 2025 04:53:01 +0000
Received: from localhost ([127.0.0.1]:42021 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uRknC-000718-Vu
	for submit <at> debbugs.gnu.org; Wed, 18 Jun 2025 00:53:00 -0400
Received: from mout02.posteo.de ([185.67.36.66]:38917)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <o.rojon@HIDDEN>)
 id 1uRkn6-00070D-Pi
 for 78332 <at> debbugs.gnu.org; Wed, 18 Jun 2025 00:52:56 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 176A2240101
 for <78332 <at> debbugs.gnu.org>; Wed, 18 Jun 2025 06:52:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net;
 s=1984.ea087b; t=1750222365;
 bh=To1r5qkLJXqEq08/ctV5dOf1nwePMVGuKrpYD7NGMjo=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=iRKMPyCDp4JlpZi3qbWJjmzFMhu8I+9YJKFXXN/KhdtS7Tvp1dsEZaEU8Nstf/u9T
 nXGcvsomRN+DEIueROqjEQVvcmWEU4KT7qaXbIWXZyRraThkNqGe+Glg7O5Cygh7Cd
 rQvrHK30RToezhFKYE70vaIFPZz4FVCtN10L1OvMO0dQO9KRucoRFteJv4Qo8zRIa2
 CyOkf2+AHb1bclyzDgif3LrthYgGAidYAIA1umfgRa1Pp1Bo4chCiFHpsw806CtypS
 bup1dL/a9R3ZPidkf1POjEFDkTar2jxGWIPOsVuUSf1ivDEGBWGgaapJDbQ5TmmZQ6
 wqLFSeyuUsk+032wfXz/xOMY74C1FOKvtzPtHIjjwF1CKRaCsVguA/W126qP/qaSlv
 osde7XprWIxMG+Q3zB2+IjUVmo+5/6Xx46l+Y9G+eVCYotB0Lwv3C4wvgWEczyrFzU
 oZcJ7YC6/1riItTJfSNk0LlUeEckSEqSntMaDEA3IkuneYcpUjR
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4bMWZN1TkXz6tx2;
 Wed, 18 Jun 2025 06:52:44 +0200 (CEST)
From: Olivier Rojon <o.rojon@HIDDEN>
In-Reply-To: <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 (Steve George's message of "Wed, 21 May 2025 18:10:13 +0100")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
Date: Wed, 18 Jun 2025 04:52:42 +0000
Message-ID: <87qzzhk5wl.fsf_-_@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -2.3 (--)
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: -3.3 (---)

--=-=-=
Content-Type: text/plain

Hi Steve, hi everyone,

first things first, thank you so much for your efforts for the Guix project.  Your awesome
newbie-friendly blog posts, the Guix User and Contributor Survey, this GCD - thanks!

I have some comments to make (see below), but from my point of view, none of them HAVE to
lead to changes in the GCD, because especially considering the proposed iterative nature
of the process, many things will turn up during the first (or second, or third, ...)
iteration that will lead to changes.  Overall, I think that this GCD proposes a
much-needed structure to a frighteningly complex process that too often is stemmed by too
few people.  I think most of its parts are actionable as is, and I really appreciate that
you took so much time to investigate how other distributions do it and that you spelt out
a road map that the release team can use to guide their actions.  I am certain that I
would be lost without such guidance, and I do appreciate that leeway for unpopular "behind
the scenes" work such as ungrafting is taken into consideration.

=================================================================

Package Sets
============
I have to admit to a certain brain tangle when it comes to this topic and I read many
contributions to the discussion to go towards this direction.  If I understood the
discussion correctly, the first release process is likely to feature Guix veterans.
Wouldn't it be possible to deliberately underspecify which package sets (how many) are
present and what their contents are?  This could take two different forms: one would say
that the release team can decide what to feature provided they test it according to the
outlined criteria (for all architectures etc), the other would say that the first release
team (comprised of veterans) lays the ground work and future release teams might have some
wiggle room.

release cycle start in $SPRING
==============================
for me personally the Guix Days were a catalyst and were motivating me to get involved
more concretely in the project than beforehand.  Maybe the end of Guix Days/FOSDEM could
be mentioned as a concrete starting point because then, a possible release team has
(possibly) had time to coordinate in person what awaits them in the following weeks.  And
if it hadn't had time, (possible) members of the release team have had ample opportunity
to charge their social and geek batteries and might be willing and able to release it ;-)

iterative process improvements/Release Cheat Sheet
==================================================
I think it is a very important step in the iterative process of release management that
lessons learnt make future iterations easier.  The discussion has often times mentioned
automation, the GCD mentions the "communication afterwards, possibly with a blog post".
My supplementary idea is to write up a kind of "TODO List" or a "Release Cheat Sheet" (or
whatever you want to call it) that mentions either (a) all the steps required from start
to finish (that's what helps me with complex tasks where I need to be vigilant with each
step so I don't want to think about the overall structure, or (b) the typical GOTCHAS,
things that you forgot that really came back to bite you. 

motivation for release: sync codebase and documentation
=======================================================
I don't know if that has already been mentioned, but another reason why a release can be
good is to have a kind of synchronisation between what the distro can do and what is
documented (where).  The current state of affairs is to make sure to always use the devel
version of the manual which I think is a terrible way to introduce newbies, while the 1.4
version -- the "correct" manual for the installer you download and install -- features
quite some dead links etc. while being so out of date in places that we might as well --
I'm exaggerating to make a point -- replace it with a fantasy novel.

META: structure of the document
===============================
Would it make sense to make the sections "Package Sets", "Plattforms and Architecture tiers", "Release artifacts" and "Release team and project" top level headings?  The way I read it they appear as aspects of the whole GCD while not standing in a content dependency relation to the "Motivation" section.

The same applies to the Appendix section, where I'd argue that when the Appendix is a
top-level heading and the explanation of the different "Events" are its direct children,
it would make sense to have their explanation on level 2 and not level 3.

@text: Package Set Finalisation
=========================
I don't understand the following sentence:

> Packages that do not build for the primary architectures so could be risk of removal
> will be identified and developers will be notified following the Deprecation Policy.

The sentence would be fine without the part "so could be risk of removal".  This part of
the sentence (to me) alludes to another aspect -- "risk of removal" -- that remains
underspecified and thus causes confusion.  Unless it is a mistake, I think it would be a
good idea to rephrase to make the two aspects "deprecation of packages that don't build on
the primary architecture" and "risk of removal" clearer.

@text: Toolchain and transition freeze
======================================
Maybe a criterion such as with package updates could be used here, like "if a change in
package X incurs change in Y (say, 50) other packages, it needs to be treated specially".

=================================================================

I also append a patch file.  Here I applied some (or all? dunno) the proposed "structure
of the document" and made some minor edits that I came across while reviewing the
document.

Again, thank you so much for your contribution, Steve! :)

Have a good day everyone,
Olivier


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=20250618T061100--guix-consensus-document-gcd-005-proprosed-changes.patch
Content-Description: document structure and minor edits

--- 20250605T061200--guix-consensus-document-gcd-005-regular-releases-version-2.md	2025-06-10 06:39:00.000000000 +0200
+++ 20250611T061200--bearbeitung-guix-consensus-document-gcd-005-regular-releases-version-2.md	2025-06-12 06:11:40.000000000 +0200
@@ -106,7 +106,7 @@
 the **November of 2025**, with a short cycle to release in June 2026.
 
 
-## Package Sets
+# 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.
@@ -157,7 +157,7 @@
 Linux kernel could block a release, but not an issue in a game.
 
 
-## Platforms and Architecture tiers
+# 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
@@ -194,7 +194,7 @@
 a release would be removed from the archive using Guix's deprecation policy.
 
 
-## Release artifacts
+# Release artifacts
 
 Using the primary architecture tier and the package sets would involve creating
 the following release artifacts:
@@ -208,7 +208,7 @@
 not block a release.
 
 
-## Release team and project
+# 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
@@ -291,11 +291,9 @@
 steps to be undertaken by the project to release a new version of Guix.  It
 proposes freezing master while the team focuses on releasing the new version
 of Guix. Specifically, a major updates freeze (week 8->12), and a hard freeze
-(week 10->12).  The drawback of this approach is that it would slow the
-velocity of changes.  During this period contributors would have to keep
-updates on team branches, or use an alternative temporary branch.  Each Release
-Team will iterate and improve the release process, so it's possible that this
-freeze period will be reduced, changed, or removed over successive releases.
+(week 10->12).
+
+The drawback of this approach is that it would slow the velocity of changes.  During this period contributors would have to keep updates on team branches, or use an alternative temporary branch.  Each Release Team will iterate and improve the release process, so it's possible that this freeze period will be reduced, changed, or removed over successive releases.
 
 There are various improvements that could be made to the release strategy over
 time, such as adding an additional slower release cadence.
@@ -335,21 +333,21 @@
 | +2 | Release retrospective |
 | +2 | Relax - it's done! |
 
-### Nominate a release team (week -5)
+## Nominate a release team (week -5)
 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.
 
-### Notify teams of upcoming release (week -4)
+## Notify teams of upcoming release (week -4)
 Make sure all teams are aware of the upcoming release.  This gives them 4 weeks
 to undertake any large transitions or major changes.
 
-### Release project start (week 01)
+## Release project start (week 01)
 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.
 
-### Package set finalisation (week 03)
+## Package set finalisation (week 03)
 Specify the package sets for this release.  The Release Team will identify all
 packages and their inputs so that a full manifest for the release is created.
 
@@ -357,7 +355,7 @@
 removal will be identified and developers will be notified following the
 Deprecation Policy.
 
-### Toolchain and transition freeze (week 04)
+## Toolchain and transition freeze (week 04)
 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.
 
@@ -370,7 +368,7 @@
 No alterations to the Guix daemon are accepted after this point.  Packages
 and services in the 'minimal' package set should not be altered.
 
-### Initial testing (week 06)
+## Initial testing (week 06)
 An initial testing sprint to look at packages, services, install media and
 upgrade testing. This should identify:
 
@@ -388,7 +386,7 @@
 A build failure of a package or service that's in a package set will be marked
 as a blocker for the release: Release Team to make determination on response.
 
-### Major updates freeze (week 08)
+## Major updates freeze (week 08)
 Major package updates are frozen on 'master' as the focus is on fixing any
 blocking packages.  **Security updates still go to 'master'**.
 
@@ -397,7 +395,7 @@
 Team branches can still be folded into the release branch as long as changes are
 minor package upgrades.
 
-### Breaking changes to an integration branch (week 08)
+## Breaking changes to an integration branch (week 08)
 If there are major breaking changes that must be moved from a team branch an
 integration branch will be created. For example `next-master`, this will be
 short-lived, existing only until after the release.
@@ -408,15 +406,15 @@
 staging branch while they do release stabilisation to prevent big flows of
 breaking changes into master which broke one of their releases [^7].
 
-### Ungraft master branch (week 08)
+## Ungraft master branch (week 08)
 Guix master is ungrafted to minimise the difference with users of the release
 initial 'guix pull' experience.
 
-### Bugs and documentation focus (week 09)
+## Bugs and documentation focus (week 09)
 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.
 
-### Branch and tag release branch (week 09)
+## Branch and tag release branch (week 09)
 The master branch is tagged and a new release branch is created.
 
 * master branch: security only.
@@ -426,7 +424,7 @@
 changes stay in a team branch or go to an integration branch.  The focus on the
 release branch is to stabilise so only resolutions to bugs should be pushed.
 
-### Testing and Hard Freeze (week 10)
+## Testing and Hard Freeze (week 10)
 Release Crictical (RC) bugs and issues should be solved for the release branch.
 
 Only changes that will fix a non-building package, or a RC bug in a
@@ -438,13 +436,13 @@
 Call for testing from all developers and users: goal is to test the main
 installation use-cases and packages within the `package sets`.
 
-### Release candidate (week 10)
+## Release candidate (week 10)
 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 release uses these artifacts.  If bugs are found/fixed then
 release artifacts are regenerated as needed.
 
-### Final release target (week 12)
+## Final release target (week 12)
 Final release is targeted for this date. All planning and work should be done
 to this date.
 
@@ -455,7 +453,7 @@
 The concept of buffer weeks to ensure the release balances time and quality
 comes from [Fedora's release plan](https://docs.fedoraproject.org/en-US/releases/lifecycle/#_release_dates)
 
-### Alternative release target #1 (week 14)
+## Alternative release target #1 (week 14)
 This release target date may be used if the Release Team determines that there
 were Release Critical bugs without workarounds at the Final release target
 date.
@@ -464,7 +462,7 @@
 workarounds at this date they may move the release to Alternative release
 target #2.
 
-### Alternative release target #2 (week 16)
+## Alternative release target #2 (week 16)
 This release target date may be used if the Release Team determines that there
 are Release Critical bugs without workarounds at one of the previous target 
 dates.
@@ -473,17 +471,17 @@
 without workarounds they may move the release to an alternative date or cancel
 the release.
 
-### Integration branch merged to master (release +1 week)
+## Integration branch merged to master (release +1 week)
 If there were any breaking changes placed onto the integration branch
 (e.g. `next-master`) then these can be merged into the `master` branch at this
 point.  The master branch then continues as normal.
 
-### Release retrospective (release +2 weeks)
+## Release retrospective (release +2 weeks)
 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.
 
-### Relax! (release +2 weeks)
+## Relax! (release +2 weeks)
 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

--=-=-=
Content-Type: text/plain


Steve George <steve@HIDDEN> writes:

> Hi all,
>
> Thanks for all the feedback on the initial proposal.
>
> I've integrated it into the GCD so attached is a revised version. I think it's ready to move to the Discussion Period (minimum 30 days from today).
>
> A short summary of the changes in this version:
>
>   - Rename staging to integration branch with suggestion of next-master [Zheng Junjie]
>   - Add benefit of updated distribution through other package managers [Rutherther]
>   - Remove reference to faster initial git pull [Rutherther]
>   - Move target annual release to June [Rutherther]
>   - Reduce freeze period by breaking it up into stages [Rutherther & others]
>       - updates freeze (week 8->12), hard freeze (week 10-12)
>   - Identify pacakge sets earlier [Vagrant]
>   - Reword template plan to show weeks [Vagrant]
>   - Add alternative release target weeks to plan [Vagrant]
>   - Identify 'at risk' packages earlier [Greg / Andreas]
>   - Make automation a goal of the Release process & release team [Greg / Ekaitz / reza]
>   - Reduce the scope of package sets [Jelle / Efraim]
>   - Provide more clarity on dealing issues in package sets [Rurtherther]
>   - Try to clarify options around RC bugs and package build failures
>   - Try to clarify purpose of release project plan as a template
>
> I would love to know if this improves things from any feedback that you gave?
>
> As well as any other thoughts, comments or ideas on how to improve this GCD!
>
> Steve / Futurile

--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] approximated popcon? (was Re: GCD005: Regular and efficient releases)
Resent-From: Maxim Cournoyer <maxim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 18 Jun 2025 07:35:01 +0000
Resent-Message-ID: <handler.78332.B78332.175023205830355 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Simon Tournier <zimon.toutoune@HIDDEN>
Cc: Vagrant Cascadian <vagrant@HIDDEN>, guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175023205830355
          (code B ref 78332); Wed, 18 Jun 2025 07:35:01 +0000
Received: (at 78332) by debbugs.gnu.org; 18 Jun 2025 07:34:18 +0000
Received: from localhost ([127.0.0.1]:44424 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uRnJH-0007tN-JY
	for submit <at> debbugs.gnu.org; Wed, 18 Jun 2025 03:34:18 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:52250)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <maxim@HIDDEN>)
 id 1uRmoK-0004Ok-0d
 for 78332 <at> debbugs.gnu.org; Wed, 18 Jun 2025 03:02:17 -0400
Received: from mailtransmit03.runbox ([10.9.9.163] 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 <maxim@HIDDEN>)
 id 1uRmoC-00BhPG-GN; Wed, 18 Jun 2025 09:02:08 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=guixotic.coop; s=selector1; h=Content-Transfer-Encoding:Content-Type:
 MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From;
 bh=NjMw9xhB/qS7Bh8lK7iXINYVPw7PpAVXH1kUEJXBqF4=; b=nIE040xSZ55OT8ivm8VpVN/ozw
 bH/Emfr+owfA34aE2h5CPC1g6A5aDzHVB0Q3BY+sbXmjAcLR7l1ciLyiuT+0r57CpMZIT/pqbXC1H
 F+IIW+znaAx4b/rXn5ieF89E/UUmfNC5klWgw9PFwgu/QPPm2830XbiXXrR0DqddRZzLFWHKB7tyF
 YhIgj3QdQxpEsoIHioycQFDOcDlNqgIpHs/vUTcjNi39C0RfI5hH3V5IKJHsTlhM3q3AwJ2h2msY5
 XDQBhQWm5XADCfLeatG0Yt9sj/nRyiHKp0hYntNYBa+qKaZCibagbtkbp8pgW5f0QeqLQvPXhIWIn
 DR4uMoDQ==;
Received: from [10.9.9.72] (helo=submission01.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <maxim@HIDDEN>)
 id 1uRmoB-0007qf-QB; Wed, 18 Jun 2025 09:02:07 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (1476852)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uRmnx-00CHdj-Oj; Wed, 18 Jun 2025 09:01:54 +0200
From: Maxim Cournoyer <maxim@HIDDEN>
In-Reply-To: <87plf81xrm.fsf@HIDDEN> (Simon Tournier's message of "Thu, 12
 Jun 2025 22:59:57 +0200")
Organization: Guixotic
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <8734ddpnu7.fsf@wireframe>
 <fgc57qffjxkfbqq5paewtef2tnsnr5kqrh2jw53btuehocly27@ubjbk5vtq5q2>
 <87plf81xrm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
Date: Wed, 18 Jun 2025 16:01:50 +0900
Message-ID: <87plf1zg69.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Mailman-Approved-At: Wed, 18 Jun 2025 03:34:14 -0400
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 Simon,

Simon Tournier <zimon.toutoune@HIDDEN> writes:

> Hi,
>
>> As we don't have popcon I don't know what's popular with users
>
> Once I heard a Debian Developer says: the aim of popcon isn=E2=80=99t to =
take
> less care of unpopular packages but the contrary.  It allows to know
> that this package in appearance useless and/or outdated is still used by
> one user so it=E2=80=99s a motivation to still maintain its availability.
>
> Although hard when the resource is constrained, I like the
> reasoning. :-)
>
> Aside, maybe we could have a rough idea of some popular packages by
> looking at the queries in the substitutes cache.
>
> Guix sysadmin, is it doable?

I suppose it could be done by processing the nginx access logs.

--=20
Thanks,
Maxim

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] approximated popcon? (was Re: GCD005: Regular and efficient releases)
Resent-From: Simon Tournier <zimon.toutoune@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 19 Jun 2025 13:03:02 +0000
Resent-Message-ID: <handler.78332.B78332.175033814632420 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxim Cournoyer <maxim@HIDDEN>
Cc: Vagrant Cascadian <vagrant@HIDDEN>, guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175033814632420
          (code B ref 78332); Thu, 19 Jun 2025 13:03:02 +0000
Received: (at 78332) by debbugs.gnu.org; 19 Jun 2025 13:02:26 +0000
Received: from localhost ([127.0.0.1]:33555 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uSEuP-0008Qj-NW
	for submit <at> debbugs.gnu.org; Thu, 19 Jun 2025 09:02:26 -0400
Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:59569)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <zimon.toutoune@HIDDEN>)
 id 1uSEuM-0008PI-CJ
 for 78332 <at> debbugs.gnu.org; Thu, 19 Jun 2025 09:02:23 -0400
Received: by mail-wm1-x335.google.com with SMTP id
 5b1f17b1804b1-451ebd3d149so4867355e9.2
 for <78332 <at> debbugs.gnu.org>; Thu, 19 Jun 2025 06:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1750338134; x=1750942934; darn=debbugs.gnu.org;
 h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=NdZkoAfN3pzVWNI3YL73jBSinoKHC1OP5Od7UKDCAdw=;
 b=QM9dXRzOJmS3gzdqlMKDajmZ3AzfCmmLQOPe7WBuZz1hI2jblvxrVlVOn2aggyTpQE
 XlmWnka0KHsKezkf+yiul3KPCqyO6ehyRlhUMoG5REHiaA01Y8a3b7vI1jNi9KBdxXWN
 OiQccosa0d4yFgFauLV1atuMeDHD0IFmeT3X/M3U+aeCpvR0hd4dE630WFe2825A/uB7
 XxRwOgiwlpULdtfif9AyLNv90RQHp8KjHFaoMrToOg50f+8ApNl8irL4j5aulzvNaS9j
 2fzbTJnSPeuYEeXjPNXcj/v54s5zvRftHx4O0WljYnM3lUguhND0XP9bZQ5oTYGx0mWM
 Mo4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1750338134; x=1750942934;
 h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=NdZkoAfN3pzVWNI3YL73jBSinoKHC1OP5Od7UKDCAdw=;
 b=sdiETAveLmKVmxSxsnoFilEloKHqhTEbwafnZLe7cUt4Ih1lptHZFqn/FhYoufEs80
 2Z1palortbg7s7iWEgoAhSOhAri3h7Ye2V6QoTnn74Hqxh7M4q7nPDHlBwJFwwxAUfYT
 1Z131JiKxsJFas/gbdc5OqqGUwOen4J7FBowSQRFSrV+8lNHa9xyGPheBxP2LzaeMAG8
 F0I0BT6aEGJ7ecwpk+sfk+ZVrhy0tI6UAZnwq1wmJnQlKcAyfEfkNjQrYsPQKJRRsYCz
 0HPb/OnMRPbE7+s+Ix2K0kB07Zzbx3fHxtkkPRNqyMNNxAyk5eAuxo1VHqS1ZNDRZmZc
 s6Xw==
X-Forwarded-Encrypted: i=1;
 AJvYcCVQnR70E8FWOsb1FApCUYoBV8qaKEigTpld2PE/DUt+aUDC+VtkbKpQ+wnQH0HsPsArmldUIQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yxjmdft7Na32imbMuJ4xK8JWDATcMVktT1hcqFd9+GjExqVj8i2
 pTPLSWdviBRJ0INHbnvVaNEbyKxL+v7vuZw3Jse+9W3/0WCvAepHoGO4
X-Gm-Gg: ASbGnctR79lp9AJkAG4L84kW/4OoLk7TNoYd14Wpqbyy8XjLvlCJ2P164EJRkx6xcY0
 i+QJPljd3oN9ecjfJ8q1hcl9zF+5sudIkXUK+6FzutDxTiZ5JRjRhR20beblpTu8zlHxoN08rs0
 c//ALVPGJHqLnTDsIQtCn11xh/g4nxbj7G5bDXtOvvSdfiNitScDS/adjNe2NvgWUIyiv1N4fSu
 BST7HC4rHMk20b0MWwlnfFkXPf41rgeN0znmdi1Y3r1Hxsv8VRxCGte/fCNf3pY1LAxTrTuIVHr
 PlGlhVOBLsL1Lbe6DiZEJ/Id6Kb3s0Jm9S735Q7Dgnx5xEYBx30GubqYT9TlRN437HTbpG0oKaS
 zyUNZHEXUHnoyB6cyG5R2SBo=
X-Google-Smtp-Source: AGHT+IG+hfSvRz9YSutxNgkqb7rHBhF5eBPzQpQwl8Q4YlIj4Er3CzQxM3T8gJBWCBxHHqqqPDPTaw==
X-Received: by 2002:a05:600c:3585:b0:43d:abd:ad1c with SMTP id
 5b1f17b1804b1-453449eb6c3mr169644275e9.6.1750338133797; 
 Thu, 19 Jun 2025 06:02:13 -0700 (PDT)
Received: from lili (nat-dsi-209.net.univ-paris-diderot.fr. [81.194.30.209])
 by smtp.gmail.com with ESMTPSA id
 5b1f17b1804b1-4535e97aa15sm29488845e9.2.2025.06.19.06.02.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 19 Jun 2025 06:02:13 -0700 (PDT)
From: Simon Tournier <zimon.toutoune@HIDDEN>
In-Reply-To: <87plf1zg69.fsf@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <8734ddpnu7.fsf@wireframe>
 <fgc57qffjxkfbqq5paewtef2tnsnr5kqrh2jw53btuehocly27@ubjbk5vtq5q2>
 <87plf81xrm.fsf@HIDDEN>
 <87plf1zg69.fsf@HIDDEN>
Date: Thu, 19 Jun 2025 14:15:29 +0200
Message-ID: <87a5643p26.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
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 Maxim,

On Wed, 18 Jun 2025 at 16:01, Maxim Cournoyer <maxim@HIDDEN> wrote:

> I suppose it could be done by processing the nginx access logs.

Do you think it would be possible to send them?  Offlist if
required. :-)

Cheers,
simon

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] approximated popcon? (was Re: GCD005: Regular and efficient releases)
Resent-From: Maxim Cournoyer <maxim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 20 Jun 2025 04:04:02 +0000
Resent-Message-ID: <handler.78332.B78332.17503922212028 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Simon Tournier <zimon.toutoune@HIDDEN>
Cc: Vagrant Cascadian <vagrant@HIDDEN>, guix-devel@HIDDEN, Maxim Cournoyer <maxim@HIDDEN>, Steve George <steve@HIDDEN>, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17503922212028
          (code B ref 78332); Fri, 20 Jun 2025 04:04:02 +0000
Received: (at 78332) by debbugs.gnu.org; 20 Jun 2025 04:03:41 +0000
Received: from localhost ([127.0.0.1]:43338 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uSSya-0000Wb-IZ
	for submit <at> debbugs.gnu.org; Fri, 20 Jun 2025 00:03:40 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:50036)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <maxim@HIDDEN>)
 id 1uSSyY-0000Vp-6u
 for 78332 <at> debbugs.gnu.org; Fri, 20 Jun 2025 00:03: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 <maxim@HIDDEN>)
 id 1uSSyR-00GER7-SB; Fri, 20 Jun 2025 06:03:31 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=guixotic.coop; s=selector1; h=Content-Type:MIME-Version:Message-ID:Date:
 References:In-Reply-To:Subject:Cc:To:From;
 bh=yT193fqXVCNtSrjWAc7cNgkpIHMP12Yky6jZ3MuepMQ=; b=KKcnjuIUPDw6Tq1edV1Loiios6
 BGOSsaIU9PQ+Ve5umpAA/wZnih3N68Dt3k/LidfYrJWOhlf2dPQzfjSlKVsOkSkImpgrUPBetJ+6H
 vN6MHcsXT7myB11HGL6i4qzWqFA78vgRYuaU3iIYBegcwJRZcVUpNBfNtS8k6T97vkQBuNDxptfrP
 Ru/n+3iomhMpfOz8u4UThYNjOC6Dd9MAzDKDRjG2MIiauzsDT4HRegD8BfZwKWng/qTd9qVfryv2m
 U4UFPhLcA+kHu/zUMmfkSNJH+Iq+JhrHzh+zQoq6jhkGbpJssPWLKtkn/9NkEz7b+V7hJRJH2icxv
 4Dj004QA==;
Received: from [10.9.9.73] (helo=submission02.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <maxim@HIDDEN>)
 id 1uSSyR-0000LV-DI; Fri, 20 Jun 2025 06:03:31 +0200
Received: by submission02.runbox with esmtpsa [Authenticated ID (1476852)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uSSyB-008mWG-Pg; Fri, 20 Jun 2025 06:03:16 +0200
From: Maxim Cournoyer <maxim@HIDDEN>
In-Reply-To: <87a5643p26.fsf@HIDDEN> (Simon Tournier's message of "Thu, 19
 Jun 2025 14:15:29 +0200")
Organization: Guixotic
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <8734ddpnu7.fsf@wireframe>
 <fgc57qffjxkfbqq5paewtef2tnsnr5kqrh2jw53btuehocly27@ubjbk5vtq5q2>
 <87plf81xrm.fsf@HIDDEN>
 <87plf1zg69.fsf@HIDDEN>
 <87a5643p26.fsf@HIDDEN>
Date: Fri, 20 Jun 2025 13:03:10 +0900
Message-ID: <87qzzfjc01.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
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 Simon,

Simon Tournier <zimon.toutoune@HIDDEN> writes:

> Hi Maxim,
>
> On Wed, 18 Jun 2025 at 16:01, Maxim Cournoyer <maxim@HIDDEN> wrote:
>
>> I suppose it could be done by processing the nginx access logs.
>
> Do you think it would be possible to send them?  Offlist if
> required. :-)

You do not have access to berlin, right? These are often multi gigabyte
or worst in size.

-- 
Thanks,
Maxim

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Greg Hogan <code@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 20 Jun 2025 15:29:01 +0000
Resent-Message-ID: <handler.78332.B78332.17504333214107 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Andreas Enge <andreas@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Liam Hupfer <liam@HIDDEN>, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17504333214107
          (code B ref 78332); Fri, 20 Jun 2025 15:29:01 +0000
Received: (at 78332) by debbugs.gnu.org; 20 Jun 2025 15:28:41 +0000
Received: from localhost ([127.0.0.1]:53569 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uSdfU-000148-N5
	for submit <at> debbugs.gnu.org; Fri, 20 Jun 2025 11:28:41 -0400
Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]:51350)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <code@HIDDEN>)
 id 1uSdfR-00013O-6O
 for 78332 <at> debbugs.gnu.org; Fri, 20 Jun 2025 11:28:38 -0400
Received: by mail-oi1-x231.google.com with SMTP id
 5614622812f47-40791b696a2so521356b6e.2
 for <78332 <at> debbugs.gnu.org>; Fri, 20 Jun 2025 08:28:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=greghogan-com.20230601.gappssmtp.com; s=20230601; t=1750433311; x=1751038111;
 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=+QCYeEZYMG8d+5GLMy87zhJT1CsoWymFsZ3lamswy00=;
 b=S0rNaVmk6qCAxL9fs8dnCrB5M2t7NzJYSktaGSjP7qEGN8qXqhHz0yW/V0qX26ple0
 mA2w1hpH8y1XyoZcG8BUQfpwHeNBVaJE/WFCZbG81XbQ62cO04SV3Ji7hZyGi8SQYA2o
 6aHHIvweuym4uU71wy2mA/DFiMi4lXoG7IFTFu3clLtCG1H48WGKBm200d4v+TZQeWEZ
 ahrOh7T4+0w3yXnD87S4fmnsBkRxezFiwGzBo5xwLPOpHXxKZBiLvGo/XvkmS+txJ9cI
 pY4LpwFo3/g/8R8yFk915XIhRPGFAKJXbh+E+5aWrpAs5yy7acNvttCP0npnYwefXR5t
 dJ+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1750433311; x=1751038111;
 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=+QCYeEZYMG8d+5GLMy87zhJT1CsoWymFsZ3lamswy00=;
 b=DxELO3BxuGityHFm9ITVAcL+xcFM8TnnkvNgKhoS8NthU9r8gXK0CjS9iIlxGO8vrp
 ZE3w+WJYFEoPgAIM2l1F8q2d1FMlCFTldZVG9/PyhdIXxU1LgWfp38YeDTVMcNXI1Q/0
 RKBnCL1GfkZZB5UY+jB9B1HjwwHk48c4FPNlslxKYH8e4Ql47x8icrWUWTXthabpCdaL
 auDIXzqVpw6Vun/ip/UN/DT7ubT5XO5b2kwbxt7rD2RU3a2+Sp/CBvjpgSTG4HKPNlgC
 ZBaZB/u16+m5zwCEoWeQHxfr+yPupM1TCorI8El6fWQ4bN934gx1vForsvoccTyvY6M9
 CWwQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCVE5h+A4AzUSAJVDUcF5hPAf8Fis2nulQA0pBcRPH1uH/CheAbRdmmKRQChvuyu9Ewyply68g==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzR9Oxhc9I9aKg1J+a8/xO3vmlxvs52+ajT5tUC3JmxYam4x0j5
 HZWjn22uBtbutDHTdeHujv3gvodSN75sihbM8lX9w6ZWrZmIPzsCcYwxrSf/VvIWKF9NcUXjz5P
 4E5aL8JwJ5rh3OfohfMt6d1b8UMQCfKiAuuSolM8cLA==
X-Gm-Gg: ASbGnct4iBKLeCwcT0w7OoPqNVj5gZz7kXHbuyQIk9pNUwSd+lUWVihs2tABQDWaADA
 0qaOLMyqLYtQ4z83sTdnIFmzd+rutFFyVTyMcwwVFs79ulqTi9hWDCCtFA+Xj4BXbSpyVgx3HG/
 HgkHE8sqmFbrtjdjOQaGqzC83Y8XisZFa6/iAKUbLOoyqWAs3XaWhhxA==
X-Google-Smtp-Source: AGHT+IEReH+DgDOsF203aYDhIRiyX0hlHFlSNiz7Fw54ALUKe9hVosxv0LeD5ZWr/6AMrtsYuTjpYpKfHNR2mfWNfRE=
X-Received: by 2002:a05:6808:19a1:b0:406:6fd3:ff2a with SMTP id
 5614622812f47-40ac6e081fbmr2582280b6e.3.1750433311310; Fri, 20 Jun 2025
 08:28:31 -0700 (PDT)
MIME-Version: 1.0
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
 <r6f5xzc27hclbvb3xhaxaxmtya5ty2rled5eyv7kz65qywjncx@xvp4ke3mofl7>
 <aExuVXb_qmj6VJ2Y@jurong>
In-Reply-To: <aExuVXb_qmj6VJ2Y@jurong>
From: Greg Hogan <code@HIDDEN>
Date: Fri, 20 Jun 2025 11:28:19 -0400
X-Gm-Features: AX0GCFs9eVjqu2_tbx2dn_6unzHCKmGTUMUstU-zgC79CBIAUnfR-W1vWKJVjWg
Message-ID: <CA+3U0Zmb5XZz8fjvD6gnTuAvbOuwwE4tkPrqFBvqBO98=ofzug@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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, Jun 13, 2025 at 2:31=E2=80=AFPM Andreas Enge <andreas@HIDDEN> wrot=
e:
>
> Am Sat, Jun 07, 2025 at 01:03:10PM +0100 schrieb Steve George:
> > One way to consider that risk is to think about whether a GCD is irreve=
rsible (a one-day door). Trying 'regular releases' is not a one-way door. W=
e can try it out, and if it turns out that we can't manage it as a project =
we'll simply fall back to our current process of irregular releases.
>
> I think you put it very mildly; the real problem of our current process
> is that it apparently has turned into "no releases"... This for me is
> the most important motivation for this GCD, we need some momentum to
> turn around this inertia.

The GCD process is not designed for building momentum but rather for
agreeing on significant changes. From GCD 001:

"""The GCD process is a mechanism to determine whether a proposed
change is *significant* enough to require attention from the community
at large and if so, to provide a documented way to bring about broad
community discussion and to collectively decide on the proposal.

A change may be deemed *significant* when it could only be reverted at
a high cost or, for technical changes, when it has the potential to
disrupt user scripts and programs or user workflows."""

What from GCD 005 is significant by this definition?

Greg

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Andreas Enge <andreas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 20 Jun 2025 17:55:02 +0000
Resent-Message-ID: <handler.78332.B78332.175044204625050 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Greg Hogan <code@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Liam Hupfer <liam@HIDDEN>, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175044204625050
          (code B ref 78332); Fri, 20 Jun 2025 17:55:02 +0000
Received: (at 78332) by debbugs.gnu.org; 20 Jun 2025 17:54:06 +0000
Received: from localhost ([127.0.0.1]:55205 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uSfwC-0006Ve-Ar
	for submit <at> debbugs.gnu.org; Fri, 20 Jun 2025 13:54:06 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:44074)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <andreas@HIDDEN>) id 1uSfw9-0006Tu-RB
 for 78332 <at> debbugs.gnu.org; Fri, 20 Jun 2025 13:54:02 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 4A4F939B;
 Fri, 20 Jun 2025 19:53:54 +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 0xD3kIc17dmH; Fri, 20 Jun 2025 19:53:51 +0200 (CEST)
Received: from jurong (sauterelle.math.u-bordeaux1.fr [147.210.16.128])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id D1E9B43C;
 Fri, 20 Jun 2025 19:53:49 +0200 (CEST)
Date: Fri, 20 Jun 2025 19:53:48 +0200
From: Andreas Enge <andreas@HIDDEN>
Message-ID: <aFWgLELObuFhC9wi@jurong>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
 <r6f5xzc27hclbvb3xhaxaxmtya5ty2rled5eyv7kz65qywjncx@xvp4ke3mofl7>
 <aExuVXb_qmj6VJ2Y@jurong>
 <CA+3U0Zmb5XZz8fjvD6gnTuAvbOuwwE4tkPrqFBvqBO98=ofzug@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+3U0Zmb5XZz8fjvD6gnTuAvbOuwwE4tkPrqFBvqBO98=ofzug@HIDDEN>
X-Rspamd-Server: hera
X-Rspamd-Queue-Id: 4A4F939B
X-Spamd-Result: default: False [-5.59 / 15.00]; BAYES_HAM(-3.00)[99.99%];
 NEURAL_HAM(-2.99)[-0.998]; MID_RHS_NOT_FQDN(0.50)[];
 MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2];
 FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+];
 RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_ALL(0.00)[];
 RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[];
 FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]
X-Rspamd-Action: no action
X-Spamd-Bar: -----
X-Spam-Score: 0.0 (/)
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,

Am Fri, Jun 20, 2025 at 11:28:19AM -0400 schrieb Greg Hogan:
> > I think you put it very mildly; the real problem of our current process
> > is that it apparently has turned into "no releases"... This for me is
> > the most important motivation for this GCD, we need some momentum to
> > turn around this inertia.
> The GCD process is not designed for building momentum but rather for
> agreeing on significant changes. From GCD 001:

hm, I do not get your point. Of course it is not the *process* of
submitting this GCD that is supposed to generate momentum, but the
*result* of the GCD (in case it gets accepted) that should generate
momentum to reach releases.

> """The GCD process is a mechanism to determine whether a proposed
> change is *significant* enough to require attention from the community
> at large and if so, to provide a documented way to bring about broad
> community discussion and to collectively decide on the proposal.
> 
> A change may be deemed *significant* when it could only be reverted at
> a high cost or, for technical changes, when it has the potential to
> disrupt user scripts and programs or user workflows."""
> 
> What from GCD 005 is significant by this definition?

If I follow this definition in the second paragraph, then this GCD
proposal is not significant; it can be reverted at low to zero cost.

On the other hand, I think that putting into place a process for releases
is a significant change; and since there are several ways of getting to
a release, it is good to have a community discussion and to collectively
decide.

My conclusion would rather be that the definition of "significant
change" in GCD 001 is a bit too narrow. For instance, I would include
organisational change in the Guix project also as significant, even if
it could easily be reverted.

Do you have a different suggestion to end up with more regular releases?
Or do you think that regular releases are not desirable?

Andreas

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: "Philip McGrath" <philip@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 21 Jun 2025 01:00:05 +0000
Resent-Message-ID: <handler.78332.B78332.175046756225783 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>, "Steve George" <steve@HIDDEN>
Cc: Brian Cully <guix-devel@HIDDEN>, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175046756225783
          (code B ref 78332); Sat, 21 Jun 2025 01:00:05 +0000
Received: (at 78332) by debbugs.gnu.org; 21 Jun 2025 00:59:22 +0000
Received: from localhost ([127.0.0.1]:59227 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uSmZi-0006hD-AV
	for submit <at> debbugs.gnu.org; Fri, 20 Jun 2025 20:59:21 -0400
Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]:57917)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <philip@HIDDEN>)
 id 1uSmZf-0006fx-FH
 for 78332 <at> debbugs.gnu.org; Fri, 20 Jun 2025 20:59:16 -0400
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.stl.internal (Postfix) with ESMTP id B994311401A8;
 Fri, 20 Jun 2025 20:59:09 -0400 (EDT)
Received: from phl-imap-01 ([10.202.2.91])
 by phl-compute-03.internal (MEProxy); Fri, 20 Jun 2025 20:59:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 philipmcgrath.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:subject
 :subject:to:to; s=fm1; t=1750467549; x=1750553949; bh=deKYJXjbKQ
 Eg5pcrkyyYvosmBJFDVG2ZQh4OxN+M6j4=; b=cYXwTn4ftYLwx7f6hdI6b21c46
 NQQ0IPSXr+tJxCUImyW1AabBo5RR68vHCsaj88aWUu2alfSj8hLTwT91rSf4HhhP
 W03hwOVCAM2DsvRatgGaYiCCldMj5fU9bA9hrf5d0kNiQ/sAqhcw5LUMFsP30YCw
 H32PGr2uUtVdKL4pzE4gHiJB2PxzKOiyUmJvPpmCQMQXbHWBs/eVwQKO4Hy75CT8
 0Rw9vmoqcFn31qC9gnsadDOKCgsukewv3Syq2sZbh4IkDuHYeH9lpztosERMXNDa
 t1feKBHid2UjsanphulG8YzioF6dPf+jVnK5GO1Qrh2UBW0hW+b02RAPut7w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1750467549; x=
 1750553949; bh=deKYJXjbKQEg5pcrkyyYvosmBJFDVG2ZQh4OxN+M6j4=; b=L
 eXK3R/M09qo3g8Dudd/dV3c0uIeogQH9Y0y3OemETFfowlcigLlm81u0qHrf1c8c
 nY14Ov1oOzorIxqINR/EucJVOHgNn8WPTXYSgC+vMJEN64HNybhuNbCfThd8Wgi3
 DyN0eMPYayQ/ZC/VmWJ1cwS78OUmi6e/GEIKtIpqSq/fKJ8KvsWAbPVfz0dTqtyD
 W6Hc9942k5/weJtrokBcTlCRfMg+CKQjUcNiXc2aLqYBeNmXHN1nHEN4HTg1EoeW
 qryQB3F/AHU0v389GACZrA4a8RVHXARvmzSFFAKdL2WUI1ECCyWtLCvR+g1EGmEt
 9Lxi6IGSo+YMgFxp9CtLA==
X-ME-Sender: <xms:3QNWaNiiHjL1l9PlNVgMjVmeBp6Sf819Qgv841AIR3n85aMtQCnprA>
 <xme:3QNWaCCCb5TFOdhk0zRnbpQw_NYozd5KC9Sl8m8T2bOqjmHBoOeQfoPHgZVTwiv5d
 SgkjHpe_dES-1qKZo8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdelledtucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi
 lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh
 epofggfffhvfevkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpedfrfhhihhlihhp
 ucfotgfirhgrthhhfdcuoehphhhilhhiphesphhhihhlihhpmhgtghhrrghthhdrtghomh
 eqnecuggftrfgrthhtvghrnhephfdugfehtdeltdekuddvveffvdehtdefjedtkeetudeh
 fedvgefgvdfffefgudfgnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpghhnuhdroh
 hrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehp
 hhhilhhiphesphhhihhlihhpmhgtghhrrghthhdrtghomhdpnhgspghrtghpthhtohepge
 dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjeekfeefvdesuggvsggsuhhgshdr
 ghhnuhdrohhrghdprhgtphhtthhopehsthgvvhgvsehfuhhtuhhrihhlvgdrnhgvthdprh
 gtphhtthhopehguhhigidquggvvhgvlhesghhnuhdrohhrghdprhgtphhtthhopehluhgu
 ohesghhnuhdrohhrgh
X-ME-Proxy: <xmx:3QNWaNF_Qw8eYIGygOpc78B3AfMUddPoxlDIzNAP7Xj4dvWNWV4K3g>
 <xmx:3QNWaCSeInw6DUAB2bB1VBuxxZYABn2qWFzDRK-tNinvBjU3Bus6cA>
 <xmx:3QNWaKxxRTKaEFnS9VrsTdtwMABlW3Aof9yKfxq_-LgWpMkj-R3gfg>
 <xmx:3QNWaI6KKD-0VJiCJvrXDNxaT4sVt3-7O04Ys_e96ndUwPLlbeZp0w>
 <xmx:3QNWaAfnPZ60-d2DAiIfr_lavW0BGyZe0XfJzP6LekjQz6Yc-E_DfqPo>
Feedback-ID: i2b1146f3:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501)
 id 04C0F18C0063; Fri, 20 Jun 2025 20:59:09 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: T766667b5681f14b5
Date: Fri, 20 Jun 2025 20:58:11 -0400
From: "Philip McGrath" <philip@HIDDEN>
Message-Id: <6ca0e5f5-7b14-4f95-ab45-5a1b22cc6a16@HIDDEN>
In-Reply-To: <87sek6f117.fsf@HIDDEN>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87o6ux82e5.fsf@HIDDEN>
 <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
 <87sek6f117.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
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 Wed, Jun 11, 2025, at 4:58 PM, Ludovic Court=C3=A8s wrote:
>> I'm wondering if we should separate "Guix installed as a packge
>> manager" into it's own package set. In the long run this would be a
>> building lock that allow us to align with Philip's suggestion of
>> following a more Nix-packages / Nix OS separation of releases. What do
>> you think?
>
> The NixOS/Nixpkgs distinction doesn=E2=80=99t really exist anymore (it=
 used to
> be two separate repos but the two are necessarily tightly coupled), so
> I=E2=80=99m not sure what the suggestion is.
>

The distinction I was thinking about was between the `nix` daemon and co=
mmand-line tool, developed at https://github.com/NixOS/nix and last rele=
ased on May 22 as version 2.29.0, and the Nixpkgs/NixOS package definiti=
ons, developed at https://github.com/NixOS/nixpkgs and last released on =
May 23 as version 25.05. IIUC, `nix` itself has a release cadence indepe=
ndent of Nixpkgs/NixOS: e.g. the previous `nix` 2.28.0 release was on Ap=
ril 4, whereas the Nixpkgs/NixOS 24.11 release was back in November.

I think the https://github.com/NixOS/nix repository corresponds to the p=
arts of Nix or Guix needed to install on a foreign distribution, as refl=
ected in particular by the origin of Guix's nix@HIDDEN package.

On Mon, Jun 9, 2025, at 9:34 AM, Ludovic Court=C3=A8s wrote:
>> ## Release artifacts
>>=20
>> Using the primary architecture tier and the package sets would involv=
e creating
>> the following release artifacts:
>>=20
>> - GNU Guix System ISO image
>> - GNU Guix System QCOW2 image
>> - ["the Guix System installation user interface on the ISO"]
>
> This omits two important things:
>
>   =E2=80=A2 The binary tarball, used to install on top of another dist=
ro, for
>     all =E2=80=9Csupported architectures=E2=80=9D (Primary and Alterna=
tive).
>
>   =E2=80=A2 The source tarball, as produced by =E2=80=98make dist=E2=80=
=99 (target audience is
>     primarily downstream packagers, such as Debian).
>
> Reducing toil will be a matter of defining =E2=80=9Csupported architec=
tures=E2=80=9D in
> a reasonable way.

For the source and binary tarballs used to install on foreign distros an=
d for downstream packaging, the case for regular releases seems clear. W=
e expect that people may choose to upgrade the Guix daemon relatively ra=
rely, especially if they (like me!) are getting it from downstream  dist=
ro packaging. Ideally, the scope of this would be small enough that back=
porting important bug fixes and security updates would be feasible. (IIR=
C, the fix for CVE-2024-52867 was not backported onto Guix 1.4.0: the re=
commendation in the blog post was to use `guix pull` or wait for your di=
stro packager to do the cherry-pick the patches.) These are what I think=
 correspond to the https://github.com/NixOS/nix repository.

For the Guix System UI+ISO+QCOW2, I am less clear on the benefits of des=
ignated releases over rolling-release snapshots like those from <https:/=
/guix.gnu.org/en/download/latest/>. (It is very possible that this is be=
cause I don't know much about how the installer works. I only tried it o=
nce or so, as an experiment: other times I have installed Guix System by=
 first installing Guix on a foreign distro and then using `guix system r=
econfigure`.)

Nixpkgs/NixOS has both a rolling-release channel, nixos-unstable, and "s=
table channels" like nixos-25.5, which "get conservative bug fixes and p=
ackage upgrades" and "are generally maintained until the next stable bra=
nch is created". Guix does not currently have "stable channels", and I h=
aven't heard anyone proposing to change that at this juncture, so the on=
ly way to get bug fixes and security updates is to use `guix pull` regul=
arly.

AIUI, this makes a release like Guix System 1.4.0 notably different than=
 a release like NixOS 25.5. If you use a NixOS 25.5 installer, you not o=
nly do get version 25.5 of the installer itself, but also also default c=
onfiguration to use the nixos-25.5 channel, so you will continue to use =
the same major versions of packages that you initially install, with onl=
y "conservative bug fixes and package upgrades". With a Guix System 1.4.=
0 installer, on the other hand, as soon as you do `guix pull && sudo gui=
x system reconfigure /run/current-system/configuration.scm && sudo herd =
restart guix-daemon`=E2=80=94which you ought to do regularly=E2=80=94you=
r package versions update the same as if you had used a snapshot install=
er.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: pinoaffe <pinoaffe@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 21 Jun 2025 09:27:03 +0000
Resent-Message-ID: <handler.78332.B78332.175049799124792 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Andreas Enge <andreas@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Liam Hupfer <liam@HIDDEN>, Steve George <steve@HIDDEN>, Greg Hogan <code@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175049799124792
          (code B ref 78332); Sat, 21 Jun 2025 09:27:03 +0000
Received: (at 78332) by debbugs.gnu.org; 21 Jun 2025 09:26:31 +0000
Received: from localhost ([127.0.0.1]:33772 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uSuUZ-0006Rk-1B
	for submit <at> debbugs.gnu.org; Sat, 21 Jun 2025 05:26:31 -0400
Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:45160)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <pinoaffe@HIDDEN>)
 id 1uSuUW-0006QT-HG
 for 78332 <at> debbugs.gnu.org; Sat, 21 Jun 2025 05:26:29 -0400
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-607ea238c37so4982395a12.2
 for <78332 <at> debbugs.gnu.org>; Sat, 21 Jun 2025 02:26:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1750497982; x=1751102782; darn=debbugs.gnu.org;
 h=mime-version:message-id:date:user-agent:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=u6MDTBerkz2KMjU+8XAfZ0ue/7k7DePvAoLXkY7u5UE=;
 b=JGtG1t3RBUgD0K0Bh+YAfLmNlO4NNESoQSlRZgiQIZzP3dK8yQ3C4gFIlHhklXUucB
 2/IYLLS42t2PTqUjcIZbKCg0my0Ef3TSuKMylWG3jGJgGPckVWSmn1j5iDSyLshaSUqB
 Bxo0LsyNM07EbPH7XL9KPBbC/fPghAfgtbVmNdizRWAwBfqFci0U3lZxxif96OxRXtXq
 cK7eefuwtAeXe/oU1XpUrRPm0TvddqoZJQtXtXJY85rlRFWkotCV7KElxxn3+hPXokGx
 ZT8hCRXDEBVgKNF46WSXeK7luNY21x9RUoFe7u2qm0Uh7Szj2mrzm57GB5j73GKiS4xX
 zGSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1750497982; x=1751102782;
 h=mime-version:message-id:date:user-agent:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=u6MDTBerkz2KMjU+8XAfZ0ue/7k7DePvAoLXkY7u5UE=;
 b=ByYl7YPfoPDJB84jccNOum/F9FUn/yQimWJa65rm+ZZRyV4+f8u9FJ50RdTcSMt/eY
 afgKpEgIFauX4iJAY8PbxmPceYFq2G3/NYzPqs+7Osm/5y7oBfWQZj7VU1IUTyYUQrXf
 Sl7skD3pFueVnvPlkI66zAf6d2A5I8O4hvhkYQ0+9WKlVvwhjhrGmyz0H5rdteaAzRMQ
 FIXS0AHt7moSuB1GBRRmrNuNNK0MQrv62q3AaC6uSkKYIoI+PT2XbfImVbB5Qq9wfaw6
 WgHe6ePQqQH6wx/bn70GUh07cAxh1trLCtwGZYw+GVEvuUMIuQV2UDPmQhL033qXdmTV
 vU2g==
X-Forwarded-Encrypted: i=1;
 AJvYcCX4/7N91lNwAEz96e0LuRzZEkWwvmzR9UIug/s8GK724yFtFwGy0SUu4pUFXgd1iBbkNsUi4g==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yz5TQLliVh3KxWMMxJczHbvM4vJHBA00J2+hbF2lBSmZKT5hkys
 usvQATddPZpiGt7LGOzn4mqkslBh1n+9jbpwcg7RjyRsjyYyelH9UgwD
X-Gm-Gg: ASbGncsYl1dj5AR5QYrp+79V2JG1574nmVhi4nqRtqoreKrcPAqMTRAi5ru0vUMIquA
 rzP97V0wfG1OU63TphUP0PG3e+tSLT6PEAHN4dFkzx5zI8omR5PYn1+hZ/aHDSJL88x7LWi/k21
 Mm7GzEKIEuV1S7RlVnYgqmQF7rR7lY6GUJADU/AsD/GV/shwKD0fO9oBYiCAhVRMBsyHVueGfx+
 EpGLyaZ/q19gLpAy+0HYmovuKM1QNYFeWqJ/iQ+Bkge2d0DLc0TmD9NdlFa2laRC/2uv1Fa4HkQ
 cY1oOpsW5NJCZp9oJz+jff5GdktsULGHDex68FbVdfLXq6MtHnGeHtumZNpalQO/2nOsxHb+pYY
 atwuJ
X-Google-Smtp-Source: AGHT+IGQ8zdmvhtjjn2mZB08cX0qC5ks9tOu/4cqjgpgcE02a5Eu3sWl5a2QSsdKzizHRzL5KcJC/g==
X-Received: by 2002:a05:6402:254e:b0:607:ec18:9412 with SMTP id
 4fb4d7f45d1cf-60a1cccd5c4mr4780460a12.15.1750497982088; 
 Sat, 21 Jun 2025 02:26:22 -0700 (PDT)
Received: from localhost (h120217.upc-h.chello.nl. [62.194.120.217])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-60a1855374csm2777497a12.31.2025.06.21.02.26.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 21 Jun 2025 02:26:21 -0700 (PDT)
From: pinoaffe <pinoaffe@HIDDEN>
In-Reply-To: <aFWgLELObuFhC9wi@jurong> (Andreas Enge's message of "Fri, 20 Jun
 2025 19:53:48 +0200")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
 <r6f5xzc27hclbvb3xhaxaxmtya5ty2rled5eyv7kz65qywjncx@xvp4ke3mofl7>
 <aExuVXb_qmj6VJ2Y@jurong>
 <CA+3U0Zmb5XZz8fjvD6gnTuAvbOuwwE4tkPrqFBvqBO98=ofzug@HIDDEN>
 <aFWgLELObuFhC9wi@jurong>
User-Agent: mu4e 1.12.11; emacs 29.4
Date: Sat, 21 Jun 2025 11:26:21 +0200
Message-ID: <8734bt4f9e.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
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 (-)

Andreas Enge <andreas@HIDDEN> writes:
>> """The GCD process is a mechanism to determine whether a proposed
>> change is *significant* enough to require attention from the community
>> at large and if so, to provide a documented way to bring about broad
>> community discussion and to collectively decide on the proposal.
>> 
>> A change may be deemed *significant* when it could only be reverted at
>> a high cost or, for technical changes, when it has the potential to
>> disrupt user scripts and programs or user workflows."""
>> 
>> What from GCD 005 is significant by this definition?
> If I follow this definition in the second paragraph, then this GCD
> proposal is not significant; it can be reverted at low to zero cost.
>
> On the other hand, I think that putting into place a process for releases
> is a significant change; and since there are several ways of getting to
> a release, it is good to have a community discussion and to collectively
> decide.

I think defining a release process might be a significant change, but
establishing a release schedule when there is none at the moment does
not seem like a significant change, and in any case I don't think that
regular releases can be brought about by a GCD

kind regards,
pinoaffe

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: "Philip McGrath" <philip@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sat, 21 Jun 2025 15:51:03 +0000
Resent-Message-ID: <handler.78332.B78332.175052106214532 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: "Andreas Enge" <andreas@HIDDEN>, "Greg Hogan" <code@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Liam Hupfer <liam@HIDDEN>, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175052106214532
          (code B ref 78332); Sat, 21 Jun 2025 15:51:03 +0000
Received: (at 78332) by debbugs.gnu.org; 21 Jun 2025 15:51:02 +0000
Received: from localhost ([127.0.0.1]:42615 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uT0Uf-0003mF-EH
	for submit <at> debbugs.gnu.org; Sat, 21 Jun 2025 11:51:01 -0400
Received: from fout-a7-smtp.messagingengine.com ([103.168.172.150]:57959)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <philip@HIDDEN>)
 id 1uT0Uc-0003kv-L6
 for 78332 <at> debbugs.gnu.org; Sat, 21 Jun 2025 11:50:59 -0400
Received: from phl-compute-03.internal (phl-compute-03.phl.internal
 [10.202.2.43])
 by mailfout.phl.internal (Postfix) with ESMTP id 10715138040A;
 Sat, 21 Jun 2025 11:50:53 -0400 (EDT)
Received: from phl-imap-01 ([10.202.2.91])
 by phl-compute-03.internal (MEProxy); Sat, 21 Jun 2025 11:50:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 philipmcgrath.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:subject
 :subject:to:to; s=fm1; t=1750521053; x=1750607453; bh=BAtx7zKfWh
 94bDHkmAJkFOVQjMmcDYTCLOUlgft79fg=; b=QyeNZmy/uUaoA8E4WQ511Q1ays
 K0juCtq1oHaeKOKuFgDzmiqd2cr5wV/IOwYgfXZxQhi9GWATj93SdWR6+wBaZ0FZ
 N8PF7ldYgoceJBR1YHUi2L6h66zBiXqhprUGSx4Woafzb3sylpPU5K+DPHg9LHvH
 GuB+ydwqioBsq0v7mgkajABcjgURM6vouCTNqQ4v+n+b2eXXNSCcQqFRmfWIseBU
 xEe8rpW+I+mEgp4jVlJS/9DC5WouOVFzmksbG1exgrSiNGuSlSm6t0UkLC7rVb02
 7iwsQGiYLpmtk62n18SlcOHi2dUIAhkEinJlCi9ir338CgjS10ZsR9QfCSrw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1750521053; x=
 1750607453; bh=BAtx7zKfWh94bDHkmAJkFOVQjMmcDYTCLOUlgft79fg=; b=L
 GjxHgFWBTFUQJMGAjh7jxFDgZlLbIje5M3eUdGEkMTlUbe+gPjcZOJpn6lR1IOzh
 Mpa/Rz0SemTD+5g2yzrtvtrqkcAnPsbXEgWWrodA3WrEQk3SJWnxcB/q2XuZsCrC
 qpRQniT7HNE3jXZNEW75iggE42nKYMiuyuOvp4isnm3fqoDoAZFUQWghFNoiT4f1
 4YIlrxNsk5NBdCv6Xhf4Y/iptqvDBD0zNy3ee4jRQT+Zb0jlYW2KTOXY8QtscJ7w
 cR+UQYRMxXkKUUL0rBc4hoq8rSUpY1wyAK4ExICC2Ef5TvEtouJWXIezg5H82mwX
 4Gj3VvL8BLGZ7K5V2iUVA==
X-ME-Sender: <xms:3NRWaI_Y-1TSsnLttTbQroOFg3nOGiFZUOcJNTzT92z-N-ZZtIor9A>
 <xme:3NRWaAvLlWEsxKmMuV84xvJpeL-O2mxM8ROK271PAU1_udXcRnHHngqyzu6ciUsxo
 1PLsjrrrZ0IpslR8z8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgdduudeilecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
 ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug
 hrpefoggffhffvvefkjghfufgtgfesthejredtredttdenucfhrhhomhepfdfrhhhilhhi
 phcuofgtifhrrghthhdfuceophhhihhlihhpsehphhhilhhiphhmtghgrhgrthhhrdgtoh
 hmqeenucggtffrrghtthgvrhhnpeejfffgleffueehhfelvdduueejuddvfeduvdefkeei
 vddvuefhvdfhteelfedvieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh
 grihhlfhhrohhmpehphhhilhhiphesphhhihhlihhpmhgtghhrrghthhdrtghomhdpnhgs
 pghrtghpthhtohepiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjeekfeefvd
 esuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopegrnhgurhgvrghssegvnhhg
 vgdrfhhrpdhrtghpthhtohepshhtvghvvgesfhhuthhurhhilhgvrdhnvghtpdhrtghpth
 htohepghhuihigqdguvghvvghlsehgnhhurdhorhhgpdhrtghpthhtoheptghouggvsehg
 rhgvghhhohhgrghnrdgtohhmpdhrtghpthhtoheplhhirghmsehhphhfrhdrnhgvth
X-ME-Proxy: <xmx:3NRWaOCtt9Dffvi5lhgIB2HhBewHkM3opgWuct5m8hiLDnJWWbF_8w>
 <xmx:3NRWaIe0z7MWjmkXwiIu3sosRUVb3nAIUbfOnKEnrBC-y87Iy8dH_Q>
 <xmx:3NRWaNPrWOaSroIleoCrKW2xu_9Lcuc-T1Cw1Rcr4r4VEkfePE_Uyw>
 <xmx:3NRWaCmXJtlW-Sy2C9eo-bBLKzwEA-xcMBDk7fr9OxyDrS5NISp_aw>
 <xmx:3dRWaPMndl-QWJRUJg4PwpJ5pkcscz2EUbBfK1KzmZl8oI51yH4TCstC>
Feedback-ID: i2b1146f3:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501)
 id 4024F18C0063; Sat, 21 Jun 2025 11:50:52 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: T766667b5681f14b5
Date: Sat, 21 Jun 2025 11:50:05 -0400
From: "Philip McGrath" <philip@HIDDEN>
Message-Id: <17ac492a-e7c0-4901-be07-ab81490f2c8b@HIDDEN>
In-Reply-To: <aFWgLELObuFhC9wi@jurong>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
 <r6f5xzc27hclbvb3xhaxaxmtya5ty2rled5eyv7kz65qywjncx@xvp4ke3mofl7>
 <aExuVXb_qmj6VJ2Y@jurong>
 <CA+3U0Zmb5XZz8fjvD6gnTuAvbOuwwE4tkPrqFBvqBO98=ofzug@HIDDEN>
 <aFWgLELObuFhC9wi@jurong>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
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 Fri, Jun 20, 2025, at 1:53 PM, Andreas Enge wrote:
> Am Fri, Jun 20, 2025 at 11:28:19AM -0400 schrieb Greg Hogan:
>> """The GCD process is a mechanism to determine whether a proposed
>> change is *significant* enough to require attention from the community
>> at large and if so, to provide a documented way to bring about broad
>> community discussion and to collectively decide on the proposal.
>> 
>> A change may be deemed *significant* when it could only be reverted at
>> a high cost or, for technical changes, when it has the potential to
>> disrupt user scripts and programs or user workflows."""
>> 
>> What from GCD 005 is significant by this definition?
>
> If I follow this definition in the second paragraph, then this GCD
> proposal is not significant; it can be reverted at low to zero cost.
>
> On the other hand, I think that putting into place a process for releases
> is a significant change; and since there are several ways of getting to
> a release, it is good to have a community discussion and to collectively
> decide.
>
> My conclusion would rather be that the definition of "significant
> change" in GCD 001 is a bit too narrow. For instance, I would include
> organisational change in the Guix project also as significant, even if
> it could easily be reverted.
>

I read the second paragraph quoted from GCD 005 as a non-exhaustive list of factors that "may" make a change "significant", not as a definition restricting the meaning of "significant" to only the examples it describes.

The first paragraph says that "whether a proposed change is significant" is to be "determine[d]" by "the GCD process". To me, it seems fairly clear that the release model for Guix "require[s] attention from the community at large", so it seems fruitful to use "a documented way to bring about broad community discussion and to collectively decide on the proposal".

Maybe a difference from some other GCDs is the consequences if this does not achieve consensus. The current policy is basically "releases happen when someone feels like it's time and puts in the work to make one". I don't think there's anything in current policy that *forbids* interested volunteers from making annual releases along the lines of this proposal, even if GCD 005 does not achieve consensus. But hopefully we *can* achieve consensus on what Guix's release model should be, and, if so, it will be valuable to document that consensus.

Philip

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 22 Jun 2025 12:21:02 +0000
Resent-Message-ID: <handler.78332.B78332.175059484421832 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>,  Efraim Flashner <efraim@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Philip McGrath <philip@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175059484421832
          (code B ref 78332); Sun, 22 Jun 2025 12:21:02 +0000
Received: (at 78332) by debbugs.gnu.org; 22 Jun 2025 12:20:44 +0000
Received: from localhost ([127.0.0.1]:47275 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTJgg-0005fq-KH
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2025 08:20:44 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:58854)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uTJgc-0005eC-Au
 for 78332 <at> debbugs.gnu.org; Sun, 22 Jun 2025 08:20:41 -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 1uTJgV-005blG-Jz; Sun, 22 Jun 2025 14:20:31 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=futurile.net; s=selector2; h=In-Reply-To:Content-Transfer-Encoding:
 Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
 bh=oPvglIbCsnAGYYRa7HKtvdiP5ywcierRg8n0Ffr9OT8=; b=KsO4q+0TfcFoOPLhc93liBZE1M
 vQql97jDHMIBL2aNUShl2oRsehqoMaTMHBupR1lo9qVlAnDO8PcSm0X/eOhvTYi7mbwsTREqCeAID
 gLrUluLR/z4cXx50/kQjoSMHmsYrIUVCVJbSc1SwWHOM/ZOXqAMZ4QbGrltRuz6ywQo01Ud4fTg9W
 XgQiBYU2LV7cmmGP3ly1k68WoQW78AbDww2NqVdvOCaQDESA6XaAiybv2AeOVv32WfIiwTDcJkK8J
 R8ISvjoejAyHMfwlzt7ToaaHGhjAHyJ0r/bAq6tOOY5B1WnYpO39iza4VoBJQmYR1umMtIKuI5c4d
 hm30wDnA==;
Received: from [10.9.9.74] (helo=submission03.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uTJgU-0003BL-Pv; Sun, 22 Jun 2025 14:20:30 +0200
Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uTJgF-0043zB-36; Sun, 22 Jun 2025 14:20:15 +0200
Date: Sun, 22 Jun 2025 13:20:13 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <bdwefjskfci5ip2lwunassqrhkro7zlapts5edfaavl4q63jk4@7jthbcpztxce>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87o6ux82e5.fsf@HIDDEN>
 <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
 <aEmHfDluw6ZSCQ12@3900XT>
 <20250611204742.sS5NE1hOmWE8d5FLpYJ64FtIfSPhGs_daASWj54i9X4@z>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250611204742.sS5NE1hOmWE8d5FLpYJ64FtIfSPhGs_daASWj54i9X4@z>
X-Spam-Score: -0.7 (/)
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,

This part of the thread is about the definition of the current variables.

- Philip you're cc'd, but actually your point is a bit sub-thread.
- Efraim this is of interest to you, so added you back in.

On Wed, Jun 11, 2025 at 10:47:42PM +0200, Ludovic Courtès wrote:
> Hello,
> 
> Efraim Flashner <efraim@HIDDEN> writes:
> 
> >> >   • “Core” packages that anyone may wish to install on any of the
> >> >     architectures supported by Guix (not Guix System).
> >> > 
> >> >     This was ‘%base-packages’ in
> >> >     <https://codeberg.org/guix/guix/src/commit/12d00767f036029f1f5738de644d4972db374f4f/etc/manifests/release.s
> 
> [...]
> 
> > (define %base-packages
> >   ;; Packages that must be substitutable on all the platforms Guix supports.
> >   (map specification->package
> >        '("bootstrap-tarballs" "gcc-toolchain" "nss-certs"
> >          "openssh" "emacs" "vim" "python" "guile" "guix")))
> >
> > I realize that they are important packages, but they're all packages
> > that, if they broke, we would've noticed anyway (perhaps not
> > bootstrap-tarballs).
> 
> It’s not just about checking they’re not broken (you’re right we’d have
> noticed, at least on the popular architectures), it’s also about
> ensuring that substitutes are available for them.
> 
> That was the spirit of the ‘assert-binaries-available’ Makefile target.
> And that, in practice, often turned out to be difficult to achieve,
> especially for Arm.

-- >8 -- >8

* %system_packages: packages required to boot and install a minimal Guix System
  or install Guix on a foreign distribution.  This only includes default
  options **required** by the installer which **must** work for a release since
  they are part of the default installer path.  For example, this would include
  the guix daemon, kernels, boot loaders, file-systems and minimal utilities.
* %desktop_packages: additional desktop environments and other options from
  the installer. This includes packages that are part of the installer
  (but not default) and other popular options as chosen by the Release Team.
  Packages **should** work, but they may receive less QA attention from the
  Release Team than %system_packages.
* %base_packages: important packages that anyone may wish to install on Guix and
  consequently the project wants to maintain substitutes for. This may include
  important toolchains, runtimes and utilities. The Release Team **may**
  perform QA on these packages.

Guix would still make all packages and services part of a release (the entire
archive).  Guix teams would be asked to test the parts of the archive that they
look after. But, only Release Critical bugs in the `package sets` could block
a release.

The Release Team may identify other package sets as needed.

-- >8 -- >8

Is that better?

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 22 Jun 2025 12:37:04 +0000
Resent-Message-ID: <handler.78332.B78332.175059578331802 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Philip McGrath <philip@HIDDEN>
Cc: Brian Cully <guix-devel@HIDDEN>, 78332 <at> debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175059578331802
          (code B ref 78332); Sun, 22 Jun 2025 12:37:04 +0000
Received: (at 78332) by debbugs.gnu.org; 22 Jun 2025 12:36:23 +0000
Received: from localhost ([127.0.0.1]:47334 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTJvo-0008Ga-ND
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2025 08:36:22 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:56310)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uTJvm-0008FI-1P
 for 78332 <at> debbugs.gnu.org; Sun, 22 Jun 2025 08:36:18 -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 1uTJve-005Gib-OP; Sun, 22 Jun 2025 14:36:10 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=futurile.net; s=selector2; h=In-Reply-To:Content-Transfer-Encoding:
 Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
 bh=ztkEpnssjRWHEKokcWIM2THbOmmvOc9ZvUtDUpUOgsI=; b=UkozD60F2Fp39MAEBRGIVS6vcz
 jc9WNTr2bQDsAbyJDv3ma7kGnfJm+gegQBYIkaFjYVMnFxPjxKzdX4dD0cu35qi+Xkgu65PERA+Pt
 3GcxBq+F3pNWxCicaW+9APnGl2v4hzL6f00UcfMwCt9zTZitdWo0hw39lV0shODPaZCfounGUM9PP
 z9j8dqxcur2xGpijcNQZR6volvmQ2iuW7VhwCydg+Q4/PNzYTdWvFWi9oZtolCyClqnmBu1OiRN1e
 dCNQagAgcr/5fyLEOS2OHWcHTdKwMP2QU3vuGPTOyOHvHMFqIz8OCLLcSikezjKjn5dL/45JC/POU
 bt5gAg0Q==;
Received: from [10.9.9.74] (helo=submission03.runbox)
 by mailtransmit02.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uTJve-0000wC-8P; Sun, 22 Jun 2025 14:36:10 +0200
Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uTJvW-004886-O5; Sun, 22 Jun 2025 14:36:02 +0200
Date: Sun, 22 Jun 2025 13:36:00 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <nsm5mf4i53r4ndsptiysc4z543qipx2udjolqf2be44naml3z2@uuu4xwp5dosb>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87o6ux82e5.fsf@HIDDEN>
 <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
 <87sek6f117.fsf@HIDDEN>
 <6ca0e5f5-7b14-4f95-ab45-5a1b22cc6a16@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6ca0e5f5-7b14-4f95-ab45-5a1b22cc6a16@HIDDEN>
X-Spam-Score: -0.7 (/)
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,

On Fri, Jun 20, 2025 at 08:58:11PM -0400, Philip McGrath wrote:
> On Wed, Jun 11, 2025, at 4:58 PM, Ludovic Courtès wrote:
> >> I'm wondering if we should separate "Guix installed as a packge
> >> manager" into it's own package set. In the long run this would be a
> >> building lock that allow us to align with Philip's suggestion of
> >> following a more Nix-packages / Nix OS separation of releases. What do
> >> you think?
> >
> > The NixOS/Nixpkgs distinction doesn’t really exist anymore (it used to
> > be two separate repos but the two are necessarily tightly coupled), so
> > I’m not sure what the suggestion is.
> >
> 
> The distinction I was thinking about was between the `nix` daemon and command-line tool, developed at https://github.com/NixOS/nix and last released on May 22 as version 2.29.0, and the Nixpkgs/NixOS package definitions, developed at https://github.com/NixOS/nixpkgs and last released on May 23 as version 25.05. IIUC, `nix` itself has a release cadence independent of Nixpkgs/NixOS: e.g. the previous `nix` 2.28.0 release was on April 4, whereas the Nixpkgs/NixOS 24.11 release was back in November.
> 
> I think the https://github.com/NixOS/nix repository corresponds to the parts of Nix or Guix needed to install on a foreign distribution, as reflected in particular by the origin of Guix's nix@HIDDEN package.
(...)

AIUI some/many distributions will only package 'releases', so it would mean doing a release of the parts of Guix that are used in the binary installer. I don't know enough to know if this is achievable for Guix - Philip if you would like to work on a follow-up GCD proposing it I would be happy to partner with you on it.

For now, I've added the following in the section about possible future improvements:

-- >8 -- >8 --


There are various improvements that could be made to the release strategy over
time, such as:

1. Create separate releases of the Guix source necessary for installing Guix
   on a foreign distribution. This would mean that downstream Linux
   distributions that package Guix could have new release more often.
1. Adding an additional slower release cadence. This could be either a security
   and critical fixes branch strategy, such as implemented by Nix. Or it could
   be a slightly slower moving branch, such as implemented by SUSE SlowRoll.


-- >8 -- >8 --


> On Mon, Jun 9, 2025, at 9:34 AM, Ludovic Courtès wrote:
> >> ## 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
> >> - ["the Guix System installation user interface on the ISO"]
> >
> > This omits two important things:
> >
> >   • The binary tarball, used to install on top of another distro, for
> >     all “supported architectures” (Primary and Alternative).
> >
> >   • The source tarball, as produced by ‘make dist’ (target audience is
> >     primarily downstream packagers, such as Debian).
> >
> > Reducing toil will be a matter of defining “supported architectures” in
> > a reasonable way.
> 
> For the source and binary tarballs used to install on foreign distros and for downstream packaging, the case for regular releases seems clear. We expect that people may choose to upgrade the Guix daemon relatively rarely, especially if they (like me!) are getting it from downstream  distro packaging. Ideally, the scope of this would be small enough that backporting important bug fixes and security updates would be feasible. (IIRC, the fix for CVE-2024-52867 was not backported onto Guix 1.4.0: the recommendation in the blog post was to use `guix pull` or wait for your distro packager to do the cherry-pick the patches.) These are what I think correspond to the https://github.com/NixOS/nix repository.
> 
> For the Guix System UI+ISO+QCOW2, I am less clear on the benefits of designated releases over rolling-release snapshots like those from <https://guix.gnu.org/en/download/latest/>. (It is very possible that this is because I don't know much about how the installer works. I only tried it once or so, as an experiment: other times I have installed Guix System by first installing Guix on a foreign distro and then using `guix system reconfigure`.)
> 
> Nixpkgs/NixOS has both a rolling-release channel, nixos-unstable, and "stable channels" like nixos-25.5, which "get conservative bug fixes and package upgrades" and "are generally maintained until the next stable branch is created". Guix does not currently have "stable channels", and I haven't heard anyone proposing to change that at this juncture, so the only way to get bug fixes and security updates is to use `guix pull` regularly.
> 
> AIUI, this makes a release like Guix System 1.4.0 notably different than a release like NixOS 25.5. If you use a NixOS 25.5 installer, you not only do get version 25.5 of the installer itself, but also also default configuration to use the nixos-25.5 channel, so you will continue to use the same major versions of packages that you initially install, with only "conservative bug fixes and package upgrades". With a Guix System 1.4.0 installer, on the other hand, as soon as you do `guix pull && sudo guix system reconfigure /run/current-system/configuration.scm && sudo herd restart guix-daemon`—which you ought to do regularly—your package versions update the same as if you had used a snapshot installer.
> 
(...)

I personally would love Guix to have a "stable" channel (as noted in the improvements section). But, after discussion with the GCD's sponsors I removed it because it was felt that this was too big a step - consequently the GCD was descoped to focus on "annual releases" and then other improvements can come later.

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 22 Jun 2025 15:05:02 +0000
Resent-Message-ID: <handler.78332.B78332.175060468525352 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Olivier Rojon <o.rojon@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175060468525352
          (code B ref 78332); Sun, 22 Jun 2025 15:05:02 +0000
Received: (at 78332) by debbugs.gnu.org; 22 Jun 2025 15:04:45 +0000
Received: from localhost ([127.0.0.1]:49273 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTMFP-0006aa-0j
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2025 11:04:44 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:44676)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uTMFL-0006Ys-58
 for 78332 <at> debbugs.gnu.org; Sun, 22 Jun 2025 11:04:41 -0400
Received: from mailtransmit03.runbox ([10.9.9.163] 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 1uTMFD-005YTc-M0; Sun, 22 Jun 2025 17:04:31 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=futurile.net; s=selector2; h=In-Reply-To:Content-Type:MIME-Version:
 References:Message-ID:Subject:Cc:To:From:Date;
 bh=t9uMnfam28tuPOgv6XixtHQ2EToNFOHbyEO1R8zmQyg=; b=CwttU2WO3xKLtDNQfSv+cgsZ1J
 zml/Makl8JX6bImkm5SCI3u9n5Q+ThceTccePyuL2kHEwgDuMoBPvB9u9cugkYyT8qd8ywcURtEr5
 JTHhl6FuB4JEwo9NaZb0NHLnm3q74j35JLr6VMvkvl+9meBA7XTjAeSfJeT4HooLD//1dJ8oAGO1S
 2jWXeF4Y3Dd4A6QdGv4FiWta0i33Ba19z2g7brrc7+CgSf7mUd6SphJ2twySpBcdL8jMqtMtBV8sc
 HRuVHRgyFKACWPZtUTw2tHvt+W8kzgVD/Anoou5XLIU4MgLqlXfwNyLK9/UoiHzimfFN4b3Z0ZdFe
 aUXSWxXA==;
Received: from [10.9.9.74] (helo=submission03.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uTMFC-00079o-UP; Sun, 22 Jun 2025 17:04:31 +0200
Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uTMF2-004mWZ-KI; Sun, 22 Jun 2025 17:04:20 +0200
Date: Sun, 22 Jun 2025 16:04:18 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <nzgbquu273awonarjqbhmbukhh5mkextwdrucpbspbus4b5e4g@npx5tjpk2ftl>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <20250618045242.g_mCroqVtI1DeK5-FsM-ZmuDLzKyON6X2B7ShaJAOKI@z>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20250618045242.g_mCroqVtI1DeK5-FsM-ZmuDLzKyON6X2B7ShaJAOKI@z>
X-Spam-Score: -0.7 (/)
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 Olivier,

On Wed, Jun 18, 2025 at 04:52:42AM +0000, Olivier Rojon wrote:
> Hi Steve, hi everyone,
> 
> first things first, thank you so much for your efforts for the Guix project.  Your awesome
> newbie-friendly blog posts, the Guix User and Contributor Survey, this GCD - thanks!
(...)

You're welcome :-)

> I have some comments to make (see below), but from my point of view, none of them HAVE to
> lead to changes in the GCD, because especially considering the proposed iterative nature
> of the process, many things will turn up during the first (or second, or third, ...)
> iteration that will lead to changes.  Overall, I think that this GCD proposes a
> much-needed structure to a frighteningly complex process that too often is stemmed by too
> few people.  I think most of its parts are actionable as is, and I really appreciate that
> you took so much time to investigate how other distributions do it and that you spelt out
> a road map that the release team can use to guide their actions.  I am certain that I
> would be lost without such guidance, and I do appreciate that leeway for unpopular "behind
> the scenes" work such as ungrafting is taken into consideration.
> 
>

Thanks for going through it in detail and both the wider thoughts and specific points really help.

> Package Sets
> ============
> I have to admit to a certain brain tangle when it comes to this topic and I read many
> contributions to the discussion to go towards this direction.  If I understood the
> discussion correctly, the first release process is likely to feature Guix veterans.
> Wouldn't it be possible to deliberately underspecify which package sets (how many) are
> present and what their contents are?  This could take two different forms: one would say
> that the release team can decide what to feature provided they test it according to the
> outlined criteria (for all architectures etc), the other would say that the first release
> team (comprised of veterans) lays the ground work and future release teams might have some
> wiggle room.
(...) 

Thanks for going through it. Overall, I think you're right and actually I should not have tried to "specify" them. 

I agree that what's going to happen is that each successive Release Team has to figure out what should be "added" (if anything), but you can't really remove too much stuff because users come to rely on things. I've just tried to realign the whole section on the basis of the current system, and to clearly word the intent - which is all about the focus of QA/manual testing.


> release cycle start in $SPRING
> ==============================
> for me personally the Guix Days were a catalyst and were motivating me to get involved
> more concretely in the project than beforehand.  Maybe the end of Guix Days/FOSDEM could
> be mentioned as a concrete starting point because then, a possible release team has
> (possibly) had time to coordinate in person what awaits them in the following weeks.  And
> if it hadn't had time, (possible) members of the release team have had ample opportunity
> to charge their social and geek batteries and might be willing and able to release it ;-)

That's a great idea, and in fact we did discuss at Guix Days so it makes sense.

I'm feel the GCD is too long already, but I think you're absolutely right about this - I've changed the Appendix 1 flow.

> iterative process improvements/Release Cheat Sheet
> ==================================================
> I think it is a very important step in the iterative process of release management that
> lessons learnt make future iterations easier.  The discussion has often times mentioned
> automation, the GCD mentions the "communication afterwards, possibly with a blog post".
> My supplementary idea is to write up a kind of "TODO List" or a "Release Cheat Sheet" (or
> whatever you want to call it) that mentions either (a) all the steps required from start
> to finish (that's what helps me with complex tasks where I need to be vigilant with each
> step so I don't want to think about the overall structure, or (b) the typical GOTCHAS,
> things that you forgot that really came back to bite you. 

Yes agreed, we'll get better if we "do" releases more often, and "document" what we learn.

The Appendix 1 plan says that each Release Team will do a Release Retrospective which is supposed to capture how to improve the overall release process. 

Specifically for documentation I had in mind the Ubuntu or NixOS release wiki docs https://nixos.github.io/release-wiki/Home.html.

We already have some as a starting points - https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org
 
I think your (a) is basically covered in a detailed version of the Appendix 1 plan, and then (b) is going to be added to the release documentation over time (as we discover those gotchas!) 


> motivation for release: sync codebase and documentation
> =======================================================
> I don't know if that has already been mentioned, but another reason why a release can be
> good is to have a kind of synchronisation between what the distro can do and what is
> documented (where).  The current state of affairs is to make sure to always use the devel
> version of the manual which I think is a terrible way to introduce newbies, while the 1.4
> version -- the "correct" manual for the installer you download and install -- features
> quite some dead links etc. while being so out of date in places that we might as well --
> I'm exaggerating to make a point -- replace it with a fantasy novel.
> 

Agreed, I think we see this a lot on IRC - users read the wrong version and are confused!

The GCD reflects this at the start:

1. New installations of Guix will be better because installation media and
   manuals will be up to date.

It's right at the start, but you didn't internalise it - should it be drawn out more? (bearing in mind I'm also fearing the length at this point!)


> META: structure of the document
> ===============================
> Would it make sense to make the sections "Package Sets", "Plattforms and Architecture tiers", "Release artifacts" and "Release team and project" top level headings?  The way I read it they appear as aspects of the whole GCD while not standing in a content dependency relation to the "Motivation" section.
> 

Yeah OK, everything you say makes sense in this bit.

As the documents becoming far too long ... I've added more words!!!

I've added a "conclusion" at the start to show what three of these things are about (reducing scope) and then made those three things (package sets, architectures and release artifacts) sub-sections. I've moved Release team up a level as well.


> The same applies to the Appendix section, where I'd argue that when the Appendix is a
> top-level heading and the explanation of the different "Events" are its direct children,
> it would make sense to have their explanation on level 2 and not level 3.
(...)

Thank-you, fixed.


> @text: Package Set Finalisation
> =========================
> I don't understand the following sentence:
> 
> > Packages that do not build for the primary architectures so could be risk of removal
> > will be identified and developers will be notified following the Deprecation Policy.
> 
> The sentence would be fine without the part "so could be risk of removal".  This part of
> the sentence (to me) alludes to another aspect -- "risk of removal" -- that remains
> underspecified and thus causes confusion.  Unless it is a mistake, I think it would be a
> good idea to rephrase to make the two aspects "deprecation of packages that don't build on
> the primary architecture" and "risk of removal" clearer.
(...)

It's my understanding that the topic of package removal has caused lots of discussion previously. There's already a Deprecation Policy in place which specifically covers both the circumstances and timing of removal. I didn't want to cover that ground again, as I don't want to relitigate it! So I've said that the Release Team can make some decisions early and then there's time for a big discussion and decisions. Consequently, I'm being diplomatic here and it's intentional :-)


> @text: Toolchain and transition freeze
> ======================================
> Maybe a criterion such as with package updates could be used here, like "if a change in
> package X incurs change in Y (say, 50) other packages, it needs to be treated specially".
> 
(...)

Yeah, I personally don't think I can clarify it. It would need someone with more direct release experience. 

Thanks so much!

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 22 Jun 2025 16:14:04 +0000
Resent-Message-ID: <handler.78332.B78332.17506088426369 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Simon Tournier <zimon.toutoune@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17506088426369
          (code B ref 78332); Sun, 22 Jun 2025 16:14:04 +0000
Received: (at 78332) by debbugs.gnu.org; 22 Jun 2025 16:14:02 +0000
Received: from localhost ([127.0.0.1]:49567 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTNKS-0001eO-RK
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2025 12:14:02 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:35266)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uTNKN-0001cq-MF
 for 78332 <at> debbugs.gnu.org; Sun, 22 Jun 2025 12:13:59 -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 1uTNKG-00642X-4r; Sun, 22 Jun 2025 18:13:48 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=futurile.net; s=selector2; h=In-Reply-To:Content-Transfer-Encoding:
 Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date;
 bh=QqTN362vJTfu1vxd4XGLoXh64THtFw0xaiI5JF77/Sc=; b=ELRuVnmD98tByscFQYemxR342g
 u+1n1i55gR7I/+0t11/7J66AAC2NCZcFDn7figQ5PxebmLRXg7sG6gVIRVzfI2IzPyK86LQEee/3n
 yL5TTvKrS2PjVBPsW7gw6x2uUmLUAXcxJbsNZUEd4lvb/qH6ITf3Fi4uKYsjg+6LWrBt19PLOhBSR
 sqJ3j8k4JlgkcQV+nDcUCvoknp/WGi0SKLCSKrPgYoX4wXXOuw1j/8tSS3VMAvXiRk9P4MPSRL/Lu
 G6Cr6tY5McFe+LuQvmPF6jvvb9pgppD7yUlNgGq/EUtFMxHB38R29orHPwX/hrEOuQFFIqHffdPkb
 Xoz/MF+Q==;
Received: from [10.9.9.72] (helo=submission01.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uTNKF-00042I-Hp; Sun, 22 Jun 2025 18:13:47 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uTNK5-002n42-97; Sun, 22 Jun 2025 18:13:37 +0200
Date: Sun, 22 Jun 2025 17:13:35 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <ppytsxzumcybromgvkyqgppwthabry2cap5r6cbs4hxlfdol6h@6l6rnux3gyjw>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87y0tw22wp.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87y0tw22wp.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Thu, Jun 12, 2025 at 09:08:54PM +0200, Simon Tournier wrote:
> Hi Steve,
> 
> Thanks for this proposal!
> 
> Well, I’ve not commented yet because I’m very doubtful that releasing
> more often can be solved with a GCD.  I mean, yeah we all would like
> more releases, and then?  :-)  Look, on February, we were all in the
> same room and we all agreed that we had to work on releasing soon and
> we cooked a plan to make it happen.  But the release has not come yet…

Understood.

You're not the only person in the group that thinks a GCD won't solve this.


> Do not take me wrong.  I do not want to be the pessimistic one cutting
> the positive circle trying to move forward.  As I wrote many times over
> the years, yeah for sure, releasing more often would be more than great!
> 
> Somehow, I think that “regular and efficient release“ is a good target
> but considering the current situation, I’m doubtful we will be able to
> go in only one go – just by deciding from the top and writing down a
> planning.
> 
> Instead, I think we need two intermediary steps:
> 
>  (1) Clarify what means being a member of a team.

I'd be happy to collaborate on something in this area. I genuinely don't really know what the responsibilities and accountabilities can be in this sort of set-up.


>  (2) Clarify the branching model; especially how to deal with grafts.
> 

I don't really understand this area enough to comment.


> To me, they are requirements before being able to have regular releases.
> 
> Therefore, I read this GCD as setting the goal in order to address the
> well known blockers as (1+2) and, only after, we will be able to have
> regular releases without burning out.
> 
> Moreover, I think it’s difficult to find the right balance between
> volunteering work and commitments.  Today, make a release is a piece of
> work.  For sure, it’s possible to smooth the things and automatize with
> various helpers etc. but if it’s not done yet, maybe it’s because it’s
> not trivial or maybe even more work than the ‘piece of work’ itself. :-)
(...)

Agreed, the difficulty of being a 'volunteer' project means we can't guarantee anything.

I hope this GCD at least (a) shows our goal/intent (b) provides some concrete ways to make 'doing the work' easier.


> Yes, I’m convinced that committing to have “regular releases” will
> improve all the releasing process over the next releases.  For sure!
> And it’s probably by making such commitment that the releasing process
> will be improved.  But we are not there yet, IMHO, so it’s still a piece
> of work and it’ll still remain one for some release cycles.
> 
> Therefore, the core of this proposal appears to me what is the bar?
> 
> Until now, the bar was high.  Maybe, one way to release more often is to
> decrease the bar so it’s easier to pass it and then we can rise it up,
> by incremental improvements.  This is the section about Package Sets,
> Tiers and Release Artifacts.
(...)

Agreed. Hopefully, adding clarity makes it easier for someone to join a Release Team and work on the release. 


> To me, that’s the key.
> 
> And concretely, who is ready to commit for 12 weeks (maybe 2 times) as
> Release Manager?
(...)

Efraim has agreed to be the first Release Manager.


> All that said, some comments hoping it might improve the bootstrap of
> “regular releases”. :-)
> 
> 
> > ## Package Sets
> 
> [...]
> 
> > 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.
> 
> I understand the meaning however it’s unclear to me.  Instead, I propose
> that the Release Team defines when they start their cycle which packages
> the release will support.
> 
> Somehow, each package set should be defined by a manifest file.  Here
> you picked 5 use-cases, so the Release Team lists the packages in the
> manifests minimal.scm, standard.scm, desktop.scm, server.scm and
> hosted.scm.  These manifests are considered as blockers.
> 
> If one package from one manifest fails and it’s hard to fix, then it can
> be excluded; i.e., moved from Tier to another Tier.
> 
> It also would help in monitoring the CI outside the release period.
(...)

I think they're a good idea, but I've managed to confuse the issue due to my own assumptions coming from my previous experiences. I've reworked the package sets to reflect what the current state of play is (Ludo and Efraim input on what is the current state)

I've also made the bar lower for testing by a Release Team, as there was a lot of feedback about it being too much.


>
> > ## Platforms and Architecture 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
> 
> This does not read as the rolling release, does it? :-)
> 
> I propose:
> 
>         - Tier 1:
>           - Architectures: x86_64, AArch64
>           - Kernel: Linux
>           - Coverage: defined by package sets.
> 
>         - Tier 2:
>           - Architectures: all others
>           - Kernel: Linux
>           - Coverage: defined by package sets.
> 
>         - Tier 3:
>           - Architectures: all
>           - Kernel: Linux, Hurd
>           - Coverage: all packages
> 
> For a release, Tier 1 must be all green; Tier 2 should be green; Tier 3
> as good as possible.
> 
> Obviously, we can add more Tier than only 3.  The main idea here is to
> define what is Tier (= list of architectures, kernel, package coverage)
> and what expects when this Tier in a release.
> 
> Well, maybe we could add a “service coverage”.
(...)

Yeah interesting, so my definition is specifying the circumstances under which something can be considerd a "Primary Architecture". It's basically trying to define how you would decide if something should be promoted. I think the reason I have it from this perspective is because if something is promoted, then it can prevent a release if any of the criteria fail. For example, if a package in a package set didn't build for a primary architecture, this would be an RC bug.

I've removed the 'Security' line from my definition, as I don't think it's useful being there given what's practically happening.

See if you think I've landed up where you are, but through slightly different words. I added a section to tie everything togehter:

-- >8 -- >8 -- 

1. Packages and services within the `package sets` must build on the `primary
   architectures`. Other packages are optional for a release.
2. Release artifacts are only made from packages within the `package sets` and
   on the `primary architectures`. Other architectures or release artifacts are
   optional for a release.
3. Testing and QA is on `package sets` on the `primary architectures` only.  The
   Release Team has flexibility to choose their response to bugs and issues.

-- >8 -- >8 -- >8


> > ## Release team and project
> 
> [...]
> 
> > 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
> 
> Hum, 2 times 12 weeks of commitment?  That’s something! :-)
> 
> For sure, back up the Release Manager with 2 people is a very good idea;
> especially about knowledge transfer.  Cool!
> 
> If the primary Release Manager is not able to keep the commitment (busy
> by life, away from keyboard, unexpected event, etc.), then the secondary
> Release Manager takes the floor.  Right?  But then, this “absent”
> primary Release Manager, does they become the next secondary Release
> Manager?
(...)

I guess in most circumstances people will say that they can't continue the commitment, rather than simply disappear. At that point the whole Release Team can discuss and hopefully someone can volunteer to step up, and the secondary one can take over. 


> Moreover, what does it happen if the both Release Manager are not
> responding?  Do we delay the time to find two new Release Managers?  Or
> is it two of the other members?
(...)

That's very much going to depend on the circumstance. At the moment my perception is that there's only a couple of people with the requisite knowledge who can drive a release. If everyone disappears then yeah we're in trouble!

Hopefully, over time - with more release experience and documentation - it would be easier for the group to recover and pick up the slack.

> The other question: what does it happen if the Release Team is not able
> to fix a blocker?  Do we delay until the fix?  Do we drop the blocker?
> Who decides?  What is the process for making such decision?
(...)

This one falls into the dificulty of a Release Team not being able to rely on individual experts in Teams (because they are volunteers). So, if the Release Team isn't an expert in something but it's on the critical path for a release (e.g. the installer doesn't work), then they have to either figure out a workaround or delay the release.

There's not the concept of a "landing zone" in the release plan template - it says if they can't do a release after three attempts then they should probably stop, but that it is ultimately up to them.


> > # 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.
> 
> Well, I do not have the answer and my honest question is: Is it more
> detrimental to have irregular^W no release since years! than to
> communicate on regular releases and fail?
(...)

We are all volunteers doing something because it's interesting and fun. We should encourage everyone to trying new things, who knows - maybe we will achieve something!

If some of those things don't happen, then we just brush it off and try something else. The alternative is to be stuck and there's no possibility of change or learning at that point.

I don't really see how anyone can criticise us for trying things.


> > # Appendix 1: Release Project Time-line
> 
> [...]
> 
> > ### 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.
> 
> Who nominates?  How?
> 
> Who decides if 7 people volunteer to be the next release team?  Hum, it
> will not happen, but still. :-)
> 
> The converse, what does it happen if no one volunteer?  IIUC, the
> primary Release Manager becomes the next secondary Release Manager, so
> what does it happen if there is no one who volunteers to be the next
> primary volunteer?
> 
> What does it happen if after the release, the primary Release Manager
> steps down and do not become the next secondary Release Manager?
(...)

In all these circumstances either someone steps up and give it a go, or they don't and we fall back to irregular releases. I don't think there's any way for me to give you the certainty you want here. 


(...)
> > ### 9. Ungraft master branch
> > Guix master is ungrafted to minimise the difference with users of the release
> > initial 'guix pull' experience.
> 
> This will take more than one week, I guess. :-)  For sure, more than few
> hours in the week.
> 
> I think this needs to be done by each team all over the changes
> independently of the release process.  As said above, I think we should
> clarify what a team does.  For instance, if a team introduces a graft,
> then this very same team must open a branch that ungrafts and then merge
> this branch as soon as possible; independently of the release.
> 
> Somehow, we removed core-updates but we have never defined a clear
> strategy for ungrafting.  Well, that’s outside the scope of this GCD
> but, IMHO, the success of this GCD depends on how to deal with grafts.
(...)

OK, have to admit a massive shortcoming for me is I have not taken part in any ungrafts so I don't really understand the overall difficulty since I haven't done it!

Thanks for all the details and time to comment!

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 22 Jun 2025 16:17:02 +0000
Resent-Message-ID: <handler.78332.B78332.17506089637947 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Leo Famulari <leo@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, zimoun <zimon.toutoune@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17506089637947
          (code B ref 78332); Sun, 22 Jun 2025 16:17:02 +0000
Received: (at 78332) by debbugs.gnu.org; 22 Jun 2025 16:16:03 +0000
Received: from localhost ([127.0.0.1]:49576 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTNMP-00023o-Do
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2025 12:16:02 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:43420)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uTNMM-00022K-Hx
 for 78332 <at> debbugs.gnu.org; Sun, 22 Jun 2025 12:15:59 -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 1uTNMF-0064Jh-Uc
 for 78332 <at> debbugs.gnu.org; Sun, 22 Jun 2025 18:15:51 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=futurile.net; s=selector2; h=In-Reply-To:Content-Type:MIME-Version:
 References:Message-ID:Subject:Cc:To:From:Date;
 bh=EBaC9qJfVazqIgWXUUQ/poQEWWKp+f/1JJN2tTq2Lsg=; b=MX30gWwhw1jceUHxUIFE+ZYG60
 +si75AJTfA9/VToxM/DAAvU4/YJFLjvQhObFlbqBYNQ9R96vJNA3Zm+wdyjLdb3b8G295labexq1C
 u8nMqPAtLQJmqDe6/S1YgXoCDT8AUY5896fCNyrH0QG9gmPklx1GOHgx93TFeXzgdwsQdI2Phhb1S
 TnEvkfdSDv0Ba7N1AfBiPgQEO6UX3TL611Ysa3ygy5Y+U2Cxwhc2U0qG6KJw9EHZiuXp67hWF4030
 wDo1wiPTCzMBKQZBzdTm7OW6yTaHa43s0rZeJoTcxsiuL6ZfrgQ+AOlgZHVL20DyHaHLP0A4I6OPt
 1rKlMW+w==;
Received: from [10.9.9.74] (helo=submission03.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uTNMF-0004GD-5j; Sun, 22 Jun 2025 18:15:51 +0200
Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uTNMD-0056MD-To; Sun, 22 Jun 2025 18:15:50 +0200
Date: Sun, 22 Jun 2025 17:15:47 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <cwkjxcywyepgehrcg7pvpemm77lhvdtb6hrm7s6wt4melw6xk5@5yqe3d2jecfq>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <87y0tw22wp.fsf@HIDDEN>
 <96857ba3-bb96-4ab6-8298-680a94d95702@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <96857ba3-bb96-4ab6-8298-680a94d95702@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Fri, Jun 13, 2025 at 10:46:18AM -0400, Leo Famulari wrote:
> On Thu, Jun 12, 2025, at 15:08, Simon Tournier wrote:
> > For instance, if a team introduces a graft,
> > then this very same team must open a branch that ungrafts and then merge
> > this branch as soon as possible; independently of the release.
> 
> +1
> 
> We have the resources to do this and there's no reason to not be doing it. Ungrafting rarely breaks anything so it should be easy.
> 
> Grafting uses energy and disk space on every user's computer.
> 
> The build farm has plenty of unused capacity to ungraft, at least on x86_64, which is the only platform that seems to be widely used (there's some evidence that aarch64 has multiple users).

Is this a topic enough to create a "short" GCD for, or perhaps we can just add it to the manual as a new policy?

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 22 Jun 2025 16:31:03 +0000
Resent-Message-ID: <handler.78332.B78332.175060986017517 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: pinoaffe <pinoaffe@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Andreas Enge <andreas@HIDDEN>, Liam Hupfer <liam@HIDDEN>, Greg Hogan <code@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175060986017517
          (code B ref 78332); Sun, 22 Jun 2025 16:31:03 +0000
Received: (at 78332) by debbugs.gnu.org; 22 Jun 2025 16:31:00 +0000
Received: from localhost ([127.0.0.1]:49602 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTNas-0004Y5-5Z
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2025 12:30:59 -0400
Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]:60756)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uTNap-0004Wy-NK
 for 78332 <at> debbugs.gnu.org; Sun, 22 Jun 2025 12:30:56 -0400
Received: from mailtransmit03.runbox ([10.9.9.163] 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 1uTNai-005j1g-IU; Sun, 22 Jun 2025 18:30:48 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=futurile.net; s=selector2; h=In-Reply-To:Content-Type:MIME-Version:
 References:Message-ID:Subject:Cc:To:From:Date;
 bh=4FBMgDvj6c0KKUY8rj2xcuSh6QeHnv1OIIsm2RZPvNs=; b=nup752qC+GdJl4BxANuy5irHq6
 w+BLDLPdTb8GWBphY5lU8chIA9lenxxsOfFgY5ARlVlAgbPphYtQDd3yQH5/5boFK7bhtbngCpEz0
 YUYREBpFiib8SBgfjaOn1f9haF+g1qaV/hbZJsRL+JZcoPH00BgpJNFm7uGPWpYfSxY/IqGwSNr0n
 KA7s/O2dobW7LoUCS7/OH+jM9q1ur3MNVQnlOJ7SP/K9aDRgP9NIm42362X1/kDWzXbb20lI0wAub
 AYYc/wG4gsmZYf6bbn7hEwJqJdPohtn2qIkCqDtQe5lL5nZgt6l4KcB9fn0h2kvVu0oV2A660a7VH
 EIGEfISQ==;
Received: from [10.9.9.72] (helo=submission01.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uTNah-0005Nr-UK; Sun, 22 Jun 2025 18:30:48 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uTNag-002rWh-8S; Sun, 22 Jun 2025 18:30:46 +0200
Date: Sun, 22 Jun 2025 17:30:44 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <zz55c62jqpfadtncxvha4u2rxikl4f6ozq4f77yd6fxzzbop77@pnzq7hunelr5>
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
 <r6f5xzc27hclbvb3xhaxaxmtya5ty2rled5eyv7kz65qywjncx@xvp4ke3mofl7>
 <aExuVXb_qmj6VJ2Y@jurong>
 <CA+3U0Zmb5XZz8fjvD6gnTuAvbOuwwE4tkPrqFBvqBO98=ofzug@HIDDEN>
 <aFWgLELObuFhC9wi@jurong> <8734bt4f9e.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8734bt4f9e.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Pinoaffe,

On Sat, Jun 21, 2025 at 11:26:21AM +0200, pinoaffe wrote:
> Andreas Enge <andreas@HIDDEN> writes:
(...)
> > On the other hand, I think that putting into place a process for releases
> > is a significant change; and since there are several ways of getting to
> > a release, it is good to have a community discussion and to collectively
> > decide.
> 
> I think defining a release process might be a significant change, but
> establishing a release schedule when there is none at the moment does
> not seem like a significant change, and in any case I don't think that
> regular releases can be brought about by a GCD
(...)

You said "I don't think that regular release can be brought about by a GCD". I don't know precisely why you think this, but I will guess that your perspective is that having a GCD doesn't magically make 4 volunteers turn up who are willing to do the work. Of course, this is true - totally appreciate that.

But, having a GCD does:

1. Provide a clear statement of what we want: "regular annual releases"
2. Provide some methods for how to make achieving releases easier: automation, package sets, architectures
3. Creates a useful organisation documentation around how to do releases: something the first release team can build on

So from that perspective, I think it _may_ help, and it doesn't hinder!

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Christopher Baines <mail@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Sun, 22 Jun 2025 18:51:02 +0000
Resent-Message-ID: <handler.78332.B78332.175061822220581 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: guix-devel@HIDDEN,  78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175061822220581
          (code B ref 78332); Sun, 22 Jun 2025 18:51:02 +0000
Received: (at 78332) by debbugs.gnu.org; 22 Jun 2025 18:50:22 +0000
Received: from localhost ([127.0.0.1]:49765 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTPll-0005LN-3t
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2025 14:50:21 -0400
Received: from mira.cbaines.net
 ([2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27]:54517)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mail@HIDDEN>) id 1uTPlg-0005Iq-8O
 for 78332 <at> debbugs.gnu.org; Sun, 22 Jun 2025 14:50:18 -0400
Received: from localhost (unknown [IPv6:2a02:6b67:e390:8b00::1ce5])
 by mira.cbaines.net (Postfix) with ESMTPSA id C298F27BC49;
 Sun, 22 Jun 2025 19:50:13 +0100 (BST)
Received: from fang (localhost [127.0.0.1])
 by localhost (OpenSMTPD) with ESMTP id f6b361b2;
 Sun, 22 Jun 2025 18:50:12 +0000 (UTC)
From: Christopher Baines <mail@HIDDEN>
In-Reply-To: <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 (Steve George's message of "Wed, 21 May 2025 18:10:13 +0100")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
User-Agent: mu4e 1.12.9; emacs 29.4
Date: Sun, 22 Jun 2025 19:50:10 +0100
Message-ID: <87a55za9wd.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: -0.0 (/)
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

Steve George <steve@HIDDEN> writes:

> I would love to know if this improves things from any feedback that you gave?
>
> As well as any other thoughts, comments or ideas on how to improve this GCD!

I'm generally supportive of regular releases, but avoiding things being
broken is just too hard at the moment, I can't see myself voluenteering
to be on the release team.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmhYUGJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XdZ2BAAgC3RYuqFGX/Tbu01z82quvCOdH4/5kW1
EE+fQnK6GhMjc22WazF7xfGPJf7FTziDJLC2Yi8dk6OifjWDDeKmfnMa39lO6Zj+
AFhP9xIXpDGZeniK1cEfkIa4onbTJdJKOZjnG7JakzFww3U9X9buty6FhERnHzzq
O1lL5q0eHnnpSf324ikSZTxwkKLrCPj/G9a+jVoxhYz2WOxxo7WDbRSl66HP9KOV
VvRKCHmjvDHRe4KWx+vhTJlz9oZHbFFYEgIscePbzCf+QXv5EaX7abAC6cEjB9PY
lKjRFUKfI9gD+ng4YTsO7Fovn87x/LkvqEo7j+VscU4Bwt9uc0SLF6VJhHYnQOLM
JVAND52v9hCWOp4Rk1llOLdfFmRgKwP3dLwrGQ3fRAOKU6lfmQ+eSnoDXHgPJ+2L
m2D1wEQawoxazJ/NauNAJ+tqTa9ri4P34f0SvadIVcFhThlMo8awo82nEiY6xnyf
TgcQouDw9p4bOT+d6aTQXQNWas+CSNLoIphig9iaW5fqtG8a3Y0dqELFvO2LV7Mj
auJUuztGd49Dy5U2fNjD/0POhjG6IJF7yKsiYD4BPAt2ZrIf40Xt8cdpE7BEtuuH
o7WT0mMeAe3FWcdOoKjiiVPo8/oUHDN+ZX4Pt3MbuwIPawDW/ME2nxs9wHUi0fQt
QG1ZA6RVA9s=
=Y3ju
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] Gathering feedback on GCD005: Guix regular releases
Resent-From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 23 Jun 2025 03:24:01 +0000
Resent-Message-ID: <handler.78332.B78332.175064902319571 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 78332 <at> debbugs.gnu.org
Cc: Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175064902319571
          (code B ref 78332); Mon, 23 Jun 2025 03:24:01 +0000
Received: (at 78332) by debbugs.gnu.org; 23 Jun 2025 03:23:43 +0000
Received: from localhost ([127.0.0.1]:51804 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTXmY-00055a-KK
	for submit <at> debbugs.gnu.org; Sun, 22 Jun 2025 23:23:43 -0400
Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:54614)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <maxim.cournoyer@HIDDEN>)
 id 1uTXmV-00055A-KQ
 for 78332 <at> debbugs.gnu.org; Sun, 22 Jun 2025 23:23:40 -0400
Received: by mail-pl1-x634.google.com with SMTP id
 d9443c01a7336-236377f00easo42850395ad.1
 for <78332 <at> debbugs.gnu.org>; Sun, 22 Jun 2025 20:23:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1750649013; x=1751253813; darn=debbugs.gnu.org;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=h2W02e4JV1vij1DlQi5Bw/FNibT+9H7CC/T0C++yjyY=;
 b=W+lHlsx8QDf6GKiK9I9pCZQfxbKxDUoSv2DFu8Fm4ud6AEe0lxtj2aPcStSl3tm8Ka
 DFc7FN9U9wtVmrZipFHrHR47dRronjjhX7WmQueXPLqHeNckBm87JyNbk8/ZWa7Pep3H
 nRUVmxIHgn818CtFsoKeShE/LCUvK9K7V2vj8AyDVAgJUv+UVj4EsSRfmo7PdgN7whzt
 H32/ARHSYB6l35pi3+9dSTXQN3DajbIQP6liI7IqBuwLA7D2rd9Vto+ibZLiicMpZbN5
 0u0QfVZoCHjCp1LE7hH9KxKuR0IAdMq4XKRPDZeKhs7OJFnt0eWcDq9POqQ5u53Vatfn
 dE8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1750649013; x=1751253813;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=h2W02e4JV1vij1DlQi5Bw/FNibT+9H7CC/T0C++yjyY=;
 b=VSS073RMtc4Xob/LdhxogzHj9jd15farZcRQ71n++/WE1qnwalgkOTXklPIgVFCq0v
 iSua9sND+/38CuEA0ErewB9PwNicx4+WSsd5nAJZEhV7M1cgMlnJv1mciqxHLfrXg4MZ
 qjWh0WgH3Y/+KW3JJLt8I/UlwyPnLJau4F8OM8ejGn4pOr+tdVY44HwhtKJJnBbjQlj0
 Fa07qwt4Wv8b+khlIEJL1Ixt5J3SxdDKqq27V+ioweIQvi6nxF/7pWuNP/WXN/nwli1V
 lC61+3Zzv5gQJ0dLzZezbpP69xppVhKmDkTOwrw+75ZxVSROzVZDlGLWphXaHTlSvkUP
 AFZw==
X-Gm-Message-State: AOJu0Yxt/U76QGoY9O8k4VWvZnLDomAQ1nHvlCvI0QlrZaP6805myHb8
 UgRyUXXmEvu8f4RQtYz0xgfsWEZdOUxd//fJuAnkrohgSWpTdVvhGi94
X-Gm-Gg: ASbGncvYXZTNz/3g5rO3dTf12gy1SJ3ctf+NSQBI6/5nrdKwz1bA8fTR9MMCIalsgfi
 iskCByoczkK7wKdMgzvCeUAL+t4pvufqhjZzg9yMRy4TFKZzcg5dI1lEhaJzZQwOVp7A5sDZ7sN
 p/vNQv958TMxUQCGZ260qRa87Rjfei2p65vkZnA8fE1kGUxsgdPcGbglZKqet9V+DVrKD/lFTgG
 am7ulfwCkQuOojp23ar5ZVbDLrtZLzfLpfENFtrxS5MqGsTd9+kypxicxcfD5fO7OMqqFnZhHzj
 JleKHfD3fSf9TGT8jSg2V+d4ygDk6NLGUJZzqpW6D+pwm6zX3uZ1YRBRCUYeZmdH
X-Google-Smtp-Source: AGHT+IFHTUqPdkIm8pLBPKMnA8mmjbQkAPd8t7RBoQgG9JcTkrXeDz49l5FI9EmmL+4nAMNtq6W1lQ==
X-Received: by 2002:a17:903:245:b0:234:b743:c7a4 with SMTP id
 d9443c01a7336-237d9adc218mr179176095ad.38.1750649012413; 
 Sun, 22 Jun 2025 20:23:32 -0700 (PDT)
Received: from terra ([2405:6586:7c0:4400:8c2a:c791:f284:c04b])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-237d87021e5sm71761125ad.226.2025.06.22.20.23.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 22 Jun 2025 20:23:31 -0700 (PDT)
From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
In-Reply-To: <wsvjntuihw27we5ckbgvl7wxez6goq2bguxjac4g6jsxr372xj@ro2dlgita4ey>
 (Steve George's message of "Fri, 6 Jun 2025 09:48:20 +0100")
References: <wsvjntuihw27we5ckbgvl7wxez6goq2bguxjac4g6jsxr372xj@ro2dlgita4ey>
Date: Mon, 23 Jun 2025 12:23:29 +0900
Message-ID: <875xgnf8em.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
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,

Thanks for attempting to tackle the thorny topic of release processes.

I finally took the time to read this carefully and in full.  Here are
some comments, I hope it's not too late!

[...]

> 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.

I'd drop the identified weakness '#3: Rolling updates aren't suitable
for all users' from the GCD; it's not addressed by this GCD, and it's
not clear that being a rolling distribution is a weakness (it's a
strength from the point of view of keeping things simple).

I feel the GCD goes to some lengths emphasizing that releases are a good
thing; while interesting, I think it may be better to take it for
granted and streamline what is already a rather long text, focusing more
on what are the current problems/pain points and what concrete changes
are proposed to address these.  Especially novel changes not already
captured in the 'release' Make target of the project would be important
to highlight/capture.

For example, some rudimentary package sets and architecture subsets are
already used; packages via /etc/manifests/release.scm, and architectures
via the SUPPORTED_SYSTEMS and GUIX_SYSTEM_INSTALLER_SYSTEMS Make
variables.

This target gives a good idea of what is in scope for the release, in
terms of release artifacts.  I've brushed that topic in the past [0],
but let's revisit this with more details here, for the benefit of this
GCD:

- Source distribution to be uploaded to the GNU FTP server

- Binary package of Guix for installation via guix-install.sh
  (currently: x86_64-linux i686-linux armhf-linux aarch64-linux 
  powerpc64le-linux riscv64-linux)
  
- Updated Guix package (which means its test suite must pass)

- ISO installation images for the supported systems (currently:
  x86_64-linux, i686-linux)
  
- VM image for the supported systems (currently: x86-64)

So that gives a rough initial scope for making a release.  It means
that:

1. Guix and all its dependencies must build successfully on multiple
architectures.
2. Xfce-desktop closure must be buildable on x86-64

Just this can take a lot of time, as Guix itself has to be built twice
even on slower machines like aarch64-linux. That's because we want the
referenced Guix package in the installation image to be the one being
released.

Then comes the *manual* testing/validation of these, which can takes time:

1. Installing the binary package via guix-install.sh in a VM, ideally
multiple different foreign distributions and see that it works
correctly.

2. Running the qcow2 image with something like virt-manager or
GNOME-Boxes; ensuring the system works correctly, with SPICE niceties
like copy-paste and dynamic display resizing.

3. Installation from scratch in a VM using the bootable ISO.  At least
the default settings should work, and it's nice to test more, of course.

Finally comes the step of uploading/communicating the changes:

1. Update NEWS file.  There's a update-NEWS Make target that does some
automation, but a lot of time will be sunk into manually combing
thousands of commits for interesting changes to mention in the NEWS file
(it's the part I dislike most) -- a better process would ensure NEWS are
captured/updated at the time changes are committed (burden on the
committer, not the release person).

2. Draft a blog post for the release. Traditionally highlighting
interesting changes, with examples and all.  This takes some time
too/writing skills.  In my opinion, if the goal is to automate releases,
this should be stripped down to the essentials, with a more interesting
blog posts following if we have people interested in authoring them.

3. Upload the release artifacts, using the gnupload to the GNU FTP and
email a few mailing lists, as mentioned in the doc/release.org file.

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

Oof, sorry for the wall of text.  Back to the actual GCD document being
discussed:

> Guix is both a package manager that can be hosted on other Linux
> distributions, and a Linux distribution. Limiting the range of
> packages and services that receive attention is consequently more
> complicated. Guix already has manifests to track which packages are
> used by Guix System's installer , so this proposal extends that
> concept.

I'd replace the term 'Linux' with GNU/Linux.  This is a GNU package,
let's not miss an opportunity to advertise GNU's existence/significance
:-).

I don't think we should introduce finer-grained package sets that must
be discussed for each release.  That goes against automation and
enlarges the current scope, which we're already struggling with.  If the
release artifacts build and test fine (which include a lightweight
desktop image), we should be minimally good to go.

> and removing the broken package from the archive using the Deprecation
> Policy. As always, packages may be un-deprecated and returned to the
> archive at a later date.

s/removing/deprecating/

> The aim in this template is for a 12 week active release project,

That's a lot of time!  I dream of a CI workflow that would build the
release artifacts and tests them minimally: when green, releasing would
take a couple days at most.

I think the process should only impact the operations of the release
team: that means not forcing everyone on a freeze, or a different
branch, etc.  The release team can simply branch from master to a
release branch and refine it there.  When it's done and released, it can
be merged back into master.  While trying to have teams synchronized for
a release sounds good, I think in practice this will cause problems.  So
releasing should be orthogonal to the status/milestones of teams, in my
opinion.  Releasing often will make that less of a problem anyway.

From the Appendix 1: release project template, I'd drop or edit these:

s/Notify teams/Notify contributors (e.g. guix-devel)/

I'd drop: 'Package set finalisation' (release artifacts is what
matters), 'Toolchain and transition freeze' (orthogonal),
'Major updates freeze' (shouldn't be much of an issue, with topic
branches being QA'd), 'Breaking changes to next-master' (changing main
flow is unnecessary), 'Ungraft
master branch' (should be done continuously / it's orthogonal).

In the past we've paid attention to having fresh translations in for a
release; I don't see this covered here.  Perhaps it's OK to be left as
an orthogonal topic if we release often enough.

So these are my thoughts, which I'm afraid are not too well
ordered/presented, but I've already spent more than 1 h writing this
email so I'll let it go :-).

Again, I think this is a fine text (it's very well written), and I
appreciate your initiative.  I think it's important to try to simplify
things rather than complicate them though, which this GCD in its current
form does to some degree (by codifying a larger scope than needed, in my
opinion).

I hope that's useful!

-- 
Thanks,
Maxim

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 23 Jun 2025 08:00:02 +0000
Resent-Message-ID: <handler.78332.B78332.175066557217142 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Efraim Flashner <efraim@HIDDEN>, Philip McGrath <philip@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175066557217142
          (code B ref 78332); Mon, 23 Jun 2025 08:00:02 +0000
Received: (at 78332) by debbugs.gnu.org; 23 Jun 2025 07:59:32 +0000
Received: from localhost ([127.0.0.1]:53474 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTc5T-0004SP-RR
	for submit <at> debbugs.gnu.org; Mon, 23 Jun 2025 03:59:32 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:54774)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uTc5Q-0004S4-7f
 for 78332 <at> debbugs.gnu.org; Mon, 23 Jun 2025 03:59:29 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1uTc5J-0004pB-BU; Mon, 23 Jun 2025 03:59:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=LZyZ9l2o5By1ccvqCzEsAj8w+4V/SubY75Z/kzFT9mk=; b=a3IMRrAc8n9aFg0PEQJV
 NAVVp4nMZu4BAXVR/TOAAZXnqp+5HApz1BpMbX3C5DCvj/kcGiD42yu6m5jc10YuxYorWiApVMtMt
 gpJDMaku+gMExPnu0vfBIuGmwDdRTcwvCMerbGaGVGS/7XAdru94Lq1O8knfh4it3+pOg3l15MVPr
 L9UmgLm1VU2iy4/XWvMStHmeNdYrqFaFVSWR6NlmqkgOKUWlBhxUwtGOhqeWHA94aIEeO7x5Ii1uk
 QmB3si/uYZ9WyUfMwq2b4jjZAL1nUbMaq4SI7aXYCXOOv04+5rZIBa8Lk+lYPkNbnqX1o2eVpp1EX
 TrUfncmoTYQ1rA==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <bdwefjskfci5ip2lwunassqrhkro7zlapts5edfaavl4q63jk4@7jthbcpztxce>
 (Steve George's message of "Sun, 22 Jun 2025 13:20:13 +0100")
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <87o6ux82e5.fsf@HIDDEN>
 <lfinhxkkoa2qgmn4t4sgy6ljh7q5keid5pig3lydie3kwszhmz@ugfownr6zfvk>
 <aEmHfDluw6ZSCQ12@3900XT>
 <20250611204742.sS5NE1hOmWE8d5FLpYJ64FtIfSPhGs_daASWj54i9X4@z>
 <bdwefjskfci5ip2lwunassqrhkro7zlapts5edfaavl4q63jk4@7jthbcpztxce>
User-Agent: mu4e 1.12.11; emacs 30.1
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Quintidi 5 Messidor an 233 de la =?UTF-8?Q?R=C3=A9volution,?= jour du Mulet
Date: Mon, 23 Jun 2025 09:58:40 +0200
Message-ID: <87ecva6g9b.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
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: -3.3 (---)

Hello,

Steve George <steve@HIDDEN> writes:

> -- >8 -- >8
>
> * %system_packages: packages required to boot and install a minimal Guix =
System
>   or install Guix on a foreign distribution.  This only includes default
>   options **required** by the installer which **must** work for a release=
 since
>   they are part of the default installer path.  For example, this would i=
nclude
>   the guix daemon, kernels, boot loaders, file-systems and minimal utilit=
ies.
> * %desktop_packages: additional desktop environments and other options fr=
om
>   the installer. This includes packages that are part of the installer
>   (but not default) and other popular options as chosen by the Release Te=
am.
>   Packages **should** work, but they may receive less QA attention from t=
he
>   Release Team than %system_packages.
> * %base_packages: important packages that anyone may wish to install on G=
uix and
>   consequently the project wants to maintain substitutes for. This may in=
clude
>   important toolchains, runtimes and utilities. The Release Team **may**
>   perform QA on these packages.
>
> Guix would still make all packages and services part of a release (the en=
tire
> archive).  Guix teams would be asked to test the parts of the archive tha=
t they
> look after. But, only Release Critical bugs in the `package sets` could b=
lock
> a release.
>
> The Release Team may identify other package sets as needed.
>
> -- >8 -- >8

These are supposed to be the names of variables used in
=E2=80=98etc/manifests/release.scm=E2=80=99?  Maybe we can omit the variabl=
e names after
all?

What matters here is the description of each one, which LGTM: things
that must work, should work, and have substitutes available.

Thanks,
Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] Gathering feedback on GCD005: Guix regular releases
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 23 Jun 2025 14:16:04 +0000
Resent-Message-ID: <handler.78332.B78332.175068811413294 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175068811413294
          (code B ref 78332); Mon, 23 Jun 2025 14:16:04 +0000
Received: (at 78332) by debbugs.gnu.org; 23 Jun 2025 14:15:14 +0000
Received: from localhost ([127.0.0.1]:56437 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uThx0-0003RM-8E
	for submit <at> debbugs.gnu.org; Mon, 23 Jun 2025 10:15:13 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:33482)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uThws-0003O1-0z
 for 78332 <at> debbugs.gnu.org; Mon, 23 Jun 2025 10:15:07 -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 1uThwj-008aXs-0o; Mon, 23 Jun 2025 16:14:53 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=futurile.net; s=selector2; h=In-Reply-To:Content-Type:MIME-Version:
 References:Message-ID:Subject:Cc:To:From:Date;
 bh=TlSzfWiNxu6QM/63DecDhjPQYpkZTUEarhRSIQViM4U=; b=rZRRX+T1SQM8xR2aZlAQWxSpN5
 nmcyv+YQ7aTZS6Bvi3eUmArY2Oxzc+qlvzBtWqXsbcm5SSg+WlsXD4DY9qrlc/qal99MjcAFaX/ob
 NVBRUuspAe16zDdEDBM8+TCU0f5Ur7547vA98NS/Mz0mMkzAbmpzVIquElJSYN4viC4/5Fo0pOZtu
 kC66Nhg3xOWgzQIoOtisOCOvdjhdQeZkwKbG/9W2L7JzT7sevjq2WiFug/HoeRNlMEpw+FxpeHmAG
 tSxzVzzvhByjJ8UFUzHNSWinhxkukPe2cJAJAqSYjqRXeDOMWqCDc94bozDGsz+VqWYOx0QBuxDnw
 +GXpbiFQ==;
Received: from [10.9.9.72] (helo=submission01.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uThwi-0004Ua-I6; Mon, 23 Jun 2025 16:14:52 +0200
Received: by submission01.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uThw7-008Iaj-0H; Mon, 23 Jun 2025 16:14:15 +0200
Date: Mon, 23 Jun 2025 15:14:11 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <sa7psea3krg6dkwxwdhm2zleakyfs7xmimdfzl2klvyunskb5s@7jnfkouwuqbh>
References: <wsvjntuihw27we5ckbgvl7wxez6goq2bguxjac4g6jsxr372xj@ro2dlgita4ey>
 <875xgnf8em.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <875xgnf8em.fsf@HIDDEN>
X-Spam-Score: -0.7 (/)
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 Maxim,

On Mon, Jun 23, 2025 at 12:23:29PM +0900, Maxim Cournoyer wrote:
(...)
> So these are my thoughts, which I'm afraid are not too well
> ordered/presented, but I've already spent more than 1 h writing this
> email so I'll let it go :-).
(...)

Thanks for going through the proposal in detail.

The section where you set out all the detailed steps will be particularly useful for revising our release documentation.

I got three things from your email:

(a) concern about the impact on contributors of releases
(b) concern over increasing the scope of releases
(c) desire to focus on the concrete elements with less intro/context

You said:
> I feel the GCD goes to some lengths emphasizing that releases are a good
> thing; while interesting, I think it may be better to take it for
> granted and streamline what is already a rather long text, focusing more
> on what are the current problems/pain points and what concrete changes
> are proposed to address these.

I wonder if we're all aligned that releases are important, and if we're willing to make trade-offs to achieve them. Consequently, intro text is important to lay out the context of why releases matter, creates a goal ("annual releases") and asks the group if they're willing to prioritise having them.

I would like to excite and rally all our contributors around doing regular releases. I would like us to emphasise release much *more* to contributors. So we have a shared group goal, with acceptance of it as a priority and the responsibilities that entails.

What is the impact on contributors?

We are all motivated by different things, and we're all volunteers. So to be totally clear I'm not saying _everyone_ has to practively take part in releases. But, this GCD does try to get alignment that releases are important, all contributors should be aware one is happening - and the _minimum impact_  is that contributors should not do things that are likely to prevent a release.

You bring up how much committers could be interrupted by releases:

(...)
> I think the process should only impact the operations of the release
> team: that means not forcing everyone on a freeze, or a different
> branch, etc.  The release team can simply branch from master to a
> release branch and refine it there.  When it's done and released, it can
> be merged back into master.  While trying to have teams synchronized for
> a release sounds good, I think in practice this will cause problems.  So
> releasing should be orthogonal to the status/milestones of teams, in my
> opinion.  Releasing often will make that less of a problem anyway.
(...)

At a practical level, in my experience the main reason why a distribution fails to hit it's release date is that another developer/team breaks the release by integrating some massive change that then invalidates all the QA. For a rolling release this specifically means making sure that the output of the initial install and then first user-experience of 'guix pull' works. 

I absolutely agree it should be as short as possible. I've added the following to the freeze step:

Each Release Team will iterate and improve the release process, so it's possible that this
freeze period will be reduced, changed, or removed over successive releases.


> I don't think we should introduce finer-grained package sets that must
> be discussed for each release.  That goes against automation and
> enlarges the current scope, which we're already struggling with.  If the
> release artifacts build and test fine (which include a lightweight
> desktop image), we should be minimally good to go.


On package sets I've learnt more about how it works and they've been reduced. The updated version of the `package sets` is in-line with my understanding of what you have in your email and what Efraim and Ludo have told me. It formalises what the project has, but doesn't expand the scope.

It now says that the release team MUST QA the default installer options, using the primary architectures (x86/AArch64) on the three installation methods which you listed as:

> - Binary package of Guix for installation via guix-install.sh
> - ISO installation images for the supported systems
> - VM image for the supported systems (currently: x86-64)

Also added that there's a source release that downstream GNU/Linux distributions can use:

> - Updated Guix package (which means its test suite must pass)


Fixing terminology:
(...)
> I'd replace the term 'Linux' with GNU/Linux.  This is a GNU package,
> let's not miss an opportunity to advertise GNU's existence/significance
> :-).
(...)

Thank-you.

 
> That's a lot of time!  I dream of a CI workflow that would build the
> release artifacts and tests them minimally: when green, releasing would
> take a couple days at most.
(...)

Agreed.

This seems like a topic that we should discuss as a group. Everyone wants something, but it seems we're not sure how to get started.


> Again, I think this is a fine text (it's very well written), and I
> appreciate your initiative.

Thank-you!

Steve / Futurile

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (consideration/decision)
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
In-Reply-To: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
Resent-From: Steve George <steve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 23 Jun 2025 14:44:04 +0000
Resent-Message-ID: <handler.78332.B78332.175068984128962 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: info-guix@HIDDEN, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175068984128962
          (code B ref 78332); Mon, 23 Jun 2025 14:44:04 +0000
Received: (at 78332) by debbugs.gnu.org; 23 Jun 2025 14:44:01 +0000
Received: from localhost ([127.0.0.1]:56530 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTiOl-0007VZ-GN
	for submit <at> debbugs.gnu.org; Mon, 23 Jun 2025 10:44:01 -0400
Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]:47780)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <steve@HIDDEN>)
 id 1uTiOV-0007SQ-MO
 for 78332 <at> debbugs.gnu.org; Mon, 23 Jun 2025 10:43:49 -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 1uTiOO-008fkA-5B; Mon, 23 Jun 2025 16:43:28 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=futurile.net; s=selector2; h=Content-Transfer-Encoding:Content-Type:
 MIME-Version:Message-ID:Subject:Cc:To:From:Date;
 bh=kP6CEWFuN2dd8wYRD/4ZafqlV69U4ZoDWrMr5CDsOc8=; b=aSdhMqx49nQV0uioXrDldHlj5r
 MZaVGbIRl+tLziXj33M1+bNCQxXF5t6qevt7zU2EBp8qBb/L+DFbcW1d+GTzbNjfTOAx9thAWeI4c
 aql8aBZTc048CqKYXfQsAxdKl1X4gDfIyXza3h7VeqXWdTQiT5icbbzt2SWwAkDYsAVBeZUsIEhJQ
 fxmMK8CWE7pVCp1M6FcINl3sn4qF7SdLnKoyNRARDI6EODTHDrZDDkPdjqjrWfWwepF9Kn0Q4WLvr
 YzzfYXD/oDBpAG0xbDrPSjEbDVzARUvPHtvqAyu7P1nR6wz6MGMvKicD+mYz2OxH0Hy/xvjDRnyXN
 Ei16xjmg==;
Received: from [10.9.9.73] (helo=submission02.runbox)
 by mailtransmit03.runbox with esmtp (Exim 4.86_2)
 (envelope-from <steve@HIDDEN>)
 id 1uTiON-0007FO-Hk; Mon, 23 Jun 2025 16:43:27 +0200
Received: by submission02.runbox with esmtpsa [Authenticated ID (641962)]
 (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93)
 id 1uTiOC-00B66P-Mo; Mon, 23 Jun 2025 16:43:16 +0200
Date: Mon, 23 Jun 2025 15:43:14 +0100
From: Steve George <steve@HIDDEN>
Message-ID: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="7mxptvcvbld2byef"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
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 (-)


--7mxptvcvbld2byef
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hi all,

After a good long discussion I'm moving GCD005 to Deliberation.

The final version is below and can be found on Codeberg:

    https://codeberg.org/guix/guix-consensus-documents/src/branch/main/005-regular-releases.md

This means that team members have 14 days to send one of the following replies on the patch-tracking entry of the GCD:

- “I support”, meaning that one supports the proposal;
- “I accept”, meaning that one consents to the implementation of the proposal;
- “I disapprove”, meaning that one opposes the implementation of the proposal.

The Issue is:

    78332 <at> debbugs.gnu.org

    https://issues.guix.gnu.org/78332

In terms of next steps beyond the GCD, Efraim has said he's willing to be the next Release Manager, and both myself and Andreas have committed to help out - I'm sure there will be others!

Thanks so much!

Steve / Futurile

--7mxptvcvbld2byef
Content-Type: text/markdown; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

title: Regular and efficient releases
id: 005
status: submitted
discussion: https://issues.guix.gnu.org/78332
authors: Steve George
sponsors: Andreas Enge, Ludovic Courtès, Efraim Flashner
date-submitted: 2025-05-21
SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-or-later
---

# Summary

Guix doesn't have a 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 for solving the challenges
associated with #1. and #2. above:

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.  Create a
rotating *Release Team* who will organise each release, with the goal of
*automating releases* wherever possible.

The benefits will be:

1. New installations of Guix will be better because installation media and
   manuals will be up to date.  The version of Guix distributed through other
   GNU/Linux distributions will also be more recent.
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.

This GCD doesn't attempt to address the challenge that rolling updates aren't
suitable for all users (#3. above).  Adding a slower-moving branch akin to
Nix's stable could be an eventual goal [^2].  However, this GCD aims for a single
achievable change by implementing 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 4-5 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 may
have a poor initial user experience due to time-bombs which occur in obsolete
packages and their test suites.  People installing from a release tarball often
find that important packages fail to build, making their initial attempts to use
Guix unnecessarily hard.  Old release artifacts also risk upstream sources
disappearing and require the project to keep older substitutes on our servers.

People using Guix installed on another GNU/Linux distribution often use the
guix-daemon packaged by their distribution.  This means that any daemon related
changes, such as a change to substitute's compression algorithm or changing the
substitute servers, only reach those users after their distributions have
updated their packaged guix-daemon version. Downstream GNU/Linux distributions
will only package new official releases from the project.

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 [^4].

This GCD proposes an annual release cycle, with releases **in June**.

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 June 2026.


# Creating efficient releases

To create efficient releases we need to focus efforts by defining the scope
of work that the Release Team does.

The result of the interaction between `package sets`, `architectures` and
`release artifacts` is that the Release Team's QA and testing is reduced as
follows:

1. Packages and services within the `package sets` must build on the `primary
   architectures`. Other packages are optional for a release.
2. Release artifacts are only made from packages within the `package sets` and
   on the `primary architectures`. Other architectures or release artifacts are
   optional for a release.
3. Testing and QA is on `package sets` on the `primary architectures` only.  The
   Release Team has flexibility to choose their response to bugs and issues.
4. Testing is prioritied towards the installation of Guix System and Guix (on a
   foreign distribution) using the `release artifacts`.  Practically, this means
   testing Guix System installs using the ISO image and QCOW2 image; and that
   Guix installs on a foreign distribution using the binary installer.
5. Each successive Release Team will look for ways to **automate releases**
   which may enable more efficient releases and alterations in the scope.


## 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
use-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 GNU/Linux
distributions, and a GNU/Linux distribution itself.  Limiting the range of
packages and services 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 each successive Release Team would identify key packages which
would receive the most Quality Assurance (QA) attention in that release.

The package sets would be:

* Required packages: packages required to boot and install a minimal Guix System
  or install Guix on a foreign distribution.  This only includes default
  options **required** by the installer which **must** work for a release since
  they are part of the default installer path.  For example, this would include
  the guix daemon, kernels, boot loaders, file-systems and minimal utilities.
* Desktop packages: additional desktop environments and other options from
  the installer. This includes packages that are part of the installer
  (but not default) and other popular options as chosen by the Release Team.
  Packages **should** work, but they may receive less QA attention from the
  Release Team than %system_packages.
* Important packages: important packages that anyone may wish to install on Guix and
  consequently the project wants to maintain substitutes for. This may include
  important toolchains, runtimes and utilities. The Release Team **may**
  perform QA on these packages.

Guix would still make all packages and services part of a release (the entire
archive).  Guix teams would be asked to test the parts of the archive that they
look after. But, only Release Critical bugs in the `package sets` could block
a release.

The Release Team may identify other package sets as needed.

Packages within the `packages sets` must build on the primary architectures
(see definition lower).  As part of the release's QA contributors would be asked
to test these packages.

Where a significant issue is found within a package or service that's part of
a `package set` the Release Team would work to resolve the problem. This could
involve (but isn't limited to) fixing the underlying issue, documenting it as
a limitation in the release notes or promoting an alternative and deprecating
the broken package using the Deprecation Policy.  As always, packages may be
un-deprecated and returned to the archive at a later date.

Given the constraints on developers the overal aim of the `package sets` would
be for them to be as small a set of packages and services 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).

- 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.

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 binary installer
- GNU Guix source tarball (as produced by `make dist`)

The Release Team should co-ordinate with any downstream GNU/Linux distributions
that packages Guix to assist them to make the new release part of their
distribution.

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.

The project would like to achieve releases with the minimum amount of effort
by developers.  Consequently, a goal for each Release Team is to find ways to
**automate releases** reducing the toil of successive releases.

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 release
  critical bugs
- 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 Manager 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 [^5].  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
Template 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.

Appendix 1: Release Project Template sets out a proposed time-line and major
steps to be undertaken by the project to release a new version of Guix.  It
proposes freezing master while the team focuses on releasing the new version
of Guix. Specifically, a major updates freeze (week 8->12), and a hard freeze
(week 10->12).  The drawback of this approach is that it would slow the
velocity of changes.  During this period contributors would have to keep
updates on team branches, or use an alternative temporary branch.  Each Release
Team will iterate and improve the release process, so it's possible that this
freeze period will be reduced, changed, or removed over successive releases.

There are various improvements that could be made to the release strategy over
time, such as:

1. Create separate releases of the Guix source necessary for installing Guix
   on a foreign distribution. This would mean that downstream GNU/Linux
   distributions that package Guix could have new release more often.
2. Adding an additional slower release cadence. This could be either a security
   and critical fixes branch strategy, such as implemented by Nix. Or it could
   be a slightly slower moving branch, such as implemented by SUSE SlowRoll [^4].


# Appendix 1: Release Project Template

To show the major steps of a release this release project template is a starting
point.  After each successive release the Release Team will undertake a
retrospective and will document improvements that can be made to the release
process and areas to automate to improve efficiency.

The aim in this template 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 |
| --- | --- |
| N/A | Nominate a release team |
| -4 | Notify teams of upcoming release |
| 01 | Release project start |
| 03 | Package set finalisation |
| 04 | Toolchain and transition freeze |
| 06 | Initial testing |
| 08 | Major updates freeze |
| 08 | Breaking changes to next-master |
| 08 | Ungraft master branch |
| 09 | Bugs and documentation focus |
| 09 | Branch and tag release branch |
| 10 | Testing and hard freeze |
| 10 | Release candidate |
| 10 | Prepare release communications |
| 12 | Final release target |
| 14 | Alternative release target #1 |
| 16 | Alternative release target #2 |
| +1 | Integration branch merged to master |
| +2 | Release retrospective |
| +2 | Relax - it's done! |

## Nominate a release team annually
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.  The best time
to do this would be annually at Guix Days as it's a natural motivational point
in the calendar.

## Notify teams of upcoming release (week -4)
Make sure all teams are aware of the upcoming release.  This gives them 4 weeks
to undertake any large transitions or major changes.

## Release project start (week 01)
Start the project with weekly updates to guix-devel and regular meetings of the
release team.  Encourage participation in testing and identifying bugs from
the community.

## Package set finalisation (week 03)
Specify the package sets for this release.  The Release Team will identify all
packages and their inputs so that a full manifest for the release is created.

Packages that do not build for the primary architectures so could be risk of
removal will be identified and developers will be notified following the
Deprecation Policy.

## Toolchain and transition freeze (week 04)
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 are accepted after this point.  Packages
and services in the 'minimal' package set should not be altered.

## Initial testing (week 06)
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

Update the list of packages that's at risk of being deprecated following their
identification in `Package set finalisation: see if these build failures have
been resolved.

A build failure of a package or service that's in a package set will be marked
as a blocker for the release: Release Team to make determination on response.

## Major updates freeze (week 08)
Major package updates are frozen on 'master' as the focus is on fixing any
blocking packages.  **Security updates still go to 'master'**.

All major changes not related to the release remain on team-branches.

Team branches can still be folded into the release branch as long as changes are
minor package upgrades.

## Breaking changes to an integration branch (week 08)
If there are major breaking changes that must be moved from a team branch an
integration branch will be created. For example `next-master`, this will be
short-lived, existing only until after the release.

The master branch slows down from this week until the release.

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 [^6].

## Ungraft master branch (week 08)
Guix master is ungrafted to minimise the difference with users of the release
initial 'guix pull' experience.

## Bugs and documentation focus (week 09)
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.

## Branch and tag release branch (week 09)
The master branch is tagged and a new release branch is created.

* release branch: regularly merged from master, tracks the release artifacts.
* master branch: receives security and resolutions of RC bugs.
* next-master: everything that normally goes to master.

At this point in time the master branch only receives security updates and
resolutions of RC bugs.  The focus is on stabilising, creating release artifacts
and ensuring that the substitute builders have caught up.  The release branch
receives regular merges from the master branch: the release artifacts are built
from this branch, so it tracks the release.  All other changes stay in a team
branch or go to an integration branch (e.g. next-master).

Only security updates go to the master branch from this point.  All other
changes stay in a team branch or go to an integration branch
(e.g. next-master).  The focus on the release branch is to stabilise so only
resolutions to bugs and anything required to create release artifacts should
be pushed.

## Testing and Hard Freeze (week 10)
Release Crictical (RC) bugs and issues should be solved for the release branch.

Only changes that will fix a non-building package, or a RC bug in a
package/service 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 deprecated using the Deprecation Policy.  As always,
packages can be un-deprecated at a later date.

The drawback of a freeze is that it slows down changes reaching users. As each
Release Team iterates and improves the release process they will consider whether
this freeze period can be reduced, changed, or removed.

Call for testing from all developers and users: goal is to test the main
installation use-cases and packages within the `package sets`.

## Release candidate (week 10)
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 release uses these artifacts.  If bugs are found/fixed then
release artifacts are regenerated as needed.

## Prepare release communications (week 10)
Determine all the changes of interest and highlights that will be communicated
to users during the release. At a mimimum this will be an update to the NEWS
file, and a blog post.

## Final release target (week 12)
Final release is targeted for this date. All planning and work should be done
to this date.

The new release is announced and new release artifacts are published.

If the Release Team determines that release has Release Critical bugs without
workarounds they may move the release to Alternative release target #2.
The concept of buffer weeks to ensure the release balances time and quality
comes from [Fedora's release plan](https://docs.fedoraproject.org/en-US/releases/lifecycle/#_release_dates)

## Alternative release target #1 (week 14)
This release target date may be used if the Release Team determines that there
were Release Critical bugs without workarounds at the Final release target
date.

If the Release Team determines that release has Release Critical bugs without
workarounds at this date they may move the release to Alternative release
target #2.

## Alternative release target #2 (week 16)
This release target date may be used if the Release Team determines that there
are Release Critical bugs without workarounds at one of the previous target 
dates.

If the Release Team determines that the release has Release Critical bugs
without workarounds they may move the release to an alternative date or cancel
the release.

## Integration branch merged to master (release +1 week)
If there were any breaking changes placed onto the integration branch
(e.g. `next-master`) then these can be merged into the `master` branch at this
point.  The master branch then continues as normal.

## Release retrospective (release +2 weeks)
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.

## Relax! (release +2 weeks)
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]: 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.

[^5]: 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.

[^6]: https://github.com/NixOS/rfcs/blob/master/rfcs/0085-nixos-release-stablization.md


--7mxptvcvbld2byef--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (consideration/decision)
Resent-From: =?UTF-8?Q?No=C3=A9?= Lopez <noelopez@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Mon, 23 Jun 2025 22:12:02 +0000
Resent-Message-ID: <handler.78332.B78332.175071671113638 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175071671113638
          (code B ref 78332); Mon, 23 Jun 2025 22:12:02 +0000
Received: (at 78332) by debbugs.gnu.org; 23 Jun 2025 22:11:51 +0000
Received: from localhost ([127.0.0.1]:60144 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTpOJ-0003Xt-6J
	for submit <at> debbugs.gnu.org; Mon, 23 Jun 2025 18:11:51 -0400
Received: from smtp6-g21.free.fr ([2a01:e0c:1:1599::15]:34588)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <noelopez@HIDDEN>) id 1uTpOG-0003X7-0U
 for 78332 <at> debbugs.gnu.org; Mon, 23 Jun 2025 18:11:49 -0400
Received: from localhost (unknown [45.67.83.248])
 (Authenticated sender: noelopez@HIDDEN)
 by smtp6-g21.free.fr (Postfix) with ESMTPSA id 29D3978034D;
 Tue, 24 Jun 2025 00:11:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr;
 s=smtp-20201208; t=1750716705;
 bh=Cy89Kg3sMUCGOONWvhOK4ub1ES8iTG8cYBMY5J/m+ZM=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=O3yUkuuNha5U55Cue0x4brHMTTUbQjM3t0f8KpO1F9RvYJxoJgpxAx7Zj4oEeioZx
 d9S8M4q2pkvd2AnTtaPLYhYe85F2hzM95Ll3IDwAkz7N8hrkhD/LNruTOiLUBhEPC/
 zEpOf1WBVkpkhhTMxR/iP0I9X2EE4onA4UkekGRohlKhHZ7HVfvim+iyLjZisgodfi
 /UWtehXS/bM8x+UwW8lKAWgsEFnfTFfGibPQDpIsz8rt2IqI06s6gXuhzx1pCJEsEs
 8hcdpoNQZCdsHsgJxvetUs8fkqkDUv6k8AdtEkdQeh/rR+J5B41uBE8ZP5Tf3mfc60
 VwRKgy6B/7zSw==
From: =?UTF-8?Q?No=C3=A9?= Lopez <noelopez@HIDDEN>
In-Reply-To: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
References: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
Date: Tue, 24 Jun 2025 00:11:20 +0200
Message-ID: <87h606nm5z.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Score: -0.0 (/)
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; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Steve George <steve@HIDDEN> writes:

> Hi all,
>
> After a good long discussion I'm moving GCD005 to Deliberation.
>
> The final version is below and can be found on Codeberg:
>
>     https://codeberg.org/guix/guix-consensus-documents/src/branch/main/00=
5-regular-releases.md
>
> This means that team members have 14 days to send one of the following re=
plies on the patch-tracking entry of the GCD:
>
> - =E2=80=9CI support=E2=80=9D, meaning that one supports the proposal;
> - =E2=80=9CI accept=E2=80=9D, meaning that one consents to the implementa=
tion of the proposal;
> - =E2=80=9CI disapprove=E2=80=9D, meaning that one opposes the implementa=
tion of the proposal.
>
> The Issue is:
>
>     78332 <at> debbugs.gnu.org
>
>     https://issues.guix.gnu.org/78332
>
> In terms of next steps beyond the GCD, Efraim has said he's willing to be=
 the next Release Manager, and both myself and Andreas have committed to he=
lp out - I'm sure there will be others!
>
> Thanks so much!
>

I support!

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQHFBAEBCAAvFiEEXVTPJVeyOOiNwYCiLSIyQQq3QEMFAmhZ0QgRHG5vZWxvcGV6
QGZyZWUuZnIACgkQLSIyQQq3QEOnuwv/ZBgZZdqyOnaKPO40hRlLhs5hL93sRD73
Ok3dc9O10ne/Tw/RiOiWZpIh3jByBcl6WpCwKneTlsHl9P0BNED+2vdzeZCiu3vR
1730WMr+y/j8wjFCDQirZvlmWA5Ka6HBC4TRtyDJADw51ds32kGj36NR9d4UUjEG
dMQ3HWKgrYaqSLVKzIAvWOyLUT1Eg60iJGMW1H8O6cl6UaLtM0LAz2PE5lD9rhST
NFg2h7QG/dqrfU3rDV75R/SWugV6J3WtL7RBw9DOgWxrpi+ki17rZjt+FeBonO6W
wKVM9uYj5AQ/fmhVsmbyA1qVNgK7V0ZPbFVoeyZ+fFKqElld7nWby+dQYxsZP1Q+
TjFR4lWLbzzHXgmHloOGbLyd2E8Q0spfJ5R0Hf24YG+84ZxC4VURt6r4aFZ1rR18
lmJnpRuGXcfKAGZwJrJTb3SYOIKnsN3/azN6iwlnMA1ocIxXLyvgV2NtIB11OHsa
blS0geTlrGtaUTCeh7BUI6iAVy4gxNSc
=78rA
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (consideration/decision)
Resent-From: Divya Ranjan <divya@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 24 Jun 2025 05:54:03 +0000
Resent-Message-ID: <handler.78332.B78332.17507444143497 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: guix-devel@HIDDEN, Steve George <steve@HIDDEN>, info-guix@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17507444143497
          (code B ref 78332); Tue, 24 Jun 2025 05:54:03 +0000
Received: (at 78332) by debbugs.gnu.org; 24 Jun 2025 05:53:34 +0000
Received: from localhost ([127.0.0.1]:37985 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTwb4-0000tw-Sn
	for submit <at> debbugs.gnu.org; Tue, 24 Jun 2025 01:53:33 -0400
Received: from latitanza.investici.org ([82.94.249.234]:46151)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <divya@HIDDEN>)
 id 1uTwaz-0000tL-9E
 for 78332 <at> debbugs.gnu.org; Tue, 24 Jun 2025 01:53:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=subvertising.org;
 s=stigmate; t=1750744403;
 bh=DH3PLqT9GiYJtddhgpsjU33gCFMw+nEiaTRq6DA3uxg=;
 h=Date:From:To:CC:Subject:In-Reply-To:References:From;
 b=QhMRSXUtRDQfALrBZ8VtRQXAkYbS2X9NSkmMp1u1YPaW0tsbjfu3M8fi5m7jsPQEl
 jCIjzTJ2lsKl1VGWdiXxysF/muc5YkEX/JaxDy4gzNEd59QldSL4xX8/7BeaVNfiEe
 A1+aykU134oF/aobbQ9zgCD9RzzaozSMn5RRNI2U=
Received: from mx3.investici.org (unknown [127.0.0.1])
 by latitanza.investici.org (Postfix) with ESMTP id 4bRDdb3qYSzGpn4;
 Tue, 24 Jun 2025 05:53:23 +0000 (UTC)
Received: from [82.94.249.234] (mx3.investici.org [82.94.249.234])
 (Authenticated sender: divya@HIDDEN) by localhost (Postfix) with
 ESMTPSA id 4bRDdZ53JNzGpn1; Tue, 24 Jun 2025 05:53:22 +0000 (UTC)
Date: Tue, 24 Jun 2025 05:53:18 +0000
From: Divya Ranjan <divya@HIDDEN>
User-Agent: Thunderbird for Android
In-Reply-To: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
References: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
Message-ID: <BE2C64C0-D960-4DE6-A564-9B11DCB8073A@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary=----TJZ84099WHW0X0B76OCL42J0MMBU44
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
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 (-)

------TJZ84099WHW0X0B76OCL42J0MMBU44
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

I support=2E

On 23 June 2025 14:43:14 GMT, Steve George <steve@futurile=2Enet> wrote:
>Hi all,
>
>After a good long discussion I'm moving GCD005 to Deliberation=2E
>
>The final version is below and can be found on Codeberg:
>
>    https://codeberg=2Eorg/guix/guix-consensus-documents/src/branch/main/=
005-regular-releases=2Emd
>
>This means that team members have 14 days to send one of the following re=
plies on the patch-tracking entry of the GCD:
>
>- =E2=80=9CI support=E2=80=9D, meaning that one supports the proposal;
>- =E2=80=9CI accept=E2=80=9D, meaning that one consents to the implementa=
tion of the proposal;
>- =E2=80=9CI disapprove=E2=80=9D, meaning that one opposes the implementa=
tion of the proposal=2E
>
>The Issue is:
>
>    78332@debbugs=2Egnu=2Eorg
>
>    https://issues=2Eguix=2Egnu=2Eorg/78332
>
>In terms of next steps beyond the GCD, Efraim has said he's willing to be=
 the next Release Manager, and both myself and Andreas have committed to he=
lp out - I'm sure there will be others!
>
>Thanks so much!
>
>Steve / Futurile

Divya Ranjan, Mathematics, Philosophy and Libre Software
------TJZ84099WHW0X0B76OCL42J0MMBU44
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div dir=3D"auto">I support=2E</div><br><br><div c=
lass=3D"gmail_quote"><div dir=3D"auto">On 23 June 2025 14:43:14 GMT, Steve =
George &lt;steve@futurile=2Enet&gt; wrote:</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail"><div dir=3D"auto">Hi all,<br><br>After a good long d=
iscussion I'm moving GCD005 to Deliberation=2E<br><br>The final version is =
below and can be found on Codeberg:<br><br>    <a href=3D"https://codeberg=
=2Eorg/guix/guix-consensus-documents/src/branch/main/005-regular-releases=
=2Emd">https://codeberg=2Eorg/guix/guix-consensus-documents/src/branch/main=
/005-regular-releases=2Emd</a><br><br>This means that team members have 14 =
days to send one of the following replies on the patch-tracking entry of th=
e GCD:<br><br>- =E2=80=9CI support=E2=80=9D, meaning that one supports the =
proposal;<br>- =E2=80=9CI accept=E2=80=9D, meaning that one consents to the=
 implementation of the proposal;<br>- =E2=80=9CI disapprove=E2=80=9D, meani=
ng that one opposes the implementation of the proposal=2E<br><br>The Issue =
is:<br><br>    78332@debbugs=2Egnu=2Eorg<br><br>    <a href=3D"https://issu=
es=2Eguix=2Egnu=2Eorg/78332">https://issues=2Eguix=2Egnu=2Eorg/78332</a><br=
><br>In terms of next steps beyond the GCD, Efraim has said he's willing to=
 be the next Release Manager, and both myself and Andreas have committed to=
 help out - I'm sure there will be others!<br><br>Thanks so much!<br><br>St=
eve / Futurile<br></div></pre></blockquote></div><div dir=3D"auto">Divya Ra=
njan, Mathematics, Philosophy and Libre Software</div></body></html>
------TJZ84099WHW0X0B76OCL42J0MMBU44--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (consideration/decision)
Resent-From: Z572 <z572@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 24 Jun 2025 07:03:02 +0000
Resent-Message-ID: <handler.78332.B78332.17507485295581 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17507485295581
          (code B ref 78332); Tue, 24 Jun 2025 07:03:02 +0000
Received: (at 78332) by debbugs.gnu.org; 24 Jun 2025 07:02:09 +0000
Received: from localhost ([127.0.0.1]:38288 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTxfU-0001Rt-VX
	for submit <at> debbugs.gnu.org; Tue, 24 Jun 2025 03:02:09 -0400
Received: from mail.z572.online ([88.99.160.180]:58128)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <z572@HIDDEN>) id 1uTxfR-0001RL-Cr
 for 78332 <at> debbugs.gnu.org; Tue, 24 Jun 2025 03:02:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=z572.online; s=me;
 t=1750748964;
 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=imEAy1GjvAZXMgOW4/xI3Ur78/nVnizhxQDU1IT1MpE=;
 b=tSvW3bru8XEQ9DOzTcgHS83TWsPabpLyJ9tWpiLFdbhaeD4gnWe1ccb4tWAsX2kqcTr0xx
 dbvCv6jqNcz5ieK4g1GIGHDCK1LNr+19NfWnYw+DfhFeJBc4S1FsyZKoJuFPKXR4LfdO6M
 FIHbk2mwB2SUTFtnM8w763HNOVoYvFY=
Received: from m (mail1.85362086.com [107.174.64.25])
 by mail.z572.online (OpenSMTPD) with ESMTPSA id 024e4fe5
 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); 
 Tue, 24 Jun 2025 07:09:23 +0000 (UTC)
From: Z572 <z572@HIDDEN>
In-Reply-To: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
References: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
User-Agent: mu4e 1.12.11; emacs 31.0.50
Date: Tue, 24 Jun 2025 15:01:49 +0800
Message-ID: <87cyathbc2.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: > Hi all, > > After
 a good long discussion I'm moving GCD005 to Deliberation. > > The final
 version is below and can be found on Codeberg: > >
 https://codeberg.org/guix/guix-consensus-documents/src/br [...] 
 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-trusted.bondedsender.org]
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
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: > Hi all, > > After
    a good long discussion I'm moving GCD005 to Deliberation. > > The final version
    is below and can be found on Codeberg: > > https://codeberg.org/guix/guix-consensus-documents/src/br
    [...] 
 
 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)]
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Steve George <steve@HIDDEN> writes:

> Hi all,
>
> After a good long discussion I'm moving GCD005 to Deliberation.
>
> The final version is below and can be found on Codeberg:
>
>     https://codeberg.org/guix/guix-consensus-documents/src/branch/main/00=
5-regular-releases.md
>
> This means that team members have 14 days to send one of the following re=
plies on the patch-tracking entry of the GCD:
>
> - =E2=80=9CI support=E2=80=9D, meaning that one supports the proposal;
> - =E2=80=9CI accept=E2=80=9D, meaning that one consents to the implementa=
tion of the proposal;
> - =E2=80=9CI disapprove=E2=80=9D, meaning that one opposes the implementa=
tion of the proposal.

I support

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfr6klGDOXiwIdX/bO1qpk+Gi3/AFAmhaTV0ACgkQO1qpk+Gi
3/C6UA/+MBZhLGZcsE32y3lv1obrTlIx1YqOJPfjZ0w7XBkdYm3ILczmBF3EcL/l
dmdjs7wnkhLos9JvIjDZv1w7M9+P0mJkYN8d8QcHzb1zhL9O30Y6uU1qqAayfkui
lDLSyyOyLbNRdyEXQ7SoTFjXTc4ng3sM5O80aD9GeLHnWq9BlR0CGGuJqYLwawAF
Vxv2c4/0Xm5h9HY348QXwl6110CTLB0taiBNxdpD1aGuXy1QPoS+UtYDUL2+D2ZA
wBS3IVSl/zHbKc6BMySfPvQezOQenXPAHG6ptUL2ndEGHnmLLIH7wjMqDMsUrdB9
DZbtnuzEx5GrZLhZLSnDqOWZa9hAHmhouxTEiWqHiC7YNlB3L97thwTusD9afdOw
Ir87YlesPViCu3d9DT06snzhvvdl/lywuk8oiFqUb5P3lhIWYzIpK5lD2Ss5oV2O
6cTp1uaOpgfPEQrg7Ey6U6czHvusVr5r3hCAJRXx61wO2ntaU9apasgSyIrXHX11
j2UBMrFtVTzLTxZFRegHHTYZN6+p7wGJxsp3JBtBiAkyq64T9e6bwkbwjRTVyTJh
r8/i8JDnTxQ4Vu/h84mcJyJckun6poXDSmKU/w/JOTvyZ1IBt3aSId6WDnpKkPKc
Zyqdra1vcqMRlzx/NqINz1vIQDD1rCwDWj5g2yGN+MyiRDN7vb0=
=68L6
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD 5
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
In-Reply-To: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
Resent-From: tusharhero@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 24 Jun 2025 09:13:02 +0000
Resent-Message-ID: <handler.78332.B78332.17507563377066 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17507563377066
          (code B ref 78332); Tue, 24 Jun 2025 09:13:02 +0000
Received: (at 78332) by debbugs.gnu.org; 24 Jun 2025 09:12:17 +0000
Received: from localhost ([127.0.0.1]:39779 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uTzhQ-0001pu-P5
	for submit <at> debbugs.gnu.org; Tue, 24 Jun 2025 05:12:16 -0400
Received: from mx.sdf.org ([205.166.94.24]:64544)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <tusharhero@HIDDEN>)
 id 1uTzhM-0001pA-Tx
 for 78332 <at> debbugs.gnu.org; Tue, 24 Jun 2025 05:12:13 -0400
Received: from mx.sdf.org (mx [205.166.94.24])
 by mx.sdf.org (8.18.1/8.14.3) with ESMTP id 55O9C9Yc026390
 for <78332 <at> debbugs.gnu.org>; Tue, 24 Jun 2025 09:12:10 GMT
Received: from 43.230.213.14 (SquirrelMail authenticated user tusharhero)
 by mx.sdf.org with HTTP; Tue, 24 Jun 2025 14:42:10 +0530
Message-ID: <40c8f9c16af520c16e842f371c223998.squirrel@HIDDEN>
Date: Tue, 24 Jun 2025 14:42:10 +0530
From: tusharhero@HIDDEN
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Spam-Score: 0.0 (/)
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 (-)

I support

---
tusharhero

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (consideration/decision)
Resent-From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 24 Jun 2025 11:30:07 +0000
Resent-Message-ID: <handler.78332.B78332.175076457211196 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175076457211196
          (code B ref 78332); Tue, 24 Jun 2025 11:30:07 +0000
Received: (at 78332) by debbugs.gnu.org; 24 Jun 2025 11:29:32 +0000
Received: from localhost ([127.0.0.1]:41517 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uU1qF-0002uS-Lw
	for submit <at> debbugs.gnu.org; Tue, 24 Jun 2025 07:29:32 -0400
Received: from mail-pg1-x52d.google.com ([2607:f8b0:4864:20::52d]:49284)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <maxim.cournoyer@HIDDEN>)
 id 1uU1qC-0002su-OB
 for 78332 <at> debbugs.gnu.org; Tue, 24 Jun 2025 07:29:29 -0400
Received: by mail-pg1-x52d.google.com with SMTP id
 41be03b00d2f7-b0db0b6a677so264931a12.2
 for <78332 <at> debbugs.gnu.org>; Tue, 24 Jun 2025 04:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1750764562; x=1751369362; darn=debbugs.gnu.org;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=5+1/Errg3V8rTfGwH1Tf4eU3QZQ4BkCrCqsst5rE4UI=;
 b=Ia6mT+dOxe0ZTWAaBKNNFvzFM6mKFbA3ePlHY1L/fYezeGVGyxj++mRjIOhEScgM+6
 UPBntBKjnx7/6RFZ/zPdjmWpfeoc4wprz1aORjKKWfusn7mG6LzMCg3FGIopI9RiLOaL
 yhjjvhUeJIkIQSmN59NJaivyzmlflZWcSwb/0zS7JhL/YWD+hcOhuzrZNhVGj/n69RDR
 +j6SivrdAKKjDIM3+xfhTc7eME4LluVF2EhjJ1rX8NKemTn5v/hYOuNZmnbM1fiGEWcT
 acFpo5eopXuhF5pyNAEGNTOQYJRSgOlk1DmspB2mZupQgh+1oqb0IH+NFj/guv8QB6NK
 gj6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1750764562; x=1751369362;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=5+1/Errg3V8rTfGwH1Tf4eU3QZQ4BkCrCqsst5rE4UI=;
 b=dPkugRFEPsAeY1qk02D7qm4WHpP9alLKzn+BS1oBiboKsOVbFob2w5im1kzxl9kML2
 hvdQ4KoGd4JX/tufhYhvufrZKotilJLQdMMAQ6YY+3Wd4CnmbAkMRvTf5xLFPKKXBJZK
 LrppgmvZJ7FYH2HQUuCm6UHp0k0C8cTLCpcEp9KR4R7CFKwc9R4rWx3zBymXFPXXitnf
 keEaKC+l2SDa/MBVrZGYl/DgCnl4U/7uGMqIHzvIVVp4yGvoIqVfDTZpkZzkSFDDPi1L
 9zP2PVTUZSfzva1MXbhd8jcm97hZppJidsCr29Xk4wl8cnfw/vTGYlSCNN+5gScckWS3
 BelA==
X-Gm-Message-State: AOJu0YwtRH6vAOwyRq+bjTuMLfMLGtbSIz5aaCHlLO3nlb3zctSCkPmm
 E4Oxfkqp0VR1U2morVbPiLGnNtunJCcy5AdFCJ+GFRM+vMr/EjocitbicMa0J/f7
X-Gm-Gg: ASbGncuphEf57VMV9wYYTkAAxfqMBbjpJvzhhoTE4XvODxYvMCTCTrzDQWVH5Jw0YZE
 qjcDprRr4UBrqHBcqDjIuBxKxJIQUwiiwserxOPDC2QJvHtCl3Vl4x5g98hlw285LOBeUlS2xwS
 1J9gxrzNfRAqK79CJRXmqjASavMlJJeUZxrrpSUbNeokvCt1YqRQj8ZONZ7nGtp5oEY/EzJiAWs
 C8fV234spfeoyBTc2wEJJYkKxzkcDH1ZSUdvRTM4RggcU8p5AfRSTNyeNvbTMAJFnfsQH/emOq2
 hflVWsYrFZRat63cSLbzGwK0IWION+3eFyY7OLZ4oysX5UXf4tmyOJIV/jgskTlB
X-Google-Smtp-Source: AGHT+IGYTxBBv6DnMYAK16d13LclM4/OvnTxdfHAXnqLUHMF7+ghQxVdh/k8hqfKuBXiuQkmBm21BA==
X-Received: by 2002:a17:90a:fc4c:b0:312:1ae9:152b with SMTP id
 98e67ed59e1d1-3159d8cf9demr21030263a91.23.1750764561278; 
 Tue, 24 Jun 2025 04:29:21 -0700 (PDT)
Received: from terra ([2405:6586:7c0:4400:8c2a:c791:f284:c04b])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-3159e06a78csm10390008a91.34.2025.06.24.04.29.19
 for <78332 <at> debbugs.gnu.org>
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 24 Jun 2025 04:29:20 -0700 (PDT)
From: Maxim Cournoyer <maxim.cournoyer@HIDDEN>
In-Reply-To: <87cyathbc2.fsf@HIDDEN> (z572@HIDDEN's message of "Tue, 
 24 Jun 2025 15:01:49 +0800")
References: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
 <87cyathbc2.fsf@HIDDEN>
Date: Tue, 24 Jun 2025 20:28:54 +0900
Message-ID: <87ecv9l6o9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha256; protocol="application/pgp-signature"
X-Spam-Score: 0.0 (/)
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
Content-Transfer-Encoding: quoted-printable

I support.

=2D-=20
Thanks,
Maxim

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJOBAEBCAA4FiEEJ9WGpPiQCFQyn/CfEmDkZILmNWIFAmhajA4aHG1heGltLmNv
dXJub3llckBnbWFpbC5jb20ACgkQEmDkZILmNWI52w//aYD8cqesP3imTAnidEMu
N3kzDb0nGdUSgZwxErBtul53XUbo26zR0kt+uiVqLp0rkY2B3Hk6snNqPO21D8Wj
hRGlrotYZ0t/cnPN2JL2muqdSJ2kPGkayBHD2WLoa2H3HSP11yOIw836OLQNCHIT
7GYVXGY+iUMwUZ5ufTWCGuuTGSdopKYk5K7wBfA92pAHO+0ljCsuXTmxeotHhXp6
KFWFhxTgq/Vf81Tw4/DzDmSp3RkcEZSBrEE2hn17UEDM4Y3TpnrEuFTfja0iEfy1
U4STbvpSR3SCzCzohcx+E+shSpJFNoQghUYo4ZDy5/0WU1wrIGEaImVNlVDSgApg
Q4jV+qVu8B4XHJMnZlsHolB+WvpL3hvD2YQNMPMSgsGQrbhEN+SALy4DpnbijEq0
LXkuO9kewtWHdpII8eTYvGpDTnE4DpsFojLQCb87wfEAu09QhAQo0H3Kb6ncWbVS
4C1v+fykJOWOulLGlAvuksuRe1yQBZYZ7RV+W/XlrRaWr+kToEwdlp0PnrynyFq8
DRG/Hl2ZcNCOuuwfUUYKNCL5cwiCSmJHyP9I85B6Wlgndm1qRA+S2OUBgX6QXQ+3
raKhguHDxbvMTPLjylEntopXGusTrpUduum7OSmx2BCeBcPNc9icZmNUzaL2lk/Q
PRMLGkINrOf8bmmHbeSnPtY=
=/sCg
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (submitted)
Resent-From: Greg Hogan <code@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Tue, 24 Jun 2025 12:12:02 +0000
Resent-Message-ID: <handler.78332.B78332.175076711811077 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Andreas Enge <andreas@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org, Liam Hupfer <liam@HIDDEN>, Steve George <steve@HIDDEN>
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175076711811077
          (code B ref 78332); Tue, 24 Jun 2025 12:12:02 +0000
Received: (at 78332) by debbugs.gnu.org; 24 Jun 2025 12:11:58 +0000
Received: from localhost ([127.0.0.1]:41982 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uU2VJ-0002sX-Sa
	for submit <at> debbugs.gnu.org; Tue, 24 Jun 2025 08:11:58 -0400
Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]:44383)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <code@HIDDEN>)
 id 1uU2VG-0002rX-Tp
 for 78332 <at> debbugs.gnu.org; Tue, 24 Jun 2025 08:11:56 -0400
Received: by mail-ot1-x336.google.com with SMTP id
 46e09a7af769-735ae68cc78so207657a34.1
 for <78332 <at> debbugs.gnu.org>; Tue, 24 Jun 2025 05:11:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=greghogan-com.20230601.gappssmtp.com; s=20230601; t=1750767109; x=1751371909;
 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=VOdcU+HOnA/JVQ+Qpwfa1qTwG2ylMYMfOhMPvcBlSIA=;
 b=B1ZsUSur6UD/kF0tNWgUwJ4lEmZoWK9GyuwdYovxbSt3AEi29xfnnRhqLtjJvkBmgH
 phlpDRKAUAfTHM267k7WkQUSEddbjS4dayQgXpE363knFDPE1LcYpBr/65vAJOywOmoc
 V+2qoBcU3Yz3GO6f520QHVqf0Fm1RAgsuvV8nbRw2sUqoo8qrXpdMcEmuIwplBYxAiOW
 OO4aaoDjIhiL906ZwreodQpzAjgPVRfChpoP/1aE/CgzZtAnHo4Mx6SV9IroYNdHff6r
 9f3pTP1PC5s2hwhOWIGZrHyfeJxeDqsHp2zuUN+4VemdDk4hAhcLSqVzZAwE6ET6mivy
 RUxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1750767109; x=1751371909;
 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=VOdcU+HOnA/JVQ+Qpwfa1qTwG2ylMYMfOhMPvcBlSIA=;
 b=LqlHi5TPm3BWQCWmo8HsuizJWs3CthAIM22LaxwlCf0hW6h2YRlhY1m0nUpwvGj2Hq
 sgNQK8zg8t8AMmVh7TtBW6sgofoHGwOo5CV62U+ghsD+2zm0SIAoTUCXop29XMBJFGAP
 /tsrB+RT+WuQPhAhlvlqg0Wu3KlKhk1iFuHE9QFdHggtP+GUri7xVp4Hz5KiXIuvHmP3
 LkFX3+s6iBOz01HbahsKnCBZO8aeyvOEaBoVUGJs0BvAOSvsRfQlZWzOK+/EKV8hWBzc
 np8008xWoVbtx8/knQij2hAOVgwAQkt2HGO2wxGOk19i5k5xr5GYbOrgisqQtl/eFzA9
 y8Lg==
X-Forwarded-Encrypted: i=1;
 AJvYcCVk3vKunAOCSVkiGBsjqOgOWoffefXp8N6GR92wJWmdCPJx+XsEnf0uQ9S6dBrQjl4WD8Q1og==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yyb0FWcKZOgfafuaEDsJeqhQweex5yJbetr2vLuVepP9QcJgOcB
 W0j0ScoMGRyL0l1RmtZSW+n7o6GoOAzLDL1sz3krShMut/1xTmPEdr9HVfrdK3kJqWBxIScTlRb
 iixYZ0gyT2MUFMm0aDT/eeTH5JXZmkA0sbshcAbzLFg==
X-Gm-Gg: ASbGnctiKV7vSxr2qNCs2aqkrIbrqocoHQTh3nYA+7sfKhgPCY7f0P9WvpQ4uHtQF15
 shnXfb7qmB9D55thDUBqOuHuMTxgbitpuVjjv/Xb1p4d3Qo4jAwJAUlcYbOMZG3W4a7vDzIsFNc
 kI85dh3bOU6gPJnqDaGtlO5FpnRtRF/POLdDLMBok2i+E=
X-Google-Smtp-Source: AGHT+IGEE3n09k9SSx4eHgFoi0zPWArtgsaqxEhQo6JULtuSnpTUltInfpa9aKLi/y+0pZ+HUftGBiUERiu+jRKRjFc=
X-Received: by 2002:a05:6830:2588:b0:72b:8889:8224 with SMTP id
 46e09a7af769-73a91e848bbmr12382478a34.10.1750767108664; Tue, 24 Jun 2025
 05:11:48 -0700 (PDT)
MIME-Version: 1.0
References: <zv55w7njr4ua3ammywzwenjrqh7pzmzxjk42l5lqu3jnsvwi3p@xw43bgpndwdz>
 <lv4hf46qhytwl6jlsi75wkldy45s3mcgyucaqxtzhls7trofk4@fxpbnuwb3zjt>
 <874iwtpjm5.fsf@HIDDEN>
 <r6f5xzc27hclbvb3xhaxaxmtya5ty2rled5eyv7kz65qywjncx@xvp4ke3mofl7>
 <aExuVXb_qmj6VJ2Y@jurong>
 <CA+3U0Zmb5XZz8fjvD6gnTuAvbOuwwE4tkPrqFBvqBO98=ofzug@HIDDEN>
 <aFWgLELObuFhC9wi@jurong>
In-Reply-To: <aFWgLELObuFhC9wi@jurong>
From: Greg Hogan <code@HIDDEN>
Date: Tue, 24 Jun 2025 08:11:36 -0400
X-Gm-Features: AX0GCFs28G4x8ecNYYeLjVaHNXp0rkRJ_6VoEWQFVFW_El7405mzTMb8FCrgZYs
Message-ID: <CA+3U0Zn2jY=aRLHFi80vW-=rQroYgOUF+iTUUDSLN-MGR70m4w@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
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, Jun 20, 2025 at 1:53=E2=80=AFPM Andreas Enge <andreas@HIDDEN> wrot=
e:
>
> Hello,
>
> Am Fri, Jun 20, 2025 at 11:28:19AM -0400 schrieb Greg Hogan:
> > > I think you put it very mildly; the real problem of our current proce=
ss
> > > is that it apparently has turned into "no releases"... This for me is
> > > the most important motivation for this GCD, we need some momentum to
> > > turn around this inertia.
> > The GCD process is not designed for building momentum but rather for
> > agreeing on significant changes. From GCD 001:
>
> hm, I do not get your point. Of course it is not the *process* of
> submitting this GCD that is supposed to generate momentum, but the
> *result* of the GCD (in case it gets accepted) that should generate
> momentum to reach releases.
>
> > """The GCD process is a mechanism to determine whether a proposed
> > change is *significant* enough to require attention from the community
> > at large and if so, to provide a documented way to bring about broad
> > community discussion and to collectively decide on the proposal.
> >
> > A change may be deemed *significant* when it could only be reverted at
> > a high cost or, for technical changes, when it has the potential to
> > disrupt user scripts and programs or user workflows."""
> >
> > What from GCD 005 is significant by this definition?
>
> If I follow this definition in the second paragraph, then this GCD
> proposal is not significant; it can be reverted at low to zero cost.
>
> On the other hand, I think that putting into place a process for releases
> is a significant change; and since there are several ways of getting to
> a release, it is good to have a community discussion and to collectively
> decide.
>
> My conclusion would rather be that the definition of "significant
> change" in GCD 001 is a bit too narrow. For instance, I would include
> organisational change in the Guix project also as significant, even if
> it could easily be reverted.
>
> Do you have a different suggestion to end up with more regular releases?
> Or do you think that regular releases are not desirable?
>
> Andreas

My opinions on the project release cadence are of no greater
consequence than the update frequency or inclusion of any individual
package by a contributor or team. Most of this GCD can simply be
merged into the project documentation, which can then be updated with
a new commit rather than requiring a new GCD. By codifying an annual
release process we actually restrict the number of releases! And what
if the June deadline is missed? If these are mere guidelines then what
are we voting on?

I do think the capacity of the release team to pause contributions to
the master branch, or to shunt these contributions onto a staging
branch, to be of significance. There are counterarguments that a pause
is not necessary, but this would make for a focused GCD and
discussion.

Greg

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
In-Reply-To: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
Resent-From: Konrad Hinsen <guix@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 25 Jun 2025 15:15:05 +0000
Resent-Message-ID: <handler.78332.B78332.175086450112129 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175086450112129
          (code B ref 78332); Wed, 25 Jun 2025 15:15:05 +0000
Received: (at 78332) by debbugs.gnu.org; 25 Jun 2025 15:15:01 +0000
Received: from localhost ([127.0.0.1]:36296 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uURpz-00039I-FE
	for submit <at> debbugs.gnu.org; Wed, 25 Jun 2025 11:15:00 -0400
Received: from fhigh-b3-smtp.messagingengine.com ([202.12.124.154]:45595)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <guix@HIDDEN>)
 id 1uUOdl-00062v-Jz
 for 78332 <at> debbugs.gnu.org; Wed, 25 Jun 2025 07:50:11 -0400
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 32BB67A0166;
 Wed, 25 Jun 2025 07:50:03 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-05.internal (MEProxy); Wed, 25 Jun 2025 07:50:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.net; h=
 cc:content-type:content-type:date:date:from:from:in-reply-to
 :message-id:mime-version:reply-to:subject:subject:to:to; s=fm2;
 t=1750852203; x=1750938603; bh=p7qK8Z0qAK/oDvIeCdFk3eYZs0KjLBwW
 nmXi4aF4tVw=; b=LC2Ut5RH9acSkik7wLvyjj5/mkksaPP+RMScwD38SJoBGTZS
 vRTVwTIm9STRy8CPYp7KlM8J/6HzTUeC7IdgUSlVuS5Tr8gi9sK5Lx+BKiagiMgb
 2rYqF+U/SHKHuNMForDCqzql759oFI/K6NZNxxG4a7Xw5kC2qWr2Gkas4KmQkNtm
 Jfe4qPG350aK2fT+ISbaSo3QPVWA3I0/mlCM1CiowgX/+aGgLb1uh/2OHGQdu74r
 5NAKYuaXw6upgN7aaHhpiYXtUXEW2n0JU3mn0+k92cqLgacEeV7UIh+4KHzmEsok
 oYtzk5scPZ9dg4DsYK5kD6RTEQa2RuspmtDzbw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:message-id
 :mime-version:reply-to:subject:subject:to:to:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1750852203; x=
 1750938603; bh=p7qK8Z0qAK/oDvIeCdFk3eYZs0KjLBwWnmXi4aF4tVw=; b=g
 PJYnfRBGkU0sbeq3JKYAvafTLXmAyswryX+MiEmmfMuvctBexKEmA80TKWRUXRA0
 unW1YZcnsKuUxa4LtHHxytiWI60OxojTjx4sqsCVc0WMNyV0LCljkS6j1Kcoy1a+
 9n60dHudGGsSuHlQFt/y0x2QnQkDFf4IkNzLZBNTqGxCFiZ8TL5OILqQ+CFMvyfS
 nn/jj6aI06u5nso8rXK7wNuSkyQUjYAiT2chGhUS5HjCQgrwzEbQSSZ9SRSNRAwR
 G+d9SCQyijGcqUJ0yGRaG+Qot6UveNu5/7J1CyeIW/rpjkvwqmMY+bSHxgFOX8MK
 3ldTwF8kNHycg+ctFeLnQ==
X-ME-Sender: <xms:auJbaAlB7FstPDSPCq1W4VC0AFlUbgO2uvMr2ZOFNGxLWQ_iT6SuYQ>
 <xme:auJbaP3iR3CujN9QkTVPoCQUtc6n3zGAIfh78LnZaFxEaOuDN55CJFxKJ08W7489Q
 RD9X9s3FkaJXkM1>
X-ME-Received: <xmr:auJbaOpLJwOoQL2zEtYku6hqWALhMYprfJbuNT2Ch8sd_LxqmKOq75-EDt9d_BKeHMpmkukduzgzqK4mvCbLHZNZk_T2psDW>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddvgddvvdejtdcutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr
 ihhlohhuthemuceftddtnecunecujfgurhephffvufffkfggtgesthdtredttddttdenuc
 fhrhhomhepmfhonhhrrgguucfjihhnshgvnhcuoehguhhigieskhhhihhnshgvnhdrfhgr
 shhtmhgrihhlrdhnvghtqeenucggtffrrghtthgvrhhnpedvtdefhfevtdehvdfgfffhud
 dtkedtveehfeeuhfeluddvhfefuedvfefhfffhhfenucevlhhushhtvghrufhiiigvpedt
 necurfgrrhgrmhepmhgrihhlfhhrohhmpehguhhigieskhhhihhnshgvnhdrfhgrshhtmh
 grihhlrdhnvghtpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgt
 phhtthhopegstggtsehkhhhinhhsvghnrdhfrghsthhmrghilhdrnhgvthdprhgtphhtth
 hopeejkeeffedvseguvggssghughhsrdhgnhhurdhorhhg
X-ME-Proxy: <xmx:auJbaMn6itJOGVUzg4XqhEa_sCvs0ZkFfx9hYAYScqBdsRJNFOldug>
 <xmx:auJbaO0hDT4RaDJxAJTQOc4n581b7vsJBg10zjOdo_zaDggkdKAu_w>
 <xmx:auJbaDv8dIXJIv6Ae8Bvv0--wjRHweogvGutMOTUICg-F9ByP9vDqA>
 <xmx:auJbaKX4bRBvkBvE2CypktnWlYXETNXKv1YzAgYZkVjHQaZRlYZfVA>
 <xmx:a-JbaIUkIJTpwzL2L8OUT9Y6cMssdwMc912GoPHr0JE4dPssvoNtu2Tn>
Feedback-ID: if41146ab:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 25 Jun 2025 07:50:01 -0400 (EDT)
From: Konrad Hinsen <guix@HIDDEN>
Date: Wed, 25 Jun 2025 13:49:59 +0200
Message-ID: <m1zfdw82hk.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Mailman-Approved-At: Wed, 25 Jun 2025 11:14:58 -0400
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 (-)

I support

Cheers,
  Konrad

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (consideration/decision)
Resent-From: Andreas Enge <andreas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Wed, 25 Jun 2025 16:24:02 +0000
Resent-Message-ID: <handler.78332.B78332.175086860915347 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175086860915347
          (code B ref 78332); Wed, 25 Jun 2025 16:24:02 +0000
Received: (at 78332) by debbugs.gnu.org; 25 Jun 2025 16:23:29 +0000
Received: from localhost ([127.0.0.1]:37431 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uUSuG-0003zO-9R
	for submit <at> debbugs.gnu.org; Wed, 25 Jun 2025 12:23:28 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:34246)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <andreas@HIDDEN>) id 1uUSu8-0003x7-92
 for 78332 <at> debbugs.gnu.org; Wed, 25 Jun 2025 12:23:26 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 473ACC10;
 Wed, 25 Jun 2025 18:23:13 +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 4t52OosMP_LF; Wed, 25 Jun 2025 18:23:12 +0200 (CEST)
Received: from jurong (arrious.as207910.net [45.67.83.248])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id CADE2C06;
 Wed, 25 Jun 2025 18:23:10 +0200 (CEST)
Date: Wed, 25 Jun 2025 18:23:08 +0200
From: Andreas Enge <andreas@HIDDEN>
Message-ID: <aFwibJv1EY7EjvMJ@jurong>
References: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
X-Rspamd-Server: hera
X-Rspamd-Queue-Id: 473ACC10
X-Spamd-Result: default: False [-5.60 / 15.00]; NEURAL_HAM(-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)[3];
 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-Rspamd-Action: no action
X-Spamd-Bar: -----
X-Spam-Score: 0.0 (/)
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 (-)

I support.

Andreas

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (consideration/decision)
Resent-From: Efraim Flashner <efraim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 26 Jun 2025 07:08:02 +0000
Resent-Message-ID: <handler.78332.B78332.175092164418380 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175092164418380
          (code B ref 78332); Thu, 26 Jun 2025 07:08:02 +0000
Received: (at 78332) by debbugs.gnu.org; 26 Jun 2025 07:07:24 +0000
Received: from localhost ([127.0.0.1]:47601 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uUghg-0004mN-9V
	for submit <at> debbugs.gnu.org; Thu, 26 Jun 2025 03:07:24 -0400
Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:51663)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <efraim.flashner@HIDDEN>)
 id 1uUghc-0004m6-RP
 for 78332 <at> debbugs.gnu.org; Thu, 26 Jun 2025 03:07:21 -0400
Received: by mail-wr1-x433.google.com with SMTP id
 ffacd0b85a97d-3a528243636so327732f8f.3
 for <78332 <at> debbugs.gnu.org>; Thu, 26 Jun 2025 00:07:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1750921634; x=1751526434; darn=debbugs.gnu.org;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender:from:to
 :cc:subject:date:message-id:reply-to;
 bh=icSK7xTJ8N1xD+uvJOMt+/HtyTsl2mB8zJ9PT3W8Y3s=;
 b=ItywM/kI3TnYKQl6LDCJsVQi/CNJMXJk7vSTqmlvdUkozQ3vozByHeBiNmTwegE/pk
 kDNk7bADo9/IJbigfCo1e2aMfjn6EIVgTVcI9t+9YOTzCBTwG+Z53XQ1xuTIvuwOB5jy
 aN8MajZtOTWV50utM4F/YrhRqWwOaqcOqYJtC9Z411UuNO+S8ijH0mWNCckRaUbhZLIC
 uUq4hEn/9o+oP4K6WUBV0bYDj23jTyA1sn+PWm9Je89rtSVE6MdSVAtuLfn336FITmPY
 q2Oq0MbV7ireLfgDeGq3YXJIjEtHZKJA4mngDh15/jrWFc2wpnuQvPuds+/3WYACkPqx
 Rm7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1750921634; x=1751526434;
 h=in-reply-to:content-disposition:mime-version:references
 :mail-followup-to:message-id:subject:cc:to:from:date:sender
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=icSK7xTJ8N1xD+uvJOMt+/HtyTsl2mB8zJ9PT3W8Y3s=;
 b=PBYqoWStSBBlR1a9NOkzSaX0iL7PBIoTg81NoBTmLkhdrflcdjujwC1feYtD0dEksR
 a9890J/GR04hkM63HnO2sK6RtN2Nxy9xbJ5FMubif4LeVhnKtXtTiMDCeVM5Jq/Nnw5Q
 M1TRAK5sSZfuuqsZJu65vPBJZcEukuJsI6zjWDLJ8unycgwIlGV0Eq5Zp/W1TNraoD1L
 VO+Ic7opzYS5WtBgbXV4/jLVcQbomv2RGb1jrzN5WyJ4jVn+UKbT71qB2hvCcsT08d9E
 HyKcvoV38Z7Q3tq4QbmibX/8W0RcyJh9b1xsTSHzdb/Uug/bTDDVHR9+PsvY296OM0zx
 /O9g==
X-Forwarded-Encrypted: i=1;
 AJvYcCVnocoMj25UtZNRDeS8XLzbNpkupvQRDxglYHkVl9MdeBJUq6+cJEhpI4kgJMaorBYNu3Nvog==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwKwlZHWaVFrglL30UaFyJmMt2DXgzrJIpIJRHsFKka3HjvF0lT
 ymnGB/Li20ZS/y/LfdQgUp3Cti5fNpq0pAqEWcJ89RpGKK1hGskjl12P0ygp+fQ1
X-Gm-Gg: ASbGnctyj/e9G0OixYxpzDte49FY4yNdj59LvxSv6s1wqQeIlMplp1gT6AIhBHLr/qu
 bTuAxX2/k1MSuEM/75U6S/YDsrWzRr1+gh5p1Clfr3hANC8dae+Z4o9UQrCYs8FbFmEbk708Km9
 g7o6y3aPGRjnv1eeW6KAGgHNKofVrD92XuZW4ZlyY95DRdKOEt9N+8wzQVJji1v65n2g1NXvQrh
 FaXMr9Vgw48+HI2eEl09RZPVLNqGST14xJHo2YWfRFSeY2ziGpLi2VNHM0tbRrYWY51rIMtYaZS
 xli5IhSW94yFwyZo+tysLZAUv8P5GMNqVTE5qFhL6cs/4uL19MPpRNciXkNG
X-Google-Smtp-Source: AGHT+IG8RAy2VH1I1xUOPPSbBDTkQxEdvl8VQa9GWu6CFsA5ZFK9Ah3uapR71qbooLSMKyHHhap50A==
X-Received: by 2002:a05:6000:2c0f:b0:391:3aaf:1d5f with SMTP id
 ffacd0b85a97d-3a6ed6746a1mr5083844f8f.52.1750921634283; 
 Thu, 26 Jun 2025 00:07:14 -0700 (PDT)
Received: from localhost ([141.226.13.68]) by smtp.gmail.com with ESMTPSA id
 ffacd0b85a97d-3a6e810a9bbsm6482115f8f.86.2025.06.26.00.07.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 26 Jun 2025 00:07:12 -0700 (PDT)
Date: Thu, 26 Jun 2025 10:07:10 +0300
From: Efraim Flashner <efraim@HIDDEN>
Message-ID: <aFzxnof_y6-MAhtd@3900XT>
Mail-Followup-To: Steve George <steve@HIDDEN>, guix-devel@HIDDEN,
 78332 <at> debbugs.gnu.org
References: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="ycUYusNDP8QYi0mM"
Content-Disposition: inline
In-Reply-To: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
X-PGP-Key-ID: 0x41AAE7DCCA3D8351
X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc
X-PGP-Fingerprint: A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
X-Spam-Score: 0.0 (/)
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 (-)


--ycUYusNDP8QYi0mM
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I support.

--=20
Efraim Flashner   <efraim@HIDDEN>   =D7=90=D7=A4=D7=A8=D7=99=D7=9D =
=D7=A4=D7=9C=D7=A9=D7=A0=D7=A8
GPG key =3D A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

--ycUYusNDP8QYi0mM
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmhc8ZsACgkQQarn3Mo9
g1HQ4w//UCXu1TDcdM/8LD0oR9D8KWvjelnVmqdQCOPD0yyKDWE8M9Z9S19900t8
orkkSgdDQKDzqYqrsCIWhiaMa8CELCmla4X0Xh8FBKu3AisNWCf3b5jaVeGqvakv
UZh0hw/j48Ivo6MsV+Ikyml928E2rLDYnEc62VILGH7Pk1voHnChpoVsvJan9AgP
abKH2+M8Hz+mL2njoBLNcrH2z6szIkJXu5gQ/nQp1mOFinyWlbl5mnImaF6ujaBE
k2ga3aLkU+uAEEvsg1iEzx91UiIIgl7iZgelTRZJ1pd31mFAFCmmj8pCdr0oMBtT
f4OaDH5XHmq+TtPom8Rjryl1ylQmT54um9nb+fTNXasHlqdBkMi3bO4D9s4ISG2r
QbIQSXEiWsjM0jyQRFJNA1GdwMav2OkKVFg98LQcBRnYLzXHINanhVuXsacoYwDl
CU2pz9fln6vrcm3G2GP9Mhfx50hHAY4DFPnfrVCJlEJRCV2oxigCUR3kxPNYfBNy
1IWBjgqkrLrsqDVET8QJ0XUG0LGPFyqGsgfGmavWWaZ6UerT9hoCfGYO3jgUXoHE
R6a4ZWK7UWS2exjAd/6Ur3HUXfqYReQCrulfCKPhq9ualLYprPo1RCCKfhZeXvtk
qtFfufwXECLnDEZPRk0lAj5BxoiBp4Dh2mSVEaVajekZeRHzsCI=
=/Fbd
-----END PGP SIGNATURE-----

--ycUYusNDP8QYi0mM--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (consideration/decision)
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
Resent-From: Cayetano Santos <csantosb@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 26 Jun 2025 07:44:02 +0000
Resent-Message-ID: <handler.78332.B78332.175092380527284 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: steve@HIDDEN
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175092380527284
          (code B ref 78332); Thu, 26 Jun 2025 07:44:02 +0000
Received: (at 78332) by debbugs.gnu.org; 26 Jun 2025 07:43:25 +0000
Received: from localhost ([127.0.0.1]:47938 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uUhGX-000760-2R
	for submit <at> debbugs.gnu.org; Thu, 26 Jun 2025 03:43:25 -0400
Received: from devianza.investici.org ([198.167.222.108]:31401)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <csantosb@HIDDEN>)
 id 1uUhGU-00075n-8S
 for 78332 <at> debbugs.gnu.org; Thu, 26 Jun 2025 03:43:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org;
 s=stigmate; t=1750923800;
 bh=FU3zHWrCUJgK3vfUS6ZNJi7PGPE4ZXwtalfmPR1vvW0=;
 h=From:To:Cc:Subject:In-Reply-To:Date:From;
 b=cp1BEo7cUOTRe0FEu2gnyUfRFtJTY7UwYp0M81NfJ2Tnjgpe5/M1zyShJO3l6RkyE
 w04MONs2XIgmUvjPzwr+I0T/S+HEFV7hTRZukmFjaha6Axrhx6LFzBwXvM5A3Z7AKa
 NUqhBMH+jiYfal59kzqpVJtIQYxiwAvAbVqSA+vs=
Received: from mx2.investici.org (unknown [127.0.0.1])
 by devianza.investici.org (Postfix) with ESMTP id 4bSVzX4S2Vz6xp1;
 Thu, 26 Jun 2025 07:43:20 +0000 (UTC)
Received: from [198.167.222.108] (mx2.investici.org [198.167.222.108])
 (Authenticated sender: cayetano.santos@HIDDEN) by localhost (Postfix)
 with ESMTPSA id 4bSVzX2l8Tz6xnq; 
 Thu, 26 Jun 2025 07:43:20 +0000 (UTC)
From: Cayetano Santos <csantosb@HIDDEN>
In-Reply-To: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
User-Agent: mu4e 1.12.11; emacs 30.1
Date: Thu, 26 Jun 2025 09:43:18 +0200
Message-ID: <87qzz77xt5.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
X-Spam-Score: -0.7 (/)
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 (-)

--=-=-=
Content-Type: text/plain


I support.

--
Cayetano Santos
.
gpg: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682
key: meta.sr.ht/~csantosb.pgp

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iI0EARYKADUWIQTMuBhC+dcFjs1nN3q/XN9N9r9mggUCaFz6FhccY3NhbnRvc2JA
aW52ZW50YXRpLm9yZwAKCRC/XN9N9r9mgnnAAQCnKxEMD0IQV02Y1+GQaXhcviBh
BxzbHvDczdssFl/R8gEAwOzNusBGZfcpqjwZABqHXEPbR8eIgoJkbHGlw27D7wM=
=qXef
-----END PGP SIGNATURE-----
--=-=-=--

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] 
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
In-Reply-To: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
Resent-From: "jgart" <jgart@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Thu, 26 Jun 2025 18:54:01 +0000
Resent-Message-ID: <handler.78332.B78332.17509640074309 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17509640074309
          (code B ref 78332); Thu, 26 Jun 2025 18:54:01 +0000
Received: (at 78332) by debbugs.gnu.org; 26 Jun 2025 18:53:27 +0000
Received: from localhost ([127.0.0.1]:53917 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uUriw-00017K-Mf
	for submit <at> debbugs.gnu.org; Thu, 26 Jun 2025 14:53:27 -0400
Received: from mx2.dismail.de ([159.69.191.136]:37532)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <jgart@HIDDEN>) id 1uUris-00015N-Md
 for 78332 <at> debbugs.gnu.org; Thu, 26 Jun 2025 14:53:23 -0400
Received: from mx2.dismail.de (localhost [127.0.0.1])
 by mx2.dismail.de (OpenSMTPD) with ESMTP id e3b0b846
 for <78332 <at> debbugs.gnu.org>; Thu, 26 Jun 2025 20:53:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dismail.de; h=
 mime-version:date:content-type:content-transfer-encoding:from
 :message-id:subject:to; s=20190914; bh=0/rwlZux9SUF5D1twtZ2L2CVN
 7OBxgA6+8LgppzvSX4=; b=JpZquynBo425zf75loktIStZOdSCw9xBFCX+0Lc8P
 fml6oP7Ytu8RLnX4yv3GvjT4Ft3Iyt7Ut59/FuMtu5OMEvN1G1S3BecQZwAMuzrr
 r+JfLyZmgcVWixL0nHStc6OQ1Wl534K/+3WowxOv32mm3xkZCgu4aernUXH5e3D2
 xETW4/wMY0DX+H7ZsbHMxSrHd2+BbnSgmHzhvBqu7LmIop9sJbJGkaakLB7NHzIY
 HKhpPL1UzXQ8gDhgMWPNTyg6YK6SY326Ymh778fj+lvHpOvzvE3ZuYxlH5DYs7eP
 rAnwVcdyqCk3wPieYm6x5yQqayf2vc8FRsvffdLnvn5tA==
Received: from smtp1.dismail.de (<unknown> [10.240.26.11])
 by mx2.dismail.de (OpenSMTPD) with ESMTP id fc6073e3
 for <78332 <at> debbugs.gnu.org>; Thu, 26 Jun 2025 20:53:14 +0200 (CEST)
Received: from smtp1.dismail.de (localhost [127.0.0.1])
 by smtp1.dismail.de (OpenSMTPD) with ESMTP id b8c343d1
 for <78332 <at> debbugs.gnu.org>; Thu, 26 Jun 2025 20:53:14 +0200 (CEST)
Received: by dismail.de (OpenSMTPD) with ESMTPSA id 7a1cde8d
 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <78332 <at> debbugs.gnu.org>;
 Thu, 26 Jun 2025 20:53:13 +0200 (CEST)
MIME-Version: 1.0
Date: Thu, 26 Jun 2025 18:53:12 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "jgart" <jgart@HIDDEN>
Message-ID: <86d63991d7a8dc9fa350a1735b708ee46fc0aec9@HIDDEN>
TLS-Required: No
X-Spam-Score: -0.3 (/)
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.3 (-)

I support.

--
jgart

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] GCD005: Regular and efficient releases (consideration/decision)
Resent-From: Janneke Nieuwenhuizen <janneke@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 27 Jun 2025 07:14:02 +0000
Resent-Message-ID: <handler.78332.B78332.175100843128836 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: guix-devel@HIDDEN, 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175100843128836
          (code B ref 78332); Fri, 27 Jun 2025 07:14:02 +0000
Received: (at 78332) by debbugs.gnu.org; 27 Jun 2025 07:13:51 +0000
Received: from localhost ([127.0.0.1]:59937 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uV3HS-0007V0-2D
	for submit <at> debbugs.gnu.org; Fri, 27 Jun 2025 03:13:50 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:45030)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <janneke@HIDDEN>) id 1uV3HM-0007TH-3U
 for 78332 <at> debbugs.gnu.org; Fri, 27 Jun 2025 03:13:47 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <janneke@HIDDEN>)
 id 1uV3HD-0000vp-S9; Fri, 27 Jun 2025 03:13:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=72SkYgqc9RySLgt43b4RBg0G3Au26e4zDXP2pvRKP1w=; b=dCi+xU7iDNFSE6jMweLi
 ZW6JPwIbmzgccP52X9odTuzmDz+SIfRl7Nbv6hQDznRFwjhp4IAzkP4oVgsIdfXgfpmX2OV6fo20K
 8cXsjLSACSEL86Cn2sq49+ImieuNzgaQVT5DKx5s6+VqwIk9J/UGg2NFDTy8ysR4ordNLIb/2Q7jY
 RpNlW9q5qTqOLXQGYup5T2+jQIFgDOTAEu0pvR4n2hSnUIUcLX7O2Im+fGHnDD5sp2o3FsAROUnvD
 F94p8nYNQbHvg2VDJidDshQdwPApgGcTeflpR+MXU9FU34guD8iDLUqSUkFCHbJU5JONM1rkck7Hx
 ee61WamnzTzkcA==;
From: Janneke Nieuwenhuizen <janneke@HIDDEN>
In-Reply-To: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
 (Steve George's message of "Mon, 23 Jun 2025 15:43:14 +0100")
Organization: AvatarAcademy.nl
References: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
X-Url: http://AvatarAcademy.nl
Date: Fri, 27 Jun 2025 09:13:29 +0200
Message-ID: <87sejly7vq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
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: -3.3 (---)

Steve George writes:

> After a good long discussion I'm moving GCD005 to Deliberation.

> This means that team members have 14 days to send one of the following
> replies on the patch-tracking entry of the GCD:

I support.

Greetings,
Janneke

--=20
Janneke Nieuwenhuizen <janneke@HIDDEN>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar=C2=AE https://AvatarAcade=
my.com

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.
Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 27 Jun 2025 09:06:02 +0000
Resent-Message-ID: <handler.78332.B78332.175101512322238 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: Steve George <steve@HIDDEN>
Cc: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.175101512322238
          (code B ref 78332); Fri, 27 Jun 2025 09:06:02 +0000
Received: (at 78332) by debbugs.gnu.org; 27 Jun 2025 09:05:23 +0000
Received: from localhost ([127.0.0.1]:32981 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uV51O-0005mY-Re
	for submit <at> debbugs.gnu.org; Fri, 27 Jun 2025 05:05:23 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:57142)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludovic.courtes@HIDDEN>)
 id 1uV51K-0005gH-DC
 for 78332 <at> debbugs.gnu.org; Fri, 27 Jun 2025 05:05:19 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludovic.courtes@HIDDEN>)
 id 1uV515-0006Zh-7B; Fri, 27 Jun 2025 05:05:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=lg1xIkBR9RFrUxrKP5Ms9ePCT53nz5mdjznvraO2Pro=; b=e1F5btH/GXEPxnNJNsST
 8zOguO1SP1+j4al5HJtkpFG+RzYz0U9b2Z9TZY7xPlUOKg/HPwV9jeWp6Ye5JMf2qUkD1CtoX0s4e
 MrtKP7cnqae+VU1on+K4YpX139p3jBkVhjUeAt2EN5tu0zjkriBaihf7ivEqMkFfWx8V95gZVmWHm
 cvddMKzrfbsUJZ3x+EZBC0UIQ0gQXFMZ6Hs/t/8MmTt5ddTYgDgICrNRKPdceYB2waYFD0MzJgC5v
 Z24Z+HOJMHUSq3ZKfx/8QQkClVoDqfwgWuWinecbH6hITi5mCE8lEFgBt55c6e6BJoB8+LFFcKW1l
 dpYAF/k09g1ukw==;
From: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
In-Reply-To: <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
 (Steve George's message of "Mon, 23 Jun 2025 15:43:14 +0100")
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
 <jfsvpkfrnez7uvawb56su4ewesauz3buinablmhk6xcx4kvbfi@zimlowx467fe>
Date: Fri, 27 Jun 2025 11:04:30 +0200
Message-ID: <87wm8xv9lt.fsf_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
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: -3.3 (---)

Steve George <steve@HIDDEN> writes:

> After a good long discussion I'm moving GCD005 to Deliberation.
>
> The final version is below and can be found on Codeberg:
>
>     https://codeberg.org/guix/guix-consensus-documents/src/branch/main/00=
5-regular-releases.md

I support.

Thank you!

Ludo=E2=80=99.

Message sent to guix-patches@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: [bug#78332] (no subject)
References: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
In-Reply-To: <e4f06ff9e3d38db80827c8c56d27f2e0108fecf5.1746793072.git.steve@HIDDEN>
Resent-From: Sughosha <sughosha@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: guix-patches@HIDDEN
Resent-Date: Fri, 27 Jun 2025 11:32:03 +0000
Resent-Message-ID: <handler.78332.B78332.17510238766804 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78332
X-GNU-PR-Package: guix-patches
X-GNU-PR-Keywords: patch
To: 78332 <at> debbugs.gnu.org
Received: via spool by 78332-submit <at> debbugs.gnu.org id=B78332.17510238766804
          (code B ref 78332); Fri, 27 Jun 2025 11:32:03 +0000
Received: (at 78332) by debbugs.gnu.org; 27 Jun 2025 11:31:16 +0000
Received: from localhost ([127.0.0.1]:34766 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uV7IZ-0001lE-Lp
	for submit <at> debbugs.gnu.org; Fri, 27 Jun 2025 07:31:15 -0400
Received: from layka.disroot.org ([178.21.23.139]:40078)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <sughosha@HIDDEN>)
 id 1uV7IW-0001aJ-Pf
 for 78332 <at> debbugs.gnu.org; Fri, 27 Jun 2025 07:31:14 -0400
Received: from mail01.disroot.lan (localhost [127.0.0.1])
 by disroot.org (Postfix) with ESMTP id 6D045260A2
 for <78332 <at> debbugs.gnu.org>; Fri, 27 Jun 2025 13:31:09 +0200 (CEST)
X-Virus-Scanned: SPAM Filter at disroot.org
Received: from layka.disroot.org ([127.0.0.1])
 by localhost (disroot.org [127.0.0.1]) (amavis, port 10024) with ESMTP
 id k5aEeE0FpL4f for <78332 <at> debbugs.gnu.org>;
 Fri, 27 Jun 2025 13:31:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail;
 t=1751023868; bh=5NR8efPcx85QAgr3LftP7RYBJv2AAHZAoYZdyHysD4U=;
 h=From:To:Date;
 b=e6NcPs4CrnLkI1/E9njVme+ml9ecSGqN+aOHep5AewweHxD22agpsmmqAE4u9zKZQ
 8wvcTkBBInOFgnk/8aEUFNlUmfvLcA7plvjgjFDyM0NnRteGBY8Lz4/jEwrMx4uIz+
 oFiqQU7mWA5XVn/sm3f5SrBFvNoAOOSc7zhjndLRVqn8Nl4PttvX3/aTT78aql+jbA
 lm9a8rrauGj58NQd2LalBEJVj/FU8ILADqEbCXReQysd7zAZMN/WTVN3ftTzKZsTMA
 nu5BqSw9RlM4mg8K2kPooJCBc079dBuKEVoWIYICs0G19R3bA/UO8JOfmbyvE0VRgb
 DjC+Lq8RVpEAw==
From: Sughosha <sughosha@HIDDEN>
Date: Fri, 27 Jun 2025 17:01:03 +0530
Message-ID: <5915213.DvuYhMxLoT@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"
X-Spam-Score: 2.0 (++)
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: I support it. Regular releases targetting its schedule helps
 in keeping packages up to date as well as stable. -- Sughosha 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
 The query to Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243
 for more information.
 [178.21.23.139 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.
 [178.21.23.139 listed in bl.score.senderscore.com]
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.8 MISSING_SUBJECT        Missing Subject: header
 0.2 NO_SUBJECT             Extra score for no subject
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 (+)

I support it. Regular releases targetting its schedule helps in keeping 
packages up to date as well as stable.
-- 
Sughosha

Last modified: Fri, 27 Jun 2025 11:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.