On 15/6/26 15:13, Gabriel Wicki wrote:
Actually I am thinking about a somewhat more brutal approach to enforcing this: We could go through the pipeline in a round-robin fashion. Every branch gets one shot, and if it is not ready to be merged, the issue gets closed. Then the team can work on fixes and open a new issue to queue up at the end of the line.
>
I think this is a sensible approach to go forward.
Maybe. But that would lead to the situation that people with more powerful machines (and money to buy powerful machines) get their branches merged faster.
During the Python 3.12 migration, my machine was essentially world-rebuilding non-stop, because by the time it was finished, we refreshed packages early in the chain, or we rebased. And now we will be doing Python 3.13.
So I was, and am, considering getting a dedicated machine to build branches I'm interested in.
Buying a dedicated branch-machine would help me, and would help the project in the short term. And I might do it, because my Guix contributions are limited by time. But long term, it might be counterproductive.
(For the record: the main reason I haven't yet build such a machine is the environmental impact; in case anyone doubts my commitment to that.)
Maybe we could reorganize the dependency graph such that we need less rebuilds? E.g. more /pinned variants maybe? Or refactor the rust and zig build chains somehow? Or move expensive packages to a separate channel?
I don't have the answers either.
