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
