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.
Calendar
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.
To Do
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?)
Settings
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.
Retrospective
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.
Leave a Reply