guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: indieterminacy
Subject: Re: ‘core-updates’ is gone; long live ‘core-packages-team’!
Date: Fri, 06 Sep 2024 13:17:39 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]