We managed to get into the 15.08 release \o/
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:
Volker also proposed:
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:
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.
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.
Based on this the team eventually derived the list of core values that represent the vision:
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.