Sprints/PIM/2023: Difference between revisions
< Sprints
Line 97: | Line 97: | ||
* Plan | * Plan | ||
** Phase 1: Once the new QML wizard is in place stop creating kolab resources and create IMAP + DAV resources instead | ** Phase 1: Once the new QML wizard is in place stop creating kolab resources and create IMAP + DAV resources instead | ||
** Phase 2: Create a migrator for the existing setups creating the DAV resources and killing the existing kolab resource | ** Phase 2: Create a migrator for the existing setups creating the IMAP and DAV resources and killing the existing kolab resource, making sure we display to the user a warning that something is migrated and it will take a long time | ||
* Problem: who got a Kolab account to test with? this is the limiting factor | * Problem: who got a Kolab account to test with? this is the limiting factor | ||
Revision as of 08:58, 1 April 2023
Venue
- Artilect Fablab Toulouse
- 10 rue Tripière – 31000 Toulouse - France
- https://artilect.fr/ (website in French only)
Agenda
Add topics we should discuss:
- KF6-based PIM (1h timebox, discussion):
- blocking issues?
- release timeline, branching
- Remaining issues with replacing the Kross-based account wizard
- KF6-based PIM, retirning components (1h timebox discussion):
- Retiring the Kolab resource in favor of CalDav/CardDav?
- Retiring the mixed maildir resource in favor or "real" maildir?
- PIM Libraries/Dependencies (10 minutes overview + breakout groups digging one of the topics)
- KMailTransportAkonadi folding in akonadi-mime?
- the last KWallet use in KMailTransport - how can we get rid of that?
- moving the remaining things needed for Kalendar from eventviews and calendarsupport down to akonadi-calendar
- can we reverse the akonadi-contact -> contacteditor dependency?
- PIM Frameworks in KF6 (10 minutes overview + breakout groups digging one of the topics)
- KDAV without KIO HTTP?
- KCalendarCore custom/non-standard properties API
- Windows compatibility (1h timebox, discussion)
- GnuPG windows toolchain compatibility
- QML compatibility (10 minutes overview + breakout groups digging one of the topics)
- QML APIs for PIM libraries
- upstreaming QML API from Kalendar to KF
Notes
QNAM port of KDAV
- we want this given the state of KIO HTTP, the complexity of KIO HTTP deployment and due to not needing anything KIO HTTP provides over QNAM for the most part
- the good news: KIO is not leaking to the outside in the KDAV API, we can switch the implementation whenever we want
- migration plan
- complete the test coverage using FakeServer scenarios, at least covering the three DAV verbs used here (PROPFIND, PROPPATCH, REPORT), ideally also the HTTP verbs beyond GET. Note that different paths are taken depending on the protocol (CardDav vs CalDav), so we need to consider both for the tests.
- A single QNAM instance can then be held by the DavManager singleton, API to provide an external one isn't needed initially (and we probably won't want it ever, this opens a can of worms in term of API safety).
KCalendarCore::Calendar async change operations
Use-case: Zanshin using KCalendarCore::Calendar with the calendar plugins instead of Akonadi-specific models.
Option 1:
- Make modifying methods on Calendar return something job-like, and thus make the API fully async.
- That's the right approach on paper...
- ... but very invasive. Likely not realistic for KF6.
Option 2:
- Add additional API for registering an error handler and possibly more change notification signals.
- Can be phased in small steps and possible even in an API-compatible way.
- Far more realistic in terms of effort.
KCalendarCore::Calendar API review
Areas in need of a closer look:
- pseudo-I/O API: isSaving(), save(), close(), reload(), ...
- base implementations are usually non functional dummys
- semantics make little sense in an Akonadi or Android world
- isSaving() looks entirely unused
- Notebook API
- we don't even know what that is, not covered in any RFC and apparently existing entirely in memory
- unused in our code, but possibly something used by Sailfish (https://github.com/sailfishos/mkcal/blob/master/src/notebook.h ??)
- Filtering capability
- Duplicates parts of the read API (raw vs non-raw)
- Conceptually something that rather belongs in a proxy-calendar on top
- Direct calls to filtered read API in any of the existing Calendar sub-classes would make a transition to the proxy approach difficult though.
- Relations API
- seems duplicated in Akonadi::CalendarBase, a possible reason for this is lacking change notifications in that base class?
- setup/removeRelations should likely be protected? currently only used by MemoryCalendar
- functionality is needed though for hierarchical todos
PIM 6
- aim for a 6-based release with 23.12, assuming a KF6 release in Q3.
- if there is a delay in KF6, we can shift by one Gear release cycle
- QML-based account wizard is not realistic before branching, there is no other big change we would want to get in before branching
- create the kf6 branch "now"
- larger changes happen in kf6 branch, with master being merged into kf6
- move kf6 CI jobs to the kf6 branch and remove them in master, after coordination with Ben
Kolab resource phase out
- Looks too easy to be true
- We already have infrastructure in place for migrating existing resources
- Should take inspiration from the GoogleResourceMigrator which did a similar job
- Plan
- Phase 1: Once the new QML wizard is in place stop creating kolab resources and create IMAP + DAV resources instead
- Phase 2: Create a migrator for the existing setups creating the IMAP and DAV resources and killing the existing kolab resource, making sure we display to the user a warning that something is migrated and it will take a long time
- Problem: who got a Kolab account to test with? this is the limiting factor
Sprint Schedule
- April 1/2, 2023
- It's possible to show up to the venue on the Friday afternoon, I will be there to greet the early birds
Travel Reimbursement
- File a request on https://reimbursements.kde.org/events/160
- The proposed hotel is around 130€ for two nights.
Attendance
- Kevin Ottens
- Ingo Klöcker
- Volker Krause
- Laurent Montel
- Carl Schwan
Hotel
- Plenty of options in the area on all price ranges, living there I didn't get to try them though...
- Proposed hotel is "Hôtel de France", seems to be one of those smaller and a bit dated but clean options
- Pricing seems a bit cheaper directly on their website: https://hotel-france-toulouse.com/ (also available through booking.com for those who prefer that)
Arrival and departure times
- Ingo: arriving 5:54 on Friday (by night train), departing 22:18 on Sunday (by night train)
- Laurent: arriving 16:55 on friday (airport), departing 20:20 on sunday (airport)
- Carl: arriving 7:07 on Saturday (by night train), departing 22:18 on Sunday (by night train)
- Volker: arriving
10:2913:24 on Friday by train, departing 17:19 on Sunday by train
Restaurants
- Friday dinner: Le Maharaja - 46, rue Peyrolières - 31000 Toulouse
- Saturday lunch: La Faim des Haricots (take away)
- Saturday dinner: Jalapeños (delivery)
- Sunday lunch: La Faim des Haricots (take away)
Report
Draft of report:
KDE Itinerary compatible event data
Can be copy/pasted into KDE Itinerary:
{ "@context": "http://schema.org", "@type": "EventReservation", "reservationFor": { "@type": "Event", "name": "KDE PIM Sprint 2023", "startDate": "2023-04-01T10:00:00+02:00", "endDate": "2023-04-02T18:00:00+02:00", "location": { "@type": "Place", "name": "Artilect Fablab Toulouse", "address": { "@type": "PostalAddress", "addressCountry": "FR", "addressLocality": "Toulouse", "postalCode": "31000", "streetAddress": "10 rue Tripière" }, "geo": { "@type": "GeoCoordinates", "latitude": 43.6017920, "longitude": 1.4428500 } } } }