10:00:00 #startmeeting SailfishOS, open source, collaboration: 03-June @ 10:00 UTC 10:00:00 Meeting started Tue Jun 3 10:00:00 2014 UTC. The chair is netzvieh. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 10:00:00 Useful Commands: #action #agreed #help #info #idea #link #topic. 10:00:05 #info Welcome to another week of SailfishOS OSS and collaboration meeting 10:00:05 #info Meeting info and agenda: https://lists.sailfishos.org/pipermail/devel/2014-June/004454.html 10:00:05 I'm the meeting chair for today and will be keeping time and order. Please behave and show mutual respect, and let's have a productive discussion. 10:00:11 #topic Brief introductions (5 min), prefix your information with #info 10:00:18 #info Sebastian Meyer, normally community member, hatless chair today 10:00:47 #info Thomas Ruecker, community member, pushes open source and sometimes chum topics 10:01:02 #info David Greaves - Mer guy and sailor 10:01:03 #info Simonas Leleiva, member and sailor 10:01:15 #info Philippe De Swert, sailor 10:01:22 #info Tommi Keisala, Jolla user and community member 10:01:38 #info Steph Gosling, community 10:02:05 #info Mikko Ahlroth, Jolla user, community member, developer of SailTime 10:02:07 #info Artem Marchenko: Flashlight, Quick Launcher, Night Silence, HelloWorld Pro, etc. Managing iOS and Android apps and mobile sites in day time job. Mostly watching meeting for signs of commercial opportunities hoping to provide a greedy 3rd party dev perspective. 10:02:22 #info Andrey Kozhevnikov, indie developer, opensource contributor 10:02:23 #info Leszek Lesner, community member, jolla user, developer 10:02:47 #info Islam Amer, sailor 10:03:03 #info Val�rio, open source contributor, sailor, mostly lurking today 10:03:11 #info Steve Jayna, Infrastructure @ Jolla 10:03:17 #info Karl Granström, sailor 10:03:33 #info Carol Chen, Community bunny @ Jolla 10:03:46 *g* 10:03:52 #info Iekku Pylkkä, Head of Developer Affairs @ Jolla, visiting doctor and will join meeting as soon as she can 10:03:52 community bunny :D 10:04:09 #info Aaron McCarthy, Position/Location, Connectivity, @ Jolla 10:04:13 #info Marko Saukko, sailor 10:04:16 #info Niels Breet, Store/services/infra @ Jolla 10:04:23 that's an important first step towards a bunny community :) 10:04:29 :D 10:04:33 netzvieh: yeap, i hop around getting people excited about sailfish 10:04:49 artemma: careful, we reproduce like crazy! 10:04:57 hmm bartender economy and bunny community 10:05:05 #topic Harbour and SailfishOS apps compatibility (30 min) 10:05:10 #info Andrea Bernabei, nemomobile contributor with BIG adsl issues 10:05:11 BasilSemuonov: would you like to address the topic? 10:05:15 cybette: are you trying to scare me with the reproduction-related processes? :) 10:05:30 I'm having big issues with my connection *right now* :( 10:05:47 i'm here, just joined 10:05:54 #info Basil Semuonov, developer 10:06:17 netzvieh, basically, all the info and statement are at agenda 10:06:21 artemma: that's for me to know ... 10:06:31 if any info required, I can post here. 10:06:51 BasilSemuonov: I'd like to have a short intro for the minutes and people here 10:06:52 BasilSemuonov: will be nice to summarize as #info 10:06:52 #link line 27 http://piratepad.net/SailfishOSSMeetings (or the one starting with "Harbour & SailfishOS apps compatibil...") 10:06:56 netzvieh: +1 10:07:14 sledges: the piratepad gets overwritten every week 10:07:20 okay, so 10:07:31 whoops thanks :) 10:07:38 #info Statement: Problem with SailfishOS fragmentation is coming. Harbour/Store is not prepared for it. 10:07:49 Description: Now we have 1 device running official SailfishOS - the Jolla Phone. And one major SailfishOS version running on devices. 10:07:49 One day Jolla will release another device. Also, SailfishOS targets to be on android devices, and once SailfishOS will be ported, lots of supported devices will appear. This will cause fragmentation in terms of 'base' specs of devices. To make it clear, i'm not talking about 'this smartphone have an attachable DVD-ROM, and that will have ultra-3D-touch surface'. I'm talking about screen resolution & aspect, CPU & GPU performance, amount of RA 10:07:49 M. Most of devices will have 1gb+ ram, 2+ cores, 16:9/16:10 aspect. 10:07:50 Of course, SailfishOS versions will be different on all devices, since there are some hardware problems, or just timeframe related 'complication' issues during new SailfishOS version release time. 10:07:53 Every-day apps like notes/music player/etc will probably work just fine. Some of 3d enabled games will. But most of gorgeous apps would break the leg here: some should not be runned on square resolultion, some require atleast 2gb of RAM to work as expected and provide neat user experience. Or imaging 'streaming apps', that require LTE support for fast connection. 10:07:58 Also, SailfishOS is rapidly developing. Dont you say that you will always use Qt 5.2 core libs? What if Qt releases 6.x in a month with 'breaking quantum-state-processor support', and it will installed in every 2 of 3 flagship phones. What will happen to all already published apps, if you change some of core packages to new major version? 10:08:06 whops, but seems readable ;) 10:08:44 #info Possible solutions: for SailfishOS itself: Introduce core meta packet(s) with sfos version, which, maybe, depend on target device(or its specs), so apps can depend on it. 10:08:50 #info read full logs for detailed description 10:09:02 #info for Habour: Add target SailfishOS version/device specs for application, while publishing. 10:09:52 And someone added, that action (investigation) should have been taken regarding themes and ambiences publishing, which also can depend on that 10:10:03 theats the next point 10:10:09 #info action 5b from http://www.merproject.org/meetings/mer-meeting/2014/mer-meeting.2014-05-13-10.00.html 'icon themes and custom ambiences in the harbour' 10:10:45 (that was me) 10:11:03 probably, thats all 10:11:03 so two points here: API and UI scaling 10:11:13 #undo 10:11:13 Removing item from minutes: 10:11:13 Android has a concept of minimal and target API versions, i.e. min and max API versions app was tested on. Works fine for them, but sure requires SDK that can switch APIs (e.g. via multiple virtual machines) 10:11:20 sledges, yes, 2 major points 10:11:27 on API: iirc ability to restrict apps per sailfish version in harbour/store were already in the works, could another sailor confirm pls? 10:11:54 UI scaling can't be issue on any way. QA should check if developer used scalable layouts or not 10:11:55 sledges: yes and deployed 10:11:58 sledges: yes we are currently working on that feature on the store side 10:12:00 phaeron: \o/ 10:12:11 Yes, we are working on API based filtering. 10:12:17 sledges: should start coming into effect next release. still needs some work on store frontend side 10:12:39 But the frontend part still needs quite some work 10:12:44 coderus, not all apps should be scalable, i.e. games, whatever sdl uis 10:12:57 In BB10 and Android a developer is required to put a checkmark for which resolutions app supports. Works 10:12:57 #info API based filtering is in the works on store side 10:13:01 BasilSemuonov: let's talk about Silica-based first 10:13:05 stephg: you're next on the agenda, if iekku is here by then, otherwise I'd push it a bit back ;) 10:13:40 no probs 10:13:48 (keep up the) good job guys 10:13:50 iOS goes further by hard limiting the number of resolutions to just few. Can Jolla also fix aspect ratio for a while? 10:14:15 BasilSemuonov: can't SDL applications be scalable? 10:14:15 iOS might be relaxing that these days 10:14:34 check rumors for scalable ipad sinulator 10:15:04 iOS strongly encourages scalable layouts now, yes. It is still just few resolutions in the end with developer telling which layout supports which resolutions 10:15:06 artemma: checkmark for resolutions +1 10:15:27 artemma: I think that's impossible with sailfish for android if stores there in next sfos for android release 10:15:29 #agree 10:15:43 but for Silica all apps should be scalable after launching next Jolla generation and QA should reject / mark for Jolla 1 only 10:15:44 In theory Store currely already supports serving different versions of apps to different devices. Or limiting visibility based on a device. 10:15:51 and seriously: it was always QML motto that it's supposed be super easy to rewrite. Easier than to make universal 10:15:56 We would need to see how this would be handled in Harbour though. 10:16:22 i knew this would quuckly degrade into per-device,per-release packages 10:16:45 BasilSemuonov: When it comes to Qt 6 or a similar library, we should be able to run those side by side. We can in theory run Qt 4 applications on the device right now and there is no reason why we wouldn’t be able to run Qt 6 apps as well. The Qt Platform Abstract (QPA) handles that part. Regarding upgrading what the system libraries use, that will have to come as a step in itself when we know what it looks like :) 10:16:50 what's bad about per-device/release packages? 10:17:10 imaging 20 releases and 50 devices ;) 10:17:12 sletta, that leads to another problem: 10:17:15 artemma: no one will care about anything other than the device they own 10:17:16 *imagine 10:17:42 mapping 3 releases to 10 devices should be fine. One for small phones, one for big tablets 10:18:06 sletta, we have 2 sailfishos versions: ver5.0, and version6.0. in version 6.0 new library added (any kind). and your application use it. 10:18:11 and then again, all qmls can live even within same binary and be selected at runtime 10:18:34 artemma: i would actually prefer that 10:18:36 you get the thing where Android sort of addresses run on every possible device, while e.g. iOS already by product line is very limited and thus more managed 10:18:38 hmm... how about the silica api takes care of big screen devices like tablets (with a specific ui) and small screen devices (like smartphones) 10:18:54 artemma: i dont think we're currently talking about suggestions for developers, just general case 10:18:57 sletta, since harbour validates agains latest sailfishos version, all going to be okay, but app will be non-installable/runnable on sfos ver5.0 10:18:59 so that even when you wrote only for your smartphone it still should look good on a tablet 10:19:13 what if I plug my jolla into 1080p lcd tv? 10:19:27 let's be clear: if Sailfish ever becomes real popular, there will be a need for device specific binaries sometimes. Think games with many megs of device optimized resources 10:19:38 javisail: it should switch to the tablet ui then 10:19:40 that is to be discouraged, but possible 10:19:44 issue (not an issue really) is changing graphics to low - mid - hi res 10:19:53 BasilSemuinov: agreed. This is where minimal API version or separate binaries would be needed. And more flexible store intake 10:20:01 15 minutes left 10:20:21 o/ 10:20:29 iekku: you made it! 10:20:31 sletta, thats what i'm talking about. core version package to depend against. if you depend you know what API is present. 10:21:03 We can already detect what api your app depends on, no need to add it specifically. 10:21:37 :) 10:21:46 xfade_, in future releases sdl support will be added. you can detect linkage 10:22:18 * jake9xx joined as well (sorry, late) so - jake9xx,sailor, blaablaa sdk guy 10:22:28 If it gets added to core library set, sure. 10:22:32 I submit app with sdl support to harbour. it okay with sfos version >= 1.0.6.x and does not work with 1.0.5.x 10:22:54 BasilSemuonov: then you will not see it on 1.0.5.x in Store. 10:23:14 That is what we are currently working on 10:23:37 xfade_, and what about inapp '$APPNAME/libs' folder? 10:23:40 i have really unstable connection, so i might drop (have done it already 2 times) 10:24:12 i can either ship own sdl or use system provided package (sdl is just an example) 10:24:39 BasilSemuonov: There is always static linking if you really want to go that way? 10:25:00 But I would suggest to do one step at a time. 10:25:16 xfade_, i'm talking about fallback solution in case if anything misses 10:25:28 Let's not try to cover the corner cases first. 10:26:15 xfade_, okay. I just proposed the solution as i see it 10:27:06 I suggest we do filtering based on API first. 10:27:30 Then we might want to look at device classes or something like that (eg. screen resolutions) 10:27:37 #info I submit app with sdl support to harbour. it okay with sfos version >= 1.0.6.x and does not work with 1.0.5.x 10:27:47 # BasilSemuonov: then you will not see it on 1.0.5.x in Store. That is what we are currently working on 10:28:00 ähm 10:28:04 #info BasilSemuonov: then you will not see it on 1.0.5.x in Store. That is what we are currently working on 10:28:09 If every single Sailfish release is fixed, why not to limit based on API levels a'la Android? Will make it easier for testing apps on a standard fixed emulator/device image 10:28:23 will the harbour QA take care of checking which sfos is supportes, or is it developers responsibility to inform that ? 10:28:51 :( sorry guys, I really think I won't be able to contribute, it keeps disconnecting :( gah 10:28:57 kimmoli: Harbour 10:29:00 I thought the api version used will define which sailfish os version it is compatible with 10:29:01 kimmoli: will be automatic 10:29:08 ok 10:29:45 is internet broken? lots of reconnects .. 10:29:47 #info harbour automatic checking which sfos version an app supports 10:30:01 5 minutes left 10:30:01 kimmoli, yes it is :) 10:30:11 kimmoli: someone dropped it 10:30:22 maybe i should learn it and fix it :) 10:30:36 * javispedro switched to cable, must be solar flares 10:30:37 kimmoli, it's my adsl which is nuts, as usual :( not an issue in the last 3 days, and since 2mins before the meeting it disconnects every few mins :( 10:30:43 istheinternetbroken.com gives me no 10:30:58 maybe that site is broken 10:31:01 sorry for leading you OT, please continue 10:31:41 how many marcs does it take... 10:31:45 anything else to add? else we can cut it short 10:31:51 cybette, :D 10:31:55 well, if sailors said they are taking some steps, topic seems resolved to me 10:32:00 okay 10:32:02 #topic Update on ambiences and icon themes (10 min) 10:32:02 #info this was an action point for iekku on 2014-05-13 10:32:02 #link http://www.merproject.org/meetings/mer-meeting/2014/mer-meeting.2014-05-13-10.00.html 10:32:02 stephg: want to give us a quick intro and an overview what you tested? 10:32:11 sure 10:32:19 #info study is ongoing 10:32:28 so broadly two things, was wanting an update to the info above 10:33:12 Ambiences basically need to have the ambience template added to the SDK. There is a planned task for that. 10:33:29 and some work on harbour side too 10:33:29 #info Ambiences basically need to have the ambience template added to the SDK. There is a planned task for that. 10:33:34 xfade_, I don't think that's the issue atm? 10:33:39 and proper testing plan 10:33:44 xfade there's enough out there from the TOH dev kit to make them work but there are harbour submission issues 10:33:45 wasn't the issue that ambianced needs root or something? 10:33:45 Harbour just needs another category 10:33:55 ambiences currently cannot by definition pass the current validator 10:34:08 Ambience app store? 10:34:14 stephg, ah right, the validator 10:34:19 Let's get creative artists started 10:34:26 #info ambiences currently cannot by definition pass the current validator 10:34:30 and if they're installed by any other method other than the store the behaviour for the user is different, without validator breaking hacks 10:34:48 fwiw they fail the validator as they don't have a main executable 10:34:51 faenil_: yeah, validator needs a change, but afaik we have a 'better' template ambiences. 10:35:09 and if you install them via kncon etc. you need a %post for ambiencd to pick them up, which is verboten 10:35:19 so it's just about changing the validator and adding a category in store 10:35:22 i know a lot of icon artists want to draw new icons, if Sailfish will allow to select icons themes 10:35:23 seems a 30mins job to me? :) 10:35:29 faenil_: potentially yeah 10:35:51 faenil_, testing plan etc isn't 30 minutes job 10:36:16 Maybe a whole theme template and themes section in the harbour? That may or may not include ambience as a part of a theme 10:36:18 Lot of corner cases to be checked. 10:36:39 For icon themes, I don't know. We don't have that ourselves afaik. 10:36:45 also Ambience wizard for SDK would be really appreciated (tired to make one, but failed on spec file eols in windows, iirc this will be fixed in next sdk version though) 10:36:50 and what about deploying own icons to /usr/share/themes/base/meegotouch/icons ? 10:37:09 coderus: +1 10:37:29 Probably needs work on lipstick to properly support icon themes. 10:37:42 kimmoli: side issue is refreshing cache, it probably did only at system restart 10:37:50 You don't want one theme to overwrite your exisiting icons and no way to go back etc. 10:38:14 xfade_: using appname- prefixes will solve that 10:38:40 #info Probably needs work on lipstick to properly support icon themes. 10:38:48 and adding image://appname/icon appname image provider in runtime will solve that also 10:39:57 in theory we do have proper icon theme support there (minus ability to switch without reboot), we just didn't test it for a very loooong time. 10:39:57 I appreciate there's alot involved with the icon side, but do you have an ETA for harbour-ey ambience stuff? 10:40:00 coderus, +1 10:40:01 2 minutes left 10:40:12 Aard, yes, sailfish is using qtcomponents theme handler isn't it 10:40:15 just revisited maybe 10:40:27 #info in theory we do have proper icon theme support there (minus ability to switch without reboot), we just didn't test it for a very loooong time. 10:40:51 not entirely 10:41:01 we are missing some bits 10:41:18 it's deeply legacy stuff obliviously, just need to renew some api for handling/changing caches 10:42:16 seems there is no eta yet 10:42:18 #topic Software sources and packages management build into system (10 min) 10:42:18 coderus: would you give us an introduction? 10:42:45 xfade_: and for that situation i'll prefer if some theme will change/override my icons by theme cache if icon artist want to replace all icons including 3rd party apps 10:42:46 Might make more chance of bringing it to production if someone would test all the parts available atm and map out the missing parts. 10:43:17 Can we get some proper summary for this discussion subject as a start? I read the etherpad and am none the wiser. 10:43:18 #info Software sources and packages management build into system 10:44:13 as Sailfish OS is FOSS linux based OS it should keep some general mechanisms for managing packages and repositories 10:44:37 As option it can be enabled under Developer mode page after enabling developer mode, but it shouldn't be excluded from OS at all 10:45:05 Main problem is Sailfish OS currently ignoring 3rd party repositories at all. Harbour as main and the only software source with no choose 10:45:45 you should be able to add repositories manually with ssu ar in developer mode? (i may be misunderstanding) 10:45:46 Ubuntu have ppa's and all users can manage is is Software sources settings 10:45:46 if you turn on developer mode there is pkcon and ssu. you can use that to manage packages. 10:45:54 i'm talking about UI side now 10:46:12 yeah it needs an UI for that 10:46:14 so a UI frontend to SSU? 10:46:14 coderus: isn't that what openrepos already does now? 10:46:31 and it's also partly what would be covered by chum 10:46:31 Sailfish should have page to observe all installed user-packages to see versions, descriptions, maintainer details and all rpm-stuff 10:46:46 xfade_: I think coderus wants a generic ui for managing repos 10:46:58 rather sounds like a generic RPM ui 10:47:05 seems so 10:47:10 And Sailfish should update 3rd party repositories and show updates not only for Harbour packages 10:47:11 coderus: so an overview of all installed applications and information about where they were installed from besides the package info itself 10:47:27 something like fremantle HAM or harmattan app manager 10:47:27 startup your N9, navigate to Settings -> Applications. Where is same page in Jolla? 10:47:34 Just look at Harmattan. Its excellent example. 10:47:36 4 minutes left 10:47:41 BasilSemuonov: exactly 10:47:48 * tbr gets cold shivers thinking of HAM and how bad its performance was 10:48:13 tbr: harmattan have slow dpkg/apt-cache system, its not an issue in current topic 10:48:15 tbr, performance depends on implementation 10:48:22 tbr: ham had +1K l10n packages to deal with :p 10:48:22 no sh*t sherlocks 10:48:38 way to pounce on a side comment... 10:48:40 #summary: 10:48:41 * tbr shrugs 10:49:08 coderus, pkcon isn't faster 10:49:09 : 10:49:10 :) 10:49:20 the home screen shows all installed GUI apps 10:49:29 1. UI for managing installed packages. Users should have option to check installed packages versions,informatino about maintainers and all existing information 10:49:40 so it only becomes an issue once you have non-gui things that didn't come from harbour 10:49:41 tbr: but it doesn't show for example how many space they eat 10:49:57 IMO 1) up there isn't 'managing' 10:50:02 coderus, i would add permission check when something like that will be implemented 10:50:17 2 minutes left 10:50:22 I agree with coderus this would also help getting rid of "about" pages in the apps if there is a listing which can show that 10:50:45 2. 3rd party repositories not handled automatically. Packages refresh updating only Harbour repo and not affect 3rd party ones. User will never get upgrade notification 10:50:59 #info summary from coderus: 1. UI for managing installed packages. Users should have option to check installed packages versions,informatino about maintainers and all existing information 10:51:11 #info 2. 3rd party repositories not handled automatically. Packages refresh updating only Harbour repo and not affect 3rd party ones. User will never get upgrade notification 10:51:15 basically a packagekit agent 10:51:31 coderus: not entirely true, the whole repo is refreshed, but harbour uses a different channel to store for update notifications 10:51:41 isn't there a nemo package manager that could be adapted? 10:51:56 It's all generic stuff for any linux-base OS. And Sailfish shouldn't ignore that and exclude that parts from OS. Harbour isnt only way for packages. 10:52:07 coderus: store-client isn't a package manager at all 10:52:09 I see that as a task for a separate full-blown package manager, like a chum client 10:52:15 from the end user perspective this would mean more confusion though, as then there would be a third place to list apps and each place would list different things 10:52:20 Enabling developer mode and 3rd party sources settings should enable these options too 10:52:39 Aard: problem is such app is not allowed in harbour (according to coderus) 10:52:41 giving 2 more minutes stolen from first topic 10:52:45 or last I heard 10:52:46 I partly agree with Aard and would like to add that it sounds like a fairly big amount of work 10:52:53 xfade_: this is certanly my point: Sailfish excluded that functionality fron OS 10:52:56 from* 10:53:22 Jolla Store handling only Harbour apps, it's okay. 10:53:34 Sound to me like a perfect community project which can be adapted whenever it reaches a certain quality? 10:53:44 +1 for xfade_ 10:53:57 After enabling Developer mode Sailfish should handle everything and provide UI for managing ssu repos and user packages with all information about it contents 10:54:10 xfade_: okay, i can take it 10:54:12 #info <+xfade_> Sound to me like a perfect community project which can be adapted whenever it reaches a certain quality? 10:54:15 MSameer: for a fully opensource community-managed app we probably can make an exception. the only problematic part there which I see is elevated privileges for talking to packagekit, it'd just mean additional audit effort on submission to make sure that it does not use anything other elevated 10:54:24 just all API should be reviewed 10:54:24 so times up 10:54:25 or probably have jolla do the binary build for that 10:54:29 #topic Updates on Action points of last meetings (5 min) 10:54:29 this is from the PiratePad chat, right after last meeting. I gathered some points and will just ask everyone if there are updates. 10:54:36 supposedly pkkit simplifies those things, gnome-packagekit is around 20k lines of glib/c code 10:54:42 lbt, tbr, Stskeeps, BasilSemuonov: any updates on chum? (e.g. policies, docs, qa (apps4meego qa material?), OBS upgrade, boss validation steps, openrepos-obs bridge) 10:54:42 pvilja1, pvuorela: any update on community tool for l10n and keyboard layouts? 10:54:42 bijjal: any (negative) feedback on roadmap mail? 10:54:42 Stskeeps: any updates on OSSification? 10:54:42 lbt, Aard: any update on (auto)docs + Silica docs? 10:54:53 #info MSameer: for a fully opensource community-managed app we probably can make an exception. the only problematic part there which I see is elevated privileges for talking to packagekit, it'd just mean additional audit effort on submission to make sure that it does not use anything other elevated 10:54:57 netzvieh: bijjal is on vacation 10:55:11 #info or probably have jolla do the binary build for that 10:55:21 netzvieh: http://autodoc.merproject.org/ 10:55:23 netzvieh: we're doing OBS upgrade of mer OBS today, or rather, lbt is banging his head against the wall and doing it 10:55:27 #info chum progressing slowly on my side. promoted a couple of apps to chum testing for U5 10:55:38 MSameer: okay now i have topics for next meeting :) 10:55:41 so that's DNS for it - and I'm going to co-locate autodoc on the repo meeting 10:55:49 #info autodoc see http://autodoc.merproject.org/ 10:55:51 netzvieh: so far I've only seen positive feedback, but I guess we'll have to see how things develop 10:55:58 coderus: I hope I helped a bit :) 10:56:02 #info netzvieh: we're doing OBS upgrade of mer OBS today, or rather, lbt is banging his head against the wall and doing it 10:56:09 and yes, OBS upgrade is happening (but stalled due to f***ing LVM) 10:56:13 Welcome to autodoc.merproject.org. Press 'a' to continue.... 10:56:21 MSameer: does it work? 10:56:23 #info community translation tool is still pending. IT team might have some time to work on it soon, but no updates at this pont 10:56:28 lbt: no 10:56:30 MSameer: try again 10:56:36 #info @roadmap mail netzvieh: so far I've only seen positive feedback, but I guess we'll have to see how things develop 10:56:44 #info chum still needs more volunteers to drive forward policies, process definition and also adaptation of the open repos client to the chum use case. 10:56:49 lbt: still no 10:56:55 MSameer: hmm - keep trying 10:56:58 lbt.. 10:56:59 :P 10:57:03 *g* 10:57:04 lbt: :P 10:57:15 * MSameer tries with ab 10:57:59 tbr: yeah - we've had some volunteers to start outlining but in the end I think it'll be down to the usual suspects :) 10:58:22 I _might_ have some more time for that in the near future, remains to be seen 10:58:50 tbr: happy to partner up on an ether/piratepad 10:58:54 BasilSemuonov: what was your ideas about openrepos <-> chum communications? 10:59:20 #help We need more volunteers for community repo surroundings 10:59:39 coderus, pulling info/packages from obs for autoupdates 10:59:39 soo 10:59:52 last topic for today 11:00:04 #topic Community guidelines, communication channels and Jollas communication (30 min) 11:00:06 #info continuing from last meeting 11:00:06 #link http://merproject.org/meetings/mer-meeting/2014/mer-meeting.2014-05-27-15.00.html point 3 11:00:06 cybette and iekku: would you like? :) 11:00:23 iekku: are you there? 11:00:27 cybette, if you could 11:00:38 haha ok 11:00:51 my connection may get lost again in any minute, lost on counts already 11:01:19 #info we've discussed about keeping mailing list focused to SailfishOS deeveloper related conversations 11:01:42 #info it will be moderated by Jolla sailors (selected) and communtiy members (no volunteers yet) 11:02:24 #info nominations/volunteers for moderators to be sent to developer-care@jolla.com 11:03:08 we'll also create a pirate pad to draft out mailing list rules, iekku will send that 11:03:23 oh yes please, keep mailing list for developers questions only. i'm not the person giving feedbacks for personal questions, i'm just ignoring it in any cases, but sometimes it very annoying, you know 11:03:54 coderus: +1 11:04:05 coderus: I think most of us are in agreement on this. it's ok to bring some topic up and bring it off the list when appropriate 11:04:15 * lbt thinks that despite all the bad stuff recently we've only just hit the limit of *actionable* (not acceptable) behaviour. We should be cautious about over-reacting with rules 11:04:23 so some moderation to keep that in place 11:04:28 lbt, +1 11:04:35 cybette: any plans for multiple communication channels like suggested on the list? 11:04:35 lbt: +1 11:05:22 netzvieh, currently no 11:05:34 and i have question about way for asking Jolla guys for API-related topics. while developing Mitakuuluu i'm using many undocumented features and have 50/50% success in contacting with Jolla developers. Sometimes they trying to help me, sometimes ignoring my questions. But it generally about nemomobile components. I'm using mails from sourcces copyright information. 11:05:39 netzvieh: at this point we would like to focus on the mailing list, together.jolla.com and irc. We can work on improving these channels (setting up guidelines is a start) but spreading ourselves too thin at this point will not be beneficial 11:05:50 nothing new, but making current ones as working better 11:05:58 iekku: +1 11:06:15 i'm desperatedly tried to start app-development related questions on TJC 11:06:45 kimmoli: i'm trying to follow new question with that tag, but missing many 11:07:02 #info netzvieh: at this point we would like to focus on the mailing list, together.jolla.com and irc. We can work on improving these channels (setting up guidelines is a start) but spreading ourselves too thin at this point will not be beneficial 11:07:22 ml is simply cleaner for dev questions (just think lkml) 11:07:27 and what about #jolladev-meeting weekly? :) 11:07:42 tech bug reporting channel would be nice 11:07:47 we can ask short API questions to jolla developers and get fast answers 11:07:51 coderus: the poor jollans :D 11:07:59 speaking of moderators, we will also like community involvement as irc channel ops and TJC moderators. similarly, nominations/volunteers to developer-care@ 11:08:01 yet even more informal topics could go on tjc 11:08:03 yeah that would be time consuming 11:08:28 coderus: did you get answers for your camera questions? 11:08:30 you can post bugs to TJC, but.. they will be outvoted by gimme-more-stuff entries instantly and sometimes only one person cares to reproduce a specific issue 11:08:35 #info speaking of moderators, we will also like community involvement as irc channel ops and TJC moderators. similarly, nominations/volunteers to developer-care@ 11:08:36 cybette: would you prefer people to nominate others or people apply for themselves? 11:08:53 tbr: both are welcome :) 11:08:54 coderus: i just want to get feedback on my API questions about opensource/community libraries/components. I'm sad when developers ignoring my mails :( 11:09:00 i would also adopt #mer rules to #sailfishos 11:09:03 MSameer: no i didn't 11:09:14 iekku: ^^^ 11:09:21 basicly common sense needed 11:09:36 iekku: the kde ones in that email were good too 11:09:49 someone pointed them out to m 11:09:50 lbt, :nod: 11:09:50 e 11:10:42 when we have a list of names we will have the voting (on piratepad or some suitable tool). 11:10:58 regarding the piratepad for community guidelines, what steps are planned? discussion on a PP can get out of hand quickly? or at first use it just as dropbox for ideas? 11:12:06 netzvieh: I think we will have a draft in place and for review and suggestions. 11:12:15 iekku: maybe can comment more if this is the case ^^ 11:12:28