Hello, I agree with Chris that we should plumb QA back into our workflow, it was a big progress at the time: "pull requests" that did not cause too many rebuilds (if I remember correctly, 300 or maybe later 600) were evaluated and the packages built, and they were immediately available as substitutes. So they could safely be applied to master.
We have part of this with the cuirass-bot, but without the upper limits on package builds, and the build results are thrown away. As for pinned versions, I am moderately excited. There is a certain tendency of not updating them, and this is yet more cleaning up work that few people are interested in. For instance, the default fmt variable is at version 9 (from 2023-06). Whenever a package requires a newer version, a newer variant is added; we also have 10 (from 2024-09), 11 (2025-12) and 12 (also 2025-12); and an old 8. This makes it too comfortable to not work on global progress: "update fmt to a newer version" (which I am trying to do on the c++-team branch right now, so this is no call to action, just an example), but to hide that we are behind the curb as far as package freshness is concerned. Another example: gdb/pinned is at version 12 (from 2022), default gdb at 14 (from 2023), while we also have 17 (from 2025). This is work that is (or should be) done on the team branches. I also made a trial with a branch that regrouped several unrelated changes that caused big rebuilds (beyond those handled by QA), into a branch called "world-rebuild". It was a success, but took quite a bit of time. Before pushing the branch I made sure "by hand" that all the "-P1" dependents for each commit were still building (as far as I could tell, since they did not necessarily build before the commit either). And an almost necessary prerequisite to this is that our distribution builds to 100%, so that we can easily see if this goes down with a commit. Andreas
