Am Wed, Apr 29, 2026 at 08:48:25AM -0400 schrieb Jason Conroy: > That process seems to focus on branches that are (mostly) ready to 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.
I think it would still work: Broken packages block those that depend on them; once a broken package is repaired, it unblocks the depending packages (potentially revealing more broken packages among its dependents). So as I see it, every non-broken package is built exactly once, every broken package is built exactly twice (one failure, one success). This assumes that all broken packages are repaired immediately so that we do not lose time. But QA handles the first two branches at the head of the queue, giving priority to the top branch; so if the top branch is stalled, the second one will be built (and can potentially be merged first; we just did this for r-team that skipped ahead of python-team). So I think this even works when we do not do the repair work immediately, assuming that the second branch in the queue is ready to merge. And I also think we do act like this already, for instance I used this procedure for the openssl update on crypto-team, and I think it is also used for the [email protected] migration on python-team (in any case, it should also be eased by work on local build failures, including during the time the branch is waiting in queue). Andreas
