Hi Andreas,
On Fri, 22 May 2026 at 12:21, Andreas Enge <[email protected]> wrote:
> there is a general problem of us having many world rebuild branches,
> and not enough build power to handle them quickly (plus occasional
> interruptions of the tools, like when we upgraded bayfront).
Well, this problem had been identified [1] when we switched to the
per-team branching model; especially when ’core-updates’ had been
deleted. And…
> But I wonder if we could not find a "social solution" in this case?
…At the time, we discussed “build train”.
Today, the next item of the queue is processed when the previous is
done. The issue is that the same package might rebuild twice.
Consider the order:
python - sbcl - r - world - haskell - audio
It means the package ’r-seurat’ will be rebuilt by the Python-world
rebuild, then rebuilt again by the R-world rebuild, then probably
rebuilt by the World-world rebuild, then rebuilt again by the
Haskell-world rebuild.
Here, at least 3 rebuilds of ’r-seurat’ are temporary and known apriori
to be wasted. In [1], the example is about 521 packages, i.e., mixing
the both illustration, 521 packages would be rebuilt 3 times for
(almost) no gain.
Minimizing at the extreme ends to the ’core-updates’ branch (= put all
the world-rebuild changes and rebuild the whole only once) and we remind
why we dropped it! ;-)
However, there is an intermediary between ’core-updates’ and the current
queue processing, IMHO. For instance, assume this hypothetical
scenario:
. team-python is ready and ask to queue the branch
. later, sbcl-team is ready and ask to queue, too late, the
team-python is already under rebuild
. two week more, r-team is ready and ask to queue
. three days more, world-team is ready and ask to queue
Why not rebuild at once r and world?
Somehow, we need rules for smoothing the friction, the “solution“ I’m
proposing with “build train” is:
When a team is ready, they send a message asking to queue. If in the
next week, another team is also ready, then the two branches are thus
built by at once by one evaluation.
I think that such combination could reduce the workload.
Well, I said “next week”, maybe it’s better to set “two weeks” or “12
days”, or I don’t know. And maybe all the branches cannot be easily
combined, but somehow, I think we could have a “rule” based on some
observations that tries to rearrange and combine the queue for being
processed at a faster pace.
Cheers,
simon
1: Naming “build train” instead of “merge train”?
Simon Tournier <[email protected]>
Mon, 09 Sep 2024 19:28:57 +0200
id:[email protected]
https://lists.gnu.org/archive/html/guix-devel/2024-09
https://yhetil.org/guix/[email protected]
--8<---------------cut here---------------start------------->8---
$ guix graph --path r-seurat python-docutils
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
--8<---------------cut here---------------end--------------->8---
--8<---------------cut here---------------start------------->8---
$ guix graph --path r-seurat ghc-dec
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
--8<---------------cut here---------------end--------------->8---
