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