[14:25] <hatch> rick_h_: currently holding on my branch for kyles to land to hook them all up - is there a card you'd like me to work on?
[14:25] <rick_h_> hatch: can you help do any QA on the stuff in review?
[14:27] <hatch> hoooooly
[14:27] <hatch> yep
[14:27] <rick_h_> hatch: ty
[14:34] <lazyPower> hatch: you still looking for me?
[14:34] <lazyPower> i was out on swap when you were pinging for me
[14:34] <hatch> lazyPower: hey - yeah I am going to remove the ghost zip from the charm - they are releasing updates too fast to keep the charm up to date
[14:35] <lazyPower> hatch: thats fine, i suggest you add a make target to sync for offline use
[14:35] <hatch> a blog offline? :)
[14:35] <lazyPower> eg: make offline - wget's the zip into files/ so it supports offline deployment.
[14:35] <lazyPower> its good practice to support offline deployments in your charms, as we dont know the use cases for people. this may go behind someones corp firewall where they cannot reach github
[14:35] <lazyPower> see: prodstack
[14:36] <hatch> I suppose
[14:36] <hatch> so wouldn't a make target fail then as well?
[14:49] <hatch> rick_h_:  looks like qa's are all caught up now
[14:49] <rick_h_> hatch: ok thank you
[14:50] <rick_h_> hatch: is there anything that can be done then to help out with the added services? Or nothing to do at this time?
[14:50] <rick_h_> jujugui call in 10 please kanban
[14:51] <rick_h_> hatch: if not, then we need to start looking at the masthead updates in the maint lane
[14:51] <hatch> not really - the canvas stuff can't land without the db updates 
[14:51] <hatch> ok I can hop on that
[14:51] <rick_h_> hatch: I'd hope you and kadams can work together on that a bit, we need to see what the UX team wants, what we can give them, and get it updated as close as we can
[14:52] <hatch> well maybe then I can take over what kadams54 is on and he can go with this masthead stuff?
[14:52] <rick_h_> hatch: up to you guys, whatever moves things the fastest to be honest
[14:52] <hatch> would just really like that added services stuff to keep moving forward
[14:52] <rick_h_> hatch: understood, I'd like to have it in the release for sure 
[14:53] <hatch> uhh yeah heh they moved the search box in the masthead updates
[14:55] <rick_h_> hatch: heh looking
[15:20] <frankban> urulama: are you going to Gardaland? 
[15:20] <kadams54> rick_h_: On the sports team note… http://imgur.com/a/OVbqs
[15:21] <urulama> frankban: yes! 
[15:21] <urulama> frankban: the helloween one, on 31st :)
[15:21] <rick_h_> kadams54: I was going to compliment you on the new do today :)
[15:21] <urulama> frankban: staying there by Sunday
[15:22] <frankban> urulama: nice! It's ages since my last time there, I remember it's really nice!
[15:23] <rick_h_> roller coastering urulama ?
[15:23] <hatch> brb grabbing coffee
[15:23] <urulama> rick_h_: sure hope so ... 
[15:26] <lazyPower> hatch: the idea is the developer machine has unfettered access to teh internet, regardless if done @ a coffeeshop before they head into the office, or what the case may be
[15:26] <lazyPower> the failure of the make target is less of a concern to me than the deployment failing
[15:48] <hatch> hmm ok I'll see what I can come up with
[16:16] <hatch> ugh this damn update
[16:16] <hatch> it's like it can't handle more than one packet per hour
[16:35] <hatch> boy would it be nice if we had css source maps :)
[16:47] <hatch> kadams54: do we have a standard border radius mixin?
[16:47] <hatch> or a standard radius?
[16:47] <kadams54> Yeah: .create-border-radius(@radius)
[16:47] <kadams54> In mixins.less
[16:49] <kadams54> That said, the only browser that doesn't support just plain old "border-radius" is IE8. Mixins always felt like overkill to me for that.
[16:49] <hatch> well I'm just using it to avoid having to type it all out haha
[16:52] <rick_h_> jujugui note that you have two weeks to file swap days from the sprint which are up. Please get those in asap if you want to use them. 
[16:53] <rick_h_> jujugui recall that you just have to file them, but can use them any time this year
[16:53] <hatch> for once I don't have any lingering
[16:53] <hatch> heh
[16:53] <rick_h_> :P
[16:57] <hatch> kadams54: so do we have a styleguide - with at least hex codes? Or am I just to guess from what's currently being used lol
[16:58] <rick_h_> hatch: it's probably in variables.less
[16:58] <hatch> I'm also trying to go off of a compressed image haha
[16:59]  * hatch holds up fingers in a frame shape.......yep that's about right
[16:59] <kadams54> Not that I know of on the styleguide. variables.less is the place to go.
[16:59] <kadams54> hatch: what are you working on?
[16:59] <hatch> new header styling
[17:00] <kadams54> Do they have a prototype anywhere?
[17:00] <kadams54> That was the nice thing about added services.
[17:00] <hatch> just a compressed photo
[17:00] <kadams54> I didn't have to guess
[17:00] <kadams54> That is less than ideal
[17:00] <hatch> it's close to done now
[17:00] <hatch> some odd spacing cascades though
[17:07] <lazyPower> rick_h_: who do i poke to get some debugging help with quickstart? i've got a deployment that is recognized but appears to be hung on my juju-gui unit, no machines are being added, and when i re-execute the bundle deployment it just queues on top of the stack.
[17:07] <lazyPower> i dont know what to file here, as its probably working as expected, but this is not the result i'm looking for, so specifics would help when filing the bug.
[17:08] <rick_h_> lazyPower: I'd check the normal juju logs and see what's up. 
[17:08] <frankban> lazyPower: juju version?
[17:08] <rick_h_> lazyPower: there's a bug out that's fixed in trunk to be aware of
[17:08] <lazyPower> frankban: 1.20.10-trusty-amd64
[17:09] <hatch> oh that's the buggy one
[17:09] <frankban> lazyPower: uhm... so it's not the devel bug
[17:09] <lazyPower> i dropped of the alpha builds when all-state-watcher broked.
[17:09] <hatch> oh
[17:09] <hatch> lol
[17:09] <lazyPower> that broke like everything everywhere re: testing
[17:09] <frankban> yeah
[17:10] <frankban> lazyPower: any hint from the gui server logs?
[17:11] <lazyPower> absolutely nothing in the gui log pertaining to the deployment
[17:12] <lazyPower> in /var/log/juju/juju-gui.log
[17:12] <frankban> lazyPower: in /var/log/upstart/guiserver.log
[17:12] <lazyPower> ah, checking there
[17:13] <lazyPower> interesting
[17:13] <lazyPower> something about pickling ssl
[17:13] <lazyPower> http://pastebin.ubuntu.com/8721706/
[17:16] <frankban> lazyPower: from those logs, it seems the deployments started: [{'Status': 'started', 'Queue': 0, 'DeploymentId': 0, 'Time': 1414515682}]
[17:16] <lazyPower> thats what i'm seeing too - but nothings happening provider side
[17:17] <frankban> lazyPower: what's returned if you go to https://<juju-gui>/gui-server-info ?
[17:17] <lazyPower> no machines are being provisioned, no service squircles on the canvas
[17:17] <lazyPower> frankban: http://paste.ubuntu.com/8721750/
[17:18] <frankban> lazyPower: didn't you mention that you tried to queue other deployments? I don't see those there
[17:18] <lazyPower> this is a fresh quickstart 
[17:18] <frankban> lazyPower: no other logs in the guiserver.logs?
[17:18] <lazyPower> i can run it again and you'll see additional deploymetns queue, give me a moment to do that.
[17:18] <frankban> lazyPower: no, that's not helpful, just wondering
[17:19] <frankban> lazyPower: so, from the gui server perspective, that deployment is started, and it's waiting to hear something from the deployer
[17:19] <lazyPower> http://paste.ubuntu.com/8721767/
[17:19] <lazyPower> there's teh follow up, no change in 0
[17:20] <hazmat> frankban, please use -S option with deployer
[17:20] <hazmat> frankban, it will speed things up immensely
[17:20] <hazmat> ie. deployer will config/deploy/relate, and exit
[17:20] <hazmat> gui is already displaying status / health
[17:21] <rick_h_> hazmat: have that captured from the sprint but haven't updated it yet. http://goo.gl/tUSTK2
[17:22] <hazmat> cool
[17:22] <frankban> hazmat: yeah, but this seems a different problem, the service blocks are not displayed
[17:23] <frankban> lazyPower: is the deployer running on the gui unit?
[17:23] <lazyPower> its not
[17:23] <lazyPower> i think it bailed due to this 404 error
[17:24] <lazyPower> its looking for a charm it cant find, which is boggling me too
[17:24] <frankban> lazyPower: ps aux | grep python >
[17:24] <lazyPower> all we have running on teh unit through python is the guiserver
[17:24] <lazyPower> 3 threads
[17:24] <lazyPower> http://pastebin.ubuntu.com/8721812/
[17:25] <hazmat> frankban, true not directly related, but it solves the queuing deployments waiting period.
[17:25] <frankban> hazmat: sure
[17:25] <lazyPower> http://paste.ubuntu.com/8721825/ -- here's the deployer error, and this is consistent when charmworld doesn't find a charm
[17:26] <lazyPower> so i think this is the core of the issue
[17:26] <lazyPower> deployer bailed, the gui-server is waiting for deployer to say something
[17:27] <frankban> lazyPower: if the deployer encounters an error the GUI should be aware of that, so this seems to be a bug in the GUI charm
[17:27] <frankban> lazyPower: could you please file it with some steps to dupe and the log in http://paste.ubuntu.com/8721825/ ?
[17:27] <lazyPower> frankban: surely
[17:27] <frankban> lazyPower: ty
[17:28] <lazyPower> frankban: thanks for helping me get good info for you - i didn't want to file a bug 'the gui ate my deployment halp'
[17:28] <lazyPower> as thats not helpful
[17:28] <frankban> lazyPower: np, ty
[17:37] <lazyPower> http://manage.jujucharms.com/api/2/~lazypower/trusty/logstash-agent-0 - is that the proper resource url for checking namespace charms?
[17:38] <rick_h_> lazyPower: should be api/3
[17:38] <lazyPower> for non-promulgated charms, this is of the form
[17:38] <lazyPower> ~$owner/series/$name(-$revision). - is what i've found in teh charmworld docs, but that appears to be the cause of the problem.
[17:38] <rick_h_> lazyPower: api/2 is deprecated a while ago
[17:38] <lazyPower> ah ok, i just incremented from 1 based on what was responding.
[17:39] <rick_h_> lazyPower: it's missing the /charm I think
[17:39] <rick_h_> http://manage.jujucharms.com/api/3/charm/~lazypower/trusty/logstash-agent-0
[17:39] <rick_h_> lazyPower: ^ is the working call
[17:39] <lazyPower> ah ok
[17:39] <lazyPower> thanks 
[17:46] <hatch> lunching
[18:27] <lazyPower> rick_h_: question for you re: store api
[18:27] <rick_h_> lazyPower: otp but what's up
[18:28] <lazyPower> nevermind, i just answered my own question by spelling it out to ask it.
[18:34] <rick_h_> cool best questions
[18:41] <lazyPower> pebkac for the win
[18:41] <lazyPower> never assume you know better than the store, it will bite ya every time.
[18:41] <rick_h_> as long as it's not my keyboard :)
[18:41] <rick_h_> then there's problems!
[18:42] <lazyPower> i thought hive was -13, its -1 in the store
[18:42] <lazyPower> namespace vs promulgated charm woes
[18:42] <rick_h_> ah, yea
[18:42] <lazyPower> when i double-checked, i realized i was being silly
[19:26] <rick_h_> jujugui off to get the boy, I'll be back tonight if anyone needs anything
[19:26] <hatch> cyas
[19:27] <rick_h_> no kadams?
[19:30] <hatch> heh not sure
[19:30] <hatch> looks like he timedout
[19:52] <hatch> kadams54: you timed out :)
[19:56] <kadams54> Yeah, my wifi's been a bit flaky today. I've had to restart it three times. Not sure what's going on.
[19:58] <stokachu> rick_h_: you around
[19:59] <stokachu> https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/landscape-server <- can someone get this pushed out now?
[20:00] <urulama> hatch, jcsackett: the ingestion happens on every 15/30min in the existing store, right?
[20:00] <hatch> every 30 I think
[20:00] <jcsackett> urulama: it happens every 15 min in charmworld. i don't know about the store.
[20:00] <hatch> yep
[20:01] <urulama> stokachu: so, ingestion happens every 15min ... when did you push it to LP?
[20:01] <hatch> jujugui requesting review and qa for masthead updates https://github.com/juju/juju-gui/pull/629
[20:01] <stokachu> urulama: 20m ago
[20:01] <stokachu> i was just told there are 1000 items in the queue though
[20:02] <hatch> it has to pass proof, did it pass proof locally?
[20:02] <hatch> (that's what usually fails for me)
[20:03] <hatch> kadams54: hey anything I can help with to get your branch done quicker? I'm just finished the one I was one
[20:03] <hatch> on*
[20:03] <hatch> pre-review or anything heh
[20:04] <kadams54> hatch: yeah, I'm going to have you look at a WIP PR for this "service flag percolates down to the unit flag" stuff.
[20:04] <kadams54> It feels Rube Goldberg-ish to me.
[20:04] <hatch> haha - sure
[20:04] <kadams54> Give me a moment here…
[20:05] <hatch> we can always bench that feature
[20:05] <hatch> and just do the service flags
[20:05] <hatch> and then fix it in post
[20:12] <kadams54> Not really an option.
[20:12] <kadams54> The flags need to be set at the unit level for machine view to work.
[20:12] <hatch> right - but they are doing that now
[20:12] <hatch> already in tha hander
[20:12] <hatch> I guess I'll wait until I see the code
[20:30] <Makyo> Whoa, new sit/stand desk from Ikea for a reasonable price http://www.ikea.com/us/en/catalog/products/S19022530/
[20:30] <rick_h_> stokachu: what's up?
[20:31] <stokachu> rick_h_: we got it, was the landscape-server in trusty cs
[20:31] <rick_h_> stokachu: ok cool. yea sorry, we don't have manual control. Requires getting IS to touch things. 
[20:31] <rick_h_> stokachu: glad it's set then
[20:36] <hatch> Makyo: am I blind or does it not say how to adjust it?
[20:37] <Makyo> hatch, in product info it says "you can adjust the height electrically from 22" to 48""
[20:37] <hatch> yup blind
[20:37] <hatch> wow quite a deal in that case
[20:37] <hatch> now can I get it in Canada....
[20:37] <Makyo> Haha
[20:38] <hatch> nope of course not
[20:39] <hatch> that crazy border is just too hard to get compressed paper and steel over
[20:41] <Makyo> Must be the new Canada-America wall they're building.
[20:42] <hatch> haha
[20:42] <hatch> that would be one big wall
[20:42] <kadams54> hatch: https://github.com/juju/juju-gui/pull/630
[20:42] <hatch> cool looking
[20:43] <hatch> kadams54: we can hide services?
[20:43] <hatch> I thought they just fade lol
[20:43] <kadams54> Fade, hide, highlight… They're all in the API.
[20:50] <hatch> kadams54: so this doesn't update the master unit list
[20:51] <kadams54> Yeah, that's what I thought too.
[20:51] <hatch> but it is?
[20:51] <kadams54> But then I added assertions against db.units into the test
[20:51] <kadams54> And it still passed
[20:51] <kadams54> Take a look at the test code and see if things look legit there
[20:51] <kadams54> I'm very puzzled
[20:51] <kadams54> I did not expect that to happen.
[20:53] <hatch> what the heck
[20:56] <hatch> Oh I see why that's happening
[20:56] <hatch> oh boy this is not good
[20:56] <hatch> heh
[20:56] <kadams54> *sob*
[20:56] <hatch> I mean, it is what it is, but no not good
[20:56] <kadams54> Is this a Canadian pep talk?
[20:56] <rick_h_> hatch: ?
[20:56] <hatch> I bet it won't update both if you 'promote' one
[20:57] <hatch> soooo
[20:57] <hatch> hmm
[20:57] <hatch> the question is do we rely on this behaviour or not haha
[20:57] <hatch> hmm thinking
[20:58]  * rick_h_ doesn't know what's up but is asking 'how does it need to be done to be right?'
[20:58] <kadams54> If we don't, then my intention had been to put an event handler (in the DB) for *:change on service.units that applied the same changes in db.units.
[20:58] <hatch> the reason its working is because we add the same 'object' as the model to both lists
[20:58] <hatch> and because its pass by reference updates to one update the other
[20:59] <hatch> so it'll fall over if one of the models gets 'promoted' to a real model
[20:59] <hatch> so does it work now....sure....will it break? ehhhhh maybe?
[20:59] <hatch> heh
[21:00] <kadams54> Would cloning the object in the test break the reference?
[21:00] <hatch> no it's in addUnit
[21:00] <hatch> so you could try in addUnit to clone it
[21:00] <hatch> see if it breaks
[21:00] <kadams54> Don't really want to change real code
[21:01] <hatch> yeah see we add the models to the unit list
[21:01] <hatch> which returns the units
[21:01] <hatch> then we add those to the service
[21:01] <hatch> so they are the same object
[21:01] <kadams54> Sorta, except I'm not using the return value from db.addUnit
[21:01] <hatch> no it's what's actually being added in addUnit
[21:02] <kadams54> Ah yeah, I see
[21:02] <hatch> so...
[21:02] <hatch> yeah...
[21:02] <hatch> hmm
[21:02] <hatch> stupid js
[21:02] <hatch> lol
[21:02] <kadams54> So I actually have unnecessary code in my JS
[21:02] <hatch> yeah 
[21:03] <hatch> so anyways - I think it'll be ok to rely on this
[21:04] <hatch> the only time it could fall over is if someone promoted a unit model then forgot to free it
[21:04] <kadams54> I can make sure we have a test for addUnit that verifies the behavior is in place.
[21:04] <hatch> well that won't make sure it doesn't break later
[21:05] <kadams54> Which won't guard against that situation, but will make sure that someone doesn't pull the rug out from under this added services work by changing the addUnit implementation on down the road.
[21:05] <hatch> yeah true true
[21:05] <hatch> well I'm not really very happy about this - but right now we'll just have to rely on this 
[21:06] <hatch> I don't see any workaround that won't be a bunch of work 
[21:08] <hatch> kadams54: I suppose we could guard for it by making sure we explicitly update both
[21:09] <hatch> kadams54: but then what I'd do is create an 'updateUnitFlag' method on the db to update both similar to addUnit
[21:09] <hatch> thoughts?
[21:09] <kadams54> Yeah…
[21:09] <kadams54> There are no good options.
[21:09] <kadams54> Just lesser evils.
[21:11] <hatch> at the point of the handlers we have db right?
[21:14] <kadams54> Yeah.
[21:15] <hatch> so maybe that last idea is the best
[21:15] <hatch> so we'd explicitly update the service in one call adn the units in another
[21:15] <hatch> it's a little hand wavy though
[21:15] <hatch> if your not in-the-know
[21:19] <kadams54> Yeah… I'm defering that whole issue for the moment to get the rest of the stuff wired up. I'll revisit once I have an idea what the rest of the ball 'o wax looks like.
[21:22] <hatch> sure thing
[21:22] <hatch> rick_h_: is there another card you'd like me onnow?
[21:23] <rick_h_> hatch: what's needed to move added services then? /me is trying to cook and keep up convos in two irc channels
[21:24] <hatch> haha - well kadams54 is getting the event handlers to update the models, once that's finished then my branch can hook up with the models and be off to the races
[21:24] <hatch> mv currently works as expected
[21:24] <hatch> so it's just the canvas stuff
[21:27] <rick_h_> hatch: I'd suggest doing a round of QA on the gui and getting ready to remove the flag and prepare for release?
[21:28] <hatch> sounds like a plan
[21:29] <hatch> kadams54: think you'll be able to get something up befor your eod that I can take over on?
[21:29] <hatch> I think thats in 30min
[21:54] <urulama> heh, just read the old man & ubuntu story ... i put ubuntu on my father's laptop. he loved it ... just couldn't live without MS Office :( Had to put win7 back. Thinking of upgrading his RAM and running office in VM ... 
[21:55] <hatch> haha - now with google docs that is coming less and less necessary
[21:55] <urulama> but he also preferred it over Windows or MacOSX
[21:56] <urulama> unfortunately, those are some serious docs with macros and shit ... 
[21:58] <hatch> definitely prefer it over the mess that is yosemite 
[21:58] <hatch> :D
[22:00] <urulama> i love yosemite! it works as a charm
[22:00] <hatch> nothing I do makes the font not blurry
[22:01] <hatch> if I didn't work in Ubuntu this computer would be unusable
[22:01] <hatch> because I coudln't stare at the font all day
[22:01] <urulama> ah, non-retina displays ...
[22:01] <urulama> their friendly message saying "go get one" :D
[22:02] <hatch> urulama: https://www.evernote.com/shard/s219/sh/a14e7c9a-75c1-44ca-9c40-2acf5f8826a4/bd29f4177d13499ae31fb8fe759895cf
[22:02] <hatch> it's only marginally better on the laptops real screen
[22:02] <urulama> i must say they do look ok on 27" but really bad on an older non-retina 15 and 13" :(
[22:03] <hatch> and the new launcher bar is just...icky
[22:03] <hatch> I turned transparency off to at least make the fonts tolerable
[22:04] <hatch> for short use heh
[22:04] <urulama> i put it on the side, so it's the same :)
[22:04] <hatch> except that none of the icons were designed for this type of bar
[22:04] <hatch> and the bouncy icons just look odd when it's supposed to be contained
[22:04] <hatch> it's really a design fail imho
[22:05] <rick_h_> they'll fix it and call it the best thing they've ever done :P
[22:05] <rick_h_> worthy of a point release in 3mo
[22:05] <hatch> lol!!
[22:06] <hatch> I thought this new designer guy is supposed to be so amazing 
[22:06] <hatch> there are so many issues that I can find - and I'm clearly not a designer lol
[22:07]  * hatch just wonders who he has to bribe to get real graphics drivers for Ubuntu for this machine ;)
[22:07] <hatch> then I can run it on metal and be done with it
[22:08] <hatch> rick_h_: did you see the update to this bug? https://launchpad.net/bugs/1375918 heh quite an oversight :)
[22:08] <mup> Bug #1375918: units can be created without a service causing cascading failures <juju-gui:Triaged> <https://launchpad.net/bugs/1375918>
[22:09] <rick_h_> hatch: yea werent you looking at that?
[22:09] <hatch> I did but couldn't figure out the issue
[22:09] <hatch> there is no issue if you never tear down old units and create new ones so their id's overlap :)
[22:10] <rick_h_> ah gotcha
[22:10] <hatch> it's probably a few days of work to fix 
[22:10] <hatch> because we need a new id system for units
[22:10] <hatch> bleh
[22:11] <hatch> the good news is that the gui is getting stable enough that we only run into wako obscure issues haha
[22:11] <hatch> sort of good news?
[22:11] <rick_h_> well this is because we remove the 'new'?
[22:11] <rick_h_> hah
[22:12] <hatch> new units are never created with 'new' 
[22:12] <rick_h_> I have to say, I was liking how really we've not had a GUI release with a major OH CRAP bug that we had to jump out ahead of and such. 
[22:12] <hatch> they are created with serviceName + '/' + unitCount
[22:12] <rick_h_> ah, I wonder if we can get what juju thinks the number should be or something
[22:12] <hatch> well I am pretty sure we have to wait for juju to ack back on creation
[22:13] <hatch> similar to the machine id 
[22:14] <hatch> rick_h_:  in some interesting news I think we can build the canvas with react :O dragging and all 
[22:14] <hatch> not that we should
[22:14] <hatch> but it appears to be possible
[22:14] <rick_h_> :P
[22:15] <rick_h_> I think we've got a lot of react stuff to put into place first before worrying about the canvas
[22:15] <hatch> haha yeah 
[22:15] <hatch> there are also other 'virtual dom' solutions coming out now that react is getting mindshare
[22:16] <hatch> so that's good news
[22:27] <hatch> Makyo: rocket failed? I thought they just postponed because of a boater
[22:28] <Makyo> hatch, that was yesterday. They just launched, failed 6 sec after launch.  MAde it 100ft or so, then just stalled.
[22:28] <hatch> damn
[22:28]  * hatch hits up youtubes
[22:28] <rick_h_> linky?
[22:28] <hatch> nothing yet
[22:28] <hatch> darn
[22:28] <rick_h_> we were just talking rocket science in the other room :)
[22:28]  * hatch NEEDS INFORMATIONS
[22:28] <Makyo> hatch, rick_h_  watching live feed on nasa.gov, pretty soon for youtubes
[22:29] <Makyo> https://twitter.com/11AliveNews/status/527224598384095235/photo/1
[22:30] <hatch> damn
[22:30] <hatch> so can the ppl on the ISS still last until next launch?
[22:30] <rick_h_> oh boom
[22:30] <Makyo> Still waiting on that
[22:30] <urulama> damn
[22:30] <urulama> was that the new program?
[22:31] <urulama> (getting away from using russian rockets)
[22:31] <Makyo> Part of the privatized supply missions, I think
[22:32] <hatch> http://youtu.be/gY8cngQba58?t=55s
[22:33] <rick_h_> hatch: did you get two reviews? /me is looking for your masthead branch but sees it landed
[22:33] <hatch> oh crud I totally blanked and shipped it after one
[22:33] <hatch> Makyo: did a review and qa
[22:33] <rick_h_> hatch: k, two reviews next time please :)
[22:34] <hatch> yeah sorry bout that
[22:34] <hatch> wow that was a big boom
[22:35] <hatch> I can't imagine what that team is feeling
[22:37] <urulama> hatch: now, *this* is something scary ... https://twitter.com/heathercmiller/status/526770571728531456/photo/1
[22:37] <urulama> :)
[22:37] <rick_h_> I think it goes something like "ugh...hope our insurance was paid up on that or I'm not getting a paycheck"
[22:37] <rick_h_> urulama: love that one
[22:38] <hatch> urulama: haha
[22:38] <hatch> rick_h_: someone would sell insurance on that? lol
[22:39] <rick_h_> yea, I think each launch is insured. http://en.wikipedia.org/wiki/Satellite_insurance
[22:39] <hatch> sheesh I bet THEY are sweating too
[22:43] <urulama> have fun all, cu tomorrow