10:00:51 <Stskeeps> #startmeeting SailfishOS, open source, collaboration: 6-May @ 10:00 UTC
10:00:51 <Merbot> Meeting started Tue May  6 10:00:51 2014 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
10:00:51 <Merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
10:00:57 <Stskeeps> #info Welcome to another week of SailfishOS OSS and collaboration meeting
10:00:58 <Stskeeps> #info Agenda today can be seen at https://lists.sailfishos.org/pipermail/devel/2014-April/004098.html
10:01:05 <Stskeeps> #topic Quick introductions (5 min), prefix your information with #info
10:01:09 <netzvieh> #info community member and generally interested in how the Jolla is moving forward into the OSSea
10:01:22 <Stskeeps> #info Carsten Munk, Chief Research Engineer @ Jolla, today hat-less meeting chair
10:02:02 <fk_lx> #info Filip Kłębczyk, community member... still... a fresh-born blogger
10:02:09 <bijjal> #info Soumya Bijjal, Software program manager @ Jolla
10:02:22 <piiramar> #info Martti Piirainen, Tieto employee, sailfish contributor
10:02:23 <cybette> #info Carol Chen, community chief at Jolla, today on sick leave but didn't want to miss this meeting
10:02:41 <netzvieh> get well cybette :)
10:03:05 <fk_lx> netzvieh: +1
10:03:11 <mattaustin> #info Community member, casual developer. Jolla owner in Australia. Interested in harbour Python support roadmap.
10:03:27 <sletta> #info Gunnar Sletta - Qt graphics stuff - Sailor @ Jolla
10:03:38 <cybette> netzvieh, fk_lx thanks :)
10:03:42 <stephg> #info Steph Gosling:- Sailfish and Nemo community member
10:03:48 <amccarthy> #info Aaron McCarthy, Software developer (location, connectivity, Qt) @ Jolla.
10:03:56 <lpotter> #info Lorn Potter, connectivity/sensors guy @ Jolla
10:03:58 <vgrade_> #info vgrade, community member, adaptations
10:04:03 <BasilSemuonov> #info Basil Semuonov, software developer
10:04:04 <pvilja1> #info Piritta Viljakainen, working with translations @Jolla
10:04:26 <eleroux> #info Eric Le Roux, bugzilla & t.j.c admin @Jolla
10:04:33 <SK_work> #info Lucien XU, Sailfish OS developer, Jolla community member
10:04:33 <Jonni> #info Jonni Rainisto, Security, privacy and locking @Jolla
10:04:35 <M4rtinK> #info community member, application developer, author of modRana
10:05:07 <oniongarlic> #info Hobbyist developer, long time lurker, Y-Radio author
10:05:09 <Jarno> #info community member, translator dutch languague pack
10:05:11 <pvuorela> #info Pekka Vuorela - Jolla, text input, settings, calendar etc
10:05:55 <Stskeeps> #topic Security Model / APIs
10:05:55 <veskuh> #info Vesa-Matti Hartikainen - Jolla, Browser
10:06:18 <Stskeeps> the format today is more of a discussion to bring up issues and just generally talk - from Jolla side, we have Jonni representing security/privacy and so on
10:06:21 <sharpneli> #info Community member. GPGPU enthusiasts, owner of the first, not unique anymore, OpenCL enabled Jolla.
10:06:22 <kimmoli> #info Kimmo Lindholm - DIY Otherhalf tinkerer, community member
10:06:26 <Stskeeps> #mode #mer-meeting +v veskuh
10:06:53 <Stskeeps> so, the topic is about security model/apis, the listed one was in it's full form: - Security Model / APIs. Jolla vision on topic. (Main subject is model, without model there is no api). What is planned? Some TJC sum-ups: https://together.jolla.com/question/9670/api-security-model/
10:07:08 <cybette> Stskeeps: seems we both have trouble +v veskuh ;)
10:07:15 <stephg> yep
10:07:27 <Stskeeps> and i'm not sure who wrote it, but let's start with bringing up some questions perhaps, to clarify the topic a bit?
10:07:50 <fk_lx> Opinion: Harbour Quality Assurance won't assure full security to apps as already was shown with Artem little provocation. Some security solution is expected. Has anyone in Jolla thought about Smack? (http://schaufler-ca.com/)
10:08:17 <deztructor> #info Denis Zalevskiy - Jolla, middleware
10:08:37 <iekku_> #info iekku pylkk� - jolla, developer affairs
10:09:38 <BasilSemuonov> Stskeeps: I added it on piratepad. same question as fk_lx
10:09:50 <SK_work> a lot of stuff around security has been developed on Linux. As fk_lx pointed out, Smack is one of them (used by Tizen ?) There is also SELinux, used now by Android
10:09:56 <Jonni> fk_lx: Atleast I havent familiarized myself with Smack yet. I'll put looking into that in my todo list, so I cannot comment yet if its viable or not.
10:09:58 <Stskeeps> BasilSemuonov: thanks :) if you'd like to elaborate more, feel free
10:10:10 <SK_work> And the infamous aegis, from Harmattan.
10:10:21 <netzvieh> wasn't my bullet point, but I think there should be some discussion of MAC to userdata, so we can decide which apps have access to what
10:10:49 <deztructor> SELinux is the most mature and supported for a long time by D-Bus
10:10:50 <Stskeeps> there's a couple of challenges there, such as upstream kernel support - as an example, ubuntu patches their kernel heavily for AppArmour
10:11:01 <Stskeeps> and i think smack is getting patched into kernels as well
10:11:06 <SK_work> IMO, a resource based security should be present (like aegis, the only security system I have experienced), however, this is double edged, as aegis was also a PITA for devs
10:11:14 <netzvieh> I also found this post a nice starting point for a discussion: https://together.jolla.com/question/41718/privacy-security-usability-subjective/
10:11:24 <Stskeeps> as a technology, smack isn't bad - it sure matured a lot since begining
10:11:57 <Stskeeps> and it is getting integrated into systemd, as well, which is a plus
10:12:21 <M4rtinK> also, isn't Android using SELinux ?
10:12:51 <Stskeeps> yes -- and given sailfishos' need to run on existing android devices, selinux may not be the worst direction forward, either
10:13:02 <deztructor> Stskeeps: iirc, smack has very short story of support from d-bus
10:13:30 <fk_lx> so maybe a roadmap connected question: When more or less we can expect such kind of security mechanism in Saifish OS? 3 months, half a year, 1 year?
10:14:01 <fk_lx> Jonni: ^
10:14:18 <SK_work> deztructor: Is DBus that important ?
10:14:27 <Stskeeps> the challenge is also that security frameworks and restrictions are like red cloths towards developers :) a lot of this enforcement would come from early checking, so it wouldn't work well if people just 'root' their devices like happens in android
10:14:35 <SK_work> It is easier and nicer to develop UI controls, yep, but what else does it provides ?
10:14:54 <deztructor> SK_work: it is widely used, you can't exclude it
10:14:59 <SK_work> deztructor: right
10:15:05 <fk_lx> in my opinion local security is better than overcaring Harbour strict rules
10:15:11 <SK_work> fk_lx: +1
10:15:17 <fk_lx> which block submitting useful apps
10:15:27 <fk_lx> thanks there is Openrepos
10:15:29 <Stskeeps> though sandboxing also disturbs some developers
10:15:35 <M4rtinK> fk_lx: +1
10:15:52 <veskuh> fk_lx, harbour limits are not because of security. Most limits are becasue of API compatibility at the moment,.
10:16:15 <M4rtinK> well, users should be always in control
10:16:21 <fk_lx> M4rtinK: +1
10:16:28 <BasilSemuonov> veskuh: scriptlets are forbidden. and this is security issue
10:16:37 <veskuh> BasilSemuonov, true
10:16:42 <deztructor> fk_lx: openrepos contains some very bad repos :p e.g. with copy of system packages breaking OS
10:16:55 <M4rtinK> give them enough red text and warnings but they should be able to override it in the end
10:16:56 <Jonni> fk_lx: if you mean aegis/smack like mechanism, it would depend how much help we get from community for improving middleware, but I would not expect that kind of features coming this year. Most likely security improvements coming this year would be smaller scale changes, like removing cleartext passwords from databases and improving linux file/group permissions.
10:17:10 <SK_work> deztructor: however openrepos is the place to provide many useful packages, like many popular apps
10:17:15 <deztructor> fk_lx: e.g. NielDK repos
10:17:31 <fk_lx> Jonni: good to hear clear statement, good that those small issues will be at least worked on
10:17:35 <deztructor> SK_work: yeah, and no proper QA so you can easily break your system :)
10:17:38 <Stskeeps> deztructor: i don't think we should go offtopic regarding repositories
10:17:44 <Stskeeps> security is the topic at hand :)
10:17:50 <iekku_> we are having plans to give more control to users, regarding to APIs.
10:18:10 <iekku_> we just need to have everything on place at server side first
10:18:35 <iekku_> and it might not be really high at priority list currently.
10:18:44 <SK_work> how does policy(pol)kit fit in the picture as well ? I have seen this on desktop linux, that provide access to resources and services
10:18:48 <deztructor> Jonni: maybe initially it worth to start to develop a set of security policies?
10:18:50 <SK_work> and it seems to be rather dev friendly
10:19:02 <Stskeeps> perhaps are there anybody who would like to talk about their experiences with other platforms and their security policies towards apps?
10:19:08 <SK_work> Jonni: what's the help needed from community ?
10:19:10 <Stskeeps> just so we can understand rest of the world's ways to do things
10:19:27 <kimmoli> its safety provided by harbour QA, security should be on device
10:19:27 <fk_lx> what is security of users/clients data on Jolla servers? Who has access to my data on Jolla servers? Why downloads of free apps are stored as user data and is it really needed?
10:19:54 * deztructor is happy with fedora selinux integration
10:20:12 <SK_work> fk_lx: (I don't think that this fits the best in "security model apis")
10:20:12 <veskuh> Stskeeps, Symbian signed was horrible pain for platform and 3rd party developers .. For Java midlets the constant nag for access to net and everythign was bad for users.
10:20:26 <iekku_> +1 for SK_work
10:20:28 <SK_work> deztructor: me not, It's rather hard to (for example) configure your web server with SE on
10:20:49 <oniongarlic> bb10 is quite nice for the user side, asks on first start that this and that is needed but user can select what permissions are given and app should handle cases when something isn't granted
10:20:51 <fk_lx> SK_work: there was sth about security model in the topic
10:20:53 <veskuh> On android and apple as user I like that I can check access of apps afterwards and revoke for example gps or notification access.
10:21:01 <Stskeeps> fk_lx: your apps are provided as a dynamic RPM repository to you and to ensure you get upgrade notifications and so on, it needs to know what apps you have installed to provide better for it in UI, and in factually delivering updates to you; all perfectly sane
10:21:02 <deztructor> SK_work: there are GUIs like firewall configuration tool
10:21:12 * sledges jumps in
10:21:24 <Jonni> fk_lx: thats a bit off topic but http://jolla.com/privacy-policy answers most parts of your data collect questions.
10:21:30 <netzvieh> I only know SELinux from RHEL/Fedora and I think it works rather well, it needs a bit of getting used to, but it's okay then :) mobile no experience
10:21:36 <fk_lx> Jonni: thanks
10:21:45 <Stskeeps> fk_lx: from previous maemo we know how miserable it is to have a whole SW repository downloaded at every single chance it gets
10:21:48 <lbt> gah
10:22:19 <Stskeeps> (it can easily get up to several mb several times a day)
10:22:37 <netzvieh> veskuh: but this isn't standard android behaviour, is it? I know you can do it on iOS, but on android?
10:23:01 <SK_work> netzvieh: on android you can't revoke most of the ermissions
10:23:01 <oniongarlic> and you can also revoke and grant specific permissions afterwards
10:23:09 <SK_work> however on iOS you can revoke location
10:23:21 <SK_work> and more stuff in iOS 7 (but can't remember)
10:23:39 <lpotter> I know for me, aegis was horrible to work with. I even had the technical manual on my desk - it was insane. glad no one is talking about that...
10:24:03 <SK_work> lpotter: aegis was horrible for devs too
10:24:21 <BasilSemuonov> SK_work: seemed fine for me
10:24:26 <deztructor> aegis is not only horrible, it is also immature and vulnerable :)
10:24:32 * lbt points out something that came up at ELC in talks. Why bother breaking security using an exploit etc when you can pop up a box saying "Can I access your wallet please?"
10:24:41 <fk_lx> Jonni: it very general but I would like this topic to come back on some other discussion. I would like to know more about who has access (in general) to my data from Jolla - all developers, chosen group etc.
10:24:47 <alterego> lbt: lol
10:24:57 <fk_lx> Jonni: I haven't found such information on that website
10:25:00 <lbt> so as well as selinux we need a data access policy as per android etc
10:25:10 <stephg> lbt: yes and MAC is on M if people don't turn it off (thinking of SEL and aegis again)
10:26:27 <lbt> IMNSHO we would be daft not to follow android's selinux lead given how we piggy-back on their low level services which (aiui) will become increasingly selinux aware
10:26:29 <mattaustin> On the desktop, I've been quite happy with recent Ubuntu/GNOME releases which use policykit I think. I either enter my password to grant access, or can select another user on the machine who does have permission (e.g. change machine-wide network settings) and enter their password. But I don't have dev experience with it.
10:26:42 <netzvieh> "Aard: "signondb accessible": This will be changed in the upcoming update, with a bigger change in privilege handling. This is code was inherited from the N9 (masked by aegis there), and is shared with Ubunutu (the privilege control bit is Jolla specific, though)" can someone say something about this?
10:27:06 <stephg> lbt do they have sane policies upon which to build?
10:27:15 <M4rtinK> first step for SELinux might be to label the plaintext password dbs with a different label than what third party apps can access
10:27:25 <Stskeeps> (8 minutes left)
10:27:30 <lbt> stephg: sane may be a stretch ... but yes
10:27:34 <M4rtinK> would solve the most serious issues IMHO
10:27:59 <stephg> sane(ish) then, seems speed of implimentation for this, or at least spec'ing is critical
10:28:31 <lbt> also - how can we prototype this stuff? eg on minimal Mer VMs
10:29:03 <lbt> we have some selinux/sepol libs in mer-tools (don't ask)
10:29:04 <Stskeeps> question is also what people would think of sandboxing applications, ie, that world view of an app would be severely limited by default
10:29:32 <SK_work> Stskeeps: they are already limited by harbour limitations (atm)
10:29:42 <Stskeeps> sure, but harbour isn't the only way apps make it to devices :)
10:29:44 <lbt> lets be clear though - this would be on 'other peoples phones'
10:30:08 <lbt> we still have  "do what you want on your own device" ?
10:30:12 <SK_work> if there is a security policuy uimplemented, there is a need of a very nice gui ton control this
10:30:18 <lbt> SK_work: +1
10:30:32 <SK_work> a popup like: app is trying to change your ambience, app is trying to read contacts
10:30:43 <veskuh> Well, at the moment you can write app that is for example bookmark editor for browser. If app is sandboxed then not.
10:30:49 <SK_work> allow always, allow for x min, allow one time, deny this time deny always
10:31:01 <SK_work> veskuh: it depends on the level of the sandbox
10:31:01 <Stskeeps> veskuh: unless permitted to, of course
10:31:08 <SK_work> if you have permissions
10:31:13 <lbt> veskuh: or at least, until that API is published and acl'ed
10:31:27 <veskuh> lbt, well, I'm never going to develop that API.
10:31:30 <SK_work> it's not as sandboxed as (eg) BB10: BB10 apps are run in separated users (IIRC)
10:31:53 <lbt> veskuh: isn't browser open-source though ... :)
10:32:02 <lbt> SK_work: I would advocate for that approach
10:32:14 <Stskeeps> android apps run with seperated users, too
10:32:19 <veskuh> lbt, yes, feel free to write that :)
10:32:24 <lpotter> I am reminded about Qtopia security - SXE. Used LIDS. I liked that it was simple. (some article apparently I wrote about it) http://porky.linuxjournal.com:8080/LJ/165/9896.html
10:32:39 <Stskeeps> (3 minutes left)
10:32:43 <SK_work> problem about this is to define a very large set of permissions: all system daemons will need a permission to protect their dbus interface (for example) etc.
10:32:57 <veskuh> I guess I'm minority, but I like having open platform. We are pretty much last one that there exists.
10:33:07 <kimmoli> veskuh: +1
10:33:19 <lbt> I think we need to look at what IOS/Windows and more importantly Android/CM do for ACLs for 'on device services'
10:33:30 <lbt> veskuh: this should be fully open
10:33:31 <netzvieh> veskuh: if you use e.g. SELinux you can turn it off an still be an open plattform
10:33:38 <M4rtinK> I would advice to fix the most glaring issues first
10:33:47 <veskuh> netzvieh, default config matters
10:33:50 <deztructor> user should define trusted sources
10:33:55 <M4rtinK> say plaintext passwords and locatio access
10:34:00 <lbt> veskuh: but my device being open == open-to-me ... not open-to-you :D
10:34:01 <SK_work> veskuh: +1
10:34:19 <netzvieh> lbt: +1
10:34:22 <deztructor> and application from those sources can use what they want. It can be logged (services app is using) and user can see it
10:34:22 <lbt> SK_work: what's your paypal passwd btw?
10:34:27 <veskuh> lbt, yeah and thats the point, I want apps that are imaginative and do unexepected connections
10:34:31 <SK_work> lbt: lol ? :D
10:34:52 <veskuh> lbt, not  just sandboxed ones where app is strictly an app like experience
10:34:54 <lbt> veskuh: you too ... paypal passwd please... i'll buy you an unexpected present :D
10:35:08 <lbt> I'm kidding but trying to make a point
10:35:18 <Stskeeps> alright, time for next topic on the agenda
10:35:28 <netzvieh> veskuh: yeah, but I want still control about those connections, and if i don't like them, i want a way to turn them off
10:35:37 <deztructor> so, if user trusts applications from e.g. lbt it can set lbt as the trusted source ;)
10:36:07 <Stskeeps> #topic Better roadmapping
10:36:22 <Stskeeps> #topic Better roadmapping
10:36:39 <Stskeeps> #info From etherpad: Better Roadmap, not neccessarily with dates, but with info like: what is worked on atm, (how/where) can the community contribute, is there someone we could talk to about $topic
10:36:53 <lbt> like MSameer's recent email ?
10:37:06 <netzvieh> lbt: which one?
10:37:10 <Stskeeps> #info From Jolla, bijjal is representing today (SW program manager at jolla)
10:37:10 <fk_lx> I would expect roadmap about when roadmaps connected with different open parts will appear.
10:37:29 <lbt> http://www.mail-archive.com/mer-general@lists.merproject.org/msg01441.html
10:37:34 <Stskeeps> bijjal: do you want to intro anything about how we work or should we go on a Q&A basis instead?
10:37:45 <bijjal> sure, I can
10:37:50 <Guest62403> Whats comming in the next few releases would be nice. With something like priorities and what might not be included.
10:37:55 <netzvieh> lbt: thanks
10:38:26 <bijjal> hello all.. a quick outline on how we practically work here: preplanning > iteration planning > feature integration deadline > bug fix integration deadline > stabilization period > public release
10:38:38 <SK_work> I would expect people from Jolla to explain what they contribute to (eg) Nemo MW
10:38:47 <SK_work> MSammer explained the DConf thing very well
10:39:07 <SK_work> others are less explained https://github.com/nemomobile/lipstick/pull/167
10:39:11 <Stskeeps> #info how jolla SW programme works: preplanning > iteration planning > feature integration deadline > bug fix integration deadline > stabilization period > public release
10:39:16 <SK_work> (even if you can guess that this is for support of folders)
10:39:36 <bijjal> SK_work, may i quickly run through how things run here and you could add in how things can be made better/more visible?
10:39:52 <SK_work> bijjal: right
10:39:57 <bijjal> thanks
10:40:10 <bijjal> #info This cycle repeats roughly about every 20 working days where all sailors meet to plan and agree on the work for approximately next 2 releases. The cycles are short to accommodate changing priorities as much as possible and release often.
10:40:37 <MSameer> SK_work: but I got no reply which is also discouraging ;)
10:41:13 <SK_work> MSameer: means that we are all confident about your plans
10:41:19 <bijjal> #info More often than not, we end up having to shift priorities here and there resulting in actually knowing the actual release content when we have the first release candidate of an update
10:41:44 <fk_lx> MSameer: don't expect replies or involvement, when previously roadmaps and disscussion about future was neglected
10:42:08 <bijjal> Having said this, we are more than happy to receive suggestions on how we can share info better
10:42:10 <fk_lx> MSameer: getting community to participate requires time and patience
10:42:26 <MSameer> I am not sure we should hijack the meeting farther?
10:42:33 <MSameer> and discuss that
10:42:44 <Stskeeps> (let us let bijjal finish and we can discuss :)
10:42:44 <prometheus> bijjal: Could you share the iteration plan once it is complete?
10:43:08 <SK_work> bijjal: IMO you can share some information aboàut what to expect after the iteration planning, and before RCs
10:43:10 <bijjal> so, we have 2 bits : Application/UI features  and then the open components. I presume both are of interest to all?
10:43:12 <Guest62403> Making public what features are in stabilization could help. Without giving dates.
10:43:13 <SK_work> so that we are aware of plans, and changes
10:43:19 <SK_work> bijjal: both
10:44:02 <SK_work> starting the release phase is also interesting for thiose who are impatient, and waiting for the next update
10:44:02 <netzvieh> bijjal: you could write e.g. a mail after those meetings where you give a quick rundown on what you are going to work for the next releases, and then if in the next meeting you see, that some point isn't on the agenda any more, give a quick rundown what problems there were/why it was dropped
10:44:04 <prometheus> bijjal: Obviously things change, and when they do, just say so. No problem.
10:44:24 <bijjal> SK_work, prometheus, yes I think we can share information after the iteration planning .. though it must be noted that it is the plan and may not make it to the target release
10:44:48 <SK_work> bijjal: yep, and inform that some features are delayed in the RC phase
10:44:55 <netzvieh> then, if possible an overview of e.g. the commit activity in the open sourced parts, but all in one page
10:45:04 <SK_work> if you use the right words, people won't be dissapointed (I think)
10:45:05 <Stskeeps> at least it could help quite a bit that we state planned effort in open components -- it very well could be part of planning effort to understand target of effort anyhow
10:45:13 <fk_lx> bijjal: it's ok even inaccurate information or the one that can change is better than no information
10:45:34 * lbt notes that roadmapping for Jolla releases != roadmapping of packages .. at least not 1:1
10:45:38 <netzvieh> Stskeeps: +1, especially for other devs to see where they can contribute
10:45:48 <SK_work> fk_lx: +1
10:45:57 <sledges> netzvieh: +1
10:46:03 <SK_work> Stskeeps: +1
10:46:14 <veskuh> fk_lx, you have been criticizing of us changing plans and now you again say that we should make unsure plans more public?
10:46:39 <SK_work> veskuh: changing plans and hiding the changes is bad
10:46:40 <fk_lx> veskuh: when it's clearly said it's unsure it's ok
10:46:58 <prometheus> veskuh: I have found that people tend to critizise change less when they see it coming
10:47:04 <fk_lx> veskuh: worse is if something is promised (open sourcing Silica) and then forgotten and not explained
10:47:07 <bijjal> fk_lx: a question, apart from the obvious benefit of knowing whats coming up, is there any other use from your pov on knowing the planned release content ahead of time?
10:47:08 <SK_work> however having a plan even if it's approxiamative is better
10:47:27 <sledges> changing plans because there'ß no time to implement feature X - so better to let community know, and that feature might even not be changed! as those developers will implement it for the iteration
10:47:31 <sledges> in time
10:47:35 <lbt> I think one issue here is that it's hard to differentiate between desires and plans
10:47:49 <lbt> we may desire things to happen but find obstacles along the way
10:48:13 <lbt> some are things that are part of our opensource work - others are commercial
10:48:24 <fk_lx> I would like to hear about plan/roadmap when C++ part of Silica will be open source finally
10:48:34 <lbt> and we need to work on how to communicate those with less confusion
10:48:47 <Stskeeps> one thought is: avoid duplication of work; perhaps take on some tasks to help out, or discuss major changes coming
10:48:47 <lbt> the problem is that the easy solution is silence
10:49:07 <bijjal> Stskeeps: Do you think the interest more on where we are heading in sw development than knowing actual release content?
10:49:09 <SK_work> lbt: +1
10:49:23 <Stskeeps> bijjal: yeah, to some level -- sometimes app developers might want to know that a certain API is coming
10:49:27 <fk_lx> lbt: silence is usually running away not facing the problems
10:49:36 <sledges> Stskeeps: bugs.merproject.org should be used for open components
10:49:46 <sledges> will ease after nemo->mer merge
10:49:52 <SK_work> sledges: or at least bridged with internal bz
10:49:57 <lbt> sledges: yes, that's in the desires list :)
10:50:02 <lbt> it's also being planned :)
10:50:05 <bijjal> Stskeeps: :nod
10:50:47 <fk_lx> so does anyone from Jolla wants to say something about roadmap when Silica components C++ will be open sourced as it was promised
10:50:56 <fk_lx> or is it a topic that will be ignored and avoided
10:50:58 <SK_work> bijjal: having upcoming features advertized can also create interest toward the next update, instead of keeping users with their problems
10:50:59 <lbt> s/promised/desired/
10:51:06 <Stskeeps> fk_lx: Silica is not open source today, effort to work on this topic is ongoing - that's the truth
10:51:19 <SK_work> lbt: it was promised (see fk_lx's article actually)
10:51:21 <fk_lx> lbt: promised
10:51:26 <mattaustin> I think roadmaps can certainly impact developer motivation. E.g. Knowing what might be a useful project/app vs knowing it's not worth doing as it will become part of the OS (like MMS functionality). Also where open source efforts could help to contribute collaboratively rather than duplicated effort/time.
10:51:41 <fk_lx> lbt: it turned into only desire half a year later after promise
10:51:51 <netzvieh> and featurewise I'd like some timeline in form of 2014Q3 or something like that, even if it will change
10:51:59 <fk_lx> lbt: desire with a lot of doubt that is
10:52:02 <Guest62403> why is this silica thing so important
10:52:13 <SK_work> because of promises
10:52:32 <oniongarlic> a timetable for APIs would be nice to know and when they are allowed on harbour so you have time to prepare (waiting for gstreamer here..)
10:52:34 <Guest62403> a promise doesn't mean it will happen immidiately
10:52:40 <M4rtinK> and being able to contribute features and fixes
10:52:48 <Stskeeps> in practice, i think it's worth more to work on the openness of the bits that are currently open, get that done, than try to open more bits that you do a bad job at being open with
10:52:53 <SK_work> netzvieh: just like the BB10 "plane arrival display" for developers, but this time for upcoming features (both devs and users)
10:52:56 <kimmoli> it was in a "roadmap" and now delayed. and you want more of these delayed things in roadmap? sounds contradictonary to mee
10:53:01 <fk_lx> Guest62403: well if "soon" is already more than year, you can have concern regarding promise
10:53:02 <bijjal> SK_work: I do agree, however, we want to be careful on what we *promise* until we know for sure. So, the previous suggestion to share the plans after our internal planning sounds like a good step.
10:53:08 <lbt> fk_lx: SK_work... and with that misunderstanding you see why silence becomes attractive :/
10:53:12 <netzvieh> SK_work: got a link for that?
10:53:13 <oniongarlic> SK_work: those are nice
10:53:14 <M4rtinK> was that rotation fix from coderus merged BTW ?
10:53:16 <SK_work> Guest62403: a promise makes it happen at some point
10:53:51 <lbt> Stskeeps: bijjal: is it fair to say we can never 'promise' anything until it's released ?
10:53:55 <fk_lx> lbt: care to talk about why C++ is not ready to be open yet?
10:54:09 <SK_work> netzvieh: http://img.blackberryos.com/bbos-images/2013/blackberry-10-3-roadmap-von.jpg
10:54:18 <fk_lx> lbt: be open
10:54:25 <fk_lx> lbt: about that
10:54:37 <bijjal> lbt: it is right in most cases that we cannot promise until we have the release mostly ready
10:54:53 <sledges> Stskeeps: +1
10:54:54 <lbt> yeah "never" is a bit absolute
10:55:00 <fk_lx> bijjal: that why you shouldn't give promises on important events if you are unsure of something
10:55:02 <M4rtinK> also would be nice to build Silica on the desktop for running apps during development
10:55:03 <bijjal> but that shouldnt stop us from sharing our intention
10:55:03 <Guest62403> personally i wouldn't expect it soon (1-2 years). And maybe it was a bad thing for jolla to promise it but its not a huge deal.
10:55:04 <netzvieh> SK_work: well that's nice :) I wouldn't mind if it was less specific though
10:55:11 <fk_lx> M4rtinK: +1
10:55:28 <SK_work> netzvieh: yep, but something like this could be nice
10:55:41 <fk_lx> Guest62403: well for me it is a deal, people got attracted by open platform and promises
10:55:51 <SK_work> bijjal: what do you think about another point during RC phase, to remove features that didn't made into the final result ?
10:55:56 <Stskeeps> i think we're going a bit off topic about this. Silica is not open source currently. State is that there's no exception granted (see policy listed in the other meeting) for open sourcing the current codebase, which is BSD-licensed QML and closed source C++, but there is a desire. Work to get that exception is ongoing.
10:56:04 <MSameer> M4rtinK: emulator has silica already built for x86 (might be usable on the desktop)
10:56:05 <veskuh> In silica's case engineering (me too) was saying open silica too soon, but we though it was happening faster. I can't go into reason, but now situation is not as simple anymore.
10:56:12 <M4rtinK> AFAIK developers would really like this from what I've herd so far
10:56:26 <bijjal> SK_work: you mean update the first info mail on planned content with things that got left out?
10:56:26 <netzvieh> Stskeeps: #info that? :)
10:56:36 <SK_work> bijjal: yep
10:57:22 <fk_lx> veskuh: well I think community deserves a clear statement on that topic, maybe even an appology
10:57:35 <bijjal> SK_work: should be doable too IMO. Stskeeps, Aard, veskuh, opinions?
10:57:36 <fk_lx> veskuh: FOSDEM would be preferably the best place for that
10:57:47 <Stskeeps> #info Silica is not open source currently. State is that there's no exception granted (see policy listed in the other meeting) for open sourcing the current codebase, which is BSD-licensed QML and closed source C++, but there is a desire. Work to get that exception is ongoing
10:57:49 <Aard> bijjal: ?
10:58:01 <Stskeeps> bijjal: yeah, should be possible to extract
10:58:22 <M4rtinK> also an upstream Silica repo would be nice
10:58:22 <bijjal> Aard: we have a suggestion to share info on the planned content after our iteration planning and update the info after RCs are made on things that got left out
10:58:41 <M4rtinK> even if only for the QML part for the time being
10:59:03 <Stskeeps> M4rtinK: regarding coderus' it fits in the same kind of thing related to QML patching, that was discussed
10:59:05 <Aard> bijjal: I'd give it a try, wait how it's received. if we get lot's of "waaah, but you promised feature x and now you don't deliver" we stop doing it, if it's received well we continue
10:59:18 <fk_lx> another thing that would be nice to know
10:59:34 <fk_lx> I would like to know about Python + PyOtherside support roadmap in Sailfish (and btw. _stopping_ _discrimination_ of some community members asking about that, only because _they_ are asking about that)
10:59:50 <bijjal> Aard: yes, we could attempt it in the least.. a bit more work, but for the better
11:00:21 <netzvieh> Aard: bijjal +1
11:00:24 <veskuh> M4rtinK, It would probably make development of silica more messy to have it split in two repos as qml and c++ are quite tightly related there.
11:00:31 <Guest62403> explain to the community that if the whole announcement thing backslashes it will stop
11:01:01 <lbt> fk_lx: the python stuff is, afaik, all happening in mer
11:01:09 <SK_work> Guest62403: don't think that threatening people is good ...
11:01:14 <M4rtinK> I am also interested in Python support timeline
11:01:21 <SK_work> there is some expectation management to be done
11:01:23 <MSameer> SK_work: +1
11:01:25 <Stskeeps> fk_lx: aard explained SDL and that stuff in a recent sailfishos-devel mail: "Please wait, we're not yet ready to allow new libraries in harbour
11:01:25 <SK_work> but I think this can be done
11:01:28 <Stskeeps> intake. We're still working on solving the issue."
11:01:29 <Guest62403> It's a fair explanation i think.
11:01:34 <Stskeeps> so that's a bigger blocker currently
11:01:59 <Stskeeps> 4 minutes left of topic
11:02:00 <BasilSemuonov> just change 'promised' to 'feature is in work, eta sept 2014'.
11:02:09 <sledges> bijjal: Aard: SK_work: so, community is given list of features that jolla dropped due to resourcing, so community can choose to work on them? avoiding dup work, and least distractions for both sides?
11:02:11 <M4rtinK> veskuh: but could get you free contributions and would motivate you to open the C++ part :)
11:02:12 <lbt> SK_work: if the community takes "this is how management works" as a "threat" then we have problems! :D
11:02:17 <sledges> each iteration
11:02:25 <M4rtinK> veskuh: win - win :)
11:02:44 <veskuh> M4rtinK, yes, that is true.
11:02:45 <sledges> features+bugfixes (in open components) - to be completely precise
11:02:47 <Aard> sledges: dropping a feature for a release does not mean we won't release it. for example, if a feature gets dropped during rc phase it most likely was just not stable enough, and will be in the update after that
11:03:09 <SK_work> Aard: then explain in RC mail
11:03:20 <SK_work> feature not stable enough, maybe next release etc.
11:03:21 <sledges> Aard: then it would be useful to give longer term plans, so community could chip in early
11:03:30 <sledges> on features that haven't even started
11:04:03 <bijjal> SK_work: yes, if something is dropped, it will be reasoned
11:04:19 <netzvieh> #info it was suggested for Jolla to share info on the planned content after our iteration planning and update the info after RCs are made on things that got left out
11:04:51 <bijjal> sledges: longer terms plans would need a bit of thought from our end too to figure out how we want to take in contributions. But I dont disagree with the idea itself
11:05:14 <sledges> by structuring that email properly (features unstable, not-started, etc) would maximise community's involvement by analysing that email
11:05:16 <Stskeeps> thanks for a lot of good views, next topic
11:05:25 <Aard> sledges: yes, but that'll only cover high level items. lower level enablers (which are exactly the things interesting for developers to help out) are currently too much effort to track. I'd like to have that open as well, but far that it'd be better to go through open bugzilla (i.e., has a dependency on mer restructuring before that can happen)
11:05:25 <fk_lx> sledges: +1
11:05:42 <sledges> Aard: +1
11:05:45 <Stskeeps> #topic Community localization
11:05:57 <Stskeeps> #info From etherpad: Including community localization contributions (translations, vkb layouts) in the OS.
11:06:09 <Stskeeps> #info From Jolla side: pvilja1 and pvuorela
11:06:27 <Stskeeps> pvuorela: pvilja1, do you want to intro anything, or just go for general Q&A?
11:06:55 <pvilja1> Stskeeps, i could go through translation tool situation
11:07:00 <Stskeeps> cool, that'd be helpful
11:07:04 <sledges> \o/
11:07:10 <pvilja1> #info Jolla is working on an open translation tool. Tool will be pootle (http://pootle.translatehouse.org/) and is already in use internally. Our target is to get community tool fully integrated into our internal processes, providing up to date sources to all languages and keeping translations up to date without manual work with files.
11:07:24 <pvilja1> #info Putting the integration into place is taking time and as Jolla team is still small, this work is often put to side for other ongoing tasks. That is why I am late with this. Original target was that the tool would be open already. At the moment there is more urgent activity delaying the work on our side.
11:08:04 <pvilja1> What else… QA work will stay on Jolla side even after the tool is open. And getting new languages on device content is our navigation decision, so giving more info on those schedules is another story.
11:08:48 <pvilja1> so, go ahead and shoot.
11:08:54 <Guest62403> What about keyboard layouts? Some are missing and we have stuff already in Openrepos.
11:09:10 <Guest62403> Are these going to be included in harbour?
11:09:17 <pvuorela> #info on keyboard layouts, the API is considered unstable at the moment, but the layout files have been bsd licensed for allowing people to play with them. some changes have been also done that allow to plug in custom input engines, like composing japanese input.
11:09:32 <netzvieh> pvilja1: what's stopping you from adding a new language on community request but not incorporating it until it has gone through QA?
11:09:39 <Jarno> Any chance of getting the strings out before so the current development on Transifex can be improved?
11:10:42 <pvuorela> Guest62403: i wouldn't yet like to declare layout API stable.
11:11:06 <SK_work> pvilja1: how is the best translation string decided (if the translation system is open)
11:11:23 <SK_work> does Jolla decides, or will it be ~fully managed by community ?
11:11:49 <pvilja1> netzvieh, Jarno: That'd mean manual file handling that'd take time. that's why i am pushing to get our own tool in use
11:12:13 * sledges would like a peer-review idea on deciding if translation is "perfect"
11:12:20 <sledges> i guess pootle supports that
11:12:40 <netzvieh> SK_work: QA by Jolla means Jolla decides in the end i think, though I'd like a peer review aswell
11:12:56 <Guest62403> pvuorela: I understand but its kind of a topic for some users (i don't have an official kb for my native language). Including stuff with a warning and alerting devs prior to possible breakage could do it?
11:13:06 <M4rtinK> I would say look how other projects, like Fedora for example, do tat
11:13:14 <pvilja1> SK_work: work will be done in co-operation, but our QA will have the last work on content going to device. It is our responsibility to make sure what we show on device (there is e.g. blacklisted terms due to licensing we need to avoid)
11:13:24 <SK_work> pvilja1: right
11:13:25 <SK_work> no problem
11:13:27 <SK_work> sounds good
11:13:54 <Stskeeps> regarding VKBs: is there any way we can seperate out VKB layouts to a github repository or something, so people can contribute layouts there, and then have an option to enable?
11:13:58 <Stskeeps> as an idea
11:14:08 <Stskeeps> so it's easier to batch change API
11:14:32 <netzvieh> #info pvilja1 work will be done in co-operation, but our QA will have the last work on content going to device. It is our responsibility to make sure what we show on device (there is e.g. blacklisted terms due to licensing we need to avoid)
11:14:41 <pvuorela> Guest62403: considering harbour, that would be same for all apps using some unstable API.
11:14:42 <sledges> currently they are all on a TMP thread, and I know one more (Lithuanian) only as a draft, not published
11:14:42 <M4rtinK> sounds like a good idea
11:14:50 <SK_work> Stskeeps: maybe we need some "maintainers" for each keyboard
11:15:01 <M4rtinK> the layouts on Github one
11:15:12 <SK_work> if there is a breakage, maintainters will have the role to update their kbd, otherwise, it's not included in next update
11:15:36 <pvuorela> Stskeeps: i suppose an option could be having some "extras" type of repository creating a separate layout package.
11:16:01 <pvuorela> Stskeeps: those would be a bit second class citizens in the sense that prediction support would be missing.
11:16:42 <SK_work> a bit like gstreamer-good, bad, ugly ?
11:16:42 <Guest62403> pvuorela: i understand. The harbour should treat all "apps" in the same way.
11:18:21 <Stskeeps> pvuorela: could we potentially get to a point where layout API is stable and those available in harbour?
11:18:26 <Stskeeps> - what do you think is missing
11:19:08 <Stskeeps> er, those available for 'apps' in harbour
11:19:40 <pvuorela> Stskeeps: could get there some day, but i think we should first implement more features we've been thinking about.
11:19:43 <Stskeeps> :nod:
11:20:14 <Stskeeps> (10 minutes left --- anybody have more questions or things to discuss on this topic)?
11:21:01 <netzvieh> maybe an #info summary on the keyboard stuff?
11:21:05 <Guest62403> maybe an approcimate roadmap for new vbks?
11:21:12 <sledges> when could we expect community trans tool available? ;)
11:21:30 <Guest62403> if they are working on any.
11:21:34 <Stskeeps> #info potential idea: github repository for keyboard layouts for contributing to, with option to enable
11:21:47 <sledges> and how could community help in making this happen sooner?
11:22:55 <pvuorela> for repository, someone gathering layouts lying around into one could be a start.
11:23:02 <Jarno> Perhaps buy some more Jolla so they can hire more people ;-)
11:23:05 <sledges> #info interest is growing, I got noticed that Hebrew SFOS translation is already drafted if not more (by Avivbyo's team)
11:23:15 <Stskeeps> #info for repository, someone gathering layouts lying around into one could be a start.
11:23:30 <cybette> Jarno: +1 ;)
11:24:07 <Stskeeps> as an idea, perhaps we could release that repository once in a while as well along with a release, perhaps
11:24:09 <pvilja1> sledges: I cannot give guaranteed schedule, but once we have the instance set up it would be good to get some community help to test it. I will ask for that when tool is available.
11:24:19 <BasilSemuonov> cybette: start ww shipping! it's hard to get one from EU ;)
11:24:20 <Stskeeps> or somehow special-cased harbour
11:24:26 <M4rtinK> I would say even just publishing string dumps for the time being would help the current translation efforts
11:24:30 <sledges> pvilja1: great, the early adopters to the rescue :)
11:24:30 <Guest62403> I'd buy one for my mom but she can't use it without a natice Kb/translation :P
11:25:04 <sledges> Guest62403: what's the language ooi?
11:25:05 <pvuorela> Stskeeps: yeah, exactly. jolla would publish such extra layouts on harbour to avoid unstable api issue.
11:25:50 <cybette> BasilSemuonov: doing our best working on that!
11:26:05 <Stskeeps> #info suggestion to have jolla would publish such extra layouts on harbour to avoid unstable api issue.
11:26:14 <Stskeeps> (4 minutes left..)
11:29:27 <Stskeeps> while there's still people around - is this a good or a bad time for you to have meeting? from jolla pov, it helps that it's within working hours at least
11:29:54 <sledges> ZogG (not here) and SK_work had raised concerns
11:30:02 <MSameer> I don't like it as it's a bit early. I totally missed it too but lbt mentioning my name made me notice
11:30:05 <lbt> works for me ... nice to have PSA in various chans from anyone that remembers the meeting is coming up :)
11:30:16 <lbt> MSameer: I was 20m late too!
11:30:21 <sledges> same
11:30:28 <MSameer> lbt: but thanks for reminding me :)
11:30:34 <cybette> We can alternate meeting times every other week
11:30:35 <sledges> but caught up with logs
11:30:38 <SK_work> actually, it fits well today, because it's lunch time in Fr
11:30:45 <lbt> cybette: confusing
11:30:47 <cybette> could be a bit confusing though
11:30:47 <SK_work> but for ZogG it's bad, he would like on week ends
11:30:48 <mattaustin> Stskeeps: Great for me on my side of the world, but I think it's important to vary so everyone can be involved around the globe.
11:30:48 <cybette> yeah
11:31:06 <SK_work> what about aussies ? only lpotter participated
11:31:13 <stephg> is there anyone here that it's awkward for? (self answering question I guess)
11:31:23 <Stskeeps> 9:31pm in brisbane
11:31:27 <Guest62403> Not comfusing if you alert people. (twitter, tjc etc)
11:31:36 <SK_work> Stskeeps: sounds OK for them then
11:31:46 <Stskeeps> ok, let's alternate to the afternoon for the next one, and alert ahead of time
11:31:54 <sledges> -1
11:31:58 <sledges> ;P
11:31:59 <SK_work> maybe one time during the week end ?
11:32:04 <lbt> Stskeeps: :P
11:32:11 <SK_work> alert ahead of time is important
11:32:33 <prometheus> SK_work: +1
11:32:36 <netzvieh> SK_work: I think you have all in all less participation on weekends
11:32:45 <sledges> netzvieh: +1
11:33:03 <Guest62403> and maybe more people with hangovers or drunk :P
11:33:11 <Stskeeps> okay, let's discuss it on mailing list, i'll send it after my next meeting
11:33:17 <netzvieh> Stskeeps: bijjal so you are trying to get that mail after your iteration meeting out?
11:33:18 <sledges> just look at general chatter on freenode during weekends ;P
11:33:19 <Stskeeps> thank you all for participating, good meeting
11:33:27 <bijjal> netzvieh: yes
11:34:03 <prometheus> Thanks
11:34:08 <netzvieh> :) great
11:34:14 <Stskeeps> #endmeeting