Am Fri, Apr 11, 2025 at 04:55:27PM +0200 schrieb Ludovic Courtès: > But we also need more flexibility, in particular the ability to say > “this branch is ready so it should be merged now”.
Well, there *is* flexibility. If the r-team branch is ready and built out on CI, say, you can merge it now (well, it would be annoying if it were merged right before a different branch that is also ready and at the top of the queue on QA, so a bit of coordination would be needed in any case). It is just not built on QA, so I do not know how ready or not it actually is. Our current definition of "ready" includes "being built on QA"... > Could we provide a > way to change the order of branches shown by qa.guix.gnu.org? We already did that by closing the core-packages-team and (temporarily) python-team branches, and letting elogind-updates and node-team go to the front. Chris explained to me that we can also do it by having merge issue 1 be blocked by merge issue 2; then 2 goes in front of 1 (this becomes complicated when shuffling r-team from place 6 in the queue to place 1, however). Right now, there are qt-team and tex-team in front of r-team, all three of which claim to be ready and "just" need to be built to be merged. We will only know if problems occur once the branches are built, though; and then it depends on the reactivity of the teams managing the branches. Some of the teams have not answered the question "is this breakage stopping you to merge, or do you want to merge nevertheless?" for several days (actually, for four branches at the top of the queue I have observed or interacted with, not one of them has reached out to say "we are not ready yet, let someone else go first"; branches are at the top of the queue, building them shows some breakage, and then the teams start repairing without temporarily giving up their spot in the queue). So the problem is more social and one of coordination than of technical measures to reorder branches. For instance, we could have a person responsible for merging branches; if a team does not merge within 24 hours after being asked the question "your branch has been built, is it ready to be merged?" this person could move the branch in question to a later position in the queue. But this would require some kind of authority which nobody has so far, and a consensus for a more active managing of branches instead of relying on the goodwill of teams and slowly emerging consensus of what should be merged in which order. Andreas
