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

[indieterminacy <indieterminacy@libre.brussels>]

On 2024-09-06 10:09, Andreas Enge wrote:
> 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.
> 

Well, if anybody wants a Friday digression, here is a parable about 
'guaranteed connections':
https://yewtu.be/watch?v=vHEsKAefAzk

YMMV

> 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