09:00:28 <chriadam_> #startmeeting Sailfish OS CalDAV/CardDAV Contributors meeting
09:00:28 <merbot> Meeting started Mon Oct  2 09:00:28 2017 UTC.  The chair is chriadam_. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
09:00:28 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:00:44 <chriadam_> Thanks for joining the CalDAV/CardDAV contributors meeting
09:00:48 <chriadam_> as always, the agenda can be found at:
09:00:48 <chriadam_> #link https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#02.2F10.2F2017_Meeting
09:00:55 <chriadam_> #topic Introductions
09:01:03 <chriadam_> Please introduce yourself with #info name/nick
09:01:08 <chriadam_> #info Chris Adams, developer at Jolla
09:01:19 <pvuorela> #info Pekka Vuorela, developer at Jolla
09:01:29 <dcaliste> #info Damien Caliste, community
09:01:32 <rubdos> #info Ruben De Smet, community
09:01:44 <dcaliste> Hello pvuorela !
09:01:59 <pvuorela> dcaliste: howdy!
09:02:14 <rubdos> Good morning everyone!
09:02:23 <jakibaki> #info Jakob Dietrich, community
09:02:30 <chriadam_> hi jakibaki, welcome
09:02:47 <chriadam_> we'll wait another 6 mins or so for more folks to arrive, then we'll get started on the agenda proper
09:07:44 <chriadam_> ok, let's continue with the agenda items!
09:07:51 <chriadam_> #topic Follow-up Agenda Items From Last Meeting
09:08:03 <chriadam_> I've reviewed and merged about half of dcaliste's PRs from the last month
09:08:19 <chriadam_> two still remain which would be good if pvuorela or someone else could also review:
09:08:24 <chriadam_> https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/23
09:08:29 <chriadam_> https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/25
09:08:36 <zotan> #info Simon Brown, community
09:08:47 <dcaliste> Thank you chriadam_ indeed. But I've added two new since Friday…
09:09:03 <dcaliste> One in kcalcore and another one in caldav. All about MER#1796
09:09:04 <chriadam_> welcome, zotan
09:09:30 <chriadam_> dcaliste: thanks - I will have to check those
09:09:30 <zotan> o/ chriadam_
09:09:32 <pvuorela> been on my list of things to check, but so far been busy with other things. think i'll get there soon :)
09:09:39 <chriadam_> pvuorela: thanks :-)
09:09:53 <dcaliste> Thank pvuorela.
09:10:16 <chriadam_> unfortunately, since #23 hasn't been merged yet, I haven't created the test packages for community members to test, or advertised it via TJC, since I think #23 is the "main one" we want to test
09:10:30 <chriadam_> so no progress on the "testing/verification" front yet to report
09:10:38 <chriadam_> but definitely will do so in the next two weeks.
09:11:00 <chriadam_> was there anything else which needs discussion, regarding follow-ups from last meeting?  did I forgot anything in particular?
09:12:12 <rubdos> Would compiling #23 and using it on my phone aid in testing?
09:12:38 <rubdos> or will we just wait on your packages?
09:13:19 <chriadam_> rubdos: any testing helps
09:13:49 <rubdos> roger that.
09:13:54 <chriadam_> in general, the more people who are willing and able to test PRs is very helpful
09:14:00 <chriadam_> :-)
09:14:21 <rubdos> good, feel free to ping me on anything you want tested. I'll just flash it on my phone and report back whether it explodes :-)
09:14:39 <chriadam_> cheers :-)
09:14:41 <chriadam_> ok, well hopefully I haven't forgotten anything else from the last meeting, so let's continue with the next agenda item
09:14:48 <chriadam_> #topic Support for Todo instances (storage + sync + UI), discussion
09:14:54 <chriadam_> I guess I'll give the floor to rubdos here
09:15:05 <dcaliste> On the good side, I'm using it snce one month without particular issues (ecept many spurious modifications that I'm tracking the origin of).
09:15:29 <rubdos> hehe, not that I have a lot to say yet. Just seems that we need QML bindings for anything backend, as it seems synchronisation itself is more or less present
09:15:42 <chriadam_> my understanding is that mkcal should support storing VTODO instances, but aside from that I don't know what else in the stack doesn't support them (e.g., sync adapters, nemo-qml-plugin-calendar, etc)
09:15:57 <rubdos> I've been writing stuff for nemo-qml-plugin-calender iirc
09:15:58 <chriadam_> rubdos: I don't believe our sync adapters support VTODOs yet
09:16:07 <chriadam_> nemo-qml-plugin-calendar is where the QML bindings exist
09:16:16 <rubdos> https://git.merproject.org/mer-core/nemo-qml-plugin-calendar/merge_requests/18
09:16:36 <rubdos> yap, I started !18 on that. Still needs some deduplication, and some general review would be welcome
09:16:46 <rubdos> (it's WIP for a reason)
09:16:57 <chriadam_> ah great!
09:17:36 <rubdos> I also think, since both todo and calendar items are subclassed from a "instance" (don't remember the exact names), some deduplication can be performed
09:17:43 <chriadam_> yes, incidence
09:17:45 <chriadam_> in kcalcore
09:18:00 <rubdos> seems like the only difference between calendar items and todo's are end date vs. due date
09:18:09 <rubdos> and that's the reason there's a bunch of code duplication :/
09:18:37 <chriadam_> pvuorela: can you give any insight into what plans might be for VTODO support in jolla-calendar app?  is this something we are planning, or potentially could add to roadmap, or is this not really on the radar at this point?
09:18:41 <dcaliste> I can give a look to your MR in the coming two weeks.
09:18:51 <chriadam_> dcaliste: that would be very helpful, thankyou
09:19:00 <rubdos> dcaliste: good. Some initial feedback would be good, before I start screwing things up too much :)
09:19:19 <rubdos> pvuorela, chriadam, would that be a separate app, or integrated into the calendar?
09:19:42 <chriadam_> rubdos: that remains to be seen.  At this stage, we don't have any sort of support.  so design will need to discuss this.
09:19:51 <pvuorela> the ui side is a bit complicated. i'm all for having middleware and sync support, but on app level the discussion mostly gets into whether we want to support icalendar todo items or more like todo lists without dates attached.
09:19:52 <rubdos> because it seems like the calendar itself would get crowded; I'd opt for a separate UI. But that's me, :)
09:20:04 <dcaliste> Good question, but whatever the answer, IMHO it's nice that TODO are stored in mkcal storage.
09:20:07 <chriadam_> right
09:20:16 <chriadam_> I agree.  so should we, currently, aim for:
09:20:26 <chriadam_> 1) ensuring mkcal supports VTODOs (I think it already does, but let's check)
09:20:38 <chriadam_> 2) trying to see what we need to change in sync adapters to sync these
09:20:51 <chriadam_> 3) ensuring the bindings (nemo-qml-plugin-calendar) work (i.e., rubdos' work)
09:21:17 <chriadam_> then at least openrepos apps can be built which provide TODO functionality, and internally we can decide direction to take from there
09:21:26 <dcaliste> I volunteer to test sync of TODOs with current caldav plugin and submit MR where needed.
09:21:27 <chriadam_> does that seem reasonable, or are there other opinions?
09:21:27 <rubdos> pretty sure mkcal supports vtodos, since my MR linked mkcal to kcalcore. Needs checking indeed.
09:21:43 <pvuorela> chriadam_: sounds good to me.
09:21:50 <chriadam_> great!
09:21:55 <rubdos> yes, sounds very good
09:22:31 <chriadam_> in terms of concrete action items for us in Jolla, aside from reviewing MRs and testing, is there anything you need from us?
09:22:32 <rubdos> can I write tests for those tasks? I remember that cal had them, but couldn't run half of them iirc
09:22:44 <chriadam_> dcaliste: rubdos: e.g. can give you a test account on the internal mer infra etc
09:23:15 <zotan> will the tasks be accessible by store apps, eg tasks?
09:23:16 <rubdos> me specifically, no, wouldn't think I need more from Jolla. Just knowing you guys discuss the design would be good :)
09:23:21 <chriadam_> rubdos: we of course would like unit tests for all functionality added.  and if you spot a problem with any existing unit test, please file a bug report on Mer bugtracker
09:23:49 <rubdos> chriadam_: not sure whether it was me or the code though, since I ran the tests against my own agenda (yeh...)
09:24:00 <chriadam_> zotan: at this stage, I don't believe we've opened up the kcal API for third party apps in harbour, no.  (long term plan is to use the QtPIM API for calendar access, but ... a fair bit of work remains before that becomes a reality)
09:24:11 <rubdos> so I suppose a test acc might be useful
09:24:22 <dcaliste> I'm running tests on my phone currently and will add unit tests for VTODO reader part and notebooksyncagent part.
09:24:40 <chriadam_> #info https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#Performing_Manual_Tests_With_The_Test_Services
09:24:50 <chriadam_> please feel free to use those services in any way you see fit
09:24:58 <rubdos> roger that
09:24:59 <chriadam_> break things / test things
09:25:14 <dcaliste> zotan, chriadam_: but using the nemo-qml-plugin API may be fine within a shorter time range for harbour ?
09:25:19 <chriadam_> any issues with them, let me know and we'll reboot those.  they're a docker instance, so easy to "re-provision"
09:25:39 <chriadam_> dcaliste: perhaps, certainly more likely than opening up kcalcore API, yes.
09:25:43 <chriadam_> dcaliste: but timeframe?  not sure
09:25:52 <pvuorela> dcaliste: calendar data needs also more privileges.
09:26:12 <dcaliste> pvuorela: ah yes you're right, forgot the devel-su -p things…
09:27:25 <chriadam_> good news is that we're internally working on MAC and access control things so this is something which we should have a proper solution for in the nearish to medium term future.
09:27:37 <rubdos> feel free to ping me know and then about progress... In the meanwhile, I'm writing a masters thesis too. FYI.
09:27:59 <chriadam_> rubdos: no problem, of course we understand everyone's time is limited.  we're grateful for help :-)
09:28:15 <rubdos> my time is usually forgetful :-)
09:28:29 <chriadam_> ok, sounds like we have a good plan, going forward, for this VTODO topic
09:28:41 <chriadam_> as always if you need anything, please send me an email or ping me on IRC
09:28:46 <chriadam_> let's continue to next topic:
09:28:54 <chriadam_> #topic MER#1714 - isdn field added to phone numbers on upsync (investigation required)
09:29:22 <chriadam_> same as last time, this is a good item for new contributors.  if you're interested please get in touch.
09:29:29 <chriadam_> #topic MER#1751 - main issue resolved, but some minor tasks here remain.
09:29:44 <chriadam_> same as last time, this also is a good item for new contributors.  if you're interested please get in touch.
09:29:56 <chriadam_> #topic Any Other Business?
09:30:19 <chriadam_> dcaliste: you mentioned finding another issue related to MER#1796 ?
09:30:36 <dcaliste> Yes, one about EXDATE.
09:31:13 <dcaliste> When comparing local and received recuring events, on local the EXDATE for modified incidences is not removed.
09:31:20 <dcaliste> Making the comparison fails.
09:31:34 <chriadam_> I'm reading the commit message now.  makes sense...
09:31:47 <chriadam_> I guess we should support both
09:31:53 <dcaliste> see https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/27
09:32:15 <dcaliste> The modification is simple: include the exdate removal in exportICSdata function.
09:32:39 <dcaliste> Not only during up-sync.
09:32:53 <chriadam_> right
09:33:01 <dcaliste> Seems to work on my device.
09:33:17 <chriadam_> well, I will try to review and test that one too
09:33:28 <chriadam_> thanks very much for your work and testing as always
09:33:49 <dcaliste> The only down part of this MR is that I took initiative to simplify a bit the removeIfDuplicate function and I'm not 100% sure I've not break a use case…
09:33:49 <chriadam_> did anybody have anythign else?
09:33:57 <chriadam_> dcaliste: I'm a bit worried abotu that too
09:34:02 <dcaliste> The second issue is in kcalcore.
09:34:05 <chriadam_> maybe split into two PRs
09:34:12 <chriadam_> kcalcore?  oh?  I didnt' see that one
09:34:14 <zotan> is #23 a likely fix for slow speed event duplication?
09:34:16 <dcaliste> ok, for two PRs in caldav.
09:34:33 <chriadam_> zotan: yes
09:34:37 <dcaliste> zotan: that's my conclusion, yes, but not 100% sure neither.
09:34:38 <chriadam_> oh wait
09:34:52 <chriadam_> was that one duplication or just purge?
09:34:58 <dcaliste> zotan: see my comment on the TJC question.
09:35:11 <chriadam_> zotan: dcaliste fixed another issue which could cause a crash in some cases, and crashes can cause duplications
09:35:21 <chriadam_> that one is merged but not tagged yet
09:35:37 <dcaliste> zotan: see https://together.jolla.com/question/166976/21126-caldav-calendar-duplication
09:35:48 <dcaliste> chriadam_: about the issue in kcalcore:
09:35:58 <dcaliste> it's about an issue in alarm comparison.
09:36:06 <chriadam_> oh another one ;-)  ok
09:36:07 <dcaliste> When the duration is set to zero.
09:36:22 <chriadam_> cool.  will check that one too.  tyvm
09:36:53 <dcaliste> icalformat is generating Duration(0, Days) while comparisons are done with Durantion(0, Seconds)…
09:37:29 <dcaliste> I propose to generate by default second durations when the delay is null.
09:37:54 <chriadam_> seems reasonable..
09:38:05 <dcaliste> I didn't want to relax the operator== in Duration in case one wants to indeed make a comparison on type.
09:39:00 <zotan> dcaliste: There's alot of detail there, I'll investigate.
09:39:37 <dcaliste> zotan: feel free to comment there also, I'm following the question and should be noticed.
09:39:51 <chriadam_> :-)
09:40:04 <chriadam_> ok, if there's nothing else, I'll quickly summarise action points:
09:40:17 <chriadam_> 1) pvuorela to review those two MRs #25 and #23
09:40:26 <chriadam_> 2) chriadam to merge those, produce test packages, ask for help testing on TJC
09:40:47 <chriadam_> 3) chriadam and dcaliste to review rubdos' MR on n-q-p-c
09:41:00 <chriadam_> 4) dcaliste will investigate caldav plugin sync support for VTODO incidences
09:41:24 <chriadam_> 5) chriadam and pvuorela to review the other MER#1796 exdate + alarm PRs in caldav+kcalcore
09:41:38 <chriadam_> did I miss anything?
09:41:44 <dcaliste> chriadam_: all these MRs about comparison issues because with the extended log, I'm easily noticing spurious modified events in log :)
09:42:09 <dcaliste> Do you want to discuss the log MRs now or we let it mature for next meeting ?
09:42:10 <chriadam_> dcaliste: definitely a good thing to notice these issues, thanks!
09:42:26 <chriadam_> dcaliste: let's discuss
09:43:33 <dcaliste> So, there are two MRs, one in Buteo to add error reporting in SyncResult and one in caldav to add success stat and error in logs.
09:43:56 <chriadam_> https://git.merproject.org/mer-core/buteo-syncfw/merge_requests/17
09:44:24 <chriadam_> which one is the caldav one?  #23 or #24?
09:44:40 <chriadam_> 24 I guess?
09:45:05 <chriadam_> https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/24
09:45:20 <dcaliste> Yes, it's !24 in caldav.
09:45:53 <chriadam_> this is "self contained" as in, it doesn't affect synchronisation itself, does it?
09:46:07 <chriadam_> it's purely: ensure that the sync result and message is stored in the log correctly?
09:46:19 <dcaliste> Yep.
09:46:37 <chriadam_> ok.  well, unless pvuorela disagrees, I'm pretty inclined to just merge these two MRs.
09:46:49 <chriadam_> we can look at hooking up the UI side at a future point in time
09:47:09 <chriadam_> for e.g. MDM reporting, even just having the log file is a useful feature IMO
09:48:04 <dcaliste> The main question is the translation approach of the error messages.
09:48:23 <chriadam_> ah, I'd forgotten about that issue
09:49:25 <dcaliste> What do you think about the second commit in buteo MR ?
09:49:37 <dcaliste> The approach of having a message and argments.
09:50:27 <dcaliste> Is it too ugly in log to have something like:
09:50:56 <dcaliste> <error><mess>an error occur in %1</mess><arg>123456789-123</arg>
09:51:00 <dcaliste> </error>
09:51:15 <dcaliste> And the mess part can be ids to be translated.
09:51:41 <chriadam_> not too ugly.  I worry though that something may already use SyncResults::message() and this isn't source compat change
09:52:11 <dcaliste> Well, SyncResult::message() does not exist.
09:52:29 <chriadam_> oh, I see :-D
09:52:29 <dcaliste> SyncResult only contains currently stat on success and an id on error.
09:53:02 <chriadam_> I don't think it's too ugly
09:53:29 <chriadam_> although if translation ids are expected in the message... hrm
09:53:36 <chriadam_> some UI would need ot load the appropriate catalogue
09:53:49 <chriadam_> which presumably might come from a random sync plugin etc
09:54:00 <chriadam_> could be tricky...
09:54:15 <dcaliste> Exactly. Or I think to something like that. I'm not very aware about translation is working.
09:54:53 <chriadam_> maybe we need to think abotu this more.  maybe buteo itself could define a bunch of specific error messages, with appropriate arguments, associated with major+minor codes
09:54:59 <chriadam_> and then the plugin just has to provide the arguments
09:55:11 <chriadam_> the UI then just loads the single (buteo-syncfw provided) catalogue
09:55:18 <dcaliste> Generic errors are not enough sadly.
09:55:23 <chriadam_> dang.
09:55:24 <dcaliste> How to express something like:
09:55:45 <dcaliste> Incidence 456 in Notebook 123456 is not found.
09:56:10 <dcaliste> When looking at the errors in caldav they look very specific to me…
09:56:22 <pvuorela> do such need translations? doesn't sound like a thing that commonly should be shown to user.
09:56:33 <chriadam_> indeed, it's impossible from buteo-syncfw point of view, since it doesn't know even what datatype the plugin will be syncing
09:56:38 <chriadam_> pvuorela: good point
09:56:55 <dcaliste> pvuorela: in my point of view, it would be nice even for users.
09:57:08 <dcaliste> Not necessary in the calendar itself (of course)
09:57:23 <chriadam_> maybe we can just avoid the translation issue altogether?  but maybe we need to discuss this more internally, as it kind of does seem bad to have russian phone showing english error messages or similar.
09:57:36 <dcaliste> But in a setting part where one can have a feed back on what happen during sync.
09:57:57 <chriadam_> some sync-history-UI etc
09:58:06 <dcaliste> chriadam_: exactly.
09:58:12 <pvuorela> if it's something that ends up only in logs, i'd prefer english over russian if i ever get to check such log :)
09:58:19 <chriadam_> yes, we need that.  I guess the "common case" though is just "this sync failed at time X due to: network/database/sync error"
09:58:28 <dcaliste> pvuorela: it's user logs ;)
09:59:30 <dcaliste> pvuorela: for debugging we need the full LOGGING_LEVEL=8 log anyway.
09:59:48 <chriadam_> I suggest we think about this a bit more, and discuss in depth at the next meeting.  I think some interesting questions to consider might be: 1) which of these should definitely be user-visible in UI?  2) are there a common subset which can be shown in all cases, and an uncommon subset which are only shown in exceptional cases?  if so, do the latter subset require translated strings? etc
09:59:54 <dcaliste> But for user it can give a clue that the error is from an incidence on server that is malformed for instance.
10:01:16 <dcaliste> chriadam_: I agree let it mature and indeed thry to sort out what we want to report to the user exactly. Feel free to comment in https://git.merproject.org/mer-core/buteo-sync-plugin-caldav/merge_requests/24
10:01:35 <chriadam_> thanks :-)
10:01:39 <dcaliste> to add ideas and reflexions.
10:01:50 <chriadam_> I will add some comments there for discussion, yes :-)
10:02:30 <chriadam_> ok, anything else?  if not, I suggest the next meeting could be Monday November 6th at 0900 UTC - does that date/time suit everyone?
10:02:53 <dcaliste> Allright for me.
10:03:02 <jakibaki> Not sure if this belongs in a seperate topic: Is there a reason this (https://git.merproject.org/mer-core/qtsensors/merge_requests/4) MR hasn't been merged yet especially this very closely related one (https://git.merproject.org/mer-core/sensorfw/merge_requests/18) already has been merged?
10:03:59 <chriadam_> jakibaki: probably no reason other than it slipped off the radar
10:04:31 <chriadam_> not sure who the sensorfw maintainer is currently... maybe spiiroin or pvuorela?
10:05:00 <dcaliste> #action pvuorela to review those two MRs #25 and #23
10:05:13 <dcaliste> #action chriadam to merge those, produce test packages, ask for help testing on TJC
10:05:13 <pvuorela> not me :) could ping simo again. i didn't merge that yet because i have no way of testing, though it looked simple enough.
10:05:23 <dcaliste> #action chriadam and dcaliste to review rubdos' MR on n-q-p-
10:05:35 <dcaliste> #action dcaliste will investigate caldav plugin sync support for VTODO incidences
10:05:42 <dcaliste> #action chriadam and pvuorela to review the other MER#1796 exdate + alarm PRs in caldav+kcalcore
10:06:18 <chriadam_> #action discuss the buteo success/failure log issue.  translated strings from plugins = either need to dynamically load plugin-provided translation catalogues, or allow non-translated strings in log (UI?), or?
10:06:45 <rubdos> If I'm not there the 6th, it's because of a CAL bug in SFOS ;-)
10:06:50 <chriadam_> ok, thanks again everyone for attending and spending your time to help us with caldav/carddav stuff
10:06:54 <chriadam_> rubdos: uh oh ;-)
10:07:01 <chriadam_> hopefully it works and reminds you ;-)
10:07:02 <dcaliste> Yes, the main question being : "what feedback do we want for sync processes?"
10:07:32 <chriadam_> yes.  that definitely requires at least some design input.  I'll try to ping jpetrell or mschuele to get some feedback on that issue.
10:07:55 <chriadam_> ok!  thanks everyone!  ending meeting in 5...
10:08:01 <chriadam_> 4...
10:08:05 <dcaliste> chriadam_: thanks
10:08:06 <chriadam_> 3...
10:08:11 <chriadam_> 2...
10:08:15 <chriadam_> 1...
10:08:18 <chriadam_> #endmeeting