all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* ‘core-updates’ is gone; long live ‘core-packages-team’!
@ 2024-08-31 13:03 Ludovic Courtès
  2024-09-01 16:34 ` Steve George
  2024-09-04 12:58 ` Simon Tournier
  0 siblings, 2 replies; 22+ messages in thread
From: Ludovic Courtès @ 2024-08-31 13:03 UTC (permalink / raw)
  To: guix-devel

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


^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2024-09-26 19:26 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-31 13:03 ‘core-updates’ is gone; long live ‘core-packages-team’! Ludovic Courtès
2024-09-01 16:34 ` Steve George
2024-09-01 17:06   ` Christopher Baines
2024-09-03 14:02     ` Christopher Baines
2024-09-06  9:01   ` Ludovic Courtès
2024-09-09 15:30     ` Simon Tournier
2024-09-04 12:58 ` Simon Tournier
2024-09-05  8:39   ` Marek Paśnikowski
2024-09-05  9:40     ` Ricardo Wurmus
2024-09-06  9:11   ` Ludovic Courtès
2024-09-06 10:09     ` Andreas Enge
2024-09-06 11:35       ` Marek Paśnikowski
2024-09-06 13:25         ` Andreas Enge
2024-09-06 13:17       ` indieterminacy
2024-09-26 12:52       ` Ludovic Courtès
2024-09-06 17:44     ` Vagrant Cascadian
2024-09-06 18:06       ` Leo Famulari
2024-09-06 20:29         ` Rebasing commits and re-signing before mergeing (Was: ‘core-updates’ is gone; long live ‘core-packages-team’!) Vagrant Cascadian
2024-09-07 17:45           ` Leo Famulari
2024-09-08  2:33             ` Vagrant Cascadian
2024-09-06 19:49       ` ‘core-updates’ is gone; long live ‘core-packages-team’! Christopher Baines
2024-09-09 17:28     ` Naming “build train” instead of “merge train”? Simon Tournier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.