Hugo Buddelmeijer writes:
On 4/29/26 14:48, Jason Conroy wrote:
That process seems to focus on branches that are (mostly) ready
to
Am I missing some detail about how to make this feasible within
a
short time window? Or does the plan hinge on an assumption that
substitute* breakages will be rare in practice?
We do need something organized for such a big change. I like to
fix
random packages, and a significant fraction of the currently
broken
packages are broken due to the gcc-14 change from December 2024.
And that gcc change was more important than changing the
substitute*
behavior in my opinion. But both are similar: a change that
could
have been opt-in, but instead opt-out was preferred (perhaps
rightly
so).
Agreed, I've felt some pain with GCC 14 as well. At least with
substitute*, we have an opportunity to constrain breakage to a few
cases
that are trivial to resolve, with patches that are (hopefully)
small
enough to resist merge conflict.
E.g. with python-team I failed to add much value the last couple
of
weeks because by the time I managed to compile the rust chain,
the
branch was rebased, so I never got to the point that I could
figure
out which packages failed, let alone fix them. Having a central
server like QA list blocking builds and serve substitutes would
solve
both problems.
Re: "list blocking builds", are you envisioning an interface
different
from the "Failing" and "Blocked" dashboards that Andreas and Phong
mentioned?
Jason
