15:00:01 <tbr> #startmeeting SailfishOS, open source, collaboration
15:00:01 <Merbot> Meeting started Tue Apr 15 15:00:01 2014 UTC.  The chair is tbr. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
15:00:01 <Merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:20 <tbr> welcome to the meeting, we're timeboxed quite strictly
15:00:25 <tbr> #nick Jolla
15:00:25 <tbr> #nick Community
15:00:30 <tbr> Please note that I want to see a good and productive discussion. I'm today just the meeting chair and I will maintain order. To do this I'm not afraid to mute people. I won't care who they are.
15:00:34 <tbr> There will be _ONE_ warning only, then mute, duration at my discretion. I won't answer to privmsg.
15:00:37 <tbr> So please just keep it civil and we'll have a great meeting.
15:00:40 <tbr> without further ado:
15:00:42 <tbr> #topic 1. Introduction of meeting participants
15:00:47 <Stskeeps> #info Carsten Munk - Chief Research Engineer @ Jolla
15:00:49 <tbr> something about you and why you're here
15:00:49 <tbr> prefix your introduction with "#info" to show up properly in the meeting minutes
15:00:52 <tbr> timebox: 10 min - until 15:10
15:00:55 <tbr> #info Thomas Ruecker, community person, Tieto employee, today not wearing any hats, just the meeting chair.
15:00:55 <lbt> #info lbt I'm a Mer co-founder and a Sailor too. I look after the public Mer infra, mer-tools and the Mer SDK which provide systems and tools to enable contributions. Systems includes stuff like bugzilla, gitlab, OBS, IMG, BOSS etc etc
15:01:01 <vgrade_> #info would like to consider myself a community member of mer/nemo projects doing mainly device adaptation work. Other hat, working with a vendor internally on a product based on Mer
15:01:08 <marc3> #info Marc Dillon
15:01:15 <fk_lx> #info Filip Kłębczyk, Upper Silesia region, Poland - feeling as a part of community, interested mainly in contributing to Nemo MW parts. Interested in all actions that would make Mer/NemoMW more contributor friendly.
15:01:18 <JvD_> #info I am Developer, ex-Meego hacker and I have been lately playing with other half HW (Myhalf). I am here for curiosity in where is the community heading to and for being part of it.
15:01:19 <artemma> #info Artem Marchenko: 6 apps in jolla store, 4 in ovi store, day job iOS app with thousands of daily users. Hope to hear abt final apps dev perspective: how community could work on adapting standard open source practices to harbour requirements (or adapt requirements to be easier). E.g. work on tools for bundling libs in, improving RPM checker rules, how-when-when-who to decide on access control.
15:01:28 <rainemak> #info Raine M�kel�inen - Engineer @ Jolla
15:01:29 <JvD_> #info Tommi Keisala
15:01:32 <Anarky> #info I'm working at Adeneo Embedded; my goal was to check how easy (or hard) it is to adapt Mer/Nemo on a board
15:01:33 <w00t> #info w00t long-term Mer/Nemo contributor, Qt Project approver, and open source hacker. My most recent hat is that I'm one of the Jolla folks, since sometime in 2012. I hack on many things.
15:01:34 <deztructor> #info Denis Zalevskiy, Jolla. cutes(-js), statefs, the-vault. Helps phdeswer with energy management sw stack maintenance (kernel/upower)
15:01:35 <tbr> for those who just joined, all jolla employees will be voiced
15:01:48 <plundstr> #info Pekka Lundström working on Jolla, mostly involved with dsme, mce, systemd and other non-UI parts
15:01:50 <iekku> #info Iekku Pylkk�, head of developer affairs @ jolla, mer bugazilla maintainer and member of advisort board
15:01:53 <Tofe> #info Christophe Chapuis - Jolla user, and also an open-source developer, and I'm here because I'm interested in the way Jolla can handle and improve the collaboration with open-source communities.
15:01:54 <crevetor> #info Antoine Reversat, community member, just here to see what is going to be said and maybe voice some concerns
15:01:55 <veskuh> #info Vesa-Matti Hartikainen, work for Jolla, developing Browser
15:02:02 <_Razor_> #info Tommi Tauriainen, LTE SW Engineer @ Broadcom
15:02:13 <squidd> #info Here to spy where the community is going
15:02:23 <locusf> #info Aleksi Suomalainen Community member
15:02:28 <Sfiet_Konstantin> #info Lucien Xu, developer for Nemo / SailfishOS
15:02:40 <Mirv> #info Timo Jyrinki has too many hats, but free software mobile phones development via Openmoko/MeeGo/Ubuntu and a happy Jolla user
15:02:41 <faenil> #info Andrea Bernabei - Nemomobile contributor and Jolla user
15:02:41 <Sage-> #info Marko Sauko - Chief Engineer @ Jolla. Also was maintaining Nemo Mobile project on my free time earlier.
15:02:42 <sjtoik> #info Santeri Toikka, student, developer, working on paper about open software business models
15:02:43 <phdeswer> #info Philippe De Swert, Jolla, middleware and kernel engineer
15:02:45 <kontio> #info kontio Sailor @ Jolla, I have an eye on various QA issues...
15:02:54 <niqt> #info developer for nemo and sailfish
15:02:54 <dr_gogeta86> #info Dumb user and linux embedded enthusiast ... Sysadmin in real life
15:02:55 <eleroux> #info Eric Le Roux Bugzilla + T.J.C admin @ Jolla
15:03:01 <sdjayna> #info Steve Jayna, Jolla IT
15:03:01 <pketolai> #info Pami Ketolainen, the Bugzilla guy @ Jolla
15:03:05 <ZogG_laptop> #info ZogG Maemo community member
15:03:13 <jake9xx> #info Jarko Vihriälä - SailfishOS SDK
15:03:17 <cybette> #info Carol Chen, Community chief at Jolla, managing community related activities and events, social media, etc., assisting iekku in developer affairs when possible
15:03:20 <Yaniel> #info Student & Jolla user, following as a unix enthusiast and developer
15:03:21 <pvuorela_> #info Pekka Vuorela - engineer at jolla, text input, calendar, settings etc.
15:03:32 <MSameer> #info Mohammed Hassan SW engineer @ Jolla and FOSS hacker/contributer (mostly listening)
15:03:54 <sledges> #info Simonas Leleiva, in Mer/Nemo community since 2012, Nemo twitter account maintainer, SailfishForAndroid developer @ Jolla
15:03:59 <giucam> #info Giulio Camuffo, Sailor, qt5 and wayland
15:04:15 <jukkaeklund> #info Jukka Eklund, community guy, Jolla advisor
15:04:21 <M4rtinK> #info Martin Kolman - community member & application developer (modRana flexible navigation system)
15:04:35 <skvark> #info Olli-Pekka Heinisuo, developer, student, Jolla user, made the power half and solar half, interested in contributing
15:05:03 <ljo> #info Leif-Jöran Olsson foss developer, ported fbreader, listening mostly.
15:05:07 <stephg> #info Steph Gosling interested community member
15:05:12 <tbr> did I miss any sailors with voice?
15:05:20 <locusf> jake9xx is a sailor
15:05:42 <tbr> had already, doesn't hurt
15:05:51 <bijjal> #info Soumya Bijjal, program manager/sailor
15:05:59 <eleroux> tbr: aye Sir!
15:06:00 <ln-> #info Lauri Nurmi, 1 app in jolla store; participating this meeting as only as observer, probably.
15:06:00 <MSameer> Aard, alterego, jusa_, kaltsi  but I am not sure they are participating
15:06:10 <tbr> eleroux: please #info :)
15:06:16 <iekku> grande, bijjal, eleroux, Aard
15:06:24 <iekku> rozhkov
15:06:30 <grande_> #info Karl Granström, Jolla store & Harbour / sailor
15:06:33 <iekku> stezz_da_board, :D
15:06:34 <tbr> we're 91 people, quite many lurkers around, but not everyone has to intro themselves, especially if they don't want to discuss
15:06:36 <eleroux> tbr: I did :)
15:06:40 <fk_lx> stezz_da_board: nice nick :P
15:06:45 <stezz_da_board> you wanted da board you have da board ;)
15:06:49 <faenil> ahaha
15:06:54 <fk_lx> :)
15:06:58 <Sfiet_Konstantin> :D
15:07:07 <jake9xx> tbr: locusf: tnx
15:07:21 <kimmoli> #info Kimmo just listening for now (until goes HW related)
15:07:28 <Yaniel> tbr: might be worth mentioning in the topic or the announcement
15:07:30 <tbr> xmlich02: we're at intros
15:07:54 <tbr> Yaniel: yeah, that got in at last minute
15:07:55 <Yaniel> soemthing like "#info if you plan to speak"
15:07:56 <meetingcpp> #info Jens Weller, C++ & Qt Developer + Meeting C++ website/conference
15:07:58 <tbr> but should be obvious
15:08:16 <tbr> ok, 2min to go
15:08:27 <tbr> any more introductions? preface with #info
15:08:46 <stezz_da_board> #info Stezz: Da board
15:08:57 <debexpert> :D
15:08:58 * lbt notes that it would make sense to use #sailfishos for backchannel chats and clarifications
15:09:00 <ZogG_laptop> maybe little bit more serously?
15:09:03 <tbr> I'll fast forward, gives us some buffer
15:09:06 <tbr> #topic 2. When's the next meeting - Regular meetings every two weeks around the project?
15:09:11 <tbr> quick discussion, possible follow up on mailing lists
15:09:11 <tbr> timebox: 5 min (hard) - until 15:15
15:09:12 <xmlich02> #info Jozef Mlich (xmlich02/jmlich) is developer of foursail; maintainer of czech and slovak translations in openrepos. Sometimes speak about jolla at local conferences (installfest, linuxalt)
15:09:34 <tbr> Stskeeps: are you taking this?
15:09:36 <Stskeeps> yes, i can
15:09:39 <ragnarkurm2> #info Ragnar Kurm Doing my first Jolla app, otherwise talking all major programming languages (ca 30) and doing websites on Drupal
15:10:17 <tbr> reminder: sailors are voiced
15:10:18 <Stskeeps> #info so the idea is that while we have one meeting now, it seems like a good idea, because of the many diverse topics, that we do this every 14 days and the question is, is it a good time for people? are people interested in syncing about community's issues and so on?
15:10:57 <Stskeeps> because we have more than enough topics to go around :)
15:11:00 <tbr> so, opinions on this?
15:11:08 <lbt> +1
15:11:11 <veskuh> Well, we did biweekly meetings early on on Nemo
15:11:19 <tbr> FYI: The next meeting might be on the community open source repository etc
15:11:23 <Sage-> Sounds reasonable imo.
15:11:37 <tbr> opinions on the timeslot?
15:11:40 <artemma> +1. Topic selection - voting on TJC?
15:11:40 <fk_lx> In my opinions 14 days are enough, assuming such meetings will be regulary organized
15:11:44 <stezz_da_board> Good to have IMHO
15:11:45 <Stskeeps> artemma: that's a good idea
15:11:46 <MSameer> I wonder if it's better to have it once per week for the first few times until most issues get ironed out/discussed/clarified and then push it to every 2 weeks
15:11:46 <faenil> +1
15:11:49 <Sfiet_Konstantin> +1
15:11:56 <locusf> +1
15:11:57 <veskuh> MSameer, +1
15:12:00 <ZogG_laptop> +1
15:12:01 <Yaniel> +1 for voting TJC
15:12:02 <niqt> +1
15:12:07 <deztructor> +1
15:12:07 <fk_lx> MSameer: +1
15:12:08 <ljo> +1
15:12:08 <giucam> +1
15:12:11 <grande_> +1
15:12:12 <cybette> +1
15:12:16 <squidd> +1
15:12:17 <ZogG_laptop> maybe should discuss what time is better thou for most
15:12:20 <faenil> Yeah if it's possible once per week at the beginning, that would be cool
15:12:23 <Sfiet_Konstantin> (not much fan of TJC though, prefered ML)
15:12:28 <tbr> #info inital proposal is every 14 days, MSameer proposes to have it initially every week until things are ironed out
15:12:31 <dr_gogeta86> +1
15:12:31 <lbt> tiny fly in ointment - if you want to do OBS stuff I'm at ELC in 14 days :)
15:12:37 <tbr> I see significant support for this
15:12:38 <lbt> but generally +1
15:12:41 <sledges> +1
15:12:43 <w00t> tbr: might be nice to rotate around a bit. at least we have some folks in the australian region who are also interested in participating, but obviously now is a terrible time for that. I don't have any concrete suggestions :)
15:13:04 <stezz_da_board> w00t: do we have ppl now in the US timerzone ?
15:13:05 <tbr> w00t: right, that's inconvenient for lpotter
15:13:10 <Sfiet_Konstantin> w00t: +1 for this
15:13:31 <w00t> stezz_da_board: at least two (michael and john)
15:13:32 <cybette> I propose weekly, alternating time zones so more people can join
15:13:34 <ZogG_laptop> i would go maybe for weekend?
15:13:37 <ragnarkurm2> suggest that keypersons should have comfortable time for others it may depend
15:13:40 <tbr> any voices against initial every week and then every 14days, time adjusted later too if necessary?
15:13:58 <Stskeeps> i'm personally okay with msameer's proposal, it makes sure we get properly kicked off
15:14:00 <fk_lx> w00t: some rotation could be good like you proposed, but anyway you want satisfy everyone
15:14:02 <tbr> Looks like time will need more discussion off list
15:14:08 <fk_lx> *won't
15:14:10 <Sage-> current time -+ 4 hours?
15:14:13 <crevetor> I'm in EST
15:14:26 <Yaniel> +1 cybette
15:14:40 <Sfiet_Konstantin> +1 cybette too
15:14:41 <tbr> #info move around time within the day in the long run to accommodate other time zones
15:14:42 <jukkaeklund> +1 to cybette
15:14:45 <tbr> ok we're running out
15:14:46 <faenil> maybe UTC evening? like 19 UTC, so that both USA and AU guys can be available (and most of those in eu)
15:14:51 <tbr> so weekly and later biweekly?
15:14:53 <stephg> +1 cybette, tz isn't important, but the need is clearly there
15:14:54 <Stskeeps> +1
15:14:56 <lbt> +1
15:15:02 <Sfiet_Konstantin> tbr: weekly at the beginning
15:15:12 <tbr> #agreed weekly meetings in the beginning
15:15:12 <MSameer> tbr: +1
15:15:17 <Tofe> +1 weekly at the beginnign
15:15:18 <dr_gogeta86> i think
15:15:20 <tbr> #agreed biweekly later
15:15:28 <tbr> #topic 3. How to make contributing to Nemo/Mer/SailfishOS easier
15:15:29 <dr_gogeta86> better 1 week into release period
15:15:35 <tbr> quick introduction (Stskeeps)
15:15:35 <tbr> timebox: 1 min (hard) - until 15:16
15:15:36 <dr_gogeta86> and 2 on dev period
15:16:24 <Stskeeps> #info so long story short, a lot of the problems we have is because it is difficult to contribute to SailfishOS; this topic is a big one; and it needs to identify solutions and proposals for fixing these things
15:16:42 <Stskeeps> and covers more than just sailfishos, but also the projects it bases on, such as mer and nemo middleware
15:16:45 <Stskeeps> (done)
15:16:58 <tbr> #topic 3.1. Current problems and situation, potential solutions
15:17:04 <tbr> 30 min open floor discussion, divided into:
15:17:04 <tbr> 20 minute discussion
15:17:04 <tbr> 10 minute solution proposals
15:17:04 <tbr> timebox: 30 min - until 15:46
15:17:25 <tbr> this is the beef
15:17:31 <tbr> keep it civil but lively
15:17:37 <tbr> the floor is open
15:17:41 <Sage-> maybe link to the mailing list post?
15:17:50 <fk_lx> Last summer I took the effort and went through nemomobile MW projects on Github, checking if they have roadmaps, list of issues etc.
15:17:54 <Yaniel> needed: a clear summary of what components are used for what
15:17:57 <Yaniel> maybe a wiki
15:18:06 <vgrade_> #info https://lists.sailfishos.org/pipermail/devel/2014-April/003915.html
15:18:10 <Tofe> Yaniel: +1
15:18:20 <ZogG_laptop> bugzilla and roadmaps
15:18:23 <tbr> #link https://lists.sailfishos.org/pipermail/devel/2014-April/003829.html
15:18:32 <fk_lx> unfortunately in most cases there were inexistent (roadmaps, bugs etc.)
15:18:34 <faenil> +100 to summary of what components are used for what
15:18:36 * artemma as end app dev finds it hard to figure out which package/library to use for this or that feature
15:18:37 <deztructor> what about dot file of packages deps generated automatically? + manually supported mindmap
15:18:49 <Yaniel> it should have github links or notes "jolla internal" as applicable
15:19:07 <Sfiet_Konstantin> needed: a list of maintainers for the list of components that are available in Nemo github
15:19:07 <faenil> deztructor, it's not much about that imho, it's more about a list of the features of a component
15:19:09 <Sfiet_Konstantin> faenil: and deps
15:19:15 <Yaniel> deztructor: the idea is not bad
15:19:15 <Sfiet_Konstantin> what connects to what
15:19:17 <w00t> we have very little documentation about higher level architecture (how things fit together, what the functionality of components are in a bigger system, how they communicate).. and that raises the bar for someone trying to learn their way around things
15:19:18 <peppelakappa> +1 for bugzilla, roadmaps and components summary
15:19:25 <locusf> I think the essential problem is that people might be willing to give back to Jolla, but the current structure of the repositories is too broken apart. A good way to give back might be fixing bugs in the middleware, that Jolla have found and the community could react to?
15:19:27 <Yaniel> but it is more about "what is relevant to X and where do I find it"
15:19:37 <deztructor> faenil: mindmap if maintained manually, can contain all this information
15:20:07 <faenil> deztructor, as long as you fit that information into a dot file, that's ok
15:20:14 <faenil> but only repo names with links, that's not enough
15:20:28 <Sfiet_Konstantin> Stskeeps: started in listing the components in Nemo in the attempt to merge it in mer
15:20:31 <Sfiet_Konstantin> #link http://www.mail-archive.com/mer-general@lists.merproject.org/msg01426.html
15:20:31 <fk_lx> I think the essence of the whole problem regarding to collaborating is in poor documentation and communication
15:20:36 <lbt> I'll jot some notes on broad topics people raise: http://piratepad.net/g3jtUqh0W8
15:20:43 <artemma> Shall also nemo/mer packages be developed for being usable in sailfishos environment? E.g. right now some nemo plugins have to be recompiled for being used in the app
15:20:44 <w00t> (apart from mental documentation that a few lucky souls have picked up over time and carry around.. but that doesn't do much to help newcomers looking for, for instance, what pieces can affect a phonecall)
15:21:00 <deztructor> faenil: of course, not. Functionality/layers/packages/relations/maintainers
15:21:09 <faenil> deztructor, yes
15:21:27 <faenil> from the contributor point of view it's really hard to understand what piece does what
15:21:37 <faenil> the example I always bring is the contacts stuff, there are many repos
15:21:37 <deztructor> so, maybe not even wiki but github io maintained in git repo
15:21:43 <Anarky> The biggest problem for companies is to use OBS, it's hard to make an adaptation for a board with flexibility like yocto has
15:21:57 <faenil> let's say someone wants to implement contacts syncing to a new service...it's not easy to understand where to put what
15:22:13 <Sfiet_Konstantin> artemma: this is more related to stability of the component it seems. Because if Nemo is Open Source, all contributions, even those who breaks compatibility, should be discussed. Jolla cannot prevent you in breaking if it's for the greater good
15:22:26 <MSameer> faenil: so we need a high level overview of the various big blocks
15:22:27 <Sfiet_Konstantin> fk_lx: +1
15:22:45 <faenil> MSameer, yep
15:22:52 <fk_lx> essentialy we need changes and future plans (even if they will change) communicated
15:23:02 <fk_lx> it's hard to join a project if you don't know where it is going
15:23:04 <artemma> Sfiet_Konstantin: more like some plugins are not ready to be run in non standard locations (when bundled into app)
15:23:07 <ZogG_laptop> fk_lx: +1
15:23:08 <Sfiet_Konstantin> deztructor: wiki is easier to edit (IMO)
15:23:28 <deztructor> Sfiet_Konstantin: but if you need to generate mindmap e.g. from dot...
15:23:33 <Sfiet_Konstantin> deztructor: the problem is not how docs are generated (wiki / dox / github.io), it is the burden to maintain them
15:23:46 <dr_gogeta86> Anarky: +1 for you
15:23:58 <dr_gogeta86> I use yocto every day is a snap
15:24:06 <ZogG_laptop> Sfiet_Konstantin: deztructor i think it's more technical question and point is not how but what
15:24:08 <Stskeeps> anybody has issues that are not surrounding source code repositories/mer/nemo, but about things related to sailfishos as a contribution target in general for TOH/ideas/APIs/apps etc? just to make sure those are heard too
15:24:14 <fk_lx> We also need a clear contribution workflow - for communicate what you want to do, fork and create branch, do your stuff, send pull request
15:24:15 <lbt> Anarky: *nod*
15:24:22 <Sfiet_Konstantin> I don't understand you, Anarky, because I'm not a company using Mer. Mind explaining the advantages of Yokto, and issues of OBS ?
15:24:30 <faenil> So, one thing is for sure, Sailfish components (from core to the higher lvls) are lacking documentation
15:24:50 <fk_lx> faenil: +1
15:24:53 <deztructor> Sfiet_Konstantin: component maintainer should be responsible for generic information about component maintained by him to be actual
15:24:56 <faenil> fk_lx, +1 for the contribution workflow
15:25:12 <w00t> Stskeeps: process documentation is lacking.. we also don't have any clear governance structure
15:25:13 <ZogG_laptop> about TOHs it's interesting about compatability of future devices
15:25:22 <niqt> faenil: +1
15:25:25 <Sfiet_Konstantin> deztructor: but component maintainer is free to accept a patch that breaks behaviour without proper doc ("let's doc later" etc.)
15:25:29 <ZogG_laptop> in other  words some roadmap there too with future plans
15:25:54 <fk_lx> We should avoid situations when some quitely work on some mega-feature, and appear someday to commit the whole thing "out of the blue" and without any public discussion it is accepted, because someone wrote "LGTM"
15:25:56 <Sfiet_Konstantin> deztructor: we also need to provide rules about docs: you break things, you doc (and unit tests), you add a feature, you doc etc.
15:26:02 <Sfiet_Konstantin> ZogG_laptop: +1
15:26:14 <Yaniel> +1
15:26:16 <tbr> 10min discussion left - 20min within this topic
15:26:17 <locusf> fk_lx: +1
15:26:29 <Sfiet_Konstantin> fk_lx: +1
15:26:36 <lbt> Sfiet_Konstantin: Anarky I suggest taking that out of this meeting to #sailfishos
15:26:39 <tbr> please consider summarizing important points and #info them so they show up in the minutes
15:26:51 <fk_lx> I mean it's also important to not double the effort (people working on the same feature parallely etc.)
15:26:53 <faenil> +1 for ZogG_laptop, there are no info about future compatibility of TOH (maybe even because Jolla doesn't know that itself in first place?) but still, that doesn't help the creation of TOHs
15:26:56 <Anarky> Sfiet_Konstantin: I tried to create an adaptation for the SabreLite; I had some difficulties to build the kernel with the default tools (like adding bc for linux 3.9+), then for the board u-boot needs to be put at a specific sector, and you can't do that with a kickstart
15:27:06 <Uninstall> hello *
15:27:34 <fk_lx> Especially parts when only one person is involved should be properly documented, otherwise we are dealing with bus/tram factor aka one-person dependency
15:27:46 <Stskeeps> this conversation is going in a good direction, some good proposals here, btw - we're listening very carefull :)
15:27:49 <Stskeeps> +y
15:27:50 <Sfiet_Konstantin> fk_lx: +2
15:28:03 <marc3> yes we are <3
15:28:10 <faenil> fk_lx, +1
15:28:11 <fk_lx> Encourage such people to spread their expertise approach
15:28:12 <Uninstall> may I ask what's the topic?
15:28:12 <MSameer> Anarky: but can't ks be fixed? I'd also say that this belongs to mer
15:28:16 <Stskeeps> i think we need to after meeting also sit down and post-parse the log of the meeting as things go very fast
15:28:20 * lbt prepares some #info in http://piratepad.net/g3jtUqh0W8
15:28:25 <ZogG_laptop> oh and about listening, it's nice to have feedback back sometimes. even if you do not agree - try to explain
15:28:32 <faenil> fk_lx, which brings us back to, we need public roadmaps for the OSS components
15:28:34 <Yaniel> Uninstall: /topic
15:28:38 <Stskeeps> Uninstall: https://lists.sailfishos.org/pipermail/devel/2014-April/003915.html , 3.1)
15:28:44 <faenil> so that people can either join and help, or find some other feature to work on
15:28:51 <Uninstall> Stskeeps: thank you
15:28:53 <Yaniel> faenil: +1
15:28:56 <dr_gogeta86> two questions
15:28:59 <faenil> ZogG_laptop, +1
15:29:02 <dr_gogeta86> armv6
15:29:11 <dr_gogeta86> and arm64bit plans
15:29:24 <faenil> dr_gogeta86, that's a bit out of topic imho :)
15:29:25 <Sage-> MSameer: ks is device specific as each adaptation (not counting x86) have their own tricks :)
15:29:27 <Sfiet_Konstantin> dr_gogeta86: this fits more to #mer I guess, maybe not in this meeting
15:29:30 <Tofe> Some information about future/next versions of base components would be useful too
15:29:31 <Stskeeps> dr_gogeta86: sailfishos is a armv7 only distro; we've been working to prepare aarch64 mer core
15:29:34 <vgrade_> Stskeeps, I'm missing some rules on what I can do as community with sfos
15:29:36 <MSameer> there are a lot of stuff marked as "roadmap" on TJC. maybe we can start with extracting them and putting them somewhere
15:29:45 <jake9xx> faenil: one things to find is the roadmaps I agree, but also the practical stuff and enablers to do real work need to be in place
15:29:46 <ZogG_laptop> just to explain myself more - communication is between two people and sometimes it feels it goes one direction and you not sure where it landed inside
15:29:52 <Stskeeps> vgrade_: yes, that'll come through hardware adaptation development kit, else there's the SailfishOS EULA
15:29:58 <lbt> tbr: should I paste from there?
15:29:58 <vgrade_> Stskeeps:from a distribution POV
15:29:59 <fk_lx> I don't see anything entirely wrong in the fact that Jolla has dominating voice, if they contribute, but should clearly inform about their future plans and explain design decissions whenever possible
15:30:08 <tbr> lbt: feel free, (didn't read though)
15:30:11 <Yaniel> +1 fk_lx
15:30:14 <Anarky> MSameer: I wrote those questions few days ago :) http://www.merproject.org/logs/%23nemomobile-porters/%23nemomobile-porters.2014-03-31.log.html
15:30:14 <fk_lx> we chose X over Y, because X is faster, better, etc.
15:30:14 <Stskeeps> dr_gogeta86: poke me after meeting for details on aarch64
15:30:14 <Sage-> MSameer: Anarky: in general that kind of adaptation specific things are always adaptation specific. But that is a bit separate issue from this and we should reserve different slot for it to discuss about.
15:30:23 <Sfiet_Konstantin> lbt: you should IMO
15:30:26 <lbt> #info Information about what packages there are and what they do is needed
15:30:32 <lbt> #info Bugzilla should be used more (!)
15:30:37 <lbt> #info Roadmaps and direction needed for MW and core packaged
15:30:41 <lbt> #info Guidance on use of systems
15:30:45 <lbt> #info Contribution flow needs to be clearer
15:30:54 <artemma> Link to end users / app developers: since TJC exists, it would be useful to use requests/complains from there for prioritizing nemo/mer work too
15:31:05 <stephg> the last 5 lines of lbt above ^ are critical for the non-coding folks here
15:31:12 <tbr> #info more clarity in community contributed hw adaptations for sailfish
15:31:15 <Anarky> Sage-: it's not only about adaptation; it's easier with yocto to add/remove some components on the distribution you want to create
15:31:23 <crevetor> I might be way off but it seems we're talking about contibuting to sailfishos but I don't recall seeing the sources anywhere. Are we talking about contributing to it through mer and nemo ?
15:31:35 <stephg> can't underestimate that, if the code contributors find it hard, it's a magnitude harder for the non
15:31:37 <Stskeeps> crevetor: yes, but contribution isn't only about code
15:31:39 <ZogG_laptop> I think as maybe TJC can be nice way to communicate, but it's not bugzilla and not roadmap and not wiki. as it's all mixed and hard to use as proper tools
15:31:42 <Sfiet_Konstantin> crevetor: yes, contributing to OSS parts (Mer Nemo)
15:31:45 <Uninstall> Anarky: I fixed that problem with Sabre and iMX related devices using a bash wrapper to mic but I think mic should be patched properly to do everything in an integrated way
15:31:46 <Stskeeps> crevetor: there's a long mailing list discussion about that topic :)
15:31:52 <faenil> How are we/you going to handle issues/bugs of OSS components? From what I understood, Jolla is not using Nemo bugzilla at the moment, and not even GitHub...is that going to change? How?
15:31:57 <crevetor> Stskeeps: Ok, I'll check that out
15:31:59 <tbr> Anarky: as much as I like both yocto and obs, I think that's not a good topic here and now
15:32:12 <Sfiet_Konstantin> faenil: +1, this need to change
15:32:15 <locusf> faenil: +1
15:32:19 <Tofe> faenil: +1
15:32:34 <Yaniel> faenil: +1
15:32:38 <fk_lx> faenil: +1
15:32:39 <iekku> Sfiet_Konstantin, maybe having again bug triages too?
15:32:43 <_Razor_> faenil: +1
15:32:48 <meetingcpp> faenil: +1
15:32:50 <Sfiet_Konstantin> fk_lx: +3 btw
15:32:50 <veskuh> MeeGo had policy of not integrating bug fixes without proper bug reference
15:32:51 * lbt would love to hear from people wanting to contribute to systems too :)
15:32:52 <Anarky> tbr: Ok, I think it should be good to talk about it in a next meeting :)
15:33:06 <Aard> faenil: this is related to the mer-merge as well. we'd prefer only moving one additional bugzilla, not two
15:33:08 <meegobit> IMHO, Like many said before, a wiki, with documentation on how the different projects and modules connect, plus a meta-repo with all that you need to get started, would go a long way, to getting more contributions and general excitment about the platform
15:33:09 <tbr> Anarky: sure, it is a valid topic
15:33:09 <Sfiet_Konstantin> iekku: please bring bug triages back yes !
15:33:10 <MSameer> as a sailor, it's really hard to use 2 bugzilla instances at the same time
15:33:12 <artemma> faenil: +1 I find it demotivating when bugs need to be reported in TJC: "broken component X" looses popularity vote to "give us free maps!" instantly
15:33:17 <MSameer> so not sure what to do here
15:33:23 <iekku> Sfiet_Konstantin, that's easy :)
15:33:29 <stezz_da_board> meegobit: +1
15:33:31 <Sage-> Anarky: well, it is same for us and one does that on .ks file. Anyway we can discuss this on other channel later.
15:33:32 <tbr> #info from faenil: How are we/you going to handle issues/bugs of OSS components? From what I understood, Jolla is not using Nemo bugzilla at the moment, and not even GitHub...is that going to change? How?
15:33:34 <Aard> faenil: plus, we'd like to enforce a policy in mer/nemo that commits need to mention bug references to public bz for tracking
15:33:54 <fk_lx> btw. I'm against project drops in to Nemo MW, without discussion and reasonable timeout like 48 hours until decision will be made (even if Jolla has deciding voice, still should be opportunity for discussion)
15:34:20 <faenil> Aard, that's good, and also, remind sailors that they're not supposed to use JB#blabla in public repos :D (you confirmed that's not supposed to happend, iirc)
15:34:21 <w00t> fk_lx: that boils back to a more generic problem of "no clear governance"
15:34:25 <lbt> I'd like to see more presence from jolla contributors in freenode irc channels
15:34:28 <deztructor> MSameer: +1 for multiply bugzillas madness
15:34:31 <Sfiet_Konstantin> #info from fk_lx: if Jolla contribute, but should clearly inform about their future plans and explain design decissions whenever possible: "we chose X over Y, because X is faster, better" etc
15:34:47 <Stskeeps> #link http://www.mail-archive.com/mer-general@lists.merproject.org/msg01426.html for context on Mer/Nemo merging, as well, to help clean up things a bit
15:34:52 <crevetor> lbt: such as (for the systems part) ?
15:34:58 <fk_lx> lbt: +1
15:34:59 <tbr> #info w00t points out the lack of governance in Mer/Nemo at the moment
15:35:06 <lbt> crevetor: no actually, for mw develoipment
15:35:14 <faenil> lbt, +1
15:35:21 <ragnarkurm2> i'm person wanting to contribute. example: found critical bug in sailfisos (cannot call) and wanted to fix it since Jolla havent fixed within 3months, but got answer from together site that this is Jolla proprietary code :( so much about my first contribution attempt
15:35:29 <lbt> and core of course, and tools and ... :)
15:35:42 <w00t> (from my personal perspective, seeing as I've personally handed out rights to all sorts of Nemo): governance started around the basics of "if you do things, you get the power to do things", based on a small group of people doing all that work, and it never really evolved or scaled up - and it probably needs to
15:35:44 <Sfiet_Konstantin> ragnarkurm2: this is not the (totally the) topic right now sorry :(
15:36:04 <Sfiet_Konstantin> w00t: it worked, but it doesn't scale
15:36:08 <tbr> Sfiet_Konstantin: well, contribution to non-oss licensed components with source available...
15:36:13 <Stskeeps> ragnarkurm2: we have a topic on this for next meeting(s), related to sailfishos and closed source to get it properly discussed
15:36:20 <veskuh> w00t, and actually there is regression since in beginning we tried to have a some docs, bugzilla, meetigns, etc.
15:36:22 <faenil> ragnarkurm2, let's focus on how to contribute to the parts which are opensource already :) or we miss the focus
15:36:22 <Stskeeps> ragnarkurm2: message me for a chat afterwards the meeting
15:36:23 <w00t> Sfiet_Konstantin: yes, we're in agreement
15:37:02 <MSameer> Stskeeps: please recap me too if you and ragnarkurm2 do not mind
15:37:04 <w00t> veskuh: yup
15:37:05 <tbr> oh, we overran, we're already in solution proposals
15:37:10 <tbr> 9min left
15:37:43 <tbr> To recap, what would people see that could help improve the current situation
15:38:02 <tbr> As we now spent some time talking about the problems, but already touched some possible ways of improvement
15:38:15 <vgrade_> +1 merging efforts
15:38:22 <fk_lx> open roadmap for each of open sourced components (Nemo MW, Sailfish Browser etc. etc.)
15:38:33 <kontio> a "How do I start to contribute" article on sailfishos.org
15:38:41 <lbt> fk_lx: that mostly comes from upstream
15:38:41 <MSameer> kontio: +1
15:38:42 <Sfiet_Konstantin> trying to follow fk_lx's ideas and w00t's, I think that features that future features that will be developed in Nemo MW should (must ?) be announced in the ML
15:38:43 <faenil> Public roadmaps, Public bugzila for public components, contribution workflow for Nemo/Mer
15:38:46 <Tofe> A way to browse the components of sailfishos, dependencies etc
15:38:47 <Sfiet_Konstantin> to haver proper discussion
15:38:47 <locusf> kontio: +1
15:38:48 <jake9xx> kontio: +1
15:38:49 <eleroux> kontio: +1
15:38:50 <tbr> #info <+kontio> a "How do I start to contribute" article on sailfishos.org
15:38:51 <skvark> kontio: +1
15:38:53 <_Razor_> kontio: +1
15:39:03 <stephg> kontio, +1
15:39:04 <faenil> kontio, +1
15:39:10 <bijjal> kontio: +1
15:39:11 <squidd> kontio: +1
15:39:11 <fk_lx> kontio: +1
15:39:12 <tbr> #info < Sfiet_Konstantin> trying to follow fk_lx's ideas and w00t's, I think that features that future features that will be developed in Nemo MW should (must ?) be announced in the ML
15:39:16 <Sfiet_Konstantin> this used to be discussions in IRC, but if we bring the discussion to ML this might affect more people
15:39:19 <Sfiet_Konstantin> kontio: +1
15:39:21 <faenil> that should be the first page, which then links to architecture and components overviews
15:39:32 <tbr> #info < fk_lx> open roadmap for each of open sourced components (Nemo MW, Sailfish Browser etc. etc.)
15:39:35 <crevetor> +1 faenil
15:39:35 <fk_lx> tbr: not onlt announced but discussed
15:39:37 <MSameer> I'd like to see the code for sailfish published somewhere instead of having to request a DVD
15:39:38 * lbt notes that sailfish.org has no public wiki .. so +1 is nice but it's not public :)
15:39:40 <Stskeeps> architectural approval of new packages (business as usual) through mailing list..
15:39:43 <M4rtinK> +1 maybe also public wishlists ?
15:39:50 <MSameer> even if it's a page with tags and links to repos
15:39:52 <tbr> fk_lx: talk to Sfiet_Konstantin I just log
15:39:53 <w00t> Stskeeps: #info
15:39:59 <Stskeeps> #info architectural approval of new packages (business as usual) through mailing list..
15:40:08 <crevetor> Public patch reviewing would be good too
15:40:09 <faenil> MSameer, good point. Kernel source still seems to be in the gray zone
15:40:09 <Sfiet_Konstantin> fk_lx: announced implies discussions (at least it encourages)
15:40:10 <meegobit> I suggest creating a meta-repo with subtree-merge of each projects repo, I've used this with great success
15:40:14 <faenil> (for example)
15:40:26 <jake9xx> get the tools and infrastructure in shape that such contribution is possible and not too hard
15:40:32 <stephg> how much work is it to improve documentation across repos even for repos without maintainers?
15:40:49 <tbr> #info < meegobit> I suggest creating a meta-repo with subtree-merge of each projects repo, I've used this with great success
15:40:51 <artemma> Jolla ppl mentioned more than once that roadmap is hardly possible for Jolla due to high agility and we don't want to decrease agility. Shall we have then clear statement of sureness for roadmap items?
15:40:57 <Sfiet_Konstantin> stephg: depending, but there are some components that requires a lot of work
15:40:59 <fk_lx> Sfiet_Konstantin: well it's a matter - "we will be using this" or "we are thinking how to solve problem X, we thought about Y, what do you think, propose alternatives"
15:41:03 <tbr> #info <+jake9xx> get the tools and infrastructure in shape that such contribution is possible and not too hard
15:41:07 <tbr> 5min left in this topic
15:41:09 <MSameer> meegobit: per sailfish os release?
15:41:10 <meegobit> the community could create our own sailfishOS community wiki
15:41:22 <jukkaeklund> open wiki to sailfish.org
15:41:33 <meegobit> MSameer: its in git, so it trakcs each module's updates
15:41:33 <ragnarkurm2> as i'm quite new in jolla - i miss mostly something like "grand map of components"
15:41:35 <locusf> jukkaeklund: +1
15:41:37 <stephg> Sfiet_Konstantin, obvs some will be worse than others but it will only get worse, thereby increasing the barrier for new folks, no?
15:41:38 <Sfiet_Konstantin> fk_lx: indeed, I thought about this, but (IMO) public posting will imply that 1. there is info about what's doing 2. complains (people might say, no X is bad, better Y)
15:41:44 <tbr> #info <+jukkaeklund> open wiki to sailfish.org
15:41:46 <MSameer> meegobit: I mean a meta repo and a tag per sailfishos release? that's a +1
15:41:51 <w00t> #info a clear path to becoming a regular contributor (& gaining rights to contribute), "governance revival", so to speak
15:41:54 <Sfiet_Konstantin> stephg: doc is mandatory IMO
15:41:58 <Yaniel> MSameer: +1
15:42:00 <Sfiet_Konstantin> will add as info
15:42:07 <stezz_da_board> jukkaeklund: +1
15:42:07 <Tofe> a wiki seems a good way to expose a mapping of components, isn't it
15:42:09 <artemma> one of the best parts of nokia developer community was/is public wiki fueled by cheapest possible incentives: title of champion of the month, a bit of free promotion and a bit of hardware. Shall Jolla borrow this idea?
15:42:12 <meegobit> MSameer: exactly
15:42:14 <fk_lx> Sfiet_Konstantin: complains are sth natural, the thing is how people deal with it
15:42:17 <MSameer> meegobit: +1 :)
15:42:21 <Sfiet_Konstantin> fk_lx: indeed
15:42:22 <Yaniel> (and thus meegobit +1)
15:42:26 <cybette> jukkaeklund: +1
15:42:28 <Stskeeps> #info links that state what repos + git tags/commits are == to what's in sailfishos build at the moment
15:42:45 <fk_lx> Sfiet_Konstantin: that's why I proposed timeout, so every discussion will end and those meritorically in power will make decision in the end
15:42:50 <stezz_da_board> artemma: ideas are good. Implementation has a cost.
15:42:53 <stezz_da_board> ;)
15:42:57 <Sfiet_Konstantin> fk_lx: timeout ?
15:42:57 <fk_lx> Sfiet_Konstantin: but at least they will hear other people opinion
15:43:02 <lbt> jukkaeklund: locusf would a discrete sailfishos.org wiki help or hinder?
15:43:02 <Uninstall> (kind of OT:  what about toolchain and package management topic? has been covered? are we going to talk about the current status of scratchbox, qemu, rpm, zypper,  mic...)
15:43:09 <Sfiet_Konstantin> fk_lx: discussion during a timerange and then decision ?
15:43:17 <Sfiet_Konstantin> fk_lx: sounds good, but for those who want an urgent fix ?
15:43:19 <fk_lx> Sfiet_Konstantin: yes
15:43:24 <lbt> jukkaeklund: from a contribution to mw PoV I mean - not apps or pure jolla stuff
15:43:28 <fk_lx> Sfiet_Konstantin: otherwise things could end as bikesheeding
15:43:35 <fk_lx> Sfiet_Konstantin: that's why time constrains
15:43:39 <Sfiet_Konstantin> fk_lx: I would (personally prefer) a continuous review
15:43:55 <Sfiet_Konstantin> like: someone brings a feature with some bit of code, and other discuss the solution
15:43:56 <locusf> lbt: define discrete?
15:44:02 <tbr> 2min left in this topic
15:44:08 <jukkaeklund> lbt, enable folks to contribute to sailfishos.org
15:44:22 <Stskeeps> Uninstall: i think we can take this one as-is through normal mer discussions, relevant people are on mailing lists, irc
15:44:27 <lbt> locusf: http://wiki.sailfishos.org vs https://wiki.merproject.org/
15:44:28 <MSameer> Uninstall: I think that is needed too but not sure if it fits now or whether tbr will mute us :)
15:44:37 <Sfiet_Konstantin> #info ask components maintainers to write architectural README, and doc if possible
15:44:43 <Uninstall> Stskeeps: ok
15:44:53 <Sfiet_Konstantin> maybe we should also have a centralized place to contribute
15:44:58 <tbr> for those who joined late: Jolla employees are voiced
15:45:03 <tbr> 1min left in this topic
15:45:03 <lbt> jukkaeklund: what is there in sailfishos that people can contribute to that is not in mer/nemo ?
15:45:11 <Stskeeps> lbt: sailfish browser :)
15:45:14 <lbt> (it's not nothing
15:45:16 <Sfiet_Konstantin> like right now mer and nemo are scattered on mer gerrit and github, should we move everything to mer gitlab for example ?
15:45:28 <lbt> but is it worth a new wiki/setup/admin...
15:45:32 <Aard> Sfiet_Konstantin: we're currently working on a graph generator for components out of obs for getting an overview, that might be useful for public use there as well once ready
15:45:34 <Yaniel> Sfiet_Konstantin: +1
15:45:34 <jukkaeklund> sailfishos is more than mer/nemo
15:45:37 <lbt> Stskeeps: also SDK
15:45:38 <Stskeeps> Sfiet_Konstantin: see http://www.mail-archive.com/mer-general@lists.merproject.org/msg01426.html
15:45:46 <tbr> I'll be closing this topic now
15:45:53 <Sfiet_Konstantin> Stskeeps: refering about this actually
15:46:07 <tbr> #topic 3.2. Solution proposal: Minimal/practical openness requirements and process for open source components in Mer/Nemo/SailfishOS
15:46:13 <tbr> 5 min intro (w00t)
15:46:13 <tbr> 15 min discussion
15:46:13 <tbr> such as dedicated/listed maintainers/owners, etc.
15:46:13 <tbr> timebox: 20 min - until 16:06
15:47:03 <tbr> w00t: just paste it
15:47:09 <w00t> you asked for it..
15:47:15 <iekku> :D
15:47:17 <tbr> everyone brace!
15:47:19 <w00t> For all intents and purposes... I'm going to be talking purely about the individual repositories containing software we are maintaining and authoring in Mer and Nemo - our core/MW efforts.
15:47:23 <w00t> We already covered some of this sort of thing earlier on, but repeating/expanding on it from my own experience working around open projects
15:47:26 <w00t> * Each project should have a maintainer with whom knowledge about that component / area is centralised
15:47:29 <w00t> * Should act as a hub for information about the area
15:47:32 <w00t> * Should be a good reference for questions about the codebase
15:47:34 <w00t> * Should be a good arbitrator for technical disputes about the component
15:47:37 <w00t> * Examples:
15:47:40 <w00t> - https://www.kernel.org/doc/linux/MAINTAINERS
15:47:42 <w00t> - http://qt-project.org/wiki/Maintainers
15:47:45 <w00t> * A good place to list maintainer information is the README
15:47:47 <w00t> * Contact information should include an email address and name
15:47:50 <w00t> * Multiple are of course permitted for larger components, mailing lists are suboptimal unless you have a huge team working on it together
15:47:53 <w00t> * Each project should have a README listing information about what it does, what it interacts with, general sort of architectural information
15:47:56 <w00t> * A README should be a good introduction to what a component does
15:47:58 <w00t> * Even for example, like “this is deprecated, use XXX instead”
15:48:01 <w00t> * A README should list major interaction points (for a simple example, “lipstick uses ngfd to present notifications” …)
15:48:04 <w00t> * But not too much detail; code is always the ultimate source of information, otherwise it becomes easily obsolete
15:48:07 <w00t> * Each project should have a "future" file (or section in README)
15:48:10 <w00t> * Explaining major direction for the component
15:48:12 <w00t> * Explaining major upcoming changes / intention in the component (“thread loading of queries to improve UI responsiveness”)
15:48:15 <w00t> * Basically explaining a wishlist of what you’d like to do - in the bigger picture - and how others can help
15:48:18 <w00t> * Not for the everyday/small items & bugs: this is just for the *big* picture
15:48:21 <w00t> * Where are we now:
15:48:24 <w00t> * We usually have an idea of who our maintainers are
15:48:26 <w00t> * But we don’t publish this information consistently, it’s usually available in ‘git log’, as a pointer in the rough direction
15:48:29 <w00t> * Should we should fix this? It will help everyone, including us (as we grow, we need to scale beyond "ask XXX" answers all the time)
15:48:32 <w00t> * We don’t work on READMEs very well or consistently
15:48:35 <w00t> * Should we should fix this?
15:48:37 <w00t> * We don’t write down wishlist information at all in a consistent way
15:48:40 <w00t> * Should we?
15:48:43 <w00t> * It’s beneficial for everyone, including us, less bus-factor
15:48:59 <tbr> thanks, for the exhaustive overview
15:49:12 <tbr> anything non-paste to add, w00t?
15:49:35 <w00t> nope. that's a basic brain-dump of what individual components need imnsho, and rough ideas of why
15:49:39 <tbr> ok, floor for discussion is open!
15:49:39 <w00t> I'll work on pastebinning and #infoing
15:50:06 <tbr> #info overview http://etherpad.dereferenced.net/p/SOSSPrep
15:50:15 <w00t> #info more permanent link: http://pastebin.com/zX1WUaY6
15:50:16 <tbr> just to have that sort of out of the way
15:50:20 <tbr> great!
15:50:33 <fk_lx> w00t: where do you see place for discussion about each component? if we start talking about all on mer-general it might get a mess
15:50:39 <MSameer> so is there a way to add the info for the maintainers to github/gitlab instead of having to edit the readme?
15:50:48 <lbt> I think we need a reasonably standard way to record this stuff per project
15:51:01 <lbt> that way it can be retrieved and presented
15:51:11 <Sfiet_Konstantin> MSameer: not really for this, README sounds more solid
15:51:12 <fk_lx> w00t: but I would see some announcements on mailing list from time to time about where each component features go, also some small changelog
15:51:13 <tbr> for everyone who joined late: Sailors / Jolla Employees are voiced
15:51:14 <lbt> it can also be analysed for "oops, no roadmap for"...
15:51:15 <Sage-> does gitlab provide discussion feature per git tree?
15:51:15 <kontio> from a QA pov it's good to have a name behind a project, so I know there is somebody which feels responsible
15:51:20 <Yaniel> regarding maintainers and git log, I repeat my idea from #jollamobile of having some autogenerated lists of the last N committers or committers in the last M days
15:51:22 <Sfiet_Konstantin> if you clone the code, you get the readme, but not the metadata from github/lab
15:51:47 <w00t> fk_lx: my own preferences are to start small (e.g. mer-general) and split off as volume dictates (mer-mw, mer-core, mer-connectivity?). for many components, there aren't a lot of people working on them. let's hear what others think :)
15:51:55 <kontio> I'd wish also that a package maintainer for packages coming from upstream is a liaison engineer between sailfish os and upstream
15:52:03 <Sfiet_Konstantin> w00t: +1
15:52:04 <tbr> for those who joined late and want to participate in the discussion, please consider introducing yourself with a line starting "#info"
15:52:07 <lbt> kontio: yep
15:52:09 <w00t> kontio: good point, I missed that one
15:52:10 <fk_lx> w00t: +1
15:52:20 <stephg> fk_lx, volume not a function of change?
15:52:36 <lbt> w00t: this metadata is 'ours' isn't it
15:52:41 <kontio> a maintainer should also follow the upstream security issues (e.g. mailing lists...)
15:52:48 <lbt> ie it's nemo/mer data, not upstream
15:53:08 <Yaniel> kontio: +1
15:53:11 <w00t> lbt: it's a bit of a mix, as sailfish contains a lot of sailfish-developed software
15:53:31 <w00t> when I wrote that I was specifically thinking about software we develop to then put into mer/nemo/SF
15:54:01 <lbt> I'm just thinking that we are the consumers/producers - not upstream - so that's OK
15:54:28 <meegobit> w00t: +1
15:54:39 <lbt> essentially thinking ahead to a way to record, track and present
15:54:59 <artemma> Is there any significant difference between components levels (in quality, maintainer skills, documentation)? So some cross-maintainers forum to improve these
15:55:07 <fk_lx> I even think that in future instead of doing one big meetings, some small regarding certain components could be done, kind of once per month or more frequent depending how certain component is developing lately
15:55:12 <tbr> kontio: a separate topic is automatic CVE tracking on Mer/Nemo level. Such things exist, but would need to be evaluated
15:55:17 <faenil> I think the "should" section of w00t's intro basically has almost all we need in the ideal world
15:55:20 * artemma recalls one component with quite poor testability
15:55:28 <kontio> tbr: +1
15:55:36 <stephg> artemma, +1
15:55:39 <Sfiet_Konstantin> faenil: +1
15:55:39 <Uninstall> CVE tracking is something we really need
15:55:46 <w00t> faenil: surely I'm missing something :-)
15:55:48 <dr_gogeta86> +1
15:55:49 <squidd> faenil: +1
15:55:50 <meegobit> #info meego lover, sailfishOS developper in the making :) (after few years of Android experience)
15:56:11 <Uninstall> by the w
15:56:24 <Uninstall> by the way we don't have any complete list of open CVEs
15:56:26 <MSameer> meegobit: \o/
15:57:07 <sledges> how does a bad maintainer get punished/replaced?
15:57:09 <tbr> Looking at the above it seems like striking the balance between package level and project level (mer/nemo/sailfish) will be a challenge
15:57:19 <Stskeeps> sledges: governance processes of the open source project in question
15:57:25 <w00t> tbr: I think they're seperate (but somewhat parallel) topics
15:57:37 <fk_lx> yes I also agree with faenil that if what w00t wrote in info will be implemented at some point, it will be very good for collaborating
15:57:37 <tbr> *nod*
15:57:41 <w00t> we need project governance & development, but individual components also have that need
15:58:05 <w00t> (speaking of the ones we're upstream for, here)
15:58:17 <artemma> maybe how does bad maintainer get help / is advised?
15:59:10 <lbt> sledges: we get them to work with Aard for a while
15:59:11 <sledges> that's the first stage, much like IRC_Guidelines ;) that's why we truly need governance definitions
15:59:13 <stezz_da_board> sledges: I have whips at home
15:59:18 <faenil> I also think this is a quite urgent matter, so it would be good to see Jolla prioritizing the documentation/roadmap/wiki stuff, i.e. Sailors should not be forced to do that after they worked 14h on Sailfish...it should be part of their day job instead of working of (for example) working on new features for the next fw
15:59:31 <faenil> of working on*
15:59:44 <artemma> There are very skilled people in the community and if some component is failing behind, help/consultancy could be provided. In needed cases even by jolla-salaried people
15:59:47 <stephg> faenil +1
15:59:49 <MSameer> faenil: come on! no body works for 14h :p
15:59:58 <w00t> MSameer: 24 hours or bust, right? :p
16:00:02 <Sfiet_Konstantin> faenil: +1
16:00:05 <artemma> faenil: +1
16:00:12 <Stskeeps> artemma: i think roadmaps could help a lot to also show where we're 'weak'
16:00:13 <tbr> MSameer: phaeron seems to exceed magically 24h quite often...
16:00:15 <Yaniel> faenil: +1
16:00:18 <tbr> at least that's my feeling
16:00:22 <Yaniel> Stskeeps: +1
16:00:23 <squidd> faenil: +1
16:00:38 <lbt> I'm not that convinced about roadmaps
16:00:40 <w00t> I think that this sort of topic is kind of akin to gardening... you don't pay attention to it for a long time, you get weeds growing, and then you need to get the edge trimmer out and clear the weeds and tidy the garden^WREADME
16:00:42 <artemma> roadmap + some sort of dashboard with quality/docs/stability/test levels?
16:00:42 <fk_lx> faenil: +1, it will bring benefits in long run
16:00:44 <Tofe> Stskeeps: +1
16:00:51 <lbt> they typically have a list of TODO items
16:00:57 <meegobit> some kind of agile development graphics
16:01:02 <stezz_da_board> tbr let's treat phaeron as a special case ok?
16:01:03 <tbr> 5min left in this topic
16:01:08 <stephg> Stskeeps which 'we'?  (not sniping, for clarification)
16:01:20 <lbt> what's the purpose of a ROADMAP ?
16:01:23 <Stskeeps> stephg: voice indicates 'jolla' :)
16:01:31 <sledges> nice to see we pulled two aspects from last topic here: governance, and sailors' presence in public wanted
16:01:44 <w00t> lbt: depends if we're talking project level or component level
16:01:46 <Sfiet_Konstantin> sledges: it is quite linked
16:01:50 <lbt> w00t: component
16:01:58 <w00t> lbt: then a ROADMAP is pretty much a TODO, yes
16:02:01 <lbt> project is usually a little more coherent
16:02:10 <lbt> w00t: vs say BZ entries...
16:02:16 <w00t> that's why I deliberately renamed it at the last minute to not call it a "roadmap" but a "wishlist" :-)
16:02:25 <tbr> please start #info-ing
16:02:30 <artemma> For final app developer ROADMAP is needed for, well, cool app development (hence time-to-sailfish release is most important)
16:02:38 <Aard> lbt: do we have something like autodoc infrastructure for mer somewhere? if not, we might want to do that
16:02:48 <lbt> w00t: so I'm kinda wondering if roadmap should be structured
16:03:05 <deztructor> Aard +1
16:03:08 <veskuh> lbt, w00t I wouldn't commit to too detailed roadmap
16:03:15 <w00t> #info README/doc gardening is an important thing; attention to it should be paid at the same level as developing (obviously, it doesn't require as much effort, it just needs conscious attention to improve)
16:03:15 <tbr> #info could autodoc help here, lbt and aard bring up this topic
16:03:16 <fk_lx> lbt: any roadmap is better that none ;)
16:03:28 <lbt> Aard: I think I left that in meego - didn't quite have the use in Mer when we stripped the docs packages :)
16:03:45 <artemma> fk_lx: +1
16:03:46 * Aard always thought stripping docs packages was a pretty stupid idea :p
16:03:51 <lbt> hehe
16:04:11 <w00t> #info CVE tracking in components is important, and lacking
16:04:11 <Yaniel> fk_lx: +1
16:04:11 <MSameer> it's impossible to have perfect roadmaps so perhaps we first make it run then make it run better
16:04:12 <tbr> 2min left in this topic
16:04:13 <M4rtinK> Aard: +1
16:04:19 <lbt> veskuh: I think my point is that maybe bz would be a better solution
16:04:22 <MSameer> and we have weekly meetings
16:04:24 <meegobit> for someone arriving from Android, we'd look for some page which is visually appealing, easy to understand, with the relevant developper-work-flows exposed
16:04:36 <Yaniel> meegobit: +1
16:04:40 <tbr> #info CVE tracking on mer/nemo/sailfish level should be considered/automated
16:04:42 <Sfiet_Konstantin> meegobit: +1
16:04:43 <dr_gogeta86> meegobit: think who arrive from ios
16:04:50 <meegobit> also
16:04:53 <lbt> Aard: I think the time has come to see how we could restore some doc packages - but you volunteer to maintain gtk - ok?
16:04:53 <meegobit> :)
16:04:55 <dr_gogeta86> especially they
16:04:56 <veskuh> lbt, well I'd like to see higher level items "Qt 5.x" as roadmap item instead of bug.
16:04:57 <Aard> I'd like to have two things: one autodoc-infra containing doc results for stuff as it builds in mer obs, and one (maybe on the same server, or in sailfishos namespace) with the docs built for each sailfishos release
16:05:02 <w00t> #info TODO/ROADMAP information shouldn't be too granular, otherwise it risks becoming outdated easily or plain useless
16:05:06 <tbr> #info < meegobit> for someone arriving from Android, we'd look for some page which is visually appealing, easy to understand, with the relevant developper-work-flows exposed
16:05:22 <lbt> veskuh: yeah - package group roadmap also makes a lot of sense
16:05:23 <w00t> (... I think that's all my important observations, others feel free to #info also)
16:05:23 <Aard> lbt: let's first publish the stuff we have, and then improve
16:05:25 <tbr> 1min left in this topic
16:05:27 <sledges> #info what-is-a-good-mainteiner - extra responsibilities, needed to be conveyed nicely chiefs of projects (so we have best yield in maintainers-volunteers)
16:05:44 <fk_lx> How to become maintainer/contributor? :P
16:05:51 <fk_lx> kind of HOWTO
16:05:51 <dr_gogeta86> +1
16:05:53 <tbr> closing in 10s
16:05:53 <MSameer> sledges: and the process of replacing a bad maintainer too
16:05:54 <w00t> #info governance is, once again, a weak point
16:06:01 <lbt> w00t: so I'm going to propose we remove ROADMAP :)
16:06:02 <tbr> I just received this PSA: The mom of little Aard is waiting for him at the checkout counters. *krzrzt*
16:06:05 <tbr> #topic 3.3 Action proposal: Participation and contribution policy for Jolla's open source contributors in open source projects
16:06:06 <stephg> MSameer, be careful woth that
16:06:07 <Yaniel> and how/where maintainers can ask for help with their tasks
16:06:14 <tbr> 5 min intro (Stskeeps)
16:06:14 <tbr> 15 min discussion
16:06:14 <tbr> timebox: 20 min - until 16:26
16:06:18 * artemma liked this BB10 roadmap format a lot and found it useful (for the consolidated final roadmap, not per small component):  - http://pic.twitter.com/4V6BWDqgpa
16:06:24 <lbt> tbr: for some future meeting can we have "roadmap : todo file or BZ" as a topic
16:06:34 <faenil> a bit OT, regarding roadmaps about closed components, BB10-like roadmaps would be cool to have https://developer.blackberry.com/html5/download/roadmap/
16:06:41 <Stskeeps> okay, if you'll give me a moment .. :)
16:06:41 <faenil> wow, artemma you anticipated me :p
16:06:50 <Stskeeps> this will be short, i think we can take other things in wrap-up
16:06:59 <tbr> ok
16:07:04 <Stskeeps> #info One thing that has been brought up is the perceived attitude of Jolla's open source contributors and a bit unclearity of our intentions in open source - marketing vs factual action in open source.
16:07:09 <Stskeeps> #info To show we mean business in open source project participation, today we have published our participation and contribution policy for Jolla's open source contributors in open source projects at
16:07:14 <Stskeeps> #link https://together.jolla.com/question/39552/what-is-the-participation-and-contribution-policy-for-jollas-open-source-contributors-in-open-source-projects/
16:07:17 <Stskeeps> (recommended reading)
16:07:24 <Stskeeps> #info It's meant as both an internal policy and something for community members and participants of open source projects to better understand how to deal with Jolla employees, their actions, statements, etc. where they're encountered, in and outside official communication channels.
16:07:31 <Stskeeps> #info This will of course also affect many other topics that we have discussed today - and drive the adoption of good open development. It aligns very much with the values of Jolla to do so.
16:08:14 <Stskeeps> .. and that's it  -- i'm not sure how much discussion is really needed for this, but it might be good to include some time into wrap-up
16:08:29 <Stskeeps> as there's many good ideas
16:08:32 <Stskeeps> (done)
16:08:35 <Bundyo> Also good: http://status.modern.ie
16:08:42 <fk_lx> I think the proposal is very good
16:08:43 <sledges> (tjc experiences DoS atm)
16:08:43 <w00t> (hooray :))
16:08:46 <tbr> I'd like to see some feedback from people on this
16:08:50 <fk_lx> I have one question regarding that
16:08:53 <artemma> Jolla in general isn't very public about what's coming (including good reasons like not actually knowing whats coming too). But that seems to be changing right now
16:09:06 <tbr> we can then segway into wrap-up/meta/aob
16:09:16 <Sfiet_Konstantin> I hope that this will change in a long term
16:09:41 <fk_lx> in source files we can find section contact: name@jollamobile.com
16:09:53 <fk_lx> is that official way of communicating or not?
16:10:13 * artemma finds it frustrating when things change without warning. Such as harbour fields supposed to be shown to testers only were suddenly visible to everybody
16:10:14 <iekku> depends on content i assume
16:10:35 <artemma> same about suddenly more strict checker script
16:10:37 <tbr> artemma: not the topic right now
16:10:50 <meegobit> In terms of what's lacking from Jolla's part I think IMHO is mostly APIs, people want to contribute, but they can't
16:10:54 <MSameer> fk_lx: not always (at least I used to maintain something but my address is still in the contacts)
16:11:01 <Yaniel> meegobit: +1
16:11:07 <iekku> we have developer-care at jolla.com and i try to address questions to correct sailor
16:11:08 <jake9xx> fk_lx: you know on some components those might not be up-to-date. I'd use the (semi)official maintainer's contact for queries like that
16:11:09 <Yaniel> we need APIs documented
16:11:14 <goroboro> meegobit: documented apis
16:11:16 <tbr> if there isn't more on the policy topic. I'll be opening for wrap up
16:11:20 <MSameer> meegobit: +100
16:11:21 <fk_lx> iekku: assuming content is related to the source file contents
16:11:25 <Aard> meegobit: this is being worked on
16:11:32 <meegobit> Aard: +1
16:11:44 <Stskeeps> as a general thing, it's better in open source projects, to participate and doing it using the mailing lists so everybody can participate in the discussions related
16:11:46 <MSameer> fk_lx: I'd trust the last few commits
16:11:53 <lbt> tbr: I think artemma has something ... there's a problem hacking on jolla devices and that stops people building on their baby steps
16:11:55 <iekku> Stskeeps, +1
16:11:57 <Stskeeps> in meego, we had times where there was humongous cc: lines
16:11:57 <cybette> Stskeeps: +1
16:11:59 <Aard> meegobit: one problem is that currently there's no way to specify that your package runs on only a specific version of sailfish when you import it, which is a problem for introducing new apis. this will change
16:12:02 <tbr> #topic 3.4 Wrap-up and finalizing action points
16:12:17 <fk_lx> Stskeeps: then why not removing employees e-mails and putting mailing list address in source file?
16:12:18 <meegobit> Stskeeps: I prefer the ask.dot together type to mailing list
16:12:22 <deztructor> to document something there should be a need/request from other parties to increase the priority of api documenting, so there should be a will to contribute to the specific project
16:12:28 <tbr> we're lucky as the previous topic was a bit faster. we have about 15min for wrapping up
16:12:28 <lbt> opensource on a device is kinda about making tiny little changes first - and I think they're hard to share
16:12:29 <fk_lx> especially if some claim it's outdated
16:12:42 <jake9xx> Stskeeps: the kernel mailing list has good practises for this, I don't see why we could not follow on that
16:12:59 <Stskeeps> fk_lx: that is a valid point - some claim that the e-mails on source file causes ownership perceptions
16:13:04 <meegobit> goroboro: +1
16:13:04 <Stskeeps> some projects discourage them because of that
16:13:19 <w00t> it also depends on the project, though
16:13:21 <Stskeeps> anyway, i sense tbr has switched topic
16:13:27 <w00t> (some have conventions of including them)
16:13:27 <fk_lx> I've seen some good google video about the problem
16:13:29 <artemma> My topic may  be a bit too off for this meeting.. I want all these cool mer/nemo development be pulled to final app side and a lot of stuff gets blocked at sailfish level without clear solution. E.g. permissions. Shall some of these things be pulled into nemo for public discussion/solutions?
16:13:39 <tbr> Stskeeps: well generally open floor now
16:13:42 <Stskeeps> nod
16:13:46 <fk_lx> Solution: Encourage people to not put their names on top of source files
16:13:47 <tbr> we should at least agree the next meeting
16:13:54 <fk_lx> There is a feeling everybody owns everything - and that's a good practice
16:14:00 <tbr> as we said weekly that would be next tuesday
16:14:05 <artemma> fk_lx: +1
16:14:11 <fk_lx> that was the summary of the video
16:14:15 <MSameer> artemma: those are _harbour_ restrictions not sailfish os restrictions
16:14:18 <tbr> are there significant reasons not to have it at 1500UTC?
16:14:29 <fk_lx> #link https://www.youtube.com/watch?v=ZSFDm3UYkeE
16:14:30 <tbr> I'd prefer to defer the time slot discussion for now
16:14:39 <MSameer> artemma: sailfish does not prevent you from adding permissions via an RPM scriptlet but it will be rejected from harbour
16:14:45 <w00t> yeah, let's not. cat herding and all that ;)
16:14:47 <deztructor> tbr: aussies?
16:14:55 <Tofe> tbr: next tuesday then
16:14:58 <Stskeeps> let's try 15 UTC as a start, then rotate as discussion goes, for next week?
16:15:02 <faenil> deztructor, I think you're seeing it the other way around, you're not doing a favour to the community, you're doing a favour to yourself. There's the chance that you'll never know how many people really want to contribute, because they'll just see there's a lack of documentation, and leave
16:15:05 <artemma> MSameer: question is shall some of these restrictions be pulled to nemo? Pure nemo doesn't care abt permissions, but any sensible final device (jolla or not) needs permissions
16:15:19 <iekku> tbr, our overseas sailors and community members?
16:15:22 <tbr> deztructor: please bring this topic up with lpotter and the other people from oz
16:15:33 <tbr> I'd prefer to fix a time now
16:15:33 <Aard> artemma: those issues are for 3rd party apps, not for packages integrated into the distribution itself
16:15:34 <dr_gogeta86> about permissions
16:15:43 <MSameer> artemma: i personally hope not but that proposal should be sent to nemo/mer ML
16:15:50 <tbr> and I don't see how we'll be able to agree on a new time within the precious last 15min
16:15:56 <Stskeeps> :nod:
16:15:57 <artemma> ok
16:16:07 <tbr> so I'd rather see that discusson for the following meeting handled on e.g. the mailing list
16:16:08 <Stskeeps> tbr: makes sense
16:16:16 <meegobit> Another thing about Jolla's updates: (I think they're evolving in this positive direction) I wish more of the changes evolved in the option creation or exposing, instead of simply changing things
16:16:19 <lbt> tbr: jfdi with "same time next week" for now :)
16:16:44 <Yaniel> +1 for same time next week, discuss other timeslots on the ML
16:16:49 <tbr> #agreed Next meeting 2014-04-22T15:00 UTC
16:17:13 <deztructor> faenil: no, this is not about favour but about priorities: if you have a pile of tasks but nobody is showing interest in contribution you'd better to do stuff instead of maintaining documentation. This is just a pragmatism :)
16:17:15 <tbr> #info discussion about time slot for the meetings that will follow to be held on the sailfish-dev mailing list
16:17:15 <MSameer> 22 might be a bit short considering easter
16:17:17 <Stskeeps> i think that we should probably publish the meeting logs (happen automatically), parse through on mailing list, get factual proposals set up and actions -- i can take an action to collect these
16:17:34 <faenil> deztructor, egg and chicken problem...
16:17:40 <tbr> MSameer: didn't you suggest weekly too? :)
16:17:48 <jake9xx> deztructor: +1
16:17:51 <Aard> Stskeeps: don't expect anything happening on actions until next meeting due to easter
16:17:56 <Yaniel> I suggest JollaHQ tweets a link to the minutes as well
16:17:58 <MSameer> tbr: I did so but this is a short week :p
16:17:59 <artemma> egg is never a problem for easter :)
16:18:02 <tbr> Aard: that's correct
16:18:04 <faenil> deztructor, and my view on that is: if you want to see interest, you first have to build the documentation
16:18:17 <deztructor> tbr: to fix the time we need .au people to be presented. maybe time will be discussed today and sent in mailing list?
16:18:20 <tbr> #info next meeting will not be about following up on actions but remaining topics
16:18:21 <w00t> deztructor: it's also not just about contribution from other people
16:18:25 <stephg> faenil, +1
16:18:29 <MSameer> tbr: +1
16:18:30 <Stskeeps> tbr: +1
16:18:32 <tbr> deztructor: see my info
16:18:34 <jake9xx> faenil: let's keep to the topic
16:18:47 <faenil> jake9xx, the topic is "wrapping up" :D
16:18:51 <tbr> time to be agreed on ml for the future
16:18:53 <cybette> Yaniel: i'll do that
16:19:01 <w00t> deztructor: it's about your own capability to remember and understand, and reducing bus factor -- if you get hit by a bus tomorrow, reasonable documentation of the outstanding situation/project means that someone else can (with some ease) carry it on
16:19:09 <artemma> not compiling docs at sailfishos wiki are a shame, yes
16:19:22 <artemma> I mean examples in docs with mistakes
16:19:25 <Yaniel> (others can do that as well ofc but I'd like to see it on the official twitter feed since it is somewhat "official")
16:19:26 <w00t> (or, if you want a little less violence -- if you were to go on holiday)
16:19:41 <jake9xx> artemma: do you refer to the firstName thingy? Waiting for a website push :)
16:19:43 <fk_lx> w00t: or switch to working at Microsoft ;)
16:19:53 <w00t> fk_lx: I said _less_ violence :-)
16:19:58 <iekku> :D
16:19:59 <tbr> should we quickly agree next topics?
16:19:59 <fk_lx> w00t: :)
16:20:09 <iekku> tbr, yes please
16:20:09 <lbt> tbr: quickly?
16:20:15 <artemma> jake9xx: to many mistakes silica docs :)
16:20:19 <iekku> lbt, 10 minutes left
16:20:20 <artemma> like many
16:20:25 <tbr> Stskeeps / lbt - "extras thingy" next week?
16:20:31 <fk_lx> wikifying silica docs ;)
16:20:43 <fk_lx> I mean moderated wiki would be ok
16:20:49 <jake9xx> artemma: if they were posted to tjc -> they are on my list as of today actually
16:20:50 <tbr> I'm asking sailors as it will need people like stezz_da_board and marc3 too
16:20:52 <deztructor> faenil: w00t :nod: I am just reflecting a real life. Documentation is important but interest also should be shown from the community side in some way to push maintainers to improve documentation.
16:20:53 <fk_lx> (moderated by Jolla)
16:20:54 <artemma> I'd submit silica docs patches as I stumble into that a lot, but there's no way yet
16:20:55 <lbt> artemma: yes - contributions to silica docs should go to the #info for an earlier topic
16:20:56 <Stskeeps> tbr: yes, i had also noted 'Closed bits of SailfishOS - why/where/how and relation to open source parts' ' Plans on SailfishOS for Android'
16:21:09 <tbr> ok, should we focus on those two?
16:21:19 <faenil> deztructor, you only "improve" something which is already there :D
16:21:31 <Tofe> tbr: contributing to sailfishos closed parts would be great
16:21:37 <MSameer> fk_lx: or the ability to add comments like Qt docs
16:21:48 <fk_lx> btw. any comments from stezz_da_board and marc3 about today's discussion? they seemed quite quiet (like ZogG_laptop)
16:21:48 <Yaniel> API documentation for both closed and opensource apis, app permissions
16:21:52 <faenil> fk_lx, moderated wiki for Silica is a good idea imho
16:22:03 <tbr> #agreed next meeting agenda will be: community open source package repository (think maemo extras) and Closed bits of SailfishOS - why/where/how and relation to open source parts, and Plans on SailfishOS for Android
16:22:13 <fk_lx> tbr: +1
16:22:17 <tbr> ok, we have 8min left
16:22:19 <Sfiet_Konstantin> tbr: +1
16:22:19 <artemma> Why are silica controls not fully open? They are like 95% open, but not fully. Just lack of time and will?
16:22:21 <Tofe> +1
16:22:24 <deztructor> faenil: this is also the reason why there should be high level docs describing the role of different components - to find the target
16:22:27 <tbr> do we need to take actions from this meeting?
16:22:33 <tbr> do we have actions for jolla?
16:22:39 <faenil> deztructor, agree
16:22:41 <tbr> there was a lot said
16:22:59 <Yaniel> artemma: +1
16:23:04 <faenil> fk_lx, +1
16:23:08 <fk_lx> tbr: w00t slowly applying what he proposed ;)
16:23:22 <artemma> Fully open silica controls would make them portable to e.g. Android. I personally would try creating just an android app with silica inside. Could work okay
16:23:39 <tbr> I guess we'll need to resolve to following up the meeting minutes with some discussion on the sailfish-dev mailing list anyway
16:23:50 <w00t> fk_lx: hey, I wrote a README and API documentation for something yesterday... :-)
16:23:52 <lbt> artemma: I think those items should go onto next meeting topics
16:23:56 <artemma> ok
16:24:03 <fk_lx> w00t: <3
16:24:10 <lbt> so they have time to be discussed properly I mean :)
16:24:11 <Sfiet_Konstantin> :)
16:24:12 * fk_lx hugs w00t
16:24:17 <tbr> #info meeting minutes will be posted to the sailfish-dev mailing list, follow up discussion there
16:24:18 <Stskeeps> artemma: long story short, they're currently closed source; we can take up that discussion at the next meeting
16:24:50 <tbr> #info we need a chair for the next meeting, as tbr will NOT be available as chair for that one for topic discussion reasons
16:24:50 <Stskeeps> in the topic for that
16:24:51 <dr_gogeta86> I've asked
16:24:51 <artemma> Stskeeps: check BSD license note in Silica QML files and these controls are 90-95% QML :)
16:24:55 <Tofe> Stskeeps: very short indeed :)
16:24:56 <deztructor> tbr: maybe jolla actions should be the same as community ones: high level arch docs first
16:25:02 <MSameer> Stskeeps: how about lipstick? community have extracted the QML bits already and patched them
16:25:25 <dr_gogeta86> many developers and artwork maker ... lipstick not suit very well with porting exsisting apps
16:25:29 <tbr> MSameer: I think that's the topic for next week?
16:25:38 <dr_gogeta86> ( made for ios and android )
16:25:47 <Sfiet_Konstantin> MSameer: well, QML is rather hard to protect
16:25:49 <cybette> tbr: I can chair, if nobody has a problem with that
16:25:57 <MSameer> tbr: I am wearing both hats now so hard for me to propose :)
16:25:58 <tbr> +1 for cybette
16:26:04 <Sfiet_Konstantin> so, even if it's not OSS, it's hard to protect
16:26:07 <iekku> +1 for cybette
16:26:13 <fk_lx> +1 cybette
16:26:15 <sledges> +1 cybette
16:26:16 <artemma> protection and license are different stuff
16:26:17 <locusf> +1 cybette
16:26:19 <faenil> Sfiet_Konstantin, I was about to write that :P but deleted it afterwards :D
16:26:40 <Yaniel> +1 cybette
16:26:40 <MSameer> Sfiet_Konstantin: and we already knew that
16:26:47 <tbr> looks like both community and sailors agree on that one, let's fix it swiftly
16:26:54 <tbr> #agreed cybette chairs next weeks meeting
16:27:18 <Sfiet_Konstantin> so IMO, even if the QML can be extracted, Jolla do not need (IMO) to release it as OSS
16:27:24 * artemma believes anyone would be fully in the legal to take Silica QMLs that are under BSD and just add Theme and maybe few other bits to these
16:27:27 <M4rtinK> I currently use a translation layer so that my code work with both Silica nad plain Controls
16:27:27 <tbr> 3min to go, time for closing words :)
16:27:45 <stezz_da_board> thanks everybody!
16:27:50 <Tofe> Sfiet_Konstantin: no, but why not, that'll be a good question for next week
16:27:55 <marc3> indeed, thank you all for the great stuff
16:27:56 <M4rtinK> if Silica was fully open I would not need to do that
16:27:58 <stezz_da_board> that was quite a good meeting
16:27:59 <tbr> as the chair I'd like everyone for showing up and also for the civil discussion, this made my job easy
16:28:01 <Sfiet_Konstantin> artemma: I think that there are a lot of stuff, like the shaders etc.
16:28:01 <M4rtinK> and others too
16:28:06 <marc3> we know there is a lot to do
16:28:07 <tbr> +thank
16:28:09 <fk_lx> stezz_da_board, marc3: thank you for appearing
16:28:15 <w00t> thanks for a useful and productive discussion, and thanks tbr for some good application of timeboxing ;)
16:28:18 <artemma> M4rtinK: talk to you later, interesting
16:28:24 <stezz_da_board> fk_lx: we didn't appear
16:28:25 <jukkaeklund> thanks tbr!
16:28:25 <marc3> fk_lx: <3
16:28:28 <stezz_da_board> we stayed here
16:28:34 <tbr> :D
16:28:35 <artemma> thanks all and tbr!
16:28:39 <cybette> a good start certainly, thanks and look forward to things improving
16:28:40 <Sfiet_Konstantin> thx tbr :)
16:28:41 <fk_lx> stezz_da_board: :)
16:28:43 <Tofe> thanks jolla for this meeting!
16:28:48 <marc3> tbr: <3 thank you for chairing
16:28:48 <Stskeeps> thanks all
16:28:49 <iekku> tbr, thank you for hosting
16:28:51 <lbt> lots of good stuff - lots to read :)
16:28:54 * tbr looks forward to more meetings of this kind
16:28:55 <_Razor_> Thank you!
16:28:57 <iekku> everyone, thank you for joining <3
16:28:58 <MSameer> tbr: you did  a great job even though I felt like running in the beginning :)
16:28:58 <Sage-> thank you all for the good discussion
16:29:04 <fk_lx> tbr: +1
16:29:09 <lbt> tbr : so corrections to the ML ?
16:29:16 <sledges> thank you and let the OSS flag fly, will require lots from board and from each sailor and community member - individually and cooperatively \o/
16:29:20 <tbr> lbt: you still have 30s ;)
16:29:22 <lbt> eg missing or extra #info etc
16:29:24 <Sfiet_Konstantin> sledges: +1
16:29:28 <tbr> but yeah, I'll be posting there
16:29:30 <deztructor> good refresh :) thank you all!
16:29:32 <cybette> sledges: well said +1
16:29:36 <Tofe> I definitely should subscribe the ML...
16:29:41 <fk_lx> sledges: +1
16:29:42 <lbt> #info from artemma: contributions to silica docs should go to the #info for an earlier topic
16:30:09 <tbr> #endmeeting