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

[Simon Tournier]

Hi Ludo,

On Fri, 06 Sep 2024 at 11:01, Ludovic Courtès <ludo@gnu.org> wrote:

> Once it’s “known good”, I see two possibilities:

[...]

>   • Attach to a “merge train”.  For instance, assume there’s a branch
>     changing ‘gsl’: this is totally unrelated to ‘ffmpeg’ but it also
>     triggers a lot of rebuilds.  We could tack that second branch on top
>     of the known-good ‘ffmpeg’ branch, and, once it’s all good, merge
>     that “train” into ‘master’.

As Andreas pointed out:

        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.

Somehow, I have the same question: if “gsl” branch is “known good”, why
not directly merge it to master.  As the other possibility suggests…

>   • Merge into ‘master’, especially if it turns out that binaries are
>     already available on the build farms.

…However, in this case, if the branch changing ’ffmpeg’ is “known good”
because it had been built, then the 521 rebuilds are wasted because the
branch “gsl” is cooking and also triggers these same 521 rebuilds.

Therefore, it would be wiser to merge the ’ffmpeg’ branch into the ’gsl’
branch and rebuild only once.  (I am not pushing the button “please save
the planet” but I am thinking about it very strongly. ;-))

Somehow, a tool is missing, IMHO.

How to know which branch needs to be rebased onto which other one?  How
to know which rebuilds from one specific branch are not independent to
some other branch?

Maybe it would help as a first step to have the intersection list of
“guix refresh” applied to two sets of packages.

Assuming two 2 branches are not continuously built but only when ready
to merge, I still have the same question [1]:

        Bah the question how to merge different branches containing world
        rebuilds without the big catch-all old core-updates branch is not
        addressed under the constraint of reducing as much as possible the
        number of world rebuilds, for what my opinion is worth.


Cheers,
simon


--8<---------------cut here---------------start------------->8---
$ guix refresh -l gsl
   | cut -d':' -f2 | tr ' ' '\n' | tail -n +2 | sort | uniq > gsl.deps
$ for i in $(seq 2 7); do guix refresh -l ffmpeg@$i \
   | cut -d':' -f2 | tr ' ' '\n' | tail -n +2 ;done | sort | uniq > ffmpeg.deps

$ wc -l gsl.deps ffmpeg.deps 
 1473 gsl.deps
  521 ffmpeg.deps
 1994 total

$ for line in $(cat ffmpeg.deps); do grep -n ^$line gsl.deps ;done | wc -l
521
--8<---------------cut here---------------end--------------->8---

1: Re: ‘core-updates’ is gone; long live ‘core-packages-team’!
Simon Tournier <zimon.toutoune@gmail.com>
Wed, 04 Sep 2024 14:58:37 +0200
id:87v7zby3r6.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2024-09
87v7zby3r6.fsf@gmail.com">https://yhetil.org/guix/87v7zby3r6.fsf@gmail.com