Re: ‘core-updates’ is gone; long live ‘core-packages-team’!

[Andreas Enge <andreas@enge.fr>]

Hello,

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.

concurring with Simon, following this description, I also do not understand
what this concept of merge trains improves as long as it is not automated
(and we have lots of build power to subsequently build several combinations
of branches).

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.

Andreas