[03:27] <hatch> huwshimi rockin huge diff on that branch :D
[03:28] <huwshimi> hatch: I panicked for a second there, I wondered what I'd broken :)
[03:28] <hatch> haha
[03:28] <hatch> it's been +1'd
[03:29] <huwshimi> thanks
[03:30] <huwshimi> I hope the tests pass.
[03:33] <hatch> haha - if they don't then it'll fail on the merge
[09:54] <frankban> morning rogpeppe: are we in the middle of the git migration?
[09:56] <rogpeppe> frankban: i'm guessing so
[09:56] <rogpeppe> frankban: i haven't seen much activity recently tho
[10:14] <rogpeppe> frankban: well, go get github.com/juju/core/... works, so i guess it's all go
[10:15] <frankban> rogpeppe: yeah I see they are probably fixing some remaining bits (lbox stuff etc) I guess a message will be sent when the migration is done
[10:16] <rogpeppe> frankban: i'm going to submit PRs anyway :-)
[10:16] <frankban> rogpeppe: :-) I am trying to figure out our next steps
[10:16] <rogpeppe> frankban: me too
[11:05] <frankban> rogpeppe: I ended up with this schema: http://pastebin.ubuntu.com/7579583/ do you want to chat about next moves?
[11:10] <rogpeppe> frankban: i can't quite see why utils/ssh is factoring in there
[11:12] <frankban> rogpeppe: I think it's ssh.ParseAuthorisedKey in testing/environ.go
[11:13] <rogpeppe> frankban: but we don't need anything that's in that file, do we?
[11:13] <frankban> rogpeppe: FakeHomeSuite
[11:14] <frankban> rogpeppe: unless we decide to replace that with something else. my schema just reflects the current status
[11:15] <rogpeppe> frankban: i don't think FakeHomeSuite uses FakeAuthKeys or FakeConfig, does it?
[11:18] <frankban> rogpeppe: charm uses testing.CustomEnvironConfig, which in turn calls FakeConfig(). however, it seems in that file ssh is only used for a check done in init(). perhaps that can be removed and we just assume FakeAuthKeys to be valid
[11:20] <rogpeppe> frankban: i think we could make charm avoid using CustomEnvironConfig
[11:22] <frankban> rogpeppe: that would be great
[11:26] <rogpeppe> frankban: just going for lunch. i may be in patchy contact this afternoon - will let you know when i am online
[11:27] <frankban> rogpeppe: ok hanks, I'll try to extract some action items from that document, I'll send you an email later
[11:27] <frankban> thanks even
[11:42] <frankban> rogpeppe: for when you are back: here is a lst of actions we can work on in parallel, please let me know what do you think: http://pastebin.ubuntu.com/7579844/
[12:16] <rogpeppe> frankban: that all looks good
[13:03] <kadams54> guihelp: still looking for review/QA on https://github.com/juju/juju-gui/pull/357
[13:04] <frankban> kadams54: looking
[13:04] <kadams54> Thanks!
[13:11] <jcsackett> morning (or afternoon), all.
[13:12] <frankban> kadams54: LGTM
[13:12] <frankban> morning jcsackett 
[13:12] <kadams54> frankban: Super. Another one bites the dust.
[13:14] <kadams54> morning jcsackett 
[13:15]  * redir broke unity
[13:15] <jcsackett> i break unity with some regularity.
[13:24] <rogpeppe1> frankban: am online for 30 mins now, then away for an hour, then back again for 3 hours (working a bit later to make up for breaks)
[13:24] <frankban> rogpeppe1: ack
[13:31] <rogpeppe1> frankban: do you want to make sure that there are tasks for those things on the kanban that you mentioned?
[13:32] <frankban> rogpeppe1: I'll create cards for each item
[13:32] <rogpeppe1> frankban: there are already cards for some
[13:32] <frankban> rogpeppe1: ok
[13:32] <rogpeppe1> frankban: e.g. "migrate juju utils package"
[13:33] <rogpeppe1> frankban: what are you on now? i will get on with something other than that :-)
[13:34] <frankban> rogpeppe1: I'd start with filetesting, not sure if we can start working on the github project yet, asking
[13:35] <rogpeppe1> frankban: ok, if you create filetesting in github/juju/testing, then try a PR against github/juju/core...
[13:36] <rogpeppe1> frankban: it looks like CI is going, and everything seems like it's working, so might as well give it a go
[13:37] <frankban> rogpeppe1: I'll try to move the testing package preserving the git history. This means I will use the git commits in github.com/juju/core as a base, that's why I asked on the channel if the project is ready to be used
[13:37] <rogpeppe1> frankban: ah, i see
[13:37] <rogpeppe1> frankban: what's the procedure for doing that?
[13:38] <frankban> rogpeppe1: wait looking
[13:38] <rogpeppe1> frankban: (i haven't done that when moving other pieces to github/juju)
[13:39] <frankban> rogpeppe1: well, for small pieces I am not sure it's worth the effort, but when migrating a whole package/subdir then it's nice to preserve the history, and should also be easy enough
[13:39] <rogpeppe1> frankban: right; i have no idea how to do that - i presume there's a tool to help, or do i have to do it manually?
[13:41] <frankban> rogpeppe1: I guess "git filter-branch --subdirectory-filter $folder -- --all" should do the trick
[13:41]  * rogpeppe1 reads up on filter-branch
[13:42] <frankban> rogpeppe1: and then, for importing the tree into testing, something like "git subtree add --prefix=filetesting $branch master"
[13:44] <frankban> rogpeppe1: see #juju-dev, we need to wait
[13:44] <bac> hey jcastro, i may be doing a barcamp talk tonight.  you have a favorite bundle for doing demos to a group of people who've never heard of juju?
[13:46] <jcastro> bac, other than the simple wordpress ones? 
[13:47] <bac> jcastro: those would probably work.
[13:47] <jcastro> I like mediawiki:scalable
[13:47] <jcastro> complex enough to get the point across, but not too complex
[13:47] <jcastro> https://jujucharms.com/sidebar/search/bundle/~charmers/mediawiki-scalable/8/mediawiki-scalable/?text=mediawiki-scalable
[13:54]  * rogpeppe1 leaves. back in an hour.
[14:03] <bac> thanks jcastro
[14:06] <kadams54> guihelp: currently looking at the "adding unit to undeployed service and clicking machine view gets you 'stuck' in machine view" card and not seeing the same behavior. My guess is that I'm just not going through the right steps to duplicate.
[14:07] <kadams54> Anyone know more details?
[14:17] <hatch> frankban thanks for trying that bug - did you fix the machine to machine.id first?
[14:20] <frankban> hatch: no, I didn't see the initial error
[14:20] <kadams54> hatch: getting selenium timeouts in my merge build. Should I retry, or does jenkins/selenium need to be kicked first? http://ci.jujugui.org:8080/job/juju-gui-merge/367/console
[14:21] <hatch> frankban oh ok, sorry I wasn't clear - that needs to be done 'machine' is a string so 'machine.id' is always undefined so it will always place a new machine
[14:21] <hatch> I'll update the bug
[14:22] <hatch> kadams54 you can re-run it in jenkins
[14:22] <frankban> hatch: I'll take another look with the bug and dupe instructions updated
[14:23] <kadams54> hatch: do I re-run by deleting the comments on the PR?
[14:23] <hatch> frankban thanks!
[14:23] <hatch> kadams54 no you log into jenkins and re-run it manually
[14:23] <hatch> do you know your jenkins account info?
[14:23] <kadams54> Yeah
[14:24] <kadams54> I thought that was the case for builds on the PR branch, but not for merge/shipit builds.
[14:26] <hatch> merge builds you can just delete the comment which says that the merge has been accepted
[14:28] <kadams54> Ah yes, OK…
[14:42] <frankban> hatch: so machine in that code is not a model instance, it's just an ecs record key... 
[14:49] <hatch> frankban correct
[14:50] <frankban> hatch: what placeholder name do we give to new ghost machines?
[14:50] <Makyo> jujugui call in 10
[14:50] <hatch> well I figured we should use the record id's
[14:51] <frankban> hatch: _createMachine does not create a ghost machine and just passes null as modelId: that does not seem correct
[14:51] <frankban> hatch: we should create a ghost machine in the db (e.g. by using an incremental placeholder name, like new1, new2 etc...) and pass the id to both addMachines and placeUnit
[14:53] <frankban> hatch: then, when everything is committed, ecs code already handles replacing the placeholder name with the real one returned by juju-core IIRC
[14:53] <frankban> rogpeppe: cards created/updated
[14:53] <rogpeppe> frankban: cool, ta
[14:54] <rogpeppe> frankban: one thing wasn't clear to me about migrating history: how do you get the commits out of the bzr commit format and into git commit format?
[14:55] <hatch> frankban lets chat after the standup
[14:55] <frankban> rogpeppe: FWIW, while waiting for the migration to be completed, we could start working on 1) moving FakeHomeSuite and 2) moving testing/http.go
[14:55] <frankban> hatch: cool
[14:56] <rogpeppe> frankban: i think the biggest part of this work is creating the stuff in github/juju/testing. changing juju-core to use the new location should be quicker and easier.
[14:56] <frankban> rogpeppe: if the migration is done today then we don't have to do that, because we use the git repository.
[14:57] <rogpeppe> frankban: i don't quite get that. surely we still need to move testing/http.go, because we don't want circular repo deps?
[14:59] <hatch> jujugui call in 1
[14:59] <frankban> rogpeppe: let's talk after the daily standup
[15:05] <bac> redir: that guy working on private charmworld seems to happy, fwiw
[15:06] <redir> bac: nice:)
[15:07] <bac> i blue myself
[15:08] <redir> uh, yeah
[15:08] <bac> http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCQQyCkwAA&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DaxHe_BVY_9c%26feature%3Dkp&ei=0OSNU_ilF6fJsASh-4GIAw&usg=AFQjCNFOnonlQH_qGbp2nJ7-hPjvffx73g&sig2=f0q5Q1iPJJnsMWkBOvB-Yg&bvm=bv.68191837,d.cWc
[15:08] <redir> blue team
[15:08] <bac> nice, url, google
[15:09] <bac> jujugui: sorry, i said "i sat in on the HR presentation.  only took 30 minutes. "
[15:23] <rogpeppe> frankban: are you still busy?
[15:33] <frankban> rogpeppe: done now
[15:33] <frankban> rogpeppe: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
[15:44] <kadams54> hatch: let me know when you get a chance to look at the "stuck in machine view" card. I'm also looking for more work… maybe getting started on the document Luca and Spencer created, turning those into cards/bugs?
[15:46] <hatch> kadams54 looking
[15:48] <hatch> kadams54 I am pretty sure that issue was the UI equivalent to this bug https://bugs.launchpad.net/juju-gui/+bug/1319549
[15:48] <hatch> kadams54 so maybe if you could try and dupe this in the UI if not, comment on this bug that it's not reproducible in the UI
[15:49] <hatch> and that can be this card
[15:49] <hatch> I haven't had a chance to look at the list from UX but I want to be careful that any changes there don't push the release back or cause conflicts for my branch
[15:51] <kadams54> hatch: Sure. First step would be to get the items in the doc turned into bugs and cards. No code changes.
[15:52] <kadams54> hatch: I don't think this card is about Chrome freezing. I remember we both had that problem. The way I read this card is that the tabs to switch between Service and Machine Views stop working. (Which has also happened to me in the past.)
[15:52] <kadams54> But I'll investigate https://bugs.launchpad.net/juju-gui/+bug/1319549 nonetheless.
[15:53] <hatch> kadams54 yeah I remember that - but when the tabs stopped working the whole UI was locked - I don't remember if refreshing worked though...
[15:53] <kadams54> No, refreshing did not work
[15:53] <kadams54> It wasn't just the Chrome tab, but all of Chrome
[15:53] <kadams54> I had to kill -9 it when that happened.
[15:53] <kadams54> It was bad.
[15:53] <hatch> ahh right right
[15:54] <kadams54> But I've also seen where the tabs stop working - I can still do stuff in MV, just can't get out of it. Usually due to an uncaught exception.
[15:54] <hatch> hmm yeah I also remember that
[15:55] <hatch> I cannot remember how to reproduce - I created a friday card about cards which are incomplete
[15:55]  * redir may have to put the a/c units in the windoes
[15:55] <redir> real soon now
[15:57] <hatch> redir what? They aren't built into the wall?
[15:57] <redir> hatch: bwahaha
[15:57] <redir> not in buildings from the 19th century
[15:57] <hatch> lol serious - all condo's and apartments here have them cut in the wall
[15:58] <hatch> ahh maybe they don't want to cut into old buildings
[15:58] <hatch> :)
[15:58] <redir> hatch: yeah, historic area
[15:58]  * hatch hands you a saw
[15:58] <hatch> git-r-dun! 
[15:58] <redir> hatch: brick buildings.
[15:59]  * hatch hands you a brick saw
[15:59] <redir> heh
[15:59] <redir> going to 30 today
[15:59] <hatch> yikes - I've had the AC on for a bit now - but it only turns on during the afternoon still 
[15:59] <hatch> my limit is about 25C
[16:00] <hatch> any hotter and I dig a hole in the garden and lay in it
[16:01] <kadams54> It's an almost perfect 23C here
[16:01] <kadams54> With a breeze
[16:01] <kadams54> Too bad the mosquitoes are TERRIBLE!
[16:02] <hatch> frankban card created in Project 1 fyi
[16:02] <hatch> kadams54 ahh nice, we are 19 now which is about perfect. very few biting bugs still, the flies are out in force though
[16:03] <hatch> kadams54 do they spray for mosquitos there?
[16:03] <kadams54> I don't believe so, no.
[16:03] <kadams54> We've had some heavy rains recently and it seems like they really came out in force afterwards.
[16:03] <hatch> darn - they do it here - we have a bunch of standing water in the ditches and stuff
[16:03] <hatch> I -think- it helps
[16:03] <hatch> ahh yeah I bet
[16:03] <kadams54> We're going to bomb the yard
[16:03] <hatch> youtube it!!!!
[16:06] <kadams54> I don't think it's going to be that dramatic ;-)
[16:06] <frankban> hatch: thanks
[16:08] <hatch> kadams54 then you're not using enough explosive! 
[16:13] <hatch> ugh the poplars are seeding
[16:13] <hatch> bloody white fluffs everywhere
[16:13] <hatch> they are nice big trees but boy do they make a mess
[16:14] <hatch> pretty much the worst in-yard tree anyone could plant haha
[16:17] <hatch> kadams54 thanks for doing the review and qa on Huw's branch - if he can land it after making your changes you can ":+1: with above mentioned changes" or something along those lines
[16:18] <kadams54> OK, updated my comment to clarify
[16:24] <hatch> working across timezones can be challenging sometimes :)
[16:33] <kadams54> hatch: Commented on https://bugs.launchpad.net/juju-gui/+bug/1319549 - I can't reproduce in develop using the console commands.
[16:34] <kadams54> I'm tempted to remove my current card - we can always add it back in if needed.
[16:34] <hatch> kadams54 thanks, and yeah I agree
[16:54] <rogpeppe> frankban: https://github.com/juju/testing/pull/9
[16:54] <frankban> rogpeppe: looking
[16:55] <rogpeppe> frankban: i haven't changed one byte :-)
[16:57] <frankban> rogpeppe: :-) LGTM
[16:57] <rogpeppe> frankban: thanks
[17:23] <hatch> kadams54 have you found something to do?
[17:23] <kadams54> Yes.
[17:23] <kadams54> Eat lunch
[17:24] <redir> rogpeppe: given a current clone of juju-core + godeps -u ... should the full test suite be passing?
[17:24] <kadams54> hatch: But that's wrapping up :-) Got any suggestions? If not, I'll work on going through the feedback from Luca and Spencer.
[17:25] <rogpeppe> redir: i think so, but it's always a bit fragile. what's failing for you?
[17:25] <redir> rogpeppe: a bunch, but hard to tell there is no summary
[17:25] <redir> dumping into a file for review
[17:25] <rogpeppe> redir: could you paste the full output?>
[17:26] <hatch> kadams54 yeah that might be best - there are other cards but I really want to get my branch landed first
[17:26] <redir> rogpeppe: yes
[17:33] <redir> rogpeppe: not so bad without all the logs. summary: http://paste.ubuntu.com/7581747/
[17:33] <redir> http://paste.ubuntu.com/7581756/
[17:33] <redir> full output ^^
[17:37] <redir> I like the jujubot avatar
[17:39] <rogpeppe> redir: hmm, i don't recognise those failures
[17:40] <redir> boo
[17:40] <rogpeppe> redir: i have to stop for the day, but one thing to look into: are you using the right mongod?
[17:40] <redir> rogpeppe: prolly n ot
[17:40] <hatch> yuss I found some cascading failures
[17:40] <redir> but I think I have the charmworld one today
[17:40] <hatch> I can get to 50% now without a failure lol
[17:40] <rogpeppe> redir: some folks on #juju-dev should be able to help
[17:40] <redir> hatch: *applause*
[17:40] <rogpeppe> g'night all
[17:40] <redir> rogpeppe: k tx. have a great eve
[17:47] <hatch> kadams54 maybe you could also give Makyo a hand with his CSS issues (if they still exist)
[17:48] <Makyo> hatch, kadams54 it appears to be a thing with the sticky headers taking a bit to generate, not what I'd thought.
[17:48] <kadams54> ok
[17:48] <Makyo> It allocates space for them, then generates them at the end of loading.
[17:54] <hatch> down to 107 failures *sigh*
[18:57] <bac> jujugui: anyone have access to safari to do a quick test?
[18:58] <hatch> bac yep
[18:59] <bac> cool, hatch, can you try connecting to my juju-gui at https://ec2-107-22-137-117.compute-1.amazonaws.com/ with safari?
[18:59] <hatch> bac ok I get the ssl warning
[18:59] <bac> hatch: i get 'connecting to the juju environment' but it hangs there
[19:00] <bac> ssl warning or certificate warning?
[19:00] <hatch> yeah this is a known bug
[19:00] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1322596
[19:01] <bac> thanks hatch, hadn't seen that bug.
[19:01] <hatch> now you have :)
[19:01] <bac> well, in that case, juju-quickstart on os x is now working.  whee!
[19:02] <hatch> yippeee
[19:02] <bac> must be packaged
[19:02] <bac> hatch: you still using atom at all?
[19:02] <hatch> bac nope back to sublime
[19:03] <hatch> I probably won't switch from sublime to anything for quite a while
[19:03]  * redir applauds
[19:03] <redir> and you wrote it swiftly in swift!
[19:04] <hatch> lol what
[19:04]  * hatch thinks redir is drunk
[19:04] <redir> lolwut
[19:04] <redir> redir wishes
[19:04] <redir> more just trying to do stuff but can't blame in bzr in sublime 
[19:05]  * redir means praise or annotate
[19:06] <hatch> haha, I mean why are you applauding me for using sublime?
[19:20] <redir> hatch: juju quickstart on osx
[19:21]  * redir applauds bac for juju-quickstat on osx, hatch
[19:21]  * redir backs up GOPATH and starts fresh...
[19:22] <hatch> :)
[19:22] <bac> redir: thanks.  how about a review and qa?
[19:22] <redir> ಠ_ಠ
[19:23] <redir> bac: OK
[19:23] <redir> need to get the mac back out
[19:24] <redir> moved it to put the AC in
[19:25]  * redir now sees his notebook cpu at 48C instead of 78C
[19:26] <hatch> haha that's probably for the best
[19:26] <bac> redir: i'm doing QA on linux to ensure i didn't mess up there.
[19:26] <bac> redir: will bug you shortly
[19:28] <redir> k
[19:34] <Makyo> Man, another stupid branch with a one-line fix.  I guess it's good that we had all these useful methods in there, just need to know where to use them.
[19:38] <Makyo> jujugui little tiny PR https://github.com/juju/juju-gui/pull/361
[19:39] <hatch> Makyo that's not guna work :(
[19:40] <hatch> the reason is that we dont' want to re-render the whole sectionA every time the state changes
[19:40] <hatch> we only want to do that when the component changes 
[19:41] <hatch> I've commented in kind in the PR
[19:43] <Makyo> Fuck.
[19:43] <Makyo> This state thing is an enormous mess.
[19:43] <hatch> sorry - I can take another look at it, I think I am on my final test (which of course is causing huge issues)
[19:43] <hatch> just need to grab some food first
[19:43] <Makyo> We switch everything over to views, then decide we can't treat them like views.  We need to destroy what's there in order to render what needs to be there, but somehow need to do it without destroying what's there?
[19:44] <Makyo> I worked through lunch too, I'm gonna take a break.  We can talk after.
[19:46] <hatch> sure, ping when you're back
[19:49] <bac> redir: https://codereview.appspot.com/105810043 por favor
[19:50] <redir> k
[19:52] <Makyo> hatch, alright, fed and calmer.  Sorry for the outburst.
[19:52] <hatch> tis O K :)
[19:54] <redir> Mayko channel the  stateless whisperer
[19:54] <redir> roy would be proud
[19:55] <Makyo> So, the problem is that changeState doesn't clean up the inspector or the charmbrowser when the state changes.  All emptySectionA does is clean up lingering inspectors and charmbrowsers.  We need to be able to either destroy, or have the subapp be able to clean up without destroying.
[19:56] <Makyo> Right now, the state code and its events take approximately 750ms to change state.  Rendering is fast, sticky headers are quick, and the spinner is negligible.  In all, it winds up being about 780ms.
[19:56] <hatch> wow, why does it take so long?
[19:57] <hatch> it should be damn near instant
[20:00] <Makyo> It's either state or navigate that's being such a drag.
[20:01] <hatch> ok that's definitely not acceptable because with everything running through state for user interactions it needs to feel instant
[20:01] <Makyo> But either way, the inspector/charmbrowser needs to be cleaned up on navigate.  The spacing is caused by lingering elements.
[20:01] <Makyo> Let me prefix everything with timestamps and I can get back to you.
[20:02] <hatch> when it switches components it should be calling the empty bit
[20:03] <hatch> oh great databinding doesn't work on the il flag for the unit details
[20:05] <redir> cloning juju with git from gh is so way faster than bzr from lp
[20:08] <hatch> redir are the repos the same size?
[20:08] <hatch> I have mixed experience with github and network speed
[20:08] <redir> well it is juju from today in both
[20:12] <Makyo> hatch, it's looking like navigate, not state.  Almost a full second to get through navigating.
[20:12] <hatch> hmm ok so...
[20:12] <hatch> hmm
[20:12] <redir> hatch: roughly 19700 commits 
[20:12] <redir> bot thso ...
[20:14] <hatch> Makyo ok so we need to track that down I guess
[20:14] <hatch> it has to be something from pretty recently
[20:14] <hatch> it didn't used to do that
[20:14] <Makyo> It did, it was just hidden by the fact that we didn't cache anything.
[20:15] <hatch> I mean before the switch over
[20:15] <Makyo> To il?
[20:15] <hatch> yeah
[20:15] <hatch> I wonder if our navigate modifications don't mesh with the state stuff
[20:15] <Makyo> Because that time difference was clicking the home button from a search, not dismissing the inspector.  Can poke around, though.
[20:16] <redir> s/bot thso/both so
[20:16] <hatch> Makyo right but I think that the same delay happens when switching between ghost and service inspectors too
[20:17] <Makyo> Okay.  Hmm. Maybe in the ns-routing-app-ext?
[20:17] <Makyo> Conflicting with state, I mean
[20:18] <hatch> yeah that's what I mean
[20:19] <Makyo> Okay, I'll dig in there.
[20:22] <hatch> I'm fairly close to getting this monstrosity of a branch up for PR then I can lend a hand
[20:31] <hatch> Makyo when you navigate around the charmbrowser and the url changes, does it change really fast, THEN hang?
[20:31] <Makyo> hatch, I put console loggers in and everything's twice as fast.  It's my new solution.
[20:32] <hatch> rofl
[20:32] <Makyo> URL changes quickly, then it slows down, seems to be between either _navigate and _dispatch in ns-routing or _cleanup and _loadCurated in charmbrowser
[20:33] <Makyo> But seriously, I'm getting half the times I was before, to the point where it looks almost fixed.
[20:34] <Makyo> I'll keep digging, the sticky headers are definitely part of the problem, almost 100 ms
[20:35] <Makyo> hatch, here's the times I'm looking at https://gist.github.com/makyo/0cf154d2d9996de7d45b
[20:37] <hatch> ahh so maybe because we aren't emptying out the token list soon enough before it calls _loadCurated
[20:37] <hatch> there is a _cleanUp method in there
[20:38] <hatch> maybe it can be purposed to fix that up
[20:38] <hatch> (almost PR'ing)
[20:38] <Makyo> Yeah, I'm poking around.
[20:38] <Makyo> Let me know when you're ready, I owe you a review.
[20:40] <hatch> Makyo you mean this 1900 line one? https://github.com/juju/juju-gui/pull/362
[20:40] <hatch> :)
[20:40] <hatch> Makyo maybe we get this one landed and then work from it?
[20:40] <hatch> then we are working with more 'final' type code
[20:41] <Makyo> Yeah, totally.  I'd rather rebase than not.
[20:41] <Makyo> Or just start over and trash this branch of mine
[20:42] <hatch> we probably should have done state and then il
[20:42] <hatch> merging them was a bad idea it's looking like
[20:42] <hatch> live and learn I suppose :)
[20:43] <hatch> kadams54 I re-sorted your new cards - cards after the il green card are required for relase
[20:43] <Makyo> Yeah.  Two flags is a good limit, but each flag could have been more limited in scope.  State, then il.  ECS, then mv.
[20:43] <hatch> if you disagree with any of my moves feel free to lemme know
[20:44] <hatch> Makyo yeah good point
[20:44] <hatch> I suppose I'll create a card friday to discuss how we got here and what we can do in the future to make sure it doesn't happen again
[20:45] <hatch> it took almost 3 full days to remove the il flag haha, that's no good :)
[20:45] <redir> bac: LGTM
[20:48] <bac> thanks redir
[20:52] <rick_h_> feature flags always seem to take a bit. We've had a few chats on trying to help with that but I don't think we did all the stuff we've mentinoed
[20:52] <rick_h_> mentioned
[20:52] <hatch> rick_h_ wb
[20:52] <hatch> :)
[20:52] <rick_h_> :P
[20:52] <hatch> I created a friday card - just so we can spitball some ideas 
[20:52] <rick_h_> coolio
[20:52] <hatch> while it's still fresh
[20:53]  * rick_h_ loads up leankit for the first time
[20:55] <rick_h_> hatch: why do flags need to be more than 2 char? it's always flags.il ?
[20:55] <hatch> rick_h_ there were instances (albeit not many) where grepping flags.il wasn't enough
[20:56] <hatch> as in, flags: { il: ...
[20:56] <hatch> very hard to find
[20:56] <hatch> it never should have passed review...but things happen
[20:56] <rick_h_> then il:  didn't work out? 
[20:57] <rick_h_> yea, I guess when I suggested it I was thinking it'd be flags.il and easy to spot
[20:57] <hatch> il : 
[20:57] <hatch> that did
[20:57] <hatch> :)
[20:57] <hatch> but yeah I figured that because the urls are often 'cached' we could stand to use more grep-able ones and not lose much on the typing
[20:58] <hatch> this isn't exactly a problem, but did waste time which could have been avoided if it was something wako like 'ispl' or something easy to grep for 
[21:00] <hatch> rick_h_ mv is probably not going to be as much of an issue because m and v aren't usually beside each other in English, whereas il....well....heh
[21:00] <rick_h_> yea
[21:00] <rick_h_> gotcha
[21:04] <hatch> Makyo are you reviewing/qaing that branch? 
[21:04] <hatch> the il one
[21:04] <Makyo> hatch, yeah
[21:04] <hatch> ok cool
[21:04] <hatch> thx
[21:05] <hatch> I'm not looking forward to the databinding bug
[21:05] <Makyo> -1513!  I like it.
[21:05] <hatch> Makyo there is probably at least another 1000 in there which are left in but not used 
[21:05] <rick_h_> hatch: which databinding bug?
[21:05] <hatch> :)
[21:06] <hatch> rick_h_ somewhere in the il work, databinding stopped working for the unit details breakout panel
[21:06] <hatch> I'm guessing it has something to do when it got moved to the right.....but yeah....it's broken
[21:07] <hatch> can we switch to react yet? kehehe (kick a man when he's down)
[21:11] <Makyo> Fired...you are...no job.  Anymore.
[21:11] <Makyo> hatch, going to walk dogs, I'm getting stomped.  Promise I'm reviewing.
[21:12] <hatch> :) np take your time
[21:12] <hatch> these past few days have not been enjoyable
[21:15] <rick_h_> bac: can you link that bug and fix to hazmat in case he's interested please? 
[21:15]  * rick_h_ goes back to vacation mode uploading tons of pictures
[21:16] <rick_h_> new camera means lots and lots of pics
[21:26] <hatch> Makyo I just updated the PR with another commit so if you had pulled it down and were QA'ing you'll want to pull again
[21:44] <Makyo> hatch, alright, thanks
[21:44] <Makyo> rick_h_, awesome
[21:59] <Makyo> hatch, QA looks good.  Good to get rid of all that code.
[21:59] <hatch> yay!
[21:59] <hatch> and CI passed
[22:26] <hatch> Makyo so can i land it?
[22:26] <Makyo> hatch, crap, yeah, sorry!
[22:26] <Makyo> Forgot.
[22:26] <hatch> haha ok
[22:52] <hatch> Makyo ok so once this merges in we will use that as the source of truth
[22:52] <Makyo> hatch, +a lot
[22:54] <Makyo> Reboot for updates
[23:00] <hatch> Makyo so when I do a search then click back, the url changes and the UI updates, hangs for about a second, then snaps to the actual cached results 
[23:00] <hatch> huwshimi morning
[23:00] <huwshimi> Morning
[23:00] <hatch> I had a chat with frankban about the bug and we came up with a good fix for it - he will be starting on it at his start of day
[23:01] <Makyo> hatch, yeah.  That second is spent on a couple of operations.  Finishing routing, building tokens, and building sticky headers.
[23:02] <Makyo> All of that was there originally, just hidden by the lack of a cache.
[23:02] <hatch> Makyo I'm thinking there is some problem in the charmbrowser because it's getting the operation to switch view types, then hangs
[23:02] <Makyo> hatch, it's not hanging, it's doing plenty of work, it's just not very efficient work.
[23:02] <hatch> haha right, hanging to the user I mean
[23:02] <Makyo> Yeah :)
[23:03] <Makyo> One solution would be for the spinner to stick around and properly indicate loading.
[23:03] <Makyo> That done, we could work on efficiency.
[23:03] <Makyo> As two iterations, I mean.  The spinner wouldn't be the fix.
[23:03] <hatch> it looks like it only hangs when going from search to curated
[23:03] <Makyo> Search doesn't have as many sticky headers.
[23:03] <hatch> 1 less :)
[23:03] <rick_h_> huh? there's only 3 sticky headers
[23:04] <hatch> damnit you just pop in here
[23:04] <hatch> lol
[23:04] <Makyo> Yeah, I just mean that search is less complicated. 
[23:04] <rick_h_> the sticky headers is very light, shouldn't be a perf issue. Never has been and we did have a working cache when it was working
[23:04] <hatch> like on the show 'The Office' haha
[23:04] <huwshimi> hatch: Ah great, thanks for chasing that up.
[23:04] <rick_h_> hatch: heh, yea bad timing. Tired and crabby and I look and go 'wtf'
[23:05] <hatch> huwshimi hopefully we'll be ready for your start of day tomorrow
[23:05] <hatch> to unblock you
[23:05] <rick_h_> Makyo: so the thing is that the result rendering isn't async any more since it's not part of an async ajax call? 
[23:05] <huwshimi> hatch: Thanks. I've been landing some chunks of work from that branch anyway
[23:05] <rick_h_> and has turned blockign?
[23:06] <Makyo> rick_h_, It's hard to pick apart, but yes, I think so.  The combination of load and render (and all the component steps) seem to be tripping over themselves.  Here's the timings: https://gist.github.com/makyo/0cf154d2d9996de7d45b
[23:06] <hatch> now that we have a more stable base to work from can take a peek in the AM to give you a break Makyo 
[23:06] <Makyo> Load takes a while, the two render steps take a while.
[23:07] <rick_h_> 400ms in routing?
[23:08] <rick_h_> Makyo: is this taking into account double dispatch? e.g. are these times doubled up somewhere?
[23:09] <Makyo> rick_h_, no, that's the entire log for clicking 'home' from search results (i.e.: loading curated from cache)
[23:09] <rick_h_> hatch: huwshimi is the issue with the padding in the categories on comingsoon known?
[23:09] <hatch> rick_h_ refresh
[23:09] <hatch> kadams54 landed a fix yesterday
[23:10] <huwshimi> hatch: It still happens for me
[23:10] <hatch> hmm comingsoon might need a clean-all
[23:10] <rick_h_> hatch: cleared browser cache reloaded and still has an issue
[23:10] <rick_h_> ok
[23:11] <rick_h_> ok, so that's not a full second but is annoying. Definitely need to show a loader and hide the UI while it updates. 
[23:13] <rick_h_> yea, css on comingsoon is toast. inspector is a mess
[23:14] <Makyo> rick_h_, yeah.  At the very least, it needs the spinner while it's churning.  Optimal fix would be to get rid of the delay, but that's proving tough to track down.
[23:14] <rick_h_> Makyo: yes, I think making the UI transition smooth is a good easy goal
[23:14] <rick_h_> Makyo: I think that you're right that there's a tree of code to take the models, create the tokens, etc and it's not instant
[23:15] <rick_h_> is kadams54 around today? I don't see any card on the board for him?
[23:20] <hatch> lemme check develop
[23:20] <hatch> yeah local develop looks fine
[23:20] <hatch> and comingsoon is broken
[23:20] <hatch> so looks like it could use a kick
[23:28] <hatch> rick_h_ he was - last I heard he was reading the comments from luca and making cards for them
[23:31] <huwshimi> Can anyone else not get into canonical IRC?
[23:32] <hatch> huwshimi I'm in now
[23:33] <huwshimi> hatch: What happens if you try to reconnect?
[23:33] <hatch> works fine
[23:33] <hatch> check that you accept the ssl cert
[23:34] <huwshimi> hmm... it isn't asking me to, it just says it has expired.
[23:35] <hatch> might be your client?
[23:36] <huwshimi> hatch: It doesn't even work with "accept invalid ssl certificate"
[23:36] <hatch> hmm odd
[23:37] <huwshimi> worked fine up until now.
[23:38] <hatch> yeah works fine for me, not sure what's up
[23:42] <huwshimi> Oh, I did just do some Ubuntu updates which included some ssl packages. Might reboot.
[23:44] <huwshimi> Nope
[23:45] <huwshimi> And now all my builds are failing :)
[23:45] <hatch> haha
[23:45] <hatch> yeah I saw that
[23:54] <huwshimi> hatch: It's "origin/pr/360/merge" to kick of a new "shipit"?
[23:55] <huwshimi> (for pr #360)
[23:55] <hatch> nope just delete the merge request accepted msg
[23:55] <huwshimi> ah
[23:55] <hatch> that other method is for the non-merge case
[23:56] <huwshimi> oh ok