Revision as of 12:16, 4 April 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.

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

@@ Line 47: / Line 47: @@
 ** 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.
 =Attendance=