09:00:03 <chriadam_> #startmeeting Sailfish OS CalDAV/CardDAV Contributors meeting
09:00:03 <merbot> Meeting started Mon Sep  4 09:00:03 2017 UTC.  The chair is chriadam_. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
09:00:03 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:00:11 <chriadam_> The agenda can be found:
09:00:16 <chriadam_> #link https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#04.2F09.2F2017_Meeting
09:00:42 <chriadam_> Not sure how many people will be attending, since I didn't send the reminder email until very late, again, unfortunately.
09:00:47 <chriadam_> #topic Introductions
09:00:54 <chriadam_> Please introduce yourself with #info name/nick.
09:01:01 <chriadam_> #info Chris Adams, developer at Jolla
09:01:20 <dcaliste> #info Damien Caliste, community
09:01:41 <chriadam_> hi dcaliste :-)
09:01:58 <chriadam_> we'll wait another 7 mins or so for other folks to arrive in case they're running late
09:02:20 <dcaliste> hello, nice to see you.
09:04:33 <chriadam_> you also!  the PR looks mostly good, I have a couple of concerns, will discuss in the upcoming topic
09:06:21 <dcaliste> Sure.
09:09:07 <chriadam_> ok, let's continue :-)
09:09:14 <chriadam_> #topic Follow-up Agenda Items From Last Meeting
09:09:20 <chriadam_> was I supposed to merge anything since last meeting?
09:10:06 <dcaliste> Yes, one MR, the one modifying icalconverter. I was supposed to add a "list" action, which I have done after the meeting.
09:10:17 <chriadam_> ah
09:10:19 <dcaliste> It's not very important, so no rush.
09:10:46 <chriadam_> this one? https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/21/diffs
09:11:16 <chriadam_> or was it to the libical / kcalcore code?
09:11:45 <dcaliste> No, sorry, I miss you indeed merged it already …
09:12:14 <dcaliste> Or it disappeared…
09:12:22 <chriadam_> let me check
09:12:32 <dcaliste> Looking for it, it was adding the export per notebook in icalconverter
09:13:33 <dcaliste> https://git.merproject.org/mer-core/nemo-qml-plugin-calendar/merge_requests/16
09:13:41 <dcaliste> I was looking in the wrong project…
09:13:57 <chriadam_> heh, me too
09:13:59 <chriadam_> thanks
09:14:18 <chriadam_> oh, yep
09:14:27 <chriadam_> that LGTM so I'll merge and tag that after this meeting
09:14:36 <dcaliste> Ok, thanks.
09:14:46 <chriadam_> just double checking: that didn't modify the command line options at all, did it?  just changed the way they were parsed?
09:14:50 <chriadam_> otherwise backup/restore will break ;-)
09:15:04 <dcaliste> Yes, the syntax is kept the same.
09:15:24 <dcaliste> Just internally, I've switched to use QCommandLineParser
09:16:17 <dcaliste> For instance 'icalconverter import foo.ics' is still importing and 'icalconverter export foo.ics' is still exporting.
09:16:47 <dcaliste> It is adding the 'icalconverter list' action and the '-n nbuid' option to the export action.
09:16:56 <chriadam_> great
09:16:56 <chriadam_> #action Chris to merge+tag https://git.merproject.org/mer-core/nemo-qml-plugin-calendar/merge_requests/16
09:17:58 <chriadam_> great
09:17:58 <chriadam_> anything else to follow up on from the last meeting?  if not, let's continue to the rest of the agenda
09:18:17 <dcaliste> Not that I immediately remember about.
09:19:00 <chriadam_> ok
09:19:00 <chriadam_> #topic MER#1609/MER#1805 - clean sync issues
09:19:00 <chriadam_> I briefly looked at the PR which makes clean-sync a per-notebooksyncagent decision
09:19:00 <chriadam_> I had a couple of questions:
09:19:23 <chriadam_> 1) does it replace/obsolete https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/22/diffs or does it go on top of that one?
09:19:49 <chriadam_> 2) mkcal cannot store millisecond-resolution timestamps in the syncDate field AFAIR - can this cause any issues?
09:20:37 <chriadam_> 3) the notebooksyncagent now creates the notebook, I believe.  IIRC creating a notebook in mkcal causes a transaction commit - is this the case or is my memory wrong?  if it does cause a commit, could this result in half-completed sync artifacts being written to database?
09:21:07 <chriadam_> 4) compatibility: if we merge and tag the change, will existing accounts continue to work, etc?  (I guess so, since the syncDate should exist for those also)
09:21:40 <dcaliste> 2) is easy : I've never seen any milliseconds in the sync log neither !
09:23:04 <dcaliste> 1) Yes, !22 was essemtialy just removing one line, the one with the deleteNotebook action. So new !23 should superceed it.
09:24:03 <dcaliste> 3) Yes, the notebook is created in notebooksyncagent. But, normally, it is still created only after the sync is successful. I'll detail…
09:24:54 <dcaliste> 4) Yes, that's a good question, but yes the setSyncDate() was already in use. So it is compatible with existing code and dtabase on device.
09:25:09 <dcaliste> Now, let's go back to the question 3)…
09:25:37 <dcaliste> The setNotebookFromInfo() new function:
09:25:53 <dcaliste> - either is associating mNotebook to an existing calendar ;
09:26:54 <dcaliste> - or is creating a in memory notebook for the duration of the sync and discussion with server, see line #215 in notebooksyncagent.cpp.
09:27:38 <dcaliste> The commit to the storage is done only in applyRemoteChanges() at line #766.
09:28:51 <chriadam_> let me check
09:29:02 <dcaliste> Sure.
09:30:35 <dcaliste> While discussing it here, I may have let a memory leak pass. In the case of in memory Notebook creation, because there is no deletion going with the new from line 215.
09:30:50 <chriadam_> ah, nice catch
09:31:53 <dcaliste> I'll see to that memory leak. Otherwise I let you think about the new workflow (which is not far at all from the old one, just that code have been moved from caldavclient to notebooksync agent).
09:31:54 <chriadam_> ok, I see what you mean about the "create new" only being "in memory" until the call to mStorage->addNotebook.
09:32:04 <chriadam_> yep, it makes sense
09:32:32 <chriadam_> ok, that's basically the only queries I had.  I've yet to test it personally, but yep, mostly seems good to me.  I like the fact that it can do per-notebook clean syncs if necessary now too
09:32:53 <chriadam_> I'll set aside a few hours in the next week to test it against the mer infra
09:33:12 <dcaliste> Yes, it is essentially the same workflow than before but I've moved code from caldav to notebook to be more local.
09:33:27 <chriadam_> and get it merged.  are you able to decline the !22 one since it's not needed any more
09:33:28 <dcaliste> Thank you for reviewing this.
09:33:41 <dcaliste> Ok, for declining !22.
09:33:52 <dcaliste> It was done before I worked on !23.
09:34:01 <chriadam_> :-)
09:34:16 <chriadam_> ok, let's continue with agenda:
09:34:19 <chriadam_> #topic MER#1796 - local modification being reported erroneously to calendar events
09:34:46 <chriadam_> the comparison with trimmed strings, makes sense.  I'll review that one thoroughly and merge.
09:34:48 <dcaliste> You'll see also that buteo-syncfw!16 is not really needed anymore. But in case, it is correcting the lastSuccessfulSyncDate() call anyway.
09:35:01 <chriadam_> #action Chris to review and merge https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/21/diffs
09:35:53 <chriadam_> typo in the commit message in https://git.merproject.org/mer-core/buteo-syncfw/merge_requests/16/diffs
09:36:29 <chriadam_> on the one hand, I'm disinclined to touch Buteo code unless I can absolutely avoid it.  on the other hand, it's clearly a bug...
09:36:48 <chriadam_> I will most likely merge that one too.
09:36:58 <chriadam_> #action Chris to merge https://git.merproject.org/mer-core/buteo-syncfw/merge_requests/16/diffs also
09:37:07 <dcaliste> I'll correct the typo !
09:38:02 <chriadam_> with regards to MER#1796 do you think it's just the "trimmed" comparison issue?  that seems very likely culprit to me.
09:39:18 <dcaliste> Aout MER#1796, the trailing whitespace was definetely an issue. But I cannot say that is solve all #1796 cases…
09:39:44 <chriadam_> ok, well I'll merge that one and ask community to test (well after I've merged all of these changes I'll generate test packages and ask for help testing)
09:39:52 <chriadam_> thank you very much for looking into those issues!
09:39:56 <chriadam_> let's continue with agenda:
09:40:06 <chriadam_> #topic MER#1714 - isdn field added to phone numbers on upsync (investigation required)
09:40:25 <chriadam_> as in previous meetings, this is low-priority but good task for a new contributor; if anyone would like to help, please get in contact :-)
09:40:34 <chriadam_> continuing
09:40:35 <chriadam_> #topic MER#1751 - main issue resolved, but some minor tasks here remain.
09:40:47 <dcaliste> Well, now that I'm actively using it on my device, I'm eiger to solve issues I encounter (and it's much easier to collect logs…).
09:41:03 <dcaliste> For CardDAV, not using it (yet)…
09:41:14 <chriadam_> as in previous meetings, this is an issue which should be easily solvable (.eml files containing .vcf data, reported by kerio), if any new contributors want to help, please get in touch :-)
09:41:49 <chriadam_> dcaliste: IMO the carddav code is much nicer to work with (maybe just hubris, since I wrote it).  BUT it does have complications due to the moderately insane qtcontacts-sqlite aggregation semantics.
09:42:09 <chriadam_> continuing
09:42:10 <chriadam_> #topic Any Other Business?
09:42:22 <chriadam_> Nothing else from me.  Can you ping me via the PR once the memory leak thing is resolved?
09:42:31 <chriadam_> then I'll merge and tag everything outstanding, generate test packages, etc
09:42:48 <dcaliste> Yep, I'll ping you after memory leak corrected.
09:43:03 <chriadam_> thanks!  do you have anything else to raise?
09:43:34 <dcaliste> Nothing for now, settling with all these changes first, but I'm still thinking about todos…
09:44:12 <chriadam_> pvuorela: we should sync up with dcaliste on this point
09:44:31 <chriadam_> fyi an internal customer might need TODO support in the nearish future, so there has been some discussion about what we should support and how.
09:45:01 <dcaliste> My point is mainly first to review caldav and calendar code to see where assumptions are made on events only. There are not so many it seems.
09:45:21 <chriadam_> right
09:45:39 <dcaliste> Good that it will be worked inside also, there will be UI integration like that ;)
09:45:41 <chriadam_> maybe some "not implemented" bits in the incidencehandler
09:46:06 <chriadam_> since those conversion codepaths wouldn't have been tested in reality for TODOs I guess, so might be some data missed etc
09:46:47 <chriadam_> anyway, let's see what happens. :-)
09:47:20 <chriadam_> once again, thanks very much for your hard work, it is greatly appreciated.  I've asked Jaymzz if we can send you a shiny new device or some tshirts ;-)
09:47:37 <dcaliste> We can discuss this in the next meeting if current MRs are working well ;)
09:47:39 <chriadam_> next meeting will tentatively be on Monday October 2nd at 0900 - would that suit you?
09:48:15 <dcaliste> Ok with the 2nd of October.
09:48:19 <pvuorela> on todos, having support gets easily into question whether to support todo lists or calendar todos.
09:49:41 <dcaliste> Without thinking much to the question list vs. calendar, I like having the synchro between devices for free (Mmh) when using calendar todos.
09:49:56 <dcaliste> And also integration with cloud things.
09:50:13 <chriadam_> lots of discussion points and tradeoffs I think.  maybe we can add that to agenda for next meeting properly, and discuss more in-depth there.
09:50:37 <dcaliste> chriadam_, I agree.
09:50:40 <chriadam_> :-)
09:50:43 <chriadam_> ok thanks again!
09:50:45 <chriadam_> #endmeeting