10:00:51 #startmeeting SailfishOS, open source, collaboration: 6-May @ 10:00 UTC 10:00:51 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 10:00:57 #info Welcome to another week of SailfishOS OSS and collaboration meeting 10:00:58 #info Agenda today can be seen at https://lists.sailfishos.org/pipermail/devel/2014-April/004098.html 10:01:05 #topic Quick introductions (5 min), prefix your information with #info 10:01:09 #info community member and generally interested in how the Jolla is moving forward into the OSSea 10:01:22 #info Carsten Munk, Chief Research Engineer @ Jolla, today hat-less meeting chair 10:02:02 #info Filip Kłębczyk, community member... still... a fresh-born blogger 10:02:09 #info Soumya Bijjal, Software program manager @ Jolla 10:02:22 #info Martti Piirainen, Tieto employee, sailfish contributor 10:02:23 #info Carol Chen, community chief at Jolla, today on sick leave but didn't want to miss this meeting 10:02:41 get well cybette :) 10:03:05 netzvieh: +1 10:03:11 #info Community member, casual developer. Jolla owner in Australia. Interested in harbour Python support roadmap. 10:03:27 #info Gunnar Sletta - Qt graphics stuff - Sailor @ Jolla 10:03:38 netzvieh, fk_lx thanks :) 10:03:42 #info Steph Gosling:- Sailfish and Nemo community member 10:03:48 #info Aaron McCarthy, Software developer (location, connectivity, Qt) @ Jolla. 10:03:56 #info Lorn Potter, connectivity/sensors guy @ Jolla 10:03:58 #info vgrade, community member, adaptations 10:04:03 #info Basil Semuonov, software developer 10:04:04 #info Piritta Viljakainen, working with translations @Jolla 10:04:26 #info Eric Le Roux, bugzilla & t.j.c admin @Jolla 10:04:33 #info Lucien XU, Sailfish OS developer, Jolla community member 10:04:33 #info Jonni Rainisto, Security, privacy and locking @Jolla 10:04:35 #info community member, application developer, author of modRana 10:05:07 #info Hobbyist developer, long time lurker, Y-Radio author 10:05:09 #info community member, translator dutch languague pack 10:05:11 #info Pekka Vuorela - Jolla, text input, settings, calendar etc 10:05:55 #topic Security Model / APIs 10:05:55 #info Vesa-Matti Hartikainen - Jolla, Browser 10:06:18 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 #info Community member. GPGPU enthusiasts, owner of the first, not unique anymore, OpenCL enabled Jolla. 10:06:22 #info Kimmo Lindholm - DIY Otherhalf tinkerer, community member 10:06:26 #mode #mer-meeting +v veskuh 10:06:53 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 Stskeeps: seems we both have trouble +v veskuh ;) 10:07:15 yep 10:07:27 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 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 #info Denis Zalevskiy - Jolla, middleware 10:08:37 #info iekku pylkk� - jolla, developer affairs 10:09:38 Stskeeps: I added it on piratepad. same question as fk_lx 10:09:50 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 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 BasilSemuonov: thanks :) if you'd like to elaborate more, feel free 10:10:10 And the infamous aegis, from Harmattan. 10:10:21 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 SELinux is the most mature and supported for a long time by D-Bus 10:10:50 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 and i think smack is getting patched into kernels as well 10:11:06 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 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 as a technology, smack isn't bad - it sure matured a lot since begining 10:11:57 and it is getting integrated into systemd, as well, which is a plus 10:12:21 also, isn't Android using SELinux ? 10:12:51 yes -- and given sailfishos' need to run on existing android devices, selinux may not be the worst direction forward, either 10:13:02 Stskeeps: iirc, smack has very short story of support from d-bus 10:13:30 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 Jonni: ^ 10:14:18 deztructor: Is DBus that important ? 10:14:27 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 It is easier and nicer to develop UI controls, yep, but what else does it provides ? 10:14:54 SK_work: it is widely used, you can't exclude it 10:14:59 deztructor: right 10:15:05 in my opinion local security is better than overcaring Harbour strict rules 10:15:11 fk_lx: +1 10:15:17 which block submitting useful apps 10:15:27 thanks there is Openrepos 10:15:29 though sandboxing also disturbs some developers 10:15:35 fk_lx: +1 10:15:52 fk_lx, harbour limits are not because of security. Most limits are becasue of API compatibility at the moment,. 10:16:15 well, users should be always in control 10:16:21 M4rtinK: +1 10:16:28 veskuh: scriptlets are forbidden. and this is security issue 10:16:37 BasilSemuonov, true 10:16:42 fk_lx: openrepos contains some very bad repos :p e.g. with copy of system packages breaking OS 10:16:55 give them enough red text and warnings but they should be able to override it in the end 10:16:56 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 deztructor: however openrepos is the place to provide many useful packages, like many popular apps 10:17:15 fk_lx: e.g. NielDK repos 10:17:31 Jonni: good to hear clear statement, good that those small issues will be at least worked on 10:17:35 SK_work: yeah, and no proper QA so you can easily break your system :) 10:17:38 deztructor: i don't think we should go offtopic regarding repositories 10:17:44 security is the topic at hand :) 10:17:50 we are having plans to give more control to users, regarding to APIs. 10:18:10 we just need to have everything on place at server side first 10:18:35 and it might not be really high at priority list currently. 10:18:44 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 Jonni: maybe initially it worth to start to develop a set of security policies? 10:18:50 and it seems to be rather dev friendly 10:19:02 perhaps are there anybody who would like to talk about their experiences with other platforms and their security policies towards apps? 10:19:08 Jonni: what's the help needed from community ? 10:19:10 just so we can understand rest of the world's ways to do things 10:19:27 its safety provided by harbour QA, security should be on device 10:19:27 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 fk_lx: (I don't think that this fits the best in "security model apis") 10:20:12 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 +1 for SK_work 10:20:28 deztructor: me not, It's rather hard to (for example) configure your web server with SE on 10:20:49 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 SK_work: there was sth about security model in the topic 10:20:53 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 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 SK_work: there are GUIs like firewall configuration tool 10:21:12 * sledges jumps in 10:21:24 fk_lx: thats a bit off topic but http://jolla.com/privacy-policy answers most parts of your data collect questions. 10:21:30 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 Jonni: thanks 10:21:45 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 gah 10:22:19 (it can easily get up to several mb several times a day) 10:22:37 veskuh: but this isn't standard android behaviour, is it? I know you can do it on iOS, but on android? 10:23:01 netzvieh: on android you can't revoke most of the ermissions 10:23:01 and you can also revoke and grant specific permissions afterwards 10:23:09 however on iOS you can revoke location 10:23:21 and more stuff in iOS 7 (but can't remember) 10:23:39 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 lpotter: aegis was horrible for devs too 10:24:21 SK_work: seemed fine for me 10:24:26 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 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 lbt: lol 10:24:57 Jonni: I haven't found such information on that website 10:25:00 so as well as selinux we need a data access policy as per android etc 10:25:10 lbt: yes and MAC is on M if people don't turn it off (thinking of SEL and aegis again) 10:26:27 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 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 "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 lbt do they have sane policies upon which to build? 10:27:15 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 (8 minutes left) 10:27:30 stephg: sane may be a stretch ... but yes 10:27:34 would solve the most serious issues IMHO 10:27:59 sane(ish) then, seems speed of implimentation for this, or at least spec'ing is critical 10:28:31 also - how can we prototype this stuff? eg on minimal Mer VMs 10:29:03 we have some selinux/sepol libs in mer-tools (don't ask) 10:29:04 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 Stskeeps: they are already limited by harbour limitations (atm) 10:29:42 sure, but harbour isn't the only way apps make it to devices :) 10:29:44 lets be clear though - this would be on 'other peoples phones' 10:30:08 we still have "do what you want on your own device" ? 10:30:12 if there is a security policuy uimplemented, there is a need of a very nice gui ton control this 10:30:18 SK_work: +1 10:30:32 a popup like: app is trying to change your ambience, app is trying to read contacts 10:30:43 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 allow always, allow for x min, allow one time, deny this time deny always 10:31:01 veskuh: it depends on the level of the sandbox 10:31:01 veskuh: unless permitted to, of course 10:31:08 if you have permissions 10:31:13 veskuh: or at least, until that API is published and acl'ed 10:31:27 lbt, well, I'm never going to develop that API. 10:31:30 it's not as sandboxed as (eg) BB10: BB10 apps are run in separated users (IIRC) 10:31:53 veskuh: isn't browser open-source though ... :) 10:32:02 SK_work: I would advocate for that approach 10:32:14 android apps run with seperated users, too 10:32:19 lbt, yes, feel free to write that :) 10:32:24 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 (3 minutes left) 10:32:43 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 I guess I'm minority, but I like having open platform. We are pretty much last one that there exists. 10:33:07 veskuh: +1 10:33:19 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 veskuh: this should be fully open 10:33:31 veskuh: if you use e.g. SELinux you can turn it off an still be an open plattform 10:33:38 I would advice to fix the most glaring issues first 10:33:47 netzvieh, default config matters 10:33:50 user should define trusted sources 10:33:55 say plaintext passwords and locatio access 10:34:00 veskuh: but my device being open == open-to-me ... not open-to-you :D 10:34:01 veskuh: +1 10:34:19 lbt: +1 10:34:22 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 SK_work: what's your paypal passwd btw? 10:34:27 lbt, yeah and thats the point, I want apps that are imaginative and do unexepected connections 10:34:31 lbt: lol ? :D 10:34:52 lbt, not just sandboxed ones where app is strictly an app like experience 10:34:54 veskuh: you too ... paypal passwd please... i'll buy you an unexpected present :D 10:35:08 I'm kidding but trying to make a point 10:35:18 alright, time for next topic on the agenda 10:35:28 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 so, if user trusts applications from e.g. lbt it can set lbt as the trusted source ;) 10:36:07 #topic Better roadmapping 10:36:22 #topic Better roadmapping 10:36:39 #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 like MSameer's recent email ? 10:37:06 lbt: which one? 10:37:10 #info From Jolla, bijjal is representing today (SW program manager at jolla) 10:37:10 I would expect roadmap about when roadmaps connected with different open parts will appear. 10:37:29 http://www.mail-archive.com/mer-general@lists.merproject.org/msg01441.html 10:37:34 bijjal: do you want to intro anything about how we work or should we go on a Q&A basis instead? 10:37:45 sure, I can 10:37:50 Whats comming in the next few releases would be nice. With something like priorities and what might not be included. 10:37:55 lbt: thanks 10:38:26 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 I would expect people from Jolla to explain what they contribute to (eg) Nemo MW 10:38:47 MSammer explained the DConf thing very well 10:39:07 others are less explained https://github.com/nemomobile/lipstick/pull/167 10:39:11 #info how jolla SW programme works: preplanning > iteration planning > feature integration deadline > bug fix integration deadline > stabilization period > public release 10:39:16 (even if you can guess that this is for support of folders) 10:39:36 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 bijjal: right 10:39:57 thanks 10:40:10 #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 SK_work: but I got no reply which is also discouraging ;) 10:41:13 MSameer: means that we are all confident about your plans 10:41:19 #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 MSameer: don't expect replies or involvement, when previously roadmaps and disscussion about future was neglected 10:42:08 Having said this, we are more than happy to receive suggestions on how we can share info better 10:42:10 MSameer: getting community to participate requires time and patience 10:42:26 I am not sure we should hijack the meeting farther? 10:42:33 and discuss that 10:42:44 (let us let bijjal finish and we can discuss :) 10:42:44 bijjal: Could you share the iteration plan once it is complete? 10:43:08 bijjal: IMO you can share some information aboàut what to expect after the iteration planning, and before RCs 10:43:10 so, we have 2 bits : Application/UI features and then the open components. I presume both are of interest to all? 10:43:12 Making public what features are in stabilization could help. Without giving dates. 10:43:13 so that we are aware of plans, and changes 10:43:19 bijjal: both 10:44:02 starting the release phase is also interesting for thiose who are impatient, and waiting for the next update 10:44:02 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 bijjal: Obviously things change, and when they do, just say so. No problem. 10:44:24 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 bijjal: yep, and inform that some features are delayed in the RC phase 10:44:55 then, if possible an overview of e.g. the commit activity in the open sourced parts, but all in one page 10:45:04 if you use the right words, people won't be dissapointed (I think) 10:45:05 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 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 Stskeeps: +1, especially for other devs to see where they can contribute 10:45:48 fk_lx: +1 10:45:57 netzvieh: +1 10:46:03 Stskeeps: +1 10:46:14 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 veskuh: changing plans and hiding the changes is bad 10:46:40 veskuh: when it's clearly said it's unsure it's ok 10:46:58 veskuh: I have found that people tend to critizise change less when they see it coming 10:47:04 veskuh: worse is if something is promised (open sourcing Silica) and then forgotten and not explained 10:47:07 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 however having a plan even if it's approxiamative is better 10:47:27 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 in time 10:47:35 I think one issue here is that it's hard to differentiate between desires and plans 10:47:49 we may desire things to happen but find obstacles along the way 10:48:13 some are things that are part of our opensource work - others are commercial 10:48:24 I would like to hear about plan/roadmap when C++ part of Silica will be open source finally 10:48:34 and we need to work on how to communicate those with less confusion 10:48:47 one thought is: avoid duplication of work; perhaps take on some tasks to help out, or discuss major changes coming 10:48:47 the problem is that the easy solution is silence 10:49:07 Stskeeps: Do you think the interest more on where we are heading in sw development than knowing actual release content? 10:49:09 lbt: +1 10:49:23 bijjal: yeah, to some level -- sometimes app developers might want to know that a certain API is coming 10:49:27 lbt: silence is usually running away not facing the problems 10:49:36 Stskeeps: bugs.merproject.org should be used for open components 10:49:46 will ease after nemo->mer merge 10:49:52 sledges: or at least bridged with internal bz 10:49:57 sledges: yes, that's in the desires list :) 10:50:02 it's also being planned :) 10:50:05 Stskeeps: :nod 10:50:47 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 or is it a topic that will be ignored and avoided 10:50:58 bijjal: having upcoming features advertized can also create interest toward the next update, instead of keeping users with their problems 10:50:59 s/promised/desired/ 10:51:06 fk_lx: Silica is not open source today, effort to work on this topic is ongoing - that's the truth 10:51:19 lbt: it was promised (see fk_lx's article actually) 10:51:21 lbt: promised 10:51:26 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 lbt: it turned into only desire half a year later after promise 10:51:51 and featurewise I'd like some timeline in form of 2014Q3 or something like that, even if it will change 10:51:59 lbt: desire with a lot of doubt that is 10:52:02 why is this silica thing so important 10:52:13 because of promises 10:52:32 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 a promise doesn't mean it will happen immidiately 10:52:40 and being able to contribute features and fixes 10:52:48 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 netzvieh: just like the BB10 "plane arrival display" for developers, but this time for upcoming features (both devs and users) 10:52:56 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 Guest62403: well if "soon" is already more than year, you can have concern regarding promise 10:53:02 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 fk_lx: SK_work... and with that misunderstanding you see why silence becomes attractive :/ 10:53:12 SK_work: got a link for that? 10:53:13 SK_work: those are nice 10:53:14 was that rotation fix from coderus merged BTW ? 10:53:16 Guest62403: a promise makes it happen at some point 10:53:51 Stskeeps: bijjal: is it fair to say we can never 'promise' anything until it's released ? 10:53:55 lbt: care to talk about why C++ is not ready to be open yet? 10:54:09 netzvieh: http://img.blackberryos.com/bbos-images/2013/blackberry-10-3-roadmap-von.jpg 10:54:18 lbt: be open 10:54:25 lbt: about that 10:54:37 lbt: it is right in most cases that we cannot promise until we have the release mostly ready 10:54:53 Stskeeps: +1 10:54:54 yeah "never" is a bit absolute 10:55:00 bijjal: that why you shouldn't give promises on important events if you are unsure of something 10:55:02 also would be nice to build Silica on the desktop for running apps during development 10:55:03 but that shouldnt stop us from sharing our intention 10:55:03 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 SK_work: well that's nice :) I wouldn't mind if it was less specific though 10:55:11 M4rtinK: +1 10:55:28 netzvieh: yep, but something like this could be nice 10:55:41 Guest62403: well for me it is a deal, people got attracted by open platform and promises 10:55:51 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 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 M4rtinK: emulator has silica already built for x86 (might be usable on the desktop) 10:56:05 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 AFAIK developers would really like this from what I've herd so far 10:56:26 SK_work: you mean update the first info mail on planned content with things that got left out? 10:56:26 Stskeeps: #info that? :) 10:56:36 bijjal: yep 10:57:22 veskuh: well I think community deserves a clear statement on that topic, maybe even an appology 10:57:35 SK_work: should be doable too IMO. Stskeeps, Aard, veskuh, opinions? 10:57:36 veskuh: FOSDEM would be preferably the best place for that 10:57:47 #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 bijjal: ? 10:58:01 bijjal: yeah, should be possible to extract 10:58:22 also an upstream Silica repo would be nice 10:58:22 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 even if only for the QML part for the time being 10:59:03 M4rtinK: regarding coderus' it fits in the same kind of thing related to QML patching, that was discussed 10:59:05 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 another thing that would be nice to know 10:59:34 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 Aard: yes, we could attempt it in the least.. a bit more work, but for the better 11:00:21 Aard: bijjal +1 11:00:24 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 explain to the community that if the whole announcement thing backslashes it will stop 11:01:01 fk_lx: the python stuff is, afaik, all happening in mer 11:01:09 Guest62403: don't think that threatening people is good ... 11:01:14 I am also interested in Python support timeline 11:01:21 there is some expectation management to be done 11:01:23 SK_work: +1 11:01:25 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 but I think this can be done 11:01:28 intake. We're still working on solving the issue." 11:01:29 It's a fair explanation i think. 11:01:34 so that's a bigger blocker currently 11:01:59 4 minutes left of topic 11:02:00 just change 'promised' to 'feature is in work, eta sept 2014'. 11:02:09 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 veskuh: but could get you free contributions and would motivate you to open the C++ part :) 11:02:12 SK_work: if the community takes "this is how management works" as a "threat" then we have problems! :D 11:02:17 each iteration 11:02:25 veskuh: win - win :) 11:02:44 M4rtinK, yes, that is true. 11:02:45 features+bugfixes (in open components) - to be completely precise 11:02:47 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 Aard: then explain in RC mail 11:03:20 feature not stable enough, maybe next release etc. 11:03:21 Aard: then it would be useful to give longer term plans, so community could chip in early 11:03:30 on features that haven't even started 11:04:03 SK_work: yes, if something is dropped, it will be reasoned 11:04:19 #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 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 by structuring that email properly (features unstable, not-started, etc) would maximise community's involvement by analysing that email 11:05:16 thanks for a lot of good views, next topic 11:05:25 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 sledges: +1 11:05:42 Aard: +1 11:05:45 #topic Community localization 11:05:57 #info From etherpad: Including community localization contributions (translations, vkb layouts) in the OS. 11:06:09 #info From Jolla side: pvilja1 and pvuorela 11:06:27 pvuorela: pvilja1, do you want to intro anything, or just go for general Q&A? 11:06:55 Stskeeps, i could go through translation tool situation 11:07:00 cool, that'd be helpful 11:07:04 \o/ 11:07:10 #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 #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 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 so, go ahead and shoot. 11:08:54 What about keyboard layouts? Some are missing and we have stuff already in Openrepos. 11:09:10 Are these going to be included in harbour? 11:09:17 #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 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 Any chance of getting the strings out before so the current development on Transifex can be improved? 11:10:42 Guest62403: i wouldn't yet like to declare layout API stable. 11:11:06 pvilja1: how is the best translation string decided (if the translation system is open) 11:11:23 does Jolla decides, or will it be ~fully managed by community ? 11:11:49 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 i guess pootle supports that 11:12:40 SK_work: QA by Jolla means Jolla decides in the end i think, though I'd like a peer review aswell 11:12:56 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 I would say look how other projects, like Fedora for example, do tat 11:13:14 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 pvilja1: right 11:13:25 no problem 11:13:27 sounds good 11:13:54 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 as an idea 11:14:08 so it's easier to batch change API 11:14:32 #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 Guest62403: considering harbour, that would be same for all apps using some unstable API. 11:14:42 currently they are all on a TMP thread, and I know one more (Lithuanian) only as a draft, not published 11:14:42 sounds like a good idea 11:14:50 Stskeeps: maybe we need some "maintainers" for each keyboard 11:15:01 the layouts on Github one 11:15:12 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 Stskeeps: i suppose an option could be having some "extras" type of repository creating a separate layout package. 11:16:01 Stskeeps: those would be a bit second class citizens in the sense that prediction support would be missing. 11:16:42 a bit like gstreamer-good, bad, ugly ? 11:16:42 pvuorela: i understand. The harbour should treat all "apps" in the same way. 11:18:21 pvuorela: could we potentially get to a point where layout API is stable and those available in harbour? 11:18:26