KDE PIM/Meetings/KDE PIM at Akademy 2020: Difference between revisions
No edit summary |
m (→Notes) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 33: | Line 33: | ||
*** Con: pulls in more stuff for building | *** Con: pulls in more stuff for building | ||
*** we agreed this is ok | *** we agreed this is ok | ||
** start to systematically collect all actionable tasks in a workboard | |||
*** see also previous work on this: https://community.kde.org/Frameworks/Epics/kdepimlibs | |||
Latest revision as of 18:08, 8 September 2020
Notes from KDE PIM BoF at Akademy 2020 on the Internet
Notes
- EteSync resource GSoC project was merged yesterday \o/
- André reporting on GnuPG/Kleopatra activities
- https://dot.kde.org/2020/02/18/gpg4kde-gpg4win-approved-transmission-processing-national-classified-information - VS-NfD certification achieved last year \o/
- Ingo working on better smart card support for Kleopatra (which includes USB-based password tokens like the Yubikey/etc)
- Android work and framework split also helped Windows deployments for Gpg4Win
- State of Kontact on Windows
- largely unknown
- we know Akonadi works though, via FatCRM (built on AppVeyor using Craft)
- we know Kontact works on WSL, via Till
- André suggests the Enigmail drop in Thunderbird might be an opportunity to reach Windows-based crypto-nerd users
- gpgme(++) build on Windows is an issue, due to its autotools build system, can possibly be addressed by adding a CMake build system upstream, in collaboration with André
- Library and dependency cleanup efforts
- there has been some progress on removing kdepim-apps-libs
- kab import/export move was stuck during Gitlab transition, Dan/Luigi will continue this now
- remaining: kab grantlee integration: can this go to akonadi-contact
- libkdepim: some stuff has been moved, to other modules or KF, more to do
- KDAV moved to KF
- should we have a dedicated sprint on this? -> yes, for doing the analysis and planning, later this year, David volunteers to join
- are we ok with applications installing their own plugin interfaces, or should those be split into separate repos? e.g. kontactinterface vs kontact, or the interfaces for the other plugins in kdepim-addons
- Pro: easier dependency tree
- Con: pulls in more stuff for building
- we agreed this is ok
- start to systematically collect all actionable tasks in a workboard
- see also previous work on this: https://community.kde.org/Frameworks/Epics/kdepimlibs
- kdepim-addons structure
- there shouldn't be any mandator or essential things in there
- KAsync
- Dan is reworking it, first for use inside Akonadi, and when it holds up there, for inclusion into KF
- Depends on C++17, but doable as it's header-only