[00:36]  * hazmat looks at charmworld indexing code..
[00:52] <rick_h_> hazmat: run away! :)
[00:53] <rick_h_> hazmat: what's the issue?
[02:06] <hazmat> rick_h_, just curious about the mapping explosion you mentioned
[02:06] <hazmat> rick_h_, that's not normal
[02:07] <rick_h_> hazmat: yea, it's hard to debug without knowing what all went on during them bringing up the new ES instance and how they tried to correct it
[02:07] <hazmat> also just getting familiar with the latest code version, it looks better
[02:07] <rick_h_> hazmat: it's still a 'theory' on that's the issue
[02:08] <rick_h_> yea, spent some time cleaning things. Learning more about ES, getting ES to do better scoring, filtering on scoring, etc. 
[02:08] <rick_h_> stuff we should have spent the time to get into ages ago
[02:20] <hazmat> rick_h_, how much pain would it be to tighten up results on search api... 184k for 20 results.. on charms.. ie. not serialize every charm on a result, but instead have the gui fetch details beyond collections.
[02:22] <hazmat> not needed.. just curious.. 
[02:23] <rick_h_> hazmat: not sure, it's on the todo list to look at. Bundles are painful in results right now and it's getting to be something we want to address
[02:30] <rick_h_> hazmat: just looking I bet 90% of that is changelogs and config options. Wonder if we can lazy fetch those and still get that nice instant load when clicking a charm (though there's a know bug #1290580)
[02:30] <_mup_> Bug #1290580: Viewing charm details makes another request even though it should be cached <juju-gui:New> <https://launchpad.net/bugs/1290580>
[02:30] <rick_h_> hazmat: so I'd say we could cut it down a big chunk easily
[02:36]  * rick_h_ runs away for the night
[09:22] <rogpeppe> frankban: reviewed https://codereview.appspot.com/77420043/
[09:22] <rogpeppe> frankban: sorry it took a while
[09:25] <frankban> rogpeppe: thanks!, looking at your review, looking at it. I am not sure about "won't m.SupportedContainers still be the expected (nil) value if SupportedContainersKnown is false?"
[09:26] <frankban> rogpeppe: the idea is: supported unknown -> nil, supported known -> [] or [lxc] ... it seems to work like this
[09:27] <rogpeppe> frankban: hmm, i think it would probably be better not to rely on nil vs [] like that
[09:28] <rogpeppe> frankban: and to expose SupportedContainersKnown in the allwatcher
[09:30] <frankban> rogpeppe: ok, I'll make this change, so basically I'll just add bith fields in the initial structure
[09:30] <rogpeppe> frankban: thanks
[09:32] <frankban> rogpeppe: re jobs I fugured out we would need it to know where it is possible to host units, so, if I am not missing something, I'd be inclined to keep that included
[09:32] <rogpeppe> frankban: yeah, and when we've got HA, it will be useful to know which machines are state servers, i think
[09:33] <frankban> rogpeppe: that's something we also need to pass in the addMachines API, so it's not completely internal, yeah, and for HA too
[09:33] <frankban> cool
[09:33] <frankban> oh, totally missed params.Alive. cool
[09:40] <frankban> fwereade: morning, I am working on a branch which adds more fields to the mega-watcher for machines. One of those fields is Jobs: it seems good to have since with that the GUI can safely know where it is possible to host units, and it can be valuable also from the HA perspective. It is also something we already need to handle when using the addMachines API. How does it sound?
[09:48] <frankban> rogpeppe: re machineJobsFromParams, I guess you intended paramsFromMachineJobs, right?
[09:50] <rogpeppe> frankban: perhaps paramsJobsFromJobs ?
[09:50] <frankban> rogpeppe: ok
[09:57] <fwereade> frankban, I think +1 to that, but I have a minor concern which is drift between the gui and the cli -- would you add them to the status API as well, please?
[09:58] <frankban> fwereade: sure, if you agree I'll create another card, so that the current one can land and we are unblocked
[09:59] <fwereade> frankban, that's great, thanks
[09:59] <frankban> fwereade: cool thank you
[10:07] <frankban> fwereade, rogpeppe: after merging from trunk, I am encountering "launchpad.net/juju-core/testing/testbase.PatchEnvPathPrepend(0): not defined" and similar when testing juju-core
[10:08] <frankban> also testbase.Restorer(0) is not defined
[10:09] <rogpeppe> frankban: have you updated your dependencies?
[10:09] <rogpeppe> frankban: (in the juju-core root, run godeps -u dependencies.tsv)
[10:09] <frankban> rogpeppe: this is after running godeps -u dependencies.tsv
[10:09] <frankban> yeah
[10:09] <rogpeppe> frankban: what's the actual compiler output?
[10:12] <frankban> rogpeppe: core compiles well, and the when I launch tests I see this -> http://pastebin.ubuntu.com/7129851/
[10:12] <frankban> (also in trunk)
[10:14] <rogpeppe> frankban: that's odd - there are no file:line messages
[10:14] <rogpeppe> frankban: if you cd to cloudinit and run go test, what do you see
[10:14] <rogpeppe> ?
[10:17] <frankban> rogpeppe: it seems I fixed this by removing pkg/linux_amd64/
[10:17] <rogpeppe> frankban: ah
[10:17] <rogpeppe> frankban: that can happen
[10:18] <frankban> rogpeppe: yeah, thank you
[10:40] <frankban> fwereade: IIUC, the cli status structure is in cmd/juju/machineStatus. is this correct? If so, since MachineInfo will also include SupportedContainers and SupportedContainersKnown, do you want those to be included there too?
[10:41]  * fwereade reads code
[10:43] <fwereade> frankban, hmm, so the deal with supportedcontainers is as follows
[10:44] <fwereade> frankban, we don't know what containers can be added until we've actually got a machine agent running, and able to check
[10:44] <fwereade> frankban, so to begin with we have the list empty, and known false, and we just let you do whatever you like
[10:44] <fwereade> frankban, and any bad requests will fail at provisioning time
[10:45] <fwereade> frankban, later we set known to true, and at the point the supportedcontainers list is actually accurate
[10:45] <frankban> fwereade: yeah I figured that out
[10:45] <fwereade> frankban, *just* exposing those 2 fields doesn't seem like an ideal way of informing users though
[10:45] <fwereade> frankban, sorry, I had to remind myself :)
[10:46] <frankban> fwereade: np, thanks for making that explicit
[10:46] <fwereade> frankban, oh hell standup
[10:46] <frankban> fwereade: so in theory, for `juju status`, we could only show supported containers after they are known
[10:47] <fwereade> frankban, you know what? don't worry about CLI status, but please file a bug against juju-core and we'll figure out priority and appropriate response
[10:47] <fwereade> frankban, status is bloated enough already
[10:48] <fwereade> frankban, at some stage we'll get around to adding flags to filter fields
[10:48] <fwereade> frankban, but just adding them willy-nilly isn't such a great idea
[10:48] <frankban> fwereade: sounds good, thanks
[10:48] <frankban> agreed
[11:24] <frankban> rogpeppe: branch updated and re-proposed
[12:00] <rick_h_> frankban: if you get a minute can you review hatch's branch here please? https://github.com/juju/juju-gui/pull/188
[12:00] <rick_h_> frankban: I started but got pulled away yesterday. Figure I'll trade you a review :)
[12:00] <frankban> rick_h_: sure, will do
[13:14] <rogpeppe> frankban: LGTM
[13:14] <frankban> rogpeppe: \o/ thanks, approving
[13:16] <bac> hi frankban, did you see the issue about quickstart on raring wrt urwid?
[13:17] <frankban> bac: no, but it would not work in raring, apparently we do not support raring, it is disabled in the juju stable PPA, so there is no urwid backport for raring in there. I presume an old urwid would be used resulting in a nice python crash. 
[13:18] <bac> frankban: you are correct
[13:19] <bac> frankban: so do we state somewhere that raring is not supported?
[13:19] <rick_h_> frankban: ok if we don't support it then I'm game for documenting and doing whatever we can to prevent installing it
[13:19] <frankban> bac: to be clear, the package works on precise, quantal, saucy and trusty -> the juju stable PPA includes urwid backports for precise and quantal. saucy and trusty already have the right urwid version
[13:20] <bac> frankban: https://launchpad.net/~juju/+archive/stable/+packages shows that we have a juju-quickstart PPA for raring
[13:20] <bac> frankban: so, i guess we either need to delete it or supply the urwid backport, no?
[13:21] <frankban> bac, rick_h_: requested deletion of juju-quickstart 1.0.0+bzr48+ppa10~ubuntu13.04.1
[13:21] <frankban> that's also an old version
[13:21] <bac> rick_h_, frankban: perhaps i should take my head off the card and let frankban pict it up.
[13:22] <rick_h_> bac: fine with me. I just want to see what we can do to prevent new users (kadams in this case) from following the docs but not having things work. 
[13:22] <frankban> bac, rick_h_: ok, that's done. bac: you could also complete the card just adding that piece of documentation
[13:22] <bac> frankban: ok, sure.  to the quickstart readme you mean?
[13:23] <bac> rick_h_: but we are in a bit of a pickle since our juju-gui vagrant image is only raring
[13:23] <kadams54> Seems like we should also update the vagrant image in juju-gui?
[13:23] <kadams54> bac: hah, yeah… beat me to it.
[13:23]  * rick_h_ goes to check, is raring EOL?
[13:23] <frankban> rick_h_: since I deleted the PPA package, the docs would not work at all (juju-quickstart package not found) if you are in raring. 
[13:23] <frankban> bac: let me check
[13:24] <rick_h_> frankban: bac ok sorry, yes raring is EOL and so I think updating the vagrant image is ok
[13:24] <bac> rick_h_: ok, i'll do that too under this card
[13:26] <frankban> bac: yeah, README.rst and the quickstart description in launchpad seem the right places to put that information. It would be nice to have both pip and apt-get instructions added to those. Note that README.rst is also used to display the nice description in https://pypi.python.org/pypi/juju-quickstart
[13:29] <bac> frankban: it seems odd that we're supporting quantal but not raring.  should we remove support for quantal leaving precise (LTS), saucy (current) and trusty (beta) ?
[13:29] <bac> that's a more consistent story
[13:35] <frankban> bac: +1 quantal and not raring is weird, let's document the new story and I'll exclude quantal in my next build. I guess I'll leave the current quantal release in the stable PPA, but updates will be only precise/saucy/trusty. how does it sound?
[13:35] <bac> perfect
[13:35] <frankban> cool bac thanks
[13:40] <bac> frankban: if quickstart is installed via pip should we tell them to use:
[13:40] <bac> sudo pip install urwid juju-quickstart
[13:40] <bac> ?
[13:40] <frankban> pip install juju-quickstart should be sufficient
[13:40] <bac> cool
[13:41] <frankban> bac: see comments in requirements.pip
[13:42] <frankban> bac: also, in trusty installing the PPA is not required
[13:43] <bac> frankban: right, just for precise
[13:43] <frankban> bac: precise and saucy
[13:43] <bac> er?
[13:43] <bac> oh, right
[13:45] <frankban> is github having difficulties also in the US?
[13:46] <hatch> frankban "see below" in your review.....did you forget to hit send on a comment? :)
[13:47] <frankban> hatch: no, I did not forget, github is down here :-/
[13:47] <hatch> ohh darn ok
[13:47] <hatch> no problem
[13:48] <bac> frankban: can you look at the doc change at https://codereview.appspot.com/78830044 ?
[13:48] <frankban> and now it's up again, they finished to recompile rubu
[13:48] <frankban> ruby even
[13:49] <frankban> bac: sure
[13:51] <frankban> bac: done
[13:52] <bac> frankban: double spaces don't get a <shrug>? :)
[13:56] <frankban> bac: :-) double spaces are serious things to deal with
[13:57] <bac> agreed and done
[13:58] <bac> rick_h_: were you aware there are 85 members of ~charmers?  80 of them are in ~inactive-charmers.  i'm a little surprised about the numbers.
[13:59] <rick_h_> bac: yea, there's some discussion on how to clean that up at some point
[13:59] <bac> rm ~inactive-charmers
[13:59] <bac> or create an ~active-charmers and use that group for permissions
[14:00] <rick_h_> bac: yea I recall an email thread where marcoceppi had a good reason for not doing that
[14:00] <marcoceppi> bac: I once removed in-active charmers from charmers
[14:00] <marcoceppi> and I got yelled at
[14:01] <marcoceppi> My goal is to get them seperated one day, I just don't have the time for it
[14:01] <rick_h_> bac: https://pastebin.canonical.com/106930/
[14:01] <rick_h_> is the end of the thread that I found
[14:01] <rick_h_> bac: so know issue and discussion taking place but not a great solution atm to just remove inactives
[14:02] <frankban> fwereade: filed bug 1295682
[14:02] <_mup_> Bug #1295682: Handle missing fields in CLI status <juju-core:New> <https://launchpad.net/bugs/1295682>
[14:02] <frankban> hatch: I'll finish your review after the call, grabbing some food now, ok?
[14:02]  * marcoceppi should get back on that thread and get some action items going
[14:02] <fwereade> frankban, thanks
[14:09]  * frankban lunches
[14:16] <bac> rick_h_: fyi, i found a bug on staging regarding bundle featuring.  should be a trivial fix.  made card.
[14:16] <hatch> frankban yeah no problem
[14:17] <bac> marcoceppi: we've added UI on staging.charmworld.com for deleting charms and deleting and featuring bundles.  it'll probably be released to production next week but thought you might want to see it on staging first.
[14:17] <bac> jcastro: ^^
[14:20] <rick_h_> bac: cool thanks for the heads up
[14:34] <hatch> so hows everyones morning
[14:36] <jcastro> bac, that is awesome, thanks!
[14:38] <rick_h_> jcastro: marcoceppi realize this deletes it from charmworld, but not launchpad/etc. So it will just reingest if you hit delete
[14:38] <jcastro> all I really need is the ability to feature/unfeature bundles
[14:39] <rick_h_> jcastro: yea, that's there as well
[14:43] <bac> jcastro: you can feature/unfeature bundles if they are owned by ~charmers
[14:43] <rick_h_> bac: yea, he just means the links for his use
[14:43] <rick_h_> generating urls isn't much fun :)
[14:44] <bac> i don't understand
[14:44] <rick_h_> bac: production doens't have the feature/unfeature links
[14:44] <rick_h_> bac: jcastro misses those, but you've added them on staging
[14:44] <bac> rick_h_: you saw that i declined the interview for next week
[14:45] <rick_h_> bac: yes, my fault. Wasn't thinking about your time away
[14:45] <bac> rick_h_: patience
[14:45] <rick_h_> bac: right, just letting him know that's on staging as well
[14:45] <jcastro> that's fine, I only needed them for the announcement last week, so mangling is fine
[14:45] <jcastro> It's not like I'll be featuring and unfeaturing new stuff
[14:45] <bac> yeah, sorry we didn't get them done earlier
[14:50] <rick_h_> jujugui call in 10 please kanban
[14:54] <frankban> hatch: review done, I decided lunch can wait, sorry for the stream of consciousness
[14:55] <hatch> haha np - I appear to be having internet issues as well
[14:55] <hatch> hopefully they are back up
[14:56] <bac> frankban: quickstart works on vagrant now, but it is a bit ugly.  https://dl.dropboxusercontent.com/u/420990/jjqs-vagrant.png
[14:57] <rick_h_> woot
[14:57] <bac> rick likes ugly
[14:57] <hatch> lol it's not that ugly in iterm....must be a terminal thing
[14:57] <hatch> linux people like ugly
[14:57] <hatch> :P
[14:57] <rick_h_> hatch: pssst you're a linux person now
[14:58] <bac> hatch: we keep you around
[14:58] <rick_h_> welcome to the party
[14:58] <hatch> yeah but my desire for uglyness hasn't hit yet
[14:58] <bac> now you ran off luca
[14:58] <hatch> haha
[14:59] <frankban> bac: vargrant box locale issue?
[14:59] <hatch> frankban thanks for the suggestions I'll have to put some thought into those
[15:00] <bac> am i in the wrong place?
[15:00] <rick_h_> bac: https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso
[15:00] <frankban> bac: vagrant local issue?
[15:00] <frankban> locale
[15:00] <bac> ah, so we use the regular spot everyday but friday?
[15:13] <bac> rick_h_: for the record, i'm not relying on vagrant.  just spun it up for testing.  may do so in the future if i decide i like atom, github gui, etc.
[15:13] <kadams54> Oh, speaking of atom… who had the invites? And are there more?
[15:14] <rick_h_> bac: ok cool. Yea it just seems to be getting some uptick in dev use so figured we should treat it as a bit more important. 
[15:14] <rick_h_> kadams54: I think Makyo had one at some point
[15:14] <rick_h_> if you need one post to twitter and I can RT you. I know a bunch of folks on there have them 
[15:15] <Makyo> kadams54, sure, email?
[15:15] <rick_h_> luca__: meet kadams54, he's tinering with some of your UI bugs and might come bugging for info/assets at some point
[15:16]  * frankban bbiab
[15:17] <hatch> I was less than impressed with atom - felt like an incomplete and slow sublime text
[15:17] <hatch> I suppose that's what they are going for
[15:17] <Makyo> It's in alpha :P
[15:17] <Makyo> Or I guess beta now that they've got invites.
[15:17] <hatch> right, but haven't they been at it since 08?
[15:17] <hatch> :)
[15:19] <luca__> rick_h_: I'm doing user testing at the moment, will say hi over a call in a bit
[15:19] <luca__> kadams54: Hi!
[15:19] <rick_h_> luca__: all good just wanted you to recognize the irc nick 
[15:28] <kadams54> luca__: Hi!
[15:28] <hatch> I'm just gona go to Wendy's....
[15:29] <rick_h_> hatch: not a good plan...not a good plan at all
[15:29] <hatch> lol
[15:29] <kadams54> Better than White Castle.
[15:29] <kadams54> ;-)
[15:33] <hatch> we don't have White Castle here unfortunately
[15:33] <hatch> fortunately? 
[15:33] <hatch> heh
[15:35] <bac> hatch, Makyo: the change to use NFS on vagrant was easy-peasy for os x.  testing on ubuntu host now.
[15:35] <bac> did require 'sudo touch /etc/exports'
[15:36] <kadams54> bac: good the hear
[15:36] <hatch> bac awesomer
[15:36] <Makyo> Oh, rock on.
[15:36] <bac> kadams54: git is already installed on the guest.  but when you brought vagrant up it wasn't there?
[15:36] <hatch> faster lint and test runs here we come
[15:37] <rick_h_> hatch: *cough*native*cough*
[15:37] <hatch> rick_h_ hey I tried - I blame whomever writes the kernel :P
[15:37] <hatch> I'd be rocking trusty by now
[15:37] <Makyo> It's in the provision script, at least.
[15:37] <rick_h_> hah, not whoever bought the laptop?
[15:37] <Makyo> Haha
[15:37] <kadams54> bac: I was seeing "command not found" errors for it when running makefile stuff… which went away after running "sudo apt-get install git"
[15:37] <kadams54> But it's entirely possible I made a newbie mistake
[15:38] <hatch> well MAYBE someone else should produce quality hardware?
[15:38] <bac> Makyo: currently /vagrant is only the juju-gui directory.  it might be nice to make it '..' instead so you could have access to other software you may be working on
[15:38] <bac> hatch: rule of thumb, if you want your laptop to work with ubuntu natively, buy whatever hardware pitti runs.
[15:38] <hatch> hmm
[15:39] <kadams54> lol
[15:39] <bac> cannot go wrong
[15:39] <hatch> haha 
[15:39] <Makyo> bac, That presupposes a certain directory structure, but if we're aiming to make the vagrant more universal for quickstart and the like, that could be nice.
[15:39] <bac> Makyo: well, it does make a bit of an assumption.  it assumes your juju-gui is contained within '..'  -- if you happen to put other stuff there, all the better.  :)
[15:40] <kadams54> Mayko: As long as it's in the provision script… I had a similar problem where node wasn't found, even though it's also in the provision script. Very possible for this to be PIBKAC.
[15:40] <hatch> PEBKAC looks better
[15:40] <hatch> :P
[15:40] <hatch> E = exists 
[15:40] <kadams54> :-)
[15:40] <hatch> kadams54 I actually use git in osx not in vagrant
[15:40] <bac> kadams54: i haven't tried making yet on my new image.  let me try before we blame the new guy.  :
[15:40] <Makyo> bac, yeah, sounds good.  I just use juju-gui/work as a relic from bzr
[15:41] <hatch> I do ~/canonical/<project>
[15:41] <bac> Makyo: i'm sure we can work out something that suits us all.  worthy goal, i'd think
[15:41] <Makyo> bac, yep, sounds good.  I'm just behind, is all.
[15:41] <kadams54> hatch: as do I, but I saw the errors when running "make devel" in the image
[15:41] <hatch> ohh interesting...
[15:42] <kadams54> ~/Code/project
[15:42] <Makyo> hatch, yeah, ~/work/<project>/, but bzr projects are ~/work/<project>/<bzr branches by user>, and work is the lightweight checkout of whatever I'm working on.
[15:42] <hatch> I've been thinking of doing that structure - I need to come up with a good one for my $GOPATH
[15:44] <bac> well, heck, why don't we just mount $HOME as /vagrant?
[15:45] <bac> not being smarty...
[15:45] <kadams54> I think it's worth playing around with… no rule we can't change it back :-)
[15:45] <bac> ok, kadams54, in my shiny new vagrant instance i just ran make devel with no intervention and it worked.
[15:46] <kadams54> bac: yeah, same here. Not sure what happened yesterday.
[15:46] <bac> ok, call it a non-issue until it appears again
[15:46] <kadams54> Also "which git" shows it installed.
[15:46] <hatch> bac honestly that's not such a bad idea
[15:46] <hatch> +1
[15:47]  * bac tries
[15:48] <kadams54> guihelp I'm ready for another pre-implementation chat on bug 1290312
[15:48] <hatch> bug #1290312
[15:48] <Makyo> _mup_, you okay buddy?
[15:48] <hatch> oh c'mon mup what ya doin
[15:50] <Makyo> https://bugs.launchpad.net/juju-gui/+bug/1290312 _mup_ 
[15:50] <Makyo> Oh well.
[15:50] <hatch> kadams54 I'm getting up to speed on the card
[15:50] <Makyo> kadams54, I recommend splitting 3 into its own card
[15:51] <kadams54> Separate card, separate ticket as well?
[15:51] <hatch> single ticket is fine imho
[15:52] <Makyo> Yeah, leave the ticket intact, just have separate cards for units of work.
[15:52] <kadams54> k
[15:52] <hatch> https://plus.google.com/hangouts/_/72cpikq3qfse972qd7v4npvkuo?authuser=1&hl=en
[15:52] <hatch> ^ kadams54 
[15:52] <Makyo> Should be able to do 1 & 2 today, not have to leave 3 hanging
[15:59] <hatch> luca__ ping?
[16:02] <luca__> hatch: not avail at the moment, I'm in user testing
[16:03] <rick_h_> hatch: something I can help with?
[16:03] <hatch> ok ping when you are, kadams54 just needs a garbage can asset
[16:04] <rick_h_> kadams54: hatch please email luca and copy spencer on it for the need. And just use a place holder of something else for the moment to move the branch forward. 
[16:10] <hatch> rick_h_ yup going to use a placeholder for now
[16:10] <hatch> I'll send the email 
[16:10] <kadams54> thanks
[16:11] <hatch> kadams54 can you ping me your canonical email, it's not in my directory for whatever reason
[16:13]  * rick_h_ goes to locate lunchables
[16:16] <hatch> quality lunch right there
[16:24] <hatch> I think I'm going to alias `ssh vagrant` to `vagrant ssh` :/
[16:29] <hatch> http://venturebeat.com/2014/03/20/docker-delivers-its-first-commercial-service-since-its-big-pivot-last-year/
[16:43] <hatch> kadams54 you should have received the trash can asset
[16:43] <kadams54> hatch: confirmed
[16:43] <kadams54> Going to run some lunch errands - bbiab
[17:04] <hatch> we need a 'willBeCalled' assertion :)
[17:04] <hatch> assert.willbeCalled(myFunction);
[17:05] <hatch> would save from writing a setinterval
[17:05] <rick_h_> hatch: would need to be like assertCalledWith? 
[17:05] <rick_h_> hatch: ugh, can't we avoid that by direct calls?
[17:05] <hatch> the test I'm doing now requires the inspector 'save' button to be clicked, then wait for the env method to be called
[17:05] <hatch> so it's async and needs to poll until the stubMethod.calledOnce() returns true
[17:06] <hatch> I'm trying to avoid that
[17:06] <hatch> I don't see anyway around it
[17:07] <rick_h_> hatch: so the around would be to split the tests. Something you're doing start a process to get to the env?
[17:07] <hatch> a really fast setInterval shouldn't be an issue though....it can poll every 10ms or something
[17:07] <rick_h_> hatch: and then you want something that verifies if that call is made, the env does the right thing
[17:07] <hatch> right but this needs an integration test (thats why this was missed last time)
[17:07] <rick_h_> so you test each end of the middle man, and skip the async in the middle
[17:07] <rick_h_> ah
[17:07] <hatch> I'm going to do a setInterval then in review if anyone can come up with something better I'm all for it
[17:08] <rick_h_> hatch: :)
[17:08] <frankban> hatch: what about mocking the env method, putting the assertions in there and then calling done?
[17:09] <hatch> frankban, u win the internets
[17:09]  * hatch switches to old-school mocking
[17:09] <frankban> :-)
[17:11] <hatch> wow I can't believe I didn't think of that
[17:11]  * hatch bows head in shame
[17:12] <rick_h_> yea, it's rare you can't work around a setInterval type thing. If you can't usually there's something bigger to look at. 
[17:12] <rick_h_> frankban: ftw :)
[17:12] <rick_h_> frankban: shouldn't you be off enjoying your weekend by now? 
[17:13]  * hatch is glad he isnt' gone yet haha
[17:13] <frankban> rick_h_: no, I usually stop at 6pm UTC, 7pm here
[17:13] <rick_h_> frankban: ah, gotcha
[17:14] <rick_h_> frankban: oh, with that time switch you moved an hour on me. 
[17:14] <rick_h_> and ouch that's late anyway
[17:16] <frankban> rick_h_: yeah but I like starting later in the morning, and this way there is more overlap with US timezones
[17:16] <rick_h_> frankban: cool, it is nice on that end. 
[17:18] <hatch> I wonder if someones job could be to write tests
[17:18] <hatch> there is clearly an advantage for the code author to write the tests
[17:18] <rick_h_> well there are test engineers
[17:18] <hatch> but there may be an advantage of someone who doesn't know the code to write the tests
[17:19] <hatch> because they see the hard 'corners'
[17:19] <rick_h_> hatch: I'm not sure, too often bad/hard to write tests are signs the author is barking up the wrong tree
[17:19] <rick_h_> hatch: to implement the feature and not get that feedback until done would be painful and lots of rewriting
[17:19] <hatch> true true
[17:20] <rick_h_> and that's a LONG way from TDD
[17:20] <rick_h_> :)
[17:20] <hatch> lol
[17:20] <hatch> yeah just thinking outlou
[17:20] <hatch> d
[17:20] <rick_h_> yep, same here 
[17:21] <rick_h_> I do wonder what 'test engineers' really do now that you mention it
[17:21] <hatch> maybe they do the exact opposite of TDD :)
[17:21] <hatch> CDT
[17:21] <hatch> code driven tests
[17:21] <rick_h_> that would be a sucky job, to be handed code and "make the tests that make this code be valid"
[17:24] <hatch> lol
[17:24] <hatch> rick_h_ maybe they write tests to match the spec and then the code needs to match that
[17:24] <hatch> I know in big enterprise apps people write class specs *yuck*
[17:26] <kadams54> We had a test engineer for awhile…
[17:26] <kadams54> They mostly focus on functional testing
[17:26] <rick_h_> there you go hatch, make your full time job selenium work...in python :P
[17:26] <hatch> kadams54 how did they know what the function was supposed to return?
[17:27] <hatch> jujugui I need a review/qa on https://github.com/juju/juju-gui/pull/191 plz and thanks
[17:27] <hatch> rick_h_ lol noooooo thanks
[17:27] <kadams54> hatch: that's too low level - they worked more on the "you're supposed to click here and the app will do X, Y Z" level
[17:27] <rick_h_> kadams54: have bandwidth to peek at it as a first review? I'll also go through it as well. 
[17:28] <hatch> ohhh
[17:28] <kadams54> Selenium, CasperJS, WebTest… on that level
[17:28] <hatch> ahh gotcha
[17:28] <kadams54> rick_h_: sure
[17:29] <kadams54> hatch: you get to be my review guinea pig :-)
[17:29] <hatch> haha, giver! When it comes to QA I can guide you through pulling down the branch
[17:29] <hatch> it's pretty easy
[17:29] <kadams54> I just setup my git aliases this morning :-)
[17:30] <bac> git folk, i accidentally did all of my work in develop -- forgot to create a new branch -- and have pushed it up to github.  how do i unwind and do it right?
[17:30] <hatch> bac heh oops :)
[17:30] <rick_h_> bac: take your develop, and create a branch from it
[17:30] <kadams54> git revert <hash>
[17:31] <rick_h_> git co -b my-workd
[17:31] <hatch> I'd cherrypick
[17:31] <rick_h_> and then push that up as a new branch
[17:31] <hatch> or that
[17:31] <rick_h_> git push origin mybranch:mybranch
[17:31] <rick_h_> and then pull request from that
[17:31] <hatch> lol there are so many ways....I like rick's approach though
[17:31] <kadams54> `git revert <hash>` will remove it from develop
[17:31] <bac> ok
[17:31] <rick_h_> and then go back to develeop and remove it per kadams54 
[17:31] <hatch> weeeeee
[17:31] <rick_h_> but do the new branch first so you don't lose work
[17:31] <kadams54> +1
[17:37] <kadams54> hatch: what's this about ghost inspector and service inspector?
[17:38] <hatch> kadams54 pre-deployment = ghost inspector post deployment = service inspector
[17:38] <hatch> (legacy talk) the icons used to be ghosted
[17:38] <kadams54> Ah, got it
[17:39] <hatch> frankban did you want to have a call about your comments - I think some are handled already by this structure but would like to discuss further than some github comments :)
[17:40] <frankban> hatch: sure
[17:40] <hatch> https://plus.google.com/hangouts/_/72cpi2tcd0t3a61utkp6p1g32s?authuser=1&hl=en
[17:45] <bac> hey rick_h_, when i try to rebase i get https://pastebin.canonical.com/106946/
[17:46] <bac> i already pushed to github, so i need to get it rebased and push with --force?
[18:00] <rick_h_> bac looking
[18:00] <bac> rick_h_: and my branch now looks like https://pastebin.canonical.com/106948/
[18:00] <rick_h_> bac: because you branched from develop there's nothing to rebase on there
[18:00] <bac> ah
[18:01] <rick_h_> bac: right you branched after you did the revert
[18:01] <rick_h_> bac: as I mentioned, do the branch first, then remove the commit on develop
[18:02] <bac> will that create another revert checkin?
[18:02] <bac> is there no equivalent of 'bzr uncommit; bzr revert'?
[18:02] <rick_h_> bac: which commit do you want to keep?
[18:02] <rick_h_> bac: which commit(s) need to end up in trunk?
[18:03] <bac> in vagrant-fixes i want the older three.  the revert was a mistake
[18:04] <bac> so, i'd like a clean develop, and those three commits in my branch squashed into one
[18:04] <rick_h_> bac k sec
[18:07] <hatch> kadams54 hmm looking at your qa failure
[18:08] <rick_h_> bac: https://pastebin.canonical.com/106949/ 
[18:08] <rick_h_> bac: that should get you going
[18:09] <hatch> kadams54 hmm I can reproduce....looking
[18:09] <hatch> thanks
[18:09] <rick_h_> bac: obviously untested, let me know if you hit an issue
[18:09] <hatch> kadams54 ohh right - woops this is a limitation of the fakebackend
[18:09] <hatch> I'll reply in the PR
[18:10] <hazmat> how do you search charm by series?
[18:11] <hazmat> in the gui, or directly against the charmworld api
[18:11] <hazmat> attempting to use api versions that used to support this.. gets unsupported api version
[18:11] <hatch> I think that functionality was removed
[18:11] <bac> rick_h_: ok, that should work but i'll commit to trunk with no rebase
[18:11] <rick_h_> hazmat: you don't in the gui. http://manage.jujucharms.com/api/3/search/?text=mysql&series=precise in charmworld
[18:12] <rick_h_> http://manage.jujucharms.com/api/3/search/?text=&series=precise for all precise for instance
[18:12] <rick_h_> hmm, might need to flip the limit off 
[18:12] <hazmat> rick_h_, any keyword to type that into manage.jujucharms.com html search box?
[18:12] <rick_h_> http://manage.jujucharms.com/api/3/search/?text=charm&series=precise looks better
[18:13] <hazmat> rick_h_, http://manage.jujucharms.com/api/3/search/?series=saucy ?
[18:13] <rick_h_> hazmat: no, filters were removed and the idea of supported 'tags' isn't designed/done
[18:13] <rick_h_> hazmat: trying http://manage.jujucharms.com/api/3/search/?text=charm&series=saucy 
[18:13] <rick_h_> hazmat: so yea, no saucy
[18:13] <hazmat> rick_h_, try any non precise series..
[18:13] <rick_h_> http://manage.jujucharms.com/api/3/search/?text=charm&series=oneiric shows some
[18:13] <bac> juju-gui / makyo: review request https://github.com/juju/juju-gui/pull/192
[18:13] <hazmat> rick_h_, they are there.
[18:13]  * hazmat gives up.. and uses launchpad
[18:14] <hazmat> rick_h_, that does work btw.. http://manage.jujucharms.com/api/3/search/?series=quantal
[18:14] <hazmat> rick_h_, the problem is there is no saucy series for the charms distro 
[18:14] <rick_h_> hazmat: right, but limited to 20 matches unless you add text=charm to get all results
[18:14] <hazmat> in lp
[18:15] <hatch> bac it's juju-gui without the - :)
[18:15] <bac> hatch: nfm
[18:15] <rick_h_> hazmat: so yea, I get results for quantal, oneiric, no saucy
[18:15] <hatch> love that you added nfs support :)
[18:16] <hatch> kadams54 do you have a ec2 juju credentials set up yet?
[18:16] <bac> hatch: it solved your problem and the saucy problem
[18:16] <bac> made sense
[18:16] <hatch> like a boss 
[18:16] <hatch> :-)
[18:24] <hatch> odd quickstart error https://gist.github.com/hatched/ab4431b789e67a0f7ef8
[18:26] <hatch> bac I can qa your branch a little later - running with parallels right now so I don't want a kernel panic :)
[18:26] <hatch> unless someone else gets to it first
[18:26] <hatch> :)
[18:26] <rick_h_> hatch: calls and calls, not getting to the review atm. If you can find someone else awesome else I'll get at it eventually
[18:27] <hatch> rick_h_ re my branch that frankban did?
[18:27] <rick_h_> hatch: no, the one that kadams54 looked at
[18:27] <rick_h_> I was going to double review you, until everone else wanted to talk to me first
[18:27] <hatch> ohh ok yeah I'm just qa'ing in a real env to confirm that the issue is a fakebackend limitation
[18:28] <hatch> I'm pretty confident but I want to be sure
[18:28] <hatch> oh and we NEEED to talk about my other branch.....:P jk whenever you have time I'll fill you in on what frankban and I discussed
[18:28] <rick_h_> hatch: heh, well I figure kadams might let you sneak by something crazy since he's not up on all the linting/history stuff
[18:28] <hatch> lol
[18:28]  * hatch goes and changes all his short var names
[18:29] <rick_h_> see I knew it!
[18:30] <kadams54> lol
[18:31] <kadams54> hatch: no, no ec2 credentials (at least not that I know of)
[18:31] <hatch> we just use our own then expense it
[18:31] <hatch> well...usually the bills are like $2 so it's not worth it
[18:31] <hatch> lol
[18:32] <kadams54> OK, in the process of signing up right now
[18:32] <hatch> https://juju.ubuntu.com/docs/config-aws.html
[18:32] <hatch>  or use `juju-quickstart -i` :)
[18:33] <kadams54> Hah
[18:49] <hatch> lunching
[18:54] <kadams54> Change of location
[19:08] <hatch> bak
[19:11] <bac> jujugui: i'm trying to QA my vagrant changes with an ubuntu host but having a hard time getting virtualbox installed.  if someone else with a pre-configured machine could try it i'd be grateful.
[19:11] <bac> is that a 'bac ack'
[19:11] <hatch> lol
[19:11] <hatch> bac I can qa it now
[19:13] <bac> thanks hazmat
[19:13] <bac> s/hazmat/hatch/
[19:14] <hatch> mounting works - I need to try with saucy now so that'll take a bit
[19:14] <hatch> blarg it keeps picking up my existing vm
[19:15] <hatch> gona need to delete it I guess
[19:18] <hatch> doooownloading 
[19:21]  * hatch needs faster internet
[19:21] <hatch> 600KBps is just not cutting it
[19:25] <hatch> jcastro have you seen that codinghorror.com has switched to using discourse for comments? It's a pretty cool idea, forces people to go elsewhere to -make- the comment but it's still shown in the article
[19:25] <hatch> ex) http://blog.codinghorror.com/please-read-the-comments/
[19:25] <jcastro> yeah we use that on insights.ubuntu.com
[19:26] <hatch> ohhh I thought it was just a link, I didn't know it also reported the comments back to the main thread
[19:26] <hatch> is insights a ghost blog?
[19:26] <jcastro> no, wordpress
[19:27] <hatch> ohh ok, he said his was a ghost blog so just curious
[19:27] <hatch> it's a pretty cool idea - hopefully help to trim out some of the idiots
[19:27] <rick_h_> hatch: did we need to chat?
[19:27] <hatch> we did!
[19:27] <hatch> vewwwy impotant
[19:27] <rick_h_> hatch: ok, your up then
[19:28] <rick_h_> shoot me a link please
[19:28] <hatch> on it
[19:28] <rick_h_> or just shoot me :P
[19:28] <hatch> lol
[19:28] <hatch> https://plus.google.com/hangouts/_/72cpi1j10275vvu1nppqkc6tnc?authuser=1&hl=en
[19:43] <rick_h_> oops, check you later hatch :)
[19:43] <hatch> lol
[19:43] <hatch> cya
[19:43] <rick_h_> note to self, don't drop your hand on the keyboard when the cursor is on the disconnect button
[19:43] <rick_h_> you will rudely run away 
[19:44] <hatch> bac still around?
[19:45] <rick_h_> hatch: +1 on the config button branch thanks
[19:46] <bac> hatch: yep
[19:46] <hatch> bac :+1: 
[19:46] <hatch> :) it's awesome
[19:46] <hatch> so friggen fast
[19:46] <bac> hatch: could you actually do the review too?
[19:46] <hatch> I did
[19:47] <bac> oh, cool.
[19:47] <hatch> that's what the :+1: is
[19:47] <hatch> QA OK is the qa being ok :D
[19:47] <hatch> I had no comments re the code heh
[19:47] <hatch> oh man this is so awesome
[19:48] <bac> no, i know.  i hadn't looked at the pull request.  thanks!
[19:48] <hatch> :-) 
[19:50] <rick_h_> hatch: ok, I'm really cranky with them now. The talk of lack of $$ for a security audit until they got funding is insulting. http://blog.npmjs.org/post/80277229932/newly-paranoid-maintainers
[19:51] <hatch> reading...
[19:52] <hatch> so basically the money that was raised was -only- used for hosting not working on the platform
[19:53] <rick_h_> hatch: yea, guess so. But to claim the poor house after that but before funding is bad form imo
[19:54] <rick_h_> not to mention it demonstrated that the community was willing to fund work on npm
[19:54] <hatch> yeah I think the whole series of events was a huge mess
[19:54] <rick_h_> no kidding
[19:55] <rick_h_> ok, with that I'm out of here and before 5pm yay!
[19:55] <hatch> lol have a good weekend
[19:55] <rick_h_> everyone have a good weekend, look forward to hanging out next week ka
[19:55] <rick_h_> bah tab fail
[19:55] <hatch> haha he isn't here
[19:55] <rick_h_> how dare he not let me tab complete his nick
[20:35] <bac> jcastro: how does cbs do the scoring for the bracket?  in first round people with same number correct have different scores.
[20:35] <bac> jcastro: congrats on your current lead.
[20:46] <bac> hatch: fancy a charmworld review? https://codereview.appspot.com/78940044  mighty simple
[20:46] <hatch> I can take a peek
[20:46] <bac> hatch: not even any python, just template
[20:48] <hatch> bac done
[20:49] <bac> excellent catch hatch!
[20:55] <hatch> :)
[20:58] <hatch> bac can you send an email to the juju-gui list about the vagrant update? People will need to have it download the new image etc
[20:59] <bac> hatch: i can, but won't it just dtrt the next time they 'vagrant up'?
[20:59] <hatch> bac it didn't for me, I had to `vagrant delete && vagrant up`
[20:59] <bac> oi
[20:59] <hatch> it did the file sharing on the next up
[21:00] <hatch> but didn't use the new image
[21:00] <bac> okey doke, i'll do it
[21:01] <hatch> cool thanks
[21:01] <hatch> bac sorry it was `vagrant destroy`
[21:01] <hatch> not delete
[21:05] <bac> hatch: did
[21:06] <bac> and with that i wish you a good weekend.  see you week after next.
[21:06] <hatch> enjoy your break! cya
[21:16] <hatch> sooo last one in the office eh
[21:16]  * hatch turns the tunes up
[21:23] <kadams54> hatch: Running into something frustrating… the local juju-gui seems to change the relationship status every couple of seconds
[21:24] <hatch> oh yeah
[21:24] <hatch> sorry
[21:24] <hatch> heh
[21:24] <kadams54> That's destroying and recreating the DOM that I'm trying to debug. What's the best way to make it stop?
[21:24] <kadams54> :-)
[21:24] <hatch> hit ctrl+s in the gui
[21:24] <hatch> it'll shut off the simulator
[21:24] <kadams54> Thanks
[21:25] <hatch> the simulator is very nice for when you want to make sure what you're working on will change states properly etc
[21:25] <hatch> but yeah, can be a hassle 
[21:25]  * hatch would like to note that that shortcut was in the code you just changed :P
[21:25] <hatch> lol
[21:26] <kadams54> :-b
[21:27] <hatch> kadams54 so how are you finding the code? Easy enough to follow?
[21:27] <kadams54> Yeah, as long as I limit myself to the constraints of the bug I'm working on
[21:28] <kadams54> Also helps that I'm being picky about which ones I pick up :-)
[21:28] <hatch> haha yeah - it'll take a bit of getting used to - there are a few different systems at work 
[21:29] <kadams54> hatch: another question: what, if any, resources are auto-reloaded when running `make devel`?
[21:29] <kadams54> Right now I've just been doing ctrl-C and running `make devel` again once I save changes
[21:29] <hatch> ohh no no
[21:30] <hatch> js is auto reloaded, css and templates aren't in vagrant 
[21:30] <hatch> (not sure why)
[21:30] <hatch> in normal ubuntu the css and templates reload too
[21:31] <hatch> I'm sure you have the 'disable cache' flag set in chrome's devtools ?
[21:31] <kadams54> yes
[21:31] <hatch> yeah - so in that case js should auto-reload, but css and templates will need make devel to be re-run
[21:31] <hatch> at least until someone fixes it
[21:32] <hatch> there are a number of those things unfortunately :)
[21:33] <hatch> we don't get to the 'slack' tasks as often as we'd like hah
[21:47] <hatch> man I wish my standing desk was motorized
[22:09] <rick_h_> hatch: yea, I do love that
[22:10] <rick_h_> with more meetings I use it back and forth a lot more now
[22:10] <hatch> the mdf blocks just aren't cutting it for me anymore :)
[22:10] <hatch> the price is right however....
[22:10] <rick_h_> yea
[22:10] <rick_h_> have to get yourself a big birthday present
[22:11] <hatch> haha I think the MBP was big enough for a while yet
[22:11] <hatch> the mrs would not be pleased if I bought one :D
[22:12] <hatch> lol @ tweet
[22:13] <hatch> it's all been in response to this http://igo.herokuapp.com/
[22:13] <hatch> https://twitter.com/NateTheFinch/status/447119466363912192
[22:33] <hatch> oh man nfs is so fast 
[22:47] <kadams54> Alright, I'm out for the weekend… have a good one!
[23:06] <hatch> and me as well cya