From: Simon Tournier <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>, guix-devel <guix-devel@gnu.org>
Subject: Re: Automatically testing package updates
Date: Mon, 02 Dec 2024 15:50:53 +0100 [thread overview]
Message-ID: <87y10ynnoy.fsf@gmail.com> (raw)
In-Reply-To: <87iks2urmd.fsf@gnu.org>
Hi,
That’s cool! Here, I share a “random thought”. :-)
> This manifest is just an example. We could come up with manifests
> targeting package collections like CRAN packages, astronomy packages,
> and so on.
Discussing on Mastodon, Konrad emitted this idea [1]:
Just an idea from someone mostly ignorant about how the build
farms work: could package builds be done lazily? E.g. the build
farm tracks requests for yet-unbuilt packages, and builds those
that have been requested ten times or so.
I know it’s not possible considering the current way substitutes are
designed.
The idea is still appealing; especially when using “guix time-machine”.
Currently and considering patch#74542 [2], the build farm will try to
build all the updates by upstream for some “defined” packages even if
these updates would never reach any branch or worse never land to
master. If I understand correctly, the idea behind is to ease updates
and/or reviewing. Yeah it should help. :-)
Consider Blender: many of all the updates are trivial updates. But on
my relatively new laptop, it takes around 15 minutes to build. It’s not
nothing and it might be a strong refrain [3] for updating and/or
reviewing the update. Here is the past rate of the updates:
5905b47287 gnu: blender: Update to 3.6.13. Sat Jul 6 00:52:44 2024 -0300
ebaf658acd gnu: blender: Update to 3.6.10. Sat Apr 6 08:40:56 2024 -0300
e8d163b49a gnu: blender: Update to 3.3.5. Fri Apr 14 15:11:51 2023 -0400
eb169d36e5 gnu: blender: Update to 3.3.5. Fri Mar 31 13:29:29 2023 -0400
45fe602602 gnu: blender: Update to 3.3.1. Sat Nov 19 19:54:14 2022 +0100
f05f831f66 gnu: blender: Update to 3.0.1. Wed Feb 9 16:06:28 2022 +0100
48d38125c2 gnu: blender: Update to 2.93.6. Sun Nov 21 18:37:50 2021 +0100
The idea of the manifest, if I understand correctly what’s behind, is to
ease that, then for example the versions 3.6.11 and 3.6.12 would have
been built by removing the constraint on having the capacity to locally
build.
That’s said, it appears to me a bazooka: build all just in case.
Because it’s not sure at all that someone™ would be motivated to commit
the Blender’s updates of 3.6.11 and 3.6.12; if we had the manifest
discussed before. :-)
Back to Konrad’s idea!
Consider that if instead of building all we would potentially need, we
only build what we really need. That’s what QA tries to do: build all
the patches. However, sometimes QA is lagging [4] or the number of
dependencies is too high. Let put more <3 in QA! Still.
Now, consider the case where we use "guix time-machine". Today, the
substitutes availability depends on the weather. ;-) Well, sometimes
substitutes are still available, sometimes not; it depends on the cache
policy. Indeed, we cannot store all binaries forever.
Therefore, consider the feature: When using "guix time-machine" on a
restricted set of channels, and so using specific revisions defined by
the channels, if the content-addressed item is not available, then it
would be possible to queue one or more or none transformations for some
packages from one specific revision of some channels we care.
This feature solves two problems at once: 1. avoid the bazooka but still
help by easing the reviewing of updates and 2. provide substitutes for
past revisions.
However, this needs to adapt how the mechanism for substituting works,
right? The question seems: Is it doable or already doomed by current
design? In other words, would it require too much work?
Cheers,
simon
1: https://social.sciences.re/@khinsen@scholar.social/113550338572274110
2: [bug#74542] [PATCH 11/11] etc: Add upgrade manifest.
Ludovic Courtès <ludo@gnu.org>
Tue, 26 Nov 2024 11:33:50 +0100
id:c55d9c57d99b50436c3afa607beaf62ae46d3c40.1732615193.git.ludo@gnu.org
https://issues.guix.gnu.org/74542
https://issues.guix.gnu.org/msgid/c55d9c57d99b50436c3afa607beaf62ae46d3c40.1732615193.git.ludo@gnu.org
https://yhetil.org/guix/c55d9c57d99b50436c3afa607beaf62ae46d3c40.1732615193.git.ludo@gnu.org
3: Public guix offload server
Arun Isaac <arunisaac@systemreboot.net>
Thu, 21 Oct 2021 02:23:49 +0530
id:878rynh0yq.fsf@systemreboot.net
https://lists.gnu.org/archive/html/guix-devel/2021-10
https://yhetil.org/guix/878rynh0yq.fsf@systemreboot.net
4: https://social.sciences.re/@civodul@toot.aquilenet.fr/113549606095407968
next prev parent reply other threads:[~2024-12-02 19:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-02 13:44 Automatically testing package updates Ludovic Courtès
2024-12-02 14:50 ` Simon Tournier [this message]
2024-12-02 19:14 ` Simon Tournier
2024-12-02 19:16 ` Simon Tournier
2024-12-05 7:20 ` Efraim Flashner
2024-12-05 8:06 ` Hilton Chain
2024-12-05 9:23 ` Ricardo Wurmus
2024-12-05 13:29 ` Suhail Singh
2024-12-05 15:31 ` Ricardo Wurmus
2024-12-05 16:10 ` Suhail Singh
2024-12-05 19:07 ` Attila Lendvai
2024-12-05 19:55 ` Ricardo Wurmus
2024-12-06 5:09 ` Suhail Singh
2024-12-14 23:46 ` Ludovic Courtès
2024-12-06 4:53 ` Suhail Singh
2024-12-05 19:58 ` Ricardo Wurmus
2024-12-03 0:32 ` Vagrant Cascadian
2024-12-14 23:47 ` Ludovic Courtès
-- strict thread matches above, loose matches on Subject: below --
2024-12-03 14:01 Sharlatan Hellseher
2024-12-14 23:51 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y10ynnoy.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).