Re: gnu: inetutils: Update to 2.4.

[Leo Famulari <leo@famulari.name>]

On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote:
> Felix Lechner <felix.lechner@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.