The KDE PIM spring sprint was held in Toulouse, France in March this year in Makina Corpus offices.
The sprint was very important, because the team needed to decide how to continue from the current situation. At the previous sprint in Munich in November when Christian Mollekopf and Aaron Seigo introduced their new concept for the next version of Akonadi it was decided to refocus all the efforts on working on that, which meant switching to maintenance mode of the Kontact Suite for a very long time and then coming back with a "big boom". In Toulouse this plan was re-evaluated and decided that it is not working for the team and that it will be much better for the project as well as the users if they continue active development of Kontact Suite instead of focusing exclusively on the “next big thing” and take the one-step-at-the-time approach.
The result was that the team re-focused on releasing the Frameworks 5 based Kontact Suite in August as part of KDE Applications 15.08. After that they will be fixing bugs and further stabilizing by improving the current code and adding new features as normal. At the same time they will be preparing the code base for migration to the new major version with the Akonadi 2 backend. So instead of one “big boom” of Akonadi, which Christian will be working on in the meantime, this approach ensures that when they finally do the switch when the code base is ready for it. With that approach the disruption to user experience will be minimal, while allowing for active development of the project. In other words a WIN-WIN-WIN situation for users, devs and the KDE PIM project.
Another discussion we had was closely related to the 15.08 release. The Kontact Suite is a very huge code base but the active development team is very small. Even with the incredible Laurent Montel on their side it’s still not enough to keep actively maintaining all of the suite. So they had to make a tough decision and abandon some parts of the KDE PIM project, at least until new maintainers step up. Some of it will only move to Extragear and will live their own lives there. What they released as part of KDE Applications 15.08 is what is called KDE PIM Core and it consists of the core PIM applications: KMail, KOrganizer, KAddressbook, Kleopatra, KNotes and Kontact. If your favorite PIM application is not in the list you can volunteer as a maintainer and help us make it part of the core release again. We believe that in this case quality is more important than quantity and this is the trade-off that will allow them to make the next release of the Kontact Suite the best one to date.
Thanks to hard work of Christian Mollekopf and Sandro Knauß most of the changes they did for Kolab have been upstreamed during the sprint. There are some very nice optimizations and performance improvements for Akonadi included, among other things. So the current releases of KDE Applications 15.08 have a really shiny Kontact Suite.
Vishesh Handa also brought up the topic of the bug count situation. They all realized the sad state of the Kontact Suite bugs and talked a bit about re-organizing and cleaning up the bug tracker. The clean up part has already begun as Laurent with Vishesh have mass-closed over 850 old KMail 1 bugs during the sprint to make it at least a little easier to get through the rest. Regarding the re-organization a short summary would be that we want to remove Bugzilla components and close bugs for the application they decided to discontinue and maybe do a few more clean up rounds for the existing bugs.
Last but not least, Franck Arrecto, Remi and Kevin Ottens have been working on Zanshin and are aiming at polishing for its next release. It comes with a lots of tests, some of them might become tests for Akonadi itself after discussing it with Dan Vratil.
Huge thank you to Franck Arrecot and Kevin Ottens for taking care of the team and securing the venue for the sprint! All in all it was a great sprint and they are happy to say that they are back on track to dominate the world of Personal Information Management.
Comments:
GMail integration - AnonDave - 2015-10-12
<p>Any news on gmail integration mentioned here?</p><p>http://www.dvratil.cz/2014/07/no-gmail-integration-in-4-14-after-all/</p>
KDE Pim and Akonadi cal/card dav conflict resolution? - Luis - 2015-10-13
<p><span style="font-size: small;">Hey, is there any progress on conflict resolution implementations while using caldav/carddav? It seems that akonadi just enters a failed state and stops synchronizing when the first conflict happens, with no way to make it sync again...</span></p>
Re: GMail integration - dvratil - 2015-10-14
No news regarding improved GMail integration, sorry. I want it to happen eventually, but right now we need to focus on more important tasks in PIM.
maintenance and next - aseigo - 2015-10-19
'it was decided to refocus all the efforts on working on that, which meant switching to maintenance mode of the Kontact Suite for a very long time and then coming back with a "big boom"'
I don't think this was actually decided at the sprint in Munich, but it was certainly proposed as a possible way forward. There was still much up in the air after that sprint, as Akonadi Next was still embryonic at that point and the best way to move Kontact forward was still to be measured. The discussion was therefore taken into future sprints such as this one in Tolouse and this year's Akademy. In any case ...
As can be seen in this article, Kontact has essentially been put into a form of maintenance, to the pont that components are being retired wholesale due to not having active developers for them. So I don't think the decision to release Kontact 5.x as stable has achieved the desired result of giving people a Kontact that was being "actively developed".
The challenge now is that Kontact 5.x, using the current Akonadi, will need to be supported for some time, and when an Akonadi Next using Kontact is released that will then need to also be supported along with a migration path. As for the 4.x version of Kontact, there are companies that I know of who are only now moving to that (yes, were still using the 3.5.x version!), so that also requires maintenance for years to come. It is very hard to attract new developers to such a scenario. For a project with sparse developer resources, spreading out like this seems questionable.
Complicating matters is that there has been no measurement of the expected costs involved in "preparing the code base for migration to the [..] Akonadi 2". It is hard to understand how any decisions can be made without knowing that. Indeed, as long as that is an unknown, it is very tempting to not make any clear decision and just continue moving in the path of least resistance which is to maintain what is there on whatever libraries (e.g. Frameworks 5) the developers have installed on their systems.
So back to what the proposal made in Munich was ... the proposal was to maintain the 4.x version, using current Akonadi, while working on the Frameworks 5 version which would target Akonadi Next. That 5.x work could (probably: should) be done one piece at a time, during which time it would get frequent, regular non-production releases for those wanting to develop and help test progress. There would be no commitment to stability or long term support of these releases until the migration to Akonadi Next was sufficient to be usable day-to-day. This seemed to fit the available human resources while keeping a stable (albeit KDE libs 4.x based) product for users. It also would create the possibilty of lowering the barrier to entry: maintaining and migrating a stable Kontact product in-place requires extensive knowledge of the current codebase and a lot of care, so the bar is pretty high there. I also fear a repeat of the "KMail is ported to Akonadi, but KAddressbook isn't, so Kontact doesn't actually work seamlessly together right now ... " type fiasco that hurt in early Kontact 4.x releases.
I honestly have zero idea how the team plans on accomplishing the feat of "one step at a time" porting in-place while maintaing stable releases. With enough developer resources, it could possibly be done, but as noted in the article, KDE PIM is lacking exactly that. My expectation is that Kontact 5.x will continue to use Akonadi in its current form indefinitely, and the maintenance burdon will soak up the bulk of available resources.
It seems, based on discussions I have had with various people, that the decision was made largely in response to pressure, both from within and from outside the PIM team, to release a Frameworks 5 based Kontact for the purpose of having a Frameworks 5 based Kontact. A significant motivating factor seems to have been retaining the current user base that has or is migrating to a Frameworks 5 based desktop environment. Personally, I wish the focus would be more on what is best for Kontact itself with an eye to expanding its desirability to users on all desktop environments / OSes, particularly since the 4.x and 5.x KDE libraries can be co-installed on a system.
