10:00:26 <Stskeeps> #startmeeting SailfishOS, open source, collaboration, 13/May/2014
10:00:26 <Merbot`> Meeting started Tue May 13 10:00:26 2014 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
10:00:26 <Merbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
10:00:26 <Stskeeps> #info Please when adding topics to the piratepad, add your name and a small description of the topic (so we can ask for elaboration), it helps to prepare for meeting
10:00:38 <Stskeeps> #topic Quick introductions (5 minutes), prefix your info with #info
10:00:39 <Stskeeps> #info Carsten Munk, Chief Research Engineer @ Jolla
10:01:07 <locusf> #info Aleksi Suomalainen Community Member
10:01:22 <BasilSemuonov_> #info Basil Semuonov, developer
10:01:38 <stephg> #info Steph Gosling, Community Member
10:01:40 <fk_lx> #info Filip Kłębczyk, blogger about Jolla, maybe still Jolla community, whatever you want to call me
10:02:16 <lpotter> #info Lorn Potter, developer @ Jolla
10:02:31 <Sage-_> #info Marko Saukko, worked with Nemo and Mer sometime ago. Now working for Jolla and contributing to Mer and Nemo when possible.
10:02:40 <amccarthy> #info Aaron McCarthy, developer @ Jolla Location, Connectivity, Qt.
10:02:51 <Nicd-> #info Mikko Ahlroth, software developer at Vincit Oy, developer of SailTime. Going to follow the discussion from the sidelines
10:03:10 <lbt> #info David Greaves - Mer infra and chum. Also Jolla sailor :)
10:03:24 <cybette2> #info Carol Chen, community chief at Jolla
10:03:25 <eleroux> #info Eric Le Roux - Bugzilla & t.j.c admin
10:03:33 <iekku> #info Iekku Pylkk�, head of developer affairs @jolla
10:03:41 <deztructor> #info Denis Zalevskiy, Jolla, middleware etc.
10:04:04 <giucam> #info Giulio Camuffo, developer @ Jolla, qt, wayland, other stuff if needed
10:04:39 <sledges> #info Simonas Leleiva, community member, Jolla sailor
10:04:43 <bijjal> #info Soumya Bijjal, sw program manager @ jolla
10:05:09 <vgrade> #info vgrade, community, adaptations
10:05:27 <Stskeeps> #topic Chum sync (lbt, basil, tbr) - 30 mins
10:05:27 <Stskeeps> #info This is more of a floor discusssion, lbt/Basil/tbr? - can we synchronise on what's been going on with Chum?
10:05:47 <Stskeeps> one too many 's'es there, but :)
10:07:03 <lbt> Well, from my side I haven't progressed it much. Went to Embedded Linux Conference and then been catching up.
10:07:31 <lbt> The next steps for me are to begin to assemble some boss validation steps
10:07:57 <Stskeeps> there's also been some work surrounding OBS upgrade in general?
10:08:06 <Stskeeps> as merproject.org OBS is an ancient version
10:08:14 <lbt> correct
10:08:31 <lbt> that's due to happen in the next few days
10:08:44 <BasilSemuonov_> from my side: openrepos bridge to obs is completed. packages may be imported once builded, and if application is linked to obs, no manual rpm upload is allowed for that app. obs builded apps have own 'badge' that app is FOSS and builded on OBS infra. Warehouse by default can only show 'trusted' and 'obs foss' software, as safe for user. show all other packages can be enabled after warning banner
10:09:03 <Stskeeps> #link http://merproject.org/meetings/mer-meeting/2014/mer-meeting.2014-04-22-15.00.html minutes from last meeting where chum was discussed
10:09:13 <Stskeeps> BasilSemuonov_: cool
10:09:25 <Stskeeps> #info Next steps for lbt: Assemble boss validation steps
10:09:34 <Stskeeps> #info merproject.org OBS upgrade, as it's currently ancient
10:09:59 <Stskeeps> #info Basil has been working on openrepos bridge to OBS: packages may be imported once builded, and if application is linked to obs, no manual rpm upload is allowed for that app. obs builded apps have own 'badge' that app is FOSS and builded on OBS infra. Warehouse by default can only show 'trusted' and 'obs foss' software, as safe for user. show all other packages can be enabled after warning banner
10:10:04 <lbt> I think we need to agree how QA will work too
10:10:05 <BasilSemuonov_> not sure if warehouse sources can be reused (may be only packagekit bindings), since openrepos have own custom api (kind of api)
10:10:13 <Stskeeps> BasilSemuonov_: any problems you've encountered?
10:10:20 <deztructor> lbt: +1
10:10:35 <Stskeeps> lbt: might be good to study how maemo.org extras did it, learn from it's failures?
10:10:38 <lbt> I need explicit rules in order to automate them - but this can include manual testing
10:10:59 <lbt> Stskeeps: yes - and we did some planning for apps4meego too
10:11:01 <BasilSemuonov_> no (-: this is just a way to spread apps builded on obs via openrepos, without manual reupload
10:11:17 <BasilSemuonov_> Stskeeps, ^ this one for you
10:11:33 <Stskeeps> BasilSemuonov_: thanks, let me know if there's anything you'll need a hand with
10:12:07 <BasilSemuonov_> Stskeeps, as lbt said, QA and policies are more important for chum at this point
10:12:10 <deztructor> regarding QA: there are repos in openrepos containing packages replacing Mer ones and resulting in some important apps beeing broken (like ssu). Such repos should not get into chum
10:12:38 <Stskeeps> deztructor: yes, that was discussed in last meeting
10:12:45 <lbt> deztructor: I think we need to break up the QA criteria to explain/measure why not
10:12:52 <Stskeeps> deztructor: see bit about reusing openrepos client
10:12:58 <lbt> ie 'does this replace a core package'
10:13:00 <deztructor> Stskeeps: ok
10:13:03 <deztructor> thanks
10:13:04 <Stskeeps> #link http://wiki.maemo.org/Extras-testing
10:13:11 <Stskeeps> ... apps4meego, hmm
10:13:16 <Stskeeps> i wonder if all that info was on the now dead meego wiki
10:13:40 <Stskeeps> yeah, it seems so - lbt, you had a copy?
10:13:59 <lbt> yes, I think so
10:14:20 <fk_lx> some Meego wiki stuff can be found on Internet Archive
10:14:29 <alterego> If we're going to do this voting and promotion thing, can we do it much better than Maemo did please :)
10:14:31 <Stskeeps> fk_lx: indeed, just found similar
10:14:46 <BasilSemuonov_> openrepos it self will move from 'per publisher repository' which need to be enabled, to 'per application repository', which will contain app itself and all needed deps based on stock firmware release. so enabling one huge repository will not replace(update) all apps you have installed from other sources
10:14:59 <lbt> alterego: yes
10:15:12 <Stskeeps> trying to get at the QA rules
10:15:19 <BasilSemuonov_> (like was with nielkd repository, when wget was pulled, but you havent installed it manually).
10:15:22 <alterego> I remember hating begging people to try and vote my app ..
10:15:28 <BasilSemuonov_> *bash, not wget
10:16:04 <alterego> For apps that may be "unpopular" maybe just have a gestation period of a couple of weeks and it gets auto-published?
10:16:11 <alterego> At least for FOSS apps.
10:16:44 <lbt> alterego: I don't see the need for voting as-such. I would rather we had general testing/reviews
10:16:59 <Stskeeps> #action stskeeps to dig up copy of apps4meego qa material
10:17:30 <alterego> lbt: requires manpower, can we make a digital cryptographic currency and pay people to test for us? :)
10:17:46 <lbt> haha ...I was typing ... : I would also be interested in rewarding diligent testers
10:17:50 <BasilSemuonov_> Stskeeps, app pulled from obs to testing. votes+comment at testing, on 5(or 10) votes, app pulled to stable.
10:18:31 <fk_lx> lbt: voting might end in result, that someone who doesn't like me might on purposes not vote on good apps. Testing should be based on clear and as much non-subjective rules.
10:18:35 <alterego> I guess maybe an initial small group of SWAT testers would be all that's required.
10:18:44 <alterego> A couple of hours of testing random apps a day, voting them up.
10:18:50 <lbt> alterego: I also recall the concept of 'super-tester' where apps which waited too long were boosted
10:18:55 <alterego> Yeah
10:19:11 <alterego> That was useful, but not well utilised, I don't remember them ever helping me for instance ..
10:19:26 <lbt> was that a maemo thing? or apps4meego ?
10:19:26 <Stskeeps> BasilSemuonov_: any way that openrepos client could theoretically pull down a few apps for testing, if you participate in tester program?
10:19:30 <deztructor> there just should not be negative votes (with explanation of reasons, of course)
10:19:37 <Stskeeps> might also be a good way
10:19:39 <alterego> Maemo thing was Maemo Extras
10:19:45 <Stskeeps> "here's a new app, help test it" kind of thing
10:19:56 <alterego> Stskeeps: +1 that would be great.
10:20:18 <alterego> We could have a simple "Sailfish Tester" app that recommends apps for testing when you've got a spare few minutes.
10:20:28 <lbt> +1
10:20:29 <BasilSemuonov_> Stskeeps, access rules can be devided into groups with custom access to certain apps. basis for that is completed
10:20:31 <deztructor> alterego: +1
10:21:18 <dr_gogeta86> sorry for the late
10:21:40 <lbt> alterego: deztructor: Stskeeps: I think one think we need to do is prepare (and justify) the packaging rules
10:21:42 <BasilSemuonov_> vote (app is tested and worked) can be uploaded to openrepos itself, what about push back to obs infra?
10:22:18 <dr_gogeta86> is possible to get piratepad url for this session ?
10:22:23 <alterego> lbt: indeed, that can get messy very quickly :)
10:22:49 <sledges> dr_gogeta86: https://lists.sailfishos.org/pipermail/devel/2014-May/004152.html
10:23:08 <BasilSemuonov_> lbt, isnt that(packaging) handled by obs?
10:23:32 <lbt> BasilSemuonov_: no - OBS builds whatever you give it
10:23:35 <alterego> BasilSemuonov_: he means rules, things like requires, provides, those messy parts that are likely to break things.
10:23:47 <BasilSemuonov_> lbt, 'packaged against target os release'
10:23:57 <deztructor> lbt: some tool additional to rpmlint (does not have plugin?)
10:23:57 <BasilSemuonov_> alterego, ah
10:24:34 <lbt> deztructor: tooling is boss (maybe using rpmlint) ... but we need to state policy
10:24:55 <lbt> eg no Requires == version
10:25:23 <Stskeeps> (10 minutes left)
10:25:41 <BasilSemuonov_> lbt, 'Requires ==' is a good decision if any app targets exact version of sfos?
10:26:18 <lbt> BasilSemuonov_: and when there's an sfos update and the app prevents the lib version from changing? :)
10:26:27 <javispedro> that may be hard to avoid
10:26:48 <javispedro> imagine I publish apps depending on something that is gone on future release
10:26:53 <BasilSemuonov_> all apps should have lower priorities than system packages. on update you should be promted:
10:27:05 <SK_work> hi !
10:27:08 <lbt> actually that brings in the other side - I'd like to see what can be done to tag apps in the rpm db so the resolver can prefer to remove non-system/jolla apps
10:27:12 <lbt> BasilSemuonov_: yes
10:27:13 <BasilSemuonov_> 'update, and this 12 packages will be removed', or 'stay as is'
10:27:15 <javispedro> pkgmgr will also prevent update (at least in current versions)
10:28:05 <BasilSemuonov_> lbt, i.e. core package/system package/optional package
10:28:12 <SK_work> lbt or Stskeeps I was wondering if there is a sort of metapackage in SFOS to check what's the current SFOS version
10:28:37 <deztructor> BasilSemuonov_: +1 for idea to ask user
10:28:40 <lbt> #info It would be nice to support package priorities in rpmdb for resolver decisions. eg: 'update, and this 12 packages will be removed', or 'stay as is'
10:28:40 <SK_work> would be easier than making a dep on another system package ?
10:29:21 <javispedro> I'd really prefer if the pkgmgr could be made "flexible" more than having a strict set of rules for pkg deps
10:29:33 <javispedro> there is the risk that one ends up with harbour-style rules.
10:29:39 <lbt> SK_work: not afaik yet
10:30:05 <BasilSemuonov_> another question is, should chum be able to provide packages which alter system packages (but not core, if there willl be diff between core and system packages)
10:30:20 <deztructor> javispedro: maybe it is better to start with strict rules and then loosening 'em
10:30:22 <BasilSemuonov_> i'm talking about patchmanager for example, lipstick-qt5
10:30:30 <lbt> SK_work: that too may help us. ie if an app is tied to a certain sfos version then maybe that metapkg would be removed and remove all apps depending on it
10:30:39 <lbt> before an os update
10:30:40 <Stskeeps> BasilSemuonov_: in the ideal world we wouldn't have to do tricks like that..
10:30:42 <lbt> Aard: ^^
10:30:56 <SK_work> BasilSemuonov_: IMO too dangerous
10:30:57 <Stskeeps> BasilSemuonov_: ideally we should be able to contribute to system packages and have things improved that way
10:31:21 <SK_work> BasilSemuonov_: even if experience has proven that lipstick-qt5 change didn't break updates not anything
10:31:32 <lbt> BasilSemuonov_: I would say 'yes if QA approves it' but also 'not initially'
10:32:09 <Stskeeps> (3 minutes left)
10:32:19 <Aard> lbt: we've been thinking for a while to use sailfish-version dependency. migt not be required, though, as we seem to be capable of figuring out where the package works based on abi compatibility. it's something we're looking into, but quite complex topic
10:32:34 <sledges> re: re-using src code: could Warehouse for Sailfish politely gradually replace all open repos to OBS ones, and offer apps from there?
10:32:58 <sledges> (i liked the idea of foss badge already etc)
10:33:18 <lbt> Aard: *nod* ... such a thing may provide a more understandable (but blunter) interface for apps
10:33:31 <BasilSemuonov_> sledges, this can be done, since source reporitory url is known
10:33:44 <sledges> and encourage devs to go OBS
10:34:18 <BasilSemuonov_> sledges, the only thing is about deps, all package deps should be at this repository.
10:34:20 <sledges> as warehouse is already popular
10:34:39 <sledges> cum is built against sailfish
10:34:41 <sledges> *chum
10:34:51 <sledges> it can offer flexible hierarchy
10:34:59 <sledges> (add more repository paths to build against)
10:35:01 <sledges> like chum-mw
10:35:08 <sledges> thanks to OBS
10:35:21 <Stskeeps> #topic More closed source discussion (Carsten) - how can the community help - 30 minutes
10:35:31 <Stskeeps> #info There was a bit on unclarity from my last meeting on what hat I was wearing, so I'm repeating it here with a Jolla hat.
10:35:34 <Stskeeps> #info Silica is not open source currently. State is that there's no exception granted (see policy for open source contribution 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:35:39 <Stskeeps> #info This is more of a Q&A discussion, please ask some questions, let's see if we can answer right away, or need to get a better understanding and get back to the question
10:35:46 <BasilSemuonov_> sledges, warehouse cannot guess about such paths, only manually entered, or importing predefind hierarchy
10:36:07 <Stskeeps> there was no description together with the question, so i'm a bit in the blind about what it's about exactly
10:36:07 <sledges> BasilSemuonov_: I'll take a look into warehouse src
10:36:46 <Stskeeps> as closed source is one of those things where it's hard for a community to really help in, in it's own nature
10:37:14 <Stskeeps> as it relies on choices made due to business reasons; or maybe it's closed source 3rd party bits we use, like hardware adaptation, etc
10:37:53 <fk_lx> Stskeeps: it wasn't unclarity, you said you were hat-less (so without any, including Jolla, hat)
10:38:16 <Stskeeps> fk_lx: yep, the word 'unclarity' is wrong, but in practice, i should have stated it was with a hat in that particular sentence
10:38:25 <Stskeeps> so i need a better word than unclarity
10:38:46 <Stskeeps> who was it that proposed the question on the etherpad? if present
10:39:09 <fk_lx> the question is if moderator should wear any hat, otherwise it confuses people
10:39:17 <Stskeeps> :nod:
10:39:19 <Stskeeps> valid concern
10:40:19 <dr_gogeta86> but any way to triage connections problem
10:40:25 <SK_work> so, who should represent Jolla in this part ?
10:40:28 <fk_lx> in my opinion if someone is a moderator, should not take any (hat) statements in discussion, otherwise it's not a neutral moderator
10:40:33 <dr_gogeta86> till now without writing anything
10:40:42 <deztructor> dr_gogeta86: those parts are all open, iirc
10:40:43 <dr_gogeta86> some wifis are unable to use
10:40:45 <SK_work> fk_lx: +1
10:41:04 <dr_gogeta86> i don't say connmann
10:41:13 <dr_gogeta86> i say sailfish os
10:41:24 <dr_gogeta86> i didn't find any reference
10:41:27 <NSA-Rep> What prohibits a moderator from being neutral.
10:41:28 <dr_gogeta86> neither into filesystem
10:41:34 <Stskeeps> fk_lx: i think we'll take cybette as moderator for next time, so i can take on topics where i need to (provided cybette doesn't have some topics), you're right, it does cause some oddity
10:41:39 <SK_work> dr_gogeta86: don't think that this is the best place to discuss here though
10:41:51 <Stskeeps> dr_gogeta86: so, it is partly closed source related
10:42:11 <dr_gogeta86> we aren't talk about the closed part of things
10:42:11 <Stskeeps> dr_gogeta86: it goes into the settings and connection selector, which are not open source
10:42:11 <dr_gogeta86> ?
10:42:32 <fk_lx> Stskeeps: +1 for a moderator that will be only moderator
10:42:42 <Stskeeps> and present the UI configuration, where the implementation for let's say, enterprise wlan isn't implemented in
10:42:48 <Stskeeps> the factual work happens in open source components
10:42:56 <Stskeeps> connectionagent -> connman -> wifi driver, ofono
10:43:17 <Stskeeps> the UI configuration is somewhere where it would help a lot if was somehow pluginable
10:43:45 <lbt> Stskeeps: can any contributions even be accepted due to copyright non-assignment?
10:43:45 <Stskeeps> lpotter: you're awake by chance?
10:43:55 <SK_work> Stskeeps: since the patching issues seems to be addressed, I wanted to go slightly further: some patches (not those changing ui a lot, but those adding more functionnalities) could be interesting, even for Jolla
10:44:11 <Stskeeps> lbt: we're looking into that particular case on how it can be, as stated in the patching session
10:44:14 <SK_work> just an example: vibrating when phone communication is established
10:44:20 <Stskeeps> it just needs some legal clarity
10:44:34 <lbt> (I should maybe ask if there are issues due to copyright and closed license - where it is and isn't relevant - eg smaller patches)
10:44:36 <Stskeeps> one way around it is using SK's patcher
10:44:43 <SK_work> (maybe it's patented though)
10:44:59 <Stskeeps> lbt: IANAL :)
10:45:15 <alterego> Is that an Apple product?
10:45:31 <lbt> Stskeeps: so maybe an action to provide community with guidelines?
10:45:44 <Stskeeps> lbt: yes, i think it was already brought up when the patching stuff was discussed
10:45:47 <lbt> both 'today' and eventually as they change
10:46:08 <Stskeeps> dr_gogeta86: does this explain a bit about how the connectivity part of sailfishos functions/where you'd need to work in?
10:46:51 <lbt> dr_gogeta86: we've recently made some big changes to Mer git and contribution side so that should now be easier too
10:46:56 <deztructor> dr_gogeta86: connman itself and other open components need love to get rid of connectivity issues
10:47:41 <SK_work> deztructor: isn't Tizen helping too for connman ?
10:47:50 <dr_gogeta86> i'm a pretty noob
10:47:56 <Stskeeps> tizen does have some patches, yes
10:48:09 <dr_gogeta86> but i've found 3 areas were sailfish os laks
10:48:14 <dr_gogeta86> *lacks
10:48:30 <dr_gogeta86> Captiveportal open wifis in public areas
10:48:40 <dr_gogeta86> Hidden Network with 802.x
10:48:58 <dr_gogeta86> Some  strange Wpa2
10:49:09 <Stskeeps> dr_gogeta86: we've been working to get a newer connman going that helps a major amount of issues, but, it's not in an update yet
10:49:18 <dr_gogeta86> i know
10:49:34 <Stskeeps> captive also relates to interpreting http 204 stuff i think
10:49:34 <NSA-Rep> Any estimate on the new connman going in Sailfish?
10:49:56 <dr_gogeta86> I wanna contribute fro fields tests
10:50:12 <dr_gogeta86> *for
10:50:23 <dr_gogeta86> i got those crappy things at home
10:50:41 <SK_work> Stskeeps: I'm wondering how can community help in the non-open source part too: it's pretty easy to write patches in the QML files, but it would be better if they could be integrated directly in the next SFOS update
10:50:46 <Stskeeps> SK_work: yeah
10:50:49 <SK_work> I know that there is a need of review and guidelines
10:50:56 <SK_work> maybe some work in this side for Jolla ?
10:51:09 <deztructor> dr_gogeta86: so, again, open components available to be used in developer mode
10:51:24 <SK_work> (and legal, like signing a contract, or licensing patches in a specific license that allow Jolla to use them)
10:51:30 <Stskeeps> SK_work: :nod:
10:51:53 <Stskeeps> NSA-Rep: not in next update, only connman+some fixes, it wasn't stable enough yet
10:51:58 <Stskeeps> rapidily improving though
10:52:38 <NSA-Rep> Next you mean May not June i believe
10:52:51 <Stskeeps> deadlines flow a bit so whatever is coming out next :)
10:53:45 <SK_work> Stskeeps: BTW, do you think that, at some point, QML could be available without the need of patching some libs ?
10:54:00 <NSA-Rep> Ok its just the we wait for a may update in a few days.
10:54:05 <SK_work> I'm thinking about lipstick of course, but also the music player (for example)
10:54:13 <Stskeeps> SK_work: lipstick is the patching you're doing at the moment
10:54:15 <Stskeeps> ?
10:54:20 <SK_work> Stskeeps: yes
10:54:38 <SK_work> this is ok, but thrills you when there is a sys update
10:55:06 <dr_gogeta86> I was too brave to did it whitout disable any
10:55:08 <dr_gogeta86> :-D
10:55:13 <Stskeeps> SK_work: i can't really say that in practice until it has happened, but you might argue (my own personal opinion) what the worth is to embed qml into a binary when it's extractable with ease
10:55:45 <lbt> I thought it loaded faster
10:55:47 <SK_work> Stskeeps: maybe speed
10:56:10 <SK_work> this can be accepted as a reason for homescreen
10:56:12 <w00t> lbt: I think when I benchmarked ages and ages ago it was actually a bit slower, but I didn't look into it much, or the why
10:56:21 <SK_work> less, for a media player
10:56:24 <Stskeeps> (9 minutes left)
10:56:31 <lbt> w00t: ok - good
10:56:42 <SK_work> (especially that media player don't seems to have much love given)
10:56:54 <lbt> w00t: it should be able to load faster :)
10:57:04 <Stskeeps> SK_work: ah, i didn't know media player had embedded qml too
10:57:10 <w00t> lbt: so you'd think :)
10:57:24 <SK_work> Stskeeps: but I think that it's for technical reasons too
10:57:37 <SK_work> (not speed but plugins, it seems ...)
10:58:40 <Stskeeps> when we speak about closed source there's always a group of people of people who're interested in replacing closed components with open ones -- are there anybody here who are looking at alternatives? not necessarily jolla bits
10:59:01 <sledges> how are the Jolla roadmap email side of things? (cc: bijjal )
10:59:23 <SK_work> sledges: +1
10:59:56 <Stskeeps> bijjal's on the other side of the world on bad connection, so if she's not answering and shortly after ping timeout, that's why
11:00:18 <SK_work> Stskeeps: I would say that rebuilding stuff is rather hard, when we already have something built
11:00:20 <bijjal> sledges: we are on it, there will be an email during this week
11:00:25 <sledges> bijjal: \o/
11:00:36 <SK_work> even if I'm checking locusf's progress on #nemomobile :)
11:00:40 <dr_gogeta86> imap idles is implemented ?
11:01:04 <Stskeeps> VDVsx: might know something about it
11:01:12 <SK_work> Stskeeps: it's usually much easier to continue working on something existing (Jolla people understood that ;) )
11:01:45 <Stskeeps> (4 minutes left)
11:02:59 <sledges> #info reply on sailfish-devel: Stskeeps: when we speak about closed source there's always a group of people of people  who're interested in replacing closed components with open ones -- are there  anybody here who are looking at alternatives?
11:03:36 <sledges> #info re: Jolla roadmap publishing: <bijjal> sledges: we are on it, there will be an email during this week
11:03:53 <VDVsx> dr_gogeta86, we need to implement some changes to our accounts first, MW is ready
11:04:07 <Stskeeps> #action organisers for us to have an independent non-hat wearing moderator for each meeting
11:04:08 <dr_gogeta86> ok
11:04:09 <VDVsx> we want to release all changes at once since some redesign is needed
11:04:11 <Stskeeps> (just getting that one along)
11:04:52 <dr_gogeta86> next frontier ... but is a desiderata are sieve filters ... and saifish become most friendly imap mobile client
11:04:57 <dr_gogeta86> :-D
11:05:26 <dr_gogeta86> Stskeeps, personally i like how do you manage
11:05:29 <locusf> SK_work: what progress ;p ?
11:05:33 <Stskeeps> #topic Accepting graphical contributions by community - 25 minutes
11:05:33 <Stskeeps> #info Could somebody explain what this is about?
11:05:39 <SK_work> locusf: :D
11:05:47 <Stskeeps> .. if anybody suggested this topic on the etherpad, please elaborate :)
11:06:16 <Nicd-> maybe you should make it obligatory to provide a description for topics on etherpad so you don't always need to ask around
11:06:18 <SK_work> Sounds a good topic though, but the scope is a bit large
11:06:30 <Stskeeps> Nicd-: yeah, i've done that and remarked in the start now :)
11:06:41 <Stskeeps> don't want to change rules out of the blue, so
11:07:10 <NSA-Rep> Yes. Thje quetsion is a bit about customization. Is there something that can be done from jolla to have graphics contributions by the community. Ie. there are icon themes floating around in TJC and no easy way of installing them
11:07:26 <SK_work> I can also add about ambiences customization
11:07:34 <SK_work> eg: black ambience for instance
11:07:55 <sledges> NSA-Rep: that can be done via openrepos (and eventually - chum)
11:07:58 <sledges> just like kbd layouts
11:08:01 <SK_work> just like system patching, changing theme / ambiences is not that hard, but there is no infrastructure to host them easily
11:08:09 <SK_work> sledges: host would include how to change them
11:08:10 <NSA-Rep> And not only for the app icons. System icons too. The icons on SFOS wasn't Jollas design team finest hour
11:08:23 <Stskeeps> NSA-Rep: hmm, it's a bit of a tough question :) a jolla device/OS has it's own design, but, people still customize their devices -- there's no functionality to really select a new icon theme. Have you considered using SfietKonstantin's patching for such a thing?
11:08:27 <SK_work> it seems you can change the icon theme (just like in harmattan), if the engine is similar
11:08:54 <NSA-Rep> Havent looked into it and i am no coder to be honnest.
11:08:55 <Stskeeps> icon themes are a bit of a headache in case you have to directly 'support' them in a OS, so
11:09:07 <SK_work> Stskeeps: icons are in a specific subfolder of /usr/share/meegotouch (iirc), this sounds like as if the same engine is used from N9
11:09:08 <sledges> SK_work: just provide a new theme under /usr/share/theme/NAME/icons and provide its inherits bits etc
11:09:15 <SK_work> and on N9 you could change theme
11:09:25 <SK_work> sledges: missing the theme switcher
11:09:36 <NSA-Rep> Is something like: install from shop and use uninstall and go back to default possible?
11:09:45 <SK_work> and don't know if there is a hardcoded path or not in Jolla side
11:09:45 <Stskeeps> as in, how do you make sure that all systems keep working after a upgrade, when icon themes are installed
11:09:49 <SK_work> so more pointers welcomed
11:09:57 <sledges> SK_work: switcher is missing yes, but that's for the last bit to think about
11:10:14 <SK_work> sledges: my biggest fear is harcode
11:10:15 <Stskeeps> so that's why it might be difficult to put it in let's say, harbour
11:10:40 <SK_work> Stskeeps: why the system would stop working if you have different icons ?
11:10:47 <Stskeeps> SK_work: think 'missing icon' situation
11:10:47 <sledges> things breaking after update applies to anything we sideload (OR, chum, ;)
11:10:57 <Stskeeps> SK_work: may or may not work
11:11:01 <Stskeeps> or that the icons become confusing
11:11:04 <SK_work> Stskeeps: add fallbacks ?
11:11:12 <BasilSemuonov_> Stskeeps, SK_work they are even not different, they are *additional*
11:11:30 <SK_work> Stskeeps: IMO the user choose the icon theme, if it's confusing for the user, then he/she won't choose it
11:11:41 <Stskeeps> iekku: could you make a note to investigate how we feel about icon themes?
11:11:43 <Stskeeps> in harbour
11:11:55 <Stskeeps> also, as an idea, custom ambiences
11:12:09 <Stskeeps> i presume there's a lot of people who might want to contribute CC-licensed artwork, for example
11:12:12 <SK_work> + technical aspects (switcher / hardcode in paths to search icons / having fallback etc.)
11:12:26 <stephg> Stskeeps: +1
11:12:45 <iekku> #task iekku to investigate how to handle icon themes in harbour + custom ambiances
11:12:59 <lbt> SK_work: I think this kind of stuff could be prototyped out in chum where community can explore what APIs are needed to provide theme support
11:13:05 <Stskeeps> NSA-Rep: are there other artwork areas that could need some thought?
11:13:08 <iekku> so yes, i take that, hopefully having something to share next tuesday
11:13:22 <Stskeeps> speaking of tuesday..
11:13:38 <sledges> #action iekku to investigate how to handle icon themes in harbour + custom ambiances
11:13:44 <SK_work> lbt: true
11:13:45 <iekku> oops :D
11:13:57 <NSA-Rep> i am not a fan of some sailfish ellements (ie the button) but i have no idea what can be done from outside jolla
11:14:00 <SK_work> lbt: (need to know how chum works though)
11:14:03 <iekku> sledges, thanks mate
11:14:12 <lbt> SK_work: mainly so community can tell Jolla "this is what we need"
11:14:15 <SK_work> NSA-Rep: you can patch via PM, and break everything
11:14:18 <SK_work> lbt: +1
11:14:23 <sledges> iekku: cheers :))
11:14:32 <Stskeeps> sound themes?
11:14:32 <Stskeeps> :P
11:14:38 <Stskeeps> (doctor who ambience, anybody..?)
11:14:39 <Stskeeps> ;)
11:14:46 <SK_work> Stskeeps: harder maybe ?
11:14:54 <lbt> special's screaming Jolla ?
11:15:02 <bijjal> Stskeeps: me!
11:15:08 <SK_work> lbt: isn't lpotter 's ?
11:15:11 <NSA-Rep> iekku would it be possibel to share on TJC?
11:15:24 <chriadam|meeting> custom component sets is a cool idea, but unless applications are written with support for run-time varied imports (eg, via the File Selector APIs which were added to QML in 5.3) they can't really be supported in SFOS imo
11:15:24 <SK_work> I would love to have Jolla give us a feedback on "light ambiences": black fonts, white background
11:15:27 <lbt> oops
11:15:53 <SK_work> chriadam|meeting: you think so ? maybe you can Component.create all the components ?
11:15:56 <Stskeeps> SK_work: do you have a screenshot of that not working nicely?
11:16:02 <SK_work> very painful, but why not ?
11:16:07 <Stskeeps> or better yet, a tjc thread. . :P
11:16:09 <iekku> NSA-Rep, not a bad idea at all. i assume it might be better forum than sailfishdevel mailing list
11:16:11 <lpotter> lbt: yes that's my screaming jolla when you drop it :)
11:16:16 <SK_work> Stskeeps: quickly: a lot of icons are white instead of black
11:16:22 <Stskeeps> SK_work: ok
11:16:26 <SK_work> the code is here to support them, but not propoerly written
11:16:33 <lbt> lpotter: :)
11:16:42 <chriadam|meeting> SK_work: not without ugly, difficult-to-maintain code.  Plus we'd lose a lot of a gains we currently get from preloading imports to generate process-sharable compiled typedata.
11:16:56 <SK_work> + the ambience blurring algo is needed
11:17:07 <SK_work> chriadam|meeting: +1
11:17:25 <SK_work> chriadam|meeting: I'm against custom components though
11:17:28 <sledges> Stskeeps: https://www.dropbox.com/s/etdyot2g2un2qov/tardis.png
11:17:41 <SK_work> at best, patch some of them, but a full set of new ones sounds not good
11:17:59 <chriadam|meeting> SK_work: well, either is a recipe for disaster tbh ;-)  but it's a cool idea "in theory"
11:18:29 <SK_work> in theory ...
11:20:37 <javispedro> chriadam|meeting: what is the file selector API you speak? a file selector widget? or sth else -- do you have link?
11:20:49 <NSA-Rep> Regarding design stuff there are quite a few threads in TJC marked with ui ux tags that the Design team can take a look at.
11:21:00 <Stskeeps> #info Regarding design stuff there are quite a few threads in TJC marked with ui ux tags that the Design team can take a look at.
11:21:12 <Stskeeps> #info Light backgrounds: quickly: a lot of icons are white instead of black
11:21:34 <chriadam|meeting> javispedro: http://qt-project.org/doc/qt-5/qqmlfileselector.html but probably best to watch Alan Alpert's DevDays presentation on them
11:21:55 <javispedro> chriadam|meeting: interesting, ty.
11:21:56 <Stskeeps> (9 minutes left)
11:22:04 <NSA-Rep> And we don't know waht the design team thinks about the TJC suggestions. I don't think they have commented on anything
11:22:34 <chriadam|meeting> javispedro: they're super new, and we won't support them for quite some time, IMO, so it's not something which can be meaningfully considered for SFOS in the short term.
11:23:40 <Stskeeps> NSA-Rep: :nod: i'll make a note about that, at least, i know they've been participating before
11:24:28 <Stskeeps> in that regard
11:25:01 <NSA-Rep> The software team seems more active :P
11:25:08 <SK_work> +1
11:25:15 <Stskeeps> we probably have 'free time' ;)
11:25:20 <Stskeeps> designers work really hard
11:25:33 <NSA-Rep> Code compiling :P
11:25:36 <dr_gogeta86> i wanna have a jolla that rocks
11:25:36 <Stskeeps> #info a lot of jolla guys are stuffed inside a room on next time for this meeting, we might have to limit topics/move some to another day
11:25:39 <dr_gogeta86> for summer
11:25:47 <lbt> NSA-Rep: nah - sharpening their crayons :D
11:25:52 <dr_gogeta86> ahahaha
11:25:58 <fk_lx> I wouldn't say all software members are responsive, some of them even ignore and abuse
11:26:13 <Stskeeps> (4 minutes left)
11:26:20 <chriadam|meeting> abuse?  who?
11:26:27 <dr_gogeta86> i think
11:26:27 <chriadam|meeting> that's unacceptable imo
11:26:30 <fk_lx> chriadam|meeting: me
11:26:35 <alterego> lol
11:26:37 <dr_gogeta86> dialer need to be redisigned
11:26:50 <alterego> dr_gogeta86: what's wrong with it? :)
11:26:52 <Stskeeps> i think is a tad off topic for this topic.
11:27:04 <alterego> dr_gogeta86: feel free to send me your thoughts in PM if you want ;)
11:27:07 <dr_gogeta86> ok
11:27:09 <alterego> No promises obviously.
11:27:13 <chriadam|meeting> but responsiveness can vary on TJC - I go through periods where I'm busy enough that I forget to check it for a couple of weeks at a time.  Also, if I'm working on features I tend to check it less than when I'm focusing on bugfixing in a sprint.
11:28:03 <chriadam|meeting> can always ping me on IRC if you see something you think I need to respond to or might have information about, or send an email, of course.
11:28:04 <fk_lx> Stskeeps: it is off-topic, but was comment to previous opinion
11:28:37 <fk_lx> Stskeeps: with which I disagree
11:29:24 <Stskeeps> also, should we open a new etherpad, or reusing the http://piratepad.net/SailfishOSSMeeting-20140429 is perfectly fine for people?
11:29:52 <stephg> Stskeeps: a new one that loses the date?
11:29:56 <Stskeeps> perhaps
11:30:00 <Stskeeps> i'll get cybette to do that ;)
11:30:10 <stephg> the 20140429 confused me for this meeting I must admit
11:30:16 <dr_gogeta86> +1
11:30:25 <Stskeeps> #info Move to non-date etherpad
11:30:29 <Stskeeps> OK, thank you all for coming
11:30:37 <cybette> Stskeeps: ok :P
11:30:57 <Stskeeps> #endmeeting