Re: 01/03: gnu: sbcl: Update to 2.3.5.

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]


Guillaume Le Vaillant <glv@posteo.net> writes:

> Christopher Baines <mail@cbaines.net> skribis:
>
>> guix-commits@gnu.org writes:
>>
>>> glv pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit b019b49c74e51e42230da471f39bff9f642fbc24
>>> Author: Guillaume Le Vaillant <glv@posteo.net>
>>> AuthorDate: Fri Jun 2 13:32:55 2023 +0200
>>>
>>>     gnu: sbcl: Update to 2.3.5.
>>>
>>>     * gnu/packages/lisp.scm (sbcl): Update to 2.3.5.
>>> ---
>>>  gnu/packages/lisp.scm | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Did this change need to go straight to master?
>>
>> → guix refresh -l sbcl
>> Building the following 314 packages would ensure 1615 dependent packages are rebuilt: ...
>>
>> Above 300 but below 1800 means staging according to [1].
>>
>> 1: https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html#index-rebuild-scheduling-strategy
>
> Currently there is no staging branch, as it got deleted because of the
> changes in the branching strategy ([1]). If someone creates a staging
> branch, will cuirass see that and start building it? Or could it just
> stay in limbo for months?

Deleting the staging branch when it's merged seems sensible to me
regardless of whether you want to use that branch in the future. As far
as I'm concerned, while there have been disucssions of changing the
branching strategy, the guidance as written down hasn't changed yet
(there are some suggested changes in [1]).

The changes in [1] still keep the 300 dependent limit on pushing changes
directly to master though.

As for the Cuirass configuration, it might need changing. You can either
ask on guix-devel/guix-sysadmin for someone to do this, or ask on
guix-sysadmin to get access to Cuirass so that you can use the admin
interface yourself [2].

2:  https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00009.html

> Concerning the specific case of sbcl dependents, they build pretty fast.
> On my machine, building all of them took less than one hour. So the
> period during which some substitutes are missing is pretty short.
>
> [1] https://issues.guix.gnu.org/63459

That's still time people will be without substitutes, and because these
changes in effect "jumped the queue", that's also time the build farm
won't be building changes from patches or the branch(s) that it's meant
to be working on (since the master branch builds have priority).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]