‘core-updates’ is gone; long live ‘core-packages-team’!

[Ludovic Courtès]

Hi again!

Over the years, consensus emerged that ‘core-updates’, as a branch where
we lump together all sorts of rebuild-the-world changes, is no longer
sustainable.  Those of us who were at the Guix Days in February 2023
came to the conclusion that (correct me if I’m wrong) we should keep
branches focused, with a specific team responsible for taking care of
each branch and getting it merged.

There’s now a ‘core-packages’ team, so there will be soon a
‘core-packages-team’ branch focusing exclusively on what’s in its scope,
as specified in ‘etc/teams.scm’.  There’s already a lot of work to do
actually: upgrading glibc (again!), coreutils, grep, etc., and switching
to a newer GCC as the default compiler.  That branch won’t be special;
it will follow the conventions that were adopted last year:

  
https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html

If you’d like to help with these things, you’re very welcome, and you
can consider joining the ‘core-packages’ team to help coordinate these
efforts in the longer run.

To reduce world rebuilds, perhaps we’ll sometimes create “merge trains”,
whereby we’ll merge, say, the branch upgrading CMake and that ungrafting
ibus on top of ‘core-packages-team’, and then merge this combination in
‘master’.  The key being: these branches will have been developed and
tested independently of one another by dedicated teams, and the merge
train will be a mere formality.

Recently, Christopher Baines further suggested that, as much as
possible, branches should be “stateless” in the sense that their changes
can be rebased anytime on top of ‘master’.  This is what we’ve been
doing for the past couple of months with ‘core-updates’; that sometimes
made it hard to follow IMO, because there were too many changes, but for
more focused branches, that should work well.

Thoughts?

Ludo’.