[01:03] <rick_h_> benji: yea, it'll work. It just breaks things like storing a value with a '.' in it and then trying to query it back out
[01:48] <gary_poster> hey huwshimi.  how you. :-)
[01:49] <huwshimi> gary_poster: Hey. Good. Doing QA :)
[01:50] <gary_poster> Cool!  Thanks huwshimi.  Things looking OK?
[01:50] <huwshimi> gary_poster: Yep, hit something small...
[01:51] <gary_poster> Cool.  We're hoping to make a release early next week so it would be great if we were in good shape
[01:51] <huwshimi> gary_poster: I've only just started, but things look pretty reasonable.
[01:52] <huwshimi> gary_poster: Certainly  looks like the highest level of polish across the board that we've ever had.
[01:57] <gary_poster> Awesome. :-) huwshimi, I'm sorry I didn't call you this evening.  I talked with everyone else this week to ask if they had any post-sprint thoughts and if we ought to consider anything about ye olde yearly goals (https://docs.google.com/a/canonical.com/document/d/1hzcQ40d-z_xC0x62uc7o1uQR16NjIM3itF5XW8MtJkw/edit).  It looks to me like we are doing quite well with your goals.  Would you like to schedule a call on you
[01:57] <gary_poster> r Tuesday morning next week to talk about these things, or is everything ok, or...? :-)
[01:57] <gary_poster> (if everything is ok then we'll just wait till next week)
[02:00] <huwshimi> gary_poster: I think things are going fine. I don't have any questions/concerns about goals, at least not from my end :)
[02:00] <gary_poster> heh, cool huwshimi 
[02:00] <gary_poster> ok, have a great weekend and talk to you next week. :-)
[02:00] <huwshimi> gary_poster: Thanks Gary, have a good evening and weekend :)
[02:01] <gary_poster> thanks :-)
[03:08] <marcoceppi> rick_h_: I put charm-tools 1.1.0 on pypi for you ;)
[03:09] <marcoceppi> rick_h_: that being said, 1.1.0 is "released" just waiting for the builders to finish
[03:09] <marcoceppi> how do you guys usually install it? from package or tarbal?
[11:15] <rick_h_> marcoceppi: you rick!
[11:16] <rick_h_> marcoceppi: if it's on pypi we'll pull it downinto a download-cache so we can install it sans internet and such with a lock version
[11:16] <rick_h_> marcoceppi: I think last time we did a custom python package build and stuck it in there, so we just have to update it with the new .tar.gz
[12:05] <gary_poster> rick_h_, "you rick!" ? :-)
[12:05] <rick_h_> gary_poster: lol too early in the morning 
[12:05] <gary_poster> :-)
[12:05] <rick_h_> marcoceppi: there's more rocking than 'ricking' in that ^^
[12:05] <rick_h_> at least they keys are next to each other
[12:05] <rick_h_> I wasn't that nuts this morning
[12:10] <gary_poster> hey bac, when you are adding the basket name to search, could you double check that we include bundle charm names as search terms too?  If we don't do that now and it is easy to add that at the same time, please add it; if it is not that easy we can have a separate card.
[12:11] <gary_poster> BradCrittenden, ^^^
[12:11] <rick_h_> bundle charm names? The names of the charms inside the bundle?
[12:12] <gary_poster> rick_h_, yes
[12:24] <BradCrittenden> gary_poster: yeah i'm pretty sure we do that
[12:24] <BradCrittenden> at least we have a test for it
[12:26] <rick_h_> gary_poster: bac yea http://comingsoon.jujucharms.com/sidebar/search/:flags:/charmworldv3/?text=mysql pulls upt he wiki/wordpress bundles
[12:26] <rick_h_> even though the search was for wordpress
[12:26] <rick_h_> err, mysql
[12:26] <gary_poster> bac, rick_h_ awesome, thanks
[12:27] <gary_poster> another card bites the dust ;-)
[12:42] <marcoceppi> rick_h_: YOU RICK AND ROLL!
[12:43] <rick_h_> marcoceppi: hah, tried not to go there
[12:43] <marcoceppi> it is early here
[12:53] <gary_poster> lol
[13:09]  * gary_poster out for a bit
[13:10] <bac> jujugui: one review/qa please of https://codereview.appspot.com/20780043/ -- note QA instructions in follow-on email.
[13:26] <bac> hey rick_h_, any free time to do the above review.  it is for the bug you filed!  :)  (very short too)
[13:26] <rick_h_> bac: yea, just in deep atm. Can look in a few. 
[13:26] <bac> thanks
[14:06] <hatch> so how was halloween for everyone?
[14:06] <gary_poster> good
[14:06] <hatch> we only had 2 groups of kids haha
[14:06] <hatch> it started raining
[14:06] <hatch> and kids these days are weak!
[14:14] <rick_h_> bac: starting review/qa now, relations are freaking mind melting
[14:18] <hatch> finally someone else who had to deal with them :P
[14:20] <rick_h_> hatch: rain didn't hurt too much http://www.flickr.com/photos/7508761@N03/10601718093/ they still bussed (literally) people in to the neighborhood. Later pics show the street just lining up with cars from outside the neighborhood. There's usually NO cars on the street
[14:20] <hatch> do you live outside the city?
[14:20] <rick_h_> no, I live inside a small-ish town
[14:21] <rick_h_> in a sub division
[14:21] <hatch> ohh - I was gona say....driving? lol
[14:22] <hatch> The only time we drove was to get to family and friends who were on the other side of the city
[14:22] <rick_h_> benji: can you do qa on bac's branch please? My virtualenv is all out of date now witht he new deployer stuff I was working on
[14:23] <hatch> could usually get more than enough candy within the neighbourhood
[14:23]  * rick_h_ finds the downside of colo
[14:23] <benji> rick_h_: sure, which branch is it?
[14:23] <rick_h_> benji: lp:~bac/charmworld/bug-1246459 
[14:23] <rick_h_> benji: from https://codereview.appspot.com/20780043/
[14:23] <rick_h_> benji: thanks!
[14:23] <benji> np
[14:24] <rick_h_> hatch: yea, we always run out so got $100 of candy this year and went through 3/4 of it. Without the rain I think I would have gotten closer to going through it all
[14:24] <hatch> well with people bussing their kids in no kiddin
[14:24] <hatch> g
[14:25] <hatch> did they at least say 'trick or treat' ?
[14:25] <hatch> or just ring the doorbell
[14:25]  * hatch doesn't give candy to kids who just ring the doorbell
[14:25] <rick_h_> yea, scond year we got a limo, only this time it was a limo bus vs a limo car
[14:25] <rick_h_> yea, most say it, some have to be forced to say it. I ignore kids that come up to me and just hold out their pillow case
[14:25] <hatch> haha yup
[14:25] <hatch> FYI you CAN just do a trick :)
[14:27] <BradCrittenden> hi rick_h_, thanks for the review.  as to the scoring question, i guess they can be reversed.  that just affects the order the results are shown, right?
[14:27] <rick_h_> bac: right
[14:27] <bac> rick_h_: i'll do it then
[14:27] <rick_h_> bac: thanks, I think it'll give better results that way
[14:36] <bac> rick_h_: qa ok?
[14:37] <rick_h_> bac: benji is doing qa. I've updated my colo-virtualenv a bit and makes it hard for me to qa 
[14:43] <hatch> the windows 'tile' for the store always says I have updates, but when I open it, nothing....
[14:44] <hatch> it's probably a conspiracy
[14:46]  * rick_h_ shakes fist at "old chunk mismatch"!!!!!!!!!!!
[14:46] <rick_h_> go through all of lbox for a pretty side by side review of my code and get nadda
[14:50] <hatch> rick_h_: well it also gives the rest of us peace of mind knowing that something else has 'reviewed' your code before we have to :P
[14:50] <gary_poster> jujugui call in 10
[14:50] <rick_h_> heh, I like to do that so "I" can review it before I ask everyone else to. -wip ftw
[14:50] <rick_h_> and help me find bits missing tests/etc
[14:51] <hatch> so when I try to do `make test-debug &` it breaks out of the background when the node process hits
[14:52] <hatch> I'm guessing I'm missing something?
[14:58] <gary_poster> jujugui call in 2
[14:58] <bac> ha, the cool ones are already there
[15:08] <benji> jujugui: I have a charmworld branch up for review that adds metrics tracking infrastructure (a model and source): https://codereview.appspot.com/20820043
[15:09] <bac> benji: did you do the qa on my branch?  i'll review yours.
[15:09] <benji> bac: the injest is still running
[15:09] <bac> benji: oh, you didn't change the limit to 10.
[15:10] <benji> bac: I ran the commands you put in the RV; you should have included rm -rf /
[15:10] <bac> oopsie
[15:12] <jcastro> hey gary_poster
[15:12] <jcastro> for mediawiki you basically want me to cat the two files together
[15:12] <jcastro> and call it "mediawiki"
[15:12] <gary_poster> hey jcastro on call
[15:13] <jcastro> but the environment names are like "mediawiki-simple", "mediawiki-scalable" and so on
[15:13]  * jcastro nods
[15:13] <gary_poster> jcastro, can scalable inherit simple?
[15:16] <jcastro> I don't know anything about how inheritance works in bundles
[15:16] <jcastro> I know how to shift-d is about it, heh
[15:27] <benji> arg, the ingest still isn't done; I guess I'll start again with a limit
[15:28] <gary_poster> jcastro, see http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/configs/blog.yaml
[15:28] <rick_h_> gary_poster: yea, we ingest with inheritence, but I wasn't aware of it until recently. I'm not sure how that'll proof. That requires pulling in the deployer config stuff I think.
[15:28] <gary_poster> rick_h_, uh-oh
[15:28]  * rick_h_ needs more test cases/examples ugh
[15:29] <gary_poster> rick_h_, could you confer with brad or benji on that?  they know where the inheritance bidies are buried
[15:29] <rick_h_> gary_poster: yea, that's the functionality we used the deployer for before that changed so much I copied it out to move forward. 
[15:29] <gary_poster> bodies
[15:29] <rick_h_> gary_poster: yep, will do. 
[15:29] <gary_poster> thanks
[15:30] <benji> I would suspect proofing after inheritence would be the way to go.
[15:30] <rick_h_> benji: yea, since this just came up yesterday that's been my take and part of the trail of XXX: but worth a real bug to make sure proof supports inheritence
[15:31] <benji> yeah, the proof tool needs to support inheritence because it will be given those kinds of deployer files to process, we won't have those though, so we should proof what actually gets stored in the DB
[15:31] <rick_h_> so jcastro, forget you heard about inheritence for a few days :)
[15:32] <jcastro> ok so should I keep them seperate for now?
[15:32] <jcastro> I need to version them still though
[15:32] <jcastro> want me to do that now?
[15:33] <rick_h_> version the services?
[15:40] <gary_poster> the charms.  Yes please jcastro.  also, note that we display your branch name and the bundle name in the GUI, so that might affect how you name things
[15:41] <gary_poster> for example
[15:41] <gary_poster> see http://comingsoon.jujucharms.com/sidebar/search/:flags:/charmworldv3/?text=jorge
[15:41] <gary_poster> we could make those names smaller I suspect
[15:41] <jcastro> you mean on the left?
[15:42] <gary_poster> yeah
[15:46] <hatch> jcastro: on Tuesday I'm going to be doing a demo of juju/GUI on my laptop what's a good collection of charms to deploy that will illustrate it's awesomeness the best?
[15:47] <jcastro> hatch, what's the audience?
[15:47] <hatch> http://www.prairiedevcon.com/
[15:47] <hatch> it's a windows slanted conference
[15:47] <hatch> but mostly developers
[15:48] <hatch> I'll be sure to mention that it works on Azure & windows but it's definitely being demo'd on Ubuntu :)
[15:48] <benji> bac: QA looks good; I only got one result for the search "muletrain" (the expected bundle)
[15:49] <jcastro> hatch, dude, do the rails charm on azure
[15:49] <jcastro> that would be epic
[15:49] <bac> benji: cool.
[15:49] <bac> my goal is to now right a proper muletrain bundle.
[15:49] <hatch> I know nothing of azure or rails haha, not sure I want to do that live
[15:50] <jcastro> so do what you know
[15:50] <jcastro> ghost?
[15:50] <jcastro> rick_h_, ok versioned things pushed
[15:51] <jcastro> rick_h_, how can I test the bundle from the store itself
[15:51] <hatch> jcastro: I was thinking of doing it on lxc since it'll be at a conference I'm not sure how reliable the internet will be
[15:51] <hatch> and relying on hotspot probably isn't wise either
[15:51] <jcastro> like If I wanted to deploy what's in the store in 15 minutes
[15:51] <bac> rick_h_: you didn't use the magic LGTM on my review
[15:52] <bac> rick_h_: found here https://codereview.appspot.com/20780043/
[15:52] <bac> it is all sad and ungreen
[15:52] <bac> and rv-submit hates it
[15:52] <jcastro> hatch, have something fired up and GUIed, the show it, then be like "ok, but our internet is flaky, so let's move locally"
[15:53] <jcastro> then juju switch and show the same stack running on LXC.
[15:53] <hatch> oh that's cool
[15:53] <jcastro> yeah
[15:53] <hatch> I could do an apache/wordpress/haproxy/mysql deployment?
[15:54] <rick_h_> bac: because I was waiting for QA to do it
[15:54] <rick_h_> that's benji's job :P
[15:54] <jcastro> and then you say "Same deployment, on my cloud and on my laptop." and go right into rick's spiel on how you guys can fire things up easily and test just like you would on a real deployment
[15:54] <jcastro> if internet is fine just switch back and forth
[15:54] <bac> rick_h_, benji would one of you fine people approve my review?
[15:54] <benji> bac: sure
[15:54] <jcastro> you want to show how you can do the same thing on any substrate
[15:55] <rick_h_> did qa get an ok? oh /me missed his irc omment
[15:55] <benji> bac: done
[15:55] <bac> ty
[15:55] <rick_h_> jcastro: "test the bundle from the store itself"? you mean find it and deploy it on comingsoon?
[15:55] <hatch> jcastro: good idea thanks
[15:55] <rick_h_> jcastro: http://comingsoon.jujucharms.com/:flags:/charmworldv3/ search, hit deploy
[15:57] <jcastro> rick_h_, I mean deployed for real. or do I wait for the gui to land to do that, then deploy on the real thing?
[15:57] <jcastro> rick_h_, I think I'm asking chicken/egg.
[15:57] <jcastro> let's say I want to test the bundles I am submitting
[15:57] <rick_h_> jcastro: you can use the deployer or the quickstart tool from the email that gary_poster sent out yesterday
[15:58] <jcastro> oh dude, the alpha quickstart one, totally missed it, thanks!
[15:58] <gary_poster> rick_h_, jcastro the version in the PPA only supports downloaded files.  URLs are in trunk but not in PPA yet, sorry :-/.  Next week
[15:59] <jcastro> yeah that's fine
[15:59] <gary_poster> downloaded bundle files I mean
[15:59] <gary_poster> cool
[15:59] <rick_h_> gary_poster: right, but jcastro can test his bundle file works locally
[15:59] <jcastro> I just didn't want to only test on deployer
[15:59] <gary_poster> oh, definitely
[15:59] <rick_h_> to lxc or aws or anything
[15:59] <jcastro> I am not worried about the bundle not working from my local file
[15:59] <jcastro> I am worried about testing it from the store
[15:59] <gary_poster> yeah, that's a great test because it uses the GUI charm to deploy
[15:59] <gary_poster> so it works in quickstart
[15:59] <gary_poster> then you are testing the GUI
[15:59] <gary_poster> in one command
[16:03] <hatch> Makyo: did you see that bug come in about upgrade charm?
[16:04] <hatch> is that a gui or charmworld issue?
[16:05] <Makyo> hatch, Both?
[16:06] <Makyo> hatch, charmworld doesn't give us a list of downgradeable versions, though we do have revision info.
[16:06] <Makyo> We could request against each version but that'd be dumb.
[16:06] <hatch> ohh ok -
[16:06] <hatch> for example precise/mysql-27/ shows me rev 28 no matter what
[16:07] <Makyo> non-linear charm versions is interesting, though.
[16:07] <Makyo> hatch, I believe you get latest no matter what.
[16:07] <Makyo> That was the backfilling, I believe.
[16:07] <hatch> ok so the 'links' to show those versions is.....useless?
[16:07] <Makyo> Until we move to api v3 I think
[16:08] <rick_h_> yep, api3 supports versioned charms as part of the bundle work
[16:08] <hatch> ahh ok cool
[16:08] <Makyo> I can't really afford to switch right now, hatch.  That answer most concerns?
[16:09] <hatch> Makyo: yep that points me in the right direction
[16:09] <hatch> thanks
[16:09] <Makyo> Cool
[16:13] <hatch> yeah mysql jumps from 22 to 28 which is odd I suppose :)
[16:16] <jcastro> wow gary_poster
[16:16] <jcastro> this plugin is my new god
[16:16] <gary_poster> jcastro, lol awesome
[16:17] <jcastro> gary_poster, where do I file bugs?
[16:18] <gary_poster> jcastro, https://bugs.launchpad.net/juju-quickstart/+filebug
[16:18] <jcastro> how is the bootstrap so fast?
[16:18] <rick_h_> :)
[16:20] <gary_poster> jcastro, getting the GUI up via the API means that we don't have to wait on downloading the charm to your local system and uploading it to the environment--it just goes straight from the charm store to the environment without a middleman; getting it up on machine 0 simply means we don't have to wait on another machine, but that's probably something you already do
[16:20] <jcastro> man, that is a thing of beauty
[16:21] <jcastro> I'm going to start filing bugs even though you mention the limitations in your mail so we can track them, is that cool? 
[16:21] <gary_poster> +1 thanks jcastro
[16:24] <jcastro> man, it's deploying the bundle
[16:24] <jcastro> awesome.
[16:24] <jcastro> dude, THANK YOU for putting the gui password in the console too
[16:24] <jcastro> that is perfect
[16:25] <jcastro> ok so the one thing I can't do is ... juju-quickstart <remote URL>, that's what's coming next week
[16:25] <gary_poster> right
[16:26] <gary_poster> we will auto-log-you-in soon, too, and have the GUI tell you where to find your password in the future, or to just use quickstart again to open the GUI in this environment, so you don't have to look at the console
[16:32] <hatch> so with the upgrade charm details, do we want to open up the charm browser? or open it in the inspector breakout?
[16:42] <Makyo> Finally got this. Man, SVG scaling is weird. I can never remember when I need to take the scale into account.
[16:43] <Makyo> Test, then propose.
[16:51] <hatch> hmm huw found quite the bug with this linking issue
[16:56] <hatch> rick_h_: got a second?
[16:57] <rick_h_> hatch: yea
[16:57] <hatch> I THINK I found a browser routing bug...but not sure
[16:57] <hatch> steps are
[16:57] <hatch> http://comingsoon.jujucharms.com/:flags:/charmworldv3/
[16:57] <hatch> deploy mysql
[16:58] <hatch> click 'upgrade service'
[16:58] <hatch> click mysql-27
[16:58] <hatch> (it should open the browser)
[16:58] <hatch> click the X in the browser details page
[16:58] <hatch> click mysql-27 in the inspector again
[16:58] <hatch> note the # in the url now
[16:58] <rick_h_> hatch: yea
[16:59] <Makyo> Cute.  HaaS (hugs as a service) http://www.nowcheerup.me/  How would one charm a hug?
[16:59] <rick_h_> hatch: sec
[17:00] <rick_h_> hatch: I don't have time to go through it but I can walk you through what to check
[17:00] <rick_h_> hatch: hangout?
[17:00] <hatch> sure link?
[17:00] <rick_h_> https://plus.google.com/hangouts/_/72cpj09acjl4ip5f6bjgt8fkqg?hl=en
[17:04] <bac> benji: after LP noticed your LGTM rv-submit was happy.  so the process is working as we'd hoped.
[17:12] <benji> bac: cool
[17:15] <benji> bac: how goes the review of https://codereview.appspot.com/20820043 ?
[17:16] <hatch> rick_h_: thought you'd find this interesting....viewNavigate is not being fired to open the panel :)
[17:16] <hatch> I think some of our routing code has become self aware
[17:16] <rick_h_> hatch: well then there's your problem. :)
[17:17] <rick_h_> hatch: so it's not updating _viewState in a sane way then I bet
[17:17] <hatch> that's probably exactly it
[17:17] <rick_h_> hatch: so will be curious to see how _viewState is getting updated and such
[17:17] <rick_h_> what values it ends up with
[17:17] <rick_h_> hatch: but it makes sense, that version of the View isn't tied to the subapp/browser.js
[17:18] <rick_h_> hatch: I mean that the inspector isn't tied to the browser state like that. /me is trying to think but brain is fried
[17:18] <hatch> yeah that's fine I'll keep tracking it down
[17:18] <rick_h_> hatch: yea, I mean there's still something sticknig it in the hash
[17:19] <hatch> the ie redirect is happening before that i've found
[17:19] <hatch> so this is a separate bug
[17:19] <rick_h_> hatch: the other thing to drop a debugger into is the sidebar: function in browser.js to check the request to see if the routing is passing it in as a hash then and we're picking it up
[17:19] <rick_h_> hatch: ok, yea, if that's not using the viewNavigate i wonder if it's just something where YUI isn't blocking the <a> for IE
[17:20] <rick_h_> hatch: it might just be a simple case of that the inspector needs to catch upgrade <a> clicks and do a manual navigate change 
[17:20] <hatch> yeah i'm going to hope that I can restore the pjax functionality
[17:20] <hatch> i'd rather not fire events all around
[17:20] <rick_h_> yea, true
[17:21] <hatch> ok sidebar is not being called
[17:22] <rick_h_> hatch: the details view can't open without it being called :/
[17:22] <hatch> the details view is rendered via 'renderEditorial' right?
[17:22] <hatch> (it's also not being called)
[17:23] <rick_h_> hatch: no, it's from sidebar
[17:23] <hatch> what in the....
[17:23] <rick_h_> benji: got a few min?
[17:23] <benji> rick_h_: sure
[17:24] <rick_h_> benji: https://plus.google.com/hangouts/_/72cpin08id5me7l01r1rnplpgg?hl=en
[17:27] <hatch> gary_poster: did you ever figure out why chrome wasn't catching your debugger statements?
[17:27] <hatch> I'm running into the same issue right now
[17:29] <rick_h_> hatch: you don't have them turned 'off' by change?
[17:29] <rick_h_> chance?
[17:29] <hatch> I wish
[17:29] <hatch> haha
[17:29] <rick_h_> ok, just checking. It's the only way I know to stop them
[17:29] <rick_h_> well, and the dev tools are open?
[17:29]  * rick_h_ ducks
[17:29] <hatch> lol
[17:30] <hatch> I have a debugger in routeDefault in browser.js and it's loading without stopping
[17:30] <hatch> that's not even possible.....
[17:30] <hatch> had to restart chrome
[17:30] <hatch> working now
[17:30] <rick_h_> so it's connected to the window? Or did you split the debugger/window?
[17:30] <rick_h_> oh, cool
[17:31] <gary_poster> hatch on call sorry
[17:32] <hatch> no problem, a reboot fixed it
[17:38] <gary_poster> so...I keep thinking that, if we don't have a "ghost" stage for bundles, we need bundles to ask for configuration
[17:38] <gary_poster> The only use case I had was openstack
[17:38] <gary_poster> which we were told was not a driver
[17:38] <gary_poster> but what about passwords
[17:38] <gary_poster> we want to have passwords and such excluded from export
[17:38] <rick_h_> yea, I've been wishing a couple of times for at least an editor window "edit this bnudle before deploying"
[17:39] <gary_poster> yeah
[17:39] <hatch> why is a ghost bundle stage so bad?
[17:39] <gary_poster> I'm picturing an inspector that lets you configure values that a bundle author has highlighted as needing configuration
[17:39] <gary_poster> because it is expensive to build and we have been told not to work on it :-)
[17:40] <rick_h_> heh, I was thinking a quick first pass is just loading the content as an editable field as yaml
[17:40] <gary_poster> huh, could be
[17:40] <rick_h_> then hit deploy and it could validate and then go
[17:40] <hatch> haha oh ok
[17:40] <gary_poster> not the GUI expereince though
[17:40] <rick_h_> true
[17:40]  * gary_poster has to step away.  back soon
[17:40] <hatch> I was thinking deploy the bundle as ghosts which the user can go into each service to modify
[17:40] <hatch> then click one 'deploy all' button
[17:40] <gary_poster> that was the original plan, yes
[17:41] <gary_poster> even that would arguably want an interface like the one I'm describing though
[17:41] <hatch> yup
[17:41] <gary_poster> "yeah, you can customize this thing, but you *really* ought to fill these out
[17:41] <gary_poster> "
[17:43] <hatch> I could see that as a logical progression from some type of form validation
[17:43] <hatch> or not...
[17:43] <hatch> :)
[17:50] <Makyo> jujugui lf review/QA https://codereview.appspot.com/20870043
[17:50] <hatch> ill do it
[17:50] <hatch> i need a break :)
[17:58] <hatch> Makyo: done lgtm qaok
[17:58] <Makyo> Whew~
[17:58] <hatch> 8 minute review/qa turnaround
[17:58] <hatch> not bad :P
[17:59] <Makyo> Heck yeah :D
[18:00] <hatch> I'm really getting nowhere with this routing issue
[18:01] <rick_h_> hatch: you hitting it enough to see if it's coming into the routed view handler's req object as with a hash?
[18:01] <Makyo> hatch, I agree that we should introduce bounding box stuff to the real topology at some point, in another branch.  Rather than just centering the canvas, it would center and scale as with bundles.
[18:01] <hatch> rick_h_: well I've determined that it's before any of the browser stuff
[18:01] <hatch> it's definitely routing issues
[18:01] <hatch> Makyo: sounds good :)
[18:01] <rick_h_> hatch: yea, so walking through the ns-routing stuff is the fun part. Obvious chase anything with hash interactions first
[18:02] <rick_h_> someone's telling it to do it, just have to find where it's coming from
[18:03] <hatch> sometimes I really hate YUI wrapping everything for convenience
[18:03] <hatch> :)
[18:05] <hatch> I do know that it's an even listening on the body for clicks to a's
[18:05] <hatch> :)
[18:05] <rick_h_> yea, that's the app framework stuff
[18:06] <hatch> right, but setting linkSelector to '.not-an-a' should disable it
[18:07] <benji> rick_h_: I don't see any big problems with your branch (just a few lint-type things that we can address in the real review); I'm going to take a stab at a little refactoring to see if it looks like something you would want
[18:08] <rick_h_> benji: thanks, appreciate the punch-drunk sanity check
[18:09] <hatch> Ooo getting closer
[18:09] <hatch> _navigate doesn't get called in IE
[18:18] <bac> benji: in https://codereview.appspot.com/20820043/diff/1/charmworld/models.py on line 1905 how is bucket_index ever None?
[18:18]  * benji looks
[18:18] <hatch> ahah
[18:18] <hatch> !
[18:18] <bac> maybe you're missing a test in the find method?
[18:18] <hatch> sometimes debugging the hard way gets the best results
[18:19] <benji> bac: if the increment is for a day that is so far in the past that there is no daily bucket for it
[18:19] <benji> I will add something to that effect to the comment.
[18:19] <bac> benji: but how?  i don't see any such logic in _find_day_offset
[18:20] <benji> bac: ooh!  you're right; there is a missing test that should have excersized that branch and pointed out the problem
[18:20] <benji> I'll add that test and then fix.
[18:20] <bac> benji: i'm not to the tests yet!
[18:21] <benji> I would *really* like us to start using test coverage.  This is exactly the kind of problem it helps find.
[18:22] <hatch> rick_h_: so this bug is not at all related to the browser stuff - that's an entirely separate issue caused by pjax routing the link vs going through the navigate... just FYI
[18:22] <rick_h_> benji: I think nose is spitting out coverage already? /me goes to check makefile
[18:22] <rick_h_> hatch: yea, that's what I figured. The only way to prove it was to verify that it was happening in the req and not in our viewNavigate calls
[18:23] <hatch> it's a pretty rare sequence of events so that's why we never caught it before
[18:23] <rick_h_> rgr
[18:23] <hatch> hopefully the removal of the router stuff allows us to remove the browser url parsing
[18:23] <benji> rick_h_: I'm thinking of a very specific kind of coverage, i.e., define a set of tests that should cover a set of code and verify that the coverage is 100%
[18:24] <rick_h_> benji: ok, looks like we're not using it but nose supports using coverage.py if it's avail
[18:24] <benji> you can build such a thing from simple code coverage, but it takes some work (I have such a system for my termbeamer project and it is great, if a bit ridgid in its requirements)
[18:24] <rick_h_> https://nose.readthedocs.org/en/latest/plugins/cover.html
[18:24] <hatch> going to grab some lunch
[18:24] <hatch> bbiab
[18:24] <rick_h_> benji: yea, gotcha
[18:29] <benji> rick_h_: here is some example output: http://i.imgur.com/4KuW5WZ.jpg
[18:30] <rick_h_> benji: cool
[18:37] <rick_h_> benji: pushing up the api tests and some tweaks due to errors the tests pointed out
[18:38] <rick_h_> benji: lp:~rharding/charmworld/proof-relations
[18:42] <bac> benji: i think it is safer to use datetime.utcnow().date() instead of datetime.date.today() given my yearning to live a tz-free existence.
[18:43] <bac> if huw were to run tests right now he'd get a different today than we would and that might break things.
[18:53] <benji> bac: I'm pretty confident that the tests will never fail do to time (but I'll give them another once-over to be sure), but I think naive dates are actually the right thing to do here, otherwise utcnow().date() might give us a day that isn't the right day 
[18:55] <rick_h_> benji: up for a follow up? I'll peek at the original notes of things to clean up and see what you think regardling reorg and try to finish up quick?
[18:56] <benji> rick_h_: I haven't written the lint-y notes yet, as I figured you might change some, but I'll be glad to do the follow-up now and include them there
[18:56] <rick_h_> benji: cool
[18:57] <bac> benji: how could utcnow().date() not be the right date if we agree to always be in UTC?.  seems unintended date offset is more likely the other way.  but, having looked at your tests and they way you always used defined dates i agree it is unlikely.  could have problems if someone adds a test that uses current time...but i guess that's just a bad test.
[18:58] <bac> s/they way/the way/
[19:16] <bac> benji: review done
[19:17] <benji> bac: thanks!
[19:19] <rick_h_> benji: https://codereview.appspot.com/20810043/ is up with reviewer comments. 
[19:19] <rick_h_> benji: thanks again for the help and sanity checks today
[19:20] <benji> rick_h_: my pleasure; looking now
[19:44] <gary_poster> jujugui, if anyone has any bandwidth to bring a hack home, http://paste.ubuntu.com/6343083/ makes all of jorge's non-broken bundles (that is, all but reviewboard) show up in the bundle visualization.  Makyo, I know you are making magic happen and I appreciate it, but if you apply that patch and then look at http://localhost:8888/sidebar/search/bundle/~jorge/mediawiki-scalable/4/mediawiki-scalable/:flags:/charmworldv
[19:44] <gary_poster> 3/?text=jorge , you'll see the first bundle visualizatio that actually pushes a charm partially off the screen
[19:44] <gary_poster> http://localhost:8888/sidebar/search/bundle/~jorge/mediawiki-scalable/4/mediawiki-scalable/:flags:/charmworldv3/?text=jorge
[19:44]  * gary_poster goes to get boys from school
[19:56] <Makyo> Something's wonky about this bundle.
[19:57] <Makyo> The 'contribute' command is listed as `bzr branch lp:~jorge/mediawiki-scalable/4/mediawiki-scalable` but should be `bzr branch lp:~jorge/charms/bundles/mediawiki-scalable/bundle`, and the yaml indentation is off (which may be the actual root of the problem)
[19:58] <Makyo> Uh, nevermind the indentation, sorry, I'm a liar.
[20:01] <gary_poster> Makyo, the branch issue is in the GUI.  My branch fixes it
[20:02] <gary_poster> I mean, my hack :-P
[20:02] <gary_poster> jujugui, am I right in guessing that no-one took the branch?  If so, I'll get to it ASAP
[20:03] <Makyo> Oh, I totally misread :(
[20:03] <Makyo> Sorry :S  No, didn't pick it up.
[20:03] <hatch> gary_poster: hey sorry I can eventually, I'm just writing a repro of this IE bug to see if it's a YUI/IE issue or something in our app
[20:08] <gary_poster> Makyo, hatch, cool, np thanks, will carry it in a few
[20:18] <hatch> ahah! it's a YUI bug
[20:18] <hatch> that took way to long
[20:19] <hatch> jujugui anyone with IE10 available for a quick sanity check?
[20:19] <Makyo> Yyyyyeah...just a sec.
[20:19] <Makyo> Let me start up.
[20:19] <gary_poster> :-)
[20:19] <hatch> Makyo: thanks :)
[20:20] <hatch> I just need a sanity check on this http://jsbin.com/ExoDUGIt/1/edit
[20:20] <hatch> there is a monkey patch which, if deleted, will allow the 'rockon' url to be added to the address bar, but in chrome everything always works as expected
[20:21] <hatch> gary_poster: ok now I can do your branch above if still needed
[20:23] <gary_poster> hatch, oh, thanks, would be awesome.  Just wrote first test.  Probably need two more--one for situation of import with a yaml file that specifies a name, and *maybe* one for the small deploy tab fix I made.
[20:23] <gary_poster> Last one might be unnecessary.
[20:24] <hatch> alrighty, can you paste the new diff?
[20:24] <gary_poster> yeah, one sec
[20:25] <Makyo> hatch, what am I looking for now?  URL doesn't change with or without monkey patch.
[20:26] <Makyo> Oh, hmm.
[20:26] <Makyo> IE may just be lame.
[20:27] <hatch> ohh it needs to be in not /edit mode sorry
[20:28] <Makyo> Oh, okay
[20:29] <gary_poster> hatch, http://paste.ubuntu.com/6343329/ .  The charm id revision change may be nastier than I had hoped.  Test I wrote fails, as you'll see.  Feel free to toss it back, but I suspect you'll make short work of it.  Part of QA should be to verify that all of Jorge's working bundles now show a visualization
[20:29] <Makyo> hatch, confirmed
[20:29] <hatch> Makyo: thanks :)
[20:29] <hatch> your work here is done
[20:29] <hatch> you may go
[20:30] <gary_poster> :-P
[20:30] <hatch> haha
[20:30]  * gary_poster returns to spreadsheet that he had escaped for a brief shining moment
[20:30] <hatch> ok can you give me a real quick overview of what the problem/solution was
[20:33] <benji> rick_h_: I'm done with https://codereview.appspot.com/20810043/
[20:36] <gary_poster> hatch, sorry, yeah.  So, the main point of this is to make it so that Jorge's bundles actually had working bundle visualizations.
[20:36] <gary_poster> The patch also has some unrelated text flybys on the bundle page
[20:37] <gary_poster> The reason why the bundles were not visualizing was that they were not importing properly.  I discovered this by trying to deploy them, and getting the nice new error massages you made yesterday, hatch.
[20:37] <gary_poster> So there were two issues.
[20:37] <hatch> sweet
[20:37] <hatch> haha
[20:37] <gary_poster> First, the discourse bundle has a charm without a revision
[20:38] <gary_poster> this caused a problem because the fake backend refused to handle it...because our charm id parser refused to handle it
[20:38] <gary_poster> I'm a little bit nervous that the change I made there will have repercussions.
[20:39] <bac> rick_h_: you have a moment for a quick call?
[20:39] <hatch> alrighty well I'll put it through its paces
[20:39] <hatch> and I'll land this wako ie fix at some point too
[20:40] <gary_poster> Second, hatch, another bundle had an issue because it wanted to deploy mysql twice.  It turns out that the fakebackend was completely ignoring the service names in the deployer file.  It also turns out that it had a bunch of code that wasn't ever doing anything.  That's the code that I deleted in fakebackend, and replaced with just setting .name
[20:40] <hatch> haha
[20:40] <hatch> awesome
[20:40] <gary_poster> That's his "mediawiki-scalable" bundle, fwiw
[20:41] <gary_poster> So those are the only two bundle-related fixes
[20:44] <hatch> sounds good
[20:47] <marcoceppi> gary_poster: do you have a link to the doc from the sprint about bundles v2?
[20:47] <gary_poster> marcoceppi, https://docs.google.com/a/canonical.com/document/d/1fmlRgMoQhdwsF5w9jPApNrTM1obXHvDwuE85kx8EsbU/edit ?
[20:47] <marcoceppi> gary_poster: Yes, thank you!
[20:48] <gary_poster> welcome :-)
[20:50] <gary_poster> marcoceppi, unfortunately, we probably won't be doing that (because we have been told not to, because of other priorities :-) ).  Something I want to propose that we prioritize is that bundles gain config fields.  Before deploying, you would need to fill in, say, password fields or other bits like the ceph thing.  I think we probably need something like this eventually, but the question is importance/prioritization.
[20:51] <gary_poster> I'll be looking for opinions later
[20:51] <gary_poster> but feel free to share now if you have any immediate ones :-)
[20:51] <marcoceppi> gary_poster: oh, yeah I saw that. I just couldn't remember the word "immutable" embarrasingly enough and needed to use it. So, I know it was recorded during that session :)
[20:51] <gary_poster> heh, ok cool :-)
[20:51] <marcoceppi> gary_poster: that idea starts to sound a lot like stacks at that point
[20:52]  * marcoceppi wonders why we just don't grow bundles in to stacks
[20:52]  * marcoceppi walks away wondering to himself
[20:52] <hatch> what happens with an immutable object encounters an immutable force?
[20:52] <gary_poster> marcoceppi, yeah, that's being proposed actively :-)
[20:52] <hatch> ....wait that's not right... :P

[20:52] <marcoceppi> hatch: marriage? Is that the answer?
[20:53] <hatch> I'm not sure
[20:53] <hatch> this sounds like a job for.....*spins around*......
[20:53] <hatch> HATCH MAN!
[20:59] <rick_h_> bac: sure thing, give me 2min?
[20:59] <rick_h_> benji: thanks for the review
[21:00] <bac> rick_h_: ok
[21:01] <rick_h_> bac: https://plus.google.com/hangouts/_/7acpjhgnd2ie5j8vpvbiko0b3o?hl=en
[21:08]  * Makyo walks dogs.
[21:08] <Makyo> May also head out a bit early today since last night was so messed up.
[21:11] <marcoceppi> greetings gui folks, there are two merges in the queue that have been here for a while. Not sure you guys were aware of it or not:  https://code.launchpad.net/~benji/charms/precise/juju-gui/fix-cache-headers/+merge/177958 and https://code.launchpad.net/~frankban/charms/precise/juju-gui/guiserver-bundles-initial/+merge/179750
[21:11] <marcoceppi> is there any action I can take on either of these?
[21:12] <rick_h_> benji: ^
[21:12] <bac> thanks rick
[21:13]  * bac walks dog between storms (i hope)
[21:13] <rick_h_> bac: np, let me know if you need anything
[21:13] <rick_h_> and if proof gives you trouble blame marcoceppi :P
[21:13]  * marcoceppi twiddles thumbs
[21:17] <gary_poster> :-)
[21:19] <gary_poster> jujugui, this is the new, new, new prioritized spreadsheet of possible Nov-Dec tasks for us.  We'll work down these as far as we can in the timeframe, while also responding to bugs and the like.  This is timeboxed: we get done what we get done in the time period.  https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AtC9etoysSQldDQxMVdmTDB4dm1XXzA0NFlLSUQ4Mmc&usp=drive_web#gid=0
[21:19] <gary_poster> Comments welcome.  I'm sending it to mramm
[21:20] <hatch> gary_poster: you have no 'units' on your cost column
[21:20] <hatch> spreadsheet fail :P
[21:20] <gary_poster> Note I reordered some of the things from the discussion with luca, but it should look familiar
[21:20] <gary_poster> hatch :-P it is planning-poker style arbitrary units :-)
[21:21] <hatch> ohhh haha gotcha
[21:21] <gary_poster> hatch that's why it says "relative" ;-)
[21:21] <hatch> iiiiiii seee now
[21:21] <rick_h_> hatch: don't try to out manager the manager :P
[21:21] <gary_poster> heh
[21:21] <hatch> haha
[21:34] <hatch> Makyo: I found a issue with your algo for positioning bundles - view the bundle vis for mediawiki-scalable bundle - just FYI
[21:35] <hatch> I can file a bug if you don't want to look at it now :)
[21:38] <hatch> oh actually nm, this won't be an issue when we add pan/zoom
[21:47] <Makyo> hatch, I thought that was the problem we were running into with gary_poster's branch? That whole bundle was busted for me.
[21:47] <Makyo> Like, most things about it.
[21:47] <hatch> Makyo: yeah sorry it's fixed now but only locally
[21:48] <hatch> so what happens is because it's to tall it doesn't fit becauseit looks like it has a padding on the canvas bottom
[21:48] <Makyo> Oh, okay.
[21:49] <Makyo> Yeh, probably later.  Surprise company in a few, and me, without any makeup on!
[21:49] <hatch> haha
[22:46] <hatch> still haven't been able to figure out a proper indention for chaining with the linter
[22:57] <rick_h_> because chaining is evil :P
[23:00] <hatch> but but promises!
[23:03]  * gary_poster runs away.  have a great weekend everyone!  If anyone has a review they need, I'll check in mail every now and then
[23:04] <hatch> you too! I'll be proposing the branch with a bit of modifications :)
[23:04] <gary_poster> awesome
[23:12] <hatch> gary_poster|away: whenever you pop back https://codereview.appspot.com/21020043/ I have added reviewer notes where things were modified from your diff
[23:13] <hatch> I'll get the IE branch proposed tonight sometime as well but now I need a break :)