Andreas Enge <andreas@enge.fr> writes:

> 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.
>
> 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.

* What if an unrelated branch gets merged before the two considered in the
example?

I suggest to generalize the process like this:
1. branch based on master, passes QA -> merge
2. branch based on master, fails QA -> fix QA, go to 1
3. branch not based on master, passes QA -> rebase, go to 1
4. branch not based on master, fails QA -> fix QA, go to 3

* What if a branch is worked on for a long time and the rebase itself
becomes non-trivial?

The rebase process could be split into multiple
steps, each corresponding to successive merge commits in the master.
The process could be further made easier by introducing a policy where
each merge commit to master must be tagged with a unique identifier.  By
a “merge commit” I mean any commit that brings a branch back to master,
including fast-forwards.

Thanks to the unique tags, not only could other branches rebase without
having to resort to commit hashes, but also users could confidently
point at specific points in the history to base their systems on.  For
example, if a new version of an application removes an important
functionality, they could pin the guix channel to the merge tag before
and take their time to implement a solution.

> 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.

I think that merging reviewed code often is a good practice, because it
could make rebasing in other branches easier to solve in case of
incompatibilities by decreasing the scope of change at any particular step.