Jump to content

Sprints/PIM/2020

From KDE Community Wiki

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)
  • [DONE] 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)
  • [DONE] 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)
    • Probably a race between ETM and The Model (from messagelist), dvratil will try to reprodudce and debug
  • Deleting emails while the inbox is sync'ed leads to emails reappearing before disappearing again (David)
    • Race in Akonadi - not sure what exactly happens, but dvratil will try think about that deeper :)
  • Finding out why kmail often shows "This message is encrypted" erroneously (David)
    • That is a bug in messageparser, I think it gets the wrong idea about XML-like attachments, dvratil might have a patch for that even somewhere locally
  • Finding out why contact completion/search doesn't find some contacts (David)
    • Could be that those are not indexed - use "delve" to query the Xapian DB
    • Debug the Xapian query executed by the completion code, see if the query is correct
  • KOrganizer: can't modify item immediately after creating it (bug 407965), https://phabricator.kde.org/D16917 didn't fully fix it? => https://phabricator.kde.org/D28559 (David)
  • Account Wizard fails to configure resources with Qt 5.14 (Laurent) - https://phabricator.kde.org/D28567 and https://phabricator.kde.org/D28583

Notes

  • KDAV: David and ervin agree with the move, ervin will do another API review
    • see mailing list for results
  • 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: 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? -> 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.
  • Telemetry Review
    • we still need to trigger the official review process
    • [DONE] config pages are missing for kab/akregator when run in kontact
    • [DONE] https://community.kde.org/Telemetry_Use is out of sync for kmail, and should list the applications explicitly

Attendance

  • Franck Arrecot
  • Laurent Montel
  • Kévin Ottens
  • David Faure
  • Dan Vratil
  • Andre Heinecke
  • Sandro Knauss
  • Volker Krause
  • Ingo Klöcker
  • Allen Winter

Report

TODO

Previous Meeting

PIM Sprint 2019, 5-7 April, Toulouse, France

Retrieved from "https://community.kde.org/index.php?title=Sprints/PIM/2020&oldid=87983"