15:00:16 <cybette> #startmeeting SailfishOS, open source, collaboration: 27-May @ 15:00 UTC
15:00:16 <Merbot`> Meeting started Tue May 27 15:00:16 2014 UTC.  The chair is cybette. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
15:00:16 <Merbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:26 <cybette> #info Welcome to another week of SailfishOS OSS and collaboration meeting
15:00:33 <cybette> #info Meeting info and agenda: https://lists.sailfishos.org/pipermail/devel/2014-May/004409.html
15:00:44 <cybette> 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:51 <cybette> There were couple of last minute additions to the agenda, we will try to cover all of them, so I'll be very strict on the time. The important thing is to get the topics considered and discussions started. We can continue discussing after the meeting and in future meetings if needed.
15:01:00 <cybette> #topic Brief introductions (5 min), prefix your information with #info
15:01:24 <faenil> #info Andrea Bernabei, nemomobile contributor & Jolla user
15:01:24 <cybette> #info Carol Chen, Community chief at Jolla, hatless meeting chair today (would be nice to wear a hat sometimes, hint hint)
15:01:57 <sledges> #info Simonas Leleiva, nemomobile community and jolla sailor
15:02:06 <lbt> #info David Greaves; Mer guy and sailor
15:02:08 <kimmoli> #info Kimmo Lindholm, community member, user, toh-hw developer
15:02:11 <xmlich02> #info Jozef Mlich - foursail developer, CZ&SK community member
15:02:22 <iekku> #info Iekku Pylkk�, Head of Developer Affairs @ Jolla, Nemo & Mer community member
15:02:29 <SK_work> #info Lucien XU, sailfish dev, Jolla user, Nemo contributor (a bit)
15:02:33 <thp> #info Thomas Perl; Sailor and community member
15:02:47 <alterego> Good afternoon
15:02:49 <stephg> #info Steph Gosling, community
15:02:59 <stephg> hello alterego longtime no see
15:03:01 <FlyingSheep> irc://irc.FreeNode.org:6667/#info Chris Lamb community member
15:03:04 <alterego> #info Tom Swindell, Sailor and community member.
15:03:09 <alterego> Hey steph :)
15:03:26 <M4rtinK> #info Martin Kolman, community developer ( modRana navigation system)
15:03:28 <alterego> Only around for an hour.
15:03:41 <SK_work> alterego: should last this long
15:03:46 <SK_work> maybe a little bit more but no much
15:03:50 <sdjayna> #info Steve Jayna, Infrastructure @ Jolla
15:03:54 <javispedro> #info Javier S. Pedro, community
15:04:05 <sledges> 90mins and more topics to cover, i don't think it will last only hour :)
15:04:06 <netzvieh> #info Sebastian Meyer, community member
15:04:16 <fravaccaro> #info Francesco Vaccaro, Jolla Community Italia admin, first time here
15:04:27 <cybette> fravaccaro: welcome :)
15:04:29 <cybette> 1 more min
15:04:40 <fravaccaro> thank you :)
15:04:43 <dr_gogeta86> #info Fabio Isgrò , sysadmin ... and Jolla phone breaker
15:04:49 <SK_work> hi fravaccaro :)
15:04:50 <pketolai> #info Pami Ketolainen, the bugzilla guy and t.j.c developer/admin @ Jolla
15:04:55 <w00t> #info Robin Burchell, Qt/MW hacker at Jolla and wider open source community
15:04:57 <SK_work> many italians here :D
15:05:07 <kimmoli> invasion?
15:05:14 <cobu> #info Tomi Virtanen, Sailor / swtester @Jolla, first time here
15:05:14 <w00t> (where's the agenda again? I can't find it..)
15:05:21 <faenil> "italians do it better" :p
15:05:24 <uvatbc> #info Yuvraaj Kelkar Jolla community
15:05:32 <cybette> cobu: welcome too :)
15:05:36 <SK_work> w00t: http://piratepad.net/SailfishOSSMeetings
15:05:40 <eleroux> #info Eric Le Roux, bugzilla & t.j.c admin
15:05:44 <w00t> SK_work: thanks, got buried in my tabs ;)
15:05:46 <fravaccaro> :D looks like we have good tastes in mobile
15:05:59 <cobu> cybette: thx :)
15:06:08 <deztructor> #info Denis Zalevskiy, Jolla, engineer
15:06:18 <cybette> ok let's get meeting going
15:06:25 <cybette> #topic Need for separate mailing list or forum? (15 min)
15:06:33 <cybette> #info There has been active discussions on the need/advantages/disadvantages of having a separate mailing list (for non-technical topics), a forum, or improving current tools.
15:06:38 <cybette> iekku, please address the topic and start the discussion
15:07:54 <cybette> iekku: ping?
15:08:12 <SK_work> too long coffee break ?
15:08:32 <iekku> I can continue from here, I have some lines to copy-paste :)
15:08:36 <javispedro> I think everyone knows what's this about either way.
15:08:54 <iekku> As a starter, here's the current situation:
15:08:55 <iekku> Developer mailing list is polluted with topics shouldn't be handled there. As David Greaves pointed out: "How would we (community, not Jolla) determine the line? and what measures do we think should be taken?"
15:09:13 <iekku> From this point of view I have indicated 2 problems:
15:09:21 <iekku> Problem 1:
15:09:23 <iekku> No clear agreed rules for mailing list.
15:09:28 <iekku> Solution: Let's create those together.
15:09:37 <iekku> Problem 2:
15:09:39 <iekku> Currently only Jolla employers are moderator. The "moderators" only moderate things like obvious spam, emails posted by non-list-member, etc. but not for off-topic content
15:09:45 <iekku> Solution proposal: select couple trusted community members as a moderators too.
15:09:59 <iekku> Then the actual topic:
15:10:00 <iekku> I assume we have general understanding on keeping developer mailing list as  a technical one.
15:10:09 <iekku> There has been + votes for general sailfish mailing list, but also - votes.
15:10:12 <iekku> Forum has been also asked, but currently we can't make it happen, together.jolla.com was our previous answer for need for Forum. We can revisit this after summer.
15:10:25 <iekku> Christopher Lamb's commented in the mailing list:
15:10:26 <iekku> 1) Together.Jolla.com (TJC): Q/A site mainly concerned on the phone + bugs and flames. So far no dedciated area for development issues.
15:10:28 <iekku> 2) Talk.Maemo.Org (TMO): A forum, strongly used by app developers and their users. Unlike other channels. this is Jolla independent.
15:10:28 <w00t> (I have to go for a bit, back in 10 mins or so :/)
15:10:31 <iekku> 3) This mailing list: used by developers to developers (both inside and outside Jolla).
15:10:35 <iekku> 4) IRC Chat. similar purpose to 3) above.
15:10:37 <iekku> 5) Other non-Sailfish-dedicated developer forums (StackOverflow, Qt Project etc.)
15:10:40 <iekku> So, is this enough?
15:11:19 <lbt> yes :)
15:11:21 <deztructor> imo, TJC serves needs in both dicussions and ranting. And it additionally to it flexible structure based on tagging can be organized into the information tree just inside the wiki hosted inside. Also any offensive posts can be easily marked and user moderation is available. Also if smth. is not related to the topic it can be dynamically retagged, so ranting will not be tagged as development at all.
15:11:22 <netzvieh> is there a clean way to get this introduction into the minutes?
15:11:30 <M4rtinK> current setup seems fine to me personally
15:11:31 <deztructor> tree-view: https://together.jolla.com/question/43899/lets-organize-information-about-jolla-and-sailfish-here/
15:11:35 <deztructor> editable as wiki
15:11:37 <SK_work> iekku: should we focus on discussion about devel-ML / devel user place to be, or in general discussion place ?
15:11:46 <SK_work> netzvieh: will do
15:11:56 <eleroux> deztructor: thanks for the initiative :)
15:11:57 <M4rtinK> mabe add a ML or two for less technical stuff
15:12:01 <SK_work> #info Current situation: Developer mailing list is polluted with topics shouldn't be handled there. As David Greaves pointed out: "How would we (community, not Jolla) determine the line? and what measures do we think should be taken?"
15:12:06 <deztructor> sailfish-devel like TJC: https://together.jolla.com/questions/scope:all/sort:age-desc/tags:app-development/
15:12:17 <SK_work> #info Problem 1: No clear agreed rules for mailing list.
15:12:33 <SK_work> #info Problem 2: Currently only Jolla employers are moderator. The "moderators" only moderate things like obvious spam, emails posted by non-list-member, etc. but not for off-topic content
15:12:34 <iekku> SK_work, i would go first with the problems, as those are most critical ones
15:12:40 <SK_work> iekku: ok
15:12:56 <iekku> and rest we need to think a bit more, it might go even to the next meeting
15:13:18 <iekku> better have clear understanding and good planning than do wrong decisions in rush
15:13:31 <FlyingSheep> agreed
15:13:32 <SK_work> right, as iekku maybe focus on the two problems pointed out first ?
15:13:39 <netzvieh> Problem 1: I'd say sailfish-devel should only be devel questions regarding sailfish/best practises
15:13:44 <SK_work> for problem 2, I +1 iekku proposal
15:14:08 <deztructor> for #1 I want to propose to replace ML with tagged TJC posts
15:14:09 <iekku> +1 for netzvieh
15:14:32 <SK_work> at least it would make the ML less controled by Jolla (or having the feeling that the ML is controlled by Jolla)
15:14:44 <lbt> fwiw : In my mind when I wrote that was something like "warning", 'mail subject to moderation after warning ignored'; then "temporary ban" then "permanent ban"
15:14:47 <faenil> deztructor, I think we share that view about how TJC could be improved
15:14:48 <SK_work> however, this leads to who should be admins
15:14:52 <netzvieh> deztructor: is there a clean way to get mails, answer with mails and have threads?
15:15:03 <faenil> though I think that post should be the homepage of the website, or it will be useless
15:15:09 <lbt> but also some metrics to measure against to see if rules were broken - hence the kde guidelines
15:15:28 <sledges> SK_work: volunteers candidate themselves
15:15:29 <iekku> lbt, :nod:
15:15:34 <iekku> sledges, +1
15:15:35 <SK_work> netzvieh: I would +1 however, it's hard to identify devel question that much. Is "how to flash SF on Nexus 4" a devel question ?
15:15:38 <deztructor> netzvieh: for subscription there is dynamic "Subscribed tags" in the side bar
15:15:39 <SK_work> pretty much yes and no
15:15:40 <SK_work> sledges: +1
15:16:06 <iekku> i would +1 lbt's proposal too
15:16:13 <netzvieh> SK_work: It's a user question, I'd say
15:16:20 <iekku> when we get community moderators it's clean game
15:16:26 <netzvieh> there could be a HADK list
15:16:38 <lbt> I don't see much need to moderate a mailing list unless it get's *really* OT ... development can easily spill into usage and some user problems trigger development responses
15:16:39 <deztructor> for any topic you participated in you will get e-mail notifications while you can exclude some tags
15:16:47 <SK_work> deztructor: kinda agree that TJC is well fitted for devel questions (much like stack overflow), BUT, the inherent non-organized structure makes it slightly strange
15:17:00 <lbt> also, in general, more mailing lists means less communication
15:17:05 <stephg> on that subject lbt, it may have been answerered last week but what happens with mer-general et al.?
15:17:07 <SK_work> while ML has a compact and portable form (ie you can even use it on SFOS)
15:17:10 <deztructor> SK_work: but https://together.jolla.com/question/43899/lets-organize-information-about-jolla-and-sailfish-here/ ?
15:17:22 <lbt> stephg: mer has only ever had one ml
15:17:25 <SK_work> deztructor: I have read this, and indeed, it sounds good
15:17:31 <SK_work> deztructor: but IMO, you shouldn't remove tools
15:17:33 <SK_work> or replace
15:17:34 <faenil> I think that can only work as homepage
15:17:36 <stephg> as has sailfish up until now, no?
15:17:38 <lbt> stephg: otoh our project is more focused
15:17:40 <SK_work> some people would like to keep ML
15:17:45 <SK_work> or use many tools etc.
15:17:48 <stephg> fair enough
15:18:05 <cybette> 3 min, are there some concrete actions we can take?
15:18:06 * lbt is not interested in a forum for example :) ... simply don't like the UI
15:18:06 <netzvieh> hmm is it possible to convert mails to questions/answers/comments automatically?
15:18:17 <stephg> lbt +1
15:18:45 <lbt> one criteria for the meego forum selection was effective ml integration - that I'd support
15:18:51 <M4rtinK> IMHO actually removing ML would be suicide
15:19:04 <javispedro> doesn't TMO have ML integration already btw
15:19:08 <lbt> not well
15:19:20 <M4rtinK> improving - yes, removing - big no
15:19:22 <faenil> as I wrote on ML, the fact that ML requires a good and configured email client to handle it decently is that alone a big drawback
15:19:28 <lbt> erm - not well last time I looked which was pre-meego :)
15:19:37 <sledges> "<+lbt> stephg: otoh our project is more focused" our = ? ;)
15:19:41 <lbt> faenil: it's a devel ml ...
15:19:46 <iekku> so, we keep devel mailing list and it's going to be for technical conversation?
15:19:58 <faenil> lbt, so? I'm supposed to use thunderbird because I'm a devel?
15:20:00 <SK_work> deztructor: wondering, is it possible to have TJC ML bridge ?
15:20:05 <lbt> if you can't configure an email client you don't belong on a devel ml :D ... I like the self filtering :)
15:20:13 * lbt runs
15:20:14 <AL13N_work> +1
15:20:18 <SK_work> one post in ML lands as topic in TJC, and replies lands as replies ?
15:20:21 <faenil> -.-
15:20:23 <iekku> and the ones who want to be moderator can contact developer-care@ we can have voting in next meeting?
15:20:25 <SK_work> faenil: :D
15:20:29 <deztructor> SK_work: imo, it is possible
15:20:32 <M4rtinK> faenil: well, many devs already use many other Mls, so it should not be that much of an issue
15:20:36 <SK_work> deztructor: this could be cool
15:20:38 <SK_work> iekku: +1
15:20:38 <kimmoli> is it possible just to give a try to TJC? test the taggings suggested by deztructor? this goes to tech details now..
15:20:39 <cybette> let's propose some action items on how to take this forward
15:20:39 <iekku> as none has said anything now
15:20:40 <deztructor> at least, there is bz-mail bridge
15:20:42 <cybette> 1 more min
15:20:42 <javispedro> faenil: lbt: no need for mail client, you can use Gmail web interface. as a filter it doesn't filter much.
15:20:44 <faenil> lbt, I'm talking about lowering the entry barrier, and you like the filtering? :D
15:20:48 <SK_work> can we have some actions ?
15:20:52 <stephg> kimmoli: how did your experiment go?
15:20:52 <deztructor> why there can't be ml-q&a
15:20:53 <SK_work> lbt's proposal were rather good
15:20:55 <M4rtinK> lbt: +1
15:21:04 <iekku> + there's lot's of community members who aren't participating to this meeting
15:21:06 <kimmoli> not well stephg , maybe too tricky question
15:21:12 <SK_work> faenil: lowering barrier and filtering is not incompatible
15:21:17 <SK_work> faenil: filter is to removet he noise
15:21:35 <stephg> javispedro: faenil there may be people in the world working on this that (during the day) don't have gmail access/or TMO or the web for that matter, but mail might be sanctioned
15:21:36 <SK_work> and maybe if a mail don't belong to some place, you can redirect the mail writer to another list, IRC ?
15:21:39 <faenil> SK_work, no he was talking about "filntering" devs who didn't use a good client :P
15:21:45 <SK_work> faenil: ah :D
15:21:57 <SK_work> faenil: it's about filtering out faenil, noting more
15:21:58 <dr_gogeta86> i think have some firm moderator is necessary
15:22:03 <deztructor> I think we have people in community who can help to get bridge done for askbot (if askbot does not have it already)
15:22:07 <SK_work> dr_gogeta86: I would say: fair
15:22:10 <SK_work> not firm
15:22:16 <stephg> +1 to community selected moderators
15:22:23 <SK_work> topic who belongs to ml, in, not to ml, out
15:22:26 <cybette> iekku: can you take action to continue discussion and work on solutions to the problems you stated
15:22:26 <javispedro> you don't need a "good client"; you just need to learn topposting ;P
15:22:27 <dr_gogeta86> sometimes you need to kick out someone
15:22:28 <lbt> faenil: it was a light-hearted comment - but yes, end users may have an issue; I seriously expect most devs to be able to setup personal folders and filters though
15:22:39 <SK_work> #action: elect community moderators
15:22:42 <FlyingSheep> On the whole I don't think we have had too much off-topic stuff, bar the last few days
15:22:45 <faenil> lbt, sure, but
15:22:45 <lbt> javispedro: that's a ban
15:22:47 <iekku> #action iekku to continue discussion and work on solutions to the problems you stated
15:22:52 <iekku> oops
15:22:56 <iekku> #undo
15:23:03 <faenil> lbt, my opinion is ML is good for one subject, i.e in this case devel...but what if you want something like forum's sections, how do you handle that
15:23:04 <iekku> #action iekku to continue discussion and work on solutions to the problems she stated
15:23:19 <cybette> ok thanks iekku :) let's move on
15:23:22 <lbt> faenil: we use the 'subject' line :)
15:23:26 <SK_work> #action: send application to developer-care@ for application as a modetaror
15:23:39 <iekku> thanks SK_work
15:23:43 <SK_work> cybette: maybe consider more time for discussion
15:23:48 <faenil> lbt, so I guess you don't have folders in your email client, you just read the subject ;)
15:23:49 <SK_work> because 15 min is small :(
15:23:55 <cybette> SK_work: that will eat into your docs time :)
15:24:00 <SK_work> cybette: :(
15:24:09 <iekku> SK_work, we continue next time :D + we take new topics related to this too
15:24:11 <netzvieh> iekku: maybe create a pad, for rules?
15:24:12 <lbt> faenil: I filter using various mechanims including ml headers and subject, yes
15:24:14 <cybette> I know 15 min is not enough. maybe 90 min is not enough
15:24:19 <AL13N_work> :)
15:24:20 <iekku> netzvieh, good idea
15:24:21 <lbt> s/filter/file into folders/
15:24:37 <iekku> #action iekku to create pad for mailing list rules
15:24:41 <SK_work> iekku: mind writing the topic directly in etherpad, so that we don't forget
15:24:46 <SK_work> iekku: cool :)
15:24:48 <faenil> lbt, and you think the need for a filtering mechanism is a good requirement for something which should be adequate for the "first app programmer" ?
15:24:54 <cybette> #info this topic to be continued...
15:24:56 <lbt> faenil: yes
15:24:59 <cybette> #topic How to manage internal hacking docs (30 min)
15:25:08 <faenil> lbt, :/ ok...
15:25:13 <SK_work> faenil: want to introduce this topic ?
15:25:18 <cybette> #info discuss about how to manage "hacker docs", internal doc that can be helpful when hacking a component
15:25:25 <cybette> faenil: please take the lead :)
15:25:37 <faenil> sure, but I talked about this in the past 1 or 2 meetings already :)
15:25:46 <dr_gogeta86> +1
15:25:51 <SK_work> reintroduce the topic in case that other don't know
15:25:56 <faenil> there is a need for overviews (possibly something eyecandy which has to attract people)
15:25:58 <faenil> of modules
15:25:59 <cybette> (btw I'd also want to be involved in discussion of previous topic so someone please volunteer as chair for next meeting :P )
15:26:34 <faenil> overviews which then become documentations of internals of a module
15:26:46 <faenil> that is really needed if there's a will to attract more people
15:27:06 <faenil> the current situation is: "I want to contribute to Nemo" -> "wait, what is nemo?"
15:27:19 <SK_work> attracting means: bringing more contributors to nemo
15:27:32 <SK_work> (captain obvious, but just in case)
15:27:38 <faenil> the ideal solution imho is to have a website
15:27:40 <AL13N_work> dev docs weren't always clear and i had to look into qt doc itself, which was then wrong, because some parts were not available
15:27:48 <faenil> which, similarly to the one for Ubuntu Touch
15:28:03 <faenil> guides the people into the structure of Nemo/Mer
15:28:05 <SK_work> faenil: ubuntu touch is rather an API docs than developers docs
15:28:06 <netzvieh> cybette: you could ask in a mail, once a time is set :) If I'm available I'd do it
15:28:12 <SK_work> faenil: +1 for guides
15:28:20 <M4rtinK> for starters a central page just listing all the components would help
15:28:22 <cybette> netzvieh: great, thanks in advance!
15:28:24 <faenil> SK_work, it is something that gives you a hint about how things work at least
15:28:25 <AL13N_work> faenil: SK_work: isn't it better to have more devs to mer, rather than nemo?
15:28:31 <SK_work> a description of all pages
15:28:42 <faenil> AL13N_work, Mer/Nemo will soon be the same thing, no difference
15:28:51 <M4rtinK> with just link to source and very short description
15:28:51 <SK_work> AL13N_work: this also comes with mer nemo merging, but middleware being developerd or used is essentially nemo
15:29:18 <lbt> I don't think that removes nemo
15:29:25 <SK_work> deztructor: did you proposed github.io / github markdown to produce some kind of page ?
15:29:30 <lbt> I think it focuses nemo on the UI layer with glacier
15:29:36 <xmlich02> Just release source code of as much components as possible. The internal hacker documentation will be not necessary anymore ..
15:29:37 <faenil> though there doesn't seem to be much interest on Jolla's side, as nothing has been done so far (or has it?)
15:29:38 <lbt> afaui
15:29:46 <faenil> can Jolla please specify its position about this?
15:29:52 <deztructor> SK_work: yes, I have it e.g. for the statefs statefs
15:30:03 <SK_work> xmlich02: we are taling about nemo middleqare that are opensource
15:30:03 <SK_work> not about ui components
15:30:04 <faenil> if there's no time available in the next 5 months, we shouldn't even discuss about this ;)
15:30:04 <lbt> faenil: about what?
15:30:07 <M4rtinK> xmlich02: +1
15:30:09 <deztructor> SK_work: while autodoc has advantage to be auto :)
15:30:18 <faenil> lbt, about the creation of such appealing documents for newcomers
15:30:30 <SK_work> deztructor: but does it generates something like: an overall page that talks about each component
15:30:48 <SK_work> what I would love to see is this kidn of page https://sailfishos.org/sailfish-silica/sailfish-silica-all.html
15:30:52 <SK_work> but for all middleware
15:30:55 <lbt> faenil: for middleware? I don't see that as a high prio for jolla as such
15:30:59 <SK_work> or maybe all packages in mer+nemo
15:30:59 <faenil> xmlich02, we're talking about documentation for the opensource parts
15:31:06 <lbt> I do see enabling it as a reasonable solution
15:31:14 <SK_work> lbt: indeed, and that's what faenil is worried about
15:31:19 <faenil> lbt, hence my question
15:31:26 <deztructor> SK_work: it can be organized here: https://nemomobile.github.io/
15:31:28 <Aard> SK_work: without fully reading the backlog, if documentation is buildable on autodoc we should make the time to go through legal check if it can be released.  if it can be -> hook to public autodoc. if not, either clean up or don't release. if not autodoc -> make it autodoc, go back to step one
15:31:29 <sledges> lbt: faenil: are github/mer+nemomobile sources already in autodoc format?
15:31:32 <lbt> so that's things like autodocs and suchlike - which are being worked on
15:31:35 <faenil> lbt, since Jolla has done pretty much nothing about it since the first meeting
15:31:38 <SK_work> deztructor: exactly
15:31:44 <faenil> I'd say we should stop worrying about it if Jolla doesn't have time for it
15:31:47 <Aard> for opensource, everything should be in autodoc already, and if not, will be eventually, as that's what we're using internally
15:31:49 <lbt> faenil: fwiw that's a mer issue, not jolla
15:31:54 <sledges> ^
15:32:09 <faenil> sure, well maintainer's being Sailors (95?)
15:32:11 <lbt> and therefore falls to me and my thousands of eager herlpers...
15:32:14 <faenil> so...well, you know
15:32:16 <lbt> oh wait.. me
15:32:19 <cybette> #info right now it's difficult for new-comers to Mer/Nemo to find out about what is Mer/Nemo and how to contribute. need better middleware docs to bring in more contributors
15:32:30 <sledges> all is needed(?) -> someone setting up autodoc on mer infra
15:32:32 <SK_work> faenil: maybe 2 different things can be done in internal docs area
15:32:35 <lbt> sledges: yes
15:32:38 <SK_work> 1. autodocs, like Aard said
15:32:41 <sledges> for really good head start
15:32:46 <SK_work> 2. preview, like you proposed at the beginning
15:32:51 <lbt> and infra is on my todo (I actually have a VM already I think)
15:32:57 <SK_work> 2. can be done rather easily, thanks to github.io etc.
15:32:58 <deztructor> Aard: do we have public autodoc?
15:33:01 <faenil> lbt, btw it's Jolla's job as well, if it wants to see somebody contributing to the platform JOLLA is using for its OS ;)
15:33:04 <SK_work> while 1. requires autodoc etc.
15:33:07 <Aard> deztructor: not yet, is on todo
15:33:43 <sdjayna> aard: i can help with that, if you give me a start, from a jolla infra pov
15:33:46 <faenil> so basically we can wrap up like in last  meeting
15:33:55 <faenil> all Jolla can do is in autodoc
15:34:00 <SK_work> #info it could be nice to have guides the people into the structure of Nemo/Mer
15:34:01 <faenil> and it will be published soon (TM)
15:34:13 <lbt> and I can reasonably easily get an autodoc system up
15:34:14 <Aard> note that documentation lives in git -> community is welcome to contribute and send pull reuqests when there are gaps they can fill
15:34:19 <lbt> +1
15:34:37 <faenil> Aard, of course. Now find me someone who's not a sailor and knows the internals of middleware
15:34:42 <SK_work> Aard: this requires though that people know the component
15:34:43 <faenil> and we'll ask him to write docs :)
15:34:59 <Aard> faenil: me. o h damn... :p
15:35:01 <lbt> faenil: find me a sailor born knowing the middleware...
15:35:17 <Aard> faenil: anyway, you should just try to talk to the people to get info out of them when you want to do that
15:35:21 <dr_gogeta86> no one
15:35:29 <faenil> lbt, I can find you a lot paid to get to know it, want to place a bet? ;)
15:35:39 <SK_work> some initial doc can also be done when assigning maintainers during mer / nemo merge
15:35:54 <deztructor> SK_work: +1
15:36:04 <faenil> Aard, so basically, yours and lbt's point is: Jolla doesn't have time, if you want docs, community should keep asking questions and write them themselves
15:36:05 <lbt> faenil: my point is that opensource is about doing work yourself  (not 'you' but all of us)
15:36:10 <faenil> is that a good summary?
15:36:11 <Aard> faenil: no
15:36:14 <SK_work> and if you have a maintainer on a package, you can ping this person to have either more info, or more docs
15:36:28 <sledges> SK_work: +1
15:36:35 <faenil> lbt, opensource is also about not wastin people's time, if there are people who can do your job for 1/1000 the time
15:36:42 <lbt> hah
15:36:47 <Aard> faenil: my point is, jolla uses autodoc, so you should use autodoc as well as it's jollas interest to have good documentation for us to use
15:37:01 <Aard> if it's not in autodoc there's a good chance that we don't have proper written down documentation as well
15:37:02 <lbt> faenil: trust me - it doesn't work like that - and I do understand it
15:37:23 <faenil> Aard, okay, and we all agreed on that I think :)
15:37:48 <lbt> faenil: however, if you make an effort to *start* something then typically a maintainer will appreciate the effort and support you
15:38:00 <AL13N_work> a simple overview page would be nice for me
15:38:02 <javispedro> I suspect half of mer/jolla's "how does everything fit together" docs would be similar to other Linux distros.
15:38:07 <faenil> Aard, so, back to what I wrote above:
15:38:09 <faenil> <faenil> so basically we can wrap up like in last  meeting
15:38:09 <faenil> <faenil> all Jolla can do is in autodoc
15:38:13 <javispedro> so maybe it would be important to center in differences.
15:38:28 <SK_work> javispedro: like ?
15:38:42 <lbt> faenil: you seem to say that as a negative - I see it as a positive... ?
15:38:45 <sledges> faenil: do i read you well: sole autodoc is not enough eye-candy for you?
15:38:55 <AL13N_work> i'm not a sailor, and i know a bit of middleware, because i asked around
15:38:57 <javispedro> SK_work: <lower level bias> well, mce would be something completely alien to someone coming frm linux
15:39:03 <javispedro> (for example).
15:39:11 <faenil> lbt, no I'm just trying to wrap up something for once :P but nobody here wants to take a clear position or say something official :p
15:39:31 <lbt> erm .. we'll officially support autodoc based documentation efforts :)
15:39:32 <SK_work> javispedro: the eye candy faenil said ?
15:39:42 <SK_work> #info <+lbt> erm .. we'll officially support autodoc based documentation efforts :)
15:39:51 <AL13N_work> it would still be nice if there's a very short doc that lists the components used and how they fit in and where to find them
15:40:04 <faenil> sledges, I'm all for autodocs if it has all the info we need, but Aard and lbt are not making me believe in the reliability of such docs :P
15:40:05 <M4rtinK> +1
15:40:10 <Aard> AL13N_work: as I said last time, I'm working on that, will be published when I have autodoc
15:40:21 <sledges> faenil: but that would improve, and would be win-win
15:40:22 <lbt> AL13N_work: that type of lead-in would be good in a wiki - although you can also autodoc it
15:40:22 <SK_work> AL13N_work: I guess this is the github.io thing
15:40:22 <AL13N_work> Aard: good enough for me
15:40:25 <cybette> 15 min left
15:40:29 <sledges> better than nothing ;)
15:40:39 <sledges> we just need autodoc.merproject.org !
15:40:47 <faenil> sledges, how will it improve?
15:40:50 * lbt goes to make the VM
15:41:00 <faenil> 1) jolla spends time on it
15:41:20 <sledges> faenil: community can see what is not reliable and point it out, send PRs to respective components to improve docs
15:41:20 <AL13N_work> a list is good, but not great, sometimes the dependencies are unclear
15:41:23 <faenil> 2) community keeps begging sailors to tell more details, sailors spend time explaining, time which they could also spend writing directly in the docs
15:41:59 <SK_work> AL13N_work: well, this kind of doc can be written and improved rather easily
15:42:04 <sledges> faenil: substitute 2) - sailors go and edit autodoc and give updated docs to the askers ;)
15:42:10 <SK_work> BUT, it takes time, and not sailors time here (IMO)
15:42:10 <AL13N_work> yes, and i once started to write a wiki
15:42:24 <SK_work> or maybe yes, but the problem is that it's the responsibility of all maintainers
15:42:28 <sledges> which should be added to (https://together.jolla.com/question/39552/what-is-the-participation-and-contribution-policy-for-jollas-open-source-contributors-in-open-source-projects/ ) ;)
15:42:28 <faenil> sledges, but that can only work if there's a good base
15:42:40 <sledges> faenil: the base is already there (internal jolla autodoc)
15:42:46 <sledges> which will be mirrored on merproject
15:42:49 <faenil> most people won't even ask for help if they see there's hardly any documentation
15:42:51 <SK_work> sledges: is it here for every project ?
15:43:08 <SK_work> faenil: well if the internal autodocs is here for many projects, then it might help
15:43:09 <sledges> sledges: just like any sailor you ask - we know only a subset of projects ;)
15:43:15 <faenil> sledges, well, if it's good and detailed documentation I guess we're all good
15:43:19 <sledges> (same applies to question - pls explain the middleware ;)
15:43:22 <faenil> everything can be improved
15:43:32 <sledges> 18:43 < faenil> sledges, well, if it's good and detailed documentation I guess we're all good
15:43:35 <sledges> Aard: ^ ? ;)
15:44:14 <thp> faenil: it's basically just all html and files that look like docs extracted from binary packages. autodoc just makes it easy to browse without having to clone, build extract the docs manually
15:44:22 <faenil> but as said, Aard and lbt don't seem to want to state that clearly, sympthom that it's not in a very good state :D
15:44:28 <Aard> sledges: see above. autodoc will contain about 99% of the documentation jolla has. if it's not good enough we need to improve that (and jolla will benefit on that). the remaining 1% needs to be moved to autodoc eventually
15:44:34 <sledges> thp: faenil asked if the src code is well documented (the one that autodoc scavenges)
15:44:44 <AL13N_work> Aard: +1
15:44:51 <lbt> autodoc isn't magic
15:45:00 <lbt> it doesn't scavenge
15:45:03 <sledges> Aard: "will contain", but faenil was asking about current state of affairs
15:45:03 <faenil> I'm just asking how good
15:45:06 <faenil> that documentation is
15:45:14 <faenil> and none seems to be able to provide an answer :D
15:45:23 <thp> faenil: it differs from project to project
15:45:23 <kimmoli> sample?
15:45:24 <lbt> it simply exports any 'make doc' contents into a web area
15:45:29 <Aard> faenil: it's impossible to provide an answer. it heavily depends on the components
15:45:50 <SK_work> faenil: I think that first, we should see what autodocs delivers
15:45:51 <lbt> if 'make doc' makes a crappy README.txt then that's what you get on the autodoc web view
15:45:53 <sledges> lbt: ah sorry i thought it's more like javadoc... hmmm how many people implemented make doc?
15:45:55 <faenil> of course, but you know, something like average, more or less...gah :P
15:45:55 <SK_work> and see what components are not good
15:45:59 <Aard> plus, if you don't use an area then you don't know about the quality of the documentation. so we'd need to go through those areas now to answer that question. which you can already do yourself, as it's in git
15:46:01 <thp> i guess from worst case "no docs at all" over "doxygen, but not annotated - no markup comments" to "fully documented as a guide"
15:46:08 <SK_work> then, we should point ouyt where to improve
15:46:18 <lbt> if it makes a wonderful html guide with styles... you get that
15:46:29 <Aard> we have several components with doxygen or similar
15:46:41 <AL13N_work> why don't we just wait on judgement of autodocs until it's there
15:46:57 <sledges> AL13N_work: +1
15:47:06 <thp> example: lipstick uses doxygen, and also has some additional guide pages: https://github.com/nemomobile/lipstick/blob/master/doc/src/launchermodel.dox
15:47:07 <AL13N_work> next topic plz
15:47:08 <sledges> that's first step
15:47:24 <lbt> sledges: the good think is that 'make doc' is a packaging level issue which may or may not use upstream docs
15:47:26 <dr_gogeta86> just one thing
15:47:29 <Aard> I don't really see how much the quality matters, though -- like I said, it's all we have. so either it's good enough, or not. nothing we can do about that before publishing
15:47:48 <dr_gogeta86> if jolla wanna attract deves i think is not the good mood
15:48:02 <dr_gogeta86> today there are some newcomers
15:48:19 <dr_gogeta86> and I think community and employers
15:48:23 <faenil> again...
15:48:25 <faenil> <faenil> so basically we can wrap up like in last  meeting
15:48:25 <faenil> <faenil> all Jolla can do is in autodoc
15:48:32 <thp> we also have to differentiate "app developer docs" (public APIs) from "platform developer docs" (e.g. lipstick's API)
15:48:35 <dr_gogeta86> doens't give out the best
15:48:40 <SK_work> thp: +1
15:48:51 <SK_work> thp: I was thinking about using the @internal from doxygen
15:49:00 <SK_work> but this leads to one problem: how to document qml components ?
15:49:04 <Aard> thp: app developer docs go to sailfishos.org
15:49:06 <SK_work> since this relies on qdoc
15:49:14 <thp> imho platform developer docs is what autodoc will give us. for app developer docs, we can hand-pick some API docs, but also should have a guide (which can of course be built with autodoc)
15:49:31 <thp> Aard: +1
15:49:44 <faenil> okay, I'll write it
15:49:47 <AL13N_work> clearly, to jolla it's more important to have app devs than middleware devs... so let's just get the autodoc and improve from there
15:50:05 <SK_work> AL13N_work: not exactly true
15:50:10 <thp> SK_work: autodoc "supports" qdoc in the sense that it doesn't care (qdoc is used at buildtime -> autodoc extracts the html files from the binary packages)
15:50:15 <faenil> #info Let's wrap up: same status as previous meeting. Jolla will publish its documentation which is autodoc-based
15:50:17 <SK_work> having mw dev encourage people to embrace the full os
15:50:18 <cybette> 5 min. any possible actions at this point? or we revisit this topic when autodocs is in place.
15:50:32 <SK_work> just like some app devs got to learn nemo to have wider range of integration
15:50:35 <faenil> #info once that documentation is published we'll see its quality, what's missing etc and take actions based on that
15:50:37 <SK_work> and at the end start to fix stuff
15:50:46 <SK_work> thp: right
15:50:51 <AL13N_work> (i would prefer the autodoc to be online sooner rather than later)
15:50:54 <SK_work> thp: but I was thinking internal vs non-internal
15:50:58 <faenil> #action Aard is working on making the autodoc docs public
15:51:08 <lbt> orly
15:51:21 <Aard> nazanin: ^^ make a note, please :)
15:51:28 <stephg> timescales either way?
15:51:35 <stephg> (seeing as was in last weeks too?)
15:51:50 <thp> SK_work: yes, i guess public QML API would be qdoc, internal - if needed - could be source code comments or doxygen or something.
15:51:58 <AL13N_work> i'd prefer to having it online even if it's partial
15:52:02 <SK_work> thp: +1
15:52:31 <SK_work> faenil: what about the introduction page we discussed at the beginning ?
15:52:42 <SK_work> should we discuss it a bit, or just leave it to autodocs ?
15:52:46 <faenil> SK_work, right
15:53:04 <faenil> but it seems jolla won't take care of that, as I understood it
15:53:15 <faenil> because that's what I meant by overviews of modules
15:53:16 <thp> SK_work: i guess let's just get autodoc running and when we have this, we can see what needs improvements and where we need some introduction/overview/index
15:53:27 <SK_work> faenil: autodoc can provide a good list
15:53:29 <Aard> faenil: I said several times that overview page of modules will come from me
15:53:33 <SK_work> but, it's might not be sexy
15:53:35 <SK_work> Aard: ah ?
15:53:38 <SK_work> right missed it
15:53:43 <SK_work> #info [17:53] <+Aard> faenil: I said several times that overview page of modules will come from me
15:53:44 <AL13N_work> i've seen Aard say this several times
15:53:49 <faenil> Aard, I only read that "a list" will come, with dependecies maybe
15:53:52 <faenil> did I miss something?
15:53:56 <Aard> maybe :)
15:53:59 * SK_work is not following well
15:54:23 <AL13N_work> (17:39:51) AL13N_work: it would still be nice if there's a very short doc that lists the components used and how they fit in and where to find them
15:54:23 <AL13N_work> (17:40:10) Aard: AL13N_work: as I said last time, I'm working on that, will be published when I have autodoc
15:54:35 <thp> Aard: and we set up so that it builds/syncs automatically from obs/git? so we don't have to manually trigger an autodoc run?
15:54:47 <cybette> logs will be available after meeting for detailed perusal ;)
15:54:54 <AL13N_work> heh
15:54:57 <faenil> what I meant by overview is descriptions, explanations of how modules link to other modulers
15:55:02 <faenil> and their duties
15:55:04 <faenil> not a list :p
15:55:10 <cybette> 1 min, let's wrap up and move on to next topic of more docs :P
15:55:10 <SK_work> faenil: maybe we can work on this too ?
15:55:14 <SK_work> but afterwards ?
15:55:24 <stephg> cybette: everyone loves docs
15:55:26 <AL13N_work> faenil: i said a list + how they fit in with each other
15:55:26 <SK_work> like when autodoc is out ?
15:55:30 <cybette> stephg: o/
15:55:33 <xmlich02> From my point of view, it doesn't matter if the documentation is created in autodoc, or just using wiki, or any suitable tool. There should be clear way how to update it if not accurate/up to date.
15:56:00 <stephg> xmlich02 +1
15:56:02 <SK_work> xmlich02: +2
15:56:05 <Aard> thp: we'll have to set up on mer obs once autodoc is deployed. basically, everything marked as doc package will be thrown to autodoc
15:56:09 <nazanin> Aard: from?
15:56:32 <Aard> nazanin: the sentence before I marked it, it'll end up on your desk eventually
15:56:36 <cybette> new topic
15:56:40 <cybette> #topic More docs: Silica API reference (15 min)
15:56:47 <cybette> #info discuss about pain points, weakness of the doc, what to enhance (from Jolla side), how to contribute (from community side)
15:57:01 <cybette> SK_work: stage is sstill yours :)
15:57:39 <javispedro> here's the Sailfish Silica Reference: https://sailfishos.org/sailfish-silica/sailfish-silica-all.html
15:57:45 <AL13N_work> imho, that isn't great, i had to go to the up qt docs several times, but then got stuff that's not implemented on jolla
15:57:50 <SK_work> cybette: woops sorry
15:58:19 <faenil> Aard, can you please point out any eta with the info tag?
15:58:22 <thp> do we know when the silica docs on sailfishos.org were last updated?
15:58:23 <cybette> SK_work: no worries. just carry on :)
15:58:25 <faenil> (sorry to interrupt guys)
15:58:30 <SK_work> There were several disucssions recently about silica docs. Silica docs by themselves are not bad, they can be read in QtC and from website, but they lacks of some information.
15:58:39 <kimmoli> i would like to see screenshots of the Silica parts on the references (as there are on pitfails page) I known there is component-gallery project.
15:58:59 <SK_work> First of all, it seems to be pretty hard to use if you are new to QML, and haven't done other QML dev (like harmattan). Many components exists, but you have hard time to find methods etc.
15:59:00 <FlyingSheep> +1 screenshots
15:59:06 <SK_work> it might be related to the lack of examples
15:59:12 <M4rtinK> screenshots!
15:59:21 <SK_work> 2. there were a proposal on ML to include screenshots in docs, what would you think about it
15:59:24 <Aard> faenil: no. we're still working on some changes to make coordinating that kind of work more efficient, the ETA for that is '2 weeks'. after that I hope we'll be able to give more reliable times
15:59:42 <AL13N_work> no, it's not lack of examples, it's the basic qt methods+properties that aren't there
15:59:45 <sledges> #info 1. Silica API reference docs are pretty hard to use if you are new to QML, and haven't done other QML dev
15:59:57 <kimmoli> and moar examples, specially copy-paste working examples
16:00:08 <sledges> #info 1.1 Many components exists, but you have hard time to find methods etc
16:00:08 <AL13N_work> this because qtdocs lists that, but not all of it is implemented for sailfish
16:00:09 <faenil> Aard, you can write this as well, at least we won't just have another "aard is working on it"
16:00:23 <SK_work> 3. as I linked in the etherpad, you have some websites that allow contribution of notes, to enhance docs.
16:00:26 <thp> AL13N_work: you mean from which Qt Quick items silica components derive? (e.g. BackgroundItem from MouseArea, Label from Text, etc..)?
16:00:32 <SK_work> it might be worth to include this kind of notes
16:00:44 <AL13N_work> thp: for example
16:00:55 <Aard> #info faenil: no. we're still working on some changes to make coordinating that kind of work more efficient, the ETA for that is '2 weeks'. after that I hope we'll be able to give more reliable times
16:00:56 <AL13N_work> thp: and some other basic qt quick which are available, and some aren't
16:01:00 <sledges> #info 2. proposal on ML to include screenshots in docs, what would you think about it?
16:01:03 <SK_work> #info Silica docs can be improved: 1. more examples ? 2. screenshots ? 3. contributed notes ?
16:01:14 <kimmoli> maybe make qdocs (or something) out of component-gallery ?
16:01:36 <kimmoli> which contains all silica components, source+doc+screenshots
16:01:47 <AL13N_work> inherited methods & properties would be nice
16:01:50 <SK_work> components gallery is pretty good indeed, as it provides both nice pages of how components are and code to use them
16:02:08 <thp> AL13N_work: +1, that requires some qdoc wizardy to interlink silica docs with upstream qt5 docs
16:02:12 <xmlich02> comment in web version of docs similar to php docs would be great
16:02:14 <kimmoli> AL13N_work: +1
16:02:19 <M4rtinK> btw, are there rpms for the componnent gallery somewhere ?
16:02:31 <SK_work> there could also be links to the best practice page (I'm thinking of backgrounditem should link to the lable changing color while placed inside a bg item)
16:02:44 <SK_work> M4rtinK: yes, zypper in silica-components-example or something like that
16:02:46 <AL13N_work> best practise pages would be nice, with a few use cases
16:02:54 <AL13N_work> it wasn't always clear what approach to use
16:02:57 <SK_work> M4rtinK: pkcon install sailfishsilica-qt5-demos
16:03:22 <kimmoli> i like the pitfails do's & dont's
16:03:36 <SK_work> I would also like some more UI guidelines
16:03:38 <xmlich02> in case of php it is called "User Contributed Notes"\
16:03:46 <AL13N_work> ie: should i go with rectangle, when to use row and/or column or what about backgrounditem vs other items etc...
16:04:04 <cybette> #info proposal on ML to include screenshots in silica reference has several supporting votes https://lists.sailfishos.org/pipermail/devel/2014-May/thread.html#4277
16:04:14 <SK_work> detailing how to design for example a messenger, or a forum browser, to see how to use an attached page, a dialog, views, pulley menus
16:04:22 <javispedro> and possibly some "full application" examples too.
16:04:34 <SK_work> because these components are really abused
16:04:57 <javispedro> sometimes I worry that if I delete the boilerplate the qtcreator "New sailfish app wizard" creates I won't be able to copy it back without creating a new app =)
16:05:02 <kimmoli> Full app example ; add qdocs to some own app, and publish it there?
16:05:57 <M4rtinK> SK_work: nice, thanks! :)
16:06:14 <thp> (as reference, the pitfalls document is at https://sailfishos.org/sailfish-silica/sailfish-application-pitfalls.html)
16:06:25 <FlyingSheep> C++ Qml integration has often been a topic on ML, so examples of that to ...
16:06:26 <SK_work> #link  https://sailfishos.org/sailfish-silica/sailfish-application-pitfalls.html
16:06:32 <javispedro> kimmoli: might be good enough and I think some people have done this
16:06:43 <SK_work> FlyingSheep: I guess this belongs to Qt, but a landing page pointing to Qt pages could be nice
16:06:46 <javispedro> (there are some entries in harbor that seeem to be "hello world" apps designed for that)
16:07:07 <M4rtinK> maybe the gallery could be installed when developer mode is activated ? :)
16:07:11 <kimmoli> C++ qml integration KISS samples +1
16:07:13 <FlyingSheep> SK_work: i meant in the context of a silica app
16:07:14 <cybette> 3 min..
16:07:28 <M4rtinK> IIRC it was like this on Harmattan
16:07:37 <kimmoli> M4rtinK: interchangeable with the tutorial ?
16:07:42 <SK_work> FlyingSheep: well, maybe from the main.cpp, you need a bit of help but in Qt pages you have a lot of them :)
16:07:46 <SK_work> M4rtinK: +1
16:07:57 <M4rtinK> yeah, tutorial, but for developers
16:08:13 <M4rtinK> would make it more discoverable
16:08:18 <kimmoli> y
16:08:25 <SK_work> M4rtinK: +1
16:08:47 <SK_work> another question now
16:09:02 <SK_work> should we, as SF developers, contribute this doc to Jolla if needed ?
16:09:09 <SK_work> like write this C++ / QML integration ?
16:09:12 <SK_work> or take screenshots ?
16:09:18 <kimmoli> ofc
16:09:30 <SK_work> but leave Jolla designers write the full app example ?
16:09:30 <Wnt> I would like to see a simple example in the official Silica documentation that has C++ <-> QML calls. I spent a lot of time searching for a such an example
16:09:40 <SK_work> kimmoli: then, how to do this ?
16:09:52 <SK_work> maybe a github ?
16:09:55 <kimmoli> SK_work: thats just the tools, there is will
16:10:05 <kimmoli> if the tools were different :)
16:10:19 <SK_work> indeed, the problem is tools: how are silica docs generated ?
16:10:19 <kimmoli> Wnt: i have modified qtcreator wizard for that
16:10:19 <thp> ok, so the C++ <-> QML integration thing has been brought up several times, this is something we should definitely have
16:10:21 <SK_work> (I bet qdoc)
16:10:27 <faenil> basically what Jolla is missing is
16:10:28 <faenil> https://developer.blackberry.com/native/documentation/cascades/
16:10:44 <SK_work> so maybe jolla should give us some insights on how to contribtue this easily for them ?
16:10:47 <cybette> #info <+thp> ok, so the C++ <-> QML integration thing has been brought up several times, this is something we should definitely have
16:10:54 <SK_work> iekku: ^?
16:11:06 <kimmoli> faenil: looks too complicated pages
16:11:12 <M4rtinK> well, I definitelly not miss Cascades ;)
16:11:15 <SK_work> faenil: +1, BB docs are solid
16:11:21 <M4rtinK> but the docs were nice
16:11:26 <faenil> kimmoli, play with it ;
16:11:29 <stephg> SK_work: faenil how much work/how complex is it to do it anyway? merge/integrate later?
16:11:49 <faenil> stephg, what do you mean
16:12:06 <cybette> iekku: maybe action for developer-care to look into making contribution easier with silica doc improvements?
16:12:10 <cybette> wrapping up
16:12:15 <SK_work> cybette: +1
16:12:16 <cybette> 3 more topics
16:12:31 <stephg> I mean if you have a vague diraction (hopefully not too vague! as to what they'd (jolla) expect just do it anyway?
16:12:36 <cybette> #action Jolla developer-care to look into making contribution easier with Silica doc improvements
16:12:48 <kimmoli> faenil: i will take a deeper look (aftrer i get a cold one later) :)
16:13:08 <iekku> +1
16:13:14 <cybette> next..
16:13:17 <cybette> #topic Bluetooth in Sailfish (10 min)
16:13:18 <SK_work> #action maybe ask the community tow contribute some docs (QML + C++, screenshots) etc.
16:13:20 <iekku> and sorry had to check out why puppy is barking
16:13:22 <SK_work> raah
16:13:22 <SK_work> :(
16:13:31 <cybette> #info Discuss current problems with Bluetooth in Sailfish, possible directions for the future, and how it affects the developer picture
16:13:36 <iekku> and now there's really weird voices coming from downstairs ->
16:13:45 <cybette> javispedro: this is your proposed topic?
16:13:48 <javispedro> yes
16:14:01 <javispedro> it's first time so I'm not sure about the needed time, but I'll try
16:14:07 <javispedro> let me summarize it in a shot way
16:14:10 <cybette> no worries, go ahead :)
16:14:22 <javispedro> I see 3 different (but not independent) problems re Bluetooth story in Jolla/Sailfish
16:14:32 <javispedro> Problem 1 is lack of public developer API for Bluetooth
16:14:51 <javispedro> Problem 2 is that Sailfish & Mer use Bluez4, which is dead upstream,
16:15:18 <javispedro> And 3 are miscellenaous bugs in Jolla hardware or adaptation layer that are preventing some use cases (e.g. wi-fi coexistance)
16:15:36 <javispedro> so, to elaborate
16:15:41 <javispedro> (feel free to interrupt now :) )
16:15:57 <Aard> 1) the reason for the lack of public developer api is that we were expecting to switch to bluez soon, which would break the api
16:16:10 <javispedro> I think the most important is problem 2 because it will change the way we may be able to fix 1 & 3
16:16:21 <cybette> #info javispedro notices 3 problems: 1. lack of public developer API for Bluetooth, 2. Sailfish & Mer use Bluez4 which is dead upstream, 3. misc bugs in Jolla HW/Adaptation layer preventing some use cases e.g. wifi coexistance
16:16:27 <kimmoli> (i would be interested in making BT apps, but die problem 1 - i have not been able to..)
16:16:52 <w00t> [sidenote: Qt 5 upstream has been slowly growing bluez5 support]
16:16:55 <javispedro> So, problem 2. Jolla uses Bluez4 (as does Debian, etc)
16:17:03 <sledges> Aard: "switch to bluez"(5?)
16:17:08 <w00t> [but, bluez5 hardware support is a Hard Problem from what I hear]
16:17:10 <javispedro> Bluez upstream has switched to Bluez5, but this breaks ABI
16:17:15 <javispedro> and API
16:17:20 <Aard> 2) see 1. however, bluez5 is still a bit of a mess + they changed kernel interfaces (and we have an old kernel), so it won't happen as soon as we were hoping. so' it's a lot more tricky than we expected
16:17:30 <javispedro> breaking many other components including but not limited to QtBluetooth itself.
16:18:08 <Aard> we recently reduced the importance of doing the switch, it's on my todo-list to figure out if we can compensate by utilizing community to help us there
16:18:26 <w00t> Aard: might be worth figuring out if qtbluetooth's api will remain the same for 4/5 (I think it will)
16:18:34 <javispedro> Aard: have you tried how much is broken in current kernel with bluez5?
16:18:35 <w00t> if that's the case, we can look at how to publicize qtbluetooth..
16:18:42 <Aard> javispedro: yes
16:18:49 <javispedro> (technically kernel 3.4 is the bare minimum for bluez5, and that you are already doing)
16:18:50 <Aard> javispedro: we'd need to backport bits
16:18:50 <faenil> Aard, would you see letting apps using current APIs as an option?
16:18:56 <sledges> #info on my todo-list to figure out if we can compensate  by utilizing community to help us there
16:19:03 <faenil> because if it won't happen soon ... :/
16:19:05 <sledges> #undo
16:19:19 <sledges> #info bluez5 is on Aard's todo-list to figure out if we can compensate  by utilizing community to help us there
16:19:20 <Sage_> javispedro: technically unfortunately the bt stack in the kernel isn't straight from the upstream 3.4 but in codeaurora or so.
16:19:33 <javispedro> Aard: ok, backporting even the entire bluetooth/* tree is not unheard of but I know it may be long process
16:19:45 <javispedro> Sage_: ouch.
16:20:00 <javispedro> so.
16:20:03 <Aard> faenil: no, we currently don't support qtbluetooth, and the bluez-qt is a big mess and basically provides a c++-api of the bluez-dbus-api -> it'll horribly break with the bluez5 switch
16:20:09 <javispedro> another option which Stskeeps briefly mentioned is Bluedroid.
16:20:18 <w00t> Aard: why don't we support it? I thought it was just the bluez5 switch
16:20:23 <faenil> Aard, yaeh but since the switch is not happening anytime soon... :/
16:20:24 <w00t> Aard: 'it' being qtbluetooth
16:20:29 <Sage_> also I want to remind that changing bluetooth stack from bluez 4 to 5 requires possible recertification of bluetooth to bluetooth sig so it isn't free either to do
16:20:36 <faenil> or you'd rather stay without bt apps for the whole year?
16:20:53 <Aard> so we have basically two options: 1) community helps us to move to bluez5 2) we work on moving to a stable bluetooth-api, and allow that in store as well. that'd include dropping bluez-qt, and rewriting bits using that
16:21:02 <Aard> both tasks are not really ideal / quick to do
16:21:28 <javispedro> anyone knows if qtbluetooth ABI as used in Jolla is compatible with final qt 5.2?
16:21:33 <Aard> w00t: there were some comments about state of qtbluetooth, don't remember exact details now. needs checking
16:21:36 <javispedro> (I'd assume so)
16:21:36 <thp> the other question would be, what parts of bluetooth APIs would app developers targetting harbour need? rfcomm? obex? anything else?
16:21:43 <Aard> javispedro: we're not using qtbluetotoh at all, we're using the old bluez-qt
16:21:48 <cybette> 2 more min
16:21:56 <Stskeeps> Aard: i think he's talking from pov of 3rd party apps
16:22:01 <javispedro> yep.
16:22:01 <w00t> Aard: ok, I'll #info it
16:22:13 <Stskeeps> not sailfishos internal usage
16:22:16 <Aard> Stskeeps: yes, but we can only allow it for 3rd party apps if we sort out the low level mess
16:22:28 <w00t> #info QtBluetooth may be usable as an abstraction point; needs API verification to make sure a possible 4/5 split won't break things
16:22:55 <javispedro> thp: what QtBt covered is OK I think
16:22:56 <w00t> (and try follow up with alex tomorrow..)
16:22:58 <meegobit> envolving the community seems exactly what the community has been asking for, and might relieve some otherwise overworked resources on Jolla's part
16:23:06 <javispedro> thp: (It still misses BluetoothLowEnergy though, even with 5.2)
16:23:08 <M4rtinK> well, by the time it is sorted out all interested devs migh have already left...
16:23:11 <faenil> who will do the API verification? :)
16:23:29 <javispedro> faenil: +1. So what's up with certification/verification?
16:23:38 <javispedro> would it impact community proposed solutions?
16:23:38 <w00t> faenil: see my second line. I need to talk to ablasche (qtbluetooth upstream maintainer) and ask him some questions :)
16:23:49 <faenil> ah I see ;)
16:23:55 <meegobit> we should be carefull which API to stabilize, considering we want to support upstream's QT solution someday, right? or not?
16:24:01 <faenil> w00t, mind infoing something about that?
16:24:11 <cybette> disconnecting bluetooth...
16:24:19 <stephg> heh
16:24:27 <kimmoli> who is looking this BT thing? managing it?
16:24:28 <w00t> #info w00tikins will follow up with ablasche (qtbluetooth maintainer)
16:24:30 <Sage_> javispedro: in the end if it is in the official firmware it needs to be done by jolla for jolla product before we can merge it there.
16:24:39 <javispedro> ok, gross understimation of time, but at least I think people is now aware of the problems :)
16:24:47 <cybette> #topic Update about chum repos progress if any (3 min)
16:25:04 <javispedro> Sage_: ok, this would affect all the support for all Jolla profiles :(
16:25:04 <cybette> javispedro: yes thanks for bringing it up :)
16:25:14 <cybette> anyone commenting about chum?
16:25:47 <meegobit> what  chum?
16:26:05 <cybette> meegobit: it was discussed in one of the earlier meetings
16:26:06 <SK_work> who proposed this topic ?
16:26:13 <meegobit> ha
16:26:20 <xmlich02> I was interested about progress
16:26:40 <sledges> lbt: tbr: ^
16:26:43 <xmlich02> Is there any task I can help with?
16:27:24 <sledges> meegobit: https://build.merproject.org/project/subprojects?project=sailfishos%3Achum
16:27:30 <lbt> I've not had time just recently - nor has tbr
16:27:33 <M4rtinK> I guess I could also offer some help
16:27:51 <cybette> #info xmlich02 and M4rtinK offering to help with chum
16:27:55 <sledges> lbt: great opportunity to offload your todo list ;)
16:28:07 <meegobit> sledges: thanks
16:28:12 <cybette> alright, last topic:
16:28:19 <lbt> getting an outline of the qa steps we'd like to automate is the main thing
16:28:24 <cybette> #topic ETA for paid-apps support on Store (2 min!)
16:28:38 <cybette> I don't have info on that..
16:28:42 <faenil> fravaccaro, the stage is yours!
16:28:48 <cybette> iekku: anything you can comment?
16:29:26 <faenil> basically fravaccaro (he shared his doubts with me already earlier) is worried about the status of the paid apps support in harbour
16:29:30 <cybette> faenil: that's my line, you get to say that if you volunteer to chair next time ;)
16:29:43 <iekku> 2nd half is my current understanging
16:29:46 <faenil> because it seems many developers are not uploading their apps because of that
16:29:48 <iekku> understanding
16:29:52 <fravaccaro> exactly
16:29:58 <SK_work> iekku: and info about stats ?
16:30:02 <SK_work> in harbour ?
16:30:16 <cybette> #info Some devs are not uploading apps to Harbour due to lack of support of paid-apps
16:30:17 <faenil> cybette, sorry I thought "I don't have info on that" was about the guy who added the topic :)
16:30:19 <kimmoli> harbour stats ++1
16:30:24 <iekku> hopefully during june
16:30:37 <fravaccaro> a general ETA like "after summer" or "within 3 months" would be nice
16:30:44 <fravaccaro> oh thank you, great :)
16:30:48 <cybette> faenil: hehe :)
16:30:59 <faenil> so, stats during June
16:31:03 <faenil> and paid apps in 2h 2014?
16:31:05 <iekku> june was for stats and 2nd half was for payment
16:31:06 <stephg> (hopefully!)
16:31:12 <faenil> iekku, can you info that?
16:31:13 <M4rtinK> any plans for related stuff like built-in donation support ?
16:31:25 <SK_work> #info Status during june and paid apps 2H 2014
16:31:31 <iekku> #info current ETA for stats in harbour is june
16:31:33 <M4rtinK> like in Mozilla addons repository ?
16:31:34 <SK_work> faenil: too bad I did it
16:31:40 <SK_work> M4rtinK: +1
16:32:06 <iekku> :D
16:32:06 <SK_work> M4rtinK: don't think that this was thought
16:32:08 <fravaccaro> (ops I missed you were talking bout stats)
16:32:34 <SK_work> but I would love to see this. Embedded donation system in store (like a popup just before installing) could be pretty nice :)
16:32:40 <sledges> has anybody checked flattr out - what do you think of this as a feasible option?
16:32:49 <cybette> additional questions please address to next meeting (since they weren't brought up earlier, it's hard to prepare for them)
16:33:11 <sledges> food for thought for next mtng
16:33:11 <iekku> M4rtinK, donation might be bit tricky as jolla is finnish company
16:33:18 <cybette> sledges: yep :)
16:33:28 <Aard> sledges: we have an rnd project for that. nothing to comment on.
16:33:36 <iekku> M4rtinK, in finland there needs to be "covernment" approval for getting donations
16:34:34 <cybette> we're already a bit overtime, let's set up next meeting time
16:34:38 <sledges> Aard: cool!
16:34:42 <cybette> #topic Next meeting
16:34:45 <meegobit> you cloud host the donation service on some other country
16:34:54 <meegobit> *could
16:35:03 <kimmoli> need to wash donations through dirkvl funky-shop
16:35:04 <cybette> next tuesday 15:00 UTC?
16:35:19 <stephg> kimmoli lol
16:35:23 <meegobit> wasn't it supposed to be alternated times?
16:35:43 <SK_work> iekku: :(:(
16:35:49 <cybette> meegobit: we had first 2 meetings 15:00 folloewd by 3 at 10:00
16:35:58 <meegobit> hum
16:36:01 <SK_work> cybette: next meeting at week ends ?
16:36:20 <stephg> SK_work: please no
16:36:20 <SK_work> time is ok for me, but I prefer 10 UTC
16:36:45 <meegobit> I just had the impression we were going to start alternating each week, to suit everyone best
16:36:57 <cybette> we can have next one at 10:00 UTC
16:37:24 <cybette> ok let's do that
16:37:34 <netzvieh> tuesday 10 or 15 UTC is fine with me, saturday 10 UTC should be okay too
16:37:43 <meegobit> for m it's fine either way, I'm just thinking of the rest of the community
16:37:52 <cybette> #info Next meeting Tues June-3 @ 10:00 UTC
16:38:04 <SK_work> a vote on ML or TJC ?
16:38:19 <kimmoli> TJS better voting than in ML
16:38:23 <kimmoli> *TJC
16:38:31 <cybette> SK_work: vote is problemetic when it comes to timing. I think we've had decent attendence for both time slots
16:38:43 <stephg> cybette: +1
16:38:43 <cybette> also depends on the topics presented
16:38:45 <sledges> time votes work on piratepad
16:38:55 <stephg> sledges: +1
16:39:07 <cybette> sledges: yeap
16:39:07 <iekku> from my point of view i can say for 95% sure that i can't promise to be in the meeting during weekens
16:39:11 <iekku> weekend
16:39:24 <meegobit> I got in late, so I couldn't participate on that topic, and I wanted to say, I agree with many, that tjc already has most of the required ingredients to suit everyone
16:40:00 <meegobit> it's kind of a forum (just easier to read IMHO)
16:40:02 <cybette> we'll plan it for 10 UTC and adjust if really needed (e.g. the person presenting a topic needs to be there etc.)
16:40:13 <iekku> +1
16:40:15 <SK_work> ok
16:40:19 <netzvieh> cybette: I could do chair on tuesday 10 utc
16:40:21 <kimmoli> piratepad link once more plz?
16:40:23 <cybette> thanks everyone! let's continue this next week
16:40:25 <meegobit> it's also kind of a ML, altough that could be improved
16:40:27 <cybette> netzvieh: o/
16:40:27 <sledges> thanks netzvieh ! and everyone
16:40:34 <stephg> http://piratepad.net/SailfishOSSMeetings
16:40:37 <cybette> #info netzvieh chairperson for next meeting
16:40:39 <kimmoli> tnx
16:41:01 <cybette> alright thanks again, disconnecting...
16:41:04 <cybette> #endmeeting