[00:19] <rick_h> hatch: kinda, fish tank cleaning
[00:19] <rick_h> while we were chatting my son dumped all the fish food into the tank
[00:19] <rick_h> emergency cleaning in progress :/
[00:19] <rick_h> hatch: what solution is this? 
[00:21] <hatch> lol, well it's pretty trivial tbh heh https://gist.github.com/hatched/2dd9628d46be512cc753
[00:21] <hatch> ^ rick_h but it comes with an odd bug, if I click 'browse' after viewing the inspector it shows the sidebar opened with only the categories....not the fullscreen
[00:24] <rick_h> looking
[00:26] <rick_h> yae, not sure what it's doing. Will have to debug the viewState and see what's getting set
[00:26] <rick_h> this seems strange imo
[00:26] <rick_h> we don't need the 67-70 stuff I thought, just left over from debuggin?
[00:27] <hatch> had to add it back in because it wasn't being set properly
[00:27] <rick_h> ah, if things are minimized, the old viewmode is never set to _XXXX 
[00:27] <rick_h> makes sense
[00:27] <rick_h> yea, die hidden stuff die
[00:27] <hatch> I'm glad you understand it because I sure don't heh
[00:28] <hatch> so can i push this up and then email it you to to take over in the am?
[00:28] <rick_h> well, if we're updating the viewState to sidebar, then the next request we try to remove _sidebar.destroy()
[00:28] <rick_h> but we never set this._sidebar because it was hidden
[00:28] <rick_h> hatch: sure thing, I think I understand the issues enough to get it going. 
[00:29] <hatch> ok great - I really want to use every available hour to try and get this release out tomorrow and there are still the two other bugs
[00:29] <hatch> thanks - I'll push and email to you
[00:29] <rick_h> hatch: rgr
[11:09] <rick_h> luca__: morning, so with your email, the goal is to setup an collapsable accordian effect then? With the three headings always visible and the content of them scrollable?
[11:13] <luca__> morning rick_h 
[11:14] <luca__> sort of, Jeff knows what we are after, are you working on it now or can you wait to talk to him?
[11:14] <luca__> rick_h: because he did it wrong to start with and Gary got a bit annoyed over the wasted effort
[11:14] <rick_h> luca__: we can wait. not a problem. I'll be getting back to it soon (late today/tomorrow?) and wanted to clarify what the goals were. 
[11:14] <rick_h> luca__: ah, this is the sticky header business?
[11:15] <luca__> rick_h: yes :)
[11:15] <rick_h> luca__: nvm, I got it then. I took a stab at it at one point so I gotcha. 
[12:07] <frankban> hey hazmat: when you have time, could you please take a look at https://code.launchpad.net/~frankban/juju-deployer/guiserver-changes/+merge/182369 ? 
[12:13] <rick_h> jujugui small review please for when people get in and need something to read with their coffee https://codereview.appspot.com/13276043/
[12:15] <gary_poster> rick_h, did you resolve with Jeff or Ben why it used to be a databinding?  The ony value I can see to the databinding is if the charm is updated and the icon changes, I guess?
[12:17] <rick_h> gary_poster: the issue before was that there wasn't the store doing icon stuff and I think it started out hoping we could generate the paths/logic in there
[12:17] <rick_h> gary_poster: but no, I didn't check on why databinding. I remeber talking with bcsaller when he added it and it was a 'show something' because the store integration wasn't ready yet
[12:18] <gary_poster> ok cool.  if it is not clear how to do it with databinding then the win seems relatively small and I'm fine with the nice-n-simple approach you have here
[12:19] <rick_h> gary_poster: yea, I was going to do data binding thinking it was a case of "if the user opens another charm we can reuse the rendered html and update the data displayed with data binding"
[12:19] <rick_h> however, the *only* attribute data bound was the icon
[12:19] <rick_h> so I think it was a case of 'let's just hack this in' gone wild :)
[12:19] <gary_poster> lol
[12:20] <gary_poster> oh so that code is *only* for the ghost?  the post-deploy is different code?
[12:21] <rick_h> gary_poster: no, I think that it's shared. However, the post-deploy can generate the icon the same way
[12:22] <rick_h> or I just broke the normal way...so take that review request back :/
[12:26] <gary_poster> rick_h, I dunno, I could go either way.  I assumed it was shared when I said "if it is not clear how to do it with databinding then the win seems relatively small and I'm fine with the nice-n-simple approach you have here."  OTOH if you are fairly convinced of the win for the post-deploy scenario, I'll leave you to it
[12:26] <rick_h> gary_poster: yea, so I'm not sure how it fits atm. Basically I've found that from the store the charm model has a charmId field to generate the icon. 
[12:26] <rick_h> from the already deployed charm that attribute isn't in the model there. 
[12:27] <rick_h> however, charmUrl is in both, and that works to generate the right icon url
[12:27] <rick_h> gary_poster: so working on adding a test to both cases so that if this breaks it shows up
[12:27] <rick_h> gary_poster: e.g. I broke the icon in the non-ghost case and so adding a test to say it's fixed. 
[12:28] <gary_poster> rick_h, ok cool.  I'll leave the branch alone for now then.
[12:55] <rick_h> gary_poster: got it figured out. Missed the service vs charm model case handling in there. Updated with an extra test to catch. 
[12:55] <gary_poster> cool rick_h, looking again
[13:06] <luca__> Morning gary_poster, welcome back
[13:06] <abentley> sinzui: Could we do a catch-up chat this morning?
[13:08] <abentley> bac: in r362, it looks like you've changed use_context so that __exit__ is run even if __enter__ fails.  Is that intentional?
[13:12] <gary_poster> hey luca__, thank you :-)
[13:14] <bac> abentley: it was my intent to register the cleanup early but didn't take into consideration what happens if __enter__ failed.
[13:14] <abentley> bac: Why did you want to do that?
[13:15] <bac> abentley: i was working on the problem that adeuring now has with spurious test failures and it looked like the test index was not properly being cleaned up
[13:16] <sinzui> abentley, sure. I can telling about how charmworld tip is incompatible with 2 migrations and It is time to upgrade pyelasticsearch
[13:17] <abentley> bac: Ah.  I think we should change it back, though.  It was registering the cleanup as soon as it was safe to do so.
[13:17] <bac> abentley: i can do that in my current branch
[13:17] <abentley> sinzui: Now?
[13:18] <sinzui> abentley, sure
[13:58] <gary_poster> hey luca__ I just got to your "Juju business assumptions" email.  I'm guessing I should not bother to reply since the deadline is long past now? :-)
[13:58] <luca__> gary_poster: Heya, no need now, but thanks anyway :D
[13:58] <gary_poster> luca__, cool :-)
[13:59] <sinzui> bac, benji, rick_h, The charmworld deployment failed because r363+ is incompatible with two migrations in earlier revisions
[13:59] <rick_h> hatch: when you're around have a fix for the issue from yesterday. http://paste.mitechie.com/show/1007/ is the diff and lp:~rharding/juju-gui/browser-fix-1217060 is the branch. Adding some tests and will have it up for review later. 
[13:59] <benji> darn
[13:59] <rick_h> hatch: then I'll be taking a strong bath for the evils committed
[13:59] <rick_h> sinzui: :(
[13:59] <sinzui> I will ask for 3 deployments today to deploy each migration at the point it has code.
[14:00] <sinzui> that was compatible
[14:00] <rick_h> migrations are fun! :)
[14:00] <sinzui> well maybe to because I think one migration was a correction for m16
[14:00] <benji> we should think about how to avoid this problem in the future
[14:00] <rick_h> sinzui: time to rollup and redeploy on -core? :)
[14:01] <sinzui> Not today
[14:01] <gary_poster> right, benji.  one approach is that we should treat a migration file as a migration in production, and devs have to deal with figuring out how to test re-migrations
[14:02] <gary_poster> that seems simplest to me, and every other idea I have is a more complex approach for questionable benefit
[14:02] <benji> gary_poster: I'm trying to remember how we ended up dealing with migrations (or "generations" back then) in the Z4M project.  We ended up in a place that worked really well, but I'll have to remember the details.
[14:03] <gary_poster> benji, IIRC it was the open source zope generations.  the trick was that ZODB would remember the generation it had, and then run through *all* generations
[14:03] <gary_poster> from last run to current
[14:04] <gary_poster> but that is still potentially riskier in a DB/env not as flexible as ZODB
[14:04] <gary_poster> reasonable but not sufficient, I'd suggest, IOW
[14:04] <benji> that might be how the mechanism worked, but we came up with a set of procedures that actually avoided most of the mechanism but still worked well; it'll take a while for me to remember
[14:04] <gary_poster> ok
[14:06] <hatch> rick_h: ahh you went with the controls binding approach
[14:06] <rick_h> hatch: yea, I think that contains the 'evil' the most
[14:06] <rick_h> hatch: I didn't follow where you were headed with the removing of the whole check entirely and such tbh
[14:07] <hatch> ohh, all I was doing was minimizing the sidebar when the user opened the full inspector
[14:07] <rick_h> hatch: yea, but then you still have the button to un-minimize visible and such
[14:07] <hatch> so the check was no longer needed becasue the browser was still on top of the inspector
[14:07] <rick_h> hatch: so there's UX conflict
[14:07] <gary_poster> benji could you add Friday card about topic pls?
[14:08] <hatch> shhhh
[14:08] <hatch> they wouldn't know
[14:08] <rick_h> jujugui for the later morning coffee crowd, some light reading https://codereview.appspot.com/13276043/
[14:08] <gary_poster> rick_h, ugh, I got lost
[14:08] <rick_h> gary_poster: I'm sory you get lost? 
[14:09] <gary_poster> give review to someone else rick_h 
[14:09] <rick_h> ah, you mean review stuff. All good. 
[14:09] <rick_h> gary_poster: yea, I'll but the western peeps :)
[14:09] <gary_poster> cool
[14:09] <rick_h> or jcsackettcif he's aroud today
[14:09] <rick_h> grrr mobile internet lag
[14:09] <hatch> rick_h: i'll take one of the reviews
[14:09] <rick_h> hatch: ty much
[14:10] <rick_h> hatch: note this is a diff card than the one we've been going over. 
[14:10] <rick_h> just fyi to avoid crossing the streams
[14:12] <benji> gary_poster: card added
[14:12] <gary_poster> thx
[14:36] <hatch> morning antdillon
[14:36] <antdillon> Morning hatch
[14:50] <bac> mark uds keynote talking about cloud-ish now.  http://summit.ubuntu.com/uds-1308/meeting/21887/intro-and-keynote/
[14:51] <hatch> thx
[14:55] <hatch> hey it's the GUI!
[14:56] <sinzui> bac, benji, your revisions are now in production. I think we want a branch to remove the migrations since we know they are not all compatible with tip
[14:57] <benji> yeah, I think so
[14:57] <benji> sinzui: I'll make a card
[15:01] <Makyo> "our less-fortunate brethren" Hah.
[15:01] <hatch> haha yeah I laughed
[15:02] <hatch> antdillon: do you have any idea what cellular frequencies are available there?
[15:02] <hatch> my google fu is returning conflicting details
[15:06] <antdillon> hatch, GSM 900 or 1800 
[15:06] <antdillon> hatch, http://www.ofcom.org.uk/static/archive/ra/topics/pmc/document/licencetypes/cellularinfo.htm#4
[15:07] <hatch> ahh nice the HTC One's in Canada have 850/900/1800/1900 GSM
[15:08] <rick_h> antdillon: is this rumor of sims in vending machines at the airport true?
[15:08] <rick_h> antdillon: it seems like a candy land of mobile connectivity
[15:09] <antdillon> rick_h, Almost, there is all way a booth selling sim cards
[15:09] <hatch> awww right on
[15:09] <hatch> guess I'll be going to get the new phone at lunch and unlocking at night haha
[15:09] <antdillon> rick_h, Or giving them away as long as you put some credit it on it
[15:10] <rick_h> antdillon: cool, yea I'll have a gsm mifi that'll need some sim love 
[15:10] <rick_h> since I don't have a GSM phone :( 
[15:10] <rick_h> stupid verizon
[15:10]  * hatch steals the wifi from rick_h
[15:10] <rick_h> hatch: sure thing. It's what I did before. Wifi'd my phone to the mifi and used it to get directions to dinner!
[15:10] <antdillon> I can see some wifi wars coming up
[15:11] <rick_h> hah
[15:11] <hatch> haha nice!
[15:11] <hatch> I'm going to get the HTC One because there are awesome Android 4.3 roms for it, ANNND Ubuntu Touch port :D
[15:11] <rick_h> cool, I'm still holding out for nexus 5. I'm not due up for a couple more months. 
[15:11] <rick_h> but then I'll be switching to t-mobile and I'll have gsm 
[15:11] <rick_h> so less of an issue with this traveling
[15:11] <bac> hatch: i recall last time i was there one of the good deals on pre-paid sims was at tesco, the grocery chain
[15:12] <hatch> rick_h: yeah I'm sick of waiting, which means a new better phone will come out next week
[15:12] <hatch> lol
[15:12] <rick_h> bac: when I tested out the mifi here on ATT to make sure it worked it cost me $30 for 300mb good for 7 days. I've got low expectations. 
[15:12] <bac> benji: would you have time to look at https://code.launchpad.net/~bac/charmworld/link-to-basket-on-lp/+merge/182415
[15:12] <benji> bac: sure
[15:13] <rick_h> bac: in copenhagen I got 1gb of data for 12months for $13
[15:13] <hatch> hahaha
[15:13] <bac> rick_h: yeah, we are ripped off and don't realize it
[15:13] <rick_h> bac: oh we realize it, but lack of options
[15:14] <bac> rick_h: in VN i could go 3 weeks with heavy data use (i get lost a lot) on a $2.50 top-off
[15:18] <benji> bac: your branch looks good
[15:19] <bac> thanks benji
[15:21] <rick_h> jujugui and hatch in particular, review #2 please for giant hacky bug. Please look away while reading. https://codereview.appspot.com/13282043/
[15:22] <rick_h> and time to head back from the coffee shop, back in a minute
[15:24] <hatch> thanks rick_h
[15:47] <rick_h> Makyo: thanks for the review. Do you have time to look at smaller/more sane other one? https://codereview.appspot.com/13276043/
[15:48] <Makyo>  rick_h sure
[15:49] <rick_h> thanks Makyo, appreciate it
[15:49] <hatch> jujugui guichat in 10
[15:53] <rick_h> jujugui and the charmworld folks, might be interseted in https://pypi.python.org/pypi/nose-selecttests/0.4
[15:54] <gary_poster> looks nice.  funny that functionality is not part of nose generally, but yay for plugins I guess
[15:56] <hatch> rick_h: after your branches land can you let me know so I can re-qa the remaining two bugs in Urgent to see if those fixes fix those bugs
[15:56] <hazmat> gary_poster, nostalgic for zope.testrunner ? ;-)
[15:56] <rick_h> hatch: rgr
[15:56] <gary_poster> hazmat, exactly :-)
[15:58] <hatch> jujugui guichat in 2min
[16:01] <gary_poster> frankban, you around for call?
[16:01] <jcsackett> jujugui: i appear to be the only one on the call...did the appointment hangout get borked, as i can't imagine that's right.
[16:02] <gary_poster> jcsackett, try guichat
[16:02] <jcsackett> gary_poster: oh, duh. of course.
[16:02] <jcsackett> thanks.
[16:02] <gary_poster> np
[16:02] <jcsackett> <--- needs more coffee
[16:02] <bac> jcsackett: i think the link in the calendar is broken
[16:03] <jcsackett> bac: yeah, it is. i don't know why i was trying to use it instead of guichat.
[16:11] <frankban> rick_h: https://codereview.appspot.com/12741051
[16:11] <frankban> thank you
[16:12] <rick_h> frankban: thanks
[16:24] <abentley> adeuring: We may want to change our pattern so that instead of creating an index and then putting the mapping, we supply the mapping at index creation time: http://www.elasticsearch.org/guide/reference/api/admin-indices-create-index/
[16:25] <adeuring> abentley: ah, very intersting. Let me try that. It would most likely fix a problem with temp_index_client()
[16:26] <abentley> adeuring: Doing a refresh may also give us a way to wait until the index is present: http://www.elasticsearch.org/guide/reference/api/admin-indices-refresh/
[16:26] <adeuring> right
[16:28] <hatch> rick_h: the branch fixed the two outstanding urgent bugs
[16:28]  * hatch goes back to QA'ing
[16:28] <rick_h> hatch: woot!
[16:28] <rick_h> hatch: had hoped so. 
[16:28] <hatch> must have been the state update and some odd race condition
[16:29] <rick_h> hatch: I think it was the same thing. The viewmode controls weren't bound right in the non-browser state
[16:38] <gary_poster> Inbox zero!  kinda sorta.  I have a few emails tagged I have to deal with.  But anyway, I'm taking a lunch break in celebration.
[16:39] <rick_h> woot! only two days, email master!
[16:40] <hatch> rick_h: found another bug
[16:40] <rick_h> hatch: stop doing that
[16:41] <hatch> rick_h: haha sorry :) https://bugs.launchpad.net/juju-gui/+bug/1217449
[16:41] <_mup_> Bug #1217449: Sidebar won't minimize after viewing unit list <juju-gui:Triaged> <https://launchpad.net/bugs/1217449>
[16:41] <hatch> can you look at it now?
[16:41] <rick_h> hatch: reviewing right now, can afterwards
[16:42] <hatch> ok assigning to you
[16:42] <rick_h> rgr
[16:42] <frankban> guihelp: anyone available for reviewing a js branch? https://codereview.appspot.com/13286043 This should land asap, before further env/ws tests are added.
[16:43] <hatch> frankban: I'll take one if no one else does (just want to finish this QA pass)
[16:43] <frankban> hatch: thank you
[16:45] <hatch> rick_h: probably related https://bugs.launchpad.net/juju-gui/+bug/1217450
[16:45] <_mup_> Bug #1217450: Browse button shows empty sidebar after clicking Juju logo <juju-gui:Triaged> <https://launchpad.net/bugs/1217450>
[16:47] <rick_h> frankban: looking
[16:47] <frankban> rick_h: thanks
[16:48] <hatch> frankban: do we have tests for the Go portion of these tests which you set the default to be 'python' ?
[16:52] <frankban> hatch: yes, I believe so, everything is more directly tested in the test_env_* files.
[16:52] <hatch> great
[16:57] <frankban> hatch: re (actual, expected), is it a JS guideline?
[16:57] <hatch> frankban: it's the syntax for the nodejs assertion library
[16:57] <hatch> http://nodejs.org/api/assert.html
[16:57] <hatch> for the full api
[16:57] <hatch> it doesn't cause any issues, just creates confusing error messages when the tests fail :)
[16:59] <frankban> hatch: interesting, I am used to expected first, and I am pretty sure I always did that in all my js branches :-) the error messages are usually confused by default, especially when you use deepEqual :-)
[16:59] <hatch> oh I know...I also think that expected should be first
[17:00] <hatch> that's why I left the decision to switch it to you :D
[17:01] <frankban> thanks hatch, perhaps we can clean up this stuff later with a mechanical branch
[17:01] <hatch> sure thing
[17:08] <hatch> rick_h: I'm taking off for an early lunch I believe the two tickets in urgent are related
[17:08] <hatch> but I*
[17:08] <rick_h>  hatch yea, looking at them now
[17:08] <hatch> great thanks a lot!
[17:08] <hatch> bbl
[17:18] <benji> abentley: do you have a few minutes to review my "respect charm versions in APIv3" branch? https://code.launchpad.net/~benji/charmworld/versioned-charm-api/+merge/182450
[17:40] <abentley> benji: looking...
[17:58] <hatch> rick_h: back
[17:58] <hatch> need any help with that stuff now?
[17:59] <rick_h> hatch: no, think I've got it. Just sanity checking and debating on testing/etc
[17:59] <rick_h> hatch: fixes both of them
[17:59] <hatch> awesome thanks
[17:59]  * hatch picked up the HTC One
[17:59] <hatch> chose a new store this time and was in and out in 10mins
[18:00] <rick_h> hatch: very cool, jealous. You'll have to let me check in out next week ;)
[18:00] <hatch> yep, now I'm stuck in a 3 year
[18:00] <hatch> haha
[18:00] <rick_h> 3yr?! ouch!
[18:00] <rick_h> I get ancy before 2yrs
[18:02] <hatch> it's not like i'm going to go with another provider so it's just picking the option that made the phone the cheapest
[18:02] <hatch> it was $100
[18:03] <hatch> I'm pumped that I am able to disable apps now
[18:04] <hatch> bye bye Facebook
[18:04] <hatch> although after I get back it'll likely be getting a rom anyways
[18:07] <rick_h> hatch: I've got one issue I'm not able to see wtf atm
[18:07] <rick_h> hatch: got a second?
[18:07] <hatch> yup
[18:08] <hatch> in guichat
[18:38] <hatch> rick_h: about to test
[18:38] <hatch> sorry make hung
[18:38] <rick_h> hatch: ok, I've got a couple test failures from it working out
[18:39] <hatch> rick_h: I got it to fail but then if I let it sit, the gui portion goes away
[18:39] <hatch> lol
[18:39] <hatch> it's like a few second delay
[18:39] <rick_h> *UGH*
[18:39] <rick_h> hatch: make sure to clear cache and such
[18:39] <rick_h> I don't know...just trying to find some excuse it could be something else
[18:41] <hatch> now I can't repro :/
[18:43] <hatch> repro'd
[18:43] <hatch> now how...
[18:44] <hatch> it's like there is a race condition
[18:44] <hatch> sometimes I can see a 'flash' of the inspector as the sidebar comes up
[18:45] <rick_h> hatch: k, well hack inbound. Give me a few min
[18:46] <hatch> alright thanks
[18:59] <abentley> benji: sorry for the delay.  Was ambushed by a UDS session.
[19:00] <benji> CRIKEY! Isn't she a beauty?!
[19:00]  * benji watches abently wrestle with the wild UDS session.
[19:08] <rick_h> hatch: guichat?
[19:08] <hatch> there
[19:31] <hatch> rick_h:  :(
[19:31] <hatch> dbl click > Build > Juju (...and repeat) still happens
[19:34] <hatch> rick_h: does that not have an issue for you still?
[19:34] <rick_h> hatch: looking
[19:35] <hatch> the dbl click is on the service of course
[19:36] <rick_h> hatch: ok, something is setting renderEnvironment to false. Looking
[19:38] <rick_h> hatch: ok, so when I navigate with clearAllNameSpaces, it's hitting back into the toggleStaticViews with a url :gui;/service...
[19:39] <rick_h> then I get the message 'waiting on service data' and that causes anothewr dispatch to go through that clears it
[19:39] <rick_h> hatch: so my navigate() command isn't 'die gui die' enough
[19:40] <hatch> lol
[19:40] <rick_h> hatch: so how would I generate a _navigate that manually set :gui:/
[19:40] <rick_h> vs :gui:/service...
[19:40] <rick_h> ?
[19:42] <hatch> there is a url method on the nsrouter
[19:42] <hatch> which you pass a config object to
[19:42] <hatch> and it generates a url for you
[19:42] <hatch> see line 1307 in app.js as an example
[19:43] <rick_h> looking
[19:48] <abentley> benji: "Featured bundle UI" looks redundant with "User innterface to (un)set a bundle as featured".
[19:49] <benji> abentley: it does, are those card titles?
[19:49] <abentley> benji: Yes.
[19:49] <abentley> benji: You're assigned to one, but not the other.
[19:49] <benji> abentley: will you kill one of them for me?
[19:49] <rick_h> hatch: I don't get this...I navigate to a fresh url but the url in req.url in toggleStaticViews is still :gui:/service...
[19:50] <abentley> benji: Done.
[19:50] <benji> thanks
[19:50] <abentley> sinzui: Do you know what "charmworld should serve README in same pattern as charm" means?
[19:51] <hatch> rick_h: so the url in the address bar is empty?
[19:51] <hatch> minus the hostname
[19:51] <rick_h> hatch: no, it's got :gui:/service/mongodb
[19:51] <sinzui> abentley, not immediately
[19:51] <hatch> oh ok, so then that makes sense?
[19:52] <sinzui> abentley, and not after a few moments of thought
[19:52] <rick_h> hatch: no, so I run this.navigate(new_url);
[19:52] <rick_h> hatch: and in the views the url is the old url
[19:52] <abentley> bac: What does your card "charmworld should serve README in same pattern as charm" mean?
[19:52] <rick_h> hatch: guichat again? sorry
[19:52] <hatch> sure
[19:53] <sinzui> abentley, bundles need a readme, and the cw page should render it?
[19:53] <bac> abentley: better?  "(nice to have) charmworld should serve README for bundle in same manner as for charms"
[19:54] <abentley> bac: Much better.  I didn't understand that it was about bundles.
[19:54] <bac> abentley: i am going to mark it blocked on my current branch, though
[19:54] <abentley> bac: Okay.
[20:27] <hatch> bcsaller: kickin around?
[20:27] <bcsaller> hatch: yeah
[20:27] <bcsaller> whats up?
[20:27] <hatch> mind poping into guichat?
[20:28] <hatch> with rick and i
[20:45] <benji> abentley: thanks for the good review; I've made all the requested changes -- I think ;)
[20:48] <abentley> benji: looking...
[21:11] <hatch> bcsaller: rick_h gg :P
[21:12] <rick_h> hatch: heh, let me know how far you get. I can finish up/clean up in the morning. A simple test on the initState should work to make sure it's cleaning 
[21:12] <rick_h> hatch: that's really the only *change* that's needed is that stupid initState method 
[21:12] <hatch> haha right
[21:12] <rick_h> I'm outta here...
[21:12] <hatch> I'll send you an email with as far as I get
[21:12] <hatch> have a good night
[21:13] <rick_h> hatch: sorry to delay the release :(
[21:13]  * hatch shakes fist
[21:13] <hatch> lol np
[21:13] <rick_h> hatch: or feel free to leave it, Probably not getting 2 reviewd and such to release today anyway
[21:13] <rick_h> I'll have it up ready to go before you start tomorrow
[21:13] <hatch> oh ok can do that too
[21:14] <hatch> I can move onto other things
[21:14] <hatch> ok so I'll leave it then
[21:14] <rick_h> yea, up to you. I know I'm blocking you and don't want to, but not sure how much you'll get anyway :/
[21:14] <rick_h> cool, thanks for the help/talk throughs
[21:56] <sinzui> bac: your revisions are on staging