[00:00] <gary_poster> Makyo, this is in the charm, right?
[00:00] <Makyo> gary_poster, yeah
[00:00] <Makyo> gary_poster, there's a step for `make test JUJU_ENV=ec2`, which runs unit tests fine, but barfs on integration.
[00:01] <gary_poster> Makyo, it is not outdated.  If you can't get it working quickly, though, I'd be fine with trusting that previous commits have run the tests properly.  That said...
[00:01] <gary_poster> Makyo, see the HACKING doc in the charm
[00:01] <Makyo> OH
[00:01] <Makyo> Was looking in the gui.
[00:01] <Makyo> Uh..
[00:01] <gary_poster> it describes how to get the plugin
[00:01] <Makyo> don't mind me.
[00:01] <gary_poster> :-)
[00:05] <hatch> gary_poster: http://jsbin.com/udiMIXo/1/edit it's a pretty trivial convention to get used to :)
[00:05] <hatch> maybe that's why there is nothing online - people thought it was too easy
[00:05] <hatch> lol
[00:05] <gary_poster> hatch, but I think it is too easy to lose
[00:06] <gary_poster> that's where the .finally might come in
[00:06] <hatch> yep I'd be ok with that
[00:06] <gary_poster> if you forget to do that *after every single application of then* then you are hosed
[00:06] <hatch> ok I'll hack a finally onto the end
[00:06] <rick_h_> gary_poster: no, they're mixed in currently I believe
[00:06] <gary_poster> hatch, also I suggested simply .then(null, console.error)
[00:07] <gary_poster> rick_h_, ?
[00:07] <rick_h_> gary_poster: re: featured/popular having their own categories?
[00:07] <hatch> gary_poster: no can do, that doesn't display the message
[00:07] <rick_h_> or collections I mean
[00:07] <gary_poster> oh, rick_h_, gotcha, thanks.
[00:07] <hatch> but I can add a 'finally' or 'end' or whatever
[00:07] <gary_poster> huw ^^^ I think that means we are good, then
[00:07] <gary_poster> hatch cool
[00:09] <rick_h_> hatch: k, I'll have to figure it out myself. I think you can just push it to https://code.launchpad.net/~benji/charms/bundles/wiki/bundle like url
[00:10] <rick_h_> hatch: so you'd fork benji's and change it, commit, and push to ~hatch vs ~benji and it'll try to ingest it
[00:10] <hatch> oh that's trivial
[00:10] <hatch> cool
[00:10] <rick_h_> hatch: rgr
[00:13] <rick_h_> hatch: not following your promises example
[00:13] <rick_h_> .end is using error which isn't defined ?
[00:13] <hatch> rick_h_: oops I forgot to lock it
[00:13] <hatch> lol
[00:13] <rick_h_> meh, we'll chat later on it. I'm done for the day and can't think straight
[00:14] <hatch> hve a good one
[00:15]  * gary_poster steps away.  maybe back later.  night all!
[00:15] <hatch> night!
[00:16] <hatch> gary_poster: still here?
[00:16] <hatch> sorry :)
[00:16] <hatch> http://jsbin.com/udiMIXo/1/edit
[00:16] <hatch> rick_h_: ^ if you happen to pop back in tinight
[00:24] <hatch> turns out people in the Promise world call it done() so a little cleanup to 'done' http://jsbin.com/udiMIXo/2/
[00:31] <gary_poster> hatch, that's part of the spec, or extension?
[00:31] <hatch> so short form is...
[00:31] <gary_poster> but that is not the same s finally
[00:32] <hatch> ES6 currently doesn't have a 'done' implementation (it's in debate) so the guy who wrote it wanted to keep it as close to a pollyfill for ES6 as possible. BUT other promise lib authors have a 'done' method which throws the error outside of a promise
[00:32] <gary_poster> My "finally" would be "no matter how many dones there are, we do this at the end.
[00:32] <gary_poster> yeah that might work too
[00:32] <gary_poster> glad it is being discussed at least
[00:33] <hatch> can't be finally though
[00:33] <gary_poster> thanks hatch
[00:33] <gary_poster> really running away now ;-)
[00:33] <hatch> that's a reserved word
[00:33] <hatch> :)
[00:33] <gary_poster> :-P
[00:33] <hatch> haha ok cya
[00:38] <Makyo> One charm integration error...
[01:26] <Makyo> I know most folks are gone, but if anyone from jujugui is around, I'm running out of steam on the charm release.  One test failed.  However, given frankban's previous work, the gui release is not immediately propagated to (nor necessarily reliant on) existing services, due to the cached version within the charm itself.
[01:27] <Makyo> The test failure is simple, and I'll try to fix it (race condition on service name already existing on an integration test), but although the GUI release was successful, the charm release is not complete.
[01:51] <huwshimi> hatch: Could the promises swallowing errors make tests not fail properly either? If an assert is failing I get "timeout of 10000ms exceeded" for that test...
[02:44] <gary_poster> Hey Makyo.  So the error is in a charm?
[02:44] <gary_poster> I mean
[02:45] <gary_poster> the race condition is within the charm tests, or within the GUI?
[02:45] <gary_poster> If it is within the charm tests, I would suggest making the charm release and filing a bug for the error
[02:46] <gary_poster> huwshimi, not exactly.  See #2 of http://jujugui.wordpress.com/2013/10/11/javascript-promise-error-handling-tricks/
[02:46] <huwshimi> gary_poster: Thanks, I'll take a look
[02:47] <gary_poster> huwshimi, the fact that you have a hang is a real error, but the problem with promises is quite possibly hiding the real cause
[02:47] <gary_poster> Makyo, then we can work on the test failure
[02:48] <gary_poster> It is very late I know, but if you see this and feel like it, yeah, I say push the branch if what I describe is the circumstance.
[02:48] <gary_poster> If not, let's do it first thing tomorrow morning
[02:49]  * gary_poster steps out for good for the evening
[04:26] <Makyo> gary_poster, for tomorrow, will do. It's just one of the tests trying to deploy a service named juju-gui when one already exists; other code is fine. Either race, or old service not being torn down properly. All other tests pass. Going to push/make card.
[12:39] <rick_h_> bah, qa'ing ingestoin over mifi fml
[12:51] <luca__> gary_poster: Do you know if Huw has started the Cloud style guidelines stuff?
[12:52] <frankban> guihelp: I need one review + QA for https://codereview.appspot.com/15020043 (python/quickstart). Thanks!
[12:59] <gary_poster> luca__, is that a GUI task?  it doesn't sound familiar
[13:00] <gary_poster> frankban, looking
[13:00] <frankban> gary_poster: thanks
[13:03] <luca__> gary_poster: I asked Huw to create this: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1NFRjWW1MQkNkVWs/edit?usp=drive_web
[13:03] <luca__> gary_poster: in code
[13:04] <gary_poster> luca__, he has not started.  he's been focused on bundle work
[13:04] <luca__> gary_poster: ok
[13:36] <gary_poster> hey frankban, my quickstart output is odd (http://pastebin.ubuntu.com/6257180/) and machine 0's /var/log/juju/unit-juju-gui-0.log is concerning (http://pastebin.ubuntu.com/6257172/).  Thoughts?  Do you want machine-0 log too?  Looks like I might have to edit it to get some passwords out
[13:37] <frankban> gary_poster: hum... what version of juju-core are you using?
[13:37] <gary_poster> oh!  weird
[13:38] <gary_poster> 1.14.1-saucy-amd64 .  Sorry, nm, I'll update my system
[13:38] <frankban> gary_poster: my first guess is that you still need --upload-tools
[13:38] <gary_poster> frankban, $ which juju
[13:38] <gary_poster> /usr/bin/juju
[13:39] <frankban> gary_poster: weird... so, you are not using the compiled one...
[13:40] <gary_poster> frankban, no, I flip that in and out as needed.  prefer to use released on for qa
[13:40] <gary_poster> released one
[13:41] <frankban> gary_poster: so it seems 1.14 is not able to find the right tools
[13:41] <frankban> gary_poster: what juju-core version do we support? 
[13:42] <gary_poster> frankban, for quickstart I am fine with support 1.16
[13:42] <gary_poster> supporting
[13:43] <frankban> gary_poster: cool, that's what i thought.
[13:46] <frankban> gary_poster: I am trying now with juju-core from ppa:juju/stable (1.16.0)
[13:46] <gary_poster> cool
[13:47] <gary_poster> frankban, I had some more suggestions in rv.  Updating my system software now...
[13:48] <frankban> gary_poster: ack, agreed, thanks
[13:49] <frankban> gary_poster: and coverage for manage.run in the next branch ;-)
[13:49] <gary_poster> :-)
[13:52] <frankban> gary_poster: where do you want me to put the juju-quickstart packages? ppa:juju-gui-charmers/stable?
[14:07] <hatch> morning all
[14:07] <rick_h_> party
[14:08] <hatch> rick_h_: not sure if you saw this http://jsbin.com/udiMIXo/2/edit
[14:08] <rick_h_> hatch: cool yea
[14:09] <rick_h_> hatch: looks like chrome is giving a traceback which is nice
[14:09] <rick_h_> and if we have a single helper function we re-use it makes it easy to drop a debugger in there before the console.error to step into things I think
[14:09] <gary_poster> frankban, yes
[14:10] <hatch> exactly - I was thinking of putting that in index.html or app.js or something so that it's easy to do just that
[14:10] <rick_h_> hatch: well I'm for doing a promises.js file which adds it in the namespace. 
[14:11] <rick_h_> but yea, and app.js can include it for everyone or something
[14:11] <hatch> trick is that it 'must' be included before any promises are used :)
[14:11]  * rick_h_ is just hateful of putting more stuff in index/app.js
[14:11] <rick_h_> and if we need to tweak/add code ... 
[14:11] <frankban> gary_poster: ok thanks, will also copy over the required jujuclient and websocket-client binaries from the juju stable ppa
[14:12] <gary_poster> frankban, cool--or have ours depend on stable?
[14:12] <gary_poster> either way is fine with me
[14:12] <hatch> rick_h_: yeah I'll figure out a good way to get it in there - I didn't spend much time on it last night
[14:12] <rick_h_> hatch: yea, I'm flying off the top of my head as well 
[14:13] <frankban> gary_poster: aha! nice idea, forgot we have that option
[14:17]  * gary_poster restarts
[14:24] <frankban> gary_poster: in case if you are going to QA now, i pushed the changes you requested
[14:25] <gary_poster> frankban, cool.  already in progress :-)
[14:26] <frankban> gary_poster: ok, and re ppa dependencies, I suppose they are only used during builds. We need those dependencies for apt-get installing the binary
[14:26] <gary_poster> frankban, mm good point.  so maybe a separate PPA would be better?  We hope to put this stable eventually anyway
[14:28] <frankban> gary_poster: a separate ppa seems reasonable
[14:28] <hatch> oh Sweet there is gona be Yoga
[14:28] <gary_poster> why is my clock no longer showing on the desktop :-(
[14:29] <gary_poster> and the option to do so in Ubuntu setting is grayed out :-(
[14:29] <rick_h_> gary_poster: it's Makyo's latest sabotage attempt
[14:29] <hatch> gary_poster: you're in fold-space, sorry there is no time
[14:29] <gary_poster> We don't like clocks anymore
[14:29] <rick_h_> puling no punches
[14:29] <gary_poster> :-)
[14:29]  * hatch has been reading sci-fi lately
[14:32] <gary_poster> frankban, qa good.  relatedly, could you comment on the juju switch branch from Frank?  Maybe my concerns are unfounded.  https://code.launchpad.net/~themue/juju-core/053-env-more-script-friendly/+merge/191640
[14:34] <gary_poster> OK trying to restart to see if I get a clock back :-/
[14:38] <frankban> gary_poster: what's your idea to avoid using --version before calling "juju switch"? 
[14:38] <gary_poster> Makyo's nefarious plan to deprive me of a clock on my desktop and prevent my ability to intone the sacred call to meeting has been defeated, via judicious and clever use of restarting my computer.
[14:38] <rick_h_> gary_poster: when all else fails!
[14:39] <gary_poster> :-)
[14:39]  * Makyo shakes fist toward the heavens, "Curses!  I'll get you NEXT time, Poster!"
[14:39] <gary_poster> lol
[14:39] <Makyo> Actually, got a dog laying on me.  Probably better to pet his head menacingly.
[14:39] <gary_poster> lol
[14:39] <rick_h_> lmao, but you weren't in here earlier wtf
[14:40] <Makyo> Power outage.
[14:40] <Makyo> But snow, so it's a trade-off.
[14:40] <gary_poster> frankban, if 1.16 then expect format 1, otherwise expect to use flag and get format 2 <shrug>
[14:41] <gary_poster> Makyo, thank you for your heroic efforts last night.  Take off early today or something
[14:42] <Makyo> Oh, np, feels good to get it out there! My charm's up and running and stable on EC2 still, so I think it's okay.
[14:42] <Makyo> Hopefully just that test.
[14:42] <frankban> gary_poster: that way we still need to check "juju version", right? so what's wrong with 1.16 expect format 1, otherwise expect format 2 without flags?
[14:43] <gary_poster> frankban, oh, yeah, same diff
[14:43] <gary_poster> frankban, my point was that we would have to look at version number
[14:48] <frankban> gary_poster: yes, I agree. So you are were asking if another way can be found to achieve the same without having to use "juju version", correct?
[14:49] <gary_poster> frankban, precisely.  and also I was asking if you agreed that forcing us to use version is pretty clunky, and breaking the behavior of the saucy released switch statement is a bad idea generally.
[14:50] <Makyo> jujugui call in 10
[14:50] <gary_poster> I was typing it :-)
[14:50] <frankban> gary_poster: ack. I'll add a comment. unrelated: could you please create a PPA for juju-quickstart? I can only create personal ones.
[14:50] <Makyo> Yeah but I was WINNING
[14:50] <Makyo> Sorry.
[14:50] <gary_poster> frankban, oh, sure.
[14:50] <gary_poster> lol
[14:51] <TheMue> gary_poster, frankban: so dropping this CL to keep the well known behavior?
[14:52] <TheMue> gary_poster, frankban: and for future scripts maybe a new command get-env?
[14:52] <frankban> TheMue: maybe the original --raw was a better idea. returning just the string or exiting with an error if no default env is configured
[14:53] <gary_poster> TheMue, right, new command or --raw.  I don't think saying "switch is new" is a good argument for breaking something that was released in saucy
[14:53] <TheMue> frankban: and when used with a new env name or with --list? error message?
[14:54] <frankban> TheMue: oh... but then we cannot distinguish between "no such argument" and "no environment". So...
[14:54] <TheMue> frankban: yes?
[14:54] <gary_poster> TheMue, and fwiw my interest is primarily in encouring what seems like a good stewardship choice for Juju here.  We can ultimately work around whatever you all do.
[14:54] <frankban> TheMue: "juju switch --raw" returning just an env name or nothing (empty string) if no env configured
[14:55] <frankban> script then can do something like try: juju switch --raw; except error: juju switch (and parse)
[14:55] <TheMue> gary_poster: reasonable
[14:55] <frankban> TheMue, gary_poster ^^^
[14:55] <frankban> TheMue: that way we can avoid checking the juju version
[14:55] <TheMue> frankban: and "juju switch --raw foo" or "juju switch --raw --list foo"?
[14:56] <TheMue> frankban: w/o raw the command is allowed that way
[14:56] <gary_poster> frankban, sounds fine to me.  I'm basically OK with any solution that everyone else likes and does not break Juju saucy release compatibility
[14:56] <frankban> TheMue: for the list it can be a newline separated list. for setting I don't see the value of --raw
[14:57] <TheMue> frankban: the problem imho is, that it is a reading, listing and setting command in one, even in one run
[14:57] <TheMue> frankban: so return an error? or do a simplified output?
[14:58] <frankban> TheMue: or just ignore the flag?
[14:58] <TheMue> frankban: can do, but doesn't feel very clean to me
[14:58] <TheMue> frankban: but you're my customers, your wish is my demand *lol*
[14:59] <Makyo> jujugui call in 1
[14:59] <gary_poster> frankban, https://launchpad.net/~juju-gui/+archive/quickstart-beta
[15:00] <frankban> TheMue: re "juju switch --raw something", from the script perspective the only important thing is the exit code imho. so, the ouput could just be the raw new environment, or nothing, are what you think is consistent
[15:00] <gary_poster> TheMue, "it is a reading, listing and setting command in one, even in one run": I agree, though there is plenty of UNIX-y precendent for this sort of thing.  (/me tries to remember an example)
[15:01] <TheMue> gary_poster: maybe, but that doesn't make it better
[15:01] <gary_poster> TheMue, fair enough :-)
[15:01] <TheMue> frankban: ok, I'll take a simplified output then
[15:01] <TheMue> frankban: so --raw stays --raw for all operations
[15:02] <frankban> TheMue: sounds good, the important bit is that "juju switch --raw" without a default env does not exit with an error, but just have no output
[15:03] <frankban> TheMue: so we know that the feature is there, the flag is there, but the environment is missing
[15:03] <frankban> TheMue: how does it sound?
[15:04] <TheMue> frankban: eh, no arg and no default is no error but also no output? hmmm, have to make a big note in the code for it. :)
[15:06] <frankban> TheMue: "juju switch --raw" with no env -> no error, no output, right. it seems sane to me. without --raw it is the same as now: no error, some human friendly output
[15:07] <TheMue> frankban: yeah, it notifies a human being, but no script
[15:07] <TheMue> frankban: btw, you know how I can set my branch back to 2 revisions before?
[15:13] <frankban> TheMue: I guess "bzr merge . -r something" is the right command. I don't remember the "something" part
[15:14] <TheMue> frankban: just found bzr revert -r<NUM>
[15:15] <TheMue> frankban: yeah, worked, nice
[15:15] <frankban> cool
[15:24] <Makyo> jujugui someone give me the link to the hangout, diff. laptop
[15:24] <rick_h_> https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso?authuser=1
[15:24] <hatch> https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso?authuser=1
[15:24]  * hatch too slow
[15:24] <Makyo> I get "The Party is Over" :S
[15:25] <rick_h_> https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso ?
[15:25] <Makyo> Nope… will see if I can recover on the S76
[15:26] <hatch> maybe you need to be logged in with your canonical account
[15:26] <Makyo> I am
[15:26] <hatch> oh hmm odd
[15:26] <hatch> click the link in the calendar?
[15:26] <hatch> that's all I got :)
[15:26] <Makyo> Did that, got party is over, why I asked.  1sec
[15:27] <hatch> Makyo: invited
[15:27] <hatch> see if that helps
[15:28] <gary_poster> Makyo, if you can't join soon we'll go to another room
[15:31] <bac> hi rick_h_, thanks for landing my branch.  everything was good?
[15:31] <rick_h_> bac: yea, one test was removed I didn't understand, but wanted to move it along
[15:31] <rick_h_> bac: qa'd well and landed. Will watch staging
[15:32] <bac> rick_h_: thanks
[15:33] <bac> rick_h_: sorry about the lack of reviewee comments.  :(
[15:33] <rick_h_> bac: all good, it fit together as I went
[15:33] <rick_h_> I like to write 'thinking' comments so most you can ignore
[15:33] <bac> that one test was removed b/c it was testing a side-effect that no longer occurred
[15:33] <rick_h_> ah, gotcha
[15:35] <bac> rick_h_: did you fix the typos before landing or do i need to do that as a trivial branch?
[15:35] <rick_h_> bah! I forgot in the long qa process :/
[15:37] <bac> ok, i may do it in a little while
[15:39] <hatch> http://jsbin.com/udiMIXo/2/edit
[15:48] <rick_h_> gary_poster: heads up that orange did a charmworld release yesterday I think. So some of our things (like the bundle icon and such) should play nice with manage.j.c 
[15:48] <gary_poster> rick_h_, cool, thank you
[15:48] <rick_h_> gary_poster: we'll still need another for backfill/proof but at least the release should be good against charmworld
[15:48] <hatch> should we move our dailys earlier 1h now? I don't think there is anyone on the west coast any longer?
[15:49] <gary_poster> oh, hatch, great point.  Makyo, jujugui, wdyt?
[15:49] <hatch> that's 9am for me, so that' gives me 1h before the meeting to get settled so I'd be ok with it
[15:50] <frankban> gary_poster: sounds good
[15:50] <rick_h_> gary_poster: +1
[15:53] <frankban> guihelp: quickstart package QA -> http://pastebin.ubuntu.com/6258045/  (I am currently qaing this in an lxc, another QA would help, thanks!)
[15:54] <gary_poster> frankban, why do we have to install python-software-properties?  can't our package depend on it?
[15:54] <frankban> gary_poster: python-software-properties is for apt-add-repository
[15:54] <gary_poster> frankban, oh :-) k
[15:54] <hatch> the icecream email is no longer legible haha
[15:55] <gary_poster> frankban, why do we want that instead of add-apt-repository?
[15:56] <frankban> gary_poster: it's the same script: apt-add is a symlink to add-apt (I used the former because I like the spelling more ;-)
[15:58] <gary_poster> frankban, :-) .  
[15:58] <gary_poster> frankban, I am doing qa if was not obvious :-)
[15:59] <frankban> gary_poster: heh, thanks!
[16:02] <gary_poster> frankban, I need saucy build, and I need amd64
[16:02] <gary_poster> or at least saucy build :-)
[16:03] <gary_poster> frankban, I can copy one over.  Do you want me to?
[16:03] <hatch> gary_poster: chainable done() http://jsbin.com/udiMIXo/5/edit
[16:04] <hatch> now back to real work :)
[16:04] <gary_poster> hatch that is chainable but (a) does not return or throw the error as it should and (b) it doesn't reliably happen at end
[16:04] <frankban> gary_poster: yes please, so we also require jujuclient and websocket i saucy. There are still no saucy packages in the juju stable ppa
[16:05] <gary_poster> ! ok
[16:05] <hatch> gary_poster: a) nope not there yet b) no but this allows you to return a done() from your api and still have it throw reliable errors but still be chainable
[16:05] <gary_poster> cool hatch
[16:06] <hatch> I may have found a way to do what you want with the wrapping but I'll work on that this weekend/next week
[16:06] <gary_poster> frankban, python-jujuclient and python-websocket-client are in saucy itself
[16:06] <gary_poster> so they don't need to be in ppa
[16:07] <frankban> gary_poster: oh, cool
[16:07] <gary_poster> (but I copied them before I learned that :-) )
[16:07] <rogpeppe> gary_poster: could you explain what the problem is with changing the output of the switch command, please?
[16:08] <frankban> gary_poster: ok, I'll delete those from ppa and make another bould of quickstart for saucy
[16:08] <rogpeppe> gary_poster: i'm not sure we provide compatibility guarantees for all the output of every command, and i'm thinking this would be easy enough to work around with a simple regex match
[16:08] <rogpeppe> gary_poster: i'd really like to keep things as simple as possible when we can
[16:09] <gary_poster> rogpeppe, pasting from previous bits: """I don't think saying "switch is new" is a good argument for breaking something that was released in saucy""" """fwiw my interest is primarily in encouring what seems like a good stewardship choice for Juju here.  We can ultimately work around whatever you all do.""" """I'm basically OK with any solution that everyone else likes and does not break Juju saucy release compatibil
[16:09] <gary_poster> ity"""
[16:10] <rogpeppe> gary_poster: i'm not sure what compatibility guarantees we provide
[16:10] <gary_poster> rogpeppe, then that's for the juju team to decide.
[16:10] <gary_poster> rogpeppe, I gave my opinion :-)
[16:10] <rogpeppe> gary_poster: :-)
[16:11] <rogpeppe> gary_poster: i guess i have a horror of creeping cruft that all there just because of compatibility issues
[16:11] <rogpeppe> s/that/that's
[16:11] <rogpeppe> gary_poster: i'd much prefer to say "this release has changed the output of the juju switch command"
[16:12] <gary_poster> rogpeppe, completely understandable.  If you all already have a known guide for backwards compatibility decisions, then stick to it.  If you don't have a known guide, then it seems like a worthy practical/philosophical discussion to have and agreement to reach.
[16:12] <gary_poster> It seemed like there was not a guide
[16:12] <rogpeppe> gary_poster: i agree
[16:13] <gary_poster> So I was putting in my $.02
[16:13] <rogpeppe> gary_poster: thanks
[16:13] <gary_poster> welcome, rogpeppe  :-)
[16:14] <rogpeppe> gary_poster: do you have scripts that rely on the current output?
[16:14] <gary_poster> rogpeppe, yes
[16:15] <gary_poster> rogpeppe, we wanted something more machine readable and raised the issue
[16:15] <gary_poster> rogpeppe, because in 1.16 the output seems geared for humans
[16:15] <gary_poster> so I think that's where this particular discussion/branch originated
[16:15] <rogpeppe> gary_poster: so would you find it awkward to cope with the format change?
[16:16] <gary_poster> rogpeppe, nope.  See above, """fwiw my interest is primarily in encouring what seems like a good stewardship choice for Juju here.  We can ultimately work around whatever you all do."""
[16:16] <rogpeppe> gary_poster: ok cool
[16:16] <gary_poster> except s/encouring/encouraging/ :-P
[16:16] <rogpeppe> TheMue: can we then go with my proposal for the time being, and if compatibility of the switch command output is considered a significant issue, we can change it later to be compatible with 1.16 ?
[16:17] <rogpeppe> TheMue: i.e. keep it simple to start with
[16:19] <TheMue> rogpeppe: i've just changed it back *gnah*
[16:19] <rogpeppe> TheMue: sorry!
[16:19] <rogpeppe> TheMue: at least you'll still have the other stuff in the revision history...
[16:20] <TheMue> rogpeppe: I do have
[16:21] <rogpeppe> TheMue: and the current state, i mean, so if we want to revert to using --raw, we can
[16:22] <TheMue> rogpeppe: so i'll take a revision, the changes out of it and create a new clean branch *sigh*
[16:22] <rogpeppe> TheMue: no, just revert the changes and re-propose
[16:23] <rogpeppe> TheMue: i.e. bzr revert -r <previous-revision>' bzr commit
[16:23] <rogpeppe> s/'/;/
[16:24] <TheMue> rogpeppe: I've done it already with the latest revision to get back to --raw
[16:25] <TheMue> rogpeppe: now the branch is somehow unclean
[16:26] <rogpeppe> TheMue: what do you mean by "unclean"?
[16:26] <TheMue> rogpeppe: there are now more files in the change than I've changed
[16:26] <gary_poster> frankban, still waiting on LP copy :-/ hopefully finished soon.
[16:26] <rogpeppe> TheMue: try merging trunk
[16:27] <gary_poster> https://launchpad.net/~juju-gui/+archive/quickstart-beta/+packages
[16:27] <frankban> gary_poster: yeah, that's the build I launched, waiting on the copy
[16:28] <TheMue> rogpeppe: it said "nothing to do"
[16:29] <frankban> gary_poster: it's ready!
[16:29] <gary_poster> frankban, cool thanks :-) retrying
[16:29] <TheMue> rogpeppe: but I'll try the reverting now
[16:31] <gary_poster> frankban, worked, and quickstart is running fine.  This is probably enough of a QA given the fact that I am now essentially doing a QA of the previous branch, but I'll see it to completion just in case :-)
[16:35] <frankban> gary_poster: thanks! I run it too. cool: from "requesting Juju GUI deployment" to "juju-gui/0 is ready" in 58 secs
[16:35] <TheMue> rogpeppe: so, proposed again, but too many also changed files
[16:35] <TheMue> rogpeppe: and merging trunk doesn't help
[16:36] <gary_poster> frankban, :-) awesome, yeah fast for me too.
[16:36] <gary_poster> frankban, we can add a time flag to show each step later ;-)
[16:36] <frankban> gary_poster: if you use --debug it will show times
[16:36] <gary_poster> frankban, lol awesome
[16:37] <gary_poster> frankban, qa good for me
[16:39] <frankban> gary_poster: great thanks. fwiw, the output with --debug: http://pastebin.ubuntu.com/6258353/
[16:42] <gary_poster> awesome :-)
[16:43] <rogpeppe> TheMue: ah, i understand what you've done now
[16:43] <rogpeppe> TheMue: if you're not careful you'll revert quite a few changes in trunk!
[16:46] <TheMue> rogpeppe: yes, i've done a merging of trunk before, and that has been reverted now too
[16:46] <TheMue> rogpeppe: but now I simply created a new branch, a cleaner one ;)
[16:47] <rogpeppe> TheMue: ok, fair enough
[16:47] <rogpeppe> TheMue: you can still use the original CL, i think, BTW
[16:47] <rogpeppe> TheMue: though you'll need to push --overwrite
[16:47] <TheMue> rogpeppe: has been quicker that way
[17:25] <hatch> Makyo|Air: MakyoOnAir would be a better name :)
[17:26] <Makyo|Air> OH man
[17:26] <hatch> lol yeah!
[17:26] <MakyoOnAir> Good call :)
[17:26] <MakyoOnAir> bzr set up and working \o/ Go set up and working \o/ Ubuntu vm mostly working \o/
[17:27] <hatch> nice!
[17:29]  * hatch copies and renames the panzoommodule.....bug fixed
[17:30] <hatch> how about we just run two identical versions of the module?
[17:30] <hatch> lol
[17:30] <rick_h_> PanZoomRemoveMe
[17:31] <hatch> honestly this is driving me nuts - I KNOW it's keeping a reference somewhere, I Just can't find it
[17:31] <hatch> and this 'fix' clearly indicates the same
[17:31] <hatch> :/
[17:31] <hatch> oh look at the time...I'm sick
[17:31] <hatch> *caugh caugh*
[17:32] <rick_h_> hatch: seriously 2-line it and let's sit down next week. There's got to be a way to wrap a net around the thing getting accessed to find out who's doing it
[17:32] <rick_h_> just keep your notes so we can figure out where you are :)
[17:32] <rick_h_> and don't burn them in a rage tonight
[17:32] <hatch> I would kill for interfaces and 'frozen' objects right now
[17:33] <rick_h_> lmao
[17:33] <rick_h_> I believe I've heard this argument somewhere before?
[17:33] <hatch> wonder how long it would take me to integrate this https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze haha
[17:33] <hatch> *caugh* typescript *caugh*
[17:33]  * hatch runs
[17:34] <rick_h_> hatch: yea, that's what i mean. There must be some way to wrap an attribute or a Node with a net to catch access/changes
[17:34] <rick_h_> what was that? I think you triggered one of my /ignore filters in my irc client
[17:34] <MakyoOnAir> HAhaha
[17:34] <rick_h_> hatch: take a break and peek at this for me and antdillon 
[17:34] <rick_h_> https://codereview.appspot.com/14960044/
[17:34] <hatch> lol!
[17:34] <rick_h_> hatch: ^^
[17:35] <hatch> can do
[17:35] <rick_h_> hatch: thanks
[17:35] <rick_h_> antdillon: review and reviewer lined up ^^
[17:35] <hatch> oh I thought we weren't removing those buttons until we had a new place for them :)
[17:35] <rick_h_> don't ask me, I'm just an lbox proxy
[17:36] <hatch> lol
[17:36] <hatch> I'm sure it's fine - I just remember that from a meeting or something
[17:36] <hatch> maybe that has changed
[17:39] <hatch> I'm all for removing code!
[17:39] <hatch> especially topology code *caugh*
[17:40] <MakyoOnAir> Lets just make sure that we can get the tasks that need to be done finished, too :P
[17:40] <hatch> rick_h_: this left the assets in - intended?
[17:40] <rick_h_> hatch: again I didn't even look at it
[17:40] <hatch> ohh ok I'll include that in the review
[17:40] <rick_h_> hatch: address questions to antdillon please :) I'm trying to get my tests in before EOD before I lie to gary_poster 
[17:41] <gary_poster> heh
[17:41] <gary_poster> it's past antdillon's EOD!
[17:41] <hatch> LIES
[17:41] <hatch> we work for Canonical, there is no EOD
[17:41] <gary_poster> :-)
[17:41] <rick_h_> on a friday before a trip...there's an EOD
[17:41] <hatch> or maybe that's just my crappy work/life ballance haha
[17:43]  * MakyoOnAir makes sure to pack plenty of earplugs to drown out the sound of hatch working through the night.
[17:44] <hatch> yeah, I have two talks to write/prepare for in the coming weeks
[17:44] <hatch> probably end up doing that at night
[17:45] <hatch> MakyoOnAir: you can help
[17:45] <hatch> lol
[17:45] <MakyoOnAir> Ffff.
[17:46] <MakyoOnAir> Oh, and FWIW, if we can make it to caltrain, I believe that's still running, but will be busy with BART down.
[17:46] <MakyoOnAir> That'll get us into the city, where MUNI is still running.
[17:47] <MakyoOnAir> Burlingame is a caltrain stop, I just don't know how close the hotel is to the station.
[17:47] <MakyoOnAir> Kind of a stupid solution, but at least it is one.
[17:47] <hatch> so did the BART ppl actually strike?
[17:47] <MakyoOnAir> Yeah,
[17:47] <hatch> last I read it was still undecided
[17:47] <MakyoOnAir> As of midnight last night.
[17:48] <hatch> $60-90k/yr wasn't enough I guess
[17:48] <hatch> (going from the news article I read)
[17:48] <MakyoOnAir> With weak benefits and in the bay area? No.
[17:49] <hatch> Just because an area is expensive to live in doesn't mean you should get paid a lot to be there
[17:50] <MakyoOnAir> That's not how cost of living disparities work.
[17:52] <hatch> well for example - in a northern oil community here it's crazy crazy expensive to live because everyone makes so much money (150k+) but that doesn't mean the people at a gas station/coffee shop make that
[17:52] <MakyoOnAir> A location is not simply defined by the average cost of living and the average wage; otherwise, there would be no restaurants in Silicon Valley because none of the waiters would say yes to $3/hr + tips, which is going rate here in northern Colorado.
[17:53] <MakyoOnAir> That's a manufactured community, and if you want to see how well those worked out in the past, read up on the Pullman Company communities.
[17:53] <hatch> well this one has a few companies but I know what you're getting at
[17:53] <MakyoOnAir> My old roommate lives in one of them. He pays $1,200/mo for a studio apartment.
[17:54] <MakyoOnAir> they're ridiculous.
[17:54] <gary_poster> Bargain for NYC ;-)
[17:54] <MakyoOnAir> Right? :D
[17:54] <gary_poster> and SFO I bet
[17:54] <MakyoOnAir> Anyway, lets save this for not-work.
[17:54] <MakyoOnAir> Just FWIW, it sounds like Caltrain and MUNI are still up and running.
[17:55] <hatch> I wonder what they get paid ;)
[17:56] <hatch> gary_poster: do you know anything about this landscape removal branch?
[17:57] <hatch> I'm trying to decide if some code should be removed or not...
[17:57] <gary_poster> hey hatch did you make the bundle with position annotations yet
[17:57] <gary_poster> hatch, no I had not seen it
[17:58] <rick_h_> benji: you around around?
[17:58] <gary_poster> hatch, I'm a bit concerned about it tbh
[17:58] <hatch> gary_poster: nope I have not
[17:58] <hatch> but that's only because I figured out without a doubt that it wasn't the bundle causing the issues
[17:58] <gary_poster> hatch k np.  would have liked to demo it to Antonio :-)
[17:58] <gary_poster> hatch, oh ok.  want me to do it?
[17:58] <hatch> if you could, sorry I thought it was needed for next week
[17:58] <hatch> not today
[17:59] <gary_poster> hatch re: ant's branch, make card for it and let's discuss with Luca?  Or, make absolutely sure that existing Landscape functionality is not replaced
[17:59] <gary_poster> hatch, np
[17:59] <gary_poster> it wasn't
[17:59] <gary_poster> just had a thought that it would be nice to have now
[18:00] <gary_poster> and we should get that ready for qa anyway
[18:00]  * gary_poster behind today. :-(
[18:01] <hatch> ok well I can do it right after ants branch
[18:03] <rick_h_> bah, /me hangs head in shame. 
[18:03] <rick_h_> spent last hour trying to figure out why I can't Mock this damn thing and it's sitting in the docs with a full page and all :/
[18:08] <hatch> rick_h_: review done
[18:08] <rick_h_> antdillon: ^^
[18:09] <bcsaller> hatch: did that fix for the events work for you?
[18:09] <hatch> gary_poster: ok done the review - have you started on the new bundle or would you like me to?
[18:09] <gary_poster> hatch go for it thx
[18:09] <hatch> bcsaller: negative, there is some other 'shared' state which is causing 'this.events' in the initializer to be populated with the subscriptions already
[18:09] <hatch> but I haven't tracked that down yet
[18:10] <bcsaller> really seems like copying the object would fix that 
[18:10] <hatch> bcsaller: creating a clone of the panzoommodule and renaming it fixes it :P
[18:10] <hatch> bcsaller: nope the issue is that it's stored on a parent objects prototype (as far as I've got)
[18:11] <hatch> gary_poster: ok on it
[18:15] <hatch> luca__: are you actually here? :)
[18:16]  * hatch waits for him to go offline :P
[18:16] <luca__> hatch: no :P
[18:16] <luca__> hatch: just opened my laptop :)
[18:16] <luca__> hatch: hows it going?
[18:16] <hatch> haha sucks when that happens ;)
[18:16] <hatch> good good - just wanted to chat about the landscape and footer removal stuff
[18:16] <hatch> but that can wait until next week
[18:16] <hatch> since you're not here
[18:23] <luca__> hatch: sure :)
[18:23] <hatch> rick_h_: ok I have pushed the new bundle....
[18:23] <hatch> it's auto ingest now?
[18:24] <rick_h_> hatch: hopefully, never done it myself
[18:24] <hatch> lol
[18:24] <hatch> how will I know?
[18:24] <rick_h_> if nto abentley might be able to tell us what I did wrong
[18:24] <rick_h_> hatch: it'll show up in 15ish
[18:25] <hatch> ok cool - well then I'm going to go grab some lunch
[18:26] <hatch> ^ gary_poster maybe the bundle will be there in 15 mins :)
[18:38] <rick_h_> hatch: well it made it to staging http://staging.jujucharms.com/~hatch/bundle/wiki/envExport
[18:38] <rick_h_> hatch: not on mjc yet
[18:47] <hatch> rick_h_: cool, works awesome :)
[18:47] <hatch> shows a definite issue with the bundle view though
[18:47] <rick_h_> hatch: cool did it hit mjc?
[18:47] <hatch> will need some discussion
[18:48] <hatch> not sure, I'm on staging
[18:48] <rick_h_> hmm, still no. :/
[18:48]  * rick_h_ wonders wtf on that 
[18:48] <hatch> that's ok though
[18:48] <hatch> at least for this use case
[18:49] <rick_h_> hatch: well it might be a sign of issues on production charmworld, so I'll disagree a bit :)
[18:49] <rick_h_> it's ok for your purposes, but hmmm'ing on my end
[18:49] <hatch> haha ok, well for this demo :)
[18:50] <gary_poster> hatch, I see it great.  interesting that the zoom doesn't work, even without removing the two lines you mentioned :-/  Thank you for doing that!
[18:51] <hatch> gary_poster: exactly...about the zoom. heh np :)
[18:51] <gary_poster> Makyo, when you have a free moment, we have d3 pan/zoom bundle vis issue for you :-)
[18:51] <gary_poster> Makyo, http://comingsoon.jujucharms.com/sidebar/search/bundle/~hatch/wiki/6/envExport/:flags:/charmworldv3/?text=hatch
[18:52] <gary_poster> heh
[18:52] <gary_poster> if you click on a relation
[18:52] <gary_poster> then you get "Are you sure you want to remove this relation?" heh and ugh :-)
[19:08] <MakyoOnAir> Oops :)
[19:08] <MakyoOnAir> I'll peek in a few.
[19:21] <hatch> gary_poster: maybe add to your list a discussion of a better way to do the bundle visualization
[19:21] <hatch> er better way to display it
[19:24] <MakyoOnAir> Bleh, yeah.
[19:26] <hatch> I have some ideas but nothing that's really groundbreaking haha
[19:27] <MakyoOnAir> Yeah, color me surprised :)
[19:27]  * hatch opens up crayola box
[19:27] <MakyoOnAir> Do want to hear them, though.  Want to talk now or wait for next week?
[19:28] <hatch> next week is fine, unless you are going to work on it now
[19:28] <MakyoOnAir> Nah. I'm almost set up on this machine and I think, like gary_poster said, I may take off a bit early today.
[19:28] <MakyoOnAir> But I should be set up with this computer for the sprint.  Will bring the other one just in case, maybe, but hopefully not have to use it.
[19:29] <hatch> oh awesome
[19:29] <hatch> I definitely want to see how you have it all setup
[19:29] <MakyoOnAir> It'll just be my home machine from now on.  Certainly go enough power.
[19:29] <MakyoOnAir> got
[19:30] <hatch> so what do you have in the Ubuntu vm? anything?
[19:31] <MakyoOnAir> juju-core, go, lbox.  Used to use it for bzr, but I just tested that out and it seems to be working from metal.  I'll keep the vm set up  with it, though, just in case I need it
[19:32] <MakyoOnAir> It's just server, though, so I don't even have X.  I just run make devel there and have networking set up so that I can see it.  All of the files are NFSd in, so I can edit locally and refresh to see changes.
[19:33] <hatch> cool cool
[19:35] <MakyoOnAir> PRobably pretty similar, just different work around to get things moving, since it's vbox instead of parallels.
[19:36] <gary_poster> hatch, ok, added.  Makyo, +1
[19:36] <rick_h_> gary_poster: https://codereview.appspot.com/14789043/ if you get time. Reviewer comments added
[19:36] <hatch> ahh right right
[19:37] <rick_h_> hatch: add a non-approved charm to your bundle if you get a sec please. 
[19:37] <hatch> rick_h_: FINE!
[19:37] <gary_poster> heh
[19:37] <rick_h_> hatch: :P 
[19:37] <hatch> anyone in particular?
[19:37] <gary_poster> hatch, expose a charm too?  See if it is in the export?
[19:38] <hatch> sure
[19:38] <gary_poster> rick_h_, I'll review now if you can get it landed.  if you won't do anything with it till later I'll postpone.  Zero pressure on you, just helping me prioritize.  You have time for a landing?
[19:38] <rick_h_> gary_poster: so I can get it landed today as long as you find nothing major. 
[19:38] <gary_poster> hatch bug 1241782: I guess there's our answer
[19:38] <rick_h_> if it'll be > 1hr of clean up or rework it'll have to wait until flight or CA
[19:38] <_mup_> Bug #1241782: juju-gui export does not include exposed ports <juju-gui:New> <https://launchpad.net/bugs/1241782>
[19:39] <gary_poster> rick_h_, ok cool, on it
[19:39] <rick_h_> hatch: actually nvm
[19:39] <rick_h_> oh wait, that's just no icon...hmmm lookin
[19:39] <hatch> so...subordinate relation lines are no longer drawn?
[19:39]  * hatch hopes this isn't just a bug in my branch
[19:40] <gary_poster> hatch, you have to hover over the wiggly thing member?  been like that forever
[19:40] <gary_poster> not ideal
[19:40] <hatch> right, is nagios not a subordinate?
[19:40] <rick_h_> hatch: daisy
[19:41] <rick_h_> hatch: as my suggestion for non-approved charm
[19:41] <gary_poster> correct it is not, hatch.  nrpe IIRC
[19:41] <rick_h_> hatch: no, nagios is a server, nrpe is the subordinate I believe
[19:41] <hatch> ahh
[19:42] <hatch> rick_h_: so you don't need my bundle updated?
[19:42] <rick_h_> hatch: yes please
[19:42] <rick_h_> hatch: with daisy
[19:42] <rick_h_> I don't know why, but just to include something :/
[19:42] <hatch> odd that a wiki bundle would have daisy but OH FINE
[19:43] <hatch> :P
[19:43] <rick_h_> hatch: please, it's named 'exportedEnv
[19:43] <hatch> rofl
[19:44] <hatch> maybe that's a feature request it should ask me what to name the export :)
[19:44] <hatch> to the bug tracker!
[19:46] <hatch> rick_h_:  pushed
[19:47] <rick_h_> hatch: cool, will wait for update. Want to verify all the icon/non-approved stuff works right
[19:48] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1241804
[19:48] <_mup_> Bug #1241804: When exporting an environment it should ask for the environment name <juju-gui:New> <https://launchpad.net/bugs/1241804>
[19:48] <hatch> :)
[20:11] <gary_poster> rick_h_, LGTM with lots of suggestions (and no required changes!  If you are not compelled, leave it).
[20:12] <rick_h_> gary_poster: thanks, looking now
[20:13] <rick_h_> gary_poster: definitely some good ones, the original parser error should be put into the debug_info section of the ProofError for instance
[20:13] <gary_poster> cool
[20:14] <rick_h_> gary_poster: the one thing is that the next step is to add the relation checks into BundleProof. Since it's outside the service block and more of higher level than a charm check
[20:14] <rick_h_> gary_poster: if that had been there would you feel different about the BundleProof? 
[20:14] <rick_h_> maybe not since the issue is that is still doing work/finding a charm and such
[20:15] <rick_h_> yea, not happy with that still :/
[20:15] <gary_poster> that's what I was about to say.  the two issues were yours (imports) and mine (work)
[20:15] <gary_poster> the relaton aspect changes none of that
[20:15] <gary_poster> relation
[20:15] <rick_h_> gary_poster: right
[20:16] <rick_h_> gary_poster: yea, just needed to simplify the view function, but this still feels odd so will think on it some more. Maybe time to create something more substantial for the proof view than a single function in the BundleApi class
[20:17] <gary_poster> rick_h_, even if it were a view/bundleUtils.py? <shrug>
[20:17] <rick_h_> heh, yea see you commented on _proof_bundle being too big still without all that code
[20:17] <gary_poster> right
[20:17] <rick_h_> gary_poster: yea, it'd just be the first time everything in the Api wasn't in that single class
[20:17] <rick_h_> gary_poster: so tried to avoid it a bit, but I do like being a trend-setter :)
[20:17] <gary_poster> heh :-)
[20:18] <rick_h_> ok, thank you very much for the time to go through that gary_poster 
[20:19] <gary_poster> welcome rick_h_ thanks for the branch :-)
[20:19] <rick_h_> off to get the boy from day care and will poke at it some more in-flight I think
[20:19] <gary_poster> cool
[20:19] <gary_poster> safe travels!
[20:21] <hatch> hmm it doesn't appear to be updating my bundle
[20:24] <hatch> sweet fixed the bundle bug
[20:24] <hatch> I can now relax
[20:25] <hatch> well, and clean up the disaster that is my 'working branch'
[20:25] <hatch> :D
[20:37] <MakyoOnAir> hatch: [,,,].join() [20:37] <MakyoOnAir> wat
[20:38] <gary_poster> heh
[20:39] <gary_poster> jujugui, here's my take on 0.11.0 changelog, adapted from Makyo's and bzr log -l 50, and my own fevered imagination.  Comments welcome.  http://pastebin.ubuntu.com/6259652/
[20:40] <MakyoOnAir> Oh, did that not make it in? :(
[20:41] <gary_poster> Makyo, it did!  As I said this morning on the call, I wanted to tweak it.  There were a few items that were wrong (because the kanban cards were wrong) and some items missing (only in the log) and then I wanted to rearrange from features to fixes to flagged.  I'll update the release doc with my suggested approach for the future
[20:41] <hatch> MakyoOnAir: lol love js sometimes
[20:41] <hatch> sometimes...not so much
[20:42] <hatch> gary_poster: reading
[20:42] <MakyoOnAir> Oh, right, yeah.  I was trying to pick the kanban cards that weren't in the last release.  That sounds good!
[20:42] <gary_poster> lol, removing "- Prevent"
[20:43] <hatch> lol
[20:43] <hatch> that's the best part!

[20:43] <hatch> if the charm browser s/were/was
[20:44] <hatch> unless thats some proper English thing and I just can't read
[20:45] <gary_poster> hatch actually that's correct subjunctive case, pretty sure
[20:45] <hatch> gary_poster: I'd remove the 'Fullscreen charm details tabs were....' item as it's not really relevant to the users as they never had that in their codebase
[20:45] <gary_poster> hatch, yeah ok, wondered about that
[20:47] <hatch> looks good :) although I still can't get the onboard flag to work haha
[20:47] <gary_poster> hatch yeah me either.  that's why I phrased that one the way I did :-/
[20:51] <hatch> proposing the bundle fix
[20:52] <gary_poster> yay!
[20:53] <hatch> 1 line fix
[20:53] <hatch> lol
[20:56] <hatch> I transfered a .ca domain name to name.com today and the email said "Your domain was transfered, that was sure fast, eh?"
[20:56] <hatch> I lol'd
[20:59] <hatch> jujugui looking for a real quick QA and review (1line) https://codereview.appspot.com/15070044/
[21:00] <gary_poster> hatch LGTM but how about a test?  should be easy enough :-) if you push back once I'll give in and give you an LGTM though :-)
[21:00] <gary_poster> hatch and good catch
[21:00] <rick_h_> hatch: you bundle is now under http://staging.jujucharms.com/~hatch/bundle/wiki/TestBundle since you changed the name between revs
[21:00] <hatch> gary_poster: thanks, and yes sorry I'll add a test
[21:00] <hatch> I still think that this is an issue with the system, but at least it's fixed properly :)
[21:01] <gary_poster> cool hatch.  want me to LGTM it so you don't have to wait for me?  I'll trust you on the test :-)
[21:01] <rick_h_> and yay looks good http://comingsoon.jujucharms.com/sidebar/search/bundle/~hatch/wiki/7/TestBundle/:flags:/charmworldv3/?text=hatch#bws-charms
[21:01] <hatch> rick_h_: yeah that wasn't there when I mentioned it...must take more than 15mins sometime
[21:01] <gary_poster> hatch, eh.  it's a module global as I expected. They have a problem everywhere. :-/
[21:01] <gary_poster> They are a problem everywhere I mean
[21:01] <hatch> rick_h_: notice that it doesn't show the unapproved charm icon in the bundle topology display?
[21:01] <hatch> gary_poster: right - but it should be using it as a reference, not as a storage on the parent prototype
[21:02] <gary_poster> hatch, we're saying the same thing IMO :-)
[21:02] <hatch> the issue is that nested objects are passed by preference
[21:02] <hatch> oh...probably right
[21:02] <hatch> :D
[21:03] <rick_h_> hatch: no, didn't notice that. I can't see it on my screen. I was checking the Token and the charms listing tab
[21:04] <hatch> sec just creating a bug with a screenshot
[21:06] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1241839
[21:06] <_mup_> Bug #1241839: Bundle topology does not show unapproved charm icons <juju-gui:New> <https://launchpad.net/bugs/1241839>
[21:06] <hatch> ^ rick_h_
[21:10] <rick_h_> hatch: lol
[21:10] <rick_h_> hatch: well now you know why I wanted you to add one so badly :P
[21:10] <hatch> haha
[21:19] <gary_poster> jujugui, https://codereview.appspot.com/14990046 1 review please?
[21:19] <gary_poster> fast one, especially if you already looked at the change log :-)
[21:20] <hatch> on it
[21:20] <gary_poster> thank you
[21:24] <hatch> lgtmd
[21:25] <gary_poster> :-) thanks hatch
[21:31] <hatch> no prob
[21:36]  * gary_poster so tired, and didn't get what he needed to get done
[21:36] <gary_poster> but EoD
[21:36] <gary_poster> See y'all on Monday!
[21:37] <gary_poster> I'll be around off an on before then
[21:37] <gary_poster> and I'll be in SF at 9:30 AM Sunday :-P
[21:37] <hatch> have a safe trip!
[21:38] <hatch> I'll be in around 330