=== kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [15:06] frankban: thanks for the reveiw I replied [15:07] hatch: I see [15:08] hatch: could you add an XXX then? [15:08] I can, thanks [15:12] uiteam still need one more review here https://github.com/juju/juju-gui/pull/684 [15:13] hatch: i can look. [15:13] thanks [15:13] and my link to my charm branch was removed from the card....awesome [15:13] bac: why u remove my link? [15:13] * hatch crys [15:13] hatch: i put it where it belongs [15:14] oh now I see [15:14] right-clicky -> link to [15:14] interesting, I didn't know about that [15:14] hatch: done :) [15:15] bac: I do need a hand landing it, I thought there would be a 'merge' button :) Do I have to do it manually? [15:16] hatch: since you couldn't use lbox then we'll have to hand land it [15:17] hatch: it requires a few steps. get a clean trunk, merge your dev branch into it with the message "[r=frankban,bac] blah blah description", then push that branch back to trunk on LP [15:17] urulama: you and frankban both want it as a constant....Where would you like it placed? [15:17] bac: ok I can do that [15:18] hatch: it's just all over the code and it looks like something that could be "global" [15:19] urulama: well it's actually only in a single place in the code, but all over in the tests [15:19] the only way to possibly protect from that is to use a global which introduces other issues [15:19] hatch: yes, you can change that in that one place, but the test will work anyway even if the actual code fails [15:20] yeah, probably too much "go-like" requirement anyway [15:20] i just noticed that you can change main code and break it but the test will still work [15:22] There are places where globals would be nice but we don't really have a 'safe' place to put them [15:23] I was sure the tests would fail if I changed the code, lemme take another look [15:23] hatch: what is this? [15:23] rick_h_: https://github.com/juju/juju-gui/pull/684/files [15:23] first comments [15:24] hatch: hmmm, yea seems it'd be api specific so a go.js thing [15:25] unfortunately that's what caused the original issue :) it being go.js specific haha [15:25] I COULD move it back in there [15:25] but every time it makes a request in any method it would have to get the credentials and then check the username [15:26] so this is quite a bit more dry [15:27] hatch: so can you just make it a constant in this file? [15:27] API_USER_TAG [15:27] sure [15:27] = 'user-' [15:28] just not sure the 2 places it's used really warrant a constant :) [15:28] but 4:1 I lose :P [15:29] :) [15:33] hatch: yeah I agree with 2 places is not a parameter point, but in this case I value more the documentation aspects, i.e. we are not adding prefixes just because, we know this is how juju builds the freaking user entity tags ;-) [15:34] lol [15:34] it is very odd [15:42] I've noticed phantom crashing quite a lot lately [15:43] Me too. It's a pain [15:46] now to try and merge my guicharm changes without blowing it all up [15:46] * hatch starts the Mission Impossible theme song [15:47] I was thinking more along the lines of Yackety Sax. [15:47] lol! [15:47] Or http://www.youtube.com/watch?v=V66m52YFZBg [15:48] Hah I don't know that one [15:50] uiteamm call in 10 kanban please [15:55] * hatch is going to be a golang master after the break [15:57] bac: the branch that I worked in was branched from lp:~juju-gui/charms/trusty/juju-gui/trunk and there is only a single commit - can I jush push it back up without doing all the merge business? [16:01] kadams54: call [16:23] * Makyo runs to coffee [16:23] Makyo: once you get back and get your branch all figured out lemme know and I can re-review [16:24] Sure thing [16:24] enjoy! === kadams54 is now known as kadams54-away [16:59] rick_h_: http://2014.jsconf.eu/speakers/rob-ashton-got-make.html :) [17:00] lol /me queues up on the chromecast === mup_ is now known as mup === mup_ is now known as mup === mup_ is now known as mup [19:30] http://css-tricks.com/icon-fonts-vs-svg/ TLDR use SVG [21:27] Hey hatch [21:28] I need your help [21:29] Is there a way to get a list of maintianers for some given charms? [21:49] mbruzek: hey [21:50] umm got a charm in mind? [21:50] I can see [21:50] hatch: ALL of them [21:50] you guys have all the crazy apis [21:50] varnish for example [21:51] ok lemme see what's available [21:56] mbruzek: well I don't think that those are listed yet [21:56] at least I can't find anything which has them [21:57] mbruzek: you might want to fire an email about that one [21:57] hatch: thanks. I figured with your API knowledge you might be able to find some kind of query like that. [21:58] mbruzek: yeah it doesn't appear to be in the api *shrugs* [21:58] so either I'm missing something or it's actually not there :) [21:59] hatch: it would probably be: get_charm(), get_metadata()['maintainer'] [21:59] something like that. I suspect that would be really resource intensive, what rick_h_ told me going inside the charms was expensive [22:00] but it beats what I am doing now. $ charm getall && grep -h maintainer */metadata.yaml | cut -d : -f 2 | sort | uniq > charmers_email.list [22:00] haha not gona lie anything done with the api wouldn't be much better :D [22:00] charm getall branches ALL the files of ALL the charms [22:00] you'd have to request them one/one (or in batches) [22:00] well blame bzr for that nonsense :P [22:02] mbruzek: you could probably rig up some type of a script to request the metadata.yaml html page from LP [22:03] and then you could parse from there