08:00:18 <Jaymzz> #startmeeting Sailfish OS, open source, collaboration – 16th May 2019
08:00:18 <merbot> Meeting started Thu May 16 08:00:18 2019 UTC.  The chair is Jaymzz. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
08:00:18 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:28 <Jaymzz> #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2019-May/008601.html
08:00:35 <Jaymzz> I am the meeting’s chairperson today, and will be doing my best to keep time and order. Please behave, respect the timings and be gentle.
08:00:45 <Jaymzz> #topic Brief introduction (5 min). Please prefix your name/handle with # info
08:00:53 <Jaymzz> #info James Noori - sailor @ Jolla
08:01:44 <flypig> #info David Llewellyn-Jones - also Sailing @ Jolla
08:01:47 <ViGe> #info Ville Nummela - sailor @ Jolla
08:01:57 <lbt> #info David Greaves - Mer guy and sailor
08:02:04 <sledges> #info Simonas Leleiva - privateer 4 Jolla
08:02:18 <runvgn> #info Walter Justen,  community member
08:02:27 <ced117> #info Cedric Heintz, community member
08:02:41 <zotan> #info Simon Brown, community
08:02:49 <M4rtinK> #info Martin Kolman, modRana developer & community member
08:06:32 <Jaymzz> #topic Do you plan to migrate projects from github/sailfishos to git.sailfishos.org ? (20 min - Asked by dcaliste)
08:06:43 <Jaymzz> #info dcaliste had to leave and can’t attend the meeting with us today, but we will anyway answer the topic so he can read the logs later.
08:06:53 <Jaymzz> #info As for github/nemomobile which was migrated to git.merproject.org when the latter was setup, do you plan to migrate github/sailfishos to the new git.sailfishos.org ? As Mer was only for middleware and lower levels, this will bring higher level stack (like sailfish secrets) and even applications (like office viewer or browser) into the sailfishos open source repositories. Will they land into mer-core there ? Or to a new group ?
08:06:53 <Jaymzz> The immediate (and sole?) benefit would be to have everything gathered under the same place, making things easy to find or browse. Additionally, this would open the later possibility to include them in a possible SailfishOS CI or bug tracker.
08:08:01 <lbt> #iinfo This is something we're still thinking about. There are both costs and benefits. Also, as you note there are open questions about bug tracking systems which may factor into this decision
08:08:27 <lbt> #info The nemomobile migration was also about a consolidation into a single mer-core - there isn't really a similar architectural drive here. Nor are there issues with the service
08:08:44 <lbt> #info Overall I think this specific move is not a high priority right now
08:09:22 <lbt> So basically - lets see what happens with the move we're making to git.sfos.org with the mer-core
08:09:32 <lbt> and how the bug tracking and workflow evolves
08:09:34 <M4rtinK> Also many more.potential contributors have a GitHub account, that Sailfish OS Gitlab account.
08:09:52 <lbt> once we have a handle on that then we'll see about consolidating
08:09:59 <M4rtinK> That may be also something to think about.
08:10:11 <lbt> M4rtinK: whilst that's true it's not too hard to get a login
08:10:29 <lbt> also there are issues with some countries and github
08:10:40 <lbt> which may be a factor down the line
08:10:48 <M4rtinK> yeah, especialy as IIRC it should be possible to use regular Jolla account, right ?
08:10:59 <lbt> that's the goal
08:11:13 <lbt> I need to work on the ldap stuff with Pami
08:12:00 <lbt> personally I'd like to consoldiate - it's neater :D :D
08:12:39 <lbt> Since dcaliste isn't here are there any other comments?
08:14:40 <lbt> I think we can move on Jaymzz :)
08:14:48 <Jaymzz> lbt: you got it
08:15:21 <Jaymzz> ApBBB: are you available for you topic that's coming up now?
08:15:28 <ApBBB> yep
08:15:34 <Jaymzz> alright let's do this
08:15:48 <Jaymzz> #topic: Fragmentation between open repos and the Jolla store and effort to bring more apps in the store. (20 min – asked by ApB)
08:15:59 <Jaymzz> #info Lets face it the store isn't in a great state shape when it comes to apps while openrepos seems to have much better days and some extremely useful and well made apps (hint mapping). Its been discussed in the past that some steps need to be taken to get more of them in the store -lifting limitations etc-. So. What is the status of it, what needs to be done and who at jolla can help solve this and not continue to have two "app s
08:16:00 <Jaymzz> tores".
08:16:32 <ApBBB> Dont have much to add question wise. The description prerry much says it all. So i am listening
08:16:36 <Jaymzz> ApBBB: there is already an answer pre-written for this, right before the meeting. So I'll put that here and you discuss it.
08:16:45 <ApBBB> ok
08:16:46 <Jaymzz> #info So far the allowed API list has been limited those APIs which are considered stable. That means that we have enough faith that we will not break the APIs in future versions, i.e. apps built for APIs which are approved today will keep on working in the future Sailfish OS versions. We have always had the plan of allowing more APIs, but the progress has been slow. As we move forward, we have basically two options: either stabiliz
08:16:47 <Jaymzz> e more APIs, or allow APIs which are not yet stable (and risk breaking apps in the future). The first option is always preferred, but the decision must probably be made on a case by case basis.
08:18:19 <M4rtinK> I don't think the option number one really proved doable.
08:19:52 <M4rtinK> While not official APIs we had apps broken by API changes before (packagekit, libpython, ICU, zlib, etc.) and they have been fixed by the community in short order.
08:20:20 <ViGe> M4rtinK: That is a good point
08:20:43 <ApBBB> on apps that have active development things are "easy" to be fixed during the early access period. the problem seems to be with apps that are abandoned
08:20:52 <M4rtinK> Guaranteeing a stable API that's actually enough for.most apps is a very big task.
08:21:13 <lbt> I wonder if there's a solution based on removing apps which use unstable APIs and break
08:21:38 <lbt> This is mainly a "normal user" issue
08:21:44 <M4rtinK> ApBBB: abandonned apps will unfortunately break sooner or later anyway, especially if using any online APIs
08:22:13 <flypig> It's worth pointing out that it's not just about stability. It's also about resource usage, security, etc.
08:22:14 <ViGe> M4rtinK: I think in many cases it really boils down to what is considered stable. As our old definition of not breaking apps in the future updates is not really feasible, I think we need to come up with a better definition.
08:22:19 <M4rtinK> but we have seen many cases where abandonned apps have been reviwed by another party
08:22:26 <lbt> so they install an app - can it say "This app uses experimental features. It may not work in future versions of the OS"
08:23:18 <M4rtinK> flypig: good point about security, an app might still continue working but have unfixed vulnerabilities
08:23:51 <ApBBB> security is a separate issue i think.
08:23:55 <lbt> Meh - the security thing seems a red herring
08:24:00 <flypig> M4rtinK, also a question about what capabilities an API gives access to.
08:24:17 <M4rtinK> In any case, if we want to make less-stable API usage allowed, we need to adjust the infrastructure a bit at least.
08:24:47 <ApBBB> BTW is APIs that block most of the openrepos apps??
08:24:57 <ApBBB> this fragmentation is really bad IMO.
08:25:25 <flypig> ApBBB, not just that. Also multiple executables, having dependencies, daemons, I think.
08:25:25 <M4rtinK> If anyone followed the issues OSM Scout Server had with the ICU upgrade, it's a good example what is currently broken and could be improved.
08:26:03 <M4rtinK> flypig: actually just the systemd socket activation requirement
08:26:12 <lbt> flypig: that's something we've debated before too - and there are tentative solutions
08:26:19 <M4rtinK> flypig: all else was store compatible
08:26:21 <ApBBB> OSM scout should be in the core os.
08:26:29 <M4rtinK> flypig: due to bundled libs
08:26:29 <ApBBB> for others to build apps on it.
08:26:30 <flypig> Yeah, I'm talking in general. I've had apps blocked for those reasons.
08:27:14 <ViGe> I don't think it's really feasible to target getting rid of openrepos completely. But we could definitely allow more APIs (and more apps) in Jolla Store.
08:27:33 <lbt> What about the point I made above?
08:27:36 <ApBBB> is the systemd socket activation a big issue for jolla??
08:27:55 <M4rtinK> Anyway, main unstable api usage pain points: - OBS targets are published late (after stable release), nobway to publish two versions, one for older SFOS (due to port not yet updated to latest).
08:28:31 <lbt> M4rtinK: can you info that
08:28:37 <M4rtinK> lbt: I dont mind any scary warnings myself - soon every active app would.have it anyway. :)
08:28:48 <ApBBB> the topic is not about getting rid of open repos. its has its place for experimental or early/beta or whatever. The problem is that many usefull things from there cant be pulled into the main store
08:28:52 <M4rtinK> lbt: sure
08:29:09 <lbt> M4rtinK: we need to support normal users though
08:29:19 <lbt> but warnings may be a way to handle it
08:29:19 <M4rtinK> #info Anyway, main unstable api usage pain points: - OBS targets are published late (after stable release), nobway to publish two versions, one for older SFOS (due to port not yet updated to latest).
08:29:50 <lbt> even flag the store to not show 'experimental' by default
08:30:43 <flypig> lbt, that's a nice approach.
08:31:27 <Jaymzz> 5 min left of this one :)
08:31:44 <M4rtinK> Normal Linux distros can handle both properly - per release build targets are immediately available once development of a release starts and one can publish apps fort 2-3 active releases for users who have not yet upgraded to latest.
08:32:02 <ApBBB> anything that has to be done by sailors to get this going???
08:33:14 <flypig> What's seen as the first priority? systemd socket activation? Maybe focus on that.
08:33:39 <M4rtinK> flypig: +1
08:33:50 <lbt> mmm
08:33:56 <ViGe> flypig: I have a feeling systemd socket activation will have a LOT of resistance. If we focus on that I can almost guarantee we won't get anywhere.
08:33:58 <lbt> that's not really an API
08:34:22 <lbt> more things like Qt positioning
08:34:31 <M4rtinK> flypig: it is really a huge shame likely the best FOSS navigation system has to live on the edge
08:34:49 <flypig> M4rtinK, I totally agree.
08:34:51 <M4rtinK> lbt: do you men qt location ?
08:35:07 <ApBBB> flypig: anyone we can beg?? :P
08:35:08 <lbt> yeah
08:35:10 <M4rtinK> lbt: positioning has been allowed for ages, thankfully
08:35:16 <flypig> ha ha ;)
08:35:30 * lbt doesn't write enough code anymore :D
08:35:33 <M4rtinK> lbt: and thats for Poor Maps, server does not need qt location
08:35:40 <ApBBB> flypig: or send beer or donuts or whatever
08:35:56 <lbt> my point is that we could identify APIs at that level
08:36:03 <Jaymzz> ApBBB: I'm giving this a few extra minutes since the last topic got cut short :)
08:36:05 <lbt> and then know when they are removed
08:36:08 <M4rtinK> also modrana does not use qt location and is in store (in cut down form)
08:36:11 <ApBBB> Jaymzz: ok.
08:36:12 <flypig> ApBBB ;)
08:36:17 <lbt> and remove apps which are experimental on upgrade
08:36:25 <M4rtinK> so osm scout server in store would already help
08:37:32 <M4rtinK> lbt: removing apps would imho.be also fine if theor API broke and they were not.fixed
08:37:46 <lbt> right - but only if we said so on install
08:38:07 <lbt> "this app uses experimental features and may be removed on upgrades"
08:38:08 <flypig> As a user, I might choose not to upgrade if I knew it would remove some of my apps.
08:38:26 <M4rtinK> lbt: same thing happens in Fedora - if an app is abandonned and no one else picks it up, it will be dropped and no longer in the repos in next release
08:38:50 <lbt> M4rtinK: but we're talking removal - not no longer available
08:38:54 <pvuorela> and actually even if there was a version available for os update, it would still need to be removed on update and reinstalled afterwards.
08:39:34 <M4rtinK> if it breaks upgrade path it will be removed as well during Fedora upgrade
08:40:00 <abranson> something that's come up before - apps built on the community obs from source would be rebuilt for each release, and so automatically validated
08:40:16 <abranson> could allow more libs to be used for apps that do that
08:40:53 <ApBBB> abranson: will there be a problem treatin apps per case ????
08:40:58 <M4rtinK> abranson: yep, that would help a lot (and again, Fedora does basically this for all packages via regular per release mass rebuilds)
08:41:04 <lbt> the issue here is how much work it would be to support it in harbour and in the client
08:41:36 <abranson> ApBBB: all apps are per-case for approval anyway. if anything it would automate some CI work
08:41:44 <M4rtinK> abranson: in many cases library upgrades are source compatible and rebuilding the app linking the lib is enough
08:41:56 <abranson> yep, especially when pkgconfig is used
08:42:10 <ViGe> So here are at least some action points for us sailors: 1) evaluate possibility to mark apps as experimental 2) evaluate possibility to allow systemd socket activation. Anything else or is this enough for us to get started?
08:42:16 <M4rtinK> abranson: and if it still.fails to build you now have an early warning fixing is needed
08:42:17 <pvuorela> was asked already, but for alternative path for getting more stuff in, i'd be curious what apis getting stabilized would allow most apps in the normal way.
08:43:00 <lbt> ViGe: I think so
08:43:00 <M4rtinK> ViGe: sounds good to me
08:43:01 <abranson> pvuorela: i don't think apis are the biggest issue atm. more the other stuff like daemons and multiple executables
08:43:38 <lbt> ViGe: we also need to find how many APIs are in the OS that apps want to use but we prevent due to being unstable
08:43:47 <ApBBB> ViGe: pure maps neeeeeeeeeeeeeeeeeddddddds to be in the store.
08:44:33 <M4rtinK> pvuorela: from.top of my head: socket activation, qt location, various nemomobile dbus apis such as screen blanking and wakelock control
08:44:50 <ViGe> ApBBB: pure maps needs also libkeepalive, which hasn't been even mentioned in this discussion yet...
08:44:59 <Jaymzz> ApBBB: how much more time do you think is needed?it's now 10 min over time
08:45:15 <pvuorela> keepalive about to be stablized: https://git.merproject.org/mer-core/nemo-keepalive/merge_requests/13
08:45:19 <ApBBB> Jaymzz: no idea TBH.
08:45:24 <pvuorela> after that gets in, we can allow it.
08:45:31 <M4rtinK> the two lst thing are stripped from.the modRana available on Store, so.it cant keep.screen on or record tracklogs in the background
08:45:42 <pvuorela> qtlocation hopefully solved sooner or later too.
08:45:44 <M4rtinK> while the Open Repos version can do it
08:45:50 <Jaymzz> ApBBB: ah well the discussion is pretty warm and technical, so I'll let it be for the time being
08:46:02 <flypig> Jaymzz, can we add ViGe's suggested action points to your list? It'd be good to track them.
08:46:25 <ApBBB> Jaymzz: i am not a technical person. you can handle the timing thing
08:46:28 <M4rtinK> ViGe: I've mentioned it :)
08:47:05 <M4rtinK> ViGe: and I'm sure more apps require some screen control wakelock control (media players ?)
08:47:09 <Jaymzz> flypig: Yes, already on it
08:47:19 <flypig> :)
08:47:58 <Jaymzz> alright if there's nothing more, and we can take this in another meeting and track the action points then, I can move on
08:48:27 <Jaymzz> #action 1) evaluate possibility to mark apps as experimental 2) evaluate possibility to allow systemd socket activation.
08:49:17 <ApBBB> move on i guess
08:49:31 <Jaymzz> yeah doing that
08:49:44 <Jaymzz> #topic general discussion (30 min)
08:49:44 <ApBBB> i'll probably ask for an update in two meeting time or so
08:49:53 <Jaymzz> ApBBB: sounds great! '
08:50:07 <Jaymzz> #undo
08:50:07 <merbot> Removing item from minutes: <MeetBot.items.Topic object at 0x3916290>
08:50:17 <Jaymzz> #topic general discussion (15 min)
08:50:53 <Jaymzz> anything to discuss/ask here?
08:51:36 <ApBBB> flypig: i have a question since you fixed the idle bug. Are the covers of the app late to upgrade on the status?? ie after a network change if you minimize the app it shows "Just Now" and if you go back to the app and minimize again shows "Up to Date"
08:52:16 <ApBBB> most likely is just a visual thing
08:52:44 <flypig> ApBBB, they shouldn't be. As far as I'm aware the cover shows the correct value. But there could be a bug in this of course.
08:52:58 <ApBBB> i also notice somethin similar when i erase an sms. delete > minimize > go back in the app > shows it for a brief moment
08:53:38 <flypig> ApBBB, how long does it take for the cover to show "Up to Date"?
08:54:06 <flypig> I mean, if you just leave it in the minimised state.
08:54:20 <ApBBB> flypig: hmmm. i need to test that.
08:55:04 <flypig> There's an update cycle that happens in the background which the cover responds to. I can take 20 seconds or so to go through. If it's longer than that, then that could well be a bug.
08:55:20 <flypig> *It* can take
08:55:40 <ApBBB> i'll need to test. in case i find something i'll let you know
08:55:46 <flypig> ApBBB, great, thank you!
08:57:11 <Jaymzz> Anything else here gents? :)
08:57:35 <lbt> ApBBB: do you ever notice the clock app show the wrong time on the cover for an instant too? Is it like that?
08:57:51 <ApBBB> flypig: ok. seems to take more than 20 sec. to test open the email app > minimize it > turn off wifi > wait a bit and then turn it on.
08:58:10 <M4rtinK> Jaymzz: is the current quick update cadence going to continue ? I like it! :)
08:58:15 <flypig> ApBBB, okay, I'll give that a go.
08:58:40 <flypig> ApBBB, do you keep mobile data on during that?
08:58:44 <ApBBB> yes
08:59:29 <ApBBB> it basically has to switch to mobile data and back to wifi
08:59:58 <flypig> ApBBB, are you talking only about the transition from "Just now" to "Up-to-date"?
09:00:05 <Jaymzz> M4rtinK: Well I would love to say yes, but it depends on so many things that I just can't have a direct answer for it...
09:00:24 <ApBBB> flypig: yes
09:00:58 <M4rtinK> Jaymzz: ok, thanks :)
09:01:14 <ApBBB> i was testing it now and didn't go back to up to date untill i turned flight mode on and off
09:01:36 <flypig> ApBBB, that's not right. It's never moving off "Up-to-date" here. We should discuss further, probably with some logs.
09:02:09 <ApBBB> hmmm. i'll test a bit more.
09:03:20 <Jaymzz> 2 minutes on this one
09:03:57 <Jaymzz> I'm moving on before another discussion starts to avoid overtime ;)
09:03:59 <Jaymzz> #topic next meeting time and date
09:04:29 <Jaymzz> #info Next meeting will be held on May 30th 2019 at 08:00 UTC
09:05:27 <Jaymzz> And that was it for this meeting. Action points mentioned above will be added to the pad, in order to keep track and follow for the next meetings. Otherwise, thanks to you all for particpating today!
09:05:52 <flypig> Thanks Jaymzz!
09:06:11 <Jaymzz> cheers :) bye all! (minutes will be sent shortly as well)
09:06:14 <Jaymzz> #endmeeting