[15:45] <hatch> lp|Metrics: The graphic titled 'Social Engagements' is pretty cool :)
[16:57] <hatch> that small svg bug is really irritating
[16:57] <hatch> I can now reproduce it after updating chrome
[16:57] <hatch> :/
[17:05] <hatch> annnnnd now I can't reproduce the export bug
[17:05] <hatch> ^ rick_h_ :/ 
[17:12] <hatch> rick_h_: yeah nothing I can do will reproduce that bug any longer. I'm going to have to bench it, maybe it was some obscure caching issue?
[17:14] <hatch> jujugui anyone able to test a GUI bug for me?
[17:46] <hatch> frankban: any luck reproducing that bug?
[18:30] <hatch> looks like it only happens when dragging a charm to the canvas from the charmbrowser
[21:12] <mbruzek> hatch ping
[21:16] <mbruzek> Can anyone here explain the jujucharms.com injest process?
[21:16] <mbruzek> I am not seeing a different version of the charm.
[21:20] <hatch> mbruzek: it should take about 30m
[21:20] <hatch> assuming of course that it passes proof
[21:20] <mbruzek> hatch: this is a personal branch
[21:20] <mbruzek> hatch does it always run proof on those branches?
[21:20] <hatch> same rules apply
[21:21] <hatch> yup
[21:21] <mbruzek> hatch: so can you explain something to me?
[21:22] <hatch> sure, any topic in particular? 
[21:22] <hatch> or should I just pick something :P
[21:22] <mbruzek> the code is on bzr revision 3.  The jujucharms.com shows kubernetes-master-1, there should be a 2 in there too, but maybe it did not pass proof
[21:22] <mbruzek> How does jujucharms.com revision the charm?
[21:23] <hatch> honestly I'm not too sure now that the revision file is no longer required
[21:23] <mbruzek> hatch: I pushed 3 almost 30 minutes ago, but I do/did not see the kubernetes-master-2 in jujucharms.com
[21:23] <hatch> in theory it could be up to an hour, if you pushed it just after the last ingestion started
[21:24] <mbruzek> bzr shows me 3 commits now, myself, whit, and myself.
[21:24] <mbruzek> But when I look at jujucharms.com I only see kubernets-master-1 I can not find kubernetes-master-2
[21:24] <mbruzek> which would have been whit's version
[21:25] <hatch> that does look to be the case
[21:25] <hatch> I don't have access to the machine to view the logs
[21:25] <mbruzek> hatch: I see your point about ingestion that is fine. I can wait.
[21:25] <hatch> friday - everyone who does is gone :)
[21:25] <mbruzek> hatch: OK
[21:26] <hatch> but yeah maybe give it 15 more mins or so
[21:26] <hatch> Does it pass proof locally?
[21:26] <mbruzek> The thing is I have to build a bundle to point to the LATEST version of my charm.
[21:26] <mbruzek> hatch: yes it does, just double checked
[21:27] <hatch> ok then yeah maybe just hold off another 15m or so and then fire an email to peeps 
[21:27] <mbruzek> hatch: I don't see how proof is tied in here.  People can push stuff in their namespace that does not pass proof
[21:27] <mbruzek> hatch: like if they are building a charm and don't know about proof
[21:28] <hatch> then it won't end up in the charmbrowser
[21:28] <mbruzek> hatch: If you say so.  I didn't know that
[21:29] <mbruzek> hatch: whit's changes were not passing proof that is what I was fixing.  his code was up there to the latest version
[21:29]  * mbruzek is confused
[21:30] <hatch> this is under your namespace or charmers?
[21:30] <mbruzek> we created a group called ~kubernetes
[21:31] <hatch> ok yeah I see -1 
[21:31] <mbruzek> https://code.launchpad.net/~kubernetes/charms/trusty/kubernetes-master/trunk
[21:31] <mbruzek> You see 3 commits there right?
[21:32] <hatch> yeah
[21:32] <hatch> there were some issues with ingestion speed last week, I can't remember if those were resolved 
[21:32] <mbruzek> when my old bundle was pulling cs:trusty/kubernetes-master-1 I was getting proof errors in whit's code
[21:33] <mbruzek> so I set out to fix the code, revision three and I want to know what number this will show up in for the charm store browser
[21:33] <mbruzek> so I can build the bundle to point to the right code
[21:35] <mbruzek> hatch what makes the charmstore increment the counter, I am aware it is not tied to bzr.
[21:36] <hatch> I don't know - I think that it does it on each ingestion where the code differs
[21:44] <hatch> mbruzek: yeah it still hasn't ingested - Your best bet would be to email peeps
[21:45] <mbruzek> who is peeps?
[21:45] <mbruzek> your peeps?
[21:45] <hatch> sent ya a msg :) 
[21:46] <hatch> you should have done this about 4 hours ago :P
[21:48] <mbruzek> hatch:  yeah
[21:49] <hatch> now if you had a GUI problem - i'd be able to help you out :D
[21:51] <mbruzek> doh
[21:51] <mbruzek> Now I see it is -2
[21:51] <mbruzek> JUST after I checked in the damn bundle
[21:51] <mbruzek> argh
[21:52] <hatch> https://jujucharms.com/u/kubernetes/kubernetes-master/trusty/2 there it is :)
[21:53] <mbruzek> why is this one 2 and the other one was showing up as -1 when there are 3 bzr commits?
[21:53] <hatch> mbruzek: likely the reason I mentioned above - it didn't ingest the second commit
[21:54] <hatch> https://jujucharms.com/u/kubernetes/kubernetes-master/trusty/2#revisions
[21:54] <hatch> it's a little confusing, I agree
[21:54] <hatch> bug report? :)
[21:54] <mbruzek> no rick will  just hulk smash me with his logic
[21:55] <mbruzek> and it might makes sense to him, I would believe that
[21:55] <mbruzek> I am happy now that I can see it, but I *JUST* checked in the code
[21:56] <hatch> lol
[21:57] <hatch> so yeah looks like you had just missed the previous ingestion
[21:59] <mbruzek> meaning I just checked in the bundle with the old -1 revision, so I have to check in 3 more bundles
[22:00] <hatch> good thing version control makes it easy :)
[22:00] <hatch> rebase ftw!
[22:09] <hatch> mbruzek: so you're good now?
[22:09] <mbruzek> hatch: yes thank you
[22:10] <mbruzek> hatch: thanks for your help and sticking with my questions
[22:10] <mbruzek> hatch: happy Friday!
[22:10] <hatch> haha np, to you too