Hi, Andreas Enge <andr...@enge.fr> skribis:
> Am Fri, Sep 06, 2024 at 11:11:14AM +0200 schrieb Ludovic Courtès: >> The way I see it, one of the branches would be tested independently. >> The second one would also be tested independently, but on a limited >> scope—e.g., x86_64-only, because (1) we usually have more build power >> for that architecture, and (2) perhaps we know the problems with those >> branches are unlikely to be architecture-specific. >> Then we’d rebase that second branch on top of the first one, and build >> the combination for all architectures. [...] > Once the first branch is good, why not simply merge it to master and then > rebase the second branch on master and test it, instead of postponing the > merge? After all, building is costly, not merging. > > Notice that with QA, the concept is that the packages will be available > on the build farm once the branch has been built, so postponing a merge > has no advantage. Maybe you’re right, I don’t know. We’ll have to give it a spin and see what works best. My main concern is the build cost of small but unrelated changes that really ought to be tested separately but trigger lots of rebuilds (or redownloads, once substitutes are available). Ludo’.
