14:30:52 <iekku> #startmeeting SailfishOS, open source, collaboration: 21-May @ 14:30 UTC
14:30:52 <merbot> Meeting started Thu May 21 14:30:52 2015 UTC.  The chair is iekku. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
14:30:52 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:31:05 <iekku> #info Welcome to another week of SailfishOS OSS and collaboration meeting
14:31:07 <iekku> #info Meeting info and agenda: https://lists.sailfishos.org/pipermail/devel/2015-May/006099.html
14:31:39 <iekku> sorry for the hassle with starting time
14:31:47 <iekku> #topic Brief introductions (5 min), prefix your information with #info
14:31:50 <daitheflu> np :)
14:31:54 <kimmoli> #info Kimmo Lindhol, tohs et al. Community.
14:31:58 <Stskeeps> #info Carsten Munk, Chief Research Engineer @ Jolla
14:32:04 <KeeperoftheKeys> So is it now or later?
14:32:17 <iekku> #info Iekku Pylkk�, Developer community sailor @ Jolla
14:32:19 <iekku> now
14:32:40 <coderus> #info Andrey Kozhevnikov, indie opensource developer
14:32:53 <sledges> #info Simonas Leleiva, sailor porter and pootler @ Jolla
14:33:00 <pketolai> #info Pami Ketolainen, developer @ Jolla
14:33:22 <daitheflu> #info François Kubler, community
14:33:26 <Tofe> #info Christophe Chapuis, community
14:33:27 <jpakkane> #info Jussi Pakkanen, SDK lead developer @ Jolla
14:33:31 <stephg> #info Steph Gosling, community
14:36:15 <iekku> #topic Opensourcing and allowing to use jolla qml components - coderus (15 min)
14:36:32 <iekku> #info some details about the topic: there are many cool proprietary qml components made by jolla: CameraExtensions, TextLinking, Email ComposerPage, Gallery ThumbnailImage/Video, Sailfish.Pickers (including allowing to use QtDocGallery), TransferEngine. It's always pain to develop applications using camera/email/gallery(filesystem)/thumbnailing, because every developer should implement own hacks for application and can't use native components. If i
14:36:39 <iekku> coderus, please
14:36:46 <coderus> thanks, iekku
14:36:49 <locusf> hmm merbot isn't opped
14:37:09 <coderus> so, if topic is not enough described - tell me
14:37:11 <sledges> thanks Chanserv
14:37:29 <Stskeeps> well, it got cut off at "if i" :)
14:37:46 <Stskeeps> which means iekku needs to start using splitlong.pl irssi script ;)
14:37:56 <iekku> :D
14:37:59 <coderus> there are a lot of cool components used in jolla apps which are not allowed to use in 3rd party projects
14:38:08 <iekku> Stskeeps, works on my screen :P
14:38:40 <locusf> also a lot of contact management middleware
14:38:48 <locusf> sorry I forgot to info :p
14:38:49 <Stskeeps> there's two sides of this, one is that they're currently closed source, and second, that they're not considered API stable and possibly uses unstable APIs underneath
14:38:57 <iekku> #info details continue: If it's not possible (please tell us why) then it will be great to have these components opensources so developer can compile and bundle it to application.
14:39:29 <Stskeeps> there's a few of those i'd say makes sense to take a deeper look at, but i don't carry any news about open source today
14:39:52 <coderus> what status of Sailfish.Pickers?
14:40:02 <iekku> #info  there's two sides of this, one is that they're currently closed source, and second, that they're not considered API stable and possibly uses unstable APIs underneath
14:40:18 <Stskeeps> we have a new SDK lead, as you may notice, so talking to him on what could possibly be done, might be a good start :)
14:40:34 <iekku> #info there's a few of those i'd say makes sense to take a deeper look at, but i don't carry any news about open source today (Stskeeps)
14:40:36 <Stskeeps> we're currrently doing quite a lot of work on sailfish 2.0 ui which has deep impact on many of the shared components as well
14:40:40 <coderus> we're actually using it with our harbour apps, but with hack to hidde usage from QA to get passed to Jolla Store
14:40:54 <iekku> #info we're currrently doing quite a lot of work on sailfish 2.0 ui which has deep impact on many of the shared components as well
14:41:31 <coderus> the other side is for example Sailfish.Silica component, which is allowed to use, but contains many undocumented components inside, like Formatter
14:41:33 <Tofe> Isn't API stability covered by the use of QML  module versionning ?
14:41:48 <Stskeeps> QML module versioning isn't always working the way you'll want it to, from what i understand
14:42:01 <Stskeeps> but i'm personally a bit out of my depth in that area :)
14:43:36 <Stskeeps> to conclude a bit: 1) i don't have any details on open sourcing these components currently 2) to be supported in harbour they need to be reasonably api stable 3) quite a lot of work going on that impacts every UI-level component, due to sailfishos 2.0 ui, so api stability is first expected after that and 4) we have a new SDK lead, jpakkane, who will be a great entry point for topics like this in the future :)
14:43:36 <Tofe> Maybe that's worth a check, as Qt has now used QML versioning for quite some time
14:43:58 <coderus> Stskeeps: so, tell then if something will change with SFOS 2.0? Will be TransferEngine, EmailComposer, SailfishPickers (including allowing to use QtDocGallery), GalleryThumbnails and other components available for developers who want to publish apps to Jolla Store?
14:44:20 <Stskeeps> coderus: i can't confirm that, but it would probably be easier at that point.
14:44:28 <Stskeeps> to make that decision
14:44:42 <iekku> #info 1) stskeeps: i don't have any details on open sourcing these components currently 2) to be supported in harbour they need to be reasonably api stable
14:44:58 <iekku> #info 1) stskeeps: 3) quite a lot of work going on that impacts every UI-level component, due to sailfishos 2.0 ui, so api stability is first expected after that and 4) we have a new SDK lead, jpakkane, who will be a great entry point for topics like this in the future :)
14:45:02 <coderus> as far i understand: nothing will change in current sailfishos iteration, and any positive changes can be expected only after sfos 2.0 being stable in future?
14:45:13 <iekku> #action iekku to get jpakkane to next collaboration meeting
14:45:18 <Stskeeps> iekku: he's here.. ;)
14:45:19 <Yaniel> re API stability: can't apps just be restricted to OS versions where the API has not changed?
14:45:27 <jpakkane> The problem with providing numbered versions of unstable libraries is that we would need to keep maintaining all of them. So suppose there is a library that releases rapidly 1.0, 1.1, 1.2 etc until 1.30. Since we can't know which versions are used by apps we would need to keep maintaining them all.
14:45:36 <iekku> Stskeeps, i should open my eyes
14:45:48 <Stskeeps> coderus: let's say released instead of stable
14:46:09 <coderus> Stskeeps: i mean being stable after it will be released of course
14:46:13 <Stskeeps> nod
14:46:28 <coderus> or should we expect to have some api to be available jsut after new os will be released?
14:46:39 <coderus> just*
14:46:40 <Stskeeps> hard to make such promises currently, just saying it's easier :)
14:46:40 <iekku> 5 minutes
14:46:48 <Stskeeps> which means it may happen
14:47:17 <Stskeeps> focus is on getting 2.0 out the door
14:47:49 <coderus> Then tell, what is main problem to make some components available for developers right now? Most of them are stable, small and simple working
14:48:19 <coderus> having such api available mking developers live easier and attract more developers to develop something at all
14:48:35 <Stskeeps> main problem is that it takes up developer time to clarify that they are going to stay stable, have them documented and have maintainer for them in the future
14:48:39 <Stskeeps> and i agree
14:49:12 <Stskeeps> an api is a commitment to it staying around :)
14:49:37 <iekku> 2 minutes
14:50:08 <daitheflu> Stskeeps: an api is also something that makes a platform attractive or not :)
14:50:12 <Stskeeps> indeed
14:50:15 <coderus> there are many cool things in sailfishos currently which have no way to be used by developers because some api problems, and i just see nothing changed since 1.0.0.5. So, best hopes it will be better after releasing 2.0
14:50:43 <Stskeeps> i'd say what you listed is a good start to get evaluated
14:50:55 <coderus> we CAN use it, but we CAN'T have apps in Jolla Store this way This is the most sad thing here.
14:51:36 <Stskeeps> so, i think we can take an action to see what can be done about those apis?
14:51:49 <coderus> so, i hope you will make sfos 2.0 more attractive for developers too, not only for users
14:52:02 <Stskeeps> yep, there's many good reasons to do so, especially now
14:52:59 <iekku> #action evaluate how jolla could open TransferEngine, EmailComposer, SailfishPickers (including allowing to use QtDocGallery), GalleryThumbnails and other components
14:53:06 <iekku> did i miss some?
14:53:23 <kimmoli> Sailfish.Media maybe
14:53:27 <Yaniel> account stuff?
14:53:46 <coderus> also someone can tell something about nemomobile components? or the same applied also?
14:54:01 <Stskeeps> well, at least they're open :)
14:54:03 <iekku> #action evaluate also Sailfish.Media and account
14:54:09 <Stskeeps> but yes, nemo components could be good too
14:54:23 <coderus> Stskeeps: i mean allowing for developers
14:54:27 <Stskeeps> yep
14:54:42 <coderus> i'm thinking and can't say any one component whish is allowed to use in harbour apps
14:54:50 <coderus> which*
14:55:48 <iekku> #action evaluate how nemomobile components could be allowed to Harbour
14:56:06 <iekku> ok, we have run out of time
14:56:42 <iekku> thank you coderus for topic
14:56:45 <iekku> #topic General discussions - everyone (10 min)
14:56:57 <coderus> thank you for making this meeting for my topic :D
14:57:26 <iekku> this is kind of funny timing, but after we announced QtPositioning opening we had huge amount of new apps
14:57:29 <iekku> so..
14:57:31 <iekku> #info Harbour QA team asks to wait until official SDK release note has been sent with new accepted APIs before submitting app to Harbour. If app is submitted too early it will be rejected because of not allowed API.
14:58:15 <coderus> jpakkane: can i ask you about SDK updating stuff?
14:59:21 <jpakkane> coderus: Sure, but I have only just recently started working here so I might not be fully up to speed yet.
15:01:05 <coderus> jpakkane: i just want to have linux native way of updating build vm. downloading sdk every time and reinstalling everything is not what i expect to have.
15:01:43 <coderus> qt modules should update itself, mer vm and target should update itself. you should not force everybody to download new sdk again and again and again :)
15:01:52 <coderus> qtc modules i mean*
15:02:56 <jpakkane> Yes, this would be useful. Unfortunately doing updates is quite tricky. E.g. every new Ubuntu or Fedora update always leads to broken installs for people.
15:03:39 <coderus> bt sdk vm have no peripherals or something.
15:03:44 <jpakkane> But we'll see if we could do something with that. Maybe only update the rootfs files and not the rest of the build vm.
15:04:01 <coderus> currently i'm not reinstalling vm and doing ssu re $VERSION and zypper up
15:04:28 <Stskeeps> (any other questions/discussion topics while we're at it?)
15:04:33 <coderus> and it always working fine, and i personally see nothing can be broken
15:04:41 <jpakkane> There are a _lot_ of things that can break. As an example when your C++ compiler updates its ABI (which happens every now and then). Most of the time it will work, yes. But every now and then there is potential to fail hard.
15:04:48 <coderus> Stskeeps: no, only one topic anout qml stuff here :)
15:05:11 <iekku> 1 minute
15:05:15 <coderus> jpakkane: so, i mean packages update scripts should worry about it
15:05:21 <Yaniel> how about streamlining the process of developing non-qt apps a bit
15:05:50 <iekku> Yaniel, sounds like own topic to me?
15:06:04 <jpakkane> Yaniel: I have a task on my plate to do a proper tutorial on how to use external build systems and/or SDL apps.
15:06:06 <Yaniel> yes, it certainly would warrant that
15:06:24 <iekku> lets move on
15:06:29 <iekku> #topic Wrap up and next meeting (10 min)
15:07:05 <iekku> 2 weeks from now would be 4th of june
15:07:20 <iekku> and it's busy day for sailors
15:07:41 <iekku> is 3 weeks too far?
15:07:58 <iekku> 11th of june, 14:30 UTC ?
15:08:52 <coderus> depends on haw many topics you will receive :)
15:09:46 <iekku> if we look back, 3 weeks might be too soon :P
15:10:08 <iekku> but i'd rather keep on going with 2 weeks, if we have enough to talk
15:10:58 <iekku> 11th of june, 14:30 UTC going once
15:11:35 <iekku> twice
15:12:11 <iekku> sold
15:12:34 <iekku> #info next meeting 11th of June, 14:30 UTC, chair: cybette?
15:12:49 <iekku> thank you all for joining the meeting
15:13:33 <iekku> #endmeeting