[00:26] cherylj: thanks [00:26] alexisb: a large monitor would make it easier to show people, but that isn't even a must have [00:27] I'll be spinning up everything on EC2 a day ahead of time as a backup, like on a cooking show :) [01:04] * perrito666 imagines a souschef removing the running command from wwitzel3 and bringing a fully deployed stack while putting the other on the fridge [01:10] perrito666: :D making a meal out of juju :)) === natefinch-afk is now known as natefinch [01:45] evening all [01:45] ericsnow, wwitzel3: either of you around? [02:05] natefinch: omw [03:06] Bug #1470601 changed: UniterSuite.TestLeadership fails on windows

[03:10] master is blessed. [03:13] mgz, thumper, davechen1y : \o/ [03:14] thumper: i'm pretty sure I've found out the reason for the stuck state servers [03:14] thumper: when do mgo.DialWithInfo and don't specify a timeout, and mongodb isn't there, it hangs forever [03:15] thumper: there's 2 places in juju where we don't specify a timeout [03:15] thumper: state.ForEnviron() is one :) [05:07] Bug #1470714 opened: Ubuntu downloads are non-obvious [07:08] hi [07:08] menn0, ping? [07:19] davechen1y, ping? [07:48] tasdomas: ack [07:48] davechen1y, sorry to be bothering you past your EOD [07:49] davechen1y, as I understand it, service-related commands in cmd/juju have been moved to cmd/juju/service, but in master, cmd/juju/get.go still exists - is there a reason for that? [08:03] tasdomas: sorry, i don't thin ki can help [08:03] i've no idea what happened there [08:04] davechen1y, thanks anyway - I emailed Cheryl with my question [08:04] ok [08:06] TheMue, what was the thinking behind putting that panic in multiEnvRunner.updateOps? [08:07] fwereade: eh, need the context, could you point me to file and line? [08:07] TheMue, txns.go, not sure line because I'm looking at a merge conflict [08:09] TheMue, but it looks like it's a problem with updateStruct that's being addressed one level up and dirtying up the updateOps logic [08:09] fwereade: aha [08:10] fwereade: I first time got aware of this multiEnvRunner with the info of automatic setting of env-uuid and prefixing of _id [08:10] TheMue, I'm well aware of the problem and the context, I'm just asking why you changed updateOps and not updateStruct [08:11] fwereade: did I? [08:12] TheMue, because it *seems* wrong -- all the other panics are generated in the updateSpecificThing methods, and the updateOps method has a couple of its own responsibilities [08:12] TheMue, heh, maybe you didn't even -- I just knew you'd been bumping up against this problem and assumed it was you [08:13] fwereade: when I found it regarding the IPAddress unique field and we discussed about it I afterwards dropped it and set both explicit in addIPAddress [08:14] fwereade: hehe, yes, because we found it "interesting" how the txn modifies the passed doc w/o returning it [09:08] dimitern: https://code.launchpad.net/~mfoord/gomaasapi/devices/+merge/263370 [09:21] voidspace, how about op=claim_sticky_ip ? [09:21] dimitern: oh yes, need to implement that [09:21] dimitern: ten minutes work [09:21] dimitern: :-) [09:22] dimitern: thanks [09:22] voidspace, np :) [09:22] dimitern: (I'll do no error checking, just add it to the device object) [09:24] dimitern: I burned an hour yesterday on an obscure bug [09:24] voidspace, that sounds good - you've got a review [09:24] dimitern: I was writing a byte array (the json result) to the response [09:24] dimitern: and that works without error and the gomaasapi Parse function will consume it [09:25] dimitern: I was just getting a null object in Parse [09:25] dimitern: took me ages to work out why... [09:25] voidspace, hmm really? [09:25] voidspace, what was it? [09:25] dimitern: you need to pass a string to response.Write [09:25] dimitern: a byte array "works" but does the wrong thing [09:26] dimitern: it sends a literal "[1 33 42...]" as the response [09:26] dimitern: which of course is invalid json [09:26] dimitern: and Parse consumes it happily and swallows the json syntax error [09:26] voidspace, ah! good catch [09:27] well, I had failing tests thankfully [09:27] voidspace, strictly speaking I think response.Write takes an io.Writer [09:28] dimitern: yeah, logging would be good [09:28] dimitern: ah, it's fmt.Fprint(w, something) [09:28] dimitern: and something can be a []byte or string [09:28] dimitern: and []byte does the wrong thing altogether... [09:29] dimitern: can't see an inline comment [09:30] voidspace, right, yeah []byte(..).String() is not what you might expect [09:30] whereas string([]byte) does the right thing [09:30] voidspace, it's on line 157 about the deviceTemplate [09:30] dimitern: I can't see it [09:30] is it draft? [09:31] dimitern: ah, I see it [09:32] dimitern: a text/template would be more code, right? [09:32] I could switch to that [09:32] voidspace, yeah - I think it will be nicer [09:32] dimitern: ok [09:33] dimitern: I'll add DELETE and claim_sticky_ip first and then do that [09:33] there maybe other review comments by then [09:35] voidspace, cheers [10:18] dimitern: gomaasapi doesn't have logging [10:22] voidspace, too bad - then ignore my comment about it - I don't insist on it [10:42] fwereade, ping? [10:45] wwitzel3: ping for when you're around [10:52] dimitern: so I need to modify the JSONObject in place [10:52] dimitern: currently JSONObject is effectively read only [10:52] dimitern: I only need to modify an array, so I'll be adding SetArray to match GetArray [10:52] dimitern: ok? [10:54] voidspace, if it works, fine, but I'll like to have a final look when done [10:54] dimitern: it will work fine [10:54] dimitern: obviously ;-) [10:54] dimitern: just make JSONObject a bit asymmetrical [10:54] dimitern: read only except for arrays [10:55] dimitern: otherwise I can serialise, do text manipulation and deserialize again [10:55] dimitern: which seems worse... [10:55] dimitern: or I can make a private function for use by the test server only as JSONObject is publiic [10:55] that's maybe better [10:55] so as not to change the public api [10:56] voidspace, that sounds better I think [10:56] dimitern: cool [10:57] dimitern: although extending JSONObject to make it fully bi-directional and breaking it out into it's own library would be cool [11:10] Bug #1470820 opened: Remove github.com/gabriel-samfira/sys/windows once go 1.4 lands [12:20] voidspace, TheMue, please take a look - http://reviews.vapour.ws/r/2088/ - AddSubnets apiserver method [12:20] dimitern: yup [12:21] TheMue, ta [12:23] dimitern: quick wish outside the review, I prefer identifier abbreviated as ID, not Id [12:23] dimitern: so it would be SebnetProviderID [12:24] TheMue, I know, but Id seems to be more common in our code; we should change all of them separately though [12:25] dimitern: we already have a mix, eg katco also uses ID [12:26] TheMue, I'm not saying we only use Id, just that it's more common [12:26] dimitern: time to change it :D viva le upper-case [12:27] TheMue, :) let's not do it now please [12:28] dimitern: hehe, ok, Ok, OK, oK *rofl* [12:28] * TheMue seems to have a melted brain *lol* [12:29] TheMue, :) [12:40] dimitern: why all those implementations of GoStringer? we haven'd used it so much in the passed. [12:41] TheMue, because I found it easier while writing tests and debugging to see that instead of (0xdeadbeef, ..) [12:42] dimitern: oh, come on, 0xdeadbeef is so good read- and understandable [12:42] :D [12:42] dimitern: but yeah, good argument [13:03] dimitern: phew, you cache is a number. but almost through [13:05] TheMue: dimitern: I prefer Id :-p [13:05] TheMue: dimitern: ID is not an acronym it's an abbreviation [13:06] so only the first letter should be capitalised [13:06] if we do reach a consensus I'll stick to it [13:06] but I think it should be Id [13:07] voidspace: AllocatableIpLow? info.Cidr? [13:07] TheMue: IP is an acronym, so is CIDR [13:07] TheMue: hence the distinction [13:07] so those should be uppercase if they aren't [13:08] I couldn't give so much importance to the case of a single letter :P [13:08] dimitern: probably the best attitude, I only have a slight preference for correctness [13:08] dimitern: it's not the case, it's consistency [13:08] so let's settle on correctness then [13:08] dimitern: unlike in python where I often found MyWildType.do_this.strconv() [13:09] that looks right for Python [13:09] consistent with pep8 [13:09] ah, except for the debate about when to use underscores and when to concatenate [13:09] fair enough [13:09] although I still think that looks fine :-) [13:13] to me it simply looks ugly and inconsistent (which says nothing about the language itself). but I simply like it more consistent, it's better readable, eye/brain don't have to do many context switches [13:13] * TheMue still dreams of the wonderful consistent smalltalk sources, sadly this lang is so bad in concurrency *sigh* [13:15] dimitern: you've got a review [13:15] ericsnow: ping [13:16] TheMue, thanks! [13:16] dimitern: np === frankban_ is now known as frankban [14:01] natefinch: standup === katco` is now known as katco [14:27] looks like there's no OCR in this hemisphere today. would anyone be able to take a look at this, please? http://reviews.vapour.ws/r/2089/ === kadams54_ is now known as kadams54-away [14:28] rogpeppe1: ah beautiful change, ill take a look although I am not sure I am able to +2 it [14:29] perrito666: thanks. more eyes the better :) [14:29] Bug #1470876 opened: Deploy --to zone=

=== kadams54-away is now known as kadams54_ [14:44] wwitzel3: ping [14:46] voidspace, TheMue, PTAL - http://reviews.vapour.ws/r/2090/ - another, much smaller review, this time fixing the subnet add CLI command [14:46] dimitern: ok [14:48] TheMue, thanks [14:48] ericsnow: can you help me understand why the hook context facade might want to know about the unit{ tag}? [14:49] katco: the unit is intrinsic to hook contexts [14:49] ericsnow: so the wpm facade is an exception? [14:49] katco: not at all [14:50] ericsnow: where is the wpm facade using the unit tag? [14:50] katco: rather we can provide the unit at the facade level rather than requiring each API method to require passing the unit tag [14:50] ericsnow: ah ok. we have the cardinality wrong atm? [14:51] katco: I think so [14:52] ericsnow: k, ty for the tutelage. making the change [14:52] rogpeppe1: got my review [14:52] katco: thanks! [14:52] perrito666: ta! [14:53] ericsnow: i'm going to propose we use the id. it will be a looser coupling if we're just dealing with strings. agree? [14:54] katco: keeping the tag would probably be better [14:54] ericsnow: so importing juju/names in components is ok? [14:54] katco: if we pass the unit itself it may save us a bit of work too [14:54] katco: I think so [14:54] katco: it's info rather than machinery [14:55] ericsnow: i would really prefer we not do state.Unit as that will couple all components to state [14:55] ericsnow: or rather, encourage it. i suppose they should be using interfaces [14:55] katco: oh, right; we'd have to make that work via interfaces [14:56] perrito666: i find myself unable to reply to your comments - the text box for the reply isn't showing (might be a Chrome issue) [14:56] ericsnow: actually, reversal. we're already passing in *state.State, this is the same. [14:56] ericsnow: i'll pass in the unit [14:56] rogpeppe1: ah that happens sometimes it is exxtremely annoying [14:56] perrito666: know of a workaround? [14:56] rogpeppe1: I just hard refrehs a couple of times [14:56] refresh* [14:56] perrito666: tried that [14:57] tried yelling at the screen? [14:57] works sometimes [14:57] katco: yeah, at that level it would make sense to just go with *state.Unit [14:57] katco: then we adapt it in component/all [14:57] rogpeppe1: I think perhaps some js library is failing to load [14:57] but I keep forgetting to check [14:57] perrito666: it seems that i can do it if i reply inline in the full diff [14:58] ericsnow: yeah exactly. we'll just have to encourage people to decouple at that point. this shouldn't be hard since that's the entire point of that package [14:58] rogpeppe1: ah, good tip [14:58] katco: again, directory structure FTW :) [15:01] rogpeppe1: and you are going to do another PR for the ProxySSHKey? :p [15:01] perrito666: i think it should probably be all the config attributes [15:01] perrito666: and i'm not entirely convinced it's my responsibility to pay of that tech debt :) [15:01] s/of that/off that/ [15:02] I have never been able to pull that argument succesfuly :p [15:06] voidspace: pong [15:09] ericsnow: changes pushed. review if you please, sir. [15:09] katco: will do [15:10] ericsnow: looks like process.go had an issue. not sure [15:10] katco: you may need to merge/rebase onto the feature branch [15:10] ericsnow: ah k lemme do that rq [15:15] cherylj: thanks v much for doing some QA on my branch [15:15] rogpeppe1: np :) I've been in the multi environment stuff recently, so I thought I should take a look [15:16] cherylj: do you know any way of listing all the multi environments so that i can destroy them prior to destroying the local env? [15:18] rogpeppe1: they will show up in juju switch -l. There's a command coming in a feature branch that will show you the environments for a particular system (aka bootstrap env) [15:19] cherylj: that would be useful. juju switch -l shows me all the dud .jenv files i have lying around too :) [15:19] rogpeppe1: yeah, that is a pain. There's a new juju supercommand called system that will let you list envs for a particular system, and do other system-y things [15:20] cherylj: cool [15:24] cherylj: i've replicated your issue. thanks v much again for trying it out. I should have done the same. [15:24] rogpeppe1: np :) [15:28] ericsnow: k sorry, had to grapple with git a bit. review updated [15:28] katco: np [15:33] katco: basically ship-it (one small detail to address) [15:33] katco: thanks for doing that [15:33] ericsnow: ah gotcha. i think i tried passing in state before rebasing and (of course) they methods weren't there :p [15:34] katco: I had meant to update that bit in my state patch, but apparently forgot [15:36] ericsnow: "State does not implement server.State (wrong type for UnitProcesses method)" [15:36] ericsnow: i'll leave that to you [15:36] katco: k [15:38] katco: yeah, just leave that bit the way you have it and I'll put up a patch to fix it [15:38] ericsnow: blah. i really butchered the commit history for this branch. i borked that rebase. [15:40] katco: I really wish Go would be smarter about compatible types in function signatures [15:42] ericsnow: is it a {co|contra}variance problem? [15:50] katco: only as it relates to strictly equivalent types (e.g. interfaces, maybe even some typedefs) [15:50] katco: I'm not even talking about implicit type coercion [15:50] ericsnow: in my experience, that's one of those things that get added to statically typed languages as they mature [15:50] katco: right [15:50] ericsnow: just a priorities thing [15:51] katco: it's on my list of Go things that could happen some day [15:51] ericsnow: :) i still want to see that spreadsheet! [15:51] katco: I'll share that with you at some point :) === liam_ is now known as Guest41856 [16:05] cherylj: i've pushed a fix for that issue - it seems to work ok for me now [16:08] anyone prepared to +2 this? http://reviews.vapour.ws/r/2089/ [16:11] i have no idea why the build bot thinks gofmt is sad: http://juju-ci.vapour.ws:8080/job/github-merge-juju/3877/consoleFull#-2049291403f64d1c3f-da20-4160-a70c-0ccd218b227e [16:12] katco: looking [16:12] mgz: entirely possible i'm missing something, but gofmt -s -w ./process.go produces no changes on my machine [16:13] katco: what go version? [16:13] mgz: 1.3.3 [16:13] bot uses 1.2.1 [16:13] so, go fmt may have changed its mind [16:13] mgz: bleh... i'll have to install v1.2.1 [16:14] mgz: looks like i can only get go 1.2.2 [16:14] I may be able to just spot it, sec [16:15] that HookContextAPI{ /* st */ } is ood [16:18] katco: I'll fetch your branch and give you the gofmt diff [16:18] mgz: ty... working on getting 1.2.2 installed too [16:20] katco: ah, also, `go fmt` passes [16:20] but the line we use in verify.bash does not [16:22] katco: i usually just install Go from source - it's dead easy and makes it straightforward to play with any go version you likre [16:22] like [16:22] rogpeppe1: that's what i have done [16:23] rogpeppe1: └11:21> ls ~/.local/ |grep go [16:23] go [16:23] go1.2.2.linux-amd64 [16:23] go1.3.3.linux-amd64 [16:23] go1.4.0.linux-amd64 [16:23] rogpeppe1: where go is a symlink to 1.3.3 [16:23] katco: ah, i have a slightly different approach [16:24] katco: it's dumb, http://paste.ubuntu.com/11810901 [16:24] katco: [16:24] % cat $h/bin/go-release [16:24] #!/usr/bin/env rc [16:24] GOROOT=$home/go-release [16:24] path=($GOROOT/bin $path) [16:24] $* [16:24] katco: `go fmt` does not do that, but `gofmt component/all/process.go` does [16:25] mgz: lol... oy... i will have to use an editor that does not run go fmt when i save ;) [16:25] is it evil that i'm using vi in a terminal in emacs? [16:26] `go fmt` doesn't seem to care either way [16:26] katco: no, it's not evil, it's great that emacs gives you a usable text editor [16:26] mgz: lol! well played sir! [16:27] mgz: HA! oh god... so i can't push because MY gofmt is sad [16:27] ehehe [16:27] mgz: oyyyy [16:27] just remove the dumb inline comment? [16:28] mgz: good idea. [16:30] rogpeppe1: looks like same thing, just fiddling with env instead of paths? [16:31] katco: i guess - i'm not sure what your things are actually doing [16:31] rogpeppe1: i have all my envars pointing to ~/.local/go, and that's just a symlink to the version i want to use [16:32] rogpeppe1: so to flip versions, i just point the symlink elsewhere [16:32] rogpeppe1: it looks to me like you just flip the envar [16:32] katco: yeah [16:32] katco: i actually like your solution [16:32] rogpeppe1: it's how os x does things as well [16:33] katco: although it would be kinda nice if $GOPATH/pkg was specific to the version too [16:33] rogpeppe1: yes, that is an annoyance when flipping versions [16:33] rogpeppe1: i end up just deleting that [16:33] katco: i often move it out of the way and then back again. [16:34] rogpeppe1: you could get overly complicated and i guess point $GOPATH/pkg to ~/.local/go/user-pkg [16:35] katco: that's an interesting idea, yes [16:35] rogpeppe1: ty for your comments on gorkin btw [16:35] katco: np - i'm sorry i didn't look at it for more than a minute or so :) [16:36] rogpeppe1: no worries at all. i'm presenting that at gophercon in a lightning talk [16:36] katco: i do feel quite strongly about the import . thing though - it's commonly used by people trying to get the "feel" of a ruby DSL, but really doesn't feel nice in Go [16:37] ericsnow: I'd love to see what your workflow is like. You commit like 20x as often as I do :) re: https://github.com/juju/juju/pull/2674 [16:37] katco: (FWIW we used to use import . for gocheck too, but changed to using gc and I think it's a definite improvement in readability) [16:38] katco: am jealous of you going to gophercon [16:38] katco: i couldn't quite bring myself to spend all that cash [16:38] rogpeppe1: i think we have an extra ticket [16:38] katco: really? [16:38] natefinch: I try to keep my changes small [16:38] natefinch: too many times I've been bitten by getting pieces done, breaking them when working on the next piece, and not being able to get back to the point where it was working [16:38] rogpeppe1: yeah, talk to alexisb [16:38] katco: we're sponsoring it? [16:39] rogpeppe1: yes [16:39] katco: woah.... [16:39] rogpeppe1: i'm speaking as well [16:39] katco: great! [16:39] katco: yeah, i saw that AFAIR [16:40] rogpeppe1: re: the import . thing, i like that when what you're trying to accomplish is supposed to feel like an extension to the language [16:40] rogpeppe1: but i know it's not idiomatic [16:40] rogpeppe1: for examples, i claim a pass, and people can do whatever they want when they use it ;) [16:41] katco: i really think it's worth trying to make it feel idiomatic [16:41] katco: and Go doesn't have language extensions :) [16:41] rogpeppe1: the import "." isn't requisite to utilizing the lib, people can do w/e they want [16:41] rogpeppe1: but it keeps my examples clear [16:48] ericsnow: yeah, totally get that [16:49] rogpeppe1: you should go to gophercon. I wish I could go, but already scheduled a vacation for next week before they announced the date. Super super jealous of those that can go, especially since I couldn't go last year either. Hopefully next year, when we don't have any kids under 1yo [16:50] natefinch: the small-commits approach also helps tell the story of how your thinking progressed over the course of the branch :) [16:51] ericsnow: yep [16:56] natefinch: i'm gonna try to go [17:09] wwitzel3: in your api client code, is there any reason not to just return the struct, rather than an interface? [17:09] natefinch: because that struct should never be created without using the constructor [17:10] natefinch: and I've never regretted using an interface, but I have regetted using a struct for a return :) === kadams54_ is now known as kadams54-away [17:12] wwitzel3: fwiw, i have not been convinced why returning a struct is better yet, but that is what idiomatic go suggests. brad fitzpatrick and andrew gerrand did some live coding and that came up as a pet peeve: i.e. "just return the struct" [17:13] wwitzel3: i think it probably has something to do with the fact that go has duck-typing, so conversions should happen in that manner, but i don't know if it takes into consideration the issues you bring up [17:13] katco: even in a case when you never want that struct instansitated without using the constructor? that seems counter to the point of public and private [17:13] wwitzel3: I don't know, if you see a constructor, it's usually pretty obvious that you shouldn't just create the struct yourself. In theory you can always make it return an interface later if needed, but initially, that extra interface just complects the package API.... it also adds a red herring, making me think there might be something different returned sometimes. [17:13] katco: not that long ago I heard davechen1y say "in functions take interfaces and return structs" [17:13] ericsnow: yeah, basically [17:14] wwitzel3: yeah i know. i agree. i haven't thought through that yet. i'd love to get that point clarified [17:14] ericsnow, are you still available for reviewboard advice? [17:15] Be conservative in what you [return], be liberal in what you accept from others [17:15] mattyw: depends on what you need [17:15] ericsnow, this http://reviews.vapour.ws/r/2091/ just doesn't seem to be working in rb at all, you can see in github that it's basically moving loads of files [17:15] ericsnow, any advice on how I can resolve this? [17:15] wwitzel3: maybe it has something to do with: you don't know how your type will be used, and the more specific you are, the more flexible your callers can be [17:16] mattyw: what isn't working in RB? [17:16] katco: isn't that what an interface is? a contract for how your type will be used? [17:16] wwitzel3: e.g. if i return interface Foo, i can only use it as a Foo. but if i return struct Bar, i can pass Bar into all the things that take interfaces that look like Bar [17:16] ericsnow, well loads of files it just shows me an errors (for the files that have gone) and for the new files it just display all the code, what's actually happened is those file were moved [17:16] mattyw: deleted (moved) files show up with an error (and say "deleted" in the file list) [17:17] mattyw: yep, that's how RB works (unfortunately) [17:17] mattyw: in this case I'd just point folks to the PR [17:17] mattyw: it's not like you made any semantic changes [17:18] ericsnow, ok will do thanks [17:18] wwitzel3: it's a valid question i think. idiomatic go says return structs. i just don't know why. [17:18] mattyw: cool [17:18] katco: isn't that what a closure is for? you encapsulate things in a manner so you can easily pass them within your API without having to implement someone elses? [17:18] ericsnow, just thought it was worth checking, in case there was any git-foo I was missing [17:18] git-fu rather [17:18] wwitzel3: if you have to write a closure, you've already lost [17:18] mattyw: no worries [17:18] wwitzel3: i'm not sure i understand the closure comment. interfaces would be dealing with methods [17:19] natefinch: that is a rather inflammatory statement :p [17:19] mattyw: it would be nice if RB handles moves (and deletes) better [17:19] katco: in general, a closure means "someone screwed up their API and now I have to fix it with this gross hack" [17:19] katco: right, but you were saying how if you run the interface vs. a struct, the struct can be passed to anything that accepts an interface that it implements [17:19] natefinch: that is absolutely wrong [17:20] katco: let's discuss after the demo ;) [17:20] mattyw: that patch doesn't have semantic changes, right? [17:20] wwitzel3: right, i don't think you can solve that with a closure as closures are functions, and interfaces deal with methods on a struct [17:20] mattyw: if not, totally LGTM [17:21] katco: no, I am saying your API which accepts interfaces, could accept closures. [17:21] wwitzel3: gave you a shipit on the client... there were a couple comments, but they're not critical [17:21] katco: creating isolation of the foreign API [17:22] wwitzel3: i.e. ok to do after the demo (or tell me I'm full of it and "Drop" them ;) [17:22] natefinch: thank you :), taking a look [17:23] ericsnow, if you want to take a look at the two commits https://github.com/juju/juju/pull/2713 you will see minor things [17:24] mattyw: yeah, that's the only difference I noticed so LGTM [17:25] ericsnow: wwitzel3: natefinch: api server abstraction finally landed [17:26] \o/ [17:26] katco: yeah, just saw :) [17:26] that took forever [17:26] i think i hit every branch of the CI issues tree on the way down [17:26] katco: I'll have a patch up shortly that fixes the UnitProcesses issue [17:26] ericsnow: sweet === kadams54-away is now known as kadams54_ [17:41] katco: http://reviews.vapour.ws/r/2092/ [17:41] ericsnow: tal [17:41] katco: ta === kadams54_ is now known as kadams54-away [17:43] ericsnow: just reading through this, we should put some thought into another name for "State" within components at some point [17:44] katco: agreed [17:45] wwitzel3: natefinch: can someone else review this as well? i'm bumping into a meeting, and i'd like another +1 [17:49] katco: yep, I will as soon as I address my changes from the rebase [17:50]