Hugo Buddelmeijer via "Development of GNU Guix and the GNU System
distribution." <[email protected]> writes:
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 this has come up before, but I wonder if a custom `guix
deploy` script, pre-configured with all necessary QA
infrastructure, would address some of these concerns. I.e.,
something that's turn-key enough for teams and individuals to
deploy and tear down at will.
For projects with very bursty resource requirements, renting a
cloud machine for a few weeks per year ought to have less
environmental impact than owning it, and may even be more
cost-effective.
Jason
