Scheduling a new release?

Scheduling a new release?

[Simon Tournier]

Hi all,

Here or there, we have bugs as:

    https://issues.guix.gnu.org/70659
    https://issues.guix.gnu.org/70726

And our answer looks like:

        > Additionally, I strongly advise upgrading guix-daemon, as noted in the
        > bug report above.

Well, the bugs appear because the user is upgrading guix-daemon. ;-)

In both cases (#70659 and #70726), it comes from a fresh install (latest
release v1.4.0) and then the first ’guix pull’ aiming to upgrade all
leads to that reported error.

Therefore, I strongly advise upgrading latest Guix release. ;-)


Although these days I do not have much free time, let make a new release
as soon as possible.  WDYT?

Who’s in?

Cheers,
simon

Re: Scheduling a new release?

[Simon Tournier]

Re,

On lun., 06 mai 2024 at 13:12, Simon Tournier <zimon.toutoune@gmail.com> wrote:

> Although these days I do not have much free time, let make a new release
> as soon as possible.  WDYT?
>
> Who’s in?

Well, the patch review sessions could be helpful.  Maybe we could run
some online hackathons.  IMHO, having a schedule together would help –
at least me ;-) – to keep the flow until crossing the finish line.

WDYT?

Cheers,
simon

Re: Scheduling a new release?

[Christopher Baines]

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

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Here or there, we have bugs as:
>
>     https://issues.guix.gnu.org/70659
>     https://issues.guix.gnu.org/70726
>
> And our answer looks like:
>
>         > Additionally, I strongly advise upgrading guix-daemon, as noted in the
>         > bug report above.
>
> Well, the bugs appear because the user is upgrading guix-daemon. ;-)
>
> In both cases (#70659 and #70726), it comes from a fresh install (latest
> release v1.4.0) and then the first ’guix pull’ aiming to upgrade all
> leads to that reported error.
>
> Therefore, I strongly advise upgrading latest Guix release. ;-)
>
>
> Although these days I do not have much free time, let make a new release
> as soon as possible.  WDYT?
>
> Who’s in?

I think it would be nice to have a new release, and indeed release more
often, I think the way to get there is for less things to be broken
between releases, such that releasing takes less effort in terms of
testing and fixing things.

To give some specific issues, I've run up against the recent issues with
nss [1][2] and I don't think we could release with the nss package as is
currently.

1: https://issues.guix.gnu.org/70662
2: https://issues.guix.gnu.org/70663

My hope is that we can spot and potentially address issues like the ones
above prior to them affecting master, and thus be more ready to release
more often. I think the issue you raise above is also an example of
this, a breakage that we can hopefully avoid in the future (through
getting the data service to just use builtin:download, discussed in
#67250).

While releases will still require bursts of effort, I think we need a
more sustainable approach to actually achieve more frequent releases.

Chris

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

Re: Scheduling a new release?

[Ludovic Courtès]

Hi Christopher,

Christopher Baines <mail@cbaines.net> skribis:

> While releases will still require bursts of effort, I think we need a
> more sustainable approach to actually achieve more frequent releases.

I think this is largely an organizational problem.

As discussed at the 2023 Guix Days (!), we could follow a model similar
to that of NixOS: form a release team (~4 people) dedicated to keeping
track of issues in particular wrt. the installer, and committed to
publishing a release within 4–6 months. (I think several people actually
volunteered back in Feb. 2023. :-))

After that, another team, possibly with some overlap, would take over.

What matters IMO is to make sure people on the team are not on their own
(they coordinate the effort, they don’t fix every single bug by
themselves), that they have agency (they decide what goes into the
release and what’s left for later), and they do not risk burn-out (it’s
a fixed-term mandate).


Anyway, I agree it’s high time we published a new release! I would
encourage anyone with some experience to volunteer on the team.  Again,
that doesn’t require expertise on the whole code base but rather a good
idea of which teams to talk to and methodology to keep track of things
to be done.

Thanks,
Ludo’.

Re: Scheduling a new release?

[Christina O'Donnell]

Hi,

On 08/05/2024 14:01, Christopher Baines wrote:
> I think it would be nice to have a new release, and indeed release more
> often, I think the way to get there is for less things to be broken
> between releases, such that releasing takes less effort in terms of
> testing and fixing things.
>
> To give some specific issues, I've run up against the recent issues with
> nss [1][2] and I don't think we could release with the nss package as is
> currently.
>
> 1: https://issues.guix.gnu.org/70662
> 2: https://issues.guix.gnu.org/70663

I can fix these by disabling tests, but I would prefer if someone with 
more experience packaging for guix could make a decision on it. 
Otherwise, I don't have any problem reducing the number of tests and 
disabling all tests on PowerPC at least.

I could also do some analysis if it was deemed necessary, inserting a 
patch to measure the timings of each test/cycle. Additionally, I could 
try packaging some of the versions between 0.88 and 0.98 to identify the 
exact change that could be to blame. However, both of these seem 
overkill, given the backlog of patches/issues we have left to get 
through, and the manpower we currently have to work with.

Would any of that be helpful?

> ...

Kind regards,

Christina

Re: Scheduling a new release?

[Christopher Baines]

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

Christina O'Donnell <cdo@mutix.org> writes:

> On 08/05/2024 14:01, Christopher Baines wrote:
>> I think it would be nice to have a new release, and indeed release more
>> often, I think the way to get there is for less things to be broken
>> between releases, such that releasing takes less effort in terms of
>> testing and fixing things.
>>
>> To give some specific issues, I've run up against the recent issues with
>> nss [1][2] and I don't think we could release with the nss package as is
>> currently.
>>
>> 1: https://issues.guix.gnu.org/70662
>> 2: https://issues.guix.gnu.org/70663
>
> I can fix these by disabling tests, but I would prefer if someone with
> more experience packaging for guix could make a decision on
> it. Otherwise, I don't have any problem reducing the number of tests
> and disabling all tests on PowerPC at least.
>
> I could also do some analysis if it was deemed necessary, inserting a
> patch to measure the timings of each test/cycle. Additionally, I could
> try packaging some of the versions between 0.88 and 0.98 to identify
> the exact change that could be to blame. However, both of these seem
> overkill, given the backlog of patches/issues we have left to get
> through, and the manpower we currently have to work with.
>
> Would any of that be helpful?

The problem described by #70663 has now been fixed on master through the
changes in #70693.

The general point I was making though is that if we can improve tooling
and processes so that problems are spotted before they reach master,
then releasing should be easier.

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

Re: Scheduling a new release?

[Andreas Enge]

Am Tue, May 14, 2024 at 11:41:26AM +0200 schrieb Ludovic Courtès:
> As discussed at the 2023 Guix Days (!), we could follow a model similar
> to that of NixOS: form a release team (~4 people) dedicated to keeping
> track of issues in particular wrt. the installer, and committed to
> publishing a release within 4–6 months. (I think several people actually
> volunteered back in Feb. 2023. :-))

That is a good approach, of course.

The two things I think should happen before a release is merging
core-updates, and making a rebuild round (or several rounds? I am unsure
whether it is safe to do everything at once) ungrafting everything.
Plus testing the installer etc.

Andreas

Re: bug#70662: Problems building nss@3.98.0

[Maxim Cournoyer]

Hi,

Christina O'Donnell <cdo@mutix.org> writes:

> Hi,
>
> On 08/05/2024 14:01, Christopher Baines wrote:
>> I think it would be nice to have a new release, and indeed release more
>> often, I think the way to get there is for less things to be broken
>> between releases, such that releasing takes less effort in terms of
>> testing and fixing things.
>>
>> To give some specific issues, I've run up against the recent issues with
>> nss [1][2] and I don't think we could release with the nss package as is
>> currently.
>>
>> 1: https://issues.guix.gnu.org/70662
>> 2: https://issues.guix.gnu.org/70663
>
> I can fix these by disabling tests, but I would prefer if someone with
> more experience packaging for guix could make a decision on
> it. Otherwise, I don't have any problem reducing the number of tests
> and disabling all tests on PowerPC at least.
>
> I could also do some analysis if it was deemed necessary, inserting a
> patch to measure the timings of each test/cycle. Additionally, I could
> try packaging some of the versions between 0.88 and 0.98 to identify
> the exact change that could be to blame. However, both of these seem
> overkill, given the backlog of patches/issues we have left to get
> through, and the manpower we currently have to work with.
>
> Would any of that be helpful?

I just encountered the following single test failure building on
powerpc64le:

--8<---------------cut here---------------start------------->8---
time certutil -K -d /tmp/guix-build-nss-3.99.0.drv-0/nss-3.99/tests_results/security/localhost.1/bigdir -f ../tests.pw
------------- time ----------------------
real 10.32 user 10.25 sys 0.07
10 seconds
dbtests.sh: #27: certutil dump keys with explicit default trust flags  - FAILED
--8<---------------cut here---------------end--------------->8---

with the summary:

--8<---------------cut here---------------start------------->8---
SUMMARY:
========
NSS variables:
--------------
HOST=localhost
DOMSUF=localdomain
BUILD_OPT=
USE_X32=
USE_64=1
NSS_CYCLES=""
NSS_TESTS=""
NSS_SSL_TESTS="crl iopr policy normal_normal"
NSS_SSL_RUN="cov auth stapling signed_cert_timestamps scheme"
NSS_AIA_PATH=
NSS_AIA_HTTP=
NSS_AIA_OCSP=
IOPR_HOSTADDR_LIST=
PKITS_DATA=
NSS_DISABLE_HW_AES=
NSS_DISABLE_HW_SHA1=
NSS_DISABLE_HW_SHA2=
NSS_DISABLE_PCLMUL=
NSS_DISABLE_AVX=
NSS_DISABLE_ARM_NEON=
NSS_DISABLE_SSSE3=

Tests summary:
--------------
Passed:             79016
Failed:             1
Failed with core:   0
ASan failures:      0
Unknown status:     2
TinderboxPrint:Unknown: 2

error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "faketime" arguments: ("2024-01-23" "./nss/tests/all.sh") exit-status: 1 term-signal: #f stop-signal: #f> 
phase `check' failed after 36124.0 seconds
command "faketime" "2024-01-23" "./nss/tests/all.sh" failed with status 1
builder for `/gnu/store/q3cqzzd4fg384lfmk91gd6higsyhs1nq-nss-3.99.0.drv' failed with exit code 1
@ build-failed /gnu/store/q3cqzzd4fg384lfmk91gd6higsyhs1nq-nss-3.99.0.drv - 1 builder for `/gnu/store/q3cqzzd4fg384lfmk91gd6higsyhs1nq-nss-3.99.0.drv' failed with exit code 1
--8<---------------cut here---------------end--------------->8---

So I'm not sure why, but the 'certutil dump keys with explicit default
trust flags' fails on powerpc64le and should probably be disabled.
Also, 36124 s, ouch!  #70950 should help for that.

-- 
Thanks,
Maxim