[00:00] Makyo, this is in the charm, right? [00:00] gary_poster, yeah [00:00] gary_poster, there's a step for `make test JUJU_ENV=ec2`, which runs unit tests fine, but barfs on integration. [00:01] 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] Makyo, see the HACKING doc in the charm [00:01] OH [00:01] Was looking in the gui. [00:01] Uh.. [00:01] it describes how to get the plugin [00:01] don't mind me. [00:01] :-) [00:05] gary_poster: http://jsbin.com/udiMIXo/1/edit it's a pretty trivial convention to get used to :) [00:05] maybe that's why there is nothing online - people thought it was too easy [00:05] lol [00:05] hatch, but I think it is too easy to lose [00:06] that's where the .finally might come in [00:06] yep I'd be ok with that [00:06] if you forget to do that *after every single application of then* then you are hosed [00:06] ok I'll hack a finally onto the end [00:06] gary_poster: no, they're mixed in currently I believe [00:06] hatch, also I suggested simply .then(null, console.error) [00:07] rick_h_, ? [00:07] gary_poster: re: featured/popular having their own categories? [00:07] gary_poster: no can do, that doesn't display the message [00:07] or collections I mean [00:07] oh, rick_h_, gotcha, thanks. [00:07] but I can add a 'finally' or 'end' or whatever [00:07] huw ^^^ I think that means we are good, then [00:07] hatch cool [00:09] 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] 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] oh that's trivial [00:10] cool [00:10] hatch: rgr [00:13] hatch: not following your promises example [00:13] .end is using error which isn't defined ? [00:13] rick_h_: oops I forgot to lock it [00:13] lol [00:13] meh, we'll chat later on it. I'm done for the day and can't think straight [00:14] hve a good one [00:15] * gary_poster steps away. maybe back later. night all! [00:15] night! [00:16] gary_poster: still here? [00:16] sorry :) [00:16] http://jsbin.com/udiMIXo/1/edit [00:16] rick_h_: ^ if you happen to pop back in tinight [00:24] turns out people in the Promise world call it done() so a little cleanup to 'done' http://jsbin.com/udiMIXo/2/ [00:31] hatch, that's part of the spec, or extension? [00:31] so short form is... [00:31] but that is not the same s finally [00:32] 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] My "finally" would be "no matter how many dones there are, we do this at the end. [00:32] yeah that might work too [00:32] glad it is being discussed at least [00:33] can't be finally though [00:33] thanks hatch [00:33] really running away now ;-) [00:33] that's a reserved word [00:33] :) [00:33] :-P [00:33] haha ok cya [00:38] One charm integration error... [01:26] 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] 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] 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] Hey Makyo. So the error is in a charm? [02:44] I mean [02:45] the race condition is within the charm tests, or within the GUI? [02:45] If it is within the charm tests, I would suggest making the charm release and filing a bug for the error [02:46] huwshimi, not exactly. See #2 of http://jujugui.wordpress.com/2013/10/11/javascript-promise-error-handling-tricks/ [02:46] gary_poster: Thanks, I'll take a look [02:47] 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] Makyo, then we can work on the test failure [02:48] 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] If not, let's do it first thing tomorrow morning [02:49] * gary_poster steps out for good for the evening [04:26] 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. === TheRealMue is now known as TheMue [12:39] bah, qa'ing ingestoin over mifi fml [12:51] gary_poster: Do you know if Huw has started the Cloud style guidelines stuff? [12:52] guihelp: I need one review + QA for https://codereview.appspot.com/15020043 (python/quickstart). Thanks! [12:59] luca__, is that a GUI task? it doesn't sound familiar [13:00] frankban, looking [13:00] gary_poster: thanks [13:03] 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] gary_poster: in code [13:04] luca__, he has not started. he's been focused on bundle work [13:04] gary_poster: ok [13:36] 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] gary_poster: hum... what version of juju-core are you using? [13:37] oh! weird [13:38] 1.14.1-saucy-amd64 . Sorry, nm, I'll update my system [13:38] gary_poster: my first guess is that you still need --upload-tools [13:38] frankban, $ which juju [13:38] /usr/bin/juju [13:39] gary_poster: weird... so, you are not using the compiled one... [13:40] frankban, no, I flip that in and out as needed. prefer to use released on for qa [13:40] released one [13:41] gary_poster: so it seems 1.14 is not able to find the right tools [13:41] gary_poster: what juju-core version do we support? [13:42] frankban, for quickstart I am fine with support 1.16 [13:42] supporting [13:43] gary_poster: cool, that's what i thought. [13:46] gary_poster: I am trying now with juju-core from ppa:juju/stable (1.16.0) [13:46] cool [13:47] frankban, I had some more suggestions in rv. Updating my system software now... [13:48] gary_poster: ack, agreed, thanks [13:49] gary_poster: and coverage for manage.run in the next branch ;-) [13:49] :-) [13:52] gary_poster: where do you want me to put the juju-quickstart packages? ppa:juju-gui-charmers/stable? [14:07] morning all [14:07] party [14:08] rick_h_: not sure if you saw this http://jsbin.com/udiMIXo/2/edit [14:08] hatch: cool yea [14:09] hatch: looks like chrome is giving a traceback which is nice [14:09] 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] frankban, yes [14:10] 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] hatch: well I'm for doing a promises.js file which adds it in the namespace. [14:11] but yea, and app.js can include it for everyone or something [14:11] 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] and if we need to tweak/add code ... [14:11] gary_poster: ok thanks, will also copy over the required jujuclient and websocket-client binaries from the juju stable ppa [14:12] frankban, cool--or have ours depend on stable? [14:12] either way is fine with me [14:12] 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] hatch: yea, I'm flying off the top of my head as well [14:13] gary_poster: aha! nice idea, forgot we have that option [14:17] * gary_poster restarts === gary_poster is now known as gary_poster|away === gary_poster|away is now known as gary_poster [14:24] gary_poster: in case if you are going to QA now, i pushed the changes you requested [14:25] frankban, cool. already in progress :-) [14:26] 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] frankban, mm good point. so maybe a separate PPA would be better? We hope to put this stable eventually anyway [14:28] gary_poster: a separate ppa seems reasonable [14:28] oh Sweet there is gona be Yoga [14:28] why is my clock no longer showing on the desktop :-( [14:29] and the option to do so in Ubuntu setting is grayed out :-( [14:29] gary_poster: it's Makyo's latest sabotage attempt [14:29] gary_poster: you're in fold-space, sorry there is no time [14:29] We don't like clocks anymore [14:29] puling no punches [14:29] :-) [14:29] * hatch has been reading sci-fi lately [14:32] 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] OK trying to restart to see if I get a clock back :-/ === gary_poster is now known as gary_poster|away === gary_poster|away is now known as gary_poster [14:38] gary_poster: what's your idea to avoid using --version before calling "juju switch"? [14:38] 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] gary_poster: when all else fails! [14:39] :-) [14:39] * Makyo shakes fist toward the heavens, "Curses! I'll get you NEXT time, Poster!" [14:39] lol [14:39] Actually, got a dog laying on me. Probably better to pet his head menacingly. [14:39] lol [14:39] lmao, but you weren't in here earlier wtf [14:40] Power outage. [14:40] But snow, so it's a trade-off. [14:40] frankban, if 1.16 then expect format 1, otherwise expect to use flag and get format 2 [14:41] Makyo, thank you for your heroic efforts last night. Take off early today or something [14:42] 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] Hopefully just that test. [14:42] 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] frankban, oh, yeah, same diff [14:43] frankban, my point was that we would have to look at version number [14:48] 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] 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] jujugui call in 10 [14:50] I was typing it :-) [14:50] 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] Yeah but I was WINNING [14:50] Sorry. [14:50] frankban, oh, sure. [14:50] lol [14:51] gary_poster, frankban: so dropping this CL to keep the well known behavior? [14:52] gary_poster, frankban: and for future scripts maybe a new command get-env? [14:52] 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] 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] frankban: and when used with a new env name or with --list? error message? [14:54] TheMue: oh... but then we cannot distinguish between "no such argument" and "no environment". So... [14:54] frankban: yes? [14:54] 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] TheMue: "juju switch --raw" returning just an env name or nothing (empty string) if no env configured [14:55] script then can do something like try: juju switch --raw; except error: juju switch (and parse) [14:55] gary_poster: reasonable [14:55] TheMue, gary_poster ^^^ [14:55] TheMue: that way we can avoid checking the juju version [14:55] frankban: and "juju switch --raw foo" or "juju switch --raw --list foo"? [14:56] frankban: w/o raw the command is allowed that way [14:56] 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] TheMue: for the list it can be a newline separated list. for setting I don't see the value of --raw [14:57] frankban: the problem imho is, that it is a reading, listing and setting command in one, even in one run [14:57] frankban: so return an error? or do a simplified output? [14:58] TheMue: or just ignore the flag? [14:58] frankban: can do, but doesn't feel very clean to me [14:58] frankban: but you're my customers, your wish is my demand *lol* [14:59] jujugui call in 1 [14:59] frankban, https://launchpad.net/~juju-gui/+archive/quickstart-beta [15:00] 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] 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] gary_poster: maybe, but that doesn't make it better [15:01] TheMue, fair enough :-) [15:01] frankban: ok, I'll take a simplified output then [15:01] frankban: so --raw stays --raw for all operations [15:02] 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] TheMue: so we know that the feature is there, the flag is there, but the environment is missing [15:03] TheMue: how does it sound? [15:04] 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] 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] frankban: yeah, it notifies a human being, but no script [15:07] frankban: btw, you know how I can set my branch back to 2 revisions before? [15:13] TheMue: I guess "bzr merge . -r something" is the right command. I don't remember the "something" part [15:14] frankban: just found bzr revert -r [15:15] frankban: yeah, worked, nice [15:15] cool [15:24] jujugui someone give me the link to the hangout, diff. laptop [15:24] https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso?authuser=1 [15:24] https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso?authuser=1 [15:24] * hatch too slow [15:24] I get "The Party is Over" :S [15:25] https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.t3m5giuddiv9epub48d9skdaso ? [15:25] Nope… will see if I can recover on the S76 [15:26] maybe you need to be logged in with your canonical account [15:26] I am [15:26] oh hmm odd [15:26] click the link in the calendar? [15:26] that's all I got :) [15:26] Did that, got party is over, why I asked. 1sec [15:27] Makyo: invited [15:27] see if that helps [15:28] Makyo, if you can't join soon we'll go to another room [15:31] hi rick_h_, thanks for landing my branch. everything was good? [15:31] bac: yea, one test was removed I didn't understand, but wanted to move it along [15:31] bac: qa'd well and landed. Will watch staging [15:32] rick_h_: thanks [15:33] rick_h_: sorry about the lack of reviewee comments. :( [15:33] bac: all good, it fit together as I went [15:33] I like to write 'thinking' comments so most you can ignore [15:33] that one test was removed b/c it was testing a side-effect that no longer occurred [15:33] ah, gotcha [15:35] rick_h_: did you fix the typos before landing or do i need to do that as a trivial branch? [15:35] bah! I forgot in the long qa process :/ [15:37] ok, i may do it in a little while [15:39] http://jsbin.com/udiMIXo/2/edit [15:48] 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] rick_h_, cool, thank you [15:48] gary_poster: we'll still need another for backfill/proof but at least the release should be good against charmworld [15:48] should we move our dailys earlier 1h now? I don't think there is anyone on the west coast any longer? [15:49] oh, hatch, great point. Makyo, jujugui, wdyt? [15:49] 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] gary_poster: sounds good [15:50] gary_poster: +1 [15:53] guihelp: quickstart package QA -> http://pastebin.ubuntu.com/6258045/ (I am currently qaing this in an lxc, another QA would help, thanks!) [15:54] frankban, why do we have to install python-software-properties? can't our package depend on it? [15:54] gary_poster: python-software-properties is for apt-add-repository [15:54] frankban, oh :-) k [15:54] the icecream email is no longer legible haha [15:55] frankban, why do we want that instead of add-apt-repository? [15:56] 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] frankban, :-) . [15:58] frankban, I am doing qa if was not obvious :-) [15:59] gary_poster: heh, thanks! [16:02] frankban, I need saucy build, and I need amd64 [16:02] or at least saucy build :-) [16:03] frankban, I can copy one over. Do you want me to? [16:03] gary_poster: chainable done() http://jsbin.com/udiMIXo/5/edit [16:04] now back to real work :) [16:04] 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] 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] ! ok [16:05] 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] cool hatch [16:06] 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] frankban, python-jujuclient and python-websocket-client are in saucy itself [16:06] so they don't need to be in ppa [16:07] gary_poster: oh, cool [16:07] (but I copied them before I learned that :-) ) [16:07] gary_poster: could you explain what the problem is with changing the output of the switch command, please? [16:08] gary_poster: ok, I'll delete those from ppa and make another bould of quickstart for saucy [16:08] 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] gary_poster: i'd really like to keep things as simple as possible when we can [16:09] 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] ity""" [16:10] gary_poster: i'm not sure what compatibility guarantees we provide [16:10] rogpeppe, then that's for the juju team to decide. [16:10] rogpeppe, I gave my opinion :-) [16:10] gary_poster: :-) [16:11] gary_poster: i guess i have a horror of creeping cruft that all there just because of compatibility issues [16:11] s/that/that's [16:11] gary_poster: i'd much prefer to say "this release has changed the output of the juju switch command" [16:12] 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] It seemed like there was not a guide [16:12] gary_poster: i agree [16:13] So I was putting in my $.02 [16:13] gary_poster: thanks [16:13] welcome, rogpeppe :-) [16:14] gary_poster: do you have scripts that rely on the current output? [16:14] rogpeppe, yes [16:15] rogpeppe, we wanted something more machine readable and raised the issue [16:15] rogpeppe, because in 1.16 the output seems geared for humans [16:15] so I think that's where this particular discussion/branch originated [16:15] gary_poster: so would you find it awkward to cope with the format change? [16:16] 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] gary_poster: ok cool [16:16] except s/encouring/encouraging/ :-P [16:16] 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] TheMue: i.e. keep it simple to start with [16:19] rogpeppe: i've just changed it back *gnah* [16:19] TheMue: sorry! [16:19] TheMue: at least you'll still have the other stuff in the revision history... [16:20] rogpeppe: I do have [16:21] TheMue: and the current state, i mean, so if we want to revert to using --raw, we can [16:22] rogpeppe: so i'll take a revision, the changes out of it and create a new clean branch *sigh* [16:22] TheMue: no, just revert the changes and re-propose [16:23] TheMue: i.e. bzr revert -r ' bzr commit [16:23] s/'/;/ [16:24] rogpeppe: I've done it already with the latest revision to get back to --raw [16:25] rogpeppe: now the branch is somehow unclean [16:26] TheMue: what do you mean by "unclean"? [16:26] rogpeppe: there are now more files in the change than I've changed [16:26] frankban, still waiting on LP copy :-/ hopefully finished soon. [16:26] TheMue: try merging trunk [16:27] https://launchpad.net/~juju-gui/+archive/quickstart-beta/+packages [16:27] gary_poster: yeah, that's the build I launched, waiting on the copy [16:28] rogpeppe: it said "nothing to do" [16:29] gary_poster: it's ready! [16:29] frankban, cool thanks :-) retrying [16:29] rogpeppe: but I'll try the reverting now [16:31] 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] gary_poster: thanks! I run it too. cool: from "requesting Juju GUI deployment" to "juju-gui/0 is ready" in 58 secs [16:35] rogpeppe: so, proposed again, but too many also changed files [16:35] rogpeppe: and merging trunk doesn't help [16:36] frankban, :-) awesome, yeah fast for me too. [16:36] frankban, we can add a time flag to show each step later ;-) [16:36] gary_poster: if you use --debug it will show times [16:36] frankban, lol awesome [16:37] frankban, qa good for me [16:39] gary_poster: great thanks. fwiw, the output with --debug: http://pastebin.ubuntu.com/6258353/ [16:42] awesome :-) [16:43] TheMue: ah, i understand what you've done now [16:43] TheMue: if you're not careful you'll revert quite a few changes in trunk! [16:46] rogpeppe: yes, i've done a merging of trunk before, and that has been reverted now too [16:46] rogpeppe: but now I simply created a new branch, a cleaner one ;) [16:47] TheMue: ok, fair enough [16:47] TheMue: you can still use the original CL, i think, BTW [16:47] TheMue: though you'll need to push --overwrite [16:47] rogpeppe: has been quicker that way [17:25] Makyo|Air: MakyoOnAir would be a better name :) [17:26] OH man === Makyo|Air is now known as MakyoOnAir [17:26] lol yeah! [17:26] Good call :) [17:26] bzr set up and working \o/ Go set up and working \o/ Ubuntu vm mostly working \o/ [17:27] nice! [17:29] * hatch copies and renames the panzoommodule.....bug fixed [17:30] how about we just run two identical versions of the module? [17:30] lol [17:30] PanZoomRemoveMe [17:31] honestly this is driving me nuts - I KNOW it's keeping a reference somewhere, I Just can't find it [17:31] and this 'fix' clearly indicates the same [17:31] :/ [17:31] oh look at the time...I'm sick [17:31] *caugh caugh* [17:32] 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] just keep your notes so we can figure out where you are :) [17:32] and don't burn them in a rage tonight [17:32] I would kill for interfaces and 'frozen' objects right now [17:33] lmao [17:33] I believe I've heard this argument somewhere before? [17:33] 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] *caugh* typescript *caugh* [17:33] * hatch runs [17:34] 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] what was that? I think you triggered one of my /ignore filters in my irc client [17:34] HAhaha [17:34] hatch: take a break and peek at this for me and antdillon [17:34] https://codereview.appspot.com/14960044/ [17:34] lol! [17:34] hatch: ^^ [17:35] can do [17:35] hatch: thanks [17:35] antdillon: review and reviewer lined up ^^ [17:35] oh I thought we weren't removing those buttons until we had a new place for them :) [17:35] don't ask me, I'm just an lbox proxy [17:36] lol [17:36] I'm sure it's fine - I just remember that from a meeting or something [17:36] maybe that has changed [17:39] I'm all for removing code! [17:39] especially topology code *caugh* [17:40] Lets just make sure that we can get the tasks that need to be done finished, too :P [17:40] rick_h_: this left the assets in - intended? [17:40] hatch: again I didn't even look at it [17:40] ohh ok I'll include that in the review [17:40] hatch: address questions to antdillon please :) I'm trying to get my tests in before EOD before I lie to gary_poster [17:41] heh [17:41] it's past antdillon's EOD! [17:41] LIES [17:41] we work for Canonical, there is no EOD [17:41] :-) [17:41] on a friday before a trip...there's an EOD [17:41] 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] yeah, I have two talks to write/prepare for in the coming weeks [17:44] probably end up doing that at night [17:45] MakyoOnAir: you can help [17:45] lol [17:45] Ffff. [17:46] 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] That'll get us into the city, where MUNI is still running. [17:47] Burlingame is a caltrain stop, I just don't know how close the hotel is to the station. [17:47]