15:00:07 #startmeeting SailfishOS, open source, collaboration and way forward 15:00:07 Meeting started Tue Apr 22 15:00:07 2014 UTC. The chair is cybette. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 15:00:07 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:07 * AL13N_work lurks 15:00:17 Welcome to the SailfishOS Community meeting! I'm the meeting chair for today and will be keeping strict timeboxes. 15:00:24 I've just spent the whole Easter weekend perfecting the art of tossing away things that are useless and get in the way, so take that as a warning that I won't hesitate to act on those misbehaving. 15:00:31 Let's keep it civilized, and have a productive discussion! 15:00:39 We'll start with a round of introductions: 15:00:42 \o/ 15:00:47 #topic 1. Introduction of meeting participants 15:00:55 #info Carsten Munk, Chief Research Engineer @ Jolla 15:00:56 preface your intro with #info, briefly say who you are and why you are participating in this meeting 15:01:02 time: 5 minutes (until 15:05 UTC) 15:01:05 #info Thomas Ruecker, a community member 15:01:11 #info Carol Chen, usually Community chief at Jolla, hatless meeting chair for today. 15:01:15 #info Aleksi Suomalainen, a community member for Nemomobile 15:01:19 #info would like to consider myself a community member of mer/nemo projects doing mainly device adaptation work. Other hat, working with a vendor internally on a product based on Mer 15:01:21 #info Steph Gosling Sailfish and Nemo community member 15:01:27 #info Vesa-Matti Hartikainen, Jolla, developing browser 15:01:40 #info Basil Semuonov - openrepos founder 15:01:49 for those who just joined, we are doing intros now for 5 min 15:01:51 cybette: can you please voice sailors for clarity? 15:01:53 #info lbtI look after the public Mer infra, mer-tools and the Mer SDK which provide systems and tools to enable contributions. Systems includes stuff like bugzilla, gitlab, OBS, IMG, BOSS etc etc 15:01:56 preface your intro with #info, briefly say who you are and why you are participating in this meeting 15:02:02 tbr: ok 15:02:07 #info Simonas Leleiva, in Mer/Nemo community since 2012, Nemo twitter account maintainer, SailfishForAndroid developer @ Jolla 15:02:19 #info community member and generally interested in how the Jolla is moving forward into the OSSea 15:02:33 #info Andrea Bernabei, Nemomobile contributor/hacker. Jolla user and supporter 15:02:41 hehe 15:02:42 oops 15:03:03 this is not the way to silence your co-workers .. ;) 15:03:04 #info Raine Makelainen, Jolla, developing Browser 15:03:12 #info VDVsx, SW developer at Jolla, Mer/nemo contributor 15:03:34 veskuh: sorry :P 15:04:19 one more min (intro yourself, prefix with #info) 15:04:40 #info Mohammed Hassan. SW engineer at Jolla and FOSS hacker (mostly listening *again*) 15:04:44 #info Richard Braakman, programmer at Jolla, free software ex-fanatic 15:05:26 Stskeeps: would you like to #info stezz and marc? 15:05:29 #info Winfried Dobbe, just generally interested in Jolla (development) 15:05:48 last call for intro 15:06:03 #info Antti Lähtevänoja, young entrepeneur: mobile repairing, hardware and software. Very interested in Jolla and Sailfish 15:06:08 #info stezz/marc - cto; coo, here in spirit, posseses stskeeps to speak officially 15:06:20 ok thanks! moving on 15:06:22 #topic 2. Community open source package repository for Sailfish apps 15:06:37 #info Guilherme Mendes, software developer, interested in SailfishOS 15:06:44 may I? 15:06:56 timebox: 35 min (5 min intro by tbr, 20 min discussion, 10 min resolution and action items) 15:06:56 (please) 15:06:59 tbr: stage is yours 15:07:05 This topic is fairly important from a community perspective. Let me introduce it quickly to you. 15:07:08 Jolla builds a lot on open source software and Qt based platforms tend to attract the open source app community. The topic of an application repository for open source applications came up pretty instantly. 15:07:12 Also given Jolla's claim to continue Maemo/MeeGo heritage carries such things implicitly. 15:07:15 Maemo had extras, MeeGo and Harmattan had AppsForMeeGo. 15:07:18 I urge Jolla, the company, to make a public commitment, during that 15:07:20 meeting, to support the open source app community. 15:07:21 ahoy 15:07:22 I support how David summarized the minimum viable way on the device on IRC: 15:07:25 1) Settings -> Untrusted SW -> tick Allow, tick Install Chum client. Done 15:07:28 2) Store -> Chum client and select install -> Untrusted SW -> tick Allow. Done 15:07:30 There are other aspects which will need to be agreed, but Jolla needs to indicate that it is willing to consider this and what needs to be done by the community for the mentioned above integration to be allowed. 15:07:35 This is a heated topic and we should not ignore that there is no predefined solution. The above is a proposal by lbt and me. 15:07:38 I'm going to openly invite people who support other approaches to speak up and make their case, specifically openrepos. 15:07:41 For reference there was also discussion on the sailfish developer mailing list and on last sunday on #jollamobile (2014-04-20) 15:07:46 hello there vacation lady 15:08:12 I hope everyone is familiar with the topic, it has been showing up again and again 15:08:26 I guess we should now open the discussion about this 15:08:34 #info Intro by tbr, also summarized in email https://lists.sailfishos.org/pipermail/devel/2014-April/004015.html 15:08:37 I think one key part of this is that we're looking to establish a community repo that Jolla can install onto devices by default 15:08:54 (for some value of default) 15:09:03 #info something a lot like Maemo Extras or Apps for MeeGo 15:09:22 lbt: Definitely. Making default is simple, but not easy 15:09:23 #info 18:07 < tbr> For reference there was also discussion on the sailfish developer mailing list and on last sunday on #jollamobile (2014-04-20) 15:09:38 thanks, that's a good one forthe log 15:09:57 so, as a start I can at least do this - on behalf of Jolla: 15:10:03 It's sad that so far we haven't had any statement even less commitment from Jolla 15:10:54 thanks tbr for introducing the topic. Let's start the discussions. Stskeeps please continue. 15:11:08 #info Jolla commits to welcoming an installable Chum/Sailfish community repository package into the Jolla Store, which will prompt for 3rd party/untrusted SW and then install, in style of how things have been functioning with maemo.org extras and other initiatives in the past 15:11:25 #info tbr's number 2 option 15:11:44 #info this carries weight as a harbour rules exception for this purposes 15:11:45 -s 15:12:12 yes, it is significant responsibility put onto the community 15:12:32 and there are requirements too 15:12:35 I feel that Jolla can only benefit from this though 15:12:39 What will be the difference between this new Chum repos and openrepos / warehouse ? 15:12:51 in terms of openness, QA and src 15:13:13 #info We believe that it should be endorsed due to the benefit of having a rebuildable and open source collection of software, that we can also use to also verify our own platform while in development and help grow the software ecosystem around SailfishOS 15:13:14 winfriedd: the intention of chum is strictly open source 15:13:34 winfriedd: with a community hat on I said we should document and enforce policy and QA which minimises risk to Jolla customers 15:13:42 but as I said I would welcome someone making the case for OR 15:13:53 Basil himself is present as I noticed 15:14:14 i'm here, just listening for now 15:14:21 Personal opinion: OpenRepos has great Web UI and working client. I like it. I’d like to see collab here, instead of reinventing things. 15:14:27 Especially as I have been publicly insulted for criticizing OR 15:14:33 there's been a comparison to OR as extras-devel - wildly popular but somewhat dangerous for end users 15:14:43 I think this must be done, and it:ll be great benefit to Jolla. But the main problems are making things simple and safe to customer. It won't work if everyone asks how to do this etc. 15:14:50 Also I cannot distribute any API key based app on OBS easily. 15:15:05 I'm wondering about backward/forward compatibility for apps that use interfaces that Jolla has not committed to keep stable. 15:15:16 there's the challenge that this enablement will not include developer mode though; so a chum/extras store UI client would need to be made or re-used 15:15:22 but for that, 15:15:24 veskuh: *nod* there are bound to be specific issues like that - linux distros have them too 15:15:28 veskuh: that is an important point for the future 15:15:48 #info Jolla invites to co-create with our PackageKit/SSU experts to help get this done properly 15:16:15 #info one problem with the OBS approach is with API keys that might be required to kept secret 15:16:32 #info I believe though the API key problem is solveable 15:17:11 why I believe OR as such is not fit for this is as it accepts any kind of RPM upload 15:17:25 there is no verifyable path from source to RPM 15:17:33 would there be any benefit in re-using the client however 15:17:34 ? 15:17:37 also closed source software is possible and present 15:17:57 but if we allow binary uploads due to API keys then there is also no way to verify the path 15:18:03 That might be possible, but I wouldn't want to offend anyone there. So depends on OR too 15:18:21 from what i know, openrepos is open source, so 15:18:24 MSameer: yes, the API key thing will be a tough one 15:18:32 (i might be wrong) 15:18:32 MSameer: there are always going to be issues - resolving them is part of the fun 15:18:41 apis can be in loadable plugins with standart interface 15:19:02 lbt: tbr so instead of starting from scratch, we can start with helping OR 15:19:16 Stskeeps: That makes it a good candidate, but still I don't want to get further insults or death threats for going near it. So this needs to be agreed. 15:19:28 so OR would get the verifyable path that we need (assuming BasilSemuonov agrees) 15:19:33 :nod: just wondering about the situation 15:19:48 MSameer: the OBS/Chum solution is something that's part of the Mer Project which underlies Sailfish 15:19:55 MSameer: I see OR as a whole out of question. full stop. 15:20:04 it certainly makes sense to help the main upstream, yes 15:20:22 tbr: that's not how it goes 15:20:31 MSameer: as it would entail a lot of things that the open source community can not take responsibility for 15:20:50 tbr: could you please list 2 of those issues? 15:20:55 I have no problem with contributions to the Chum area (even huge ones like a client and web UI) ...but Chum is a fully opensource only solution 15:21:18 MSameer: binary uploads are available, bad track record with platform interaction, no QA 15:21:22 the requirement, as such, to be in a store is that there's a community-vetted set of software, that can be tested and QA'ed; and understood immediately if it is in any way blocking system issues, etc 15:21:36 I still don't see why we can't make OR and chum work together especially if we allow binary apps due to API keys 15:21:50 we can, I'm sure 15:22:03 but then maybe I should not speak for BasilSemuonov :) 15:22:07 Chum is, at the moment, nothing discrete 15:22:15 it is simply an area on the Mer OBS 15:22:16 I personally build in Mer OBS so I don't have any issues so far 15:22:18 OBS integration is possible, import from Chum is possible, but i dont think that mixing things in one client is a good idea (in terms of security as tbr saying) 15:22:22 and some rules in the Mer automation 15:22:40 BasilSemuonov: do you have a git link for the openrepos client, by chance? 15:23:02 i.e. upload source to OBS->package at Chum = ok. digests are fine. Add extra blob with keys = no trace if package was builded from same source 15:23:07 sure 15:23:11 As I previously said, I don't have anything against OR presenting Chum content to its users. That's welcome. Also integrating with people who build on OBS is a good idea. 15:23:14 https://github.com/custodian/orn-warehouse 15:23:18 thanks 15:23:23 #link https://github.com/custodian/orn-warehouse 15:23:24 tbr: binary uploads will be allowed for API keys = non-verifyable. What's left is QA and OS integration (which is a side effect of QA AFAICT) 15:23:39 MSameer: that was not said. 15:23:53 there's fwiw, probably ways to include API keys, despite open source 15:24:07 some retrieve it from web, maybe there could be a trusted key store, etc 15:24:13 MSameer: if you state that enabling API keys taints this beyond building from source then the stance needs to be clear: No api keys 15:24:24 lets not rabbithole the API key thing ... that's my bad habit :) 15:24:40 yes, api key is a thing to be looked at and studied, valid concern 15:24:48 This is strictly about open source applications 15:24:50 tbr: of course adding a binary blob taints 15:24:51 :nod: 15:25:04 :nod: 15:25:07 I don't want even the faintest notion that we are allowing arbitrary gigabyte sized binary blobs. 15:25:35 and here too - Mer as a project wants to develop this kind of rule processing 15:25:44 Jolla already uses it a fair bit 15:26:09 and this is about having a open and collaborative area for building those rules and interfaces to them 15:26:11 4 more min for discussions, after which let's work on coming to some kind of agreement and follow-up steps/actions 15:26:20 to give that a name you are speaking about B.O.S.S. 15:26:24 yes 15:26:39 want to #info that? 15:26:50 good point 15:26:57 main advantage of chum is QA ;) 15:27:07 #info Mer as a project wants to develop this kind of rule processing which it already has as BOSS 15:27:30 So is there a plan for handling compatibility with new Sailfish updates? 15:27:33 BasilSemuonov: yes - and that's something which we see that Jolla (any vendor) would need 15:27:37 BasilSemuonov: the main point is strict open source. The api issue needs to be clearly separated and solved in a sensible way without tainting this. 15:27:42 rbraakman: yes 15:27:51 Like, how is responsibility divided for both QA and fixing apps 15:27:52 rbraakman: yes, there's a good link to a nice talk with aard earlier in this conversation 15:27:55 rbraakman: and some pipe dreams too 15:28:21 rbraakman: #jollamobile discussion 2014-04-20 evening 15:28:26 rbraakman: we still need a user communication solution - this is a really tricky problem 15:28:44 The idea here is also to give the open source applications a bit more freedom 15:28:58 what about "chum-stable" and "chum-testing" ? 15:29:06 e.g. telepathy plugins wouldn't be possible today AFAIU in harbour 15:29:15 they exist but would not be visible in non-developer mode 15:29:17 or daemons 15:30:27 BasilSemuonov: what is 'exposed' to Jolla users, would be 'chum stable' 15:30:30 #link http://www.merproject.org/logs/%23jollamobile/%23jollamobile.2014-04-20.log.html#t2014-04-20T16:03:08 log of #jollamobile 2014-04-20 15:30:33 adding 'testing' or 'devel' would probably be more involved 15:30:37 thanks cybette! 15:30:45 . 15:30:46 :) 15:30:49 so there's motivation to participate in testing 15:31:10 yeah, we don't want people to go straight to extras-devel "because it's easy" 15:31:13 we also need to learn from maemo extras 15:31:15 hehe 15:31:20 :) 15:31:33 So it's time to give this some direction and summary 15:31:40 maemo-extras was okay, but then failed because of stalled packages 15:31:46 yes, next 10 min for summary and directions 15:31:52 BasilSemuonov: mind if i link your tweet? 15:31:57 sure 15:32:08 BasilSemuonov: agreed - but developers had no motivation to QA either 15:32:17 BasilSemuonov: and that lead to its own issues 15:32:17 #link http://www.twitlonger.com/show/n_1s1fioe 15:32:20 I'd propose to go ahead as Stskeeps said and in addition work with BasilSemuonov on adapting the OR client for "chum" (whatever the final name) needs and feeding back to OR as upstream 15:32:52 lbt: developer can vote, and it was okay, there were no testers to vote 15:33:11 BasilSemuonov: these are the things we need to learn from 15:33:19 i'd like to quickly ask, what more is wished from jolla side? 15:33:26 1) 15:33:36 and a timeframe 15:33:40 Stskeeps: some clear stated expectations. e.g. regarding policies 15:33:59 and guidelines on minimum expected policy for acceptance of Chum to 'go live' 15:34:21 tbr: i think common sense should really be clear -- don't intentionally break people's devices, be reachable, be active in time closer to releases 15:34:26 ie testable acceptance criteria for enabling chum from community side 15:34:34 hopefully we can find a way to pre-vet new sailfishos + chum releases 15:34:52 ie policy documented, QA in place ... 15:35:02 timeframe - i need to talk deeper with engineering about this, but i also believe that chum (as a project) has something to work on before it can go live 15:35:10 Stskeeps: also a commitment to communication towards the community would be great. Maybe even a dedicated contact for issues. 15:35:34 yes, this is going to take time on both sides to be ready for prime time 15:35:37 let's start out with me as a contact part and i'll try my best to find somebody who's better at it 15:35:47 tbr: +1 person needed 15:35:51 ... and we really need a name for it that doesn't mean "shark bait" 15:35:57 it also helps if there would be a way to report OS bugs. My app got rejected twitch from harbour due to a bug in one of the OS libraries 15:36:09 so being able to report those issues would be good 15:36:19 :nod: 15:36:20 MSameer: isn't that a jolla issue? 15:36:21 and don't tell me tjc :) 15:36:27 MSameer: tjc 15:36:31 heh 15:36:32 MSameer: but that's the official line :) 15:36:41 MSameer: i think as we improve the mer+nemo state, it becomes easier for a large amount of components 15:36:44 but yes 15:36:45 anyway, let's stay on target 15:36:46 mailing list perhaps 15:36:48 :nod: 15:36:55 so 15:37:10 #info Stskeeps commits as contact person for this (for the moment) 15:37:16 #info Stskeeps will be Jolla contact for this topic until further notic 15:37:22 heh 15:37:23 #info both sides to work on their "homework" 15:37:56 #info where "homework": policies, qa, boss (community). platform, pkcon, etc (jolla) 15:38:18 i'd also like to propose that we sync again in 14 days on this topic? 15:38:22 to see where we're at 15:38:25 #info proposal stands that we collaborate with OpenRepos on the client software for mutual benefit 15:38:28 #info Jolla to agree some criteria for Chum being 'ready'. Negotiation of actual criteria on irc/email :) 15:38:46 yes, let's see in 14 days 15:38:56 #info Sync again in 14 days on this topic 15:39:16 #action prepare community side, policies, documentation, qa 15:39:24 i hope this is also seen as more concrete commitment to the cause 15:39:32 indeed it is 15:39:44 already sundays discussion was surprisingly productive 15:40:00 the previous noncommital was infuriating 15:40:07 anyway, it's a wrap 15:40:08 any last words on this before we move on? (thanks for keeping good time) 15:40:28 going going... 15:40:36 #topic 4. Plans on SailfishOS for Android 15:40:41 darn 15:40:44 hehe 15:40:46 no, 3) 15:40:48 Stskeeps: fair to say that Jolla commits to supporting QA-backed opensource-only community app repository and 'store' 15:40:51 I think there's #undo 15:40:53 #topic 3. Closed bits of SailfishOS - why/where/how and relation to open source parts 15:40:58 copy paste error :P 15:41:14 Stskeeps will give an overview on the current state of things about this topic, to provide a common understanding and reference for discussion. 15:41:16 okay.. so, many of you may know these things already, but it's so we can get on the same page and understand the situation 15:41:20 yes 15:41:21 :P 15:41:25 :) 15:41:27 timebox: 20 min 15:41:33 Stskeeps: go ahead :) 15:41:41 first off: this is practically the OSS policy that we run with in Jolla, on a day to day basis: 15:41:45 #link https://together.jolla.com/question/3014/clarification-of-open-source-policy/#post-id-6768 15:42:21 it's 'default permission for these cases, else not open source, but if you ask it can be excepted', for tld;r 15:42:22 * tbr has read this 15:42:35 it's good to see this 15:42:42 and for for example virtual keyboards and sailfishos browser, this has been an exception 15:42:58 (ie they're open) 15:43:06 (virtual keyboards are BSD licensed so you can make new layouts, legally) 15:43:41 this in practice means that we contribute a large amount of code to Mer/Nemo middleware and surrounding projects (Qt, for example) 15:44:27 on top of that, in many applications, the QML source is available within the device file system, which has been used to do things like Sfiet_Konstantin's patcher 15:44:47 and we're happy if you tinker with your devices at own risk in developer mode 15:46:17 another view, -- http://releases.merproject.org/~carsten/niceview.png -- this is an older view of sailfishOS, what things the sailfishOS UI depends on; mw/core is nemo/mer in practice, hw adaptation is closed source (except for kernel) for most part; and then jolla-non-oss to the right showing closed packages 15:46:19 In that context I'd inject: there has been a recurrent question: how to contribute fixes to those bits back 15:46:22 :nod: 15:46:27 and that's an issue we're looking into 15:46:34 good to hear 15:46:36 i don't have an answer today; but it should be possible 15:46:51 sailfish browser became open source since that png 15:47:10 #into Stskeeps says Jolla is looking into how people can contribute back fixes to non-oss licensed UI bits that have e.g. QML openly available on device 15:47:42 we are also looking into the state of sociald's OSS status, but no commitment yet that i can say today 15:48:16 mind info-ing those or should I? 15:48:30 #info sailfish browser became open source since that png 15:48:30 I think that overview is something for the minutes, but an updated version would be nice 15:48:36 #link http://releases.merproject.org/~carsten/niceview.png 15:48:37 but tinkering with QML because it's available on the phone is not strictly legal ;) 15:48:56 it's a bit of a grey zone, but as long as it's not done commercially no harm should be done 15:48:57 MSameer: it is, it's your device, nobody can forbid that 15:49:05 MSameer: it's contributing that back that's the problem 15:49:19 MSameer: IANAL, distributing is not allowed, tinkering your own phone is ok. 15:49:22 tbr: not true from a very strict legal POV 15:49:30 tbr: please go ahead and #info if we missed something (or in my case, slow) 15:49:40 #info we are also looking into the state of sociald's OSS status, but no commitment yet that i can say today 15:49:42 tbr: but that''s a separate topic anyway 15:49:47 MSameer: also that depends on the country you're in 15:49:57 #info Stskeeps says Jolla is looking into how people can contribute back fixes to non-oss licensed UI bits that have e.g. QML openly available on device 15:50:04 I had typoed the #info 15:50:06 anyway: our opinion is that that kind of behaviour is okay, it's good to see community innovate and play around 15:50:26 so long as they don't call Care :D 15:50:47 #info Jolla appreciates the community tinkering and is ok with it as long as there are no commercial interests involved 15:51:06 .. now, do we have any particular pain points we want to discuss? 15:51:12 #info and as long as people understand that care can't help them ;) 15:51:20 tbr: where did the "as long as there are no commercial interests involved" come from ? 15:51:22 #info at own risk of hair lsos, etc 15:51:29 MSameer: from me, somewhere above 15:51:33 that was not said by Stskeeps 15:51:34 that 15:51:38 was :) 15:51:41 either way, that's what i meant :) 15:51:46 aha 15:51:46 ok 15:51:48 sorry 15:51:51 15:48:55<+Stskeeps> it's a bit of a grey zone, but as long as it's not done commercially no harm should be done 15:51:56 * MSameer slaps himself 15:52:00 Maybe clarify that "tinkering" here refers to the non-free files 15:52:03 so ... pain points... MSameer? 15:52:22 lbt: I have no pain :) 15:52:22 #info tinkering as in modifying the non-oss licensed parts of sailfish 15:52:23 8 min left for this topic, direct pain points to Stskeeps 15:52:37 MSameer: slap harder ...aard will help 15:52:53 best hush - we'll get kicked by cybette_with_axe 15:53:14 okay, so people seem mostly content about the current oss or non-oss parts..? :P 15:53:14 lbt: good warning ;) 15:53:18 I think that was pretty much the biggest pain point? 15:53:19 veskuh: distributing as app, or in general? so if i change my qmls, I'm basically not allowed to share diffs? 15:53:39 so, i don't know if you guys know of webos patches community 15:53:42 they distributed patches 15:53:53 netzvieh: patch is ok, whole file is not. 15:53:53 * tbr missed that 15:54:00 :nod: patch is okay, whole file is not 15:54:16 #info distributing patch is ok, whole file is not. 15:54:38 #info Patches for QML changes are acceptable, but not distribution of whole files 15:54:40 #link http://forums.webosnation.com/webos-patches/ 15:54:44 Stskeeps: is there a sane reset mechanism 15:54:45 technically, 100% diff file is a patch or file? 15:54:53 lbt: sfiet has a decent framework 15:55:01 BasilSemuonov: hehe, now we're getting into details .. :) 15:55:15 what about plans to open source more apps, something simple like calculator or notes ? could also work as reference for developers 15:55:16 basically, use common sense 15:55:19 what about learning from the closed bits, eg. I have used lipstick-jolla-home QML for studying, as per the Glacier homescreen? 15:55:47 Stskeeps: does his framework recover from broken QML patching w/o factory reset? 15:55:52 ie QML restore? 15:56:04 locusf: i think when you develop software yourself you have to understand that working with this may taint your own output, i'm not a lawyer 15:56:16 locusf: in general, as a software engineer, you need to be careful 15:56:30 i'm looking if we can somehow improve such a situation 15:56:34 Stskeeps, we don't need need to look into webos, we have patch manager for jolla http://talk.maemo.org/showthread.php?t=92935 . In my opinion it is way to the hell 15:56:47 xmlich02: yes, that's what i'm referring to 15:56:48 locusf: if you need to study closed code to learn the api - log bugs on SDK docs in tjc 15:57:12 but since such a practice has started, it also has to be adressed 15:57:16 there is no body who is not tainted because we all worked for various companies 15:57:22 locusf: reverse engineering is allowed for protocols and APIs. For looking as example or ideas, I really don’t know. May be more difficult areas. 15:57:25 let's see how things can improve in future 15:57:28 so I don't think this is really something that can be used against people 15:57:45 * MSameer took off his jolla hat long ago 15:57:53 Stskeeps: ok good to know 15:58:02 lbt: absolutely 15:58:17 2 min left - speak now on this topic (or continue later in mailing list) 15:58:18 we also welcome suggestions to improve middleware apis and closed apis for patches 15:58:26 MSameer: My IPR professor said that the rule of thumb was that you cannot make notes, but if you remembed (non-patented) stuff then its ok, but that was over 10y ago. 15:58:44 is he out yet? 15:59:17 veskuh: good point 15:59:17 #info Stskeeps says that Jolla also welcomes suggestions to improve middleware apis and closed apis for patches 15:59:23 Stskeeps: on pain points - didn't spot an answer to my framework Q 15:59:28 Stskeeps: does his framework recover from broken QML patching w/o factory reset? 15:59:33 lbt: that's up to sfiet to answer :) 15:59:36 "at own risk" 15:59:59 lbt: ask that, and he will add: ssh + run command to revert, for example 16:00:03 sometimes you nuke your device even with closed source software, there's a good recovery menu 16:00:04 lbt: I remember that one has to undo all patches before updating to a new SFOS release 16:00:04 right - just wondering if jolla can help with that to reduce risk of trying to contribute 16:00:22 BasilSemuonov: OK 16:00:49 let's move on to next topic. I think we've had good discussion and can continue in other channels 16:00:50 mainly looking for places that may really benefit from Jolla helping 16:00:55 :nod: 16:01:04 #topic 4. Plans on SailfishOS for Android 16:01:12 whew, got the right topic this time 16:01:28 ok, Stskeeps will take the lead again on this. stage is yours. 16:01:42 timebox: 20 minutes 16:01:55 okay, so, we released sailfishos for android devices for mako/nexus 4, early adopter release 2 last week 16:01:59 to clarify: this is about the current Nexus4 / S4 images not that rumoured launcher? 16:02:01 it has working phone calls and so on 16:02:02 yes 16:02:06 S3 16:02:07 ok 16:02:14 right 16:02:37 we have some work to do with the galaxy s iii lte on modem side, hence why it's not out yet, as it can send SMS, but not phone or use data ;) 16:02:55 we'll shortly start some work to also allow ports to later cyanogenmod versions 16:03:13 Are there ways the community can help? 16:03:24 I know there is the plan in the long run to do this adaptation kit 16:03:29 but in the short term? 16:03:49 is it so that the more stable cm is on Android device, the better Sailfish support it gets? 16:03:53 the problem lays mostly on our side as we don't have the adaptation kit out yet; so it's hard to really get into it, despite some people trying hard to get things working (ballock, vgrade, i'm looking at you..) 16:04:02 #info Discussion on Sailfish OS for Android devices (Nexus 4 / S3). Early adopter release 2 was released last week. 16:04:28 I mean mako is nexus so of course but s3 lte because it has fairly open qualcomm chipset? 16:04:47 yeah ballock is doing a lot of compiles on my old MeeGo OBS worker hardware at OSUOSL ;) 16:05:01 one reason for the delay is a bit on legal side (and that takes time); and that we want to make sure not to repeat mistakes of the past, and have a factual path for people doing official sailfishos adaptations 16:05:07 native sfos = android sfos in terms of api/packages/compatibility? 16:05:21 BasilSemuonov: sailfishos factually running on an android device 16:05:25 make that an info please :) 16:05:36 #info one reason for the delay is a bit on legal side (and that takes time); and that we want to make sure not to repeat mistakes of the past, and have a factual path for people doing official sailfishos adaptations 16:05:47 and also that we want to polish it quite a fair bit 16:05:49 we do have 16:05:54 #link http://github.com/mer-hybris 16:05:55 already 16:06:18 Stskeeps: i mean binary compatibility 16:06:29 BasilSemuonov: SailfishOS 1.0.5.16 release + a hardware adaptation 16:06:34 same apps, same apis 16:07:08 we'd like to get to a point where anybody with a bit of clue about making android builds, can get into making sailfishos builds for their device 16:07:15 without knowing let's say, OBS 16:07:18 BasilSemuonov: early adopters are using OR/warehouse on nexus4 already 16:07:30 yup 16:07:52 there's of course some challenges: we don't have 'paid' stuff like HERE maps/positioning, mp3 codecs, etc 16:08:06 #info Sailfish OS on Android is SailfishOS 1.0.5.16 release + hardware adaptation (with same apps and APIs) 16:08:25 i'm pushing to 'any android vXX.XX' is going to be supported, or add some min tech specs here' 16:08:37 BasilSemuonov: android 4.2.2 and above, ideally, cm 10.1 16:09:02 re paid stuff, so it's quite a pure sailfishos experience - we do want to figure out how to deal with this 16:09:10 and we'll be adding jolla store soon enough as well 16:09:27 the release cycles for the OS itself will follow sailfishOS update releases 16:09:42 but wihout the 'paid' stuff I'll be able to distribute say a nexus 5 image? 16:10:00 * tbr listens up 16:10:17 vgrade: that's the legal side of things we're figuring out, but it'd be a bit silly to provide a HADK, want spread through community and not allow this 16:10:21 As I already host vgrade's N9/N950 images :) 16:10:25 people already do this for n9/n950 16:10:26 I suppose that the more stable CM is on device, the more changes device has to have properly working Sailfish? 16:10:37 laehtis: yes, it's all about glueing things up 16:10:53 in terms of adoptation the 'paidstuff' is probably key imo 16:10:54 Stskeeps: the community has seen sillier things, so excuse the questions ;) 16:10:56 note though that not all jolla sailfish things that you get on a jolla device is jolla's, or licensed for other stuff 16:11:34 so, jolla-xt9, alien dalvik, codecs, exchange support and so on are no-go 16:11:43 it'll be easier to understand those limits as we go along 16:11:56 I see an important topic here: The open source community can and SHOULD step in and replace what necessary 16:12:11 e.g. find a way to get location work without the HERE stuff 16:12:14 +1 16:12:21 +1 16:12:22 there's alternatives such as opencellid, as well, or mozilla's 16:12:24 I've been preaching this for a while ;) 16:12:28 but yes, that's one thing that can be done 16:12:28 +Stskeeps okay so e.g devices with qualcomm chipset would be ideal, such as S3 LTE, Note 3 LTE. And of course Nexus 4 mako and Nexus 5 hammerhead, which have good hw support 16:12:47 also when people asked why aliendalvik - well you can write it as OSS, I'd love to see that and I would help with it 16:13:16 #info < tbr> I see an important topic here: The open source community can and SHOULD step in and replace what necessary 16:13:18 QC hardware is probably a good bet in terms of modem 16:13:26 :nod: 16:13:45 many jolla employees can't participate in some of these things, but a community is a community 16:14:18 #info necessary: location, android runtime, keyboard prediction - just to name examples 16:14:19 laehtis: modem is what mostly matters yes, but GPU is less of a problem 16:14:29 tbr: and maps 16:14:36 ah, yes! 16:14:50 isnt osm qt plugins available? 16:14:54 #info also necessary: maps replacement (that should be easy, OSM hint hint) 16:14:55 laehtis: a CM ROM for -any- Android device (provided it runs well there) makes itself a SFOS candidate 16:14:55 there is yes 16:14:58 #info [19:12] also when people asked why aliendalvik - well you can write it as OSS, I'd love to see that and I would help with it 16:15:07 ;) 16:15:11 :) 16:15:25 5 more min on SailfishOS on Android topic - ask your questions, voice your concerns, etc. 16:15:40 so that's what i had to share today.. we're doing our best but a lot will be a lot easier when we post HADK 16:15:44 (pronounced "Haddock") 16:15:53 * sledges cringes 16:15:54 :D 16:16:06 any plans to get non-oss stuff to android via paid-app from store? 16:16:15 Hardware Adaptation Development Kit? 16:16:18 BasilSemuonov: rephrase, sorry 16:16:19 is sailfishos IRC place for android adaptation talk? 16:16:21 locusf: yes 16:16:22 vgrade: yes 16:16:33 i mean i have nexus4, installed sfos, open jolla store, paid $50 and have licensed alien-dalvik 16:16:52 BasilSemuonov: it's an approach 16:16:59 #info HADK = Hardware Adaptation Development Kit, pronounced "Haddock" 16:17:13 +Stkeeps: I see. But when we want a full working SF with no bugs we must have good HW support, because some Android OEMs don't provide properly sources to GPU and so on, so there will be graphic lags, camera HW problems etc. 16:17:14 BasilSemuonov: more details if/when we can do that in future 16:17:29 $50 = cost of licensing option per user for device+jolla fee (or whatever) 16:17:29 * tbr can see an interesting series of codenames based on Haddock... Thundering Typhoons! 16:17:45 #info For Android adaptation talk, join #sailfishos on freenode 16:17:49 laehtis: hybris resolves most of that 16:17:59 laehtis: we use the android apis 16:18:20 so we're as stable as an open android implementation would be 16:19:04 2 min 16:19:06 so when the jolla store for mako is released, will it be possible to update directly from the device? 16:19:06 1 min 16:19:08 any plans for a tablet 16:19:12 netzvieh: ideally yes 16:19:14 adaptation 16:19:20 vgrade: UI ? 16:19:26 * tbr would help with the Nexus7 2013 16:19:26 and as a minor note.. would anybody be interested in playing with tablet hardware and play with tablet-izing the UI with sfiet's patcher? 16:19:29 QC based 16:19:35 :D 16:19:48 lbt: Yes, most definitely. But I meant that some devices don't have properly AOSP support, such as Samsung Exynos models, so they are pretty much out of the question when talking about a fully working build 16:19:52 #info there is also interest in 'tabletizing' sailfishos 16:20:01 laehtis: correct 16:20:05 just gathering interest atm :) 16:20:09 16:20:09 :P 16:20:12 #info ^ by using e.g. sfiet's pandora patcher 16:20:35 last call on this topic. 16:20:39 Stskeeps: well again, ballock was there first ;) (ignoring the nexus7 2012 demo) 16:20:54 nexus7 2012 was basically 'big phone' 16:20:58 not very tablet-y 16:21:02 yes, hence ignoring 16:21:16 anywho 16:21:21 bing bing, last round 16:21:30 #topic 5. Wrap-up, action items and next meeting 16:21:49 i guess one action should be that cybette sets up next meeting and asks for topics? 16:21:54 as tbr took it today 16:22:06 we should alternate with community 16:22:06 sounds good 16:22:13 #action cybette to set up next meeting and ask for topics 16:22:26 and australian-friendly timing too ^ 16:22:27 timing wasn't for this meeting, I can't remember 16:22:28 lbt: fine, but needs to be clear 16:22:45 #info time slot discussion should happen on mailing list 16:22:51 kk 16:23:08 as lorn can't participate during this time as he's in .au 16:23:36 can we agree next meeting is one week from today, and decide time on mailing list? 16:23:40 one thing I'd like to touch on briefly: how's the outlook for Qt5.2? it has more stable APIs 16:24:00 fine by me, but this needs to be kicked off today then 16:24:06 what tbr said 16:24:17 #info tbr propose to touch on Qt5.2 for next meeting 16:24:26 .. i think he meant now ;) 16:24:28 that was a question for right now ;) 16:24:33 ah 16:24:33 #undo 16:24:34 tbr: it's not going to be the next update, at least 16:24:36 #undo 16:24:36 Removing item from minutes: 16:24:44 roger 16:24:49 that's already a statement 16:24:55 w00t would be a better person to talk to 16:25:02 community is waiting for stable APIs 16:25:04 :nod: 16:25:07 so any bit of information helps here 16:25:15 also the bit: not in the next update 16:25:17 you can see WIP at http://github.com/mer-qt afaik 16:25:31 hopefully we'll have all that work in mer-nemo combo soon 16:25:45 #info Qt5.2 not in next update and you can observe WIP at http://github.com/mer-qt according to Stskeeps 16:26:35 #info next meeting 2014-04-29, time to be discussed on mailing list 16:26:43 what else? 16:27:01 anyone have open questions, loose ends, not yet put down actions? 16:27:35 anyone? :) 16:27:44 i have some lag from last meeting due to easter, but will be spending time on processing it properly during this week 16:27:44 * cybette puts away axe 16:27:53 and we can probably discuss further at next meeting 16:27:54 #help Volunteers wanted for the community repository effort! talk to lbt and tbr on freenode IRC, #sailfishos 16:28:10 #info yes please 16:28:24 #action Stskeeps to go through backlog from previous meeting for next meeting 16:28:30 how is mer<-nemo merge progressing? 16:28:50 not effected until 1st of may 16:28:54 but http://git.merproject.org 16:29:07 how's feedback from outside sailfish/nemo? 16:29:07 follow discussion at mer-general@ 16:29:16 tbr: so far so good 16:29:21 *nod* 16:29:31 tbr: lbt: could you write up a post for the ML what exactly is needed? 16:29:36 thanks for the meeting, once again very productive 16:29:47 #link http://git.merproject.org 16:29:49 also appreciate the clarification of community repo 16:29:54 thanks all 16:30:00 #info follow mer<-nemo merge on mer-general mailing list 16:30:05 netzvieh: yep 16:30:12 thanks everyone! ending meeting now 16:30:13 #info I hope that Jolla keeps up this meeting habit 16:30:19 +1 16:30:27 #endmeeting