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