Hey, I think it's been quite a while since sending out an update on QA stuff that I'm working on, the last update to guix-devel looks to be back in December [1]. 1: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00093.html Since then quite a lot of stuff has happened, including meeting people in Brussels again which was great. # Infra stuff There's now a proper system service [2] for the qa-frontpage running on bayfront. 2: https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=8c17ac564447aa5448fc6eca40001c5b68c17d61 The Git repository is now on Savannah [3] allowing other committers to push changes. 3: https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/ I've also spent some time fixing and improving the data.qa.guix.gnu.org upkeep stuff, as it needs to regularly clear out the unused data. At some point in the near future, I'd like to not be solely responsible for the financial and administrative part of keeping data.qa.guix.gnu.org (plus Patchwork and Gitolite) running. There's a thread about this on the guix-sysadmin mailing list, but if anyone has any thoughts, please let me know. # Data service The data service provides much of the data to make qa.guix.gnu.org work, and I've been trying to improve it in a few areas recently. I've added something [4] in which seems to make computing the system test derivations happen faster. I'm not quite sure of the impact, but the main benefit at the moment is that revisions are being processed more quickly, which reduces the time to give feedback on patches and branches. 4: https://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=bf41c6ebb1c12ec15ee77e727a1ae0d7a1466aef I've also done another deep dive in to PostgreSQL query performance to get the blocking-builds page working. This page still needs a bit more work, as I'm unsure about some of the data it's giving back, and currently it's difficult to see what builds are blocked and why, but I'm hoping that this'll be helpful when it comes to branches like core-updates. Here's the page for armhf-linux builds for a recent core-updates revision [5]. 5: https://data.qa.guix.gnu.org/revision/62ff0b90864c8a4484aa2f14856ff33d05e00b0c/blocking-builds?system=armhf-linux&target=none&limit_results=50 One issue I made surprisingly fast progress on after the Guix Days was the interaction of grafting and the channel instance derivations, there's a patch series needing a second round of review here [6]. Currently data.qa.guix.gnu.org often can't compute the channel instances for all systems, and these changes should resolve that. 6: https://issues.guix.gnu.org/61363 # QA Frontpage I've made various small changes to try and make things faster and take less memory. The memory usage is still an issue, but things like the branch pages now work which is good. Substitute availability information is also now shown on the pages for branches. # Next steps Since starting to build core-updates and increasing the number of patch series tested (both in terms of number and increasing the build limit), the bordeaux build farm has been running flat out. That's good, but it's now even more important to tune how builds are prioritised to try and make better use of the build resources. I think the missing data to do that is some good picture of what's recently been built, currently being built, and queued up. This information is in the build coordinator, so it just needs exposing somewhere so people can easily see it. Another key area for improvement is trying to make any feedback given clearer and more actionable. For example, currently for patches and branches, more failing builds for a particular system will be highlighted, but there's no easy way of just seeing the things that were failing to build that weren't before. It would be good to know what other people submitting or reviewing patches would benefit from though, what things would be most helpful? As always, if you have any comments or questions, just let me know! Thanks, Chris