[00:02] <rick_h> huwshimi: yea, that's on my todo for autocomplete. Basically we'll need a viewNavigate with some sort of history flag that tells it to reload the previous state 
[00:02] <rick_h> huwshimi: so it doesn't exist yet, and needs to be defined/coded into the bit that updates state to go off the old state first. 
[00:03] <huwshimi> rick_h: Ah right. We need some breadcrumbs under the search box so I was going to start that with a home button but I'll leave that until your bits are in place.
[00:03] <rick_h> huwshimi: ok
[00:03] <huwshimi> (Unless doing breadcrumbs as part of your work makes sense)
[00:03] <huwshimi> rick_h: ^
[00:03] <rick_h> huwshimi: not really
[00:04] <huwshimi> rick_h: Sure :)
[00:05] <rick_h> huwshimi: honestly we're a bit out of the loop. We didn't think we'd still be on this and we've ignore much of the new design/etc. 
[00:06] <huwshimi> rick_h: OK sure.
[00:06] <rick_h> so breadcrumbs is 'what breadcrumbs?' :)
[00:06] <huwshimi> rick_h: Fair enough :)
[00:07] <huwshimi> rick_h: The latest visuals for the autocomplete have the breadcumbs in them, so hopefully you're building the right thing :P
[00:08] <rick_h> huwshimi: https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1ZmdTTDdTZEdFOGM is what I'm going off of. It's what I know about in the oscon deliverables folder and search
[00:08] <rick_h> nothing there, so if ther's other stuff we need to be updated. 
[00:09] <rick_h> and we should start killing off out of date visuals as there's too damn many things floating around in docs to keep up with
[00:09] <huwshimi> rick_h: Agreed.
[00:10] <huwshimi> rick_h: That's the latest one. The screen for when you've searched or when you're browsing a category has the breadcrumbs
[00:11] <huwshimi> rick_h: I.e https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1ZVpkRjVtY0luaE0/edit
[02:51] <hatch> evening gui nightcrew
[02:51] <hatch> aka huwshimi
[02:51] <huwshimi> hatch: Night
[02:52] <hatch> oh I was using evening as a greeting
[02:53] <hatch> :)
[02:54] <huwshimi> hatch: Oh, hello :)
[11:55] <luca__> can someone help me bzr something? argh...
[11:55] <rick_h> luca__: rgr
[11:55] <luca__> rick_h: I was hoping you wouldn't help since I pestered you so much yesterday!
[11:55] <rick_h> luca__: going to be slim pickings this morning :)
[11:56] <luca__> rick_h: I've just typed "bzr branch lp:~huwshimi/juju-gui/visual-update-4"
[11:56] <rick_h> though I don't know. Sometimes some of the guys are around in the moring but in quiet mode
[11:56] <luca__> hehe yeah :(
[11:56] <luca__> and it came back with "Branched 824 revisions. "
[11:56] <rick_h> luca__: ok, and you have a visual-update-4 directory like yesterday?
[11:56] <rick_h> luca__: ah heh, so you did that in some other path than the previous one?
[11:57] <luca__> I have a update-4 directory in my files
[11:57] <rick_h> luca__: ok
[11:58] <luca__> but when I type "make devel" it says "make: *** No rule to make target `devel'. Stop.
[11:58] <luca__> "
[11:58] <luca__> it's never done that before
[11:58] <rick_h> luca__: so you have to be in the directory in the project that has the Makefile in it
[11:58] <rick_h> if you can't do an `ls` and see the Makefile then you're not going to be able to run make *
[11:59] <luca__> right
[11:59] <luca__> so I need to cd into the update-4 file?
[11:59] <rick_h> luca__: correct
[11:59] <luca__> ah "make devel" is doing something now
[12:00] <luca__> I need to obviously update my instructions
[12:01] <luca__> so, it should be:
[12:01] <luca__> 1. cd .. (cd src/jujugui/)
[12:01] <luca__> 2. run "bzr branch lp:~juju-gui/juju-gui/browser-default"
[12:01] <luca__> 3. cd to file drectory
[12:01] <luca__> 4. run "make devel"
[12:01] <luca__> 5. Open browser and visit http://localhost:8888/
[12:02] <rick_h> luca__: that looks good
[12:02] <luca__> rick_h: nice
[12:02] <luca__> rick_h: it's all up and running in the browser, thanks for your help again :D
[12:02] <rick_h> luca__: np, glad to help :)
[12:03] <luca__> rick_h: :)
[12:26] <luca__> rick_h: do you have the link to that site where I can leave feedback for the branch?
[12:50] <rick_h> luca__: sorry, missed your request there. https://codereview.appspot.com/11160043/ is the link
[12:52] <luca__> rick_h: thanks :D
[13:06] <rick_h> gary_poster: so huw's branch is a LGTM with the update branch I've linked into the comments. luca__ might have some other feedback. If someone can help usher that through that'd be great. 
[13:06] <luca__> rick_h: I have 8 bugs so far
[13:06] <gary_poster> fantastic, thanks for the update branch rick_h .  luca__ are any of them  showstoppers or ok to land separately?
[13:06] <rick_h> luca__: k
[13:07] <luca__> gary_poster: nothing serious, I'll send them to you in 2 seconds
[13:07] <luca__> gary_poster: it looks very good
[13:07] <gary_poster> luca__, awesome thanks
[13:09] <luca__> gary_poster: sent
[13:09] <gary_poster> thx, will look soon (on call)
[13:09] <luca__> gary_poster: no worries
[13:33] <jcsackett> sinzui: having issues with g+, be on standup soon.
[13:36] <bac> gary_poster: let me know when you'd like to have our cal
[13:37] <bac> our call, not our cal
[13:37] <gary_poster> bac, yeah sorry finishing up
[13:37] <bac> np
[13:59] <gary_poster> luca__, is https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1Y3k3UWJibndUbHc narrow charm details the visual design for the vertical scrollbar?
[14:07] <hatch> morning
[14:12] <luca__> gary_poster: yep
[14:12] <luca__> gary_poster: we're not entirely sure what we can do with a scroll bar so….if you guys have some good ideas then I would be really happy to see them.
[14:13] <gary_poster> luca__, ok cool.  so we shouldn't worry too much with assets for now, but just get it working then, IIUC. bac ^^^
[14:13] <bac> rt
[14:13] <luca__> gary_poster: bac yeah, the most important thing is that it's unobtrusive
[14:14] <luca__> gary_poster: bac we like chromes scroll bars which disappear 
[14:14] <bac> luca__: actually, we're talking about the vertical zoom slider
[14:15] <bac> luca__: gary_poster misspoke when he said scrollbar
[14:15] <gary_poster> sorry
[14:15] <luca__> gary_poster: bac oh!
[14:15] <luca__> gary_poster: bac then yes, thats the one :D
[14:15] <luca__> gary_poster: bac I can send you the assets if you need them
[14:15] <gary_poster> luca__, +1
[14:15] <bac> yes please
[14:16] <gary_poster> rick_h, you available for a quick call about charm model issues?  will let you go asap I promise :-)
[14:16] <rick_h> gary_poster: sure thing
[14:16] <bac> luca__: with the slider marker (called the 'thumb' in yui-speak) have a drop shadow?
[14:18] <abentley> adeuring: I believe your get-content-from-bzr branch will fix this bug: https://bugs.launchpad.net/charmworld/+bug/1199780 See comment #4
[14:18] <_mup_> Bug #1199780: search requests errors when a charm has no last_change <charmworld:Triaged> <https://launchpad.net/bugs/1199780>
[14:18] <luca__> bac: the little white circle does have a drop shadow
[14:19] <luca__> bac: I'm sending you assets for this zoom bar https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1QjdzNWMwUm9ENDg/edit?usp=sharing
[14:20] <bac> luca__: yui requires the marker and shadow to be in one image as sprites.  i may need to work with you to get that done correctly.
[14:20] <luca__> bac: ok
[14:20] <adeuring> abentley: it _might_ fix the error  -- but it is also a reminder that I should test how the new code behaves for an empty branch
[14:21] <abentley> adeuring: True.
[14:23] <abentley> sinzui: If the charm store doesn't care which branch is promulgated, should we?
[14:28] <sinzui> abentley, I don't think we want to care
[14:29] <sinzui> abentley, I think the store is making zips from snapshots. It doesn't care about continuity.
[14:33] <hatch> luca__: is the prototype scrolling wrong? I was under the impression that it should 'push' the previous one up? https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html#
[14:34] <hatch> one being heading
[14:34] <hatch> right now that prototype simply covers up the previous one
[14:35] <luca__> hatch: that's correct, it should push the other header out like it does on iOS and instagram, Ant couldn't spend too much time on it.
[14:35] <hatch> *phew* ok
[14:42] <hatch> luca__: I should also mention that the 'push up' kind of looks like garbage when using a scroll wheel on a mouse with a large scroll value
[14:43] <hatch> I'm wondering if we shouldn't trap the scroll and then animate it ourselves
[14:43] <hatch> (this is of course way more work)
[14:43] <hatch> ^ gary_poster if you're around you may want to weigh in
[14:43] <luca__> hatch: the push seems to be really hard to animate
[14:44] <luca__> hatch: as a compromise we was looking at possibly a fade state between the 2 colliding headers
[14:44] <hatch> well yes the push is hard - but that's not really the issue
[14:44] <gary_poster> hatch, trap scroll and animate: +1 as bug for later work
[14:44] <hatch> ok I'll create that bug
[14:44] <hatch> luca__: are you ok with that?
[14:45] <luca__> hatch: do you mean something like that demo you showed me yesterday?
[14:46] <hatch> when header 2 comes in contact with header one, it pushes header one up as it scrolls
[14:46] <luca__> hatch: ok, that is what we want
[14:46] <hatch> however when you use a scroll wheel it 'jumps' which looks bad because of the order of events that need to happen
[14:47] <luca__> hatch: right
[14:47] <hatch> so we will need to trap the scroll and then animate the scroll ourselves
[14:47] <hatch> to smoothen it out
[14:47] <luca__> hatch: that makes sense, thanks
[14:48] <hatch> alllrighty
[15:00] <sinzui> luca__, arosales_, rick_h: We appear to be accepting icons that are not based on the one true icon template: http://manage.jujucharms.com/charms/precise/postgresql shows the issue best. orangesquad discussed enforcing icons based on the template, and we concluded that would be too strict. We can revisit the decision.
[15:01] <rick_h> sinzui: yea, I think it's great to help with the icons, but not sure it's great to enforce too much as many projects have established icons and not all charmers are going to be graphic artists to adjust/fix them?
[15:01] <rick_h> basically we stand to take a hit on charm submissions/etc if we enforce it too much. Then again, we only show them for reviewed charms so that limits the numbers a bunch. 
[15:02] <arosales_> sinzui, rick_h: I take it if the icon isn't in the correct format it is not picked up correctly in the charm browser?
[15:02] <rick_h> arosales_: if it's not icon.svg and valid svg (coming soon) it won't get pulled in. 
[15:02] <rick_h> arosales_: however, if it's a valid svg, but doesn't use the gradient/lighting guidelines we accept it currently
[15:02] <sinzui> arosales_, the icon template has the squircle outline and sets the dimensions to 96x96
[15:03] <sinzui> the template has a gradient. users may change it, but they must follow the guidelines
[15:04] <arosales_> aiui as long as a charmer submits a valid svg, their icon will show up even if they don't follow the template/guidelines, correct?
[15:04] <sinzui> no
[15:04] <sinzui> arosales_, icons are only shown for reviewed charms. ~charmers approved the icon
[15:05] <arosales_> sinzui, yes sorry. If they are ack'ed by the review process too.
[15:06] <arosales_> sinzui, but if ~charmers don't catch the icon not being in the correct format and still ack it will show up in the store as long as its a valid svg
[15:06] <arosales_> my question is around how much review ~charmers should be doing around the icon
[15:06] <hatch> darn my trackpad is out of batteries
[15:08] <sinzui> arosales, I don't see think document on juju.ubuntu.com. I thought it was added: https://docs.google.com/document/d/1hBTH_7RLUYMV-VhZOGxb-bFHICXyVRU4t8L79Dlea80/pub
[15:09] <frankban> bac: could you please take another look at https://codereview.appspot.com/11110043 ?
[15:09] <bac> frankban: sure
[15:09] <frankban> thanks
[15:09] <arosales> jcastro, did you icon guide get ported over to the new docs
[15:10] <arosales> sinzui, ya I am not seeing it. We'll need to add that
[15:10] <hatch> gary_poster: luca__ http://jsbin.com/utitov/2/ - this breaks in FF for some reason and has an odd offset issue when scrolling back but it's very close
[15:10] <jcastro> we never added the icon guide to the docs
[15:11] <jcastro> we just gave people the google doc
[15:11] <jcastro> it never made it out of a google doc onto normal docs
[15:11] <hatch> oh noes not another Google Doc ;)
[15:11] <hatch> too soon?
[15:11] <arosales> jcastro, ah
[15:12] <arosales> jcastro, I'll sync up with evilnick on getting that google doc added to the docs
[15:12] <jcastro> I believe we used the "I sent it to the list, therefore it's documented" method on that one, heh
[15:13] <arosales> sinzui, in progress of adding it to the docs https://bugs.launchpad.net/juju-core/+bug/1199367
[15:13] <_mup_> Bug #1199367: icon.svg isn't documented anywhere <juju-core:Triaged by evilnick> <juju-core docs:Triaged by evilnick> <https://launchpad.net/bugs/1199367>
[15:14] <arosales> sinzui, any guidance on how much review of the icon ~charmers should do?  Must follow the template, can deviate a little, or any valid svg?
[15:18] <gary_poster> luca__, I remembered what I was going to say: the way we *can* get reuse of ant's prototype in the GUI is to reuse his brain :-)  he will have solved the issues before so maybe can be faster.  (whew, remembering makes me feel better ;-) )
[15:19] <hatch> hmm
[15:19] <hatch> http://jsbin.com/utitov/3/
[15:20] <hatch> is better but there is an issue
[15:20] <luca__> gary_poster: haha well, feel free to speak to him, he's solely on Juju until the end of next week so he can work on anything Juju related
[15:20] <gary_poster> cool luca__ :-) thanks
[15:20] <luca__> hatch: that's better, there seems to be a tiny issue scrolling upwards
[15:20] <hatch> it appears that scrolling fast and with different scroll values 'tricks' it into thinking it's in a different position than it should be
[15:20] <hatch> luca__: yeah, which doesn't happen if you scroll slowly heh
[15:20] <sinzui> arosales, sorry, webops pinged and I have waited 11 days to get their full attention
[15:20] <luca__> hatch: hehe
[15:21] <hatch> getting closer
[15:21] <hatch> scrolling is friggen hard
[15:21] <sinzui> arosales, per the guidelines in the url I pasted, I think the dos and don'ts section makes it easy to spot check.
[15:22] <hatch> luca__: btw it works stunningly (not a word) in FF now
[15:22] <hatch> heh
[15:22] <sinzui> arosales, the postgresql example is clearly missing the squircle and background
[15:22] <gary_poster> hatch, cool, I think I see the issue you mean
[15:23] <gary_poster> hatch lemme know if you think we should discuss trapping the scroll etc.
[15:24] <gary_poster> hatch just finished call.  going to your call :-P
[15:25] <gary_poster> Makyo, will probably be late ^^^
[15:25] <Makyo> gary_poster, ack, lmk
[15:25] <gary_poster> will do
[15:26] <luca__> bac: are the assets from jamie ok?
[15:26] <bac> luca__: except for the sprite/shadow issue.  haven't plugged them in yet.
[15:27] <luca__> bac: ok, let me know
[15:27] <bac> frankban: the code looks good but i haven't qa'd it yet.  did the changes you made address the issues i raised?
[15:28] <frankban> bac: yes, the should fix constraints order and unexpected conflicts
[15:28] <frankban> s/the/they
[15:28] <bac> frankban: great
[15:30] <bac> done frankban
[15:31] <frankban> great, thanks bac
[15:36] <luca__> Category results and Search results for browse mode can be seen here: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1LS04ZTUyeUk1bEU/edit?usp=sharing
[15:37] <arosales> sinzui, ok. so well try to take a strong stance on the guidlines in the doc
[15:50] <Makyo> jujugui call in 10 kanban now
[15:51] <hatch> luca__: can you tell me what the width of the inspector panel is and what the gap to the right of the inspector is
[15:53] <luca__> hatch: width is 290px
[15:54] <rick_h> I hate testing autocomplete. Talk about a mess of integration. 
[15:54] <hatch> bcsaller: your status bar branch shows numbers for the units but the mockups don't - sorry I forgot to include that in my comments
[15:55] <luca__> rick_h: but auto-complete is one of my most beloved features ^^
[15:55] <rick_h> luca__: it's coming, just writing tests around it is a pita
[15:56] <rick_h> :P
[15:56] <luca__> hatch: the gap to the right hand side of the inspector is 20px
[15:57] <hatch> luca__: ok 20px all around, got it
[16:01] <sinzui> gary_poster, we are doing some in-place changes to the webops deployment script to gather all the pieces (release tarball and npm cache) into the charm for the deploy. I agreed to add a upgrade hook to support unpacking the tarballs for future deploys
[16:01] <gary_poster> jujugui call now
[16:02] <sinzui> np, just an fyi that I we are working on the deploy now
[16:02] <gary_poster> sinzui, you should not need the npm cache for non-dev builds; that may be a regression
[16:02] <sinzui> oh!
[16:02] <gary_poster> bcsaller, call ping
[16:05] <gary_poster> jcastro, bug 1194866 has fix going into review very soon
[16:05] <_mup_> Bug #1194866: Cannot deploy http://jujucharms.com/~marcoceppi/precise/discourse from GUI <juju-gui:Triaged> <https://launchpad.net/bugs/1194866>
[16:05] <marcoceppi> \o/
[16:05] <marcoceppi> I can finally stop getting pings :P
[16:08] <benji> bac: I'm far from a CSS expert, but I'll be glad to pitch in once my branch is reviewed/landed.
[16:08] <bac> thanks benji
[16:10] <rick_h> here comes autocomplete: reviews please sinzui jcsackett hatch and luca__, if you want to peek to start writing up the UX issues. I wasn't sure on exact sizes of things in the result set. https://codereview.appspot.com/11126043
[16:10] <rick_h> this is sans-categories for an initial stab
[16:11] <hatch> bcsaller: did you see my comment about the status bar branch showing numbers?
[16:14] <gary_poster> frankban, how goes the arm stuff?
[16:14] <luca__> rick_h: I can check it tomorrow
[16:15] <frankban> gary_poster: Start in 1 hour -> https://launchpad.net/~frankban/+archive/ppa/+builds?build_text=&build_state=all
[16:17] <rick_h> luca__: cool. I look forward to the checklist to update :)
[16:30] <sinzui> orangesquad, does anyone have 5 minutes to review https://code.launchpad.net/~sinzui/charmworld/sane-icon/+merge/174058
[16:30] <abentley> sinzui: Sure.
[16:33] <abentley> sinzui: Since abel is in the middle of changing it so we don't use the on-disk file, could you use from_bufffer instead?
[16:33] <sinzui> oh, yes I can
[16:33] <hatch> rick_h:  the 'reviewed' flag looks like a 'favourite' button, especially because the pointer changes to a cursor when you hover over it
[16:34] <rick_h> hatch: k, but the new design moves the reviewed badge over to a * on the right so it's just a fact of the charm-token for today
[16:35] <hatch> rick_h: it is a * on the right now though?
[16:35] <rick_h> hatch: huw's branch is up for review doing that. 
[16:35] <hatch> no I mean, it is right now
[16:35] <rick_h> hatch: so it's pointless for me to make any UX mods to the charm-token for this design issue. 
[16:35] <rick_h> hatch: ah, I don't have it locally in my branch atm I guess then
[16:36] <hatch> the first thing I thought was "oh cool you can favourite charms"
[16:36] <hatch> :)
[16:36] <rick_h> hatch: ok, well we can toss that to design, but not sure what to do about that atm
[16:36] <bcsaller> hatch: sorry, missed that, yes, it has numbers, some of the mocks did in the past. I think it makes sense to include them but if we get feedback otherwise its simple to remove. The ratios shown reserve minimum space for small segments so 9999 running units and 1 in error doesn't end up being 1 pixel. Because of that the numbers can make it clear if its 1 unit or 30 or whatever
[16:36] <hatch> bcsaller: yeah - I can see an argument for both, I just wanted to point it out in case it was accidental
[16:38] <hatch> rick_h: yeah maybe we can switch the star to a badge with two lions fighting over a steak
[16:38] <rick_h> hatch: ooh, needs moar shark!
[16:39] <hatch> ok ok - a shark can be jumping over the lions
[16:40] <hatch> benji: review done
[16:41] <benji> cool, thanks
[16:42] <sinzui> abentley, I had a bad push, If you look at the MP again you will see the code now reads from the handle provides and on 1k is read
[16:43] <sinzui> PS, the test actually shows the bare minimum to pass a magic match for svg
[16:45] <abentley> sinzui: RULES suggests that this branch enforces a 96x96 valid svg, when actually, that's being left to proof.
[16:45] <sinzui> abentley, right, that is what we want to do
[16:46] <abentley> sinzui: R=me.
[16:46] <sinzui> after todays discovery, we may want to do more like verify the same ids as the template are present, or check for the squircle and gradient elements
[16:55] <rick_h> teknico: review inbound
[16:56] <teknico> rick_h: thank you
[16:57] <sinzui> gary_poster, bac, juju-ui, the production deploy failed because the charm wants an npm cache: https://pastebin.canonical.com/94238/  This happens juju-gui-source changes. Is there another config setting that makes it clear we don't need the npm-cache? serve-tests=false perhaps?
[17:03] <frankban> gary_poster: the binary packages for i386, armel and armhf are now in ppa:juju-gui-charmers/devel . amd64 is still pending. I'd like to test the new packages before copying them in stable. I'll do that tomorrow morning
[17:04] <hatch> bcsaller: nice fix for the units
[17:16] <bcsaller> hatch: thanks
[17:28] <rick_h> anyone aware of the status bar code? I'm getting test failures, but only on test-prod in the views.StatusBar stuff?
[17:29] <rick_h> https://pastebin.canonical.com/94254/ I've make clean'd and runs fine in browser/debug. 
[17:29] <gary_poster> benji, any quick fix for sinzui's report above?  This is high priority
[17:37] <benji> gary_poster: sorry for the slow response, I'm eating lunch and need to get back to it, but the quickest fix I can see is to wrap the fetch in a try/except that passes on a subprocess.CalledProcessError
[17:37] <gary_poster> ack thanks benji
[17:37] <sinzui> really
[17:38] <sinzui> We will accept a timeout? Wont that slow the charm deploy by minutes?
[17:38] <gary_poster> sinzui, yeah, we don't need it for stable releases.  The proper fix is to not do it at all.
[17:39] <rick_h> bcsaller: is the statusbar yours? If I move it to the list of 3rd party files to load in merge-files it works.
[17:39] <rick_h> bcsaller: curious how you got it to land. :)
[17:39] <sinzui> gary_poster, okay. I can wrap the call and put it up for review to unblock webops
[17:39] <bcsaller> 207318
[17:39] <bcsaller> 645310
[17:39] <rick_h> focus daniel-son :)
[17:39] <bcsaller> woah
[17:41] <gary_poster> lol
[17:41] <bcsaller> rick_h: it worked fine here
[17:41] <bcsaller> but I'll add it to that list
[17:41] <rick_h> bcsaller: I'm trying to submit a quick branch. I'll include it here
[17:41] <bcsaller> and submit a trivial 
[17:42] <bcsaller> ahh, thanks
[17:42] <rick_h> bcsaller: I just wanted to sanity check I'm not missing something. 
[17:42] <rick_h> bcsaller: since it must have gone through to land, but I can't get it to combine at all after multiple clean/clean-all's 
[17:42] <bcsaller> I suspect I had the test server running already when lbox check ran and it used the built files? I've seen that work around this issue in the past
[17:42] <hatch> few things are as irritating as a Y.View not firing a render event.....
[17:42] <hatch> cc rick_h ^
[17:42] <hatch> ehh?? :)
[17:43] <rick_h> hatch: :/ ?
[17:43] <hatch> the fact that a Y.View doesn't fire a render event....is very irritating
[17:43] <rick_h> meh, I've not had that big a problem with it that I can recall.
[17:43] <hatch> lies
[17:43] <rick_h> now the AC widget...
[17:43]  * hatch walks away
[17:43] <rick_h> :P
[17:43] <hatch> haha
[17:44] <abentley> hazmat: Part of ingest permits the branch name to be either 'trunk' or 'trunk-1
[17:44] <abentley> hazmat: What's the rationale for that?  Doesn't it make the charm store address ambiguous?
[17:45] <rick_h> hatch: don't walk away, you're supposed to be reviewing my branch :P https://codereview.appspot.com/11126043/
[17:45] <hatch> ohhh am I now
[17:45] <hatch> 4000ln difs are too big :P
[17:46] <rick_h> oh bah, conflicts
[17:46] <rick_h> was like "wtf...4000 lines?!"
[17:46] <rick_h> oh, and you've learned by now to ignore test/data/autocomplete.json :P
[17:46] <hatch> haa yup
[17:47] <rick_h> bcsaller: https://codereview.appspot.com/10839044 has the change if you don't mind peeking at the other 4 lines while you're in there :)
[17:48] <rick_h> sinzui: jcsackett can I get a second on ^^ as well please?
[17:50]  * sinzui looks
[17:55] <teknico> I get three errors in trunk when running "make test-prod": http://pastebin.ubuntu.com/5865679/
[17:55] <rick_h> teknico: see the discussion with bcsaller ^^, branch is incoming
[17:55] <teknico> rick_h: great, thanks
[17:55] <rick_h> teknico: just as fast as lbox can run its little heart out 
[17:56] <hazmat> abentley, ignore it.. it was for a branch a legacy issue from the charm distro on lp i found on a single charm when doing the initial impl
[17:56] <hazmat> abentley, s/ignore/yank
[17:57] <abentley> hazmat: Excellent.  So from here on out, only "trunk" branches are considered.
[17:57] <hazmat> i think there was maybe two charms that exhibited that problem and they were from natty
[17:57] <abentley> hazmat: I'm hitting it with ~zulcss/charms/oneiric/nagios/trunk and ~zulcss/charms/oneiric/nagios/trunk-1
[18:00] <rick_h> grrr, branch switching confusing lbox fml
[18:01] <teknico> rick_h: how about another look? https://codereview.appspot.com/10888048/
[18:01] <rick_h> teknico: loaded up right now
[18:03] <rick_h> teknico: LGTM thanks for the test changes/fixes.
[18:03] <teknico> rick_h: thank *you*! :-)
[18:06] <rick_h> teknico: the fix for the test failures is landing
[18:06] <rick_h> teknico: so pulling from trunk should be good for that now
[18:07] <teknico> rick_h: great. it's a bit late now, so if someone else will give the gift of a review, I'll merge trunk and land this later
[18:07] <rick_h> teknico: rgr, have a good night
[18:07] <hatch> rick_h: just fyi I am reviewing your branch right now, it's just taking a bit
[18:07] <teknico> rick_h: thanks
[18:07] <benji> gary_poster: I'm back from lunch.  Is there anything I can do to help on the NPM cache issue?
[18:08] <rick_h> hatch: thanks, yea, it's a pita branch. I'm pushing a fix for the template conflict currently now that the test fix is in trunk
[18:08] <gary_poster> benji, yes, gimme one sec
[18:08] <benji> k
[18:10] <gary_poster> benji, ok here.  maybe guichat?
[18:10] <benji> gary_poster: k
[18:10] <hatch> rick_h: is this branch supposed to be QAable?
[18:11] <rick_h> hatch: yes
[18:11] <rick_h> hatch: once the confilict is resolved. The template won't compile until then
[18:11] <rick_h> hatch: pushed update should be there now. 
[18:12] <hatch> hmm ok - well the error I get is actually a 406 http error
[18:12] <rick_h> hatch: OH! right, no. You have to change the api enpoint to staging. in the config to QA
[18:12] <rick_h> sorry, my mistake on the instructions. 
[18:12] <rick_h> hatch: it's waiting on a release to production on the back end currently. 
[18:13] <hatch> hmm
[18:13] <hatch> when is that going to be released?
[18:13] <rick_h> http://staging.jujucharms.com/ to be exact
[18:13] <rick_h> hatch: any time. sinzui was looking at getting into the queue to get a release today. Not sure if it'll happen today/tomorrow. 
[18:13] <rick_h> hatch: so obviously I won't land it until the back end supports it
[18:13] <hatch> ok I'm asking because it causes other errors to cascade which we obviously can't have in trunk
[18:14] <rick_h> hatch: rgr
[18:14] <hatch> will check your new code
[18:14] <hatch> rick_h: although this could be good
[18:14] <hatch> the code should be able to handle this failure without throwing a console error
[18:15] <sinzui> rick_h, hatch. We are in the queue. there is an incident in front of us.
[18:15] <sinzui> I think we will have webops attention again in 2 hours
[18:16] <hatch> sinzui: that's fine - I'm just saying that the GUI code shouldn't break if the api endpoint goes down so the AC failure code should be able to handle that inevitability cc) rick_h
[18:16] <hatch> so this was a blessing in disquise :)
[18:17] <hatch> we caught the issue ahead of time
[18:20] <rick_h> hatch: gotcha
[18:21] <rick_h> hatch: though if the store goes down it's far from a silent failure as you'll not get this far to get an AC widget, but ok :)
[18:21] <hatch> haha well maybe it will go down after they got this far ;)
[18:26] <hazmat> http://www.zdnet.com/verizon-backs-ubuntu-smartphone-7000017954/
[18:28] <hatch> bac: do you have a 'positioned' vertical scroll bar?
[18:28] <hatch> er
[18:28] <hatch> slider
[18:28] <hatch> I am trying to figure out how far left to position the inspector
[18:28] <hatch> the values in the mockup and from Luca were wrong heh
[18:29] <bac> hatch: i do...but i'm not sure where exactly it is going to go
[18:29] <hatch> hazmat: that's awesome news!!
[18:29] <bac> hatch: won't know until i get the new assets in place
[18:29] <hatch> ok I'll just place it whereever then, it's a single line fix in a follow-up then  I guess
[18:29] <hatch> thx
[18:29] <bac> no verizon on the island. :(
[18:30] <hatch> no verizon in Canada either
[18:30] <hatch> buuuut
[18:30] <hatch> as soon as there is a north american GSM band phone then we r golden
[18:32] <bac> gary_poster: hurrah, i found the issue.  it was coming from bootstrap and was not on the element i'd been looking at.  img max-width:100%
[18:32] <gary_poster> yay bac!!!
[18:32] <hatch> we are so close to removing bootstrap :)
[18:33] <hatch> doesn't Verizon have a horrible track record of loading a TON of bloatware on their phones?
[18:33] <bac> yes, vzn is notorious for that i hear
[18:33] <hatch> I'm kind of curious how the ubuntu smart phone will manage carrier garbage and lock ins while keeping an open platform
[18:34] <bac> hatch: you should join the CAG
[18:35] <hatch> I'll bring with it my nation(see house) wide cellular network(see wifi)
[18:37] <bac> gary_poster: look at little old caktus listed with the big boys: http://us.pycon.org/2014/
[18:37] <gary_poster> bac cool :-)
[18:37] <bac> apparently they did the site
[18:37] <bac> per calloway
[18:38] <hatch> past employer?
[18:38] <bac> no, a local little consulting shop that sponsors python user group stuff
[18:38] <bac> by local, i mean NC
[18:39] <hatch> ahh
[18:39] <hatch> Montreal....that's near me
[18:40] <hatch> only a 3h flight....lol
[18:42] <hatch> actually there is a js conf in Vancouver in November
[18:45] <jcastro> hey gary_poster 
[18:45] <jcastro> search is busted on uistage
[18:45] <jcastro> the new one, 8086
[18:46] <hatch> the manage.jujucharms.com is 503'ing
[18:46] <gary_poster> jcastro, thanks much.  sinzui, ^^^ deployment?
[18:48] <hatch> gary_poster: can you head to 8086 and quickly drag the bottom of the window up to see if there is a scrollbar ?
[18:48] <hatch> it's like the resize event doesn't always fire
[18:48] <hatch> and I am just wondering if it's just me
[18:49] <gary_poster> hatch confirmed it sometimes happens
[18:49] <hatch> alright thanks, looking for the cause
[18:50] <sinzui> gary_poster, They are waiting on a revised charm. I am putting that together now.
[18:50] <gary_poster> sinzui, ah ok, no I meant the fact that search is broken on 8086
[18:51] <gary_poster> sinzui, jcastro wfm now.  jcastro works for you?
[18:51] <hatch> jcastro: wow osx port of juju? well done
[18:51] <gary_poster> sinzui, bug and possible "proper" fix here: https://bugs.launchpad.net/juju-gui/+bug/1200337
[18:51] <_mup_> Bug #1200337: gui charm should only get npm cache when building <juju-gui:Triaged> <https://launchpad.net/bugs/1200337>
[18:51] <gary_poster> sinzui, have not tested
[18:51] <jcastro> Charm API server did not respond
[18:51] <jcastro> is what I get
[18:52] <sinzui> rick_h, your autocomplete changes are in production as of this minutes, but I think squid has cached some of the old representations
[18:52] <jcastro> oh dude, hard refresh fixes that, got it
[18:52] <gary_poster> ok cool thanks jcastro
[18:54] <sinzui> gary_poster, rick_h, what is the state of the autocomplete branch. The changes just went into production. I was not expecting regressions, only new features for autocomplete
[18:57] <sinzui> gary_poster, I expected your charm changes to be based on the stable charm: https://code.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk
[18:57] <gary_poster> sinzui, sorry, no, but you probably can apply the revision
[18:57] <sinzui> oh, fab, yes I can thanks gary
[19:09]  * Makyo -> lunch
[19:12] <hatch> my fan sounds like an old 486 when it changes directions
[19:12] <hatch> maybe it is.....
[19:17] <jcsackett> jujugui: can i get two reviews of https://codereview.appspot.com/10944045/, please?
[19:29] <jcastro> hey guys how long does it take for the gui to show a change in the store?
[19:29] <jcastro> I just added a bunch of categories
[19:31] <rick_h> jcastro: 15min ish
[19:32] <rick_h> sinzui: AC is in progress. Needs another review and some updates from me. I figure to get it landed in the morning hopefully
[19:32] <sinzui> okay
[19:33] <jcastro> rick_h: thanks
[19:33] <sinzui>  I can participate when I webops doesn't need me
[19:33] <rick_h> sinzui: https://codereview.appspot.com/11126043/ is the in progress review
[19:33] <jcastro> ok so now that I am using the search for all these fixes
[19:33] <rick_h> sinzui: ok
[19:33] <jcastro> I am totally confused on how to navigate
[19:33] <rick_h> jcastro: ?
[19:33] <jcastro> ok so I click on the juju button
[19:33] <jcastro> then I browse by category
[19:33] <jcastro> say apps
[19:34] <rick_h> jcastro: so once you start searching you're done for. 
[19:34] <rick_h> jcastro: there's work in progress to add some breadcrumbs/better nav
[19:34] <jcastro> yeah I need a way to go back
[19:34] <jcastro> oh ok
[19:34] <rick_h> jcastro: but yea, known issue
[19:34]  * jcastro nods
[19:34] <jcastro> also
[19:34] <jcastro> I does anyone know what we put in "file-servers"? 
[19:35] <rick_h> jcastro: ceph? samba? I'm not sure tbh
[19:35] <rick_h> jcastro: feel free to use the back button to help nav. It should work to get you where you were
[19:35] <jcastro> yeah
[19:39] <rick_h> time to mow the lawn...yay me
[19:39] <sinzui> rick_h, looking
[19:40] <rick_h> sinzui: cool, thanks. I'll have the updates requested first thing in the morning and will get hatch to ok before he gets sidetracked :)
[19:40] <hatch> too late, I've already been sidetracked for tomorrow
[19:51] <hatch> the moment when you realize fixing tests is taking longer than the code you wrote
[19:57] <bcsaller> hatch: only when I TDD can I avoid that but my TDD skills are not always up to the task
[20:00] <jcsackett> bcsaller: thanks for the review. jujugui, can i get one more review on https://codereview.appspot.com/10944045/
[20:00] <benji> jcsackett: I'll do one.
[20:00] <jcsackett> benji: thanks!
[20:02] <benji> jcsackett: LGTM
[20:03] <jcsackett> thanks, benji.
[20:20] <bac> jujugui: i need reviews on https://codereview.appspot.com/11182044 please
[20:21] <benji> bac: I'll take one
[20:21] <bac> thx
[20:24] <jcastro> hey sinzui 
[20:24] <jcastro> can we make `juju deploy ubuntu` do the right thing? It's an old bug where the store can't handle "ubuntu" 
[20:27] <hatch> heh too much awesome in "ubuntu" ?
[20:27] <bcsaller> still need one review on https://codereview.appspot.com/11181043
[20:30] <bac> thanks bcsaller and benji
[20:30] <benji> my pleasure
[20:31] <bac> benji: that other guy sure messes up your nick tab completion
[20:31] <benji> heh
[20:35] <sinzui> jcastro, I don't hack on juju. How is that broken? I assume it deploys a charm named ubuntu (that presumably is a vanilla install)
[20:36] <jcastro> yeah it's just a blank server
[20:43] <hatch> jujugui looking for two reviews https://codereview.appspot.com/11186043/
[20:43] <bcsaller> hatch: I can take one
[20:43] <hatch> thanks
[20:46] <jcsackett> hatch: i can take the other.
[20:46] <hatch> awesomer
[20:51] <gary_poster> hatch I qa'd fwiw.  nice
[20:51] <sinzui> jcastro, I think I found your bug about deploying ubuntu. It certainly is in the store: https://store.juju.ubuntu.com/charm-info?charms=cs:precise/ubuntu&stats=0
[20:51] <hatch> great thx
[20:53] <jcsackett> inspector is looking pretty cool.
[20:55] <hatch> yeah it's coming together nicely
[20:58] <gary_poster> hatch, bcsaller, interesting bug to explore next week: 1000-unit service in sandbox with simulator on is unresponsive every 1 second (delta push?).  Made a card.  inspector-specific
[20:59] <hatch> unpossible!
[20:59] <gary_poster> :-)
[20:59] <bcsaller> gary_poster: yes, I've seen that too, the timeline profile does indicate its tied to the delta
[20:59] <gary_poster> something fun to debug, hopefully nothing paradigm shifting
[21:00] <gary_poster> huwshimi, whoa man, you are starting earlier and earlier :-)
[21:00] <huwshimi> gary_poster: Morning :)
[21:00] <hatch> maybe he is moving west
[21:00] <hatch> :)
[21:01] <gary_poster> Makyo was working on getting your branch landed again, working with fixes from rick_h IIRC
[21:01] <Makyo> Juuust pushed.
[21:01] <arosales> gary_poster, I see the apache2 icon is showing the category instead of the icon.svg
[21:02] <Makyo> lp:~makyo/juju-gui/visual-update-4
[21:02] <jcastro> sinzui: I wonder if the new add-machine command means we don't need it anymore
[21:03] <gary_poster> arosales, AIUI there is a problem with that svg.  I emailed you and jcastro about it.  The category icon is actually a new improvement thanks to sinzui: it was simply not rendering any image
[21:03] <hatch> gary_poster: bcsaller the 'overview' viewlet is being touched 1000 times every second
[21:03] <hatch> this might be related to the d3 thingy
[21:04] <gary_poster> Makyo, awesome thanks.  huwshimi do you want to take it from here, or what?
[21:04] <gary_poster> I'd like to get it landed asap one way or another, and it sounded like it needed some important fixes
[21:04] <huwshimi> gary_poster: Can do, let me take a look
[21:05] <gary_poster> thanks huwshimi.  ping us when you want us to review or approve or whatever is appropriate
[21:05] <hatch> updated the card
[21:05] <sinzui> jcastro, my local deploy is of ubuntu is fine. (juju deploy ubuntu)
[21:05] <gary_poster> benji, hatch, what do we need to do to get the destroy branch landed?
[21:06] <Makyo> huwshimi, gary_poster I adjusted some things based on comments, but I'm not sure where the original stuff came from; take those or leave those as you need.
[21:06] <benji> gary_poster: I need the linter to stop abusing me
[21:06] <Makyo> s/stuff/design
[21:06] <Makyo> I guess I can use my big programmer words.
[21:06] <gary_poster> lol
[21:06] <benji> it will land in just a few seconds
[21:06] <gary_poster> benji, awesome thanks
[21:06] <hatch> benji: ping me when it's up and I'll do another QA
[21:07] <arosales> gary_poster, was that email sent today. I am not finding it. But  I will take a look
[21:07] <gary_poster> arosales, no, not today, looking
[21:10] <sinzui> arosales, The category issue that cause a non-existent icon to appears is in user data...outside of our control. We fixed that by filtering out categories we don't know about. As of two hours ago, icon.svg files that don't convince magic that they are genuine svgs are ignored
[21:11] <sinzui> ^ this last change address that fact that apache2's charm has a png claiming to be an svg
[21:12] <hatch> benji: I think you applied the pointer:cursor to the wrong element other than that LGTM
[21:15] <huwshimi> gary_poster: What's your opinion on how to know which changes to make? Do I go by the designs or on the feedback in the review?
[21:16] <arosales> sinzui, hmm the apache2 icon ~should~ have been valid, but I'll re-upload the one design sent
[21:16] <huwshimi> gary_poster: (And that's not me trying to pick a fight, I'm just trying to figure out which changes to make...)
[21:16] <gary_poster> huwshimi, :-)
[21:17] <benji> hatch: indeed, thanks
[21:17] <sinzui> arosales, does "file icon.svg" say it is an svg?
[21:17] <sinzui> it says it is a png for me
[21:17] <gary_poster> huwshimi, want to have an early call in guichat?
[21:17]  * Makyo walks dogs quick (or not so quick - so hot, gonna have to hose them off first).
[21:18] <huwshimi> gary_poster: Sure
[21:20] <sinzui> arosales, while nautilus wont show me the icon for apache's icon.svg, it will if I rename it to icon.png
[21:20] <arosales> sinzui, http://pastebin.ubuntu.com/5866259/
[21:21] <sinzui> yeah I just did the same. We agree
[21:21] <sinzui> arosales, I think I have the charm template. I can try making a replacement as I queue for you division
[21:22]  * sinzui has great hope that gui will be deployed in the next 20 minutes
[21:23] <arosales> sinzui, I am little confused as to why the browser isn't currently parsing the current icon.svg
[21:24] <arosales> sinzui, but really what ever we need to do go get to to render correctly I am a +1
[21:25] <sinzui> arosales, the browser did parse it. I saw it lied and decided not to get involved with a possible malicious vulnerability
[21:25] <sinzui> It saw the icon is a lie
[21:25] <sinzui> arosales, pngs don't scale well either
[21:26] <arosales> sinzui, do you need me to commit a version  I got from design which should be the same thing.
[21:27] <sinzui> arosales, if you have a genuine svg, then go ahead and commit it. If not, I can make something. I just found the official apache logo svg that I can use with the templte
[21:27] <sinzui> gary_poster, you might need to sit down for this...
[21:27] <gary_poster> sinzui, uh oh
[21:27] <sinzui> gary_poster, juju-gui is deployed and the right version...
[21:27] <gary_poster> sinzui, YAY!
[21:27] <gary_poster> sinzui, thanks, and thanks to IS!
[21:27] <sinzui> No one, not even webops can see the site at the ip it is deployed too
[21:28] <gary_poster> lol
[21:28] <gary_poster> ok
[21:28] <sinzui> thedac will try to ssh tunnel into to see the site render with the proper UI
[21:28] <sinzui> I need to file an rt to get the IPs public
[21:28] <arosales> sinzui, I'll confirm the one design sent is a _real_ svg
[21:28] <arosales> if not I'll get that one and re commit
[21:30] <hatch> bcsaller: mind finishing up that review? :)
[21:30] <bcsaller> hatch: sorry, got sidetracked with the perf issue
[21:30] <bcsaller> back on it
[21:30] <hatch> hey that's for next week :P
[21:30] <hatch> was it the d3 thingy?
[21:32] <hatch> no matter how much I try to prepare I'm always way behind on house stuff for a sprint
[21:36] <bcsaller> hatch: no, not d3 :-p   It looks like sandbox calls sendDelta for each new unit in the loop which calls update for units which renders the template 1000 times for 1000 units
[21:37] <hatch> ohh lol
[21:37] <hatch> glad it wasn't the d3 thing, that thing is cool
[21:41] <arosales> sinzui, uploaded an svg for apache. We'll see if that helps.
[21:41] <arosales> gary_poster, sinzui thanks for the explanation there
[21:41] <gary_poster> thanks arosales 
[21:42] <arosales> gary_poster, icons and categories are looking better. But if design can get us some more we will add those.
[21:42] <arosales> I'll do another check post what design is able to give us in terms of icons.
[21:44] <benji> gary_poster: branch landed (finally)
[21:44] <gary_poster> benji, yay thanks! :-)
[21:44] <sinzui> gary_poster, thedac confirmed that the gui is operational in production. I am now creating an rt to ask that the IPs be public
[21:45] <gary_poster> sinzui, even better, thank you :-)
[21:50] <hatch> hmm I can't submit this branch
[21:50] <hatch> it says it's out of date but there are no changes when I pull
[21:50] <hatch> and it says it's up to date when I use bzr update
[21:52] <hatch> yeah it's definitely out of date
[21:55] <hatch> cleared it out and trying again
[21:55] <gary_poster> hatch could you give me the link of your most recent header prototype again pls?
[21:55] <hatch> http://jsbin.com/utitov/3/edit
[21:55] <gary_poster> ty
[21:55] <hatch> I haven't done any work on it since this morning
[21:56] <gary_poster> ack
[22:07] <hatch> just playing around with trunk
[22:07] <hatch> the inspector is comign along really nice
[22:08] <hatch> keehee
[22:08] <hatch> I can switch between inspectors all day long watching that status bar move around :)
[22:08] <hatch> simple things....simple minds I guess :)
[22:09] <rick_h> gary_poster: reply inbound. Taking the boy to dinner, but please let me know if that doesn't clear up the discussion.
[22:09] <gary_poster> cool, thanks rick_h !
[22:11] <hatch> gary_poster: next task on my list? I was thinking of working on the header of the inspector
[22:11] <gary_poster> hatch, sounds good.  that will move the scroll down to the bottom div?
[22:11] <gary_poster> a bottom section I mean, sorry
[22:12] <hatch> yeah so we would have Status and Settings, as well as the header with the icon and title visible at all times
[22:12] <hatch> to match v7 design
[22:12] <gary_poster> cool
[22:14] <hatch> bac: really cool technique on the slider but why didn't you set the slider orientation to vertical instead?
[22:14] <gary_poster> jujugui if anyone wants to come to the call with huw that would normally be in 16 minutes, please come now! :-)
[22:31] <Makyo> New bug, hopefully small fix: #1200412
[22:31] <_mup_> Bug #1200412: drag-and-drop: dropping a service on a non-drop target leaves the token appended to the body <juju-gui:New> <https://launchpad.net/bugs/1200412>
[22:46] <huwshimi> rick_h: Sorry for the confusion about the home/back link. Any pointers on what I need to set to get back to the initial screen for the sidebar. Fire viewNavigate something...
[22:49] <hatch> gary_poster: did you let slip that we are doing another Friday EOD release? :P
[22:50] <hatch> bcsaller: so are you thinking of creating a throttling method for update?
[22:50] <hatch> so it only allows the ux to update once per second?
[22:50] <hatch> UI
[22:51] <bcsaller> hatch: there are a few related fixes, that one and making sure the bindings list we generate is unique 
[22:52] <hatch> ahh great great
[23:07] <huwshimi> gary_poster: Do I need another lgtm or is the one from rick_h and changes from Makyo enough?
[23:07] <Makyo> LGTM :)
[23:09] <huwshimi> Makyo: Thanks :)
[23:19] <hatch> Makyo:  huwshimi here ya go http://i.qkme.me/3v5d87.jpg
[23:20] <Makyo> Pff hahaha
[23:20] <Makyo> Meanwhile: http://blog.anguscroll.com/if-kerouac-wrote-javascript
[23:20] <hatch> lol
[23:26] <huwshimi> haha
[23:26] <huwshimi> hatch: Can I just use that for all my reviews from now on then?
[23:27] <hatch> lol
[23:27] <hatch> maybe
[23:46] <rick_h> huwshimi: yea, to get back we'll need to fire viewNavigate with a valid change object. We can bind that link in the events object for the view it's rendered in
[23:51] <rick_h> huwshimi: did the viewmode controls changes make sense?
[23:52] <huwshimi> rick_h: Yeah that was great, thanks.
[23:53] <rick_h> huwshimi: ok, going to put the little guy to bed/bath. I'll check in if yuo need anything else. 
[23:56] <huwshimi> rick_h: Thanks, I'll see how I go.