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