KDE PIM/Meetings/Randa2015

Randa 2015 Meeting Notes

Attendees

• Christian Mollekopf
• Dan Vratil
• Martin Steigerwald
• Michael Bohlender
• Laurent Montel (input via IRC)
• Sandro Knauss
• Volker Krause

Project Direction

At Akademy this year we defined a vision for the project that was met with positive responses so far. KS did a similar exercise internally, with a largely compatible result.

During this meeting we looked at goals and directions based on the vision. We especially discussed the following options:

• Focus on Kontact and Kontact only (similar to what Krita does very successfully), vs. focusing on KDE as a whole.
• A limited feature set in order to improve polish and maintenance ("Thunderbird-like"), vs. feature-rich applications aimed at "power users".
• Move towards these goals using feature-preserving incremental refactoring steps with continuous releases, vs. a more substantial feature-reducing rework with possibly a longer development cycle.

We agreed that the current Kontact will keep focusing on the feature/power user scenario, and keeps providing infrastructure for integration with all of KDE. Movement forward will happen in incremental steps within the standard four month KDE application release cycle. The other scenario will be served by Kontact Quick (see below).

For all cases we agreed on two primary user groups, Michael will work on creating personas.

• Corporate users with lots of inbound emails and calendar/resource management ("Munich").
• Power users with lots of inbound emails and extensive email automation ("ourselves").

Release and Development Cycles

We discusses the pros and cons of feature-boxed and time-boxed releases. While KS prefers feature or milestone-based development cycles, the rest of the community prefers the established time-based releases that we have been employing in the recent years. We will therefore continue in this manner. KS might do separate LTS branches and releases, which isn't affected by this.

Project Planning

We are very happy with the instant uptake in the recently deployed Phabricator task board. We discussed details regarding our workflow with it, with the following conclusions:

• We will aim to fill Phabricator backlog with everything we want to do or that has to be done (e.g. the KDELibs4Support porting).
• Assigned tasks in backlog indicate that a person wants to work on those, ie. if you also want to work on those coordinate with the assignee.
• Unassigned tasks in the backlog are up for grabs.
• We aim to have at least all tasks for the next release in there, preferably more, to give us a few month forward visibility, and thus everyone to have a chance to coordinate on what will be in the upcoming release.
• KS will add their plans and milestones to the KDE Phabricator as well.
• We will keep completed tasks to the "Done" column of the corresponding release, but keep them open. At the time of the release we will turn this into a changelog and then close all tasks by batch edit.

In order to enable as much as possible KS work to happen upstream (which is in everyone's best interest), we all want to improve coordination, on equal grounds.

KDE PIM and KF5

The lockstep version approach of KF5 is a problem for KS' LTS plans (see frameworks-devel/release-team MLs for details). Keeping dependencies on the minimal required version would be beneficial for this. We will have to see to what extend this will be possible.

We attempt to get the following first batch of PIM libraries into KF5, for the November release:

• kcontacts
• kholidays
• kmime
• syndication

For gpgmepp the GnuPG community is interested in integrating it upstream, next to gpgme itself. We think that's a good idea and would simplify things, the only concern is to keep the CMake-base build system in order be able to support Windows native builds (this is a problem with gpgme). If integrating it upstream turns out infeasible, we will also attempt to move it to KF5.

Kontact Quick

The plans for a QML-based mobile variant of KMail got slightly generalized towards a QML-based variant of Kontact that can cater to the needs of different form factors (phones, tablets, desktop), named "Kontact QUick". This will be build from the ground up, with user-centric design and focusing on use-cases that make sense on these devices.

The backend code will in large parts be shared with Kontact, we will especially look into making the following components usable without a QtWidget dependency:

• kcalcore
• kcontacts
• itip (extracted/rebuild from existing code)
• mailtransport (transport only, not the configuration)
• messageviewer
• messagecomposer
• auto-config (from accountwizard, but not the account model)
• LDAP and address completion (logic, not config)

Experiences from KS Munich Deployment

Sandro presented experiences from the Munich deployment.

• Kiosk conflicts with config files containing Akonadi ids that are local to a user.
• LDAP configuration
  • Munich has a special LDAP setup, so all hardcorded LDAP Filters inside kdepim failes, like person, groups, resourcesearch.
• Running Akonadi with shared home folders.
• Naming consistency between our applications, with legacy applications and Kolab Roundcube.
  • Also a problem with translations.
• Zanshin feels like an alien, because it has an other worklow like the other applications (no save button, moving tasks to tags,...)
• Debugging sync issues, logging/inspections tools for diagnosis.
  • Documentation about diagnostic tools exists in techbase, but nobody knows about it.
• Hardcoded 5 min poll interval minimum is too long for calendar

Random Technical Details

Maildir Optimizations

• Maildir does not correctly extract flags on initial listing, as that code assumes a MIME tree, but we only read the head
  • That's ok, as the indexer eventually takes care of that
• Optimize this to just read the envelope headers directly from the file, bypassing KMime parsers
• Make sure the serializer doesn't emit PLD:HEAD for items with just PLD:ENVELOPE (optionally)

messageviewer

• make html writer write method emit code location

Notes Application

• 15.08 has no way for users to access their notes anymore. Zanshin was supposed to provide that, if it wont be ready for 15.12 we'll bring back KJots.