← Sprints/PIM/2020 You do not have permission to edit this page, for the following reason: The action you have requested is limited to users in one of the groups: Users, Administrators, trusted, KDEDevelopers. You can view and copy the source of this page. 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 === * [DONE] 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 ([https://bugs.kde.org/show_bug.cgi?id=407965 bug 407965]), https://phabricator.kde.org/D16917 didn't fully fix it? Can anyone find a way to reproduce it? (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? *** dvratil: needs porting to KJob (from the custom KJob-like code) and API cleanup, otherwise good to go ** the entire set of email libs - lots of work, does anyone externally need those right now? *** dvratil: KMime make a lot of sense, but probably needs a good API review * KParts usage: ** dfaure: <tt>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).</tt> ** 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. * Account Wizard: ** Possible approaches *** port to QML and rewrite the JS scripted UI *** drop the account wizard in favor of KAccounts *** add a new widget-based plugin system to replace the scripted UI bits ** KAccounts is where we want to get to ultimately, the other options might be needed as an intermediate step if we don'T get that done before the KF6 deadline though. ** We need to find a solution for the D-Bus issue with Qt 5.14, that breaks the entire account wizard. * KF6/Qt6 ** We need to make sure Grantlee joins frameworks with KF6 for real this time. * Gitlab migration ** We all want that, but it should happen all at once, once everything is ready and all repos transition. =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= [[Sprints/PIM/2019 | PIM Sprint 2019, 5-7 April, Toulouse, France]] Return to Sprints/PIM/2020. Retrieved from "https://community.kde.org/Sprints/PIM/2020"