Hi Leo,

Indeed, as far as I can remember we've always updated SBCL directly on
master, because it's one of those exceptions.

> `guix refresh -l sbcl` shows "Building the following 221 packages would
> ensure 988 dependent packages are rebuilt [...]"

Note that most of these packages are "cl-*" packages, which effectively
just copy the source code of SBCL packages.  They don't compile anything.

> Remember, the rebuild limit for the master branch is 300 rebuilds,
> according to item 8 of the manual section Submitting Patches:
>
> https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html
>
> Sometimes it's fine to go over the limit a little bit, especially for 
> packages that are cheap to build, but SBCL packages are pretty
> expensive.

In my experience it is indeed one of theses cases where it's fine to go
over the limit, because beside the check phase of very few packages
(sbcl-lparallel and sbcl-ironclad come to mind), most SBCL packages
build in an instant.

The whole set of Lisp packages builds in a few minutes on my machine.

What do you think?  Do you think it would still be wiser to update on
staging instead?

What do you mean with "coordinate it in advance"?  Is there a better way
to handle the process?

> The aarch64 builders, which are mostly emulated on x86_64 machines,
> cannot build SBCL [0], and we need to cancel those derivations
> manually, or they'll spend weeks repeatedly failing to build it. Maybe
> we should just disable SBCL on aarch64 until the build farm can build
> it reliably?

Sure thing, but I'm not an aarch64 user so maybe someone else would like
to comment about this.
Thoughts, anyone?

Otherwise I can remove aarch64 from the list of supported systems in the
SBCL package.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/