[11:52] <antdillon> rick_h, Hi, would you be able to help get me set up with the latest juju gui?
[11:52] <rick_h> howdy antdillon 
[11:52] <rick_h> sure, sounds like fun :)
[11:52] <antdillon> rick_h, lol thanks
[11:53] <antdillon> rick_h, If I can get it running locally or access to a staging I can mess with that would be great
[11:53] <rick_h> antdillon: did you want to run a quick hangout first to kind of figure out where we are or did you have a specific trouble getting it going
[11:54] <antdillon> rick_h, Yeah sure
[11:54] <rick_h> antdillon: there's two ways to go. 1) check out the source with bzr and go through the hacking doc http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/HACKING
[11:54] <rick_h> antdillon: or 2) use the charm to get an instance up and running in canonistack and then ssh into it and work on it remote
[11:55] <rick_h> antdillon: forgive me if I offend, but going to assume nothing. Have you used bzr much? setup a LP account?
[11:56] <antdillon> rick_h, That's fine, yes use bzr for our sites and have an account
[11:56] <antdillon> rick_h, nick is ya-bo-ng
[11:57] <rick_h> antdillon: ok, then maybe this will be easy. just bzr checkout lp:juju-gui and then walk through this hacking doc that's in the root of the tree
[11:57] <rick_h> antdillon: you can probably skip the rapi-rolloup step and just use the sandbox. 
[11:57] <rick_h> antdillon: so start with line 47 of that hacking doc
[11:58] <antdillon> rick_h, Will do
[11:58] <rick_h> antdillon: and let me know if you run into trouble. 
[11:59] <antdillon> rick_h, I sure will
[12:53] <antdillon> rick_h, Its working a treat, thanks
[12:54] <rick_h> antdillon: awesome
[12:55] <rick_h> antdillon: make sure to shout if run into anything. 
[12:56] <antdillon> rick_h, I will, thanks
[13:12] <gary_poster> frankban, yay on first branch :-)
[13:12] <frankban> :-)
[13:56] <hatch> morning
[13:57] <benji> rick_h: I could use some ideas on how to wire up access to app.modelController.getCharm.  If you could look at https://codereview.appspot.com/10500044/diff/1/app/widgets/charm-container.js and let me know what you thing, I would appreciate it.
[13:58] <rick_h> benji: otp will look in a sec. 
[13:58] <benji> thanks!
[13:58] <benji> my instinct is to send app.modelController.getCharm through as part of the config, but I can't trace the config and object instantiation all the way back to app
[13:59] <hatch> benji: did you see how the deploy method is passed into the subapp in the app.js initializer?
[13:59] <benji> hatch: nope, I'll take a look at that
[14:00] <benji> hatch: actually, I have seen that... I did it. :)
[14:00] <hatch> I only ask because on line 222 you use some reference to app instead
[14:00] <benji> The problem is that I don't see the chain of causality that starts in app and ends in the charm container widget
[14:01] <rick_h> benji: ok looking
[14:01] <benji> hatch: right, that's what I'm trying to remove
[14:01] <rick_h> so benji I'd assume we'd do the same thing we did in the add button to get the charm data we've got, turn it into a Charm model instance, and use that in the drop event. 
[14:02] <rick_h> benji: guichat?
[14:02] <hatch> sorry I'm having some issues with my vm
[14:02] <benji> rick_h: sure, but I need a minute to prepare;  I'll ping you in a couple
[14:02] <rick_h> benji: rgr
[14:05] <benji> rick_h: I'm in guichat
[14:14] <abentley> orangesquad: could you please review https://code.launchpad.net/~abentley/charmworld/remove-bzr-ingest-job/+merge/170899 ?
[14:14]  * sinzui looks
[14:18] <gary_poster> hey hazmat, did you see my email about deployer?  sound ok?
[14:26] <sinzui> abentley, r=me
[14:26] <abentley> sinzui: Thanks!
[14:29] <bac> hi benji
[14:29] <hatch> benji: did you want a review on /charm-dnd-2 ?
[14:30] <bac> benji: when you have a moment, i need to ask you about some stuff in go sandbox
[14:31] <benji> hatch: not quite yet; I have to tweak a couple of things
[14:31] <benji> bac: ok, it'll be a couple of minutes
[14:31] <hatch> alrighty, lemme know when
[14:40] <benji> bac: I'm free
[14:44] <bac> benji: guichat?
[14:44] <benji> bac: sure
[14:53] <abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-scan-ingest-job/+merge/171093 ?
[14:55]  * sinzui does
[14:59] <sinzui> abentley, r=me
[15:13] <hazmat> gary_poster, sounds good
[15:13] <gary_poster> awesome thanks hazmat
[15:25] <hazmat> gary_poster, reply sent
[15:25] <gary_poster> thank you :-)
[15:33] <rick_h> benji: https://code.launchpad.net/~rharding/juju-gui/dnd-test/+merge/171121 is kind of what I was talking about. It's not working right (evt is empty of any data) but the events fire 
[15:33]  * benji looks.
[15:34] <rick_h> benji: note I moved the functions inside to try to gain a closure so only one copy of the json'd data was kept around for each charm-token instance
[15:34] <rick_h> so hacky hacky 
[15:35] <benji> :)
[15:35] <benji> that's pretty close to what I have
[15:50] <bcsaller> I'm having trouble tracking down some bleeding tests on my branch, its somewhere in the existing code. Maybe after the meeting somone can help look at lp:~bcsaller/juju-gui/ghosttown/ with me?
[15:50] <gary_poster> jujugui call in 10, kanban now pls
[15:50] <hatch> bcsaller: sure
[15:51] <bcsaller> hatch: thanks
[15:55] <abentley> orangesquad: could you please review https://code.launchpad.net/~abentley/charmworld/remove-jenkins-ingest-job/+merge/171124 ?
[15:56] <sinzui> okay
[15:59] <gary_poster> jujugui cll now
[15:59] <gary_poster> ish
[16:09] <hatch> rick_h: are the featured charms queries cached on the server? sometimes they come in in a slightly different order which would imply no...
[16:09] <hatch> sorry ^ abentley
[16:10] <abentley> hatch: No, they aren't.
[16:10] <hatch> ahh ok - should I file a bug for that? or is it a known thing?
[16:12] <abentley> hatch: No, caching will only be implemented if and when we need it.
[16:12] <rick_h> hatch: what's up/wrong with the featured charm order/etc?
[16:12] <rick_h> hatch: featured charms are manually selected and can change at any time
[16:12] <rick_h> hatch: so not sure if you're just generally worried about speed or you're setting up a test or something to rely on that info
[16:13] <hatch> rick_h: abentley just curious - I figure if it's building a list every request I figure it was wasteful load on that server
[16:14] <rick_h> hatch: so right now it's not. Since featured can be changed by ~charmers it responds immediately :)
[16:14] <abentley> hatch: We're not aware of any performance problems on the server.
[16:14] <rick_h> hatch: and for now the perf isn't an issue
[16:14] <sinzui> abentley, r=me
[16:14] <hatch> yeah it's not an issue now
[16:15] <rick_h> hatch: so yea, no caching atm since we don't need it. Our deployment includes squid and can be added as required down the road. 
[16:15] <hatch> ahh cool cool
[16:15] <abentley> hatch: Premature optimization is the root of all evil.
[16:17] <hatch> :)
[16:24] <benji> rick_h: am I correct that the charm's attributes just get slammed on the charm token object?  I need a clean set of object attributes to JSONify.
[16:24] <rick_h> benji: correct. the charm token is passed the model.getAttrs()
[16:24] <rick_h> benji: in my example that's the cfg stored in the intializer 
[16:24] <rick_h> benji: I stored that cfg off so that it was kept clean from the token's attrs
[16:25] <benji> rick_h: ah, gotcha
[16:26] <Makyo> hatch, when you get a sec, would like to talk about a task.
[16:28] <hatch> sure
[16:29] <hatch> Makyo: guichat?
[16:29] <Makyo> Sure, be right there.
[16:50] <hatch> bcsaller: when the db is destroyed there is no destroy method
[16:51] <hatch> so it doesn't necessarily detach those events...trying that now
[16:51] <bcsaller> hatch: I suspect I might need to retain the handle and free them manually 
[16:53] <hatch> yeah that didn't work :)
[16:55] <hatch> nope that didn't help either
[16:57] <hatch> bcsaller: you should probably merge trunk into this to take advantage of the fixes teknico did to the tests
[17:00] <hatch> oh that didn't help either
[17:00] <hatch> heh
[17:05] <hatch> arg
[17:08] <hatch> bcsaller: ok any of my 'ideas' didn't pan out :( next step would be to go test by test commenting them out
[17:08] <bcsaller> hatch: thanks for looking, I'll merge trunk and try again, was hoping you'd spot something I'm missing
[17:09] <bcsaller> we still use way too much state to test :-/
[17:09] <hatch> yeah - my new branch moves the deploy/inspector code into an app extension so that it can be unit tested properly
[17:09] <hatch> sorry I coudln't be of any real help
[17:12] <bcsaller> hatch: I appreciate the time, thanks
[17:13] <benji> rick_h: I got a crazy error when trying to instantiate a charm model (var charm = new models.Charm(charmData);
[17:13] <rick_h> benji: crazy?
[17:13] <benji> ): Uncaught TypeError: Cannot use 'in' operator to search for 'bubbleTargets' in {"initialized":true,"destroyed":false,"distro_series":"precise" [... lots more]
[17:13] <rick_h> benji: can you paste me the lots more into a pastebin please?
[17:13] <benji> and bifurcated
[17:14]  * rick_h wonders if getting more than supposed to and wtf is up with that
[17:14] <benji> rick_h: com
[17:14] <benji> pfft
[17:14] <benji> rick_h: http://paste.ubuntu.com/5796075/
[17:17] <rick_h> benji: so in looking at the data, the two that jump out at me are initialized and destroyed? Can you try doing a quick hack of del charmData.inialized and charmData.destroyed and see if that changes things?
[17:17] <rick_h> benji: and then we can chase them down if that's the issue
[17:17]  * benji tries
[17:17] <rick_h> hatch: isn't there a way to tell YUI to ignore non-declared attrs in a initializer?
[17:17]  * rick_h can't find a flag/setting for that atm
[17:18] <hatch> I'm a little confused - if they aren't declared then they shouldn't exist?
[17:18] <hatch> I'm probably missunderstanding
[17:18] <rick_h> hatch: maybe I'm assuming 
[17:18] <rick_h> hatch: sec, let me try something. 
[17:25] <hatch> aww man today is a Canadian holiday
[17:25]  * hatch grumbles about The Man
[17:25] <bcsaller> swap day?
[17:26] <hatch> well I didn't even know it's a holiday, just noticed on the calendar hah
[17:27] <benji> rick_h: I figured it out: that was just a string, I forgot to parse it back into an object.
[17:28] <rick_h> benji: ah ok yay
[17:36] <gary_poster> hatch,  since you are working you can use this as a swap day.  Take another day off within the next few weeks and claim it in canonicaladmin as a "swap day" and reference the national holiday
[17:40] <gary_poster> jujugui and orangesquad, you all are invited to participate in the great bundle naming vote of 2013, sent out by luca__ a little while ago.  Participate if you like. :-)  Use comments n the google doc
[17:40]  * rick_h ducks
[17:40] <gary_poster> (thanks again luca__  :-) )
[17:41] <luca__> gary_poster: np
[17:42] <sinzui> gary_poster, thanks. I am still pondering, hoping for something that will be a great transitional name for the bright future
[17:42] <gary_poster> :-) cool sinzui
[17:42] <hatch> I'm confused by this vote
[17:43] <hatch> I need continuous ads on Fox News to tell me what to vote for
[17:43] <gary_poster> lol
[17:43] <rick_h> gary_poster: now this is the idea of a environment dump/load setup right?
[17:43] <gary_poster> rick_h, yes.  in contrast to stacks
[17:44] <hatch> although they are almost the same thing
[17:44] <hatch> :)
[17:47] <rick_h> ok, went out on a limb and ranted against the idea from the beginning :)
[17:47] <hatch> ranting is on a limb for you? are you sure....?
[17:47] <hatch> :P
[17:47]  * hatch ducks
[17:47] <rick_h> hah, see you caught the irony there didn't you :P
[17:47] <hazmat> let's call them chundles ;-)
[17:47] <hatch> haha
[17:48] <rick_h> eundles!
[17:48] <hatch> undies!
[17:48] <bcsaller> charm bracelets 
[17:48]  * rick_h forsees the Haynes lawsuit
[17:48] <hatch> charm undies
[17:48] <hatch> wait till we get our charms on you
[17:50] <hatch> Makyo: run into any issues with the viewlet stuff?
[17:51] <Makyo> hatch, nah, it's interesting, pretty easy to read. 
[17:51] <hatch> good good
[17:52]  * hazmat has a zope3 flashback from hearing viewlet
[17:53] <hatch> I had to google that
[17:53] <hatch> :)
[17:53] <rick_h> hazmat: yea, makes me cringe every time I review a branch!
[17:54] <hatch> jujugui can we simply call bundles stacks and make the difference transparent? They virtually are the same thing as far as the user is concerned it's only the implementation that differs
[17:54] <rick_h> hatch: no no no no no kthx no :)
[17:54] <hatch> why not?
[17:55] <bcsaller> hatch: it is more complex than that, stacks will have hooks and so on, and persistent identity. You can make a case that a stack with no hooks is very similar though
[17:55] <rick_h> this is why I want to ditch the 'charm' and make one about the environment and one about the charm
[17:55] <hazmat> hatch, except stacks have meaning oonce their imported
[17:55] <hazmat> hatch, bundles don't
[17:55] <rick_h> one is just a dump of the current environment and you can reload that environment, the other is a full on charm, with an api, etc
[17:55] <hatch> that's fine - that can be an added feature to stacks once they are done
[17:55] <gary_poster> hatch, also Mark S says no.  So...it's important that you understand the difference, but... :-)
[17:55] <bcsaller> they could though, that property is either useful or ignorable 
[17:56] <hatch> right now a 'stack' could simply be a collection of charms
[17:56] <rick_h> hatch: think of system backups vs a meta package. 
[17:56] <hatch> then we could add these 'hooks' and the like lateron
[17:56] <hazmat> a stack is a logical (really hierarchical) grouping with exported endpoints and possibly additional behavior, they want for different visualization in the gui as well.
[17:56] <hazmat> ie i can zoom into a stack
[17:56] <rick_h> system backup is just a dump/restore of the files where they were. A meta package is itself a package that can have install hooks/etc and brings together a bunch of individual packages
[17:56] <hatch> I understand that - however I think that we are going to confuse our users when these stacks come out
[17:57] <hatch> it is confusing enough that we need a vote about it
[17:57] <hatch> so clearly there is something not right here
[17:57] <rick_h> hatch: I'm partially with you. I wish we'd drop the charm part of the bundles name to help keep them seperate
[17:58] <hatch> you can think of a stack as a wrapper around a bundle which implements additional functionality ie) hooks
[17:58] <hatch> which could then be thought of an enhancement ontop of a bundle
[17:58] <rick_h> disagree :)
[17:58] <hatch> I don't know who wrote this but in the vote it even says """We currently think that we will want to deprecate this idea once we have stacks, but we don’t know when stacks will appear.  It could be well over a year."""
[17:59] <gary_poster> hatch we can treat a stack like a bundle, but we can't treat a bundle like a stack.  Kapil's explanation gets to the heart of it.
[17:59] <gary_poster> I wrote that
[17:59] <hatch> which means that stack is a logical enhancement of a bundle
[18:00] <hatch> I foresee 1000 of these questions "Which do I want, the wordpress bundle or wordpress stack?"
[18:00] <hatch> "what is the difference between the wordpress bundle and the wordpress stack?"
[18:00] <gary_poster> hatch, the plan AIUI is that people will never ask that.  Once we have stacks, we will deprecate and/or convert and rename bundles.
[18:01] <hatch> exactly
[18:01] <hatch> so why don't we just call bundles stacks
[18:01] <hatch> and add features to it
[18:01] <bcsaller> two similar concepts is bad, I agree, but I think your understanding is flipped, bundles are dumbed down stacks rather than an enhancement story the other way 
[18:01] <rick_h> I still use a use for this idea of taking your current environment (maybe with multiple stacks deployed) and backing that up/restoring it via the bundles functionality
[18:01] <rick_h> I still would see a use that is...ugh
[18:01] <hatch> rick_h: then that could be called an 'export'
[18:02] <rick_h> then let's call it an export now and now confuse people :)
[18:02] <gary_poster> hatch, because that's not what Mark S wants.  to make this argument, put it in the doc.  Happily, Mark R has agreed to make the decision, because I did not want to.
[18:02] <rick_h> and environment export hehe
[18:03] <hatch> alright I'll add to the doc, thanks for the discussion to flesh out my idea :)
[18:03] <bcsaller> rick_h: it might be a subset of the environment and it might be added to an existing env on import. I think environment in those cases implies too much
[18:09] <hatch> document updated, feel free to tear me apart :P
[18:11] <hatch> now I forget what I was doing prior to this vote
[18:11] <hatch> lol
[18:14] <hatch> oh now I remember
[18:14] <hatch> bcsaller: is your code 'stable' pending this test fix so I can start looking at integrating?
[18:17] <robbiew> gary_poster: nice work to you and your team on the new gui
[18:18]  * hatch pats team on the back
[18:18] <robbiew> ...and I should probably thank the designers...so a nod to them as well
[18:18] <robbiew> it's fucking awesome ;)
[18:19] <hatch> and it's only going to get better :)
[18:21] <rick_h> bcsaller: I guess technically we could do that but my understanding is that it's an all or nothing dump currently. True you can import into an existing environment, but again, it seems to match up more with backup/restore. 
[18:21] <hatch> rick_h: that name backs you into a corner
[18:21] <hatch> an 'export' is generic enough to work for anything
[18:22] <hatch> a name needs to be generic enough to not back you into a corner but specific enough to describe what it does
[18:22] <rick_h> hatch: but I don't mind. We've got something better coming along. It's a place holder and this way it's kept apart. but it's how I see it. Let the rest fall into place. 
[18:24] <hatch> I think we agree but are disagreeing on semantics :P
[18:24] <hatch> "my export name can beat up your export name"
[18:24] <hatch> :D
[18:30] <gary_poster> thanks robbiew :-)
[18:34] <hatch> dialog or dialogue ?
[18:36] <benji> For the LP project we used British English, I expect that is still the default.
[18:38] <hatch> dialogue it is
[18:41] <hatch> grabbing lunch, ding if ya need me
[18:56]  * Makyo lunch
[19:37]  * bac seeks reviewers https://codereview.appspot.com/10522043
[19:38] <hatch> holy smotes
[19:38] <hatch> that's a large diff
[19:38] <hatch> smokes*
[19:40] <hatch> oh and yes bac I'll do it
[19:40] <hatch> :)
[19:40] <bac> hatch: make sure you use the link i pasted not the other
[19:41] <hatch> yup used that one
[19:41] <bac> hatch: ok.  i accidentally re-used a branch name and lbox tacked it on to a months old review
[19:41] <hatch> oh heh - yeah I've done that before
[19:41] <hatch> kind of a issue with bzr I suppose
[19:43] <gary_poster> jujugui could I have three volunteers to review the wireframes luca just sent out, before EoD today?  If I get more than three, bonus!  I want at least three, other than me.  orangesquad, if you have feedback, it would be appreciated as well, but please get it in today.
[19:44] <bac> o/
[19:44] <hatch> I will
[19:44] <hatch> but he didn't attach the wireframes
[19:44] <hatch> I replied to him to mention that :)
[19:45] <bac> if he's gone that's going to make it hard to get reviewed by eOd
[19:45] <hatch> lol
[19:45] <hatch> hopefully he gets his email on his phone and will realize eventually
[19:47] <sinzui> thank's gary_poster, I had not notices I had email
[19:48] <gary_poster> hatch, bac, I think it might have been ripped from the mailing list
[19:48] <luca__> Hi all, was my wireframe attached to my email?
[19:48] <gary_poster> luca__, it was
[19:48] <gary_poster> not your fault
[19:48] <gary_poster> I think the mailing list ripped it out
[19:48] <gary_poster> I can forward to people
[19:48] <gary_poster> go relax :-)
[19:48] <gary_poster> thank you!
[19:48] <hatch> :D
[19:48] <luca__> gary_poster: haha cheers :)
[19:49] <luca__> night!
[19:49] <gary_poster> night
[19:49] <hatch> night
[19:49] <gary_poster> bac, you confirm that you did not receive it either?
[19:49] <bac> i did not get an attachment
[19:49] <gary_poster> lol ghosttown
[19:49] <gary_poster> ok forwarding to gui team and orange...
[19:50] <hatch> bcsaller: it was the lack of a flags object?
[19:50] <bcsaller> hatch: no, that was an issue in some tests, but I moved the event binding under that flag for the time being 
[19:50] <hatch> ahh ok
[19:51] <bcsaller> and all was right in the world 
[19:53] <abentley> orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-store-ingest-job/+merge/171162
[19:53]  * sinzui looks
[19:54] <sinzui> abentley, maybe after this we can talk about high bugs and clearing the queue during deployments
[19:54] <abentley> sinzui: sure.
[19:56] <hatch> bac: review done
[19:56] <sinzui> abentley, r=me
[19:56] <hatch> bcsaller: reviewing
[19:56] <bcsaller> awesome
[20:01] <abentley> sinzui: Ready when you are.
[20:01] <jcsackett> jujugui/orangesquad: can i get 2 reviews on huw's design work for the sharing widget, please? https://codereview.appspot.com/10495045
[20:03] <gary_poster> jcsackett, I'll give you a code lgtm and you can count as the qa reviewer if you want
[20:03] <gary_poster> or do you want qa as well?
[20:04] <jcsackett> gary_poster: oh, i can do qa.
[20:04] <gary_poster> cool, jcsackett. LGTM.  land it. you count--not your branch.
[20:05] <gary_poster> I mean...
[20:05] <gary_poster> sigh...English
[20:05] <jcsackett> gary_poster: i follow. :-P
[20:05] <gary_poster> :-)
[20:05] <hatch> bcsaller: done
[20:05] <bcsaller> hatch: thanks
[20:29] <bac> hatch: why should i check that we're logged in before logging out before testing that the unauthenticated check is done?  seems a bit redundant to me.  we're not testing the logout method.
[20:31] <hatch> bac: but you are - if the logout function isn't working you won't be able to test your code
[20:31] <hatch> so it's a safety assert to tell you, yes this test can fail
[20:33] <bac> hatch: no, let's test logout somewhere else if it isn't tested.  but i'm not going to check every time i call it to ensure it worked.
[20:34] <hatch> allllllright
[20:35] <bac> i mean, if i call logout and then assert that we're actually logged out, how can i be sure the assert wasn't broken???  :)
[20:40] <hatch> hah
[20:40] <hatch> gary_poster: a charm cannot specify options for a config correct? re luca's comment on the dropdown in settings
[20:41] <gary_poster> yes, a charm can hatch.  lemme make sure I am seeing what you mean...
[20:42] <bac> gary_poster: this new design by luca will require our auto-growing text entry boxes.  i hope he's ok with that.
[20:42] <bac> gary_poster: my bug requesting a new 'text' type in juju config was blown off and marked as 'opinion'
[20:42] <gary_poster> bac, I hope so too.   Might as well mention it.
[20:42] <gary_poster> :-/
[20:42] <bac> not even wishlist !
[20:43] <bac>  s/opinion/sod off/
[20:43] <gary_poster> :-/
[20:43] <gary_poster> hatch, what comment?
[20:43] <gary_poster> bac, what bug?
[20:44] <hatch> Confirm setting - can we do these as drop downs or do they have to be input fields
[20:44] <hatch> can as a charm author I specify a list of options?
[20:44] <gary_poster> oic
[20:44] <hatch> I was sure it had to be a text input
[20:44] <gary_poster> no
[20:44] <gary_poster> yeah text fields you are rght hatch thanks
[20:45] <hatch> alright thanks for clearing that up - I'll add that to my review
[20:45] <gary_poster> hatch, which means checkboxes validating value are kinda funny
[20:45] <hatch> yup that was going in there too :)
[20:45] <gary_poster> empty string? looks ok!  random ascii? looks ok!  utf8? looks ok!
[20:45] <hatch> lol
[20:46] <bac> gary_poster: bug 1171980
[20:46] <_mup_> Bug #1171980: Allow a 'text' configuration type <juju-core:Opinion> <https://launchpad.net/bugs/1171980>
[20:46] <gary_poster> ack thanks bac
[20:47] <bac> yeah, those checkboxes are odd
[20:47] <hatch> I don't see how that's opinion
[20:47] <hatch> that's clearly a valid feature request
[20:48] <bac> hatch: and we've now spent more time discussing it than it would take to implement
[20:48] <bac> well, almost
[20:48] <hatch> lol
[20:48] <bac> i'll be happy to do it if it won't be rejected
[20:49] <hatch> it almost certainly would be lol
[20:59]  * gary_poster has to go cook some fish.  I'll try and do some reviews of bac and bcsaller's branches later, but maybe between you two and Makyo you can get those reviewed.  I'll take myself off as a reviewer of bac's branch. looked good so far. :-)
[21:00] <bac> gary_poster: np
[21:00] <hatch> could someone take a review of bcsaller's branch so I can merge it into mine? :)
[21:00] <hatch> CI is broken
[21:00] <hatch> I think it's a canonistack failure
[21:01] <hatch>  "ProcessExecutionError"
[21:02] <hatch> luca is going to have a lot of text to read in the morning after we do these reviews :)
[21:04]  * bac dogwalk.  will try to do reviews later.
[21:14] <hatch> Makyo: do you have a card for that branch?
[21:14] <Makyo> hatch, no, sorry.
[21:14] <Makyo> hatch, It's in story1 review now
[21:15] <hatch> ok cool
[21:15] <hatch> just adding my name to the review tag
[21:21] <bcsaller> Thanks for the review
[21:27] <bcsaller> hatch: that is merged now, are you ok to continue with it while I continue work on deployer exports?
[21:28] <hatch> yep it's going to be a touch more work than I thought but np I'll git-r-dun
[21:36] <benji> hatch: my branch is ready for review: https://codereview.appspot.com/10500044 (I, however am ready to go, so I'll read the amazing reviews tomorrow)
[21:37] <hatch> benji: ok cool I'll get right on it
[22:15] <hatch> bcsaller: is the topology related to the app via views.environment.instance.topo ?
[22:15] <hatch> I can't remember if thats the proper chain
[22:15] <hatch> it's so deep it's like it's a Java object :P
[22:15] <bcsaller> hatch: that looks right, needing to extract it like that is usually a bad sign, when its the whole app we might promote it up and pass it into the view from app
[22:16] <hatch> yeah that's a good idea
[22:16] <hatch> ok thanks
[22:16] <hatch> because the topology has no reference to the jujuapp instance right?
[22:16] <hatch> ^ bcsaller
[22:17] <bcsaller> I think we've always said its bad policy to pass app down
[22:17] <hatch> yep just confirming
[22:17] <bcsaller> topology isn't however a singleton, something to keep in mind
[22:17] <hatch> thx
[22:18] <hatch> we will have multiple topologies?
[22:18] <bcsaller> picture drawing bundles in a selection 
[22:20] <hatch> alrighty
[22:20] <hatch> right now it's a singleton
[22:20] <hatch> but I can see where it could be easily edited to not be
[22:35] <hatch> benji: review done
[23:02] <huwshimi> Morning
[23:43] <bcsaller> hazmat: ping