Attending the yearly KDE Pim Sprint in April in Toulouse was nice. For me it is often leaving a cold rainy Germany and arriving warm, almost summer weather with a lot of sun. This time the weather in Germany was also sunny and warm when I left, but spring's always further in Toulouse. As only around ten people attended the sprint, it was also a time to get to know the people behind the nicknames. Unfortunately there were no new faces this time, but a new contributor joined the Pim team and attended remotely.
As the trains from Germany to Toulouse take some time, for me, the sprint normally starts with entering the train and having time to hack. The first things I looked at, were some cleanups in the dependency chain in KDE Pim, by moving stuff around.
Reaching Toulouse, David and I started to dig into the problem, that sometimes connections to remote servers stall and nothing goes back and forth without an error being triggered. This issue is only visible if the internet connection is not stable, like a connection while riding the train. Yes, it's a good thing that sometime developers have to face real world, to be able to reproduce bugs. To solve these issues we first had to reproduce them, which leads into the problem of how to reproduce an unstable internet connection. It took a while before we had a setup running to reproduce the issue and after a lot of trial and error, we finally managed to fix the issues we'd found.
Email security is a big issue in KDE Pim and KDE made privacy a goal for the next years. As a whole team we discussed what we can improve in the context of KDE Pim and added some topics in Phabricator, what we want to improve T7050 (have a look at the subtasks). As the sprint was before the public announcement of EFail, but we were already informed about this, we could discuss the outcome of EFail and add some improvements. You can read about the current situation of KMail and EFail on dot.kde.org.
We also looked at how we can support emails using Memory Hole. Memory Hole is a way to also encrypt headers in emails. The discussion has started but I havn't found time to implement it yet, see T742 for more information.
Together with Daniel I had a discussion on how to improve the way to debug issues with Akonadi. Currently it is very hard to debug issues with Akonadi, but we already have a tool for debugging: Akonadi Console.
But still Akonadi Console has some issues, as you can't keep it running for days to wait for issues that happen very rarely. This is because it slows down your computer too much after some time. The Debug view shows the transmitted data between Akonadi and all clients. To make it possible to keep Debug running for days, we had to refactor the Debug view to use a TableView to display the logs instead of a simple TextView. A TableView scales much better with a big amount of data. We can now keep it running and save those logs and scan for interesting entries by hand later. Another advantage is that we can now change the filter settings while logging and have the ability to add more logic to find the interesting entries. Together with this switch we replaced the hand written Debug log protocol with JSON. This also removed the need to implement a separate parser for the protocol and you can use QJson directly for further filtering.
Another issue, that we've been having for a long time, was that you needed to restart Akonadi to view the logs, as those are only printed in the console you start Akonadi from and if you had disabled logging, then no logs were available. Also, you had to enable the correct categories to view a specific issue. Daniel used the time of the sprint to implement another tab in Akonadi Console to display those logs. So you don't need to restart Akonadi anymore to view the logs, which is a great step forward to debugging more easily.
Thanks to KDE e.V. for supporting me in joining the sprint.