[01:05] <hatch> evening huwshimi
[01:10] <rick_h_> huwshimi: <3 
[01:10] <huwshimi> hatch: Evening!
[01:11] <hatch> I am now able to sit straight in my chair again
[01:11] <rick_h_> hatch: :p
[01:11] <hatch> got one of these http://en.wikipedia.org/wiki/Myofascial_release
[01:20] <hatch> huwshimi: can you review this so I can land it? https://github.com/juju/juju-gui/pull/566
[01:20] <hatch> qa has already been done
[01:21] <huwshimi> sure
[01:22] <hatch> huwshimi: oh looks like rick_h_ is doing it
[01:22] <huwshimi> ah ok
[01:23] <rick_h_> huwshimi: feel free to look as well
[01:23] <rick_h_> I'm just being nosy
[01:23] <huwshimi> :)
[01:25] <rick_h_> hatch: feedback in, just one theme I'd ask a revisit with and a question or two
[01:27] <hatch> rick_h_: ok replies done - one q about the defaults for the model
[01:27] <hatch> default
[01:34] <rick_h_> github bit the farm :/
[01:34] <hatch> yeah just saw that :?
[01:34] <rick_h_> hatch: Hmm, I see what you mean. Most of the code isn't looking at this value so there's a lot of existing code that would have to know to create models with the right value. Setting a value means this has a chance to be a lie. 
[01:34] <rick_h_> The more I think on it the more this might be right. I do think it's odd that the comments mention an assumed default if undefined. 
[01:34] <rick_h_> I'll make some other suggestions based on sticking with an undefined default. 
[01:34] <hatch> sure ok thanks
[01:34] <rick_h_> hatch: so my other comment was that the comments you have around "if the value is undefined we set it to comitted"
[01:34] <hatch> oh I think that's a lie
[01:34] <rick_h_> but the code there after that isn't doing that
[01:35] <hatch> yeah - I think I had it do that before but then it wouldn't fail if something was missed
[01:35] <rick_h_> so I'd suggest updating that repeat comment or updating the code to get the value, and clearly set it comitted right there
[01:35] <hatch> you bet
[01:35] <rick_h_> that way the comment and the code are in line right together and chances of that being kept up to date are better
[01:36] <hatch> yeah definitely
[01:36]  * rick_h_ runs away for the night and checks on the wife-hop-a-long
[01:37] <hatch> haha cya
[01:37] <hatch> pass her my best
[01:37] <hatch> I just recently did the same
[01:37] <hatch> on the way back from London, it still hurts
[09:47]  * fabrice|lunch is going for lunch with friends
[10:38] <rick_h_> morning
[10:38] <rick_h_> party fabrice|lunch 
[12:07] <fabrice> rick_h_: morning
[12:18] <kadams54> rick_h_: looking for a new card; any suggestions? Was thinking about tackling bug #1371107.
[12:18] <mup> Bug #1371107: Machine view do not show icons after login <juju-gui:Incomplete> <https://launchpad.net/bugs/1371107>
[12:22] <fabrice> kadams54: kool the one I entered yesterday !
[12:22] <kadams54> guihelp: looking for reviews and QA on https://github.com/juju/juju-gui/pull/568 - review covers a whole four lines of code!
[13:18] <kadams54> jcsackett: thanks for the QA!
[13:19] <jcsackett> kadams54: yw. 
[13:19] <kadams54> Oh oh, wait, no…
[13:20] <kadams54> Aarrrr, thanks for the QA, you bilge-sucking bit-pusher!
[13:21] <rick_h_> morning
[13:21] <rick_h_> kadams54: looking
[13:22] <rick_h_> kadams54: that one's a tricky one. jcsackett did some work around that
[13:22] <rick_h_> kadams54: basically we don't get data until the page loads from the delta stream and so we'd need to live update the UI, but the user might have interacted so not sure we can
[13:23] <kadams54> rick_h_: yeah, I approached it with fear and dread ;-)
[13:23] <rick_h_> kadams54: can you investigate https://bugs.launchpad.net/juju-gui/+bug/1371112
[13:23] <mup> Bug #1371112: Unable to delete a service after deployment failed <juju-gui:New> <https://launchpad.net/bugs/1371112>
[13:23] <rick_h_> kadams54: and see if there's something there we need to look closer at and update please?
[13:23] <kadams54> rick_h_: Sure
[13:27] <urulama> rick_h_: that might be a core issue, i remember --force to remove a service in error state
[13:28] <rick_h_> urulama: right, just want to check it out
[13:33] <kadams54> guihelp: anyone have a suggestion on how to get units to fail on deploy?
[13:33] <rick_h_> kadams54: check out http://reports.vapour.ws/charm-tests-by-charm and look for a charm that fails that's not a lint issue
[13:35] <kadams54> rick_h_: Cool. That page seems super useful. Bookmarking.
[13:41] <rick_h_> kadams54: yea, it's in development still but might help with some of this. It's just a little hard to call out something we know fails to deploy atm
[13:41] <rick_h_> vs was it a test failure, or a lint failure, or what
[13:52] <kadams54> rick_h_: I updated 1371112 with additional comments. Merits looking into more.
[13:58] <rick_h_> kadams54: hmm, yea this gets into showing unit health in MV and such. 
[14:00] <kadams54> Yeah, that plays into it, but even if we did display unit health… there are still a bunch of other places that the workflow falls over, IMO.
[14:00] <rick_h_> kadams54: right, the workflow is in the inspector
[14:00] <rick_h_> kadams54: otp atm, thanks for checking into it. We'll have to think on it. 
[14:02] <kadams54> rick_h_: It seems like I ought to be able to destroy a unit in an error state. And the GUI makes it look like I should be able to as well - that is, I can go through the whole "make a change, click commit, click confirm" workflow. But it isn't actually being destroyed, which puts the GUI into a really odd state.
[14:03] <rick_h_> kadams54: right, and it's a pain point that juju wants you to resolve first
[14:04] <rick_h_> kadams54: so the UX is poor on cli and we're carrying it into webui
[14:06] <kadams54> rick_h_: since I don't have much experience with this… in the CLI you have to run 'juju resolved <unit>' before you can run 'juju destroy-unit <unit>'? Even if you do nothing to actually resolve the error?
[14:06] <rick_h_> kadams54: yes
[14:06] <rick_h_> kadams54: and every user learns that by getting angry with juju
[14:06] <kadams54> rick_h_: OK, got it.
[14:06] <kadams54> lol
[14:06] <rick_h_> so I understand what's happening and agree it's :(
[14:50] <hatch> jujugui call in 10
[14:52] <kadams54> guihelp: looking for a second review and QA on https://github.com/juju/juju-gui/pull/568
[14:53] <hatch> sure
[14:53] <fabrice> sure
[14:53] <fabrice> I was trying to get into my first review but hatch you can do it
[14:54] <rick_h_> fabrice: just do it
[14:54] <rick_h_> there's no rule that we can only have two on there
[14:54] <kadams54> It would actually be a pretty good PR for a first review
[14:54] <rick_h_> fabrice: and it'd be good to try out and do the QA
[14:54] <rick_h_> and hatch can just do review
[14:54] <fabrice> kool I'll do that this evening
[14:54] <kadams54> Congrats hatch, you get to review four lines of code :-)
[14:57] <hatch> kadams54: code looks good I'm more interested in the qq
[14:57] <hatch> qa
[14:58] <kadams54> Awesome. More eyeballs.
[14:59] <rick_h_> jujugui call in 1 go go go kanban, fight chrome, microphones, and your battery power remaining!
[15:00] <rick_h_> fabrice: rogpeppe2 ^
[15:33] <jrwren_> rick_h_: I'm missing one of those 4 review comment options, can you fillin the blank? 1. What is this doing?   2. Suggestion: do this too/instead.   3. Urgent: This is a problem.   4. _____
[15:33] <hatch> hammertime
[15:34] <Makyo> jrwren_, This is broken but out of scope, make a follow up carad
[15:34] <rick_h_> jrwren_: not in scope for this branch but please adda  follow up card
[15:34] <Makyo> *card
[15:34] <jrwren_> Makyo: thanks!
[15:34] <rick_h_> jrwren_: e.g. I see something up but don't block this on it
[15:34] <jrwren_> rick_h_: thanks!
[16:09]  * rick_h_ goes to find lunch now 
[17:14] <hatch> ooooo boy
[17:19] <rick_h_> hatch: what did you do now?
[17:20] <hatch> rick_h_: heh nah its just this conflict resolution UI was not designed to be used outside of conflict resolution
[17:20] <rick_h_> hatch: right, but you're not doing that yet right?
[17:20]  * hatch digs through closet for shoehorn 
[17:20] <rick_h_> one step at a time?
[17:21] <hatch> oh I'm done the other part 
[17:21] <hatch> https://github.com/hatched/juju-gui/compare/config-default?expand=1
[17:21] <hatch> I now need to figure out  how to make the UI work
[17:22] <rick_h_> hatch: then let's move that forward. The UI part can only be on the summary for now blocking and it's an incremental step forward. 
[17:22] <rick_h_> hatch: then we can regroup on the UI part on the inspector
[17:22] <hatch> rick_h_: but once the summary says there is something busted....how will they resolve it?
[17:22] <rick_h_> this is going to grow with tests/such and doing it in one swoop will go bonkers
[17:22] <rick_h_> hatch: it's a baby step. 
[17:22] <rick_h_> hatch: we'll do that part next
[17:23] <hatch> alrighty
[17:23] <hatch> I'll split my card up
[17:23] <rick_h_> ty
[17:23] <hatch> while I listen to the new Weird Al album
[17:24] <hatch> https://play.google.com/music/m/Bbevcxdfomo3gzvbf3aqiv6dubi
[17:56]  * rick_h_ steps away for a little bit
[18:20] <urulama> hatch: i'm living in "there be dragons" land :( /me goes find the album somewhere
[18:21] <hatch> haha
[18:35] <urulama> khm ... FB's sponsored ad for me is ... "Move to America" 
[20:43] <hatch> jujugui does comingsoon still update properly>
[20:43] <hatch> ?
[20:43] <jcsackett> hatch: i don't think so.
[20:44] <hatch> I think I stumbled across a databinding bug
[20:45] <hatch> yup
[20:48] <rick_h_> hatch: jcsackett it updates as far as I'm aware
[20:48] <hatch> jujugui anyone got a second to confirm this bug? rick_h_https://bugs.launchpad.net/juju-gui/+bug/1371789
[20:48] <mup> Bug #1371789: changing the configuration value of one boolean value marks all as uncommited <juju-gui:New> <https://launchpad.net/bugs/1371789>
[20:48] <rick_h_> hatch: jcsackett or do you mean a CSS issue? 
[20:48] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1371789
[20:50] <jcsackett> hatch: did huw's branch land? thought it addressed this. 
[20:50] <hatch> ugh this databinding is a house of cards
[20:50] <hatch> which branch is that?
[20:51] <hatch> there are no open prs
[20:55] <jcsackett> hm. it landed. i did not see this behavior qa-ing his branch, but it might be related. 
[20:55] <jcsackett> hatch, it may be CSS based, not data binding. 
[20:55] <jcsackett> I am in transit right now, but can look soon. 
[20:56] <hatch> jcsackett: yeah I didn't see it either while qa'ing kyles or huws heh
[20:57] <hatch> I added a screenshot
[21:06] <rick_h_> hatch: rgr, I see it and probably another chunk of work around the css stuff that kadams poked at today
[21:14] <hatch> conflict resolution is a tough problem - we probably should have invested the time in writing a more generic solution back when
[21:14] <rick_h_> Makyo: how goes the ecs stuff? 
[21:14] <rick_h_> hatch: jcsackett you'd have to QA with a charm with multiple boolean to see it, and they'd have to fit into the same space of the sidebar
[21:14] <Makyo> rick_h_, okay, just hunting down a million edge-cases.  Autoplacing units is giving me the most woe.
[21:14] <rick_h_> hatch: jcsackett so not surprised it went unnoticed
[21:15] <rick_h_> Makyo: how so?
[21:15] <hatch> rick_h_: yeah - true true
[21:15] <rick_h_> jcsackett: put a card on you for MV for next week, sorry to pull you back but with that and this other bug want to squash them asap monday
[21:15] <Makyo> rick_h_, placeUnit is just not very comprehensible, so I think I might've messed up in there somewhere.
[21:16] <rick_h_> Makyo: want to push WIP and we can peek at it monday before you start?
[21:16] <hatch> Makyo: oh I had to parse it too - if you need some help I may be able to help light the way
[21:16] <Makyo> rick_h_, sure, one sec.
[21:16] <Makyo> (Will likely be making up some slow-hours this weekend, fwiw
[21:16] <Makyo> )
[21:17] <rick_h_> but why does placeUnit come into play about swapping out the ecs with a fresh one on the env after deploy?
[21:17] <rick_h_> Makyo: all good, just checking in.
[21:17] <jcsackett> rick_h_: dig. on both cause of bad qa and back to mv. 
[21:17] <Makyo> rick_h_, I simplistically thought that placeunit would only come into play with ecs.changeSets[0], but I might've been kidding myself.
[21:18] <Makyo> rick_h_, Just needs some digging.
[21:18] <rick_h_> Makyo: rgr, ok
[21:18] <rick_h_> Makyo: well lean on the team if you need help. 
[21:18] <Makyo> rick_h_, rgr - wip branch https://github.com/makyo/juju-gui/tree/multi-ecs
[21:18] <rick_h_> or fresh eyeballs :P
[21:19] <hatch> https://github.com/makyo/juju-gui/compare/multi-ecs
[21:19] <Makyo> Or https://github.com/juju/juju-gui/pull/569 yeah, sorry.
[21:19] <hatch> Makyo: I think something is borked here....this includes changes that frankban made too
[21:19] <Makyo> Whaaat happened with that PR
[21:19] <Makyo> Yeah, one sec.
[21:19] <rick_h_> Makyo: need to rebase with develop
[21:20] <Makyo> Whaaat the hell
[21:21] <rick_h_> Makyo: have a sec to chat? 
[21:21] <rick_h_> hatch: jcsackett free to join?
[21:21] <Makyo> rick_h_, sure
[21:21] <hatch> yup
[21:21] <rick_h_> standup
[21:21] <Makyo> standup or friday call?
[21:21] <hatch> in friday
[21:21] <hatch> oh 
[21:21] <Makyo> Oh, okay
[21:23] <jcsackett> Coming. 
[21:23] <jcsackett> Well that was weird. 
[21:33] <hatch> I need to get out more - I'm worried that my brain will become acustomed to mouth's moving and sound being out of sync
[21:33] <hatch> lol
[21:34]  * rick_h_ runs away for the day night all!
[21:34] <hatch> cya rick_h_
[21:34] <rick_h_> lol
[21:37] <jrwren_> have a good weekend ya'll.  
[21:37]  * jrwren_ leaves
[21:40] <lazyPower> rick_h_: you know you work for an awesome company when you come across an email thread that mentions toga and powdered wig revenue in a large-scale discussion.
[21:40] <lazyPower> As I stated in the email, I slow clap for you sir.  well done.
[22:06] <rick_h_> lazyPower: glad you appreciated me feeding the trolls
[22:06] <rick_h_> I almost closed it while writing it but damn that kind of attitude bugs me
[22:09] <lazyPower> I was thorougly impressed
[22:09] <lazyPower> seriously
[22:09] <lazyPower> an argument like that shoudl be put on showcase in the hall of huehuehue