(reorganized to put more on-topic reply higher) 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).
merge. But since the break-and-fix migration we've been discussing needs QA feedback, it sounds like the bulk of the branch work can't begin until it's already #1 in the queue. And for an iterative process (where each fix reveals failures in unblocked dependees) that means several lengthy QA passes.
We do need to find a better mechanism for such big changes. I did think that it would be fine to have failing packages once 'your branch' is built by QA, but now realize that that assumption was wrong.
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.
But I did not realize that that process delays other (perhaps better behaved) branches significantly, so I need to find a way to not rely on that. (But maybe python-team is fine; I don't know.)
Hugo
