Hi Cayetano, On 2026-06-15 at 14:13+02:00, Cayetano Santos wrote: > A bit of background. CI farm builds every single pull request (pr) > which doesn’t impact more than 300 dependent¹: on success, the pr is > merged in master ... and rebuild back again, consuming computing > resources (see https://codeberg.org/guix/guix/pulls/9274, for example). > > Beyond the current 300 threshold, a pr should be send to a topic > (team) branch; once every few, all the branch is built, all of its pr > in a raw. On success, the branch is merged in master: available > binaries are then available as substitutes, no extra computing > resources are used². > > Teams, branches and Guix QA³ are a great idea, and way more computing > efficient than processing individual pr. This is why I'm proposing > here a slightly different strategy to alter the fraction of changes > which fall into each category (see https://codeberg.org/guix/guix/pulls/9314). > > - Reduce the current threshold from 300 to 150 dependents > - Impose a threshold on patch version upgrades⁴ (see ‘patch-upgrade’ > codeberg tag) > > [1] > https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html > [2] https://codeberg.org/guix/guix/issues/9098#issuecomment-16666955 > [3] https://qa.guix.gnu.org/ > [4] https://semver.org/ > [5] https://yhetil.org/guix-devel/[email protected]/t/#u
I agree with the sentiment, though I need to note that the reason topic branches are doing so well is largely thanks to Andreas's (as much as he wish he needn't have to) effort on overseeing and ordering them. Aside from sharing this branch sitting responsibility across us, the current FIFO queue is going to mean a reviewed update will land on master in, optimistically, a month, and someone will have to resolve the conflict in-time when the branch is at its turn. I'm surprised to learn from https://codeberg.org/guix/guix/issues/9098 that substitutes from CI are not cached, and this seems to be the root of the problem (not in, we must cache CI outputs, but rather, why it is not feasible to cache CI outputs). On QA I'm struggling to get misc-world-rebuild through because the evaluation keeps dying and we don't have enough disk space there to keep substitutes between rerun. I'm just raising the issues so Andreas and Chris (CC'd) can explain the situation with CI and QA and we can document the constraints we have on the infrastructure. Ideally, I think it can help a lot if CI are only started explicitly by team members after approval instead of running on every PR push. This way I suppose we can even afford to keep the substitutes. Cheers, Phong
