Hey,

I sent out the last update [1] back near the start of December.

1: https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00021.html

In summary, QA has been not really working since mid December as
data.qa.guix.gnu.org wasn't keeping up with processing revisions for
patches and branches. I was also looking to shutdown
data.qa.guix.gnu.org but this didn't happen, there still seems to be
some interest in managing the infrastructure though the project (and
shutting it down also takes more time and effort than leaving it
running). Things are still running though, and I'm hopeful that QA will
be back processing patches in the next few weeks.

Specifically for the QA frontpage, little has changed in the last
month. I have got around to making a diagram to put QA in context and
it's now included in the README [2]. Let me know if any more diagrams
would be useful as I've now got a process.

2: https://qa.guix.gnu.org/README#orgd169767

For the Guix Data Service, I've put some time in to speeding up the
processing of revisions. I replaced all uses of delete-duplicates with a
sort and pair-fold alternative and parallelised computing the guix
derivations, computing the package derivations and a few other things
that happen through inferiors. This still needs a bit more testing, but
the changes are deployed on data.qa.guix.gnu.org and I think it's sped
up processing individual revisions at least.

Since data.qa.guix.gnu.org had less revisions in the database, I took
advantage of this to do some maintenance and managed to reduce the size
of the database considerably. Hopefully the frequent cleanup tasks will
prevent it from getting this large again.

Finally, I made various small fixes and speedups in the Guix Build
Coordinator. I hopefully mitigated the port encoding issue [3] by
switching from using the display procedure to log to using string->utf8
and put-bytevector. I opened a bug for a Guile segfault I hadn't seen
before [4]. I also hopefully reduced the impact of the build coordinator
stopping listening for connections by checking this internally and
exiting if there's an issue. Unfortunately I've been quite slow in
tracking down and trying to fix or at least mitigate these frequent but
hard to reproduce bugs, but I think I've made some progress recently.

3: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62590
4: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68221

Looking forward, there's still the issue of me hosting various parts of
QA. Andreas has sent a proposal around on this in the last couple of
days though.

There's been some discussion in the past about using the data service to
monitor performance related things, but maybe this is important for just
keeping QA running as well. Failing to spot these issues before they're
introduced can cause significant disruption, so maybe we need the data
service to start monitoring and reporting on how particular performance
characteristics change between revisions so that this can be reported by
QA.

While the bordeaux build farm is still doing well I think, I still
haven't got around to implementing a way of pruning the nars that aren't
for the master branch from being stored indefinitely. I've got some
design ideas, but they need implementing and testing. There's also the
ongoing issue of build hardware for current and up and coming
architectures.

Let me know if you have any comments or questions! I'm also planning to
be at the Guix Days event and FOSDEM in a couple of weeks.

Thanks,

Chris