Hi Ludo,
On Fri, 06 Sep 2024 at 11:01, Ludovic Courtès <l...@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.touto...@gmail.com>
Wed, 04 Sep 2024 14:58:37 +0200
id:87v7zby3r6....@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2024-09
https://yhetil.org/guix/87v7zby3r6....@gmail.com
