What happened in Toulouse?

Standard

… a KDE PIM sprint happened in Toulouse! And what happened during that sprint? Well, read this wholly incomplete report!

Let’s start with the most important part: we decided what to do next! On the last PIM sprint in Munich in November when Christian and Aaron introduced their new concept for next version of Akonadi, we decided to refocus all our efforts on working on that which meant switching to maintenance mode of KDE PIM for a very long time and then coming back with a big boom. In Toulouse we discussed this plan again and decided that it will be much better for the project and for the users as well if we continue active development of KDE PIM instead of focusing exclusively on the “next big thing” and take the one-step-at-the-time approach. So what does that mean?

We will aim towards releasing KF5-based KDE PIM in August as part of KDE Applications 15.08. After that we will be working on fixing bugs, improving the current code and adding new features like normally, while at the same time preparing the code base for migration to Akonadi 2 (currently we call it Akonadi Next but I think eventually it will become “2”). I will probably write a separate technical blog post on what those “preparations” mean. In the meantime Christian will be working from the other side on Akonadi 2 and eventually both projects should meet “in the middle”, where we simply swap the Akonadi 1 backend with the Akonadi 2 backend and ship next version. So instead of one “big boom” release where we would switch to Qt 5 and Akonadi 2 at the same time we do it step-by-step, causing as little disruption to user experience as possible and allowing for active development of the project. In other words WIN-WIN-WIN situation for users, devs and the KDE PIM project.

I’m currently running the entire KDE PIM from git master (so KF5-based) and I must say that everything works very well so far. There are some regression against the KDE 4 version but nothing we couldn’t handle. If you like to use bleeding-edge versions of PIM feel free to update and help us finding (and fixing) regressions (just be careful not to bleed to death ;-)).

Another discussion we had is closely related to the 15.08 release. KDE PIM is a very huge code base, but the active development team is very small. Even with the incredible Laurent Montel on our side it’s still not enough to keep actively maintaining all of the KDE PIM (yes, it’s THAT huge ;-)). So we had to make a tough decision: some parts of KDE PIM have to die, at least until a new maintainer steps up, and some will move to extragear and will live their own lives there. What we release as part of KDE Applications 15.08 I call KDE PIM Core and it consists of the core PIM applications: KMail, KOrganizer, KAddressbook, Kleopatra, KNotes and Kontact. If your favorite PIM app is not in the list you can volunteer as a maintainer and help us make it part of the core again. We believe that in this case quality is more important than quantity and this is the trade-off that will allow us to make the next release of PIM the best one to date ;-).

Still related to the release is also reorganization of our repos, as we have some more splitting and indeed some merging ahead of us but we’ll post an announcement once everything is discussed and agreed upon.

Thanks to Christian’s hard work most of the changes that Kolab did in their fork of KDE PIM has been upstreamed during the sprint. There are some very nice optimizations and performance improvements for Akonadi included (among other things), so indeed the next release will be a really shiny one and there’s a lot to look forward to.

Vishesh brought up the topic of our bug count situation. We all realize the sad state of our PIM bugs and we talked a bit about re-organizing and cleaning up our 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 I still have to send a mail about it but a short summary would be that we want to remove bugzilla components and close bugs for the apps we decided to discontinue and maybe do a few more clean up rounds for the existing bugs.

I’m sure I’ve forgotten something because much more happened during the sprint but let’s just say I’m leaving some topics for others to blog about ;-).

Huge thank you to Franck Arrecot and Kevin Ottens for taking care of us and securing the venue for the sprint! All in all it was a great sprint and I’m happy to say that we are back on track to dominate the world of PIM.

The only disappointment of the entire sprint was my failure to acquire a French beer. I managed to try Belgian, Spanish, Mexican and Argentinian beer but they did not serve any French beer anywhere. Either there’s no such thing or it must be really bad…:-)

KDE PIM Sprint in Toulouse

We had a great dinner with the local KDE people on Saturday. Also a prove that Laurent is a real person :-D

 

18 thoughts on “What happened in Toulouse?

  1. Konrad

    Thank you for the interessting post! But does it mean that KJots will be discontinued and there will be no way to sync with Kolab notes?

    • Sinclair

      from reading on support forums like forum.kde.org I have a feeling that KJots is not actively maintained any longer and you are likely better off trying to migrate to something like KNotes.

      I prefer Basket myself, which has been unmaintained for quite some time but I have read that it is now being ported to K5

  2. Emil Sedgh

    This is great news. I can finally ditch KDE SC 4 and move to Plasma 2 on August.
    Thanks a lot for the great work on KDE PIM.

    • You can move to Plasma 5 already now and use the KDE 4 version of KDE PIM, they work just fine and thanks to breeze-kde4 they will look like “native” KF5 applications :)

      • Emil Sedgh

        Oh yes I know. I have a recent build of KF5, workspaces and applications and I give it a try every couple of weeks.

        Its a state of mind, knowing KMail sitting there isn’t native :p

        Except for the joking, not all features are ported yet and not all features work fine in this combination. For example I cannot search my emails using KRunner.

        Since SC 4 is perfect for me, I’ll just wait with patience ;)

  3. Rainer Dorsch

    Thanks for that post and congratulations and I am glad, that you found the win-win-win situation.

  4. christoph

    Finally someone has the guts!

    I have read it everywhere, but no proof was given. IRC conversations do not count, those can be faked. Blog posts do not count either. But this blog post reveals it with a proof in form of a real photo ;)

  5. Kevin Krammer

    I am very happy to hear that the decision to be the only framework which would not keep compatibility with old clients of its service has been revised.

    Allowing KF5 based and kdelibs based applications to be used in parallel is a core goal of the whole Frameworks 5 effort.
    Not having that between KF5 and kdepimlibs would have been really bad.

    I know that you were really looking forward to having only to deal with a new, streamlined communication protocol between server and clients, but dropping the established protocol instead of some gradual phasing out is just never a viable solution.

    Again, very happy user and user supporter here :-)

  6. Sinclair

    Thanks for the heads-up! And I am pleased to hear you are opting for a, hopefully, smooth upgrade path as we KDE-PIM users have had our fair share of “bumpy ride” upgrades.

    Is Telepathy its own entity then and no longer KDEPIM? I know it is actively developed but as I recall used to be a part of KDEPIM concept

    • KTp itself was never part of KDE PIM. They have the kpeople library, which was in PIM because of its integration with Akonadi, but they are all now part of KDE Application and were released in 15.04.

  7. Foo

    What about Akregator? Surely, it must be the second most used KDEPIM application behind KMail. What happened to akregator2, etc? Is it really that hard to port it to KF5? It’s not a very complex application, the most annoying thing with it is that the web view uses KHTML which is hopelessly out of date. Akregator with a modern web engine would be awesome (I know the situation in Qt5 with WebKit is not perfect, but it’s still better than KHTML!)

    • KF5-based Akregator will be released from extragear at the same time as KDE Applications, but it won’t see much active maintenance beyond that, unless an active maintainer steps up and starts taking care of maintenance and releases. If that happens we will be more than happy to include it in the PIM core again.

    • Regarding Akregator2 (i.e. Akonadi-based Akregator) the port is basically done, but more work is still needed to finish the Akonadi resource to sync RSS feeds and probably some more polishing of Akregator itself is needed.

      I don’t know what engine the KF5 port is using currently, we could probably try QtWebEngine (chromium-based) if time allows.

  8. Ernesto Manríquez

    Speaking of “KDE PIM core” and the parts of KDE PIM that need to be dropped, please, kill both the KOrganizer Reminder Daemon and KAlarm with fire. They duplicate themselves, and the Reminder Daemon, which was really needed in a world without Akonadi, it’s not needed anymore because it duplicates Akonadi, eats 100 MB of RAM extra, and can be replaced by a small Akonadi notifier daemon that sets a reminder and notifies it through the KDE Notification system, nagging me. KAlarm is the same thing, you can simply replace it with the ability to set arbitrary alarms in KOrganizer and export them as a calendar.

    • Moving the Reminder Daemon into an Agent would not make much difference – the component which consumes the memory is the MemoryCalendar, which holds all the events in memory (calculates recurrences, exceptions and what not). What we really need to do is to optimize the memory consumption of the MemoryCalendar – but that’s very hard work that might not be possible with current Akonadi design.

Comments are closed.