Sprints/PIM/2020

In-person meeting cancelled due to global pandemic.

Sprint Schedule

April 4/5, 2019

Agenda

Proposed topics, roughly grouped by scope. Feel free to extend and regroup this.

General project stuff

• How can we get all of kde/pim migrated to gitlab? (Allen)
• [DONE] Did the bi-monthly summary blog approach we tried over the last year work out and should we continue with this? (Volker)
• [DONE] Should we phase out the Kolab resource in favor of IMAP+DAV, and if so, how can we do that practically? (Volker)
• [DONE] Progress of frameworkification, is KDAV ready to go, which framework is next after that? (Volker)

KF6

• [DONE] The use of KParts in kdepim (with some KF6 changes in mind) (David)
• KF6/Qt6: anything problematic or anything larger to do in PIM or "our" frameworks? The Kross usage in accountwizard comes to mind. (Volker)

Larger reviews

• [DONE] Review and finalize the API of Nicolas' platform calendar access abstraction - https://phabricator.kde.org/D24443. (Volker)
• Review the KUserFeedback usage for 20.04 (Volker)

Specific bugs

• Deleting multiple emails really fast leads to some of them being stuck in "about to be deleted" state (David)
• Deleting emails while the inbox is sync'ed leads to emails reappearing before disappearing again (David)
• Finding out why kmail often shows "This message is encrypted" erroneously (David)
• Finding out why contact completion/search doesn't find some contacts (David)
• KOrganizer: can't modify item immediately after creating it (bug 407965), seems fixed already (https://phabricator.kde.org/D16917) (David)

Notes

• KDAV: David and ervin agree with the move, ervin will do another API review
• Frameworkification:
  • kgapi - this is used externally AFAIK, so it might be worth moving? Dan?
  • the entire set of email libs - lots of work, does anyone externally need those right now?
• KParts usage:
  • dfaure: lxr reminded me that kdepim uses KParts for embedding into kontact. I just had a deeper look, and it actually makes sense (KParts is basically a plugin mechanism with a widget() method, a XMLGuiClient+actionCollection for actions, and a KAboutData, all of which make sense in kontact).
  • The plan however is to port from KParts::ReadOnlyPart to KParts::Part and to move parts to kf5/parts/ subdir so that the new KParts::PartLoader can be used.
• Bi-monthly summary blog:
  • works, let's keep doing this
  • let's not increase the frequency, lacking the bandwidth for this
  • do we have more volunteers to help with this? Sandro volunteered.
• Kolab resource
  • we do have a similar problem with Google calendar/addressbook resources being merged into one, so a generic approach is needed anyway
  • migration approach: automatically migrate configuration and re-create the new resources, but do not migrate data and rely on resyncing instead.
  • akonadi_migration_agent exists for this, with UI, so we can probably integrate it there
• Calendar plugins
  • Flat list, one-level grouped list or full tree?
    • Flat list is not enough either way
    • Only Kolab uses a full tree, so a one-level tree is enough from an Akonadi POV
    • Go for the single level list by adding a CalendarGroup property to CalendarEntry.
  • Should CalendarEntry be folded into Calendar? -> yes
  • We do NOT need an enabled property per calendar, this is handled per application, not globally.
  • How do we do lazy population in calendar plugins?
    • Add a (pseudo-)virtual open() method to Calendar, to trigger (async) population. This completes the existing lifecycle methods (close, reload, save, etc), and we consider API symmetry to outweigh the reasoning for moving sync() to CalendarPlugin.

Attendance

• Franck Arrecot
• Laurent Montel
• Kévin Ottens
• David Faure
• Dan Vratil
• Andre Heinecke
• Sandro Knauss
• Volker Krause
• Ingo Klöcker

Report

TODO

Previous Meeting

PIM Sprint 2019, 5-7 April, Toulouse, France