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

From: Sharlatan Hellseher <[email-masked]>
Date: Sun, 08 Jun 2025 10:44:25 +0100

Hi,

* Vote

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

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

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

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

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

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

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

---
Oleg