Status update, 15/12/2022

The last update of 2022, and the 14th since I started writing these.

Before we begin it’s vital to check my list of top albums from 2022, which I’m sharing to Mastodon:

• #5 – Fred Thomas – Another Song About Riding The Bus
• #4 – Klawo – Klawo
• #3 – The Slackers – Don’t Let The Sunlight Fool Ya

For #2 and #1 you will have to follow @vladimirchicken@mastodon.art I guess!

I’m commit full time at work to a project, as is normal, and a couple of spare hours a week lets me push forward a few things in GNOME.

(By the way, if you have a few hours to donate towards improving GNOME, Georges has some ideas for you).

I’ve been intermittently looking at OpenQA testing of GNOME since the summer, and I just posted a short progress report about that over on discourse.gnome.org.

I’ve also been looking at search in GNOME since about 2012, and the two things are hopefully about to converge.

When I first started volunteering my time to help maintain the Tracker search engine, CI was a luxury that GNOME couldn’t afford. Testing a patch for Tracker required a maintainer to do the following:

• download it from Bugzilla
• apply it to the local Git tree
• rebuild, which often involved 5+ minutes waiting for Autotools to check if we’d travelled back in time to the 1980’s since the last build
• run the test suite (those bits which worked)
• install and manually test the change

If anything went wrong due to the patch, the maintainer had to reply to the patch author what went wrong, and check back tomorrow to repeat the process. It’s really only due to the dedication of the maintainer team that anything ever got done.

Things have improved dramatically since the project moved to Gitlab, adopted Gitlab CI and resurrected the ‘functional-tests’ test suite which provides a model of the real desktop search process.

The ‘functional-tests’ model is useful but it is just a model, there are many more components involved when you actually start searching in GNOME Shell. The test surface includes: tracker-miner-fs and libtracker-sparql, GNOME Shell, the many search providers, Nautilus, the content apps (Music, Photos, etc), the GNOME platform libraries, the service manager (systemd), right down to the kernel itself. (If you see the background indexer taking more resources than the Shell, the problem lies in part with the kernel’s scheduler wrongly prioritizing background processes).

There are some plans in the air about changing the design and implementation of search in GNOME. This is really exciting to see – I have ideas myself – but the first step should be to better test what we already have.

And so, I recently ran a survey on what people search, and when I next get a little time to spend on GNOME, I hope to start adding some test content and search tests to OpenQA, so we can exercise the whole search stack, and confidently work to make it better.