Am Fri, Jun 12, 2026 at 01:54:40PM +0200 schrieb Gabriel Wicki: > Andreas, are we in a particular rush? Because from our (or at least my) > perspective we waited for QA to hint us towards everything we'd need to > resolve before pushing the audio-team changes to master. I mean, like, > everything throughout the dependency tree. > But I somehow get the feeling that being on top of the QA build queue > means being in a rush and getting into a pushable state ASAP.
This is how I conceive the thing. Right now we have eight branches in QA. So just as an example, if the top branch takes a week to get ready and (as a world rebuild branch) about a week to get built, we need two weeks per branch and four months to empty the queue (during which time more branches will have lined up). If the branches are ready, it takes only two months. This will make the difference between a sustainable and a clogged pipeline. Moreover, if the top branch is not ready, we will need project resources over and over again to build the branch. So my opinion is that the two or three branches at the top of the queue should be ready to be merged, so that also ideally all this could be done without human intervention and back and forth. For instance, I am actively monitoring the branches, and the less they are in good shape, the more work this will take me for reordering, stopping a branch with problems, letting another one to the front, and so on. And there is some inertia also in the build infrastructure to switch from one branch to another. So I think it is a question of regards for the other waiting branches that all of them are ready. Of course this is not always possible - you cannot build a branch up to its leaves at home. Or in haskell-team, we could not build the ghc versions on aarch64 machines at home. But the branch should be ready as much as reasonably possible. For instance, this could mean building the -P1 dependents of changed packages. And even then, we will be busy enough with unforeseen problems! 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. This provides some incentive to only submit branches in good shape. But it is less efficient if only a few changes are needed to repair a branch that is almost okay. Andreas
