Akademy 2015 PIM BoF Notes - 2015-07-28

Attendees

Dan Vratil
Christian Mollekopf
Kevin Ottens
Ingo Klöcker
Sandro Knauss
Volker Krause
Franck Arrecot
Sebastien Renard
2 people from the LiMux team

KDE PIM release

We managed to get into the 15.08 release \o/

The Way Forward

It is clear that the current state of KDE PIM codebase is not as good as we would like especially given the manpower available and that we need to do something about it.

It is necessary that we look at where we are now, where we want to go and how do we get there, for which we need a vision (see below) and some guidelines on how to ensure and improve the quality of the code base.

Christian proposed the following guidelines for the codebase:

Each module has at least rudimentary tests that can then be extended
- Tests need to be deterministic, no random timeouts to check if something already happened, only QTRY_VERIFY and alike is allowed.
Clear layering. No depending on Akonadi from everywhere.
Each module comes with a clear set of justified dependencies.
Commented out code is only allowed in conjunction with a task in Phabricator. No dead/commented code.
Each module requires a clear interface that allows the module internals to be replaced eventually.
UI modules need to be separated from non-UI parts. All UI parts need to be eventually replaceable by QML equivalents.
No dialogs in non-UI parts.
New features are only added after having been selected from the roadmap for a future release

Volker also proposed:

If you deprecate stuff, you have to port all uses in KDE PIM away from that.
Discourage dumping ground library.

Volker asked how are we going to manage the feature roadmap. Proposed solution was to use Phabricator's tasks for that. It is useful for documenting which features we have, both so that developers can keep track of what others are working on as well as generating proper changelogs. We obviously cannot force this on all developers, but it is still possible for the roadmap to be maintained by other team members. Finally the roadmap would allow us to discuss features before they go in in order to maintain the core product.

Christian also presented a gameplan in order to get to Akonadi Next:

KDEPIM is redesigned from ground up. We create a design and then fill in the required pieces.
A pragmatic approach to come to target ASAP. We honor the requirements, but don't rewrite just to make it nicer.
Only a minimal set of features in the beginning. We build a clean core and readd features from there.
Removed features are documented in Phabricator and categorized as "REQUIRED", "WISHLIST" or "NOT WANTED".

Christian tried to estimate KAddressBook cost for refactor or rewrite as an example, however it was argued that that is not enough information to decide on approach. Others pointed out that KAdressBook is also not representative sample of KDE PIM code base as it has been almost completely rewritten during KDE4/Akonadi port and is not nearly as complex as KOrganizer or KMail. Christian pointed out that this was an example for the estimation process, not for the estimation result.

For comparison, Akonadi port took 3 years to do and many more years to stabilize, Kontact mobile too 800 full-time days. With current contributor base it is not possible to go for a full rewrite as that would take 2-3 years, even assuming Christian and Sandro could work on it full time the whole time.

Most people thought that the best and only really affordable approach is to do slow incremental changes, even though the entire process might take longer. It would allow us to ship new features and changes to users every 4 months, getting us gradually closer and closer to the overall Akonadi Next design and making the final "leap" to it much easier and less costly and dangerous. It will also prevent developer burnout while working on separate branches for very long period of time. Finally it is really also the only way to ensure continuous development of current Akonadi and KDE PIM, which is necessary if we want to keep and extend the user base.

It will also make it easier to attract more developers this way, as they can see their fixes getting to users, unlike with a full rewrite, where it would take another 3 to 4 years to actually ship the code. Christian pointed out that a non-incremental approach could potentially be more interesting for newcomers because they have to deal with less legacy code.

Vision

In order to get where we need to get, we need to have a vision. Thanks to Kevin Ottens we were able to identify the important values of the KDE PIM project, it's core features that should be preserved. As a result we also have a high-level overview of things and features that are not necessarily important to the product and could be considered for removal to simplify the codebase and decrease the maintenance burden.

The team identified the "core" parts of the product: KMail, KAddressBook, KOrganizer, task manager and note manager, the later two being handled by Zanshin. It was proposed not to actually mentioned real application names, but instead the use cases. To outline the "core" we not only draw the line around the applications but also within each application to identify features that need to be part of the core (like crypto) and features that can be considered "addons" and implemented as plugins.

[Insert picture of the feature tree here]

Based on this the team eventually derived the list of core values that represent the vision:

free software
reliable/scalable
elegant user experience / usability
multi-platform
privacy by default
encouraging open standards
offline support
improving user productivity
well-integrated experience
email, calendaring, tasks, note taking, contact management

Dan Vratil will talk to Thomas Pfeiffer or Andrew Lake and ask them to help us turn the bullet points into an actual text.

With the vision defined we could continue to discuss the route how to get to Akonadi Next. As explained above, it is necessary to cut features in order to reduce the codebase into a maintainable size, however this decision needs to be made by the whole team. Daniel will collect input from Laurent on this.

Obviously the team need to stick to good coding practices, look at the current codebase and evaluate it. Christian will propose a list of features that should be "core", addons or removed completely.

Dan and Christian will meet again in September in Randa, where they will look on the list and try to draft architectural decisions based on that and make some decisions.