Revision as of 11:52, 4 April 2020

In-person meeting cancelled due to global pandemic.

Sprint Schedule

April 4/5, 2019

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

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)

[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)

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)

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)

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

TODO

@@ Line 12: / Line 12: @@
 * 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)
-* Should we phase out the Kolab resource in favor of IMAP+DAV, and if so, how can we do that practically? (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)