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

[Steve George]

Hi,

I have a question on one part of the workflow, and would like to propose an 
addition to the 'stateless' branches Chris suggested:

On 31 Aug, Ludovic Courtès wrote:
> 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
> 
(...)
> 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.

Under the 'patches and branches' workflow, what should happen to packages that 
are *not* part of any team, but do cause a rebuild of more than 300 dependent 
packages?

Andy Tai gave an example of ffmpeg [0]. There aren't enough contributors or 
committers for every package to be covered by a team, so this seems like a 
permanent constraint even if more teams do grow over time.

The manual currently says it goes to 'staging' [1], and that this will be 
merged within six weeks. Is this actually true? I don't see any sign of it on 
Guix' git [2], and an unsure if the manual is out of sync with the branches 
workflow. 

While 'staging' seems like it could have similar difficulties to core-updates 
if it gets out of hand. The alternative choice of each time someone making a 
branch 'ffmpeg-and-stuff-i-collected-with-over-300-rebuilds' doesn't seem like 
a better choice ;-)

> 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.
(...)

Long-lived branches and ones that don't cleanly apply onto master cause lots of 
difficulties from what I've seen. Perhaps a lesson is that branches should both 
be stateless *and* should not exist for more than 3 months. We already have a 
rule that encourages atomic changes within any patch in order to make things 
faster/easier to review. By extension, lets do the same with branches - merge 
them more often.

I would propose a patch to the managing patches/branches sections of the manual 
depending on what the consensus is here.

Steve / Futurile

[0] https://lists.gnu.org/archive/html/guix-devel/2024-08/msg00202.html
[1] https://guix.gnu.org/devel/manual/en/guix.html#Submitting-Patches
[2] https://git.savannah.gnu.org/cgit/guix.git/refs/heads