15:00:10 #startmeeting SailfishOS, open source, collaboration: 10-June @ 15:00 UTC 15:00:10 Meeting started Tue Jun 10 15:00:10 2014 UTC. The chair is cybette. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 15:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:19 #info Welcome to another week of SailfishOS OSS and collaboration meeting 15:00:25 #info Meeting info and agenda: https://lists.sailfishos.org/pipermail/devel/2014-June/004515.html 15:00:31 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! 15:00:37 #topic Brief introductions (5 min), prefix your information with #info 15:00:39 #info netzvieh, Community member 15:00:43 hoi hoi 15:00:47 hi netzvieh :) 15:00:50 #info Artem Marchenko: supporting all dev programs possible and Get-Mitakuuluu-to-app-store! 15:00:56 #info Carol Chen, Community chief at Jolla, hatless chair today 15:01:19 #info Steph Gosling, community 15:01:21 hi ! 15:01:30 #info kimmoli, community guy, usually just fuzzing around 15:01:38 i'm here :D 15:01:42 #info Morpog_PC__ Community member, part time nemo contributor, graphics guy as hobby 15:01:43 coderus: o/ 15:01:44 sorry i'm not too late? :) 15:01:57 #info Lucien XU, SF dev, community, device breaker :D 15:02:02 #info Andrey Kozhevnokov. coderus. 15:02:03 coderus: just in time! intro section 15:02:05 coderus: info time :) 15:02:05 #info Andrea Bernabei, community member, nemomobile UI contributor 15:02:39 #info Jozef Mlich - foursail developer, community member 15:03:03 #icon Andrey Kozhevnikov. Opensource contributor, Mitakuuluu developer. 15:03:16 coderus: icon ? 15:03:17 hello everyone! intro yourself! you can lurk later :) 15:03:18 #info iekku Pylkk�, developer community & developer-care@ sailor @ jolla, mer bugzilla maintainer 15:03:25 SK_work: :D 15:03:27 cybette, <3 15:03:27 I'd have totally forgotten this meeting :O good to have a highlight on #topic :D 15:03:46 #info Andrey Kozhevnikov. OpenSource contributor, Mitakuuluu developer. 15:03:57 netzvieh: will make you chair again next week so you won't forget ;) 15:04:09 #info Petr Rockai, on-off devel, curious onlooker, user 15:04:33 one more minute for self intro! prefix with #info 15:05:17 cybette: sadly I'm working at a customers then (or I'm on my way home with Deutsche Bahn), in both cases no reliable IRC ;) 15:05:27 * artemma thinks that mitakuuluu is real cool app (and Get-Mitakuuluu-to-app-store!), but it will still take a bit of time before #icon coderus :) 15:05:39 #topic API documentation for nemomobile and own Sailfish component (15 min) 15:05:57 #info coderus proposed this topic and would like to discuss ways to communicate with maintainers 15:06:11 coderus: please go ahead 15:06:31 netzvieh: ah that's too bad 15:06:34 Problem: nemomobile and SailfishOS lacks of documentation. API part very poorly documented or doesn't have documentation at all. 15:07:11 While developing i should investigate opensource parts of nemomobile components to figure out how it works. 15:07:21 #info Simonas Leleiva being late 15:07:42 For SailfishOS components every time i need to ping someone from Jolla devs in irc or developers-care mail 15:08:00 Do i need to show any examples of that? 15:08:21 #info Juho Hämäläinen, developing audio/policy etc for jolla, sorry for being late 15:08:29 coderus: if you have, it will be good for reference 15:09:00 sledges, jusa_: I'll remember you next time ;) 15:09:16 :)) 15:09:36 coderus, if I remember correctly we had the documentation discussion twice already, and Aard said that what they can do is provide the autodoc that they're using in Jolla 15:09:48 Currently i'm having problems with Qt and QML GStreamer components for video recording. Have some success contacting Andrew den Exter via developer-care email. 15:09:58 Controls screenshots Linking to Qt docs is what I am lacking most often 15:10:03 faenil: its little different thing 15:10:11 i'll continue and you'll understand 15:10:26 faenil: I think coderus is expanding on the topic more specifically about the communications aspect 15:10:29 coderus: yes please do 15:11:02 ah I remember now, you proposed the weekly hour for API support, or something like that 15:11:05 I like that :p 15:11:21 Jolla using own CameraExtensions QML component for managing gstreamer options and presets, its available for developers, but not documented. I can't get available resolutions and options, and so on. 15:12:05 This part using QtMultimedia and little expanding it with gst presets features. And it can't be made with autodoc or so. 15:12:07 coderus: (I remember that one from IRC :-) 15:12:53 * artemma remembers similar pains when exploring nemo permissions. When tried to grab volume keys controls.. I just dropped it, because couldn't find info and experiments were taking too much 15:13:04 And now about contacting maintainers. 15:13:19 and I agree that figuring out sailfish components is a pain in the backside 15:13:36 artemma: Sailfish.Media afaik have MediaKeys component, and i successfully used it. 15:14:10 coderus: I wanted to grab control system-wide, not when app is running. But even this MediaKeys is news to me 15:14:31 erm, better discuss that later guys and continue :D 15:14:46 artemma: it's working system-wide while app is running. not only foreground. 15:14:55 artemma: ask me it after meeting please, i'll explain you 15:14:55 let's remain on topic please 15:15:16 As i understand developer-care is correct way for contacting maintainers, but you can also help developers with listing maintainers names and related products. 15:15:22 (I couldn't find any docs when I was trying to get communi's landscape working AFAIR) 15:15:33 I will note I have opened a TJC question about using volume buttons from QML 15:15:42 As for Sailfish controls, I use sailfish help A LOT. Three things trouble in the order of priority: 1) lack of screenshots; 2) no linking to external docs (particularly Qt controls Silica inherits from); 3) many examples are just obsolete and don't work without corrections 15:15:45 quite a while ago 15:15:46 And also you can start a company for opensource parts about creating proper community documentation. 15:15:52 no reaction so far 15:17:12 artemma: agree. some (just some) opensource components have good docs compiled into qch, and it should be available in qtc after installing package-docs package or so in Sailfish SDK center 15:17:19 * artemma would actually contribute something [small] to Silica control docs if there was a way to contribute 15:17:20 iekku: do you want to comment on this from developer care point of view? 15:17:31 coderus: how was contacting emails from the source files? 15:17:54 or something for Jolla to consider and get back in next meetings 15:17:59 3 min 15:18:00 sledges: actually jolla devs don't want to contact privately, if i send them email. only via developer-care 15:18:21 want/have time ;) 15:18:25 coderus: I'd prefer online docs over in-SDK docs 15:18:41 sledges: thats actually problem. 15:18:43 mornfall: +1 15:19:01 i will share all my sucess on sailfisdev blog. 15:19:19 mornfall: SDK docs are pretty much identical to SDK ones. I use mostly online ones, but then QtC ones too sometimes 15:19:26 much easier for me to develop on the phone than in the SDK behemoth, so anything SDK-only is out of my reach by default 15:19:38 hmmm 15:19:40 also, out of google's reach 15:19:45 coderus: do you have a proposal how things can be improved 15:19:51 dumping everything you have on the web would be a good start, IMHO :) 15:20:02 communications wise. we are not talking about documentation here 15:20:06 cybette: we have great community at the moment. 15:20:08 so basically, next to "not enough docs" it's "devs need more time to answer our questions" ? 15:20:15 well I for example don't use SDK at all 15:20:27 i usually check who to contact, and use bit wider scale, so first one who is available ie. has enough time responds 15:20:33 netzvieh, well, maybe they need time at all to answer stuff 15:20:46 cybette: just create some page with components lack of documentatoin and we'll find volunteers 15:20:46 so in that sense developer-care is the best way 15:20:54 it's not just about time, it's also about where/when to ask the questions. Asking on TJC and hoping for a response... IRC works way better 15:20:58 some questions needs answers from several areas 15:21:10 maybe have a special day in the week where all jolla devs try to spend one hour answering questions? 15:21:11 iekku: roundtrips are expensive 15:21:20 #info Jolla will consider if there is more efficient way to contact maintainers and devs, in the meantime developer-care is the best way 15:21:22 irc logs != documentation :) 15:21:30 :D 15:21:33 cybette: anf after storing everything in one place Jolla can improve documentation online and for next SDK release also 15:21:42 Maybe a forum (or same mailing list) with somebody to care that questions/topics actually get answered or dropped consciously? 15:21:43 during weekend it's good to ping me at irc 15:22:11 coderus: +1 on let community participate on docs at a central place 15:22:12 you know, to cope with the situations when the relevant person just doesn't visit forum often :) 15:22:14 ok times up. let's move on. I foresee we'll revisit this topic soon 15:22:19 wasn't this one of the reasons tjc was created? I think that if devs pay attention to tjc it will work 15:22:23 #topic Accepting community opensource applications which cannot pass Harbour (15 min) 15:22:27 (what about an old-fashioned wiki? seems to work for KDE folks?) 15:22:30 #info from coderus: "accepting community opensource applications which cannot pass Harbour validator, but full opensource projects." 15:22:33 cybette: artemma: probably creating sdk-request tag for TJC if devs will look at this every time, it can help 15:22:36 shall there be some agreed tag(s) on tjc? 15:22:38 #info "Allowing Jolla/Harbour QA to build, test, and release applications with own channels and keep maintainer information" 15:23:05 Continuing last meeting topic. 15:23:13 meegobit, tjc is not dev related i think 15:23:36 letting dev comment on doc ? 15:23:41 Morpog_PC__: tjc is a mess :-) (that's probably topic #4 though :) 15:23:42 Someone from Jolla wrote about possibility of testing and publishing full opensource applications to Harbour. 15:23:48 #info work ongoing to get beta-channel at Store, no ETA yet. Harbour QA will provide light quality check 15:24:03 coderus: was in last weeks meeting iirc 15:24:11 We are now in new topic. Please respect the allocated times 15:24:59 i assume we don't have server side sailors here now, they might be bit busy ;) 15:25:02 Mitakuuluu as example, it have really a lot of restricted qml and Qt imports, but it full opensource project, and users want to see it in Harbour 15:25:06 iekku: how much of Harbour QA is automated? any chance of service for the automated part? 15:25:52 mornfall, some parts are and i assume ones we have plans ready we can opensource scripts (or at least some of those) 15:25:55 another example is foursail. It is using just QtPositioning. And it is fully open sourced.. 15:26:07 mornfall, and we are automating more all the time 15:26:09 it also full opensource project, i wish Jolla can help with minimizing/allowing some unwanted apis used by applications and/or check sources and build+publish (OBS?) it internally, and developer can only push commits. 15:26:24 isn't the risk of breaking during next update here with non-supported APIs ? 15:26:38 * artemma doesn't mind special service for particularly important and trusted apps such as Mitakuuluu and fourSail, but letting just anybody drop code with restricted API use to app store even if it's called beta channel.. 15:26:45 SK_work, that's the reason why we can't allow those now to Store 15:26:45 xmlich02: for QtPositioning i know it really unstable right now 15:27:01 the very same thing with modRana 15:27:08 how easy / hard is to deploy channels in store ? 15:27:15 so we need to find a proper way to handle apps using unstable APIs 15:27:21 a la maemo extras ? 15:27:34 chum repos? 15:27:41 SK_work: it can be probably resolved with api versions categories in Store, discussed at last meeting 15:27:47 coderus: actully I have a import error handler for QtPoisitioning 15:27:52 yep 15:28:09 SK_work, it might not be about how hard it is, but when we can do it. 15:28:09 iekku: one way would be to publish updates to developers ahead of time, so the store could update the apps that need to be updated along with the system update 15:28:20 there are different not allowed things: it is one thing to use unstable API, it's another thing to deploy to /usr/bin. I am in favor of some checks still 15:28:20 so modRana will still run if it fails, just without positioning 15:28:27 iekku: might be impractical QA-wise 15:28:41 coderus: what are you doing with an installed app, that won't work after a system update? warn the user? deinstall it? block update? 15:29:01 also developer can upgrade own phone os verions one week before public release to test and improve applications for upcoming release :) 15:29:21 I'll note it has been 6+ months of no GPS apps in store already 15:29:26 Apple way is exactly that to provide beta versions of OS to developers ahead of time to get ready for changes. And then stable or not stable doesn't matter much anymore - it's dev's headache to get ready 15:29:41 netzvieh: system banner "Some applications will be blocked during software update: [list]" 15:29:57 coderus: aah +1 15:29:59 *was | was blocked 15:30:07 iekku: but really, at this point it seems unavoidable to deal with the backward-incompatibility issue 15:30:10 snd also no Python apps, no SDL apps, no contact integration, no volume butons... 15:30:13 artemma: but if an update breaks apps, it would be Jollas fault in the consumer's eyes 15:30:27 at least partly 15:30:28 if it's only about unstable API, harbour can maybe even automagically send notes to all apps devs/users affected 15:30:36 netzvieh, for common user yes 15:30:38 iekku: what Harbour does now is bury its head in the sand... :| 15:30:39 netzvieh: it should be done and available only after enabling beta-channel of course 15:30:39 M4rtinK_jolla_, +1, time's running... 15:30:42 netzvieh: depends on the wording: these applications are not compatible with new version of SFOS 15:30:50 netzvieh: of course not. Look at apple: they just pull back apps that don't work anymore 15:30:57 netzvieh: and consumer should accept and understand beta-channel rules before 15:31:04 so yes, I agree with coderus and others here :-) let apps break on updates if need be 15:31:10 * Sage_ ponders what is the topic atm. 15:31:20 Sage_, :D 15:31:30 I'm prepared to fix any breakage that shows up 15:31:36 Sage_: publishing apps that don't meet Harbour reqs 15:31:37 Sage_: we want more beta apps in Harbour, thats it 15:31:44 * Sage_ points to #topic cmd for the meetbot 15:31:45 Sage_: accepting community opensource applications which cannot pass Harbour validator, but full opensource projects. 15:31:50 coderus, remove "more" ;) 15:32:01 also, remove beta :-P 15:32:03 well, that is the normal workflow in Linyx distros anyway 15:32:13 (sorry guys, i was stuck in a sales meeting for a vacuum cleaner) 15:32:14 iekku: s/more/to have 15:32:15 coderus: you're expecting sane customers ... I'm not that long in the IT business, but I've seen enough to not expect common sense in probably 20% of users 15:32:15 and come on, there are how many apps in the store? 200? Testers can even manually click through them all on SFOS update and pull anything even slightly suspicious 15:32:20 is meetbot not working?? 15:32:20 we sort of don't really have that many compelling apps in the store do we? 15:32:21 ah, not opped bot :) 15:32:43 artemma, +1 15:32:52 netzvieh: its not a big deal if someone won't enable beta channel in Harbour settings 15:33:00 mornfall, we need to somehow show to customer that application is using unstable API and we can't quarantee ot's working properly (now or after update) 15:33:16 #topic Accepting community opensource applications which cannot pass Harbour (7 min left) 15:33:18 * artemma believes in the current app store situation, priority should really be hard on Get-Mitakuuluu-to-app-store! compared to some customers disappointed that coderus failed to upgrade to new OS update on day 1 15:33:30 iekku: marking it beta is probably good enough, isn't it? 15:33:51 iekku: just additional settings for Stope applications 15:34:02 mornfall, that's why we are planning Beta channel 15:34:04 Store* 15:34:10 and planning the QA for it too 15:34:12 * artemma is using mitakuuluu as example. Other good apps such as foursail should get there too 15:34:22 iekku: you have to agree that the average quality of android apps in harbour is appalling anyway, even half-broken native apps are probably going to be more valuable... 15:34:26 artemma, that's also our will 15:34:31 iekku: exactly. jsut enabling Beta channel, long EULA text, accept/decline. 15:34:38 iekku, though will beta channel be available before the API versioning stuff is in place? 15:34:46 I think if the target is published a few days before update, everything will be fixed in time 15:34:46 because otherwise, we need a faster option 15:34:50 * artemma agrees that beta channel is better than nothing 15:34:54 faenil: it shouldnt 15:35:04 faenil, i don't believe. but as i said i don't have eta atm 15:35:08 for active developers of course 15:35:31 I think this topic is also better served with more sailors working on store/harbour participating. 15:35:33 Can you have at least an idea on what's going to change a couple of weeks in advance? 15:35:33 active and trusted ones 15:35:37 as well as syncing with the progress of chum 15:35:59 developers could read a dev blog and notice the relevant change is coming and be ready to when it actually comes 15:36:09 so to summarize: beta opt-in inside store with warning about os updates and auto blocking of beta apps after os update. Developers in beta channel should be able to join beta testing of SF OS next version to prepare an apps update. 15:36:16 just follow Android and Apple practice there - they are not that bad 15:36:31 artemma: well the iteration planning mail could have a dev section, if there are planned api changes 15:36:31 and tried with time 15:36:33 Morpog_PC__: thanks 15:36:35 artemma, i haven been thinking how to get good enough "early warning" system for developers 15:36:38 I understand the current rules 15:36:43 artemma, and get it automated :P 15:36:58 iekku: it's called "dump your OS on github" :-) 15:37:07 mornfall, :D 15:37:08 but at the same time the current situation is slowly moving before repair 15:37:14 iekku: aren't API changes discussed in the iteration planning meetings? 15:37:14 iekku: new mailing list? 15:37:23 iekku: iOS and Android and facebook devs just follow a dev announcement channel. Whatever you mark ads official will work, be it blog or mailing list 15:37:33 coderus, i think sailfish os could be suitable 15:37:37 linux for example have good mailing lists for summarize changes for upcoming releases 15:37:41 * artemma personally is in favor or a blog with automated mail subscription for those willing 15:37:41 iekku: (a m/l with commit notifications would work just as well, and won't work for the same reasons...) 15:37:44 #info summary of proposal: beta opt-in inside store with warning about os updates and auto blocking of beta apps after os update. Developers in beta channel should be able to join beta testing of SF OS next version to prepare an apps update 15:37:49 coderus, at least if we don't get individual warning system 15:38:12 blog with tree-like comment system is easier for clarification questions 15:38:18 api or abi breakages could also be discussed in community meetings 15:38:27 iekku: this new list for registered developers only. you can publish some details to public mailing list of course. 15:38:44 coderus, ah, true. makes sense 15:39:00 2 min 15:39:14 just general info to mail mailing list and all internal changes and TODO to new mailing list 15:39:33 #summarize: beta opt-in inside store with warning about os updates and auto blocking of beta apps after os update. Developers in beta channel should be able to join beta testing of SF OS next version to prepare an apps update. 15:39:37 why not to have the list public? It will be out of interest for most people, so what 15:39:40 coderus: with NDA for each registered dev? 15:39:41 #info early warning system about API changes could be a mailing list for registered developers only 15:40:03 #summarize: beta opt-in inside store with warning about os updates and auto blocking of beta apps after os update. Developers in beta channel should be able to join beta testing of SF OS next version to prepare an apps update. Morpog_PC__ good enough? 15:40:08 NDAs suck 15:40:10 don't :-) 15:40:10 netzvieh: no no, for foss only 15:40:11 artemma: +1, I don't see any reason not to have it public 15:40:18 #info early warning system about API changes could be sent to sailfish os devel mailing list 15:40:30 coderus, yep 15:40:46 coderus: if you have a closed list, you have to have NDAs, else you can have it public ... 15:40:54 artemma: you shouldnt be restricted from list, just new list for weekly details with a lot of coding stuff not for everyone 15:40:57 #action iekku to talk with service sailors about this and hopefully get some ETA soon 15:41:10 iekku: good proposals 15:41:11 netzvieh: closed i dont mean restricted, sorry 15:41:20 ok time is up for this topic 15:41:28 just for developers publishing in beta-channel 15:41:36 #topic More advanced "Developer mode" or "3rd party sources" features (15 min) 15:41:40 #info from coderus: "Enabling UI for managing packages, displaying all package information, repositories, showing update notifications for 3rd party repositories." 15:41:45 #info "Functionality probably maintained by community, can depends on (2) if so, provide full source code for Jolla for review and building as part of OS mode tools." 15:41:49 #info "Discussing main points of future development. Jolla can introduce peoples, who can help with API side and other important information." 15:41:57 and again continuing last meeting topic. 15:42:27 Does Jolla interested in adding more functions like packages control center and ssu management in developer mode tools? 15:42:28 installing zypper by default would be a good low-effort start, wouldn't it? :-) 15:43:08 currently we're talking about GUI available under developer mode page after enabling developer mode 15:43:37 at least packages management is very urgent part, and it should be added to sfos 15:43:44 coderus: I think that has a pretty limited audience? 15:43:59 what is with that zypper? i dont get it, for me pkcon is enough. (or is it just me) 15:44:08 mornfall: you think a little amount of peoples used it in harmattan? 15:44:13 kimmoli_sailing: proper searching etc 15:44:45 netzvieh: dont take windows road 15:45:14 package is package and users should be able to read installed package information. Everything from rpm-info should be available 15:45:19 coderus: no idea... I only had N900 and it was a huge, extremely slow mess :-) 15:45:31 coderus: (package management GUIs, that is) 15:46:04 Hildon Application Manager isnt the fastest thing on earth :) 15:46:12 coderus: well I never said anything against that? just that e.g. zypper allows for proper searching and that's one of the reasons it's superior to pkcon in my eyes ;) 15:46:35 also zypper can do dup --from=3RD-PTY-REPO 15:46:58 netzvieh: sorry wrong highlight, mention to mornfall 15:47:09 I'd still like to have some GUI for ssu/pkcon or zypper 15:47:18 please dont steal topic :D 15:47:22 * artemma thinks if GUI front-end is wanted, then somebody will have to do it. We only need a promise from Jolla to let it be included in the harbour beta channel or whatever like that (assuming they find the app okay) 15:47:46 coderus: what do you imagine would be the main difference between warehouse and the proposed GUI? 15:47:49 * artemma doesn't think Jolla is likely to create such a front-end on its own 15:47:56 I think managing and querying are two separate things, don't disagree with artemma about a UI for query but the management is another thing entirely 15:48:01 mornfall, I guess automatically updates 15:48:02 and I'm against management in the UI personally 15:48:15 Morpog_PC__: as in not doing those? 15:48:22 mornfall: it should be part of system at firts, nobody will install such software from 3rd party sources 15:48:22 Morpog_PC__: or as having a cronjob for them? 15:48:42 without having to open a 3rd party app 15:48:47 aka warehouse 15:48:50 coderus: if nobody will install it as 3rd party, maybe it's not needed after all? 15:48:54 Sailfish should have this GUI built into system settings pages 15:48:57 (also for querying don't see what harbour rules would be broken as is currently) 15:49:07 Isn't it more about permission dichotomy: If users shall be allowed to mess with the device, then they should be able to do it with a GUI app if anybody is eager to build one 15:49:18 artemma: of course no 15:49:25 only user packages should be visible there 15:49:32 applications only 15:49:34 what's a 'user package' 15:49:37 no libs 15:49:53 * artemma still doesn't get the problem, sorry. You can have it all in command line already, can't you? So just build GUI front end for it and that's it 15:49:54 sounds like jolla store for non-harbour channels to me 15:50:06 no libs, apps with desktop launcher 15:50:13 mornfall: not store 15:50:24 you understand topic wrong :) 15:50:25 coderus: disagree, in patchmanager, ausmt / patchmanager daemon are installed 15:50:26 artemma, coderus wants the GUI to be included in Jollas settings UI 15:50:31 can be done by any developer for publishing in openrepos and maybe future beta-alpha channels 15:50:36 they don't have desktop file but might be interesting to display them 15:50:44 coderus: if it only manages GUI apps, it's the same as jolla store ... just with a different channel? 15:50:48 SK_work: its dependencies, and it should be cleaned after removing head package 15:50:52 * got lost 15:50:56 Jolla's Settings UI is extensible, you just need to write/register a proper plugin me thinks 15:51:06 coderus: not really: you can technically install daemon without gui 15:51:11 and use only the daemon 15:51:19 (like allow 3rd party apps to interact with the daemon) 15:51:22 * cybette notices a shortage of Jolla sailors for comments today 15:51:22 (or any daemon) 15:51:34 mornfall: more or less. it should show all applications, also installed manually from rpm and from warehouse and other channels, it doesnt matter 15:51:37 how do you tell a "user" package in sfos? 15:51:56 cybette, i saw that already at info part 15:52:13 SK_work: and you can't remove daemon from that gui then, and it wont be untouched if some other package depends on that. 15:52:17 coderus: you are suggesting warehouse like plugin for settings ? :) 15:52:22 coderus: I suspect there's lack of metadata in those cases though 15:52:24 iekku: yeah, need to include bunny/badger kicks in the invitation emails 15:52:45 Uhm, is the topic about that Jolla should ALLOW such GUI apps, about that Jolla should BUILD such app on its own or about technical help regarding how to do such an app? 15:52:52 mornfall: sorry, what ccases? 15:52:55 3 more min 15:52:59 cybette, yep 15:53:02 coderus: but you might need it to appear and be able to uninstall it etc. 15:53:06 coderus: "also installed manually from rpm and from warehouse and other channels" 15:53:21 phaeron: i suggest to keep packages/repositories management tool build into system as any other linux based os have 15:53:42 SK_work: it will be uninstalled with last package depends on that. 15:53:43 and ssu / pkcon are not enough 15:53:52 ( as in you want ui ) 15:53:55 coderus: no, you are not on debian :( 15:54:20 SK_work: it's easy with zypper rm -u 15:54:25 mornfall: stop kidding me, prm database have all info :) 15:54:40 phaeron: it is, but not for non-experts users 15:55:00 SK_work: it doesnt matter, it shound be only configurated properly. 15:55:04 we are developers here. we are discussing exposing such options to less experienced people 15:55:15 coderus: not really, if you rpm -i something, where are you going to look for updates? 15:55:17 phaeron: no 15:55:22 * artemma still failed to get the actual problem impossible to do already today. Well, it's fine as long as some people did understand the issue and have a discussion 15:55:29 phaeron: it should be visible under developer mode inly 15:55:31 only* 15:55:45 why. developer already knows how to use command line 15:55:48 coderus: should it ? 15:55:49 what will less experienced people benefit from this? only think I can think of is ability to uninstall packages that are in some undefined way "user visible" but have no .desktop file. 15:55:50 I think this discussion should be continued after the meeting and a more concrete proposal made for next meeting or to mailing list 15:55:50 phaeron: +1 15:55:53 and something like "pacman" from arch linux but with a gui? 15:55:56 cybette: +1 15:55:57 coderus: because normal users can install packages too 15:56:03 artemma, getting a GUI into settings, that gets approved by Jolla and integrated into SFOS 15:56:06 phaeron: why commant line< my topic is about GUI :) 15:56:25 thanks everyone, let's move on. I don't think we'll get a conclusion here now. 15:56:30 If you want to hide whatever option from less experienced people, borrow a page from Android book: they require 7 taps (yes, seven taps) on a particular About menu item for showing Developer menu 15:56:35 SK_work: i'll be happy if it doesnt require devmode, but many peoples against :) 15:56:39 #topic Update on community guidelines/moderation (15 min) 15:56:44 coderus: because nobody understands what the advantage of the GUI you propose over the existing CLI is, I think (especially if it's developer-only) 15:56:47 cybette, +1 15:57:01 #info Draft of community guidelines http://piratepad.net/sailfish-community-guidelines 15:57:01 cybette: please let us know if Jolla interested in topic, we can continue later then. 15:57:10 Morpog_PC__: anybody can build such a GUI already today (if wants) and push it to open repos, can't he? 15:57:12 coderus: +1 15:57:16 coderus: I'll ping Jolla 15:57:27 SK_work: your topic on Jolla communications is in a separate topic, instead of grouped with this as I wrote in email 15:57:37 iekku: please take the stage :) 15:57:39 artemma, sure but you can't get it by default in next sfos update, can you? ;) 15:57:45 ok next topic 15:58:01 cybette: perfect 15:58:19 * netzvieh is against 3 strikes personally 15:58:38 * artemma finds it somewhat ironic that he is uploading an app to Apple app store and pushes Android app to release testing while sitting on the #mer-meeting 15:58:38 so, what i have done so far, is just a draft: http://piratepad.net/sailfish-community-guidelines 15:58:43 netzvieh: feel free to comment on the pirate pad 15:59:09 artemma: are you giving me a reason to kick you? ;) 15:59:18 I don't see a problem with what's in that PP 15:59:22 and so far i haven't receved any names for ml moderator candidates 15:59:22 cybette: in chat or pad itself? 15:59:30 iekku: nice, thank you 15:59:32 -1 to not posting of chunks, Email have attachment feature. pastebin have short lifetime. 15:59:52 cybette: if I don't follow guidelines, sure I need to be kicked. Didn't notice it yet, but you are the moderator 15:59:54 netzvieh: please comment here as well, since we're here to discuss this :) 15:59:55 xmlich02: chunks are about IRC 15:59:56 xmlich02, that was for IRC 16:00:00 xmlich02: lifetime? 16:00:13 coderus: pastebins expire 16:00:18 artemma: i'm just kidding. let's focus on the discussion of the topic now 16:00:19 It is not about mailinglist? sorry then .. 16:00:24 * kimmoli_sailing goes to search a charger, ttyl 16:00:27 SK_work, are you here? 16:00:31 iekku: here 16:00:41 SK_work, could you also want to say something? 16:00:48 i'll prefer paste services than attachment, if it isnt complete project 16:01:06 but it's better to use monospace font instead of paste if lines < 100 :) 16:01:18 iekku: SK_work's topic is next, I've separated them 16:01:19 don't know what to say, not very fan of the 3 strikes either 16:01:29 * artemma thinks the guidelines are good. Usual "think fist, do good stuff, don't do bad stuff". But well, maybe there is value in stating that aloud 16:01:30 cybette, ah sorry :D 16:01:37 even though this topic is somewhat of a "response" to the next 16:01:48 i don't know if there's anything else 16:01:50 xmlich02, it'S about maillist and irc, read it again 16:01:51 SK_work: I understand those 3 strikes as a time-local thing... if it's not, I would disagree too 16:02:08 iekku: how about reminding about nominations to developer-care 16:02:10 i engourage people to comment the draft and send out call for ml-moderators tomorrow 16:02:11 just start cleaning mailing list and post only developer questions, and we will better too :) 16:02:16 SK_work: i.e. if you get three warnings within a week, then a ban is appropriate... if you get three warnings over five years, certainly not 16:02:24 Are there particular pain points we are trying to solve? The only enforcing things I see is : technical qs only and 3 warning system 16:02:29 mornfall: +1 16:02:32 iekku: have we received many nominations for moderators? 16:02:35 iekku: ^^ what was the intent behind "3 warnings"? 16:02:38 well, then again -1 to chunks. It is wrong at IRC, but good in mail. 16:02:40 none 16:03:02 xmlich02: but you don't want all dev discussion on the ML? 16:03:07 mornfall, if someone violates guidelines first warning, second and then ban 16:03:18 iekku: I think that "be helpful" might be in 2nd point 16:03:21 iekku: I mean about timespan, what I said to SK_work above 16:03:23 meaning that it's very important 16:03:48 * artemma wouldn't restrict channel for tech things only, but doesn't know how to enforce it for-tech-things-MOSTLY. I think people shall be able to express frustration about forum too, but not in 20 emails in 10 topics 16:03:49 iekku: I don't think it's OK to ban someone right away because they already got 2 warnings a few years ago 16:03:52 at least after what happend on dev mailing list ints a good idea to define that its for technical talk only (and not call it developert talk ;-) ) 16:03:54 I guess 2 strikes + 1 would be better, after 2 strikes 1 weekor month ban, after that if it continues lifetime ban 16:04:00 mornfall, ah, true 16:04:04 for ML I'd propose no html and inline quoting, and banning those +1 mails 16:04:22 as said, please comment the draft :) we need to make it together 16:04:32 netzvieh: +1 16:04:41 * artemma thinks "don't be a jerk" and "stay mostly on tech topic" is better than "tech questions only" 16:04:41 -1 for inline quoting 16:04:45 for long mails it helps 16:04:45 netzvieh, I want different rules for IRC and mailinglist 16:04:46 it's not a community guideline if it's not done together with community 16:05:01 yeah, tech questions only is a bit limiting 16:05:13 there are people chilling out on nemomobile, why not elsewhere ? 16:05:15 and let's not make too many rules 16:05:20 keep it simple 16:05:25 SK_work, shhh :D 16:06:03 xmlich02: there are? read the _bold_ text, would you? 16:06:10 I'm against liftime ban, and I think its not happening often that such hard measures are needed, if its better defined, and if there is an alternative to the developers tech stuff list, it will most likely work without things like permanent ban 16:06:34 * artemma thinks warnings should really be used for abusive things or being a jerk only, not for a newbie inserting long text by mistake or before somebody points him to guidelines 16:06:41 there's no such thing as a lifetime ban on the Internet 16:06:44 Halo2: well, recently, there were some reasons to give a livetime ban so ... 16:06:51 +1 artemma 16:06:56 artemma: indeed 16:07:04 if a newbie comes, you can point it to this guideline though 16:07:08 SK_work: link? 16:07:17 SK_work I think wich an alternative address and some days the problem can also be handled 16:07:32 mailing lists: no private discussions, tech topics, chunks for < 100 lines, pastebin for more. attachment or link to github/etc. required to solve complex problems. 16:07:38 mornfall: fk_lx stuff 16:07:40 artemma +1 :) 16:07:55 3 min. 16:07:55 Halo2: +1 16:08:03 It is very unclean for me. The most of IRC guidelines applies also to mailing list (e.g. don't be a jerk). 16:08:18 are chunks in mailing lists really a problem? 16:08:21 iekku: ^ some cleaning / relayouting ? 16:08:22 SK_work: I have no idea what to think about the fk_lx affair. 16:08:32 xmlich02, well, why should you be a jerk on irc, but not on maillist? 16:08:38 Halo2: they are if it's code IMO, more easy to read on pastebin / github 16:08:46 good to see comments and opinions. i'll add mine to the piratepad after meeting when I put hat back on :P 16:09:02 :) 16:09:08 mornfall: on ML it was spam, I'm not thuinking about other stuff, and it's not the topic 16:09:41 please make sure your commenta are also at the piratepad 16:09:46 comments also 16:09:54 SK_work: "spam" is a subjective thing, and handing out lifetime bans lightly is not a good practice 16:09:58 #info please add your comments to http://piratepad.net/sailfish-community-guidelines 16:10:01 irc is always more relaxed discussions, some short private dialogs are okay, but its not okay if stealing irc for long private discussions if just 2-3 persons involved. 16:10:11 mornfall: yeah, true 16:10:55 alright, thanks iekku for taking this forward. let's now discuss SK_work's topic 16:10:55 * artemma wonders if forum would serve better than mailing list (with subsections for tech and not so tech issues). Ideally a forum with a mailing list(s) interface 16:11:22 #topic Feedback on Jolla communication (10 min) 16:11:27 #info from SK_work "This topic comes to my mind because of recent events in the community, and some / many? community members think that Jolla communication is one of their weaker point." 16:11:47 coderus: +1 16:11:52 artemma: forum = more spam, slood, ooftopic, +1, +1000, thanks, and more flood. 16:12:03 I have feedback :-) ... please have an actual bug tracker 16:12:11 artemma: we've discussed that a bit in an earlier meeting. right now Jolla does not have resources to maintain a forum. we'll focus on improving the current channels of communication 16:12:11 ahoy, we have new topic 16:12:16 oops. forgot no hat. 16:12:29 Feedback on Jolla communication: Jolla communication is often seen as one of their biggest weakness. There were a lot of communication hickups during Jolla launch (Sailfish OS is suddenly dubbed Beta, some international "First ones" got the phone after Finnish second ones etc.). It still continues nowadays, as Jolla advertizes it's Sailfish OS as open (source), while it is clearly not open-source, even if efforts are made to mak 16:12:31 * artemma thinks Jolla comms improved during recent months. Thanks, guys! 16:12:38 To get more information / insight, you need to go on IRC and talk with Jolla engineers, or send Tweets to them. (For example) Stskeeps is usually very helpful, and don't hesitate to discuss a bit more about future plans. For example, ports to other Android will be enabled with the "HADK", but in official media, there is no mention of HADK at all. Another example is about update 7. People on IRC were expecting it to have a little 16:12:45 This leads to two different and conflicting information sources. In one side, official media, that only provides verified information, takes time to apology from failures, and don't provide any information about upcoming features. In the other side, developers that might be a bit too chatty, and talk about unconfirmed open-sourcing plans or upcoming plans. As an example, this blog post from fk_lx http://dontbreakthesails.blogspo 16:12:53 #link http://dontbreakthesails.blogspot.fr/2014/04/sailfish-silica-half-open 16:13:01 I would like to have a discussion about these communication problems, to have feedback from other people of the community, as well as from Jolla, to help improving communication, both to the community, and in general (Jolla image). I see at least two axis of discussion: 1. reaction to problems (mainly apologies), 2. communication about upcoming topics (releases, plans, ideas). 16:13:09 SK_work: you are being cutoff at 512 characters 16:13:10 dont write big rules until there are no spam, offence, jerks and etc. 16:13:22 mornfall: damn 16:13:34 SK_work: (IRC limit) 16:13:41 mornfall: we have two. mer bugzilla and nemo bugzilla. we are working to try to improve their usage. 16:13:42 SK_work: I think the jist comes across tho 16:13:58 http://paste.kde.org/pwblblkim 16:14:01 ^ 16:14:07 phaeron: so which one gets sailfishos bugs? :-) 16:14:09 #link http://paste.kde.org/pwblblkim 16:14:10 SK_work: thanks 16:14:11 i dont saw any spam, jerkings, flood in ML 16:14:13 lazy to repaste 16:14:22 cybette: bad idea to link: this paste expires 16:14:22 :( 16:14:34 SK_work, you should have strike for that. Large chunks of text. 16:14:35 ah 16:14:36 SK_work: broken link 16:14:43 sledges: yep 16:14:53 mornfall: well once we get the process going we can add a third :) 16:15:01 please, let's stay on topic 16:15:02 but there is already too much fragmentation of communication 16:15:23 imho 16:15:23 http://paste.kde.org/piiojrafg 16:15:25 one sec repasting ^ 16:15:36 that works 16:15:48 #link http://paste.kde.org/piiojrafg 16:15:53 (this one works for 1 week) 16:16:04 phaeron: I think tjc is very unsuitable to tracking anything at all. Which only makes matters worse with regards to fragmentation... 16:17:16 SK_work, we are working to get communication better 16:17:18 phaeron: askbot is probably fine for support -- but doubling as a bug tracker, it's really messy 16:17:30 iekku: It can be seen :) 16:17:36 SK_work, and i think first baby steps have been taken :) 16:17:47 but yes, we have still long way to walk 16:17:59 mornfall: I kinda agree. but imho it was the best option for the situation when it was implemented 16:18:02 what bothers me the most is point 1. 16:18:10 * artemma has tech and tech-UI issues sometimes such as Conversations being labeled to another person and has little idea where to report it too. TJC feels quite wrong :/ 16:18:14 point 1. is that Jolla usually takes time to proper communicate failure 16:18:21 phaeron: maybe... but right now, it's sort of a blackhole 16:18:28 phaeron: which doesn't look very good on Jolla 16:18:29 and this leads to a lot of anger. 16:18:50 just take last update. Because of SSL issues, update got delayed, but noone explained except Aard on IRC 16:18:57 if people were aware of this 16:18:59 TJC is great for a wider comms feedback. Some of that feedback canbe pulled to a tech bug tracker 16:19:06 there is no accessible bugtracking or? 16:19:09 (but of course, at the end they were happy to get the update :)) 16:19:26 I would teally appreciate some responce to my RFEs on TJC... 16:19:37 *teally 16:19:52 M4rtinK_jolla_: (that's what I was talking about TJC being a blackhole :) 16:20:09 agree that TJC is really quite bad 16:20:12 if TJC is a bug tracker now, there should be some status-like tags at least. It sorta demotivates a lot to spend time on [somewhat] quality bug reporting and not knowing if anybody relevant even looked at the entry 16:20:15 since it's flooded with issues 16:20:26 artemma: +1 16:20:27 and I think the effort on the part of Jolla to get it together (haha, pun) is disproportionate 16:20:36 IMO TJC won't replace a good old bugzilla 16:20:57 I'm more used to trac 16:21:10 SK_work: bugzilla might be a bit of an overkill, but *some* bugtracker instead of a board-come-voting-platform would be a huge improvement :-) 16:21:11 Halo2_: no accessible bugtracking system 16:21:29 artemma, +1, 16:21:31 I think this is the most important thing if you want to have community development 16:21:32 SK_work: community could also help (someone re-posts on twitter of what Aard said about delay) - united power 16:21:32 * artemma thinks that bug tracking problem is solved nowadays already. Maybe just use a bug tracker (whichever Jolla fancy for)? And TJC could be one source for bug reports to be pulled from (by moderators or whoever technical wants to help) 16:21:34 tjc is good for people telling the workarounds they have found, but as a bug tracker i think it's laking 16:21:40 mornfall: the fact is that there are already 2 bz for mer nemo, and one internal 16:21:44 so why not bz ? 16:22:09 sledges: indeed, but why @JollaHQ don't do this ? 16:22:14 could help even more 16:22:21 we're back to square one, for the bugtracking thing we need Mer and Nemo to be merged, and they're not yet, afaik (cc Stskeeps ) 16:22:33 the gap between official and unofficial com is really disturbing for me 16:22:34 SK_work: ofc, yet every little helps 16:22:44 whichever bugzilla is chosen, there is only one step from using it: an official link from sailfishos.org :) 16:22:45 I agree, it's disturbing indeed 16:22:55 artemma, +1 16:23:20 artemma: +2 16:23:24 SK_work: sure, if BZ works it's fine by me 16:23:24 SK_work, that's something we have to really improve 16:23:56 ok I'm taking notes even though I'm not commenting. 16:23:59 okay, so we have two main subtopics: bugtracking and announcing changes ahead of time, right? 16:24:00 like already said, propably its just me, but i think trac is more usable but please correct me 16:24:09 * SK_work wonders if it's really that hard to get official statements, are the investor needed to have @JollaHQ retweet Aard ? 16:24:10 etc. 16:24:15 thanks and let's continue the subtopics in a future meeting 16:24:17 artemma: +1 16:24:20 SK_work: my only concern was that BZ might be hard to set up, but if there's expertise on board, then no qualms 16:24:26 so can we have a bugzilla? :-) 16:24:30 mornfall: there is mer nemo bz 16:24:35 why not sfos 16:24:38 imho, bugtracking issue already discussed enough. Jolla just has to start/choose and announce bugtracker officially, we can't really do it for Jolla 16:24:45 the fact with a bz is that there is a need of having people triaging 16:24:52 bz without triaging is TJC 16:24:57 (worse than TJC) 16:25:02 #topic Chum repo process and its policies (3 min) 16:25:08 SK_work: sure, but you can at least do triage with BZ, unlike with TJC 16:25:08 #info xmlich02's opinion here: http://piratepad.net/iVW0lrOKXF - please comment directly to the pirate pad 16:25:18 SK_work, I'd be happy to triage bugs 16:25:32 xmlich02-jolla: do you want to add anything to this? 16:25:44 * artemma doesn't mind if official bugtracker is accessible by registered devs only if you are so afraid of too much general public. Public can report to TJC then and devs to pull it to a bugtracker 16:25:46 SK_work: also, you can set up BZ to have votes, and confirm bugs based on votes 16:25:55 SK_work: the votes in TJC are basically useless as far as bugtracking goes 16:26:01 i am still not sure what input is expedted from community 16:26:05 artemma, +1 16:26:17 faenil: me too 16:26:24 artemma, though I'm a bit tired of saying the same things all the times...(which is what you're saying :) ) 16:26:31 it is up to jolla representatives to explain this 16:26:36 hi, we are on new topic. please take a look at xmlich02-jolla 's link http://piratepad.net/iVW0lrOKXF 16:26:46 cybette, oops sorry 16:27:12 ah, sorry, didn't notice. Long intro of topic to channel usually makes a change easy to notice :) 16:27:57 lbt tbr : ping ^ 16:28:08 ok, I guess there's a lot in that link to digest, so take your time after the meeting (that is xmlich02-jolla 's idea as well) 16:28:15 and comment there 16:28:25 let's wrap up 16:28:33 ok, i will pass that onto chum fellows 16:28:37 xmlich02-jolla: only thing to say about this: the pain-points that gives +X karma should also be displayed somewhere else 16:28:38 #topic Next meeting 16:28:39 sledges: thanks! 16:28:40 like in a client 16:28:49 damn :D 16:28:59 ;) 16:29:08 next tuesday, alternate back to 10 UTC? 16:29:37 silence means consent! 16:29:40 wfm 16:29:47 * artemma liked curent time. Understands the need to variate though 16:30:01 artemma: yeah, couple of sailors told me they couldn't make it today because of the time 16:30:04 * Morpog_PC__ reads log if he can't make it 16:30:11 alright let's go with that 16:30:11 * SK_work doesn't like 16:30:16 10UTC is lunch time 16:30:16 #info Next meeting Tues June-17 @ 10:00 UTC, 16:30:17 * Halo2_ also preffers >12 UTC 16:30:21 Morpog_PC__: that's the spirit 16:30:33 SK_work: have it at the same time, I usually do :P 16:30:39 we'll also welcome australians :) 16:30:44 cybette: yeah 16:30:44 sledges: exactly! 16:30:49 I said I don't like this slot 16:30:49 * netzvieh won't be able to participate, so both times are fine :D 16:30:53 because it's not lunch time :) 16:30:58 i hope there's someone else willing to chair 16:31:10 ok thanks everyone. I'll end meeting now. we can continue chatting of course in other channels 16:31:13 #endmeeting