Steve George writes: > 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 "Managing Patches and Branches" section deliberately doesn't mention anything about teams as there's no requirement for branches to be associated with teams. Grouping related changes together is good for a few reasons, but it's absolutely fine to have a branch which updates a single package, not related to any team. As noted on the page as well, if you don't have commit access (which is required for creating branches), you should just open the issue then hopefully someone with access will create the branch for you. > 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 ;-) That page needs updating I think. >> 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. Initially the documentation on branches said to create an issue when you want to merge a branch, but this was changed to when you create a branch to try and avoid situations like this, where a branch sits around and gets stale for many months.