=== urulama__ is now known as urulama
=== urulama is now known as urulama___
=== dimitern is now known as dimitern_afk
[13:36] <hazmat> do we release updated charms for both trusty and precise?
[13:36] <hazmat> re gui
[13:36] <rick_h_> hazmat: we have been yes
[13:36] <hazmat> cool
[13:37] <rick_h_> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/revision/100 1.2.2 GUI
[14:49] <hatch> man the gui is stable
[14:49] <hatch> I haven't come across a single unknown bug
[14:50] <hatch> (unknown being the key word there)
[14:50] <hatch> ;)
[14:51] <hatch> although Makyo I still from time-to-time get the services bouncing all over on deploy - it appears to be related to dragging at a specific point during the deploy cycle but I can't reproduce it reliably 
[14:52] <rick_h_> kadams54: hatch how we doing for releasing today? I looked at kadam's branch but the card is in coding still?
[14:52] <kadams54> I'm prepping an update on that PR that will take it out of WIP status.
[14:53] <rick_h_> kadams54: ok cool
[14:58] <hatch> yeah we should probably do a follow-up bug fix release after this one for some of those known bugs
[16:08] <kadams54> hatch, rick_h_: https://github.com/juju/juju-gui/pull/631
[16:08] <kadams54> *finally*
[16:11] <rick_h_> kadams54: ty looking in a min
[16:11] <hatch> kadams54: on it
[16:24] <hatch> kadams54: ok reviews done- mind taking a look
[16:27] <kadams54> Yeah, I looked through them. I've got a 12:30 lunch appointment here, but I'll reply in the PR.
[16:33] <rick_h_> kadams54: review done
[16:33] <rick_h_> hatch: you've got the steps then to integrate enough to QA?
[16:34] <hatch> rick_h_: yeah I'll take this work to make sure my branch works as expected - I've made a bunch of comments but it should work as expected as is then we can revisit these changes later if needed
[16:35] <rick_h_> hatch: ok cool
[16:35] <rick_h_> hatch: let me know if you need a hand 
[16:37] <hatch> I just need to find all the rules again
[16:37] <hatch> heh the interactions are complex lol
[16:38] <hatch> I replied to the angular thread :) Wrote the email at like 2am forgot to send it
[16:38] <rick_h_> hatch: :)
[16:39] <rick_h_> hatch: don't see it yet booo
[16:40] <hatch> it's long.....real long
[16:40] <hatch> might take time go through the internets
[16:40] <rick_h_> lol
[16:40] <rick_h_> ouch
[16:40] <rick_h_> I'll read it over lunch then :)
[16:41] <hatch> well how do you systematically destroy angular in a short email....like c'mon
[16:41] <hatch> :P
[16:42] <hatch> holy crap it works
[16:43] <hatch> well the mv is broken....but holy crap the canvas stuff works
[16:43]  * hatch needs a moment
[16:47] <hatch> ok yeah the qa is not good wrt the mv stuff and one bug on the canvas stuff which might be related to the data being sent from this branch
[16:55] <hatch> ok I found one pre-existing bug
[16:55] <hatch> I'll hop on that
[17:00] <rick_h_> hatch: cool ty
[17:00] <rick_h_> and yay 
[17:01] <hatch> I've added the qa issues to the PR
[17:01] <hatch> and created a card for the bug I'm on
[17:28] <hatch> kadams54: thanks for the replies - I replied to the one about defaults
=== dimitern_afk is now known as dimitern
[18:21] <hatch> lunching
[18:37] <kadams54> hatch: ping me when you're back, I have a question.
[18:44] <kadams54> guihelp: anyone know what's going on here? I set an attribute on a ModelList, but when I ask for the same attribute back, it's not set as expected. http://pastie.org/private/2npre7yetltxg4hvrtalw
[18:44] <rick_h_> kadams54: looking
[18:49] <rick_h_> kadams54: I'm not sure that's supposed to work tbh
[18:49] <rick_h_> kadams54: on using set and it reaching into the models in the list?
[18:49] <rick_h_> kadams54: I mean a model can have attrs so not sure how that would work 
[18:50] <kadams54> Yeah… that's what hatch seemed to suggest in the PR.
[18:51] <kadams54> modelList.set('foo', 'bar') would be equivalent to looping through and doing model.set('foo', 'bar')
[18:52] <rick_h_> kadams54: yea, but looking at http://yuilibrary.com/yui/docs/api/classes/ModelList.html#method_set I don't see it. I'd punt on that
[18:52] <rick_h_> kadams54: and see if you can figure out the QA issue? 
[18:52] <kadams54> Yeah, getting to that.
[18:53] <rick_h_> kadams54: and then when hatch gets back I'd like you guys to pair over a hangout and get the bits pulled in together. I'd like to try to have a qa'able branch I can qa at the coffee shop tonioght so tomorrow can be release
[19:04] <tvansteenburgh> rick_h_: is this is the canonical precise juju-gui -> ~juju-gui-charmers/charms/precise/juju-gui/trunk ?
[19:04] <tvansteenburgh> that's the only one i can find
[19:09] <rick_h_> tvansteenburgh: yes
[19:09] <tvansteenburgh> ty
[19:10] <rick_h_> tvansteenburgh: there's a ~juju-gui which is out dev one
[19:11] <rick_h_> doh, which has this change from adam but we hadn't done a release yet so you didn't see it
[19:11] <rick_h_> tvansteenburgh: so never mind
[19:11] <rick_h_> http://bazaar.launchpad.net/~juju-gui/charms/trusty/juju-gui/trunk/revision/209 tvansteenburgh 
[19:12] <rick_h_> tvansteenburgh: we're doing a release this week with the new feature and so hadn't put out the updates from adam, sorry that caused you to dupe them
[19:12] <tvansteenburgh> actually that one is not quite right
[19:12] <tvansteenburgh> so i'll send you a merge anyway
[19:12] <rick_h_> oh, well then carry on :)
[19:12] <tvansteenburgh> :D
[19:21] <hatch> kadams54: yo
[19:22] <kadams54> hatch: Hey, digging into your QA issues right now.
[19:23] <kadams54> Pushed changes that addressed all your review feedback if you want to look those over.
[19:23] <hatch> sure will do
[19:30] <hatch> kadams54: looks good - was my memory wrong wrt the .set() on a ML?
[19:31] <rick_h_> hatch: looks like it just sets attrs on the ML object
[19:31] <rick_h_> hatch: checked out the api but didn't see anything that would do it
[19:31] <hatch> hmm darn - wonder what I'm thinking of then
[19:32] <hatch> sure seems like something like that should be possible
[19:32] <rick_h_> you can .each and .some of a list
[19:32] <rick_h_> but I think you're thinking nodelist vs modellist
[19:32] <hatch> ahhhhh that's it
[19:32] <hatch> yes sorry my bad
[19:45] <hatch> kadams54: so did you want to pair on that qa debugging?
[19:55] <rick_h_> kadams54: hatch you guys settled?
[19:57] <hatch> I'm just hammering out a test for my branch - haven't heard back from kadams54 yet
[19:57] <hatch> should have this up shortly
[19:58] <rick_h_> kadams54: around? 
[20:02] <kadams54> rick_h_, hatch: yup, sorry.
[20:03] <rick_h_> kadams54: cool, please get together with hatch to sync up your branches/qa issues and get things pulled together hopefully by EOD if at all possible
[20:04] <kadams54> hatch: we have two QA issues. I'm looking at the first. You want to dig into the second?
[20:05] <hatch> jujugui looking for a review on a small bug fix https://github.com/juju/juju-gui/pull/632
[20:05] <hatch> kadams54: can do - if you don't think they are related?
[20:06] <kadams54> No, but don't quote me on that.
[20:06] <hatch> heh ok I'll take a look with your most recent updates
[20:06] <rick_h_> hatch: kadams54 I'd like you guys to work together please. get a hangout together, and keep in sync so if we need to hatch can carry to his EOD when kadams54 EOD's and such
[20:06] <hatch> ok can do
[20:08] <kadams54> hatch: standup hangout?
[20:08] <hatch> rick_h_: #632 is pretty small and easy to qa if you have time
[20:08] <hatch> kadams54: yup will join shortly
[20:08] <rick_h_> hatch: lookihng
[20:08] <rick_h_> looking
[21:12] <rick_h_> hatch: kadams54 going afk until coffee shop time tonight. Please make sure to drop me a note on where we're at for tomorrow at EOD please
[21:13] <hatch> rick_h_: hop in standup?
[21:14] <hatch> ok hopped out
[21:29] <hatch> jujugui anyone around able to do another easy review? https://github.com/juju/juju-gui/pull/632
[21:30] <Makyo> hatch, on it
[21:31] <Makyo> :+1:
[21:32] <hatch> thanks 
[22:46] <rick_h_> hatch: what's up?
[22:46] <hatch> :/
[22:46] <hatch> so many rules!
[22:46] <hatch> I'm trying to fix one last rule
[22:47] <rick_h_> hatch: k
[22:47] <hatch> the mv and service view have such different rules that post release this should be refactored a bit
[22:47] <hatch> I didn't realize how different they are
[22:58] <rick_h_> hatch: did you see the highlight icons from luca as well?
[22:59] <hatch> I didn't 
[22:59] <hatch> atm I'm just focused on getting this case fixed
[22:59] <hatch> which is going to require some model updates
[23:01] <rick_h_> hatch: :/ what's so different on it? 
[23:01] <hatch> ermahgerd - well in the service view 'related' services matter
[23:01] <rick_h_> hatch: I thought that's what this sync'ing of the state to the service/unit models was for. So that we could show/hide/highlight properly with the model as the single source of truth?
[23:01] <hatch> and we update the service model and unit model accordingly
[23:01] <hatch> unfortunately the mv doesn't care if anything is related
[23:02] <rick_h_> right, but the unit models don't need updating on the service view details
[23:02] <hatch> but the container column AND service view do
[23:02] <hatch> er not service view
[23:02] <hatch> sorry
[23:02] <hatch> just the container column
[23:02] <hatch> but the machine column needs the machine models to be set separately
[23:02] <rick_h_> ok, but that can just be rendering differences based on the same model dta?
[23:02] <rick_h_> ugh, we can't just handle machine show/hide at render time?
[23:03] <rick_h_> if the render() call finds that none of the units are visible, it just never draws?
[23:03] <hatch> problem is that the units use the 'related services' code to mark hidden/visible because that's what it needs for the container column
[23:04] <hatch> so we can't rely on that for the machine column
[23:04] <hatch> so the machines need their own flag
[23:05] <hatch> rick_h_: so I'm going to take a little break now, play some Destiny :) then come back later with a fresh head and get this done
[23:05] <rick_h_> hatch: ok, let me know if I can help
[23:09] <rick_h_> hatch: just thinking about that, it sounds like what we need is a triple state there. I've been hidden, I'm related to a hidden, and then false
[23:09] <rick_h_> hatch: so you can just check that field for more than a true/false and be ok
[23:09] <rick_h_> hatch: vs adding new model stuff to machines
[23:10] <rick_h_> in a way it's 6 of one, half dozen of another, but wonder if it's a bit simpler that the 'state' is in a single bit of data vs another one