=== chihchun is now known as chihchun_afk [05:26] hola [11:07] aquarius: enjoyed that session about UCS last night [11:08] popey, me too, although I was surprised to discover that nik90 and I actually have different goals for it, because I want PyPI/npm/github and he wants a curated store of excellence :) [11:10] am currently wondering whether there is value in working on the ucs tool and having, essentially, "main" (what nik90 wants; components must be brilliant and will end up in the SDK; add by merging to the core branch; all component authors must be highly trusted) and "universe" (anyone can add; provide a link to a remote location; onus is more on the developer to know what to use) [11:11] That makes sense to me. [11:12] aquarius, popey good morning [11:12] it will unavoidably make the developer experience slightly more complicated than nik90 currently has, because you now have to specify whether you want main or not (I would not like universe to be completely invisible unless you know about it, otherwise it'll never get used, and eventually everyone agrees that it's the default) [11:12] nik90, heya! [11:15] aquarius: when we talked yesterday about the requirements of components, it included a set of documentation, test cases and stable api that cannot be guaranteed by every 3rd party component out there [11:16] Hence my proposal that there is "main", which needs those things, and "universe", where those things are a good idea but aren't *required* and which components are good is discovered by market forces, like npm or pypi or the click store or google play :) [11:16] But I kind of like the idea of main and universe [11:17] obviously, having good documentation and test cases and a stable API makes your component more attractive [11:18] I'd rather everything was in universe until it was good enough for main [11:18] then if its so good in main it might go to sdk [11:21] new proposal, too: components with a slash in their name are in universe [11:21] and the names are user/component [11:21] so I make sil/mycomponent [11:21] and that's in universe [11:21] if it gets good enough to reach main, and I want it to go into main, then it becomes "mycomponent" [11:22] and then eventually it hits the SDK [11:22] +1 [11:22] so does the component-store store the metadata of the components in universe? [11:22] so we can tell people: don' t use stuff with a slash in its name if what you want is basically SDK 2.0 [11:22] yep, the component store stores the metadata [11:22] but not the components themselves [11:23] and ucs looks in *two* places, depending on whether you want main or universe components [11:24] what about the documentation for these components in universe? One of the benefits of being in the "main" is that it allows for documentation to live in a central place with good formatting. [11:24] (that is: the universe server doesn't have the details of main components in it, so that if universe dies or goes away, main keeps working) [11:24] or perhaps we don't impose that requirement on components in universe? [11:24] documentation for a universe component is up to its author [11:24] ack. [11:25] pretty much everything in npm is in github and the readme is the documentation (or they have a readthedocs site etc) [11:28] aquarius: can you draw a flowchart of how the structure of the universe would be? As in the metadata, uploading it to the store, server etc..and I can help with some of the individual bits. [11:32] I can [11:32] it's all abundantly clear in my head :) [11:33] now make it clearer for all of us so that we can help you :) [11:34] aquarius: btw the ucs script atm is just a bash script which does its job, do we need to convert it into python? [11:34] it needs to not be bash [11:34] https://bazaar.launchpad.net/~ubuntu-touch-community-dev/component-store/trunk.14.10/view/head:/script/ucs [11:34] I personally would make it be python [11:34] since that's well-supported on Ubuntu [11:34] ok, I will look into converting it [11:35] and the alternative well-supported things are all miserable compiled languages ;) [11:35] I'd hold off for a bit until we decide whether we're doing this? [11:35] you mean the universe part? [11:38] *nod* [11:38] 'cos if you rewrite it and then we add universe I bet you'll need to rewrite it again :) [11:39] hehe [11:39] ok [11:47] * DanChapman settles down to watch the UCS session. What a great idea!! [11:47] morning nik90, aquarius, popey o/ [11:48] morning DanChapman [11:52] I need to work out how best to document the pile of broken glass that is my head. Will think on it today :) [11:53] :) [13:33] o/ How can I install and register a scope on the phone from a click package? [13:51] hy [13:51] can i ask here?? [13:52] why device status : disconnected [13:58] Hello all [13:58] I have a problem with OnlineAccounts [13:59] What error: "RequestAccess failed: QDBusError("com.ubuntu.OnlineAccountsUi.InvalidApplication", "Invalid client application")" means? [14:34] mhall119: hey, I got a question. What open-source license would be best for components that I like to share with everyone? Recently I read in your blog, that you went with BSD. Should I stick with GPL or go with BSD as well? [14:46] Hello everyone. Just a quick question, which is the suggested way to implement settings in the applications at the moment: U1DB, LocalStorage or Settings in Qt.labs? [14:47] swordfish90: hmm that's a tough one [14:47] All 3 are supported by the Ubuntu SDK. For settings such as user preference I would definitely choose between U1db and Qt.Labs.Settings. [14:48] nik90, ahahah, I know that :D ... [14:48] gcollura: can you help with this one ^^ [14:48] Anyway yes, we are talking about the user settings in the terminal if that's of any use. [14:51] swordfish90: I would lean more towards Qt.Labs.Settings then. It is blazing fast at loading values [14:53] Ok, it's also probably the easiest. With local storage I had plenty of boilerplate code. Thank you nik90! [14:54] swordfish90: LocalStorage would definitely be my last choice ;) .. I was only doubting the choice between u1db versus qt.labs.settings [15:05] nik90, +1 settings we've started using that in Music and its awesome :) [17:13] nik90: I would recommend BSD, but if you like the protections of the GPL then LGPL would work for you too === amn is now known as Guest74622 [17:38] hello [17:38] everyone === bob is now known as Guest9075 === balloons is now known as Guest4725 === mihir_ is now known as mihir === chihchun_afk is now known as chihchun === tsimpson_ is now known as tsimpson === DanChapman_ is now known as DanChapman [19:34] popey: ping [20:13] mihir: pong! [20:31] Anyone else get Gmail notifications making a noise even though the device is in silent mode? === daker__ is now known as daker [21:08] popey, ping ? [21:09] ahayzen: heya [21:09] popey, hey we have set the development focus has remix (as suggested by balloons) ... [21:10] popey, seems the side affect is jenkins gets run twice as it is set to run against trunk (now remix) and lp:music-app/remix ? [21:10] popey, do you think we need to disable the remix one? [21:10] popey, eg see https://code.launchpad.net/~andrew-hayzen/music-app/remix-store-tab-index/+merge/241877 [21:12] let me see [21:12] oh i see, yes. [21:13] i dont see how to disable that [21:14] popey, i guess fginther` as he set it up? [21:15] yes. [21:15] lemme ping him a mail [21:15] popey, i wonder what happens when we try to merge? ... first one wins? or does the universe collapse? [21:17] i suspect first one wins [21:18] do we have any in flight? [21:19] popey, soon but not yet they are all under review i was talking to victor about them and suddenly realised double jenkins lol [21:21] sent [21:21] hehe [21:21] we go from zero jenkins to all the jenkins ☻ [21:21] popey, thanks :) [21:21] popey, all the jenkins \o/ === Elleo_ is now known as Elleo [21:59] ahayzen, popey, music-app/remix jobs are disabled now [21:59] fginther`, thanks :) [22:08] boom, thanks fginther` === mhall119_ is now known as mhall119