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

• 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?
  • We need an enabled property per calendar
  • How do we do lazy population in calendar plugins?

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