[00:13] <rick_h> huwshimi: so thought about it and viewNavigate isn't needed. Home is just the hard coded path of either /sidebar or /fullscreen based on the isFullscreen param
[00:13] <rick_h> huwshimi: so I'd just make the template have those links and not try to fire custom stuff
[00:14] <rick_h> that is what we mean by "Home" right?
[00:18] <huwshimi> rick_h: Well, the sidebar needs to be able to navigate back from the search results or a category without closing the charm panel...
[00:20] <rick_h> bcsaller: still around?
[00:20] <bcsaller> rick_h: yes
[00:20] <rick_h> bcsaller: looking at your branch with the icon, does that work? We never have an icon value so wondering where it's binding to/from?
[00:21] <rick_h> huwshimi: right, so on search results, home would purely be a link to /sidebar or /fullscreen.
[00:21] <bcsaller> The ghost inspector sets it from the charm data onto the service so it works in that single case
[00:21] <rick_h> huwshimi: or what is the 'charm panel'?
[00:22] <bcsaller> we have notes that we need a more general solution
[00:22] <huwshimi> rick_h: I think it would need to be "/sidebar/precise/ceph-12/"
[00:22] <rick_h> bcsaller: right, I'm with you on notes. Known issue and Makyo hit it with his work to include an icon but wasn't sure how this fit
[00:22] <rick_h> huwshimi: ah, gotcha.
[00:22] <rick_h> bcsaller: ok, so you're getting it from Makyo's work then which is getting it from the Store if it has it. Cool
[00:23] <bcsaller> rick_h: yes, its based on that work
[00:23] <rick_h> bcsaller: cool, that helps. Thanks.
[00:28] <rick_h> huwshimi: so it sounds like the only thing we're changing is clearing search. So yea, a viewNavigate with a change object of {search: false; query: {};hash: undefined} would reset it
[00:29] <rick_h> or query: undefined I guess is simpler
[00:29] <huwshimi> rick_h: Ah, that sounds promising.
[00:30] <rick_h> that would leave the viewmode and the charmid alone which are the two parts you want to keep consistent
[00:32] <huwshimi> rick_h: I was thinking of building this inside charm-search.js. But inside that file, and its corresponding template it doesn't have the isFullscreen variable. Any idea how I might get access there?
[00:33] <rick_h> huwshimi: sec
[00:33] <rick_h> huwshimi: I was thinking it would be part of the sidebar/fullscreen views and that has it. It could go in subapp/views/view.js
[00:33] <rick_h> and be shared between them.
[00:34] <rick_h> Now I guess, when does "home" show up? Is it always there? Or only during a search?
[00:34] <huwshimi> rick_h: It only apears during a search (including viewing a category), or if you're viewing a charm in full-screen mode
[00:34] <rick_h> huwshimi: who's rendering the html link I guess?
[00:35] <huwshimi> rick_h: The HTML needs to exist in that header (hence me wanting to put it in charm-search.js)
[00:35] <rick_h> huwshimi: oh, in the charm-search widget?
[00:35] <huwshimi> rick_h: Yeah
[00:36] <rick_h> huwshimi: ah, so the *right* way to do that then is to create a new event in the widget, like the "search changed" event now that's a "GO_HOME" event. Then anyone that creates a new Search() widget needs to bind to that event and fire the viewNavigate when it happs.
[00:36] <rick_h> huwshimi: just like the SEARCH_CHANGED event works now
[00:36] <huwshimi> rick_h: OK.
[00:37] <rick_h> huwshimi: hmmm...so then the trick is that you need to supress that link from the widget when it's not a search/charm details view. :/
[00:37] <huwshimi> rick_h: I'll still need to know when to hide/show that control, but I guess I can do that in the parent view
[00:37] <huwshimi> heh
[00:38] <rick_h> huwshimi: yea, thinking. We've not really had conditional stuff like that.
[00:38] <huwshimi> rick_h: Yeah, there are a few other cases I'm going to need to do similar stuff to change headers etc. depending on the particular view
[00:38] <rick_h> huwshimi: ok, so the subapp/browser/views/view.js has a charmID attribute. So if that's set you're looking at a charm.
[00:39] <huwshimi> (stuff outside the view content)
[00:39] <rick_h> huwshimi: that gets you part way there.
[00:39] <rick_h> huwshimi: so you'd need to add a flag in the _renderSearchWidget based on if there's a charmID...and then the other one is if you're in search mode or not.
[00:39] <rick_h> huwshimi: well, you want 1) "isFullscreen and charmID is set...show the link"
[00:40] <rick_h> 2) "Search results are being shown"
[00:40] <rick_h> 1) you're set on
[00:40] <rick_h> 2) I'm looking
[00:40] <rick_h> huwshimi: you can check the filters object.
[00:40] <rick_h> huwshimi: the same View has a filters ATTR, if those are set to something you should be in a search.
[00:41] <rick_h> huwshimi: the only problem with that is we still have default filters set. We've not removed them in a branch yet
[00:41] <rick_h> huwshimi: so those have to go as well.
[00:42] <rick_h> then if any fitler is set, you're doing a search.
[00:42] <rick_h> huwshimi: because in the filters is the query being search, or the category selected when viewing a category
[00:42] <huwshimi> rick_h: This is looking like a job that would probably take a day. So might not be feasible once I've gotten through my other list of things...
[00:43] <rick_h> huwshimi: k, yea. It's not as simple as I'd hoped because of the new conditional rules.
[00:43] <huwshimi> :(
[00:43] <rick_h> huwshimi: the other thing is to always show a home link to start out
[00:43] <rick_h> and add the conditions as follow ups
[00:44] <huwshimi> rick_h: I'm guessing the search/categories bug I filed is probably not trivial either?
[00:46] <rick_h> huwshimi: I don't think it's hard. I think the category links need a more specific viewNavigate change object.
[00:46] <rick_h> huwshimi: it's not clearing out enough stuff.
[00:47] <huwshimi> rick_h: OK, I might take a look at that later if I get a chance.
[00:52] <rick_h> huwshimi: yea, basically in browser/browser.js in the _getStateUrl it's merging the filters where it sounds like it should replace the data.
[00:52] <rick_h> line 81, this._filter.update(change.filter);
[00:53] <rick_h> it wasn an update so that as you changed yuor checkboxes in the filter it would add/subtract one item at a time.
[12:29] <benji> bac: I have finished walking through the email quagmire and am soon to reach the caffeine castle.  Once that journey is complete I can help you battle the CSS dragon.
[12:30] <bac> benji: the css quagmire was holding up the branch you reviewed yesterday.  the problem was a setting being inherited from bootstrap.
[12:30] <bac> benji: thanks, though.
[12:31] <benji> oh, good!
[12:31] <benji> I'll have to find a different dragon then.
[12:32] <gary_poster> benji, other dragons available.  ping me :-)
[12:33] <benji> will do
[12:36] <gary_poster> please review and land Huw's most recent branch ASAP: https://codereview.appspot.com/11209043/
[12:40] <bac> i'm reviewing the above
[12:41] <benji> I'll do a review too.
[12:47] <gary_poster> thanks
[12:58] <benji> jujugui: it is known that dragging of service inspectors is completely broken?
[12:58] <benji> I thought it was just the branch I am reviewing, but it happens on trunk too
[12:59] <gary_poster> luca__, rick_h I am swamped with meetings this morning.  I just sent out an email about the priorities for today.  Please review.  Also, could you please discuss together the home/back button issue and the search interaction issue between categories and text?  For each of these I would like an expedient solution we can implement today in an hour and land, which may require discussion.
[13:00] <gary_poster> rick_h, luca, I think these experiences are broken ATM, and my goal is to not be broken for this release.
[13:00] <gary_poster> benji, service inspectors are not draggable in Luca's design.  We may want them to be draggable to demo variation ideas from MS.  "Flexible"
[13:00] <bac> benji: http://uistage.jujucharms.com:8086/:flags:/serviceInspector/ is really borked
[13:00] <gary_poster> is goal
[13:01] <luca__> gary_poster: sure, I'll get in touch with Rick
[13:01] <benji> gary_poster: in that case they are broken on the trunk because they are partially draggable ;)
[13:01] <gary_poster> ok thanks
[13:11] <bac> benji: do you see the inspectors being completely broken on huw's branch?  no content for most 'tabs'.
[13:12] <rick_h> gary_poster: will do, I'm afk a little bit this morning but will try to meet up with luca
[13:12] <benji> bac: nope, I didn't click on any of the tabs; let me look real quick
[13:12] <benji> bac: yep, very broken
[13:12] <bac> benji: i'm unsure what we're supposed to be looking for.  luca__ do you know?
[13:20] <rick_h> sinzui: I'm still getting setup at the dealer here and might not make the standup. My branch for autocomplete is updated ready for final review by you and hatch.
[13:20] <rick_h> sinzui: will try to get into the call as there's some important stuff flying around atm.
[13:24] <sinzui> thank you rick_h
[13:28] <hatch> benji: bac inspectors are not supposed to be dragable
[13:29] <hatch> 8086 is also working as expected here
[13:29] <bac> hatch: some content drags and snaps back.  is that expected?
[13:31] <benji> bac: did you find out if the empty inspector tab issue was introduced on this branch or pre-existing in trunk?  If not I can test it quickly.
[13:31] <bac> benji: i did not yet
[13:31] <benji> bac: I'll take a look.
[13:31] <hatch> benji: it's a known issue - it happens when you open the inspector too quick after deployment
[13:32] <benji> ah, ok
[13:32] <benji> race conditions are fun
[13:32] <rick_h> run faster!
[13:33] <luca__> gary_poster: me and Ale have just had a meeting with MS and he's very happy with the inspector
[13:33] <luca__> gary_poster: there are some content changes but overall he was pretty positive
[13:33] <gary_poster> luca__, awesome :-)
[13:33] <luca__> gary_poster: said the new Juju looks f'ing amazing
[13:33] <gary_poster> lol :-)
[13:34] <hatch> bac: the dragging is not expected - that's not a known bug :)
[13:34] <luca__> bac: gary_poster do I need to look at anything?
[13:34] <bac> luca__: benji and i are looking at huw's branch https://codereview.appspot.com/11209043
[13:35] <bac> luca__: the description references some visual changes you requested but doesn't state what they are.  if you know and can verify the fix that would be helpful
[13:35] <luca__> bac: I can try to bar it
[13:36] <luca__> bac: bzr
[13:38] <luca__> bac: checking it now against the list of bugs I sent off
[13:39] <gary_poster> luca__, I need to have some help from you with the expedient plans for home/back and search interaction, but I'm swamped and rick_h is afk.  I will ping asap, 'cause these are biggest risks remaining IMO
[13:39] <gary_poster> I'm swamped on calls I mean
[13:39] <luca__> gary_poster: ok, I'm available most of the afternoon
[13:39] <gary_poster> thank you luca__
[13:39] <rick_h> luca__: gary_poster hopefully I can be free in the next hour
[13:39] <gary_poster> thanks rick_h
[13:41] <luca__> bac: gary_poster I can confirm that all of the bugs I submitted yesterday have been fixed in visual-update-5 apart from the 2 that have been stated in gary's email
[13:41] <gary_poster> luca__, great, thank you!
[13:41] <gary_poster> bac could you land when you are satisfied please?
[13:43] <bac> gary_poster: if there are small issues with the branch you want me to just fix them then land, i assume.
[13:43] <gary_poster> bac yes please
[13:43] <bac> cool.  i'll wait for benji's input (if it isn't there yet)
[13:44] <benji> bac: I just posted (not LGTM, unfortunately; big problem with the test runner)
[13:44] <bac> benji: rt
[13:44] <benji> bac: "rt"?
[13:45] <bac> benji: 'roger that'.  i think i've referenced my helicopter pilot fantasy before?
[13:45] <benji> heh
[13:57] <benji> gary_poster: I'm ready for a dragon quest.  Should I take up that NPM cache issue?
[13:57] <gary_poster> bac, did you mention to luca about whatever different assets we need for the zoom widget?
[13:57] <gary_poster> benji no one sec
[13:57] <benji> k
[14:01] <gary_poster> benji, oscon tasks have highest priority today.  I sent email and have new "urgent" kanban section.  If bac could use help in fixing Huw's branch, that would be best use of time.  Otherwise see urgent section of kanban
[14:01] <bac> gary_poster: what we have may work, though limited to a fixed size slider.
[14:02] <benji> gary_poster: will do
[14:02] <benji> bac: I described the problem with the body styling and test runner in the review, but I could easily work up a patch.
[14:02] <bac> gary_poster: this page has an example using very similar assets. http://yuilibrary.com/yui/docs/slider/slider-from-markup.html  the issue is the lack of separate images for the rail and end caps
[14:03] <bac> benji: i'll ping you if that'll be more efficient
[14:03] <benji> k
[14:04] <gary_poster> bac, ack. luca, ^^^ is that enough info to ask jaime for what we need?  AIUI, as a convenience it would be great if he could simply slice the images per the example above
[14:04] <gary_poster> sorry, luca__ ^^^
[14:05] <bac> gary_poster: there is also the possible issue of the thumb image being a sprite with embedded shadow.  unsure how much of this YUI skinning should be pushed to jamie
[14:05] <gary_poster> bac, when you say "unsure how much" you mean we possibly/probably should not push it to him, because we will be better able to identify what we need?
[14:06] <gary_poster> and it is simply a matter of slicing?
[14:06] <bac> gary_poster: i'm saying YUI skinning has very specific requirements and it is unclear who should ferret them out.
[14:08] <gary_poster> bac ok.  luca__ scratch that scrollbar request for now :-) thank you
[14:09] <jcsackett> jujugui: head's up, i have an appliance repair dude showing up at 11, so i'll be absent for the retrospective. i don't see any cards i have a strong feeling about, so you shouldn't feel my loss very keenly. :-P
[14:09]  * benji feels a vague sense of loss.
[14:11]  * jcsackett laughs
[14:15] <benji> gary_poster: I would ideally tackle one of the two criticals that have yet to be claimed.  They both list needing to be discussed, have they been?
[14:16] <bac> benji: how do i reproduce the test failure you saw?
[14:17] <benji> bac: its not so much a test failure, but a failure of the tests.  Run the tests, wait for them to end, try to scroll up, feel frustrated and listless.
[14:18] <bac> benji: i ran 'make test-server' and i can scroll around a-ok in chrome.  what am i missing?
[14:18] <bac> benji: but i do feel listless
[14:18] <benji> bac: let me replicate it again, one second
[14:19] <hatch> lol
[14:20] <luca__> gary_poster: was dealing with something, is there anything you need?
[14:21] <hatch> luca__: I think the 'reviewed' icons look like 'favourite' buttons
[14:21] <hatch> just sayin :)
[14:21] <luca__> hatch: your not the only one to say that, we are testing it on monday and tuesday with 10 users from the inductry
[14:22] <hatch> rick_h: and I decided a better symbol would be two lions fighting over a steak with a shark jumping overhead
[14:22] <luca__> hatch: +1 I'll get jamie to mock something up :D
[14:23] <hatch> lol
[14:24] <hatch> so huw's branch added overflow: hidden to the body, but something added overflow: auto to the element
[14:24] <hatch> causing the scroll bar to re-appear
[14:25] <gary_poster> benji, they have not yet been discussed.  not ready
[14:25] <benji> k
[14:26] <gary_poster> luca__, nothing I need right now thanks, till Rick is ready
[14:26] <rick_h> luca__: ping for when you get time to chat
[14:26] <gary_poster> ooh ooh!
[14:26] <rick_h> gary_poster: too since it makes him so happy :)
[14:27] <gary_poster> :-)
[14:27] <gary_poster> I will join if I can but I have another call for now.  Very excited about possibility of getting a reasonable quick resolution to those issues though :-)
[14:27] <benji> bac: I can't reproduce the error now.  I don't know what happened.  So you can disregard the patch part of that comment, but the part about removing the now-redundant code still applies.
[14:27] <rick_h> hatch: would really appreciate if you can re-look at the AC branch this morning so I can get that in/up.
[14:27] <bac> benji: done
[14:28] <rick_h> gary_poster: heh, don't get your hopes way way way way up :P
[14:28] <gary_poster> :-/
[14:28] <gary_poster> ok
[14:29] <rick_h> sinzui: while I wait to get some time with luca__ did you want to chat for a sec for anything hangout related?
[14:30] <luca__> rick_h: I'm free you need anything
[14:30] <rick_h> luca__: ok, will send an invite one sec
[14:30] <luca__> rick_h: hatch is this better for the reviewed icon? https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1WWwyd2cyLWtrWWc/edit?usp=sharing
[14:30] <gary_poster> luca__, LOL!
[14:30] <hatch> BAHAHAHAHAHA
[14:31] <luca__> hehe
[14:31] <rick_h> luca__: https://plus.google.com/hangouts/_/0c7a8746abe1e765bf1f06cd256f317702da126d?hl=en
[14:31] <gary_poster> antdillon hey https://plus.google.com/hangouts/_/b00dc841a3b70c4f357210452e531a462a28841a
[14:31] <hatch> do it do it!!!!
[14:31] <rick_h> luca__: O...M...G on the icon
[14:31]  * gary_poster still giggling
[14:32] <antdillon> gary_poster, Im there
[14:32] <bac> jujugui: what are the steps to use lbox to submit another's branch?  how does it link my local branch to huw's MP?
[14:33] <hatch> bac: are you going to land huw's branch that you NLGTM'd?
[14:33] <Makyo> bac, -adopt, I think
[14:33] <bac> hatch: catch up man.  I changed my vote.
[14:33] <hatch> ohh lol ok well one second
[14:33] <bac> Makyo: is that really all that is requried
[14:34] <hatch> there is a breaking change in my QA
[14:34] <Makyo> bac, no clue :D
[14:34] <Makyo> bac, the docs for lbox are...well...
[14:34] <hatch> what...there are docs for lbox? ;)
[14:34] <bac> Makyo: i branched trunk into a 'review' branch then merged his branch in.  can lbox really link it all together?
[14:35] <bac> 'lbox submit -h' isn't too clear on what happens.  guess i can try.
[14:35] <bac> hatch: so i'm waiting on a review from you?
[14:35] <hatch> bac: I just qa'd see my comments as one thing needs to be fixed before it lands in trunk
[14:36] <bac> hatch: the overflow issue is resolved per benji's review suggestion
[14:36] <Makyo> bac, I've never had the chance to try, I juist know the option exists.
[14:37] <bac> Makyo: ditto.  i'll report back.
[14:37] <hatch> bac: ohh ok - I thought that would do the exact opposite of what we wanted
[14:37] <hatch> the bigger issue is the small charm config when not under the flag
[14:38] <bac> hatch: i don't understand what you mean.  wanna chat?  might be fastest
[14:39] <hatch> sure
[14:39] <hatch> in guichat
[14:44] <bac> hatch: rejoining
[14:44] <hatch-mobile> bac sorry it all crashed, rebooting
[14:46] <rick_h> bac: so when I did his stuff I just created a branch under my name, merged his stuff in, pushed to my account, and re-lbox'd it references his codereview url in a self-LGTM as the dicussion was over there and then submitted it
[14:46] <rick_h> sinzui: ok, off that call, shifting up what I'm working on based on emails and such. Let me know if we need to sync up.
[14:46] <bac> rick_h: sweet, thanks for the details
[14:47] <bac> but now i'm super curious about -adopt
[14:47] <sinzui> rick_h, I see you have already claimed one of the important issues on the board
[14:47] <rick_h> sinzui: so I put back those as they're considered lower priority than fixing the home button according to luca and gary_poster's email
[14:48] <sinzui> yep, I saw you do that
[14:48] <rick_h> the other things lower on the priority list are all dependant on removing the filters UI and the default filter settings. So they're nice to have but will be more work than EOD will allow
[14:48] <sinzui> kanban doesn't tell you who is watching
[14:48]  * rick_h feels stalked
[14:48] <rick_h> :P
[14:49] <hatch> bac: ok I'm back now but I have to set my env back up - were you able to reproduce with mysql?
[14:49] <bac> hatch: no, it looks good to me
[14:50] <hatch> ok one minute I'll set this back up
[14:50] <Makyo> jujugui call in 10 kanban now
[14:50] <bcsaller> hopefully my lbox submit finishes before then :(
[14:51] <hatch> jsbin is down :(
[14:52] <gary_poster> rick_h, hey, you still talking?
[14:52] <rick_h> gary_poster: done talking atm
[14:52] <antdillon> gary_poster, Oh forgot to say, I am off on Monday (its my stag do this weekend) I will be starting on Tues
[14:53] <gary_poster> antdillon, oh cool, congrats and have fun. :-) see you Tuesday then.  Maybe we'll have more for you to work with by then :-)
[14:54] <gary_poster> rick_h, mind joining guichat real quick to summarize plans for me?
[14:54] <rick_h> gary_poster: yep one sec
[14:54] <bac> hatch: you still rebooting?
[14:54] <gary_poster> thanks
[14:54] <hatch> bac: yup just booting up the env
[14:54] <hatch> (i really gota setup a script for this)
[14:57] <rick_h> gary_poster: joining
[14:57] <gary_poster> jujugui call in 3
[15:00] <hatch> bac take a look at my screen for the bug
[15:03] <rick_h> hatch: sinzui https://codereview.appspot.com/11126043/ is updated, comments replied to, tests updated. let me know if there's anything else needed.
[15:04] <bac> benji: you still have huw's branch marked bad.  do you want another pass or just land with your dissent?
[15:04] <benji> bac: I'll re-mark now
[15:04] <bac> but it'll be a lie!  :)
[15:04] <sinzui> rick_h, criss-crossed. You got my LGTM
[15:07] <bac> gary_poster: that sounds like a good check for 'charm proof'
[15:21] <adeuring> abentley: could you please have another look at https://code.launchpad.net/~adeuring/charmworld/get-file-content-from-bzr/+merge/173987 ?
[15:22] <abentley> adeuring: Sure.
[15:24] <abentley> adeuring: I don't understand "I chose to return the branch's directory instead of the branch itself because the directory is needed as an entry in the charm_data dictionary during test setup".  You can get the directory from the branch, as I explained.
[15:24] <adeuring> abentley: I know, but that's not what is needed in tests -- it's the directory
[15:26] <abentley> adeuring: So you're saying it was for convenience?
[15:27] <adeuring> abentley: yes
[15:27] <abentley> OK
[15:28] <abentley> adeuring: at 103, you are patching BZR_EMAIL into the environment, but bzr_isolation should do that for you.
[15:28] <adeuring> abentley: ouch, forgot hat... I'll fix it
[15:44] <abentley> adeuring: r=me.
[15:44] <adeuring> abentley: thanks
[16:01] <sinzui> Bugger. webops are creating unversioned tarballs.
[16:04] <sinzui> gary_poster,  or bac: Webops asked that we add an upgrade hook  to the juju-gui stable charm to handle cases where we want to deploy a new release of the app. This seams easy enough, but now I see the webops scripts create unversioned tarballs. There is never a config change to indicate to the backend to unpack the tarball.
[16:05] <gary_poster> sinzui, the tarballs are always named the same?
[16:05] <sinzui> yes
[16:05] <gary_poster> :-/
[16:05] <bac> yes, :(
[16:05] <sinzui> I see other problems with their script
[16:05] <gary_poster> sinzui, easiest solution is to add revid to the tarball name
[16:05] <gary_poster> if unversioned
[16:05] <sinzui> the source is hardcoded. They need to edit the script each deploy.
[16:06] <sinzui> I'll propose a replacement script that makes it easy for them and us to do a deploy of just the app
[16:07] <gary_poster> sinzui, cool, thanks.  is this documented on your wiki page?
[16:07] <sinzui> No.
[16:08] <sinzui> I got a pastebin copy of the script. https://pastebin.canonical.com/94228/
[16:08] <sinzui> The version was changed yesterday to my request, but the script will need to be edited again for the next request :(
[16:09] <rick_h> luca__: around?
[16:12] <gary_poster> bcsaller, could you let me know what you think about in terms of difficulty of getting those export issues addressed?
[16:13] <gary_poster> when you've had time, of course
[16:18] <bcsaller> gary_poster: I'm reviewing them now, there are some questions, like qualified charm name, precise/mysql-1 or cs:precise/mysql, including rev, etc? Just not sure yet, making notes on some of the bugs
[16:21] <benji> Makyo: what browser were you using when you saw bug 1200412?
[16:21] <_mup_> Bug #1200412: drag-and-drop: dropping a service on a non-drop target leaves the token appended to the body <juju-gui:In Progress by benji> <https://launchpad.net/bugs/1200412>
[16:21] <Makyo> benji, Chrome v28
[16:24] <benji> Makyo: hmm, I'm running the same and I can't reproduce the symptoms listed in the bug.
[16:24] <rick_h> luca__: take two, would love a sec to chat.
[16:24] <Makyo> Checking..
[16:25] <luca__> rick_h: sure
[16:25] <luca__> rick_h: got a hangout?
[16:25] <rick_h> couple of ? for you luca. Hangout?
[16:28] <Makyo> benji, hmm, quick chat so I can screenshare?
[16:28] <benji> Makyo: sure, guichat is open
[16:41] <hatch_> sorry was dc'd
[16:42] <hatch_> reposting - bcsaller: re your 250ms comment - I'm OK with either approach just curious if you were planning on changing to rate limiting vs debounce or leave it for now?
[16:42] <bcsaller> hatch_: I left it for now, I think it will be fine the way it is, but we can keep an eye on it
[16:42] <hatch_> alright sounds good :)
[16:44] <hatch_> why do I have to add my ssh key to be able to pull from our bzr repo...did it get locked down by accident? :)
[16:55] <bcsaller> hazmat: ping
[16:56] <hazmat> bcsaller, pong
[16:56] <bcsaller> hazmat: can you check the comment in https://bugs.launchpad.net/juju-gui/+bug/1200625 and see if that export matches your needs
[16:56] <_mup_> Bug #1200625: gui export is exporting invalid config options / not respecting type when serializng <juju-gui:New> <https://launchpad.net/bugs/1200625>
[16:56] <bcsaller> that includes service output, annotations and config changes
[16:56] <hazmat> hmm
[16:56] <hazmat> i was going against uistage.jujucharms.com:8086
[16:56] <hazmat> maybe that's not on a cron
[16:57] <hazmat> bcsaller, might be some noise then.. your comment export looks good to me,
[16:57]  * hazmat checks trunk
[16:57] <bcsaller> hazmat: that export is from my current branch, I didn't change the options handling but the other things were changed, I have to propose this
[16:57] <hazmat> oh
[16:57] <hazmat> gotcha
[16:58] <bcsaller> if it looks good then it should be ready
[16:58] <bcsaller> but the options handling seemed sane out of the box
[17:00] <hazmat> bcsaller, the yes/no thing correspond to booleans in yaml
[17:00] <hazmat> but the type is a string
[17:01] <hazmat> ie when that gets passed to juju core it will barf on debug setting
[17:01] <bcsaller> sounds like an import error ;)
[17:01] <hazmat> since it per the charm config schema it should be a string, but comes in as a bool
[17:01] <hazmat> not really
[17:01] <hazmat> its two bugs
[17:01] <hazmat> sorry phone call
[17:01] <hazmat> exporting default
[17:02] <bcsaller> its going out as a string here, the parse side translates it to a bool in implicit conversion which is wrong
[17:03] <bcsaller> wait, you don't want me to export if its the default value on the charm? more work but I can do that
[17:08] <sinzui> gary_poster, http://comingsoon.jujucharms.com/ is up
[17:08] <gary_poster> awesome thanks sinzui!
[17:09] <gary_poster> hey luca, you really here? :-)
[17:09] <luca> gary_poster: just leaving
[17:10] <luca> gary_poster: if you send me an email ill pick it up
[17:10] <gary_poster> cool thanks luca ttyl
[17:23] <hatch> rick_h: https://bugs.launchpad.net/charmworld/+bug/1200704
[17:23] <_mup_> Bug #1200704: charm search autocomplete has slow options request times <charmworld:New> <https://launchpad.net/bugs/1200704>
[17:23] <rick_h> hatch: cool, will put on the board. Thanks.
[17:27] <hatch> rick_h: I LGTM'd the branch pending the css fix as everything else looked good - the clickoutside if you can't fix we can follow-up with a fix on that
[17:28] <rick_h> hatch: ok, will look into it in a little bit. Almost done with this home branch. A 'testing' we shall go...a testing we shall go...
[17:28] <rick_h> curses, luca left
[17:28] <hatch> high ho the dairy o a testing we shall go
[17:29] <hatch> not sure what a dairy o is
[17:29] <hatch> it's probably something horrible
[17:29] <rick_h> gary_poster: I've got the home link branch up here. lp:~rharding/juju-gui/home-link I was hoping to get luca to look before he left but :(
[17:30] <rick_h> gary_poster: I also found a decent fix for the search/category issue and have fixed it in there. I'm working on tests to support the changes but if anyone wants to QA in luca's place I'd love to hear it's what's expected.
[17:31] <gary_poster> rick_h, home link: thank you!  shoot him a mail.  he said he would be checking.  I'm sending him a couple too.  I'll look soon too, though if you are happy with it then I'm +1 on starting the review process.  search/category: even more awesome! I guess I'm the only one who can at this point unless you get luca's reply.
[17:32] <gary_poster> I will do so asap, though I have two emails I'm trying to plow through before then
[17:32] <rick_h> gary_poster: ok, will shoot him an email. Tests will add a little time but trying to get it going and up for review asap.
[17:32] <gary_poster> cool thanks you!
[17:32] <rick_h> gary_poster: understood, just a heads up on where we're at and such.
[17:32] <gary_poster> great
[17:37] <hatch> rofl https://twitter.com/horse_yui/status/355741939955544065
[17:43] <gary_poster> :-)
[17:45] <gary_poster> hey jcsackett , one of our goals that I'd forgotten about was that, when on jujucharms.com, instead of seeing "log out," you would see ...something else that I forgot.  A link to somewhere.  Did you do that as part of your default view work?
[17:45] <rick_h> time to acquire food, brb
[17:51] <arosales> gary_poster, could you or bac add additional details to https://bugs.launchpad.net/charm-tools/+bug/1200713 when you have an opportunity
[17:51] <_mup_> Bug #1200713: Charm Proof: Ensure the default configs match the defined type <Juju Charm Tools:New> <https://launchpad.net/bugs/1200713>
[18:00] <gary_poster> arosales, bac, added
[18:05] <arosales> gary_poster thank you.
[18:06] <hazmat> bcsaller, yes re default
[18:06] <bac> arosales: done too
[18:06] <bcsaller> hazmat: thats fine but it only masks this issue, doesn't prevent it
[18:06] <hazmat> bcsaller, re serialization in general, it would be good to cast to the specified config type as well. arguably its  a bug in core and one in the charm
[18:07] <bcsaller> yeah, re core
[18:12] <hatch> bcsaller: I see when you added the icon to the inspector you used the databinding for the header information
[18:12] <hatch> that information is not supposed to be in a viewlet
[18:12] <hatch> can you think of a way to bind to the fields without requirng a viewlet?
[18:13] <bcsaller> hatch: VC owns databinding, its can either add a slot for header with the viewlet or add the databinding with addBinding directly
[18:13] <bcsaller> I think a slot and a viewlet make sense, its just a slot we always show
[18:15] <hatch> hmm
[18:16] <hatch> yeah slot probably does make the most sense as far as separation of concerns is.....concerned
[18:16] <hatch> will do that, thx
[18:18] <benji> jujugui: small branch to fix a drag and drop issue: https://codereview.appspot.com/11138044
[18:18] <bac> benji: i'll do one
[18:18] <benji> thanks
[18:18] <hatch> benji: got it
[18:18] <benji> great
[18:19] <hatch> position fixed on the body eh? heh
[18:19] <hatch> I foresee issues in the future
[18:20] <bac> benji: why is that overflow still in service.js?  it should've been removed in trunk
[18:20] <benji> bac: it may have been a race with me branching.  I should have merged in trunk before proposing.  I'll do that now.
[18:21] <bac> benji: doesn't lbox produce a diff against trunk?
[18:21] <bac> i mean, you shouldn't have had to do anything.

[18:22] <benji> I'm re-proposing the merged branch now.
[18:23] <hatch> benji: I'm doing a QA, which revno are you on?
[18:23] <hatch> just to make sure I have the right one
[18:23] <Makyo> lbox produces a diff against :parent, which points to a revision of trunk.
[18:23] <Makyo> That way new code doesn't show up as deleted.
[18:24] <benji> hatch: 824; it's still in the process of proposing
[18:24] <benji> hatch: ok, it's finished proposing
[18:25] <hatch> got it thx
[18:25] <bac> benji: cool, your diff is much smaller now
[18:25] <benji> good
[18:27] <hatch> benji: QA fails spectacularly
[18:27] <benji> hatch: how so?
[18:27] <hatch> drag and drop (so fixed gets applied)
[18:27] <hatch> then d click on the inspector
[18:27] <hatch> dclick on the service
[18:27] <hatch> to view the fullpage inspector
[18:28] <hatch> also the ghost inspector panel is way off position now
[18:28] <Makyo> hatch, ghost inspector is way off position for me in trunk.
[18:28] <hatch> ohh
[18:29] <benji> hatch: double-click on the ghost inspector?  That doesn't appear to do anything.
[18:29] <Makyo> Er.. as in clipped at the bottom; I'm not actually following along, sorry.  I'll keep my yap shut if that's not the case.
[18:30] <hatch> sorry I meant dclick on the service after deployed
[18:30] <hatch> ^ benji
[18:30] <hatch> Makyo: the ginspector is probably 100px down from the top nav
[18:30] <hatch> similar on trunk?
[18:30] <hatch> it looks proper to me on trunk
[18:31] <benji> hatch: gotcha, yep that's a bug.  I think I have a fix.
[18:31] <Makyo> ~20px here, but it's clipping over the bottom bar.
[18:31] <hatch> Makyo: ahh yeah that happens to me if I shrink my window too
[18:31] <hatch> the overlap
[18:31] <Makyo> hatch, running full screen full HD here.
[18:31] <hatch> benji: I'm concerned that applying position fixed to the body is going to cause us more issues
[18:31] <hatch> as fixed pulls it out of the flow of the page
[18:32] <hatch> which can cause render performance issues too
[18:32] <hatch> (not sure if they apply here)
[18:32] <benji> hatch: yep, my fix is going to be to remove the fixed style after the drop, so it will only be applied while dragging
[18:32] <benji> I'm open to other ways to keep the window from scrolling during a drag, but I haven't been able to find a sane one
[18:34] <hatch> benji: so why doesn't the overflow: hidden on the body work? what am I missing? It appears to work as expected here
[18:35] <benji> hatch: because if you drag down to the bottom (or right) of the window, the body will scroll
[18:35] <hatch> hmm cannot repro - trying in Ubuntu
[18:36] <hatch> nope
[18:36] <hatch> OHHH
[18:36] <Makyo> I can repro.  No scrollbars, just works the same way as other hidden, where if you select and drag.
[18:37] <hatch> I see now
[18:40] <hatch> man this DD is suck a mess
[18:40] <hatch> (not your fault benji) :)
[18:40] <hatch> such*
[18:42] <hatch> Makyo: how are you handling dropping off the drop target?
[18:42]  * hatch is curious
[18:43] <Makyo> Not sure what you mean.
[18:43] <gary_poster> uh
[18:43] <gary_poster> not sure how I left
[18:43] <gary_poster> jcsackett, you around?
[18:43] <hatch> well when you drop a service off the drop zone, to remove the thumbnail
[18:44] <hatch> I thought you were working on that...
[18:44] <hatch> I could have been wrong :)
[18:44] <Makyo> hatch, no, working on left hand panel for unit view.
[18:44] <hatch> gary_poster: that happened to me 3 times today heh
[18:44] <gary_poster> hatch benji was doing that
[18:44] <hatch> ohhh ok
[18:44] <hatch> ohhh
[18:46] <bac> benji: done
[18:46] <bac> gary_poster: looking for a task.  i can start the slider skinning but don't think it is landable today.  thoughts?
[18:47] <gary_poster> looking bac
[18:47] <hatch> bac: QA'd ok?
[18:47] <hatch> should I re-make my branch?
[18:47] <bac> hatch: yes.  i reproduced the problem on uistage but not in benji's branch.  did i miss something?
[18:48] <hatch> hmm intersting - the full screen inspector views are all broken for me
[18:48] <hatch> will try clearing cache and remaking
[18:48] <bac> hatch, benji: the problem i saw on uistage was the body scroll up leaving a void.  doesn't happen with fix.
[18:48] <hatch> ohh so you didn't QA the rest :)
[18:48]  * bac thinks we could all write better merge proposals
[18:49] <gary_poster> hatch, bac, Makyo any of following would be good to do:
[18:49]  * bac describing the broken behavior
[18:49] <hatch> bac: the merge proposal is fine - but it introduces a regression
[18:49] <gary_poster> - QA Rick's branch (I can do that now I think)
[18:49] <benji> gary_poster: I wasn't working on the garbage icon; I can take a look.
[18:49] <hatch> so that's why we need to do a more thorough QA
[18:49] <gary_poster> - sticky header icon
[18:49] <bac> hatch: by 'better mp' i mean explicitly state the problem for people doing qa
[18:49] <gary_poster> benji, bug 1200412?
[18:49] <_mup_> Bug #1200412: drag-and-drop: dropping a service on a non-drop target leaves the token appended to the body <juju-gui:In Progress by benji> <https://launchpad.net/bugs/1200412>
[18:50] <gary_poster> maybe I misunderstood the conversation, sorry
[18:50] <gary_poster> - charm title ellipsis
[18:50] <gary_poster> - CSS transitions
[18:50] <bac> hatch: but you're right, i tried to exercise his problem but didn't do full qa of the app
[18:50] <gary_poster> bcsaller, do you have the feedback you need from Kapil about the export issues?
[18:50] <Makyo> For this next week, gary_poster ?  Don't want to switch now.
[18:51] <bcsaller> gary_poster: I think so yes, it looks like we want some special processing around service options which is in progress, the rest already appears correct in my branch
[18:51] <hatch> bac: this brings up a good question - should the reviewers be required to do that qa? or should the author of the proposal?
[18:51] <gary_poster> Makyo, ack.  sorry, I was not clear that we could/should put aside inspector tasks if you've only just started.  My fault.  as you were--keep doing what you are doing
[18:52] <bcsaller> gary_poster: even with the special processing for options though the real issue will still be in core
[18:52] <rick_h> abentley: ignore my comment on that bug, I mis-read it at first.
[18:52] <benji> gary_poster: nope that bug is about scrolling; well that's the way I interpreted it, the scrolling breaks the app and is ugly, the left over icon isn't worth worrying about in my opinion.  People could drag hundreds of icons into non-target parts of the app and not be an issue
[18:52] <bac> hatch: author should but he can't be trusted so the reviewers should.
[18:52] <hatch> lol
[18:52] <abentley> rick_h: sure thing.
[18:52] <hatch> so after 3 qa's we better not be introducing any regressions lol
[18:52] <gary_poster> bcsaller, ok cool thank you
[18:53] <gary_poster> hatch, bac, not sure each review should be full exploratory review
[18:53] <gary_poster> exploratory testing I mea
[18:53] <gary_poster> n
[18:53] <bac> gary_poster: the ellipsis card says you have some secret sauce
[18:53] <gary_poster> bac, barely. was hoping luca could provide.  However...
[18:54] <bac> gary_poster: i just meant to say if anyone is going to do it, it should be one of the reviewers.  as a developer i am a very tender QA person so i am not to be trusted, and i suspect others may have the same affliction.
[18:54] <gary_poster> bac ack
[18:54] <hatch> *note to self - get bac to review my horrible code*
[18:54] <hatch> :P
[18:55] <bac> hatch: no, i'm very thorough with other's code!
[18:55] <hatch> ohhhh I see, you just let yourself off easy
[18:55] <hatch> ;)
[18:55] <bac> yessss
[18:55] <hatch> haha
[18:55] <gary_poster> hatch, could you review https://codereview.appspot.com/11138044/ pls?  want to make sure you don't have secret sauce about deleting elements there
[18:56] <hatch> gary_poster: I did, it failed QA , benji is working on the fix now
[18:56] <gary_poster> hatch ok thaks
[18:56] <gary_poster> rietveld is weird
[18:56] <hatch> weird, or broken? ;)
[18:57] <hatch> I swore that it used to tell me which areas I had commented on without refreshing
[18:57] <hatch> then one day it just stopped
[18:59] <hatch> *use tests to write code - who needs docs anyways!*
[19:02] <benji> hatch: the branch has been updated
[19:02] <hatch> awesome!
[19:02] <hatch> pulling
[19:06] <sinzui> thank you gary_poster, I did my Mp in the wrong order...I create the reitveld review request afterwards. I will remove it since the Lp MP was sufficient
[19:06] <bac> gary_poster: so is the goal to have charm title in charm browser be a single line with ellipsis or two lines with ellipsis? if the former then 'postgresql-psql' would be one affected.
[19:07] <gary_poster> cool sinzui
[19:07] <gary_poster> bac single I think
[19:07] <bac> gary_poster: k
[19:09] <hatch> benji: nogo (sorry :( ) see review for the comment
[19:09] <benji> hatch: thanks
[19:09] <benji> I'm going to eat a late lunch now.
[19:09] <hatch> I swear I'm not trying to be a pain
[19:09] <hatch> :)
[19:09] <benji> :)
[19:10] <hatch> benji: alright - I am meeting some friends for lunch in about 30mins so just push up wheever you get to and I'll get to it as soon as I get back
[19:10] <hatch> pending of course you find a solution
[19:13]  * hatch contemplates making Benji a drag and drop dart board
[19:24] <rick_h> hatch: bcsaller jcsackett anyone up for a review please? https://codereview.appspot.com/11224044
[19:24] <rick_h> gary_poster: ^^ that's the home stuff
[19:25] <hatch> Oh Kay
[19:25] <gary_poster> thanks rick_h
[19:25] <rick_h> sinzui: I'm not 100% sure I can get autocomplete landed. We've hit yui3-skin-sam issues and a bug in clicking off AC suggestions. Will work on that here, but not sure how long I've got.
[19:25] <rick_h> yay long running branches that pick up more issues the longer it lives
[19:25] <sinzui> indeed they do.
[19:25] <gary_poster> rick_h, sinzui I've seen a few core charm browser issues too; and have been trying to ask jcsackett about a change I had forgotten about
[19:25] <sinzui> rick_h, I think you are EoD
[19:26] <gary_poster> yeah I was wondering about that :-)
[19:26] <rick_h> sinzui: I've got some extra time today since I was afk this morning.
[19:26] <gary_poster> oh cool
[19:26] <rick_h> gary_poster: what's that?
[19:26] <jcsackett> gary_poster: what change is that?
[19:26] <gary_poster> yay jcsackett!  ok first you
[19:27] <gary_poster> we were supposed to make it so that, on jujucharms.com, logout button was replaced with [something I forget, maybe a link].  Was that part of your changes?
[19:27] <gary_poster> I mean, the changes to set default view and stuff
[19:27] <sinzui> rick_h, we let's emphasise quality and stability. I would rather postpone autocomplete if the effort to get it production ready would delay of issues we want in production early net week
[19:28] <rick_h> sinzui: rgr, just wanted to give you a heads up. If the css issues are lighter than they look, and a workaround for the d3/svg/click bubbling is available in the next hour or so I'll try to get it landed. It's qa'd ok aside from those
[19:28] <rick_h> and I understand home/etc was higher priority so will get that landed before EOD if possible
[19:28] <sinzui> understood
[19:28] <gary_poster> rick_h, ok you now :-)
[19:28] <gary_poster> I will qa in a sec but these are core charm browser issues I found.
[19:28] <rick_h> gary_poster: woot
[19:29] <gary_poster> (1) go to http://uistage.jujucharms.com:8086/fullscreen/search/precise/cinder-8/
[19:29] <gary_poster> (2) click on Browse
[19:29] <gary_poster> I get "Failed to load search results.
[19:29] <gary_poster> Charm API server did not respond:
[19:29] <gary_poster> "
[19:29] <gary_poster> Another one...
[19:29] <rick_h> gary_poster: hold up, I can't dupe
[19:29] <jcsackett> gary_poster: no, that wasn't communicated in the card i had. all i've ended up doing was setup the option for fullscreen to be default and expose that as a config for the charm.
[19:30] <gary_poster> rick_h, cool, will clear cache
[19:30] <rick_h> gary_poster: clicking on browser does nothing for me.
[19:30] <rick_h> gary_poster: did you mean search? or something else?
[19:30] <gary_poster> rick_h, oh sorry I meant build
[19:30] <jcsackett> gary_poster: i can possibly take care of that change on monday, if i get more specifics.
[19:30] <hatch> gary_poster: rick_h: I can repro
[19:30] <rick_h> gary_poster: ok, known issue with bad charm and the work for that is in progress
[19:30] <gary_poster> jcsackett, ack I'll try to dig it up
[19:31] <gary_poster> thanks jcsackett
[19:31] <hatch> rick_h: it's an access control origin issue
[19:31] <jcsackett> np.
[19:31] <rick_h> gary_poster: though to be fair, how did you get to that url to start with?
[19:31] <rick_h> hatch: no, it's an upstream error in the api because of bad data. See bug #1199780
[19:31] <_mup_> Bug #1199780: search requests errors when a charm has no last_change <charmworld:Triaged> <https://launchpad.net/bugs/1199780>
[19:31] <hatch> the browser is looking awesome btw :)
[19:31] <rick_h> hatch: any search for "all charms" will error right now
[19:31] <hatch> ohhh ok
[19:31] <rick_h> due to that issue
[19:32] <rick_h> gary_poster: ok, so 2) ?
[19:32] <gary_poster> rick_h, my other story is how I got to that story actually.  so...
[19:32] <gary_poster> (1) go to http://uistage.jujucharms.com:8086/precise/cinder-8/
[19:33] <gary_poster> rick_h, scratch that, it is http://uistage.jujucharms.com:8086/fullscreen/precise/cinder-8/
[19:33] <rick_h> gary_poster: rgr
[19:33] <gary_poster> (2) search for cinder
[19:34] <gary_poster> (3) click on cinder in results
[19:34] <gary_poster> nothing happens
[19:34] <rick_h> gary_poster: yea, that's a bug.
[19:34] <gary_poster> rick_h: Variant of that
[19:34] <gary_poster> (1) go to http://uistage.jujucharms.com:8086/fullscreen/search/precise/cinder-8/?series=precise&text=cinder&type=approved
[19:34] <gary_poster> (2) click on cinder
[19:34] <gary_poster> nothing happens
[19:34] <gary_poster> well, the url changes
[19:34] <rick_h> gary_poster: right, that url change is a bug as well in the routing
[19:35] <gary_poster> cool
[19:35] <rick_h> gary_poster: see #1199392
[19:35] <_mup_> Bug #1199392: can't view fullscreen charm details from url <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1199392>
[19:35] <rick_h> gary_poster: but that first variant is legit. I'll file a bug on it now. Should be some corner case around the state deciding what view to show.
[19:35] <rick_h> gary_poster: e.g. easy fix once found
[19:35] <gary_poster> rick_h, cool thanks.  ok, going to look at your home branch...
[19:37] <rick_h> gary_poster: #1200743 for tracking purposes. Thanks for the nice repo instructions
[19:37] <_mup_> Bug #1200743: complex search/view interactions in fullscreen fail to work <charmbrowser> <juju-gui:Triaged> <https://launchpad.net/bugs/1200743>
[19:37] <gary_poster> cool thank you!
[19:37] <rick_h> sinzui: any word on the misbehaving charm data bug? I thought I heard something about abel's work might fix and saw he got a branch into review today?
[19:38] <rick_h> sinzui: sorry to bug you but I don't see any card for him on the board
[19:38] <hatch> rick_h: I'm about half way through review (then to QA) but I have to take off now for lunch, so you might be past EOD by the time I get it done, is that ok?
[19:38] <sinzui> rick_h, he didn't get his branch landed. He was concerned about a corner case
[19:38] <rick_h> hatch: yea, don't worry. I'll make sure I get it through before I hit bed tonight
[19:38] <sinzui> rick_h, I will ask webops to delete the branch that is not a charm
[19:39] <hatch> ok great
[19:39] <rick_h> sinzui: ok, no problem. Just wanted to let gary_poster at least one of his three bugs was close to working :)
[19:39] <rick_h> one easy fix, and one's a pita wheeee
[19:39] <rick_h> I feel the need to get a 'bug hunting' fun to drop on the desk for times like this
[19:39] <gary_poster> :-)
[19:41] <gary_poster> rick_h, I merged your branch with trunk and got conflict.  http://pastebin.ubuntu.com/5869067/ (tree is trunk,merge-source is you).  should I really delete that padding?
[19:41] <rick_h> gary_poster: sec, looking
[19:42] <rick_h> gary_poster: so I think that neesd to stay? I didn't add that code so guessing we both added at the same spot?
[19:42] <gary_poster> rick_h, cool agree
[19:43] <gary_poster> rick_h, with a similar level of confidence ;-)
[19:43] <rick_h> I'll pull trunk here locally and merge in and make sure things are resolved
[19:44] <rick_h> gary_poster: ok, wtf. I edited the file 30 lines below...no idea why bzr hates me
[19:45] <gary_poster> :-)
[19:45] <sinzui> rick_h, we will now wait for ingest to notice the empty branch is gone
[19:45] <rick_h> bcsaller: thanks for the catch. I had a container.one vs a container.all on the event for that. Updating and adding another test now
[19:45] <rick_h> gary_poster: so the Home link doesn't work :) but will in a sec
[19:46] <bcsaller> thats an easy one to make, ha ha, get it ;)
[19:46] <rick_h> ho ho ho ho
[19:46] <gary_poster> cool rick_h
[19:47] <bcsaller> enough punishment
[19:48] <jcsackett> rick_h: sounds like you're addressing the one thing i found in my review. :-P
[19:48] <rick_h> jcsackett: yep, pushing now, will have to wait for lbox to go through again before it shows up in reitveld
[19:51] <bac> gary_poster: css-only ellipsis works for that field.  \o/  i now see that no one appears to be using gallery-ellipsis any more.  i'd like to rip it out.
[19:51] <gary_poster> bac +1
[19:52] <bac> gary_poster: will do in two branches
[19:52] <gary_poster> bac +1
[19:52] <jcsackett> rick_h: yay, lbox.
[19:53] <jcsackett> it has been very slow for me today.
[19:54] <rick_h> crap, now test failures. looks like something is cascading down
[19:57] <gary_poster> rick_h, I see a number of issues--did you address them in the merge/update?  example: (1) http://localhost:8888/fullscreen/ (2) search for glance (3) click on glance. Problem: competing home links in header.  Example 2: (1) go to http://localhost:8888/ (we really can't hide the home link just on the home page, trivially? :-/ ) (2) search for mysql. Problem: a line covers up "search results"
[19:57] <rick_h> gary_poster: looking, fighting test failures atm now. Will look at those in a sec.
[19:57] <gary_poster> rick_h, cool, sorry
[20:04]  * benji dives back into the drag and drop swamp.
[20:06] <rick_h> gary_poster: looking at issues. Thanks 1) is from breadcrumbs work. Looking for where huw put that since he didn't put it in the widget here. 2) there might be a hacky way, but nothing that I'd like to see live in trunk. 3) Looking into that. I'm double checking to see if that border rule can come out all together.
[20:07] <sinzui> rick_h, the query is fixed in production and staging.
[20:07] <rick_h> oh come on, he freaking absolute positioned the breadcrumbs way out of the View itself?!
[20:07] <rick_h> sinzui: awesome, thanks.
[20:07] <rick_h> gary_poster: I'm going to pull breadcrumbs right now. They're only on the charm details view and in a wrong place.
[20:08] <rick_h> gary_poster: any complains on trading Home link for breadcrumb on charm details?
[20:08] <rick_h> complaints that is...ugh
[20:08] <sinzui> abentley, rick_h, I took this opportunity to measure the time of deletion to ingestion, and cache clearing. Ingest takes 17 minutes in production. The search/cache was fixed within a minute of ingestion
[20:09] <rick_h> sinzui: very cool.
[20:10] <abentley> sinzui: That is scary, because we ingest on 15 minute cycles.
[20:11] <bac> jujugui: get the easiest review of the day here: https://codereview.appspot.com/10964045
[20:11] <sinzui> abentley, We changed production to be just-in-time cycling I thought
[20:11] <benji> bac: I'll take a look.
[20:11]  * sinzui looks for rt
[20:13] <abentley> sinzui: I assume production still runs enqueue every 15 minutes.  If it's doing it more often, then we're in really big trouble.
[20:16] <benji> I learned a new term that I really like over lunch, the "grep test": http://jamie-wong.com/2013/07/12/grep-test/
[20:17] <sinzui> abentley, worker-interval=1 in m.jc.com
[20:18] <abentley> sinzui: So if I understand you correctly, we're filling the queue every 1 minute, but it takes 17 minutes to remove that from the queue.  Is that right?
[20:19] <sinzui> abentley, I thought we had changed the process to get a lock  so that the queue would not be appended to while the lock was kept
[20:19] <gary_poster> rick_h, I don't think so?
[20:19] <gary_poster> rick_h, that's a step up, right?
[20:20] <rick_h> gary_poster: I think so. That's updated, #3 is corrected as well. Just fighting test-debug and delegate for a final update.
[20:20] <abentley> sinzui: I don't know anything about the locking.  If so, we should be fine.
[20:20] <sinzui> Do I dare go into #webops one more and ask for the count of what is in the queue?
[20:20] <bac> jujugui: one more for https://codereview.appspot.com/10964045/ ?
[20:21] <sinzui> maybe I should get a job as a webop
[20:21] <gary_poster> bac, will look.  code looks fine; will try qa :-)
[20:22] <sinzui> oh, I could put together the diagnostic page to tell us that all process are operating and what their size/capacity is
[20:23] <rick_h> oh I'm a moron...ugh
[20:24] <rick_h> gary_poster: updated branch pushing now.
[20:24] <gary_poster> bac LGTM
[20:24] <bac> thx
[20:24] <gary_poster> cool rick_h .  so it has fixes for #1 and # 3?
[20:24] <rick_h> gary_poster: correct
[20:24] <rick_h> gary_poster: looking close for #2, maybe a temp hack with an XXX
[20:25] <gary_poster> rick_h, cool.  +1 on temp hack for #2.  pretty important to visuals to hide I think
[20:27] <bac> sinzui: why does searching for 'postgres' not return 'postgresql-psql' ?
[20:27] <gary_poster> bac postgresql does.  apparently not partial text
[20:28] <gary_poster> discovered as well
[20:28] <bac> oh
[20:28] <rick_h> yea, search doesn't do paritals atm
[20:28] <sinzui> bac, elasticsearch is not configured to search substring
[20:28] <sinzui> bac, but it is configured to do that on autocomplete cases
[20:28]  * gary_poster is happy with new alias:
[20:28] <gary_poster> alias bzrevert='bzt revert && bzt revert --forget-merges'
[20:28] <gary_poster> where bzt == bzr
[20:29]  * bac bzr help revert
[20:29] <bac> er, bzr revert help
[20:31] <abentley> gary_poster: Since revert automatically forgets merges, I don't see the advantage of this.
[20:31] <gary_poster> abentley, oh, it doesn't/didn't for me
[20:31] <sinzui> abentley, ingest could has a lot of steps that are surely collecting redundant data. If the branch has not changed and proof has not changed, don't run proof. The same is also true for jenkins.
[20:32] <gary_poster> abentley, perhaps this is merely remembered or even misremembered pain.  willinvestigate later
[20:32] <abentley> gary_poster: If you revert a particular file or directory, it won't forget merges.  Otherwise, it will.
[20:32] <sinzui> abentley, quick look, these have ingest times: http://manage.jujucharms.com/tools/store-missing
[20:32] <gary_poster> abentley, cool thanks
[20:32] <sinzui> looks like this phase is exactly 15 minutes
[20:33] <abentley> sinzui: what about cs:~benji/precise/juju-gui ?  Looks more like 12 minutes to me.
[20:34] <sinzui> yeah
[20:34] <sinzui> we are network bound for Lp and jenkins so we can expect variations
[20:34] <abentley> sinzui: Anyhow, I guess the locking acts as a de-facto ingest delay.
[20:35] <abentley> sinzui: There is *lots* we are doing redundantly.  Like ingesting the charm files.  Every. Single. Time.
[20:35] <sinzui> abentley, we clear the queue with every deploy, so al is we is we deploy often.
[20:35] <rick_h> gary_poster: can't. Even an XXX hack will not work since the height is hard coded, the widget isn't redrawn in a search content vs a home context to catch the update.
[20:36] <gary_poster> rick_h, :-( I dunno if it is ok to land if it is on home. :-(  other issues are fine btw, though I think breadcrumbs will be better in future when we replace.
[20:36] <gary_poster> I mean, I ad t
[20:36] <gary_poster> qa'd
[20:36] <gary_poster> it
[20:36] <rick_h> gary_poster: definitely agree on breadcumbs.
[20:37] <rick_h> gary_poster: just not enough time to get it in there right atm.
[20:37] <gary_poster> ack
[20:37] <rick_h> gary_poster: luca signed off on permanent home. I made sure to express to him that was the result of getting it in.
[20:37] <gary_poster> rick_h, oh, you mean getting it at the top?
[20:37] <gary_poster> sorry that made no sense
[20:38] <gary_poster> other than <surprise> ;-)
[20:38]  * rick_h isn't following still
[20:38] <bac> jujugui: and another exciting review.  almost 500 lines of deletions.  https://codereview.appspot.com/11216044/
[20:39] <rick_h> gary_poster: guichat?
[20:39] <gary_poster> bcsaller, btw you should probably tell us how to qa service-options-viewlet branch
[20:39] <gary_poster> rick_h, +1 thanks
[20:47] <bcsaller> gary_poster: It was something I saw when looking at the home-link branch, but there may have been another issue there, the charm I thought would trigger it didn't on trunk just now
[20:48] <rick_h> bcsaller: jcsackett updates up there
[20:49] <jcsackett> rick_h: ack.
[20:52] <jcsackett> rick_h: i'm seeing you completely removing the home button now, but not adding it back anywhere.
[20:56] <rick_h> jcsackett: huh?
[20:56] <gary_poster> rick_h, I ended up by saying everything was looking great :-)
[20:56] <rick_h> gary_poster: ah, cool. Thanks, trying :)
[20:56] <rick_h> jcsackett: you mean the event catch? It's changed to a delegate that catches both cases
[20:57] <rick_h> jcsackett: and both of them are tested in the tests now
[20:57] <rick_h> jcsackett: if you mean something else let me know
[20:57] <gary_poster> bcsaller, ok so I should just to code lgtm?  bac you need review too?
[20:57] <jcsackett> rick_h: i am looking at the template.
[20:57] <bac> gary_poster: i do, should be cake
[20:57] <jcsackett> ah, rick_h, ignore me.
[20:57] <jcsackett> wrong template.
[20:57] <rick_h> jcsackett: ah yea, that' the breadcrumbs huw added I removed since they conflict
[20:57] <jcsackett> rick_h: i was looking at where you ripped out breadcrumns.
[20:58] <bcsaller> gary_poster: yeah, I think its a win, somehow that triggered before and you'd get an empty inspector.
[20:58] <gary_poster> cool, on it
[20:59] <gary_poster> bac, how was it actually turned on, anyway?
[21:00] <bac> gary_poster: how was that ellipsis code used?
[21:00] <rick_h> bcsaller: can you peek at the review now that the one/all issue is adjusted? https://codereview.appspot.com/11224044/
[21:00] <bcsaller> sure
[21:00] <rick_h> bcsaller: changed to .delegate and skip all that one/all business :)
[21:00] <bcsaller> good call
[21:00] <gary_poster> bac, I mean, what was the mechanism to turn the ellipsis code on?
[21:01] <bac> gary_poster: like this:
[21:01] <bac>  container.all('.charm-summary').ellipsis({'lines': 2});
[21:01] <bac> gary_poster: you can see it in action with 'bzr diff -c 245'
[21:01] <gary_poster> bac cool thx
[21:02] <gary_poster> bac LGTM get somebody else :-)
[21:02] <gary_poster> benji how did drag thing turn out?  did you get that landed?
[21:02] <benji> gary_poster: nope, stilly trying to fix very subtile breakage
[21:03] <gary_poster> benji, :-/ k.  when do you give up? :-)
[21:03] <benji> soon
[21:03] <gary_poster> k
[21:03] <gary_poster> lemme know
[21:03] <benji> k
[21:04] <bac> benji: subtile, like in subflooring?
[21:04] <rick_h> cement board
[21:04] <bac> ha
[21:04] <benji> heh
[21:04] <rick_h> very nasty buggy stuff
[21:04] <bac> is that the same as mud board?
[21:06] <bac> jujugui: one more for https://codereview.appspot.com/11216044/ -- it's another fun one
[21:08] <gary_poster> bcsaller, LGTM with a bug fix and maybe a test
[21:11]  * bac has to step out.  bbiab to land my branch.
[21:11] <gary_poster> bcsaller, ugh, missed your other one.  I will review it.  jujugui, could we have a second review of https://codereview.appspot.com/11227043/ ?  critical
[21:11] <bac> bac: ok
[21:11] <rick_h> gary_poster: looking
[21:12] <gary_poster> bac, Makyo gave you an LGTM fwiw
[21:12] <gary_poster> thanks rick_h
[21:12] <bac> gary_poster: just saw.  thanks Makyo
[21:13] <bac> fwiw, i liked gallery-ellipsis... (no pun)
[21:13] <jcsackett> jujugui: can i get two reviews on https://codereview.appspot.com/11230043 ? it's mostly deletions and icon changes.
[21:14] <gary_poster> jcsackett, if no one has soon I will.  one or two ahead of you
[21:14] <jcsackett> gary_poster: dig, thanks.
[21:15] <jcsackett> sinzui: can you pick mine up, perchance? https://codereview.appspot.com/11230043
[21:15] <sinzui> I can
[21:15] <jcsackett> awesome, thanks.
[21:16] <rick_h> gary_poster: can I get a second LGTM on here then? I've got to run get the boy from day care soon. https://codereview.appspot.com/11224044/
[21:16] <gary_poster> rick_h, on it
[21:17] <jcastro> man just our luck
[21:17] <jcastro> finally get all those categories
[21:17] <jcastro> and the dang icon guy goes on holiday for 2 weeks
[21:17] <rick_h> jcastro: heh
[21:18] <benji> hatch and gary_poster: as best I can tell, https://codereview.appspot.com/11138044 is fixed; still needs a good QAing though
[21:18] <gary_poster> jcastro, heh :-)
[21:18] <gary_poster> hatch, can you do that?  I've got a queue of three atm
[21:19] <gary_poster> and I want rick and benji to be able to EoD
[21:19] <rick_h> gary_poster: I know hatch said he was afk for a little bit and would get back.
[21:19] <gary_poster> oh right
[21:19] <gary_poster> :-/
[21:19] <gary_poster> ok benji, I'll try to qa it soon; if you need to run lemme know
[21:19] <gary_poster> we can land it for you if need be
[21:20] <gary_poster> rick_h, hack idea for later: listen for EV_SEARCH_...and friends and add and remove class there?
[21:21] <rick_h> gary_poster: yea, code might be able to go into the code that fires the viewNavigate based on that.
[21:22] <jcsackett> sinzui: i have to run afk for a moment. if you have questions on the branch just drop 'em on rietveld.
[21:24] <gary_poster> rick_h, LGTM with one old observation and one new observation
[21:24] <gary_poster> thank you
[21:25] <rick_h> gary_poster: the search clearning should happen now. It was part of the last minute squeeze in
[21:25] <rick_h> gary_poster: and ty for the LGTM
[21:25] <gary_poster> rick_h, oh sweet :-)
[21:26] <rick_h> ok, I'm out. See you all on the other side...of the appalacians next week...
[21:32] <gary_poster> bcsaller, LGTM with trivials
[21:32] <gary_poster> rick_h, thanks!  see you sson
[21:32] <gary_poster> soon
[21:32] <gary_poster> on to jon's
[21:34] <hatch> gary_poster: I am still not sure about this position fixed thing
[21:34] <hatch> I'm pretty sure it'll cause issues on mobile heh
[21:36] <sinzui> gary_poster, what is the lowest version of Firefox that is supported?
[21:39] <hatch>  sinzui I want to say 21
[21:39] <hatch> but I can't actually confirm that
[21:39] <sinzui> 21 is the magic number for me
[21:39] <sinzui> 20 is not magic at all
[21:40] <hatch> haha well there ya go
[21:40] <hatch> 21 there were some large changes with how FF works, and 22 is the most recent
[21:40] <hatch> so you would have to be pretty far behind to be <21
[21:40] <gary_poster> sinzui, 21 is good
[21:40] <hatch> yusss i got it right
[21:40] <gary_poster> hatch, position fixed for what, the headers?
[21:40] <hatch> the body
[21:40] <hatch> on benji's branch
[21:41] <gary_poster> oh!
[21:41] <hatch> I can't suggest an alternative
[21:41] <hatch> but I think that that's going to cause us issues in the future
[21:41] <hatch> so it may just be a bandaid
[21:41] <sinzui> jcsackett, okay, I am will to trade a LGTM if you revise the use of window.location.origin to a cover IE10
[21:42] <gary_poster> hatch, :-/ dunno.  if you don't have another suggestion though, maybe we should wait to fight that battle
[21:43] <hatch> that's kind of what I was thinking
[21:43] <hatch> do we have a tablet to test on?
[21:43] <hatch> I only have my N7 with Android
[21:43] <gary_poster> Makyo has an ubuntu touch.  I have an ipad.  one of those work for what you have in mind?
[21:45] <hatch> well since the support matrix only includes the touch right now I was hoping we could QA in there to make sure there isn't any wakyness
[21:46] <hatch> or do you think that's not necessary?
[21:48] <Makyo> Should I bring the tablet, gary_poster ?
[21:48] <gary_poster> Makyo, hatch, only for fun :-)  If you don't bring it no biggie Makyo, but +1 if it is easy
[21:48] <hatch> gary_poster: Makyo: I can tell you that the UI is all sorts of broken with the position fixed on the body in Chrome for Android
[21:49] <jcsackett> sinzui: by revise you mean replace it with using either origin or protocol + host?
[21:49] <gary_poster> :-/
[21:49] <hatch> but on trunk I can use it :)
[21:49] <hatch> it's actually pretty cool heh
[21:49] <gary_poster> hatch, that's pretty bad if this one change suddenly breaks Android :-/
[21:50] <hatch> well it's because it pulls the whole body element out of the flow of the page which I'm going to assume cascades into some weirdness because that's never done
[21:50] <hatch> I've never even heard of people going position fixed on the body before
[21:50] <hatch> heh
[21:52] <bcsaller> why does the token need to append to the body anyway rather than be its own floating div?
[21:52] <hatch> I was thinking if we could position it where the mouse is...but then we might as well use the YUI DD module
[21:52] <sinzui> jcsackett, yes, I think we should follow the example in the nod.js code
[21:53] <jcsackett> sinzui: ok, per your comment?
[21:53] <jcsackett> pushing that change now.
[21:53] <hatch> bcsaller: it has to be visible in the DOM to be the dragable proxy
[21:53] <hatch> it's pretty odd...
[21:54] <bcsaller> top: -1000px left -100px with position absolute?
[21:54] <rick_h> bcsaller: replies inbound
[21:55] <hatch> bcsaller: I thought I tried that but maybe it was another bug
[21:55] <hatch> one sec
[21:56] <gary_poster> jcsackett, code LGTM but qa bad: "X" to close is in wrong place.  I also can't find an image from luca of where the icons should go but it doesn't look right there in the build mode--it looks like it should really be above the tabs
[21:56] <gary_poster> jcsackett, want to guichat to see what I'm seeing?  I tried clearing cache
[21:56] <jcsackett> gary_poster: per luca, below the tabs.
[21:57] <jcsackett> gary_poster: sure, one moment
[21:57] <gary_poster> jcsackett, does that seem as odd to you as it does to me?  is there an image?
[21:58] <jcsackett> gary_poster: there is not. is guichat open?
[21:58] <gary_poster> jcsackett, it is, see you there
[21:59] <hatch> bcsaller: yep as I thought, it doesn't work - when it's positioned off the screen the drag proxy is invisible
[22:00]  * bac gotta run.  see y'all in raleigh
[22:00] <hatch> cya bac
[22:00] <hatch> safe travels
[22:01] <hatch> does anyone remember why we didn't use YUI DD for this drag stuff?
[22:03] <bcsaller> was it just a preference for the HTML5 stuff? Not sure. really does seem like that native stuff should work but itsn't baked yet.
[22:04] <hatch> yeah I think the issues we are having are caused by workarounds around chrome being stupid
[22:04] <hatch> whereas the YUI DD code absolutely positions an element under the cursor
[22:06] <hatch> I gota say - with the exception of there being too much UI chrome on this new design, it works pretty darn well on a tablet
[22:07] <hatch> side effect of us just being so awesome....right?? right????
[22:07] <hatch> awwww yeahhhhh
[22:07] <bcsaller> I'd like to cut over to the pointer events polyfill or something similar so we can pull in better touch support more easily
[22:08] <hatch> I'd like developing on something that isn't a moving target lol
[22:08] <hatch> ahh who am I kidding....I'd get bored
[22:08] <hatch> "what do you mean this just works?"
[22:08] <hatch> lol
[22:18] <jcsackett> gary_poster, sinzui: changes you've requested are up https://codereview.appspot.com/11230043
[22:18]  * sinzui looks
[22:18] <gary_poster> jcsackett, on it thanks
[22:19] <gary_poster> hatch, what's the story for benji's branch?
[22:19] <hatch> if we use it - it breaks mobile...bigtime - if we don't, we don't have a better sollution besides switching to YUI DD (which I'm not sure why we didn't go that route in the beginning)
[22:20] <hatch> so maybe there was a reason YUI DD didn't work
[22:20] <hatch> I can think of alternatives, but none that would be trivial (positioning the drag proxy under the cursor)
[22:21] <benji> rick and I couldn't get YUI DND to work so we went with HTML5 instead
[22:21] <hatch> ohh ok, do you remember what the issue was?
[22:22] <hatch> and as a follow-up - can we use the actual icon in other browsers and just 'deal with it' until chrome fixes the cutoff icons issue?
[22:22] <benji> the last thing I remember was trying to get the tokens to drag out of the sidebar , they wouldn't leave their container
[22:23] <hatch> ahh
[22:23] <benji> actually we are dealing with the cutoff issue, the cloning of the icon is to deal with firefox; it uses the default drag icon if we don't
[22:24] <hatch> ohh odd, I've never seen the cutoff
[22:24] <hatch> but hmm
[22:24] <hatch> basically if we want to support mobile we can't use your fix
[22:26] <hatch> benji: so in FF we can't point it to the icon in the DOM already?
[22:27] <benji> the cutoff only happens with background images (not the per-charm custom icons)
[22:28] <hatch> ok I'll hack on this a bit
[22:28] <benji> hatch: right, if I recall correctly, FF didn't like that
[22:28] <hatch> it's past your EOD
[22:28] <benji> may the schwartz be with you
[22:28] <hatch> lol well you are right, it doesn't like that
[22:30] <hatch> ok that was an OSX bug
[22:30] <hatch> got it to work
[22:30] <hatch> without an extra cloned node
[22:32] <hatch> I'll try these changes on trunk and then propose the branch if it works in all 3 browsers
[22:33] <gary_poster> thanks benji, hatch.
[22:33] <gary_poster> jcsackett, LGTM with one additional style hack that I give you specific numbers for.  Thank you very much!
[22:34] <gary_poster> hatch, will be back soon if you need LGTM
[22:42] <hatch> sure np - this is taking a little longer than expected because I have too many branches active heh
[22:49] <hatch> jcsackett: except use a single line to apply those padding styles :P
[22:49] <gary_poster> well, yeah, that would be fine :-P
[22:50] <hatch> for some reason WIndows 8 is telling me what the weather is in New York
[22:50] <hatch> it's raining if anyone cares
[22:50] <hatch> :D
[22:53] <hatch> oh IE you suck so much
[22:53] <hatch> we had a comment in our ghost-inspector.js file which caused a js parse error....
[22:53] <hatch> a comment....
[22:55] <hatch> hmm
[22:55] <hatch> this is a disaster lol
[22:55] <hatch> gary_poster: would you like me to file IE10 bugs?
[22:55] <gary_poster> hatch, yes
[22:56]  * hatch schedules off next week to file bugs
[22:56] <hatch> tee hee
[22:56] <gary_poster> hatch, that bad, eh? :-/
[22:56] <hatch> yeah it's pretty bad - good thing it's so standards compliant
[22:56] <hatch> ....
[22:56] <gary_poster> heh
[23:06] <hatch> ok so I have fixed the primary issue but caused another one
[23:06] <hatch> the icon in the middle of the ghost in FF is too large
[23:07] <hatch> it's svg <image> tag has the proper dimensions
[23:07] <hatch> but the image isn't scaling properly inside it
[23:08] <hatch> has this happened to anyone else?
[23:09] <bcsaller> hatch: I just took a peek at this myself, what about http://jsfiddle.net/p33KJ/1/ doesn't do what we need?
[23:09] <gary_poster> Maybe Makyo has svg insight, hatch, dunno?
[23:10] <hatch> bcsaller: I've actually already solved that issue
[23:10] <hatch> heh sorry
[23:10] <bcsaller> with the HTML5 codepath?
[23:10] <hatch> yep
[23:10] <bcsaller> ahh, ok
[23:11] <hatch> https://gist.github.com/hatched/03c074ee0543b5f2d223
[23:11] <hatch> bcsaller: ^
[23:12] <hatch> look at line 8.....that caused IE to explode
[23:12] <hatch> lol
[23:12] <gary_poster> poor IE.  such a fragile flower
[23:13] <hatch> so yeah this diff works....with the exception of the svg image resize issue in FF
[23:14] <Makyo> gary_poster, hatch - Oh, foo.  Yeah.  We have to append 'px' to width and height attributes for FF to parse them.
[23:15] <gary_poster> ah!  cool, thanks Makyo!  /me senses happy branch landing approaching...
[23:16] <Makyo> I thiiink that's it.
[23:16] <gary_poster> :-)
[23:19] <gary_poster> bcsaller, when are you landing your branches?  you have two sets of LGTMs waiting for you. :-)
[23:19] <hatch> Makyo: ahh cool I'll try that
[23:19] <hatch> thanks :D
[23:21] <bcsaller> gary_poster: I thought I had for some reason, must have failed on a merge, checking
[23:21] <gary_poster> cool
[23:21] <hatch> Makyo: so I don't see the x and y being set on the old version
[23:24] <Makyo> Lines 1186-1187 in app/views/topology/service.js
[23:26] <bcsaller> gary_poster: if the second LGTM is the options fix that needs one more review unless you think doesn't
[23:29] <gary_poster> bcsaller, oh, right.  I personally think it verges on trivial.  I say try to get one more and if you don't land it anyway :-)
[23:30]  * gary_poster steps away
[23:30] <bcsaller> ahh, I see what happened, the trunk merge needed an npm update to run the tests successfully and submit died in one of my many open terminal tabs :(
[23:41] <hatch> Makyo: ok thanks
[23:54] <hatch> have a good weekend all - safe travels!
[23:58] <gary_poster> you too hatch.  you closing up on the dnd branch till Monday?
[23:58] <hatch> gary_poster: nope, I plan to propose it but I have supper plans which start in 2mins
[23:58] <hatch> :)
[23:58] <gary_poster> lol
[23:58] <gary_poster> ok enjoy
[23:59] <hatch> :) thanks


[01:22] <menn0> waigani: would you mind looking at: http://reviews.vapour.ws/r/2456/
[01:22] <waigani> menn0: sure
[01:22] <menn0> waigani: it's a fix for intermittent allenvwatcher test failures that i've noticed
[01:22] <menn0> waigani: there's another problem to fix as well but this one issue is happening more often
[01:25] <waigani> menn0: shipit
[01:36] <menn0> waigani: thanks
[01:39] <davecheney> i love the fact that all our upgrade and provisioner tests use "ppc64le" as the "i cannot possibly happen" operating system
[01:41] <anastasiamac> davecheney: isn't it easier to support impossible operating systems? :D
[02:06] <davecheney> we're basically using quantal-ppc64le as our "nope, cannot happen" sentinal
[02:37] <mwhudson> davecheney: good think the ubuntu architecture is called ppc64el then
[02:37] <mwhudson> *THING
[02:37] <mwhudson> doh can't brain today
[02:49] <davecheney> axw_: godeps: cannot get information on "/home/dfc/src/launchpad.net/gwacl": bzr revision-info has unexpected result "244.1.1<EMAIL_ADDRESS>[02:50] <davecheney> mwhudson: oh god
[02:50] <davecheney> don't mention the war
[02:50] <davecheney> or the worst joke in the world that continues to keep on giving
[03:09] <davecheney> state tests now take 450+ seconds to pass
[03:09] <davecheney> % go test ./state/...
[03:09] <davecheney> ok      github.com/juju/juju/state      438.504s
[03:09] <davecheney> golf clap
[03:09] <davecheney> FAIL    github.com/juju/juju/state/leadership   600.006s
[03:09] <davecheney> fucking fantastic
[03:12] <mup> Bug #1487947 opened: provider/ec2: localServerSuite.TestNetworkInterfaces  <juju-core:New> <https://launchpad.net/bugs/1487947>
[06:46] <mup> Bug #1487947 changed: provider/ec2: localServerSuite.TestNetworkInterfaces  <juju-core:New> <https://launchpad.net/bugs/1487947>
[07:16] <dimitern> rogpeppe, hey, have you seen https://code.launchpad.net/~dimitern/godeps/fix-bzr-revision-info-parsing/+merge/268223 ?
[07:16] <rogpeppe> dimitern: nope :)
[07:16] <rogpeppe> dimitern: only just back from 2 weeks' holiday
[07:17] <dimitern> rogpeppe, have a look when you have a moment :) it's just 2 characters change
[07:17] <rogpeppe> dimitern: looking
[07:17] <dimitern> dooferlad, TheMue, hey guys, it seems net-cli is blessed for merging in master
[07:20] <rogpeppe> dimitern: interesting. out of interest, do you actually want to use non mainline revision numbers as dependencies?
[07:21] <dimitern> rogpeppe, I suppose not, but at least when there is such a case now godeps refuses to work anymore
[07:21] <rogpeppe> dimitern: yeah, i agree it shouldn't fail in that case
[07:21] <dimitern> rogpeppe, maybe print a warning when there are dots in the bzr revision and go on?
[07:22] <rogpeppe> dimitern: i think i'll just go with your fix actually. if you really want a non mainline revision, you can have one
[07:22] <rogpeppe> dimitern: it should be obvious in the .tsv file anyway
[07:22] <dimitern> rogpeppe, sounds good
[07:26] <rogpeppe> dimitern: reviewed
[07:31] <dimitern> rogpeppe, thanks!
[07:32] <dimitern> rogpeppe, I think you should manually merge the MP, as there's no bot to pick it up
[07:38] <rogpeppe> dimitern: merged (ooo, my bzr-fu is getting rusty!)
[07:40] <dimitern> rogpeppe, :) mine too
[07:57] <dooferlad> dimitern: great! Lets do it and go drink some beer!
[07:57]  * dooferlad knows that TheMue would rather drink whisky
[07:57] <TheMue> dooferlad: good idea, got time next week monday. wonna meet in London?
[07:57] <dimitern> \o/
[07:58] <TheMue> dooferlad: ah, you know me right
[08:00] <dooferlad> TheMue: I think you meen tuesday. Well, maybe Monday evening...
[08:01] <TheMue> dooferlad: yeah, Monday evening
[09:01] <dimitern> dooferlad, voidspace, standup?
[09:01] <voidspace> dimitern: trying, it's not letting me in :-/
[09:01] <voidspace> restarting the browser
[09:01] <dimitern> voidspace, oh boy :/ monday hangout issues
[09:02] <voidspace> dimitern: not having used this machine for six weeks issues too...
[09:02] <voidspace> 350mb of updates
[09:02] <voidspace> including a new firefox - that maybe the issue
[09:02] <voidspace> that looks better
[10:03] <voidspace> dimitern: ready
[10:03] <dimitern> voidspace, omw
[11:33] <dimitern> fwereade, hey, are you around today?
[12:49] <TheMue> dimitern: btw, the provider I meant has been the vsphere one. i has a partial implementation of the networking interface
[12:53] <dimitern> TheMue, ok, so for vsphere then SupportsSpaces will be false, but the other method will remain
[12:53] <TheMue> dimitern: yep, did it that way
[12:54] <dimitern> TheMue, +1
[13:11] <redelmann> hi, im having some problem with juju-gui
[13:11] <redelmann> machine-0 logs says:  error stopping *state.Multiwatcher resource: unit not found
[13:12] <redelmann> everytime i load juju-gui on browser
[13:12] <redelmann> and no icons appears
[13:12] <redelmann> this is a juju bug or gui?
[13:18] <redelmann> i open this issue: https://bugs.launchpad.net/juju-gui/+bug/1485249
[13:18] <mup> Bug #1485249: Juju gui is not loading. <juju-gui:New> <https://launchpad.net/bugs/1485249>
[13:56] <rogpeppe> anyone know about the openstack provider?
[13:57] <urulama> dimitern: ^
[13:59] <mup> Bug #1486106 changed: TestNetworkInterfaces fails on vivid/wily <ci> <ec2-provider> <intermittent-failure> <test-failure> <juju-core:Fix Released by dooferlad> <https://launchpad.net/bugs/1486106>
[13:59] <rogpeppe> in particular at this moment I'm interesting in understanding the different roles of the tenant-name (taken from env var OS_REGION_NAME) and region (no env var) attributes
[14:01] <mgz> rogpeppe: you have that mixed up, tenant-name is taken from OS_TENANT_NAME
[14:02] <mgz> it's a user-specific grouping of resources
[14:02] <rogpeppe> mgz: so they are - not sure how i read that wrong
[14:02] <mgz> whereas regions are a cloud-level seperation
[14:03] <rogpeppe> mgz: for some reason i'd copied/pasted the wrong env vars and didn't check back to the source
[14:03] <rogpeppe> mgz: i did think it was potentially very confusing :)
[14:04] <rogpeppe> mgz: one weird thing: why does openstack fall back to using the ec2 passwords?
[14:07] <mgz> rogpeppe: there's a semi-compatible ec2 api, so many of the rcs set the same vars for ec2
[14:07] <rogpeppe> mgz: it seems like a potential security leak to me
[14:08] <rogpeppe> mgz: and i don't see any other values that do the same thing
[14:08] <wwitzel3> fwereade: ping
[14:08] <fwereade> wwitzel3, pong
[14:09] <wwitzel3> fwereade: katco isn't feeling well, are you able to move up our discussion to now? so she can take off and get some rest
[14:09] <fwereade> wwitzel3, sure, let's
[14:09] <rogpeppe> mgz: and surely if it was using AWS_SECRET_ACCESS_KEY it ought to use AWS_ACCESS_KEY_ID too?
[14:09] <wwitzel3> fwereade: we are in moonstone, https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1
[14:12] <mgz> rogpeppe: the names used are just based on what was looked at in practice by the clients
[14:15] <mgz> and there's not really a security issue, the access ley/secret key are not passed along unless you say you're using that authmode
[14:15] <rogpeppe> mgz: do you think it might be reasonable to drop support for using AWS_SECRET_ACCESS_KEY and EC2_SECRET_KEYS for the openstack password?
[14:15] <mgz> so you need to be pretty deliberate about wanting it
[14:16] <rogpeppe> mgz: isn't userpass the default auth mode?
[14:17] <rogpeppe> mgz: so ISTM that it'll send that password in the usual case
[14:17] <mgz> and it's basically always going over https to somewhere that won't be loging your auth attempts
[14:18] <mgz> you'd need to have and endpoint url manually set to something hostile, or dns poisoned
[14:18] <rogpeppe> mgz: from the p.o.v. of the user that's not necessarily true - they don't know what's at the other end
[14:18] <mgz> and also have accidentally sourced your ec2 creds
[14:18] <mgz> I don't think the ec2 provider is robust against that
[14:19] <mgz> we don't check that the ec2 endpoint is really amazon
[14:19] <rogpeppe> mgz: i think we do, don't we
[14:19] <rogpeppe> mgz: 'cos we use https
[14:19] <rogpeppe> mgz: without using InsecureSkipVerify
[14:19] <rogpeppe> ?
[14:19] <mgz> that just verifies it has been signed by something in your chain
[14:20] <mgz> it doesn't verify what it is.
[14:20] <rogpeppe> mgz: well, same security as any website :)
[14:20] <rogpeppe> mgz: and, yes, i'm well aware that https security is a farce
[14:21] <mgz> the ec2 signing mechanism is better though, in not passing along the secret
[14:21] <rogpeppe> mgz: but we all blithely go on assuming that verisign et al are somewhat reliable
[14:22] <rogpeppe> mgz: i mean, fair enough i guess if people actually use AWS_SECRET_ACCESS_KEY for their openstack password, we don't wanna break that
[14:22] <rogpeppe> mgz: it just triggers my Something Wrong Here sense.
[14:23] <mgz> I think it's likely not really used any more, all the current rc things will at least include both, and generally only the OS_ versions
[14:23] <mgz> just whether it's worth futzing with
[14:24] <rogpeppe> mgz: i'm moving the env vars into the openstack provider to do the environschema stuff, and it made me wonder...
[14:25] <rogpeppe> mgz: i mean, maybe goose.v1/identity should export the env var names
[14:29] <mup> Bug #1465404 changed: worker/provisioner: fail lxcBrokerSuite.TestStartInstanceLoopMountsDisallowed <intermittent-failure> <unit-tests> <juju-core:Fix Released by dooferlad> <https://launchpad.net/bugs/1465404>
[14:29] <mup> Bug #1473209 changed: github.com/juju/juju/service/windows undefined: newConn <ci> <intermittent-failure> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by bteleaga> <juju-core trunk:Fix Released by bteleaga> <https://launchpad.net/bugs/1473209>
[14:35] <mup> Bug #1465404 opened: worker/provisioner: fail lxcBrokerSuite.TestStartInstanceLoopMountsDisallowed <intermittent-failure> <unit-tests> <juju-core:Fix Released by dooferlad> <https://launchpad.net/bugs/1465404>
[14:35] <mup> Bug #1473209 opened: github.com/juju/juju/service/windows undefined: newConn <ci> <intermittent-failure> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by bteleaga> <juju-core trunk:Fix Released by bteleaga> <https://launchpad.net/bugs/1473209>
[14:39] <dimitern> fwereade, hey
[14:40] <dimitern> fwereade, does this look in line with what we discussed? http://reviews.vapour.ws/r/2463/
[14:41] <rogpeppe> mgz: this is what i've got: http://paste.ubuntu.com/12184056/
[14:41] <mup> Bug #1465404 changed: worker/provisioner: fail lxcBrokerSuite.TestStartInstanceLoopMountsDisallowed <intermittent-failure> <unit-tests> <juju-core:Fix Released by dooferlad> <https://launchpad.net/bugs/1465404>
[14:41] <mup> Bug #1473209 changed: github.com/juju/juju/service/windows undefined: newConn <ci> <intermittent-failure> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by bteleaga> <juju-core trunk:Fix Released by bteleaga> <https://launchpad.net/bugs/1473209>
[14:41] <rogpeppe> mgz: does that look reasonable to you?
[14:42] <rogpeppe> mgz: actually, i should avoid copy/pasting those env vars
[14:45] <mgz> rogpeppe: you have EC2_SECRET_KEYS ... with an S
[14:46] <rogpeppe> mgz: that's what goose uses
[14:46] <mgz> also, not really to do here, but we should add tenant-id already
[14:47] <mgz> heh, in which case you probably can just delete it, as it's been wrong for a while then
[14:47] <rogpeppe> mgz: :)
[14:47] <rogpeppe> mgz: i suspect the same of AWS_SECRET_ACCESS_KEY too
[14:47] <mup> Bug # changed: 1458717, 1461393, 1463641, 1467372, 1474788, 1478660, 1484617
[14:47] <rogpeppe> mgz: but i'm actually thinking i don't want to risk breaking anything at all
[14:48] <mgz> rogpeppe: no, that one is right, the old naming there was just dumb
[14:48] <rogpeppe> mgz: i know it's right - i just think that using an AWS name for openstack creds is silly
[14:49] <rogpeppe> mgz: particularly when it doesn't use AWS_ACCESS_KEY_ID for one of the user names
[14:49] <mgz> it was the only way to use non-password auth on the old hp cloud
[14:49] <mgz> as there aren't OS names for the different values
[14:51] <rogpeppe> mgz: ah, makes sense
[14:59] <rogpeppe> mgz: ok, here's a review for you: https://github.com/go-goose/goose/pull/14
[14:59] <mup> Bug #1459064 changed: worker/leadership: data races in test and code <intermittent-failure> <tech-debt> <unit-tests> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1459064>
[14:59] <dimitern> voidspace, dooferlad, TheMue, please have a look at these last 2 PRs we need to unblock merging net-cli into master: http://reviews.vapour.ws/r/2463/ and http://reviews.vapour.ws/r/2464/
[14:59] <mup> Bug #1460893 changed: many unhandled assigned values <tech-debt> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1460893>
[15:01]  * dimitern steps out, bbl
[15:02] <frobware> hello all - new starter on the Juju Sapphire team today.
[15:02] <mgz> rogpeppe: looks fine. as I hinted earlier, there are some bigger bits that could do with fixing in the os auth stuff, but nothing that blocks this change.
[15:02] <mgz> frobware: hey there!
[15:02] <rogpeppe> mgz: thanks
[15:03] <mgz> frobware: another Andrew?
[15:03] <frobware> mgz, tis the way...
[15:06] <ericsnow> fwereade: we didn't mean to chase you away! :)
[15:11] <mup> Bug #1459064 opened: worker/leadership: data races in test and code <intermittent-failure> <tech-debt> <unit-tests> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1459064>
[15:11] <mup> Bug #1460893 opened: many unhandled assigned values <tech-debt> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1460893>
[15:14] <rogpeppe> mgz: could you land my goose branch for me please? i'm not a member of goose collaborators currently
[15:17] <mup> Bug #1459064 changed: worker/leadership: data races in test and code <intermittent-failure> <tech-debt> <unit-tests> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1459064>
[15:17] <mup> Bug #1460893 changed: many unhandled assigned values <tech-debt> <juju-core:Fix Released by dave-cheney> <https://launchpad.net/bugs/1460893>
[15:18] <redelmann> anyone know about juju-gui?
[15:18] <redelmann> im trying to debug an issue
[15:18] <natefinch> redelmann: probably better to ask in #juju
[15:19] <redelmann> thank natefinch
[15:19] <voidspace> dooferlad: I see you reviewed the first one, are you looking at the second too?
[15:19] <mgz> rogpeppe: erm... can't remember exactly but the bot may actually just still check if you're a juju memeber
[15:19] <dooferlad> voidspace: yes
[15:19] <mgz> rogpeppe: added the comment anywa
[15:19] <rogpeppe> mgz: thanks
[15:21] <voidspace> dooferlad: ok, I'll leave it to you :-)
[15:21] <voidspace> thanks
[15:21] <dooferlad> voidspace: I haven't graduated yet. I suggest you look at the first one first - it seems to have been committed with the second as well.
[15:21] <dooferlad> voidspace: then you know which bits to ignore :-)
[15:22] <voidspace> ah
[15:22] <voidspace> I did think the second had some extraneous stuff in it
[15:23] <voidspace> dooferlad: dimitern: first looks good and it tells me which bits of the second I can ignore too
[15:24] <voidspace> in which case the second looks trivial
[15:24] <voidspace> dooferlad: although I missed the concern you raised, need to read the code agian!
[15:24] <voidspace> *again
[15:29] <mup> Bug #1488139 opened: juju should add nodes IPs to no-proxy list <juju-core:New> <https://launchpad.net/bugs/1488139>
[15:35] <mup> Bug #1488139 changed: juju should add nodes IPs to no-proxy list <juju-core:New> <https://launchpad.net/bugs/1488139>
[15:48] <mup> Bug #1488139 opened: juju should add nodes IPs to no-proxy list <juju-core:New> <https://launchpad.net/bugs/1488139>
[16:01] <bodie_> is the answer to why godeps is used rather than godep a simple one?
[16:01] <alexisb> welcome frobware !
[16:05] <mgz> bodie_: godeps is older than godep
[16:07] <bodie_> I see.  thanks mgz o/
[16:26] <rogpeppe> mgz and anyone else: fancy a smallish review of a change to the openstack provider code? http://reviews.vapour.ws/r/2465/
[16:27] <dimitern> katco & moonstone: fwereade texted me about an hour ago his power's out and wanted to convey this apologies
[16:27] <dimitern> voidspace, dooferlad, thanks for the reviews guys!
[16:30] <mgz> rogpeppe: looks fine in general, the descriptions are a bit all over the place though, do you want nitpicks?
[16:30] <rogpeppe> mgz: specific suggestions would be great
[16:30] <rogpeppe> mgz: i copied the descriptions from the boilerplate
[16:31] <rogpeppe> mgz: much appreciated
[16:31] <mgz> ah, so they're now it two places? that's a bit unfortunate.
[16:31] <rogpeppe> mgz: when i get some extra time, the plan is to generate the boilerplate from the schema
[16:31] <mgz> how much will you hit me over the head if I ask you about generating the boilerplate from the schema?
[16:32] <mgz> eheh, you win.
[16:32] <rogpeppe> :)
[16:33] <rogpeppe> mgz: i'm also not liking my decision to go with partial sentences for the descriptions. using go-like full sentences seems like it's a better plan in the end.
[16:34] <rogpeppe> mgz: but these things are fairly easy to change
[16:38] <mgz> rogpeppe: review'd
[16:38] <rogpeppe> mgz: ta v much
[16:39] <rogpeppe> mgz: not sure about mentioning that control-bucket will be auto-generated - that's kinda true of every parameter that's optional.
[16:41] <mgz> I'm a little antsy on that one as setting it can be actually harmful... but it can also just be required
[16:46] <rogpeppe> when would it be required?
[16:47] <rogpeppe> mgz: perhaps a comment in the description saying "(do not set this unless you know what you are doing)" might be appropriate
[16:47] <mgz> rogpeppe: yeah, but leave it for now, don't need to futz with here.
[16:48] <rogpeppe> mgz: k
[16:48] <mgz> we need it for ci testing on canonistack, I *think* it's related to being able to cleanup reliably
[16:57] <mup> Bug #1488166 opened: Service with just one unit left which doesn't think it's the leader <landscape> <leadership> <juju-core:New> <https://launchpad.net/bugs/1488166>
[17:21] <perrito666> bbl groceries shopping
[17:44] <natefinch> ericsnow: getting this error when running featuretests: charm not found in "/home/nate/src/github.com/juju/juju/testcharms/charm-repo": local:quantal/workload-actions
[17:46] <ericsnow> natefinch: is it actually there (/home/nate/src/github.com/juju/juju/testcharms/charm-repo/quantal/workload-actions)?
[17:47] <ericsnow> natefinch: perhaps still named "proc-actions"?
[17:47] <ericsnow> natefinch: (which should be fixed)
[17:49] <natefinch> ericsnow: doh, yep
[17:49] <natefinch> I blame wwitzel3
[17:49] <ericsnow> natefinch: :)
[17:51] <natefinch> ericsnow: I'll submit a PR to rename them
[17:51] <ericsnow> natefinch: sounds good
[18:19] <wwitzel3> :(
[19:28] <natefinch> I think I got whatever katco has.  I should remember to wear a mask to hangouts from now on.
[20:54] <mup> Bug #1488245 opened: Recurring lxc issue: failed to retrieve the template to clone  <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1488245>
[21:47] <davechen1y> ping http://reviews.vapour.ws/r/2458/
[22:22] <perrito666> davechen1y: ship it, I am happy that that is being worked :)
[22:22] <perrito666> there is only a typo in the description
[23:10] <davechen1y> perrito666: thanks