Sprints/PIM/2020
< Sprints
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?
- Flat list, one-level grouped list or full tree?
Attendance
- Franck Arrecot
- Laurent Montel
- Kévin Ottens
- David Faure
- Dan Vratil
- Andre Heinecke
- Sandro Knauss
- Volker Krause
- Ingo Klöcker
Report
TODO