09:00:47 <chriadam_> #startmeeting Sailfish OS CalDAV/CardDAV contributors meeting 11/12/2017
09:00:47 <merbot> Meeting started Mon Dec 11 09:00:47 2017 UTC.  The chair is chriadam_. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
09:00:47 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:01:07 <chriadam_> The agenda can be found at #link https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#11.2F12.2F2017_Meeting
09:01:24 <chriadam_> Again, apologies for having to postpone this meeting last week at last minute, something came up.
09:01:39 <chriadam_> Also, I apologise if I disconnect halfway through the meeting, if that happens please wait a couple of minutes for me to come back online.
09:02:05 <chriadam_> My internet connection is pretty darn flaky as our ISP has been having ongoing infrastructure issues for the last month...
09:02:13 <chriadam_> #topic Introductions
09:02:22 <chriadam_> Please introduce yourself with #info name/nick :-)
09:02:30 <chriadam_> #info Chris Adams, developer at Jolla
09:02:52 <dcaliste> #info Damien Caliste, community
09:02:55 <ljo_> #info Leif-Jöran Olsson, community
09:03:47 <chriadam_> abranson: are you online?
09:05:21 <chriadam_> we'll wait another 5 mins for people in case they're late.  in particular, abranson knows the OBS stuff which will be the main topic of today's meeting, I guess.
09:07:32 <abranson> yes sorry - am here!
09:07:59 <chriadam_> great!
09:08:02 <abranson> #info Andrew Branson, dev @ Jolla
09:08:05 <chriadam_> welcome everyone ;-)
09:08:14 <chriadam_> let's start on the agenda:
09:08:20 <chriadam_> #topic Follow-up Agenda Items From Last Meeting
09:08:43 <chriadam_> 1) I briefly investigated mer1822 and found the likely culprit, but have been busy with crypto stuff so haven't had a chance to reproduce / fix the issue
09:08:51 <chriadam_> I will hopefully get the time to do so before christmas
09:09:11 <chriadam_> 2) I merged one of dcaliste's caldav patches, but that made 2 other ones (30 and 32) conflict / need rebase
09:09:29 <dcaliste> I'm doing the rebase now…
09:09:36 <dcaliste> Will be ready in one hour.
09:09:40 <chriadam_> 3) I checked dcaliste's buteo-syncfw PRs, one of them causes public API break which I'll need to grep our sources ot see if it that might cause some issue
09:09:47 <chriadam_> dcaliste: no rush, huge thanks
09:10:16 <dcaliste> Great to hear news on 1822 ;)
09:10:34 <chriadam_> were there any other outstanding action items?  there's an outstanding carddav PR from a community member which fixes a bug, however it doesn't have a unit test - I don't know if the community member has the time to add that one or not...
09:11:01 <chriadam_> where were we at with the TODO stuff?  IIRC the nemo plugin PR had a couple of issues but was mostly ok
09:11:03 <dcaliste> For 3), you can skip the API break by removing the last commit.
09:11:16 <chriadam_> I forgot to check mkcal/kcalcore PRs...
09:11:17 <dcaliste> It's not mandatory to fix the issue.
09:11:25 <chriadam_> dcaliste: great, that'd be my preference
09:11:36 <chriadam_> to give me more time to check etc
09:11:52 <dcaliste> I pushed this commit because the API is broken and will give wrong values.
09:12:03 <dcaliste> Well not wrong, but useless ones.
09:12:24 <dcaliste> Namely it's the nextSyncTime() call.
09:12:41 <chriadam_> yeah, I don't disagree with your reasoning ;-)
09:13:06 <chriadam_> but need to make sure we transition existing clients before removing that api
09:13:17 <chriadam_> ah, the mkcal PR relies on caldav PR 32 which is being rebased
09:13:20 <chriadam_> I'll check that one again tomorrow
09:13:50 <chriadam_> ljo_: I haven't had time to follow TJC - is there any new issues there in particular which need attention?
09:14:50 <ljo_> No, it looks mostly good. Damien did a nice work.
09:14:57 <chriadam_> great
09:15:07 <chriadam_> ok, did I miss anything, or should we continue with the rest of the agenda?
09:15:15 <dcaliste> Just one minute…
09:15:29 <dcaliste> The MR!32 in Caldav is independant from mkcal MR.
09:15:56 <dcaliste> The mKCal MR is a base for a future caldav MR that is not pushed yet.
09:16:09 <dcaliste> It's on my disk but forgot about it.
09:16:15 <chriadam_> aha!  ok, I see
09:16:34 <chriadam_> I will review and merge that one tonight then, unless pvuorela_ finds some issue with it (mkcal MR#2)
09:16:39 <dcaliste> It allows to grep incidence in a time period not just before a given date.
09:17:00 <dcaliste> MR in mKCal is adding a new API to do this.
09:17:11 <chriadam_> makes sense, does that cover deleted items also?
09:17:37 <dcaliste> Yes, it is adding a condition in the database SELECT.
09:17:46 <chriadam_> great
09:18:05 <dcaliste> currently it is doing date < before, and I have added a AND date > after.
09:18:25 <dcaliste> So we can select the database within the same range than we are doing with the server.
09:19:37 <chriadam_> that will greatly improve our client code.  I remember adding some ugliness to the plugin to work around that limitation in mkcal.  Seems like the PR is quite small after all, I should have gotten my hands dirty...
09:19:54 <chriadam_> well, thank you very much for doing that.
09:20:09 <chriadam_> ok, let's continue with the rest of the agenda:
09:20:16 <chriadam_> #topic WebDAV sync discussion and next steps (mer:contrib OBS)
09:20:26 <chriadam_> I guess we need to discuss a few main things here:
09:20:36 <chriadam_> 1) what steps to take to get it building in OBS
09:20:46 <chriadam_> 2) what steps to take to pull that into Sailfish OS images
09:21:07 <chriadam_> 3) what might be necessary for us to add in closed-source code (e.g. account settings) to make it work
09:21:28 <chriadam_> 4) what migrations might be necessary for existing c*dav accounts to add webdav sync functionality (or not do this?)
09:21:35 <chriadam_> 5) ... what did I miss?
09:21:57 <dcaliste> Seems fine. It covers my own questioning.
09:22:05 <chriadam_> abranson knows much more about OBS than I, so I will hand over to him here ;-)
09:22:14 <abranson> ooh interesting
09:23:10 <dcaliste> Some context: I've coded a Buteo sync plugin for WebDAV, see https://git.merproject.org/dcaliste/buteo-sync-plugin-webdav
09:23:12 <chriadam_> dcaliste: can you outline precisely what the sync plugin implements currently, and how it's exposed?  I assume it's just a buteo client sync plugin, with some semantics specified for how/when to synchronise local/remote data within some specific folder? or?
09:23:30 <dcaliste> yes…
09:23:52 <dcaliste> It is using the Buteo framework (direction options, conflict resolution options…)
09:24:00 <abranson> well, anyone can get stuff built in obs, but to have more official projects building needs approval and creation by the IT guys
09:24:35 <dcaliste> It is waiting for an account setting that store the local folder to sync, and another for the server path where to sync to (or from).
09:24:49 <abranson> i'd previously requested a mer:core:contrib project, where we could build everything that ended up in contrib, but I think that scope was maybe too big
09:25:03 <dcaliste> It is exactly based on the caldav sketleton.
09:25:06 <abranson> so will have to talk to them about the best way to get stuff built so that people can just add the repo and try things out
09:25:28 <dcaliste> thank you abranson.
09:25:58 <abranson> so really we'd want the webdav plugin used by an account type
09:26:12 <abranson> e.g. owncloud/nextcloud, which already has cal and card?
09:26:55 <dcaliste> I've added it as a onlinesync account type, just like carddav and caldav.
09:26:58 <chriadam_> abranson: ok.  what might an ETA be on the OBS things?  and can you add instructions to the sfos wiki about how to do that stuff (i.e. how to submit repo to be built as package in mer:contrib, and how add mer:contrib on device to pull those built packages) once it's done?
09:27:04 <dcaliste> It's just a new onlinesync service.
09:27:59 <chriadam_> yes, account side we can add it to the caldav/carddav generic onlinesync account.  the account migration might be a bit of a pain but I think we can short-cut by saying "if you want webdav support, please delete and recreate your account", and just allow webdav support added in new accounts.
09:28:12 <abranson> chriadam_: i think including a package in the obs build should be something sailors set up when we include a project in contrib
09:28:24 <dcaliste> chriadam_, there is no necessity for migration.
09:28:36 <dcaliste> At least, I think so.
09:28:59 <chriadam_> abranson: so what is the process, if a contributor wants a project to be built in mer:contrib?
09:29:32 <abranson> well, asking in irc I think, or maybe at a meeting?
09:29:38 <dcaliste> In fact, it is adding some settings for existing account when entering the UI account page, but enable is set to false by default so the plugin is not activated.
09:30:03 <chriadam_> dcaliste: right, migration isn't needed if we just default to disabled, I agree
09:30:44 <abranson> maybe in here? should the scope of this meeting widen to general mer-contrib?
09:31:16 <chriadam_> sure, I don't mind.  But I adamantly don't want to be the person tasked with doing OBS related things, because I don't understand any of it ;-)
09:31:36 <abranson> i think it would be nice if people can ask for their branches of existing mer:core projects be forked into contrib and built
09:31:40 <dcaliste> About OBS, so the first step is to create a new project buteo-sync-plugin-webdav in git mer-contrib, so I can push there and make MRs for patches and new functionalities.
09:32:37 <abranson> chriadam_: yeah don't mind doing that at all - just have to find some scheme that lbt is happy with so we can build stuff and test it, and have other users test it, as a precursor to inclusion in the real mer:core
09:32:52 <chriadam_> dcaliste: I think abranson is saying that the OBS project in mer:contrib would have to be created by a sailor.  or maybe I misunderstood?
09:32:53 <abranson> tbh we could use it ourselves for testing new packages
09:33:23 <chriadam_> abranson: I agree.  some clearly defined process like: 1) it gets built in mer:contrib.  2) once it's been tested by community, we import into mer:core if we think it's good for core.
09:33:27 <abranson> dcaliste: yes I can create you a new project in mer:contrib for the webdav plugin. that's a good start
09:34:08 <chriadam_> but that first stage (how does it get built in mer:contrib?  what does the community contributor have to do other than ask us to create the OBS project, and what do we have to do to go from "git repo" to "building and webhooked" etc?
09:34:17 <chriadam_> ) needs ot be documented I think
09:34:23 <abranson> chriadam_: the granularity is I think something we need to think about. if we only have one mer:contrib obs project, then people who add the repo will get everything. that might not be good for stable testing
09:34:29 <dcaliste> I agree with your plans for OBS. So what is missing is a trigger so tag in git mer-contrib triggers rebuilds in OBS.
09:35:15 <abranson> i'm wondering if we should do something like the feature branches we do internally. so we have a mer:core:contrib:feature:mer### for each feature
09:35:56 <dcaliste> I agree that contrib should be based on features to avoid pulling all devel things.
09:35:59 <abranson> i could ask for a root mer:core:contrib project on merproject obs that I can admin, then we can use webhooks to build stuff in there
09:35:59 <chriadam_> I'm not a huge fan of feature branches, honestly, simply because it adds complexity.  but I agree that it does add granularity (allowing individual contributions to be tested independently...)
09:36:30 <dcaliste> Currently, what is simple though is to point people to the build directory of OBS, saying there are packages there for testing.
09:36:30 <abranson> that independent testing is crucial, otherwise broken and old things could cause real headaches
09:37:06 <chriadam_> abranson: hrm, fair point.  but I'd prefer e.g. mer:core:contrib:feature:webdav rather than per-bug feature repos, for example
09:37:29 <abranson> chriadam_: yeah, that's possible. it'd be nice to include bz in the loop though.
09:37:35 <chriadam_> well, I guess granularity is something we can iterate on later
09:37:40 <chriadam_> what's our current plant?
09:37:41 <chriadam_> plan*
09:37:55 <chriadam_> abranson: are you going to ask IT to give you a mer:contrib OBS project + admin rights?
09:38:02 <chriadam_> then are you going to set up a webdav project?
09:38:21 <chriadam_> do we need to create a mer-core/buteo-sync-plugin-webdav git repo, or can it build from dcaliste's git repo?
09:38:24 <abranson> https://sailfishos.org/wiki/Webhooks is the instructions for personal obs builds btw. we'd be doing this, but creating a contrib project for them rather than doing it in user home project I think
09:38:38 <chriadam_> huh I had no idea that page existed
09:39:19 <chriadam_> yes, having a "contrib" repo also makes it more "official"
09:39:23 <chriadam_> we can curate what goes into it
09:39:33 <chriadam_> and we can ask users to test those packages without needing to worry too much
09:39:36 <dcaliste> Thanks for the link. Currently, I was changing the service file by hand on OBS to trigger build from private projects.
09:39:48 <abranson> chriadam_: yes. i'll talk to them about how they think it should look. I think they'll have some specific ideas in mind for the obs projects
09:40:06 <chriadam_> indeed, I'll leave those details in your hands ;-)
09:40:32 <chriadam_> from my side, once there is something building in OBS, I will look at adding the accounts settings code to support it in there
09:40:38 <abranson> so people can already create their own git repos and obs builds. we need to create a stepping stone between those and the sailfish builds and repos
09:40:51 <chriadam_> yes
09:40:57 <chriadam_> and document that process
09:41:07 <chriadam_> and advertise somehow that such a process exists
09:41:08 <abranson> so a procedure for both of those transitions
09:41:20 <chriadam_> e.g. in the sailfish os community meeting
09:41:27 <abranson> i don't think I actually have sfos wiki edit rights yet. must ask someone about that...
09:41:39 <chriadam_> ask lbt
09:41:54 <chriadam_> we also need a process to give community members edit rights in the wiki
09:42:03 <chriadam_> so many things to do
09:42:04 <abranson> chriadam_: as a bit of a seed, would you like to use the contrib mechanism for staging for c*dav contributions, or is that too much complexity?
09:42:43 <chriadam_> abranson: interesting idea
09:42:49 <chriadam_> actually, that would be good
09:43:01 <abranson> i'm wondering if more contributions are actually an extension of this effort
09:43:46 <chriadam_> hrm, actually, let's put the c*dav contrib gating / testing on hold for the moment
09:43:48 <chriadam_> concentrate on webdav
09:44:02 <chriadam_> once we have something for that, we can look at expanding
09:44:27 <chriadam_> but there are concrete actions which need to take place for webdav sync at least, which should provide learnings and outcomes first, I guess.
09:44:32 <abranson> yep
09:44:52 <abranson> after that we can add c*dav builds into the contrib obs projects
09:44:56 <chriadam_> yes
09:44:58 <chriadam_> that'd be great
09:45:03 <chriadam_> what's our ETA on the OBS project?
09:45:41 <abranson> if the it guys are available enough to bang out the details, i'd like to see it created this week.
09:45:45 <chriadam_> I know everyone's super busy, but wondering if this webdav could be building in a mer:contrib feature repo before christmas
09:46:03 <chriadam_> ok, fantastic.
09:46:18 <abranson> i know they won't want to do it unless they know it's the correct approach, as there's a danger of nasty legacy if it's done wrong
09:46:32 <chriadam_> true
09:46:41 <dcaliste> Thanks all, that's great! I agree it should be done properly, not in haste.
09:46:48 <chriadam_> don't let my constant wish for haste get in the way of good architecture ;-)
09:47:29 <chriadam_> ok, so I guess we can wrap up this topic in the agenda
09:47:31 <chriadam_> actions:
09:47:46 <chriadam_> 1) abranson to ask IT about creating an OBS repo for mer contributions and giving him admin rights
09:48:02 <abranson> chriadam_: thanks for pushing it! it's very easy to get carried away with other tasks...
09:48:18 <chriadam_> 2) once that's done, abranson will create an OBS project to build dcaliste's webdav contribution
09:48:47 <chriadam_> 3) once that's done, chriadam will look at accounts settings code to allow clients to use that.  need to consider how to allow externals to test that... maybe just standalone installable packages with the patches applied...
09:49:01 <chriadam_> abranson: thank you for offering to do the OBS stuff.  it's greatly appreciated.
09:49:25 <chriadam_> and of course thanks to dcaliste for doing great work, and giving us good reasons to work out these contribution processes
09:49:42 <ljo_> +1
09:49:54 <chriadam_> ok, anything else on that topic, or shall we continue with agenda?
09:50:06 <dcaliste> To go back to your initial point list, some words about 3), as I said, it is adding a new service to existing onlinesync sync type, so the main UI for it exists already.
09:51:08 <dcaliste> The main issue is how to setup new credentials.
09:51:19 <chriadam_> dcaliste: yes, need to extend that one with field entries (for remote url as liek the other ones, and for local sync dir)
09:51:30 <chriadam_> IIUC
09:51:48 <dcaliste> Because currently the UI is checking credential on CalDAV or CardDAV actions…
09:52:19 <dcaliste> So I can only test on server without credentials…
09:52:43 <dcaliste> Is there a way to defined basic AUTH (login pass) wy commadline for a given account?
09:53:05 <abranson> is there a possibility to ask for some closed source stuff to be opened there? i don't know what the status of the accounts stuff is there
09:53:20 <chriadam_> https://sailfishos.org/wiki/Webhooks
09:53:22 <chriadam_> uh
09:53:37 <chriadam_> https://git.merproject.org/mer-core/buteo-sync-plugin-carddav/tree/master/tools/cdavtool
09:53:45 <chriadam_> that one has the code which does the credentials checking stuff
09:54:09 <dcaliste> Ah, great. I'll check this and adapt it to WebDAV if needed.
09:54:35 <chriadam_> (copy paste of the code from the jolla-settings-accounts setup code.  need to copy any changes made there back into j-s-a unfotrunately)
09:55:06 <chriadam_> it's not properly separated into a reusable component for reasons which are not very good.
09:55:42 <chriadam_> ok, let's continue:
09:55:49 <chriadam_> #topic Any Other Business
09:56:04 <dcaliste> There should e a separate package for DAV stuff because for calendar the importation / exportation code is also duplicated.
09:56:16 <abranson> dcaliste: https://git.merproject.org/mer-core-contrib/buteo-sync-plugin-webdav
09:56:25 <abranson> i made you master cos it's yours
09:56:30 <chriadam_> there was a TJC post about "event time changes to one hour later when syncing to caldav" which I noticed
09:56:58 <chriadam_> also the outstanding carddav PR needs a unit test but other than that LGTM
09:57:06 <dcaliste> abranson: great thank you.
09:57:20 <chriadam_> I don't have anything else to discuss :-)
09:57:48 <dcaliste> chriadam_: do you plan to create a new testing CalDAV package for TJC after last MRs inclusion?
09:58:02 <chriadam_> dcaliste: yes, after I merge those two rebased PRs
09:58:27 <dcaliste> About the shift to one hour later on TJC, I asked the guy some logs but I didn't find the root for it.
09:58:37 <chriadam_> actually, I just remembered I'm away tomorrow, so wednesday is the earliest I'd be able to do that
09:59:17 <dcaliste> chriadam_: no problem.
10:00:07 <chriadam_> thanks again to everyone for their contributions.  really appreciated.
10:00:19 <chriadam_> if nothing else, I will close the meeting!
10:00:25 <abranson> chriadam_: and thank you for keeping all this in the air!
10:00:48 <ljo_> Daylight savings? I have seen some roundtrip problems there, but have not had any proper investigation.
10:00:52 <dcaliste> Thank you all for keeping this alive internally also (and make it grows also).
10:00:56 <chriadam_> up in the air is about right.  this last month I've gotten very little done in this domain, no internet access makes it tricky ;-)
10:01:03 <chriadam_> ljo_: definitely sounds DST related to me
10:01:31 <chriadam_> well, let's see if some logs get posted, might help
10:01:38 <chriadam_> ok, gnight everyone :-)
10:01:40 <chriadam_> #endmeeting