On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: > Felix Lechner <felix.lech...@lease-up.com> writes: > > With the core-updates process now abandoned, I retitled the issue to > > Could you share the reference of that? I'm not against it, but our > currently documented process still mention the good old staging and > core-updates branches.
At the Guix Days in February, we discussed the branching workflow and reached a rough consensus that for non-core packages (defined in %core-packages), we should try to adopt a more targeted "feature branch" workflow. That's actually what we used to do, before we outgrew our old build farm, after which we were barely able to build one branch at a time (IIRC, we would stop building master in order to build core-updates or staging). The discussion was summarized by Andreas here: https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html Currently we are demo-ing this workflow in the wip-go-updates branch and go-team Cuirass jobset. My hope is that we can rewrite the relevant documentation in the coming months, as we learn from these early efforts. I don't think the core-updates process is abandoned, but we should reduce its scope. For the core of Guix, both the packages and Guix itself, it makes sense to alter things in tandem. But as we have >22000 packages, there are many packages that would currently qualify for core-updates but aren't core, and can be relatively easily tested in smaller themed batches. I would suggest abandoning the staging branch approach after its current patches are merged to master. The staging branch was always a kludge from when our build farm was struggling. For something like inetutils, I would suggest borrowing from its package module name (gnu packages admin), and attempt to update the administrative packages as a group. Those who are interested in system administration should lead the effort.