The Sprint series comes out every 3 weeks or so. Focus will be on the apps I maintain (Calendar, To Do, and Settings), but it may also include other applications that I contribute to.
GNOME Calendar saw a moderately busy spring, mostly focused on landing a few outstanding 3.32 merge requests (thanks Michael Catanzaro for writing and landing them!), and lots of regressions (#426, #432).
A few crashers were solved (#419, #455), and important regressions too (#383, #451). Given that the current sprint’s Calendar week is also before 3.34.1, I expect a few more inconsistencies to be ironed out, and an overall stable GNOME Calendar as a result.
I am positively surprised to see how much was achieved on GNOME To Do during the past sprint! The difference is massive; using GNOME To Do from the Nightly Flatpak is much more pleasant now. In fact, I’ve been using it for the past few weeks without any major problem!
Overall, a few nice cleanups landed (#282), To Do was adapted to the latest GTK4 API changes (#276), and a nasty crasher was uncovered (#279).
But to me, the spotlight goes to the micro annoyances that were smashed during this sprint. For example, GNOME To Do does not re-download all your task lists every time you focus the window anymore (#275). Various small problems in the Today, Next 7 Days, and All Tasks panels were fixed (#277, #278, #280, #281, #283).
I’m considering doing a GNOME To Do 3.96 alpha release during the next sprints, but the GNOME To Do Team (i.e. me and 5% of Tobias) needs to double-check if the current set of features is enough, and what would be a good way to handle the release (“closed” alpha? what kind of feedback do we want? how can we retrieve this feedback? would it be better if we have user testing sessions rather than open feedback?)
Unfortunately, this was not a productive sprint for GNOME Settings in terms of expectations. I expected to work on the most recent design updates for Settings (#296), but most of my time was spent reviewing merge requests (#622, #690). This heavily severed design & development coordination
However, in the middle of those merge requests, a few niceties landed, such as the improved Wi-Fi hotspot creating dialog (#669 – thanks Sadiq and Purism!) so it wasn’t a feature-absent cycle.
We are in the period of the release cycle that is between 3.34.0 and 3.34.1. Usually, this is when the majority of bugs reported by downstreams and individuals is fixed.
I tried to work on new features for Settings, but it didn’t work out as I expected. During this period, I ended up working and reviewing bugs much more than I thought it would be necessary, and the time to work on new features was severely reduced.
This is the biggest lesson learned this spring: focus on stability between the X.90 and (X+1).1 period, it’s the best time for that. New features that will already wait for the next release can wait an extra month.
6 thoughts on “Sprint 5: stability, stability, stability”
Regarding the alpha release, it sounds a lot like what you need is telemetry that the app is sending to some GNOME server (ofc this should be displayed to the user on first run with opt-out functionality).
What kind of telemetry? Well, better not reinvent the wheel. Prometheus, a very good FOSS timeseries database, defines four data types. It’s a simple model, yet very flexible. Together with Prometheus Query Language (promql) and Grafana you can gain good insight in your application while it runs anywhere.
The challenge lies in the data flow. Usually Prometheus scrapes HTTP endpoints exposing app-local metrics. With desktop app the flow will need to be reversed, with the app pushing to some intermediate which Prometheus can scrape. Or hack on Prometheus. Or look for existing solutions. I didn’t yet have the need for pushing.
It sure sounds like a lot of fun (I like this backend stuff). If this could also be a way for me to start contributing to GNOME, I’d eagerly jump on.
BTW, even with the old “bug-ridden” release I already enjoy the To Do app very much!
Thanks for the offer, but I have no intention to add telemetry to GNOME To Do. I would be interested, however, in reviewing other contributions from you! 🙂
A while back there was a post on usability tests, which I found quite thorough and it’s already tailored to GNOME. Besides that, surveys also seem like a good idea. I wouldn’t go with either usability test or survey; both are good ideas. Though maybe usability test delivers actionable results more quickly.
Well, contributing to GNOME is a long time goal that always falls short because I went the web path. Telemetry seemed like a good idea to jump in because it’s familiar terrain. Not that I would balk at the challenge, it’s the energy required. Sébastien Wilmet understands it:
I’d say working in familiar terrain for GNOME would be alright energy wise.
I am really enjoying reading theses sprints. I feel it’s a great way to get people more engaged and make the whole development process of gnome, thanks for continuing this Georges.