#juju-gui 2013-05-27
<dimitern> hey guys, anyone around?
<dimitern> I have a question how do you handle client api websocket connections going down
<dimitern> frankban, teknic: maybe you can help? ^^
<dimitern> oops teknico ^^
<teknico> dimitern: maybe :-) go on
<dimitern> teknico: so there's a way to ping a websocket connection and verify it's still alive
<dimitern> teknico: are you using this with the gui?
<teknico> dimitern: possibly, let me have a look
<teknico> dimitern: we use Y.ReconnectingWebSocket
<frankban> dimitern: IIRC we use a reconnecting websocket, reconnecting when the onclose message arrives. The websocket connection should have a readyState attr set to 1 if the connection is open
<dimitern> frankban, teknico: So this I presume uses some form of pinging internally? Where's the code?
<teknico> dimitern: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/assets/javascripts/reconnecting-websocket.js
<teknico> dimitern: invoked from http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/store/env/base.js#L172
<dimitern> teknico: istm you're reconnecting when the connection is closed, but not actively monitoring whether it's stil alive
<teknico> dimitern: yes, that's my understanding too
<dimitern> teknico: ok, thanks for checking
<teknico> dimitern: yw
<frankban> dimitern: could you please review https://codereview.appspot.com/9641044 ? 
#juju-gui 2013-05-28
<rick_h_> morning
<hatch> morning
<hatch> rick_h_, thoughts on changing the browser flag to just be 'browser' ?
<rick_h_> hatch: yes :)
<rick_h_> hatch: so it's in flux at the moment. I'm finding some issues following the old LP FF conventions because it used a . notation which in JS looks like nested objects. So went to -, then _. Trying to work out the best way still
<rick_h_> hatch: but we could easily want to have a series of flags in the browser subapp so I kind of prefer the explicit browser_enabled/browser_newux and such since it's a subapp
<rick_h_> hatch: be glad I dropped the original plan of subapps_browser_enabled :P
<rick_h_> which I like but don't want to type
<hatch> haha - I am just using :flags:/inspector as a truthy check
<rick_h_> yea, everything so far has been a single term, but I think anything in a subapp at least should be NS
<rick_h_> as the start of some useful conventions
<hatch> maybe we can use https://github.com/adambom/parallel.js to speed up our tests :)
<rick_h_> hatch: not until we rewrite everything :P
 * rick_h_ has been doing too much window. in the code to feel that we're anywhere near parallel tests. 
<hatch> haha hey it's a good dream
<rick_h_> +1
<hatch> I was looking at these new designs from luca on my laptop and am kind of concerned that the top 'chrome' takes up a good 1/5th of my screen on my laptop
<hatch> so I can only actually see 6 charms in the search results page and can't even see their full descriptions
<hatch> it feels very 'zoomed in' 
<hatch> this of course likely isn't an issue on my desktop :)
 * gary_poster hasn't seen yet...
<rick_h_> jcsackett: standup ping
<jcsackett> rick_h_: fighting with g+
<rick_h_> hatch: up for some review love? https://codereview.appspot.com/9731047 jcsackett as well please ^^
<benji> has anyone seen this while trying to do an lbox propose? http://paste.ubuntu.com/5710198/
<hatch> rick_h_, sure
<hatch> benji, never seen that
<gary_poster> me either...
<rick_h_> benji: think I saw that in my raring install. Sec, checking my history
 * hatch is glad he isn't on raring yet ;)
<benji> I recently upgraded to raring.
<rick_h_> benji: sec, on call. Will dbl check.
<benji> even though I've had some small issues (this and the fact that lbox isn't available for it) it has been worth it because my networking (wifi) has been so much better
<gary_poster> yay!
<hatch> benji, I have read others complaining about wifi issues haha
<hatch> maybe you took their good luck :)
<benji> heh
<hatch> ubuntu needs a better driver story
<hatch> I don't know how many hours i've fought with installing graphics drivers in the correct order to get things to work properly
<hatch> I know it's not ubuntu's fault but...ya know
<gary_poster> lol, I go to uistage.jujucharms.com:8080, and Chrome says "This page is in Galician.  Would you like to translate it?"  um?
<gary_poster> I reported an incorrect language detection
<hatch> gary_poster, haha I've ran into some odd languages there too!
<gary_poster> :-)
<gary_poster> hatch I compared https://launchpadlibrarian.net/140916463/Juju_Full_Home.png against http://uistage.jujucharms.com:8080/bws/fullscreen/
<gary_poster> new version is definitely taller at top
<gary_poster> but only in "Charm browser" section, for one thing
<gary_poster> and not *wildly* taller
<gary_poster> 20 or 30 px maybe?
<hatch> ahh yes you're right - I guess the design itself has always been like that
<gary_poster> luca, hi.  fwiw, hatch reported that the charmbrowser header took up 1/5 of his laptop screen
<gary_poster> hatch, what's that screen res?
<hatch> sorry I meant the whole gui chrome
<hatch> 1366x768
<gary_poster> hatch, yeah sorry I meant that when you are using the charmbrowser in full screen, 1/5 of the screen is in the header
<luca> gary_poster: hatch I'm working on minimising the headers in the GUI to something more "refined" a lot of it currently is throw back from previous designers
<gary_poster> luca cool, thanks.
<luca> gary_poster: hatch mainly because it does the same thing on my laptop hehe :)
<gary_poster> lol
<hatch> haha 
<hatch> oh right you're on a air
<hatch> an*
<luca> hatch: yup
<hatch> alright then - so you can easily see the low res issues
<hatch> I'm not even sure this is an issue for us, but I kind of assumed it would be used by ppl on their laptops
<gary_poster> frankban, did/does the NOT LGTM review on the API address juju core branch mean a big change?
<gary_poster> hatch, oh no, people definitely don't use laptops ;-)
<hatch> lol
<hatch> maybe they are all using retina MBP's so it's not an issue :)
<gary_poster> :-)
<frankban> gary_poster: quick hangout?
<gary_poster> sure frankban 
<frankban> gary_poster: I am in the gui chat
<rick_h_> benji: ok, this was part of my virtualenv hell 
<rick_h_> benji: so I had to for install an updated virtualenv 1.9 to get that working. 
<benji> please say there is a ppa, please say there is a ppa
<rick_h_> benji: wget "https://pypi.python.org/packages/source/v/virtualenv/virtualenv-1.9.1.tar.gz" && sudo pip install virtualenv-1.9.1.tar.gz
<rick_h_> lol
<benji> darn
<rick_h_> well I didn't look for a PPA
<rick_h_> I'm anti .deb for my .py so it was a 'whatever works' in this lxc
<benji> I hate installing junk in my OS.  I guess I need to go back to heavy lxc use
<rick_h_> benji: but yea, there's some issue in how python got multi-arch'd and virtualenv in 13.04 that causes issues and the python-virtualenv isn't new enough to handle it in 13.04
<rick_h_> jcsackett: picking up a review on your caching branch
<benji> you'd think that would be on the did-we-break-python checklist
<rick_h_> yea, it's how I found out I was the only one using a raring lxc on the squad :/
<jcsackett> rick_h_: wait, it's up?
<rick_h_> jcsackett: just heads up I'm doing on of the reivews for your cache branch.
<jcsackett> rick_h_: right, i'm just surprised--from my end it looks like it kept dying without completing the proposal.
<jcsackett> "it" being lbox.
<rick_h_> jcsackett: oh, got the emails
<jcsackett> rick_h_: well, fantastic.
<bac> hi rick_h_, i see you added 'bin/*' to .bzrignore for juju-gui.  those files are versioned so that seems ungood to me.
<rick_h_> bac: oh hmm, /me dbl checks what was up with that
<hatch> rick_h_, I don't see anything setting noop in your tests...isn't that what it was for?
<bac> rick_h_: ok, let me know if i shouldn't revert it.
<rick_h_> bac: this is from a while ago?
<rick_h_> bac: yes, please revert if you need it now or I can drive-by in my current branch. This was from my own putting the gui in a virtualenv and didn't realize I was colliding with existing stuff
<rick_h_> hatch: looking
<rick_h_> hatch: it's set and used in the app/subapps/browser/browser.js
<bac> rick_h_: ok, i'll do it in my branch
<rick_h_> bac: thanks
<hatch> rick_h_, ohh ok now I see the intended use
<rick_h_> hatch: cool, please suggest any docs updates/etc to help make it clearer. Been a while since I looked at it now myself :/
<rick_h_> stupid long hanging branches of doom
<hatch> yeah I have one of those myself
<hatch> rick_h_, LGTM'd now to qa
<hatch> rick_h_, QA looks OK
<rick_h_> hatch: cool thanks
<benji> rick_h_: have you seen this one? http://paste.ubuntu.com/5710371/
<rick_h_> benji: yep, got that one as well. I've not gotten past that one. I only get it on lbox submit and have been doing submit from my laptop which isn't in an lxc. I thought I got that around getting the gslint package from the local path or something
<rick_h_> -cr work fine :/
<rick_h_> benji: but i had assumed that was more to do with me running a local pypi mirror and it's not in the lxc yet so ugh that you get it as well
<benji> hrm
<rick_h_> benji: https://pastebin.canonical.com/91696/ is how my version looks
<rick_h_> benji: not sure why it's looking for mypi since I commented that out of my pip config, but seems like it's still somewhere. Assumed that's why I was getting this error.
<benji> grr, it is using zipped eggs, so debugging is harder
<hatch> benji, are zipped eggs some kind of southern delicacy? 
<benji> heh
<hatch> :)
<rick_h_> jcsackett: notes inbound, let me know if you want to hangout on it
<jcsackett> rick_h_: may want to chat, reading notes/considering.
<rick_h_> jcsackett: rgr
<hatch> luca, I just noticed in one of your mockups you use a comma in 10,234 and the other two don't - not sure if it matters but thought I'd point it out :)
<rick_h_> jcsackett: just invite me to a hangout or we might even be able to co-opt guichat. 
<luca> hatch: there isn't meant to be a comma, the visual designer is sending me a masthead file for you guys to reference. Cheers for the heads up :)
<hatch> :)
<benji> score one for tests: I just made a "small" change that would have broken my branch if I hadn't had tests
<hatch> go tests....go tests.....go tests.......
<hatch> there is TDD, BDD, and I am going to coin the term RDD
<hatch> Regression Driven Development :D
<gary_poster> yay, thank you rick_h_ .  have not checked out browser default flag yet, but saw the landing :-)
<rick_h_> gary_poster: cool, hatch qa'd and should be good. next up...icon svg out of the api updates
<gary_poster> yay! :-)
<benji> perky yet refined review available: https://codereview.appspot.com/9657046
<teknico> how classy :-)
<teknico> Makyo: got time for a quick chat? d3 is confusing me
<Makyo> teknico, Sure.
<teknico> Makyo: https://plus.google.com/hangouts/_/02bb45411739e441fe107c9f66e2a8cc36ba4ba7?authuser=0&hl=en
<abentley> rick_h_: Since you created "Update charmworld docs/ to match new life with injestor.", could you please review https://code.launchpad.net/~abentley/charmworld/ingest-docs/+merge/166080 to see if it addresses it?
<rick_h_> abentley: sure, give me a couple and I'll peek at it.
<hatch> hmm I'm getting the Uncaught SyntaxError: Unexpected end of input  errors from jujucharms again
<rick_h_> hatch: more details req'd. DNS issue? actually getting a bad response? 
<rick_h_> url that you're hitting it's failing on, etc
<hatch> rick_h_, it will just cut off the transfer
<hatch> it happened at home on my desktop too
<hatch> so I know it's not me
<hatch> but that's all I have - if you make the request directly it works 100% of the time
<gary_poster> could be following you around hatch.  We have our ways.
<hatch> but through the app it appears to be cutting off the transfer
<hatch> lol
<rick_h_> hatch: so compare headers? something diff between app req vs manual
<jcsackett> rick_h_: i've published my replies. you want to read them and then see if we can have a chat before the jujugui standup? or do you want me to ping you after that?
<jcsackett> oops, forgot the hyphen. sorry for the needless alerts, all. :-P
<rick_h_> jcsackett: sure, reading now.
<hatch> rick_h_, forget that - I just got it to cut off when going direct
<hatch> rick_h_, yeah from time to time - apparently without reason https://manage.jujucharms.com/api/0/charms/interesting will just stop sending data between 8-12s 
<hatch> it always appears to stop during one of the svg's though
<hatch> not sure if that helps with anything though :)
<abentley> jcastro: I think https://bugs.launchpad.net/charmworld/+bug/1015767 has already been done.  Can you confirm?
<_mup_> Bug #1015767: Queue time needs to be measured by last modified, not creation time. <charmers> <charmworld:Triaged> <https://launchpad.net/bugs/1015767>
<gary_poster> jujugui call in 6. kanban now?
<jcastro> abentley: still open afaict
<abentley> jcastro: The age column is based on last modified.  You can see that in "Merge for apache2 from precise/apache2/additional-modules" for example.
<jcastro> oh, I misunderstood!
<abentley> jcastro: Maybe we need a text change?
<jcastro> yeah, there was something we wanted tweaked
<jcastro> sec, searching mails for it
<jcastro> abentley: oh, we wanted non-employee submissions prioritized
<jcastro> but I guess that's a new bug right?
<abentley> jcastro: I would say.
<gary_poster> jujugui call in 2
<jcastro> ok so should I resolve this one?
<abentley> jcastro: The only think I see outstanding is hazmat wanted date modified to be displayed as a column.
<jcastro> yeah that works for me
<abentley> jcastro: And if you can think of a clearer column name for "age", that would be nice too.
<jcastro> Time in Queue
<abentley> jcastro: last-modified doesn't measure time in queue.  Is that going to be okay?
<jcastro> abentley: we had a bunch of ideas on the queue, if you want me to like outline them all etc I can do that
<jcastro> ok, how about "Last Modified" then?
<jcastro> I don't care too much how long something is in there, I care that when someone posts a new revision it gets responded to quickly.
<abentley> jcastro: It would be confusing to have two columns called Last Modified.
<jcastro> like if a charm takes a month to make it through that's fine, as long as we're responsive.
<jcastro> I guess leave it as age then?
<abentley> Okay.
<jcastro> https://bugs.launchpad.net/charmworld/+bug/1185087
<_mup_> Bug #1185087: Prioritize new charms in the review queue <charmworld:New> <https://launchpad.net/bugs/1185087>
<jcastro> I think that does what we want instead of prioritizing based on employer.
<jcsackett> welp, that was the uber crash, jujugui. be back in a moment.
<hatch> https://manage.jujucharms.com/api/0/charms/interesting
<hatch> ^ jcsackett 
<hatch> it appears to frequently cut off around 8-12s inside one of the svg's 
<abentley> hatch: rick_h_ is updating to API 1, which will remove the svgs from the output.
<hatch> abentley, ok great - I hope that helps fix the issue as a side effect
<abentley> hatch: It seems to.  https://manage.jujucharms.com/api/1/charms/interesting loads fine for me.
<hatch> abentley, ahh I didn't know that the api version was up yet - that's so much faster and loads without issue
<hatch> excellent
<rick_h_> hatch: yea, work in progress. Backend is updated and much nicer. Front end in progress
<hatch> right on
<hatch> thx
<Makyo> ...typo D:
<Makyo> All tests pass now.
<gary_poster> yay Makyo :-)
<teknico> bac: thanks, anyone up for an easy one? https://codereview.appspot.com/9731048/
<bac> teknico: benji already did and i'm looking at it
<teknico> bac: right, sorry, it was benji
<teknico> and Makyo knows about it already, so it sort of makes three :-)
<bac> teknico: done
<teknico> bac: thanks (for real this time :-) )
<benji> bac: review of https://codereview.appspot.com/9836043/ done
<bac> benji: thanks for the productive and entertaining review
<benji> I can think of no higher praise.
<benji> gary_poster: I'll contact you after lunch about how I can help.
<gary_poster> sorry benji, thanks.  pulled off to lunch
<gary_poster> hatch https://docs.google.com/a/canonical.com/file/d/0B1IM--9A1RkTVGR1N05CdmVfN3c/edit (slides 18, 20, etc.) includes sketches on future directions for inspector.  if you want to incorporate now, great.  if not, we can iterate towards this soon
<gary_poster> hazmat, how do I get on uistage again?  ubuntu@ doesn't work any more
<hatch> gary_poster, so does this mean we aren't going to the 'floating' panels anymore?
<gary_poster> hatch, uh? :-) guichat really quick?
<hazmat> gary_poster, root@
<gary_poster> ah thanks hazmat 
<hazmat> gary_poster, working dir is in /opt
<gary_poster> ack thanks again hazmat 
<hatch> gary_poster, I can't seem to log in, lemme try to reconnect - the internet here is horrible
<gary_poster> ok
<gary_poster> bcsaller, I see wordpress on uistage.  I think maybe we don't restart any more?
<gary_poster> restart improv I mean
<bcsaller> ahh, maybe
<gary_poster> thanks hatch. :-) ttyl
<hatch> gary_poster, sorry - someone called, apparently that causes the internet to go down
<jcastro> heya gary_poster 
<gary_poster> hatch, everybody knows you are not allowed to talk on the phone and surf at the same time
<gary_poster> jcastro, hey
<jcastro> we'd like to add "framework" as a category to show in the gui, do I file a bug or bring it up with design or what?
<hatch> I feel like it's 1996
<hatch> lol
<gary_poster> jcastro, file a bug, gimme the number and I'll run with it
<rick_h_> jcastro: file a bug please and if you can bring it up with design add that as well. 
<jcastro> ack
<rick_h_> jcastro: I think we have to add support to the charm linter, add it to the backend, and then we need a new icon for it
<gary_poster> jcastro, I have now run with it.  whew!  that was hard.  thanks rick_h_ :-)
<rick_h_> jcastro: so it'll be a few steps to get it through. 
<rick_h_> jcastro: and we'll probably ask for another to keep a nice balanced even number of categories for design :P
<rick_h_> need two teams to join the league at the same time
<jcastro> https://bugs.launchpad.net/juju-gui/+bug/1185125
<_mup_> Bug #1185125: Add "framework" as a category  <juju-gui:New> <https://launchpad.net/bugs/1185125>
<rick_h_> jcastro: cool thanks. Will bring it up and see if we can't get the ball rolling. 
<abentley> orangesquad: I'm linking of using soupmatchers in our charmworld view tests.  Is there a better option?
<jcastro> rick_h_: yeah, I'm sure we'll need to come up with ways to remove/add categories, so I figure might as well figure it out now
<rick_h_> abentley: lxml?
<rick_h_> jcastro: yea, I'm writing out the list, since it's across several code bases and requires design work I'm not sure there's going to be a good answer forit
<jcsackett> rick_h_, abentley: i have more familiarity with soupmatchers than lxml.
<abentley> rick_h_: How do you test with lxml?
<hatch> rick_h_, curious as to the ETA on the api changeover? (planning my day)
<rick_h_> abentley: just parse the doc and assert using normal assertions?
<rick_h_> hatch: depends, working on it now. In an ideal world I'll have it tomorrow but I've not run all the tests through yet. 
<rick_h_> hatch: tomorrow or wed I'd say
<rick_h_> abentley: guess I'm not sure what you're using it to check. 
<hatch> ahh ok thanks
<abentley> rick_h_: the HTML output of a view.
<hatch> gary_poster, guichat to resume where we left off?
<rick_h_> abentley: right, so you can lxml parse the doc and using the find/etc functions to locate notes/etc. It's C-backed so fast. 
<gary_poster> sure hatch
<gary_poster> mm, bcsaller, no, uistage is hosed :-( it is blank for me now.  I tried to add mediawiki and it told me that a service of that name already existed.  going to look at ws messages...
<jcastro> rick_h_: welcome back man, I missed bothering you
<bcsaller> gary_poster: yeah, when I glaced at it it looked like it just wasn't rendering anymore. You can follow the notifications to actual mentioned services and units for example
<rick_h_> jcastro: :P
<rick_h_> jcastro: we still have to chat blog post. I want to get that out one day
<jcastro> rick_h_: I'm on the SE podcast soon until EOD, I can go now though if you want?
<rick_h_> jcastro: how about we setup something later int he week. I need to re-read it myself and trying to get this change asap
<jcastro> sure
<rick_h_> jcastro: long 3hr CHC wed. :P
<jcastro> the biggest thing I saw, is that you need to intro it to someone who does not know what you work on
<rick_h_> jcastro: yea, agreed
<jcastro> right now to understand it you basically have to work @ canonical
<jcastro> actually, I wouldn't even mention juju-gui itself, that will just confuse people
<jcastro> "I am working on a project and I want to show people a prototype"
<rick_h_> jcastro: cool
<gary_poster> jujugui trunk appears to be broken.  (1) notifications are hidden when you click on them (2) there's a white bar that is always present on the left, even on inner pages
<gary_poster> to demo first one, join to rapi-rollup or go to uistage
<gary_poster> to demo second one, should be obvious
<gary_poster> There's a third problem that is on uistage: the services do not show up
<gary_poster> I  can't dupe that locally yet
<gary_poster> could I have someone look at #1 and #2?
<bac> other than that mrs. lincoln...
<gary_poster> :-)
<bac> o/
<bac> hatch, rick_h_: either of you care to do an easy review?  linked off my cardd
<gary_poster> thank you bac.  I suspect that the merge with browser default might be a part of #2
<rick_h_> gary_poster: white bar is my fault. Since we don't load the subapp now it doesn't auto hide it's html bits. 
<rick_h_> gary_poster: FF doesn't change the index.html DOM content :/ 
<gary_poster> rick_h_, gotcha.  not the end of the world.  #1 is much worse, and yet-to-be-reported #3...
<gary_poster> large.json works fine locally...
<gary_poster> as does sample.json
<bac> so chrome on os x thinks uistage is written in galacian and offers to translate it.
<gary_poster> yeah, linux too
<gary_poster> I reported it to google <shrug>
<gary_poster> not sure what we would have done to cause that
<benji> gary_poster: ready to talk when you are
<gary_poster> thanks benji.  bcsaller, downloading on uistage and locally (shift d) is not working for me.  it causes a relogin for me.  that's realtively minor compared to the fact that uistage shows no services.  could you please figure out what is wrong with uistage and fix it, other than the #1 and #2 I mentioned above? :-)  I am pretty sure that simply restarting the improv on uistage will fix this but I would rather address
<gary_poster>  the problem
<gary_poster> bcsaller, will try out benji's tool in anger to see if I can dupe locally that way :-) will report back.  benji, wanna join on guichat and you can talk me through it, and I'll review while I'm at it, and then we'll talk about the rest?
<benji> gary_poster: sounds good
<bcsaller> gary_poster: I can look at it now
<gary_poster> thank you very much bcsaller
<bcsaller> app.db.services.size() === 121, someone may have exceeded some operational limit we didn't know about, thats out of the bounds of our use cases
<rick_h_> abentley: ping, in checking out the api1 changes I notice we lost the count and such in search results? http://manage.jujucharms.com/api/1/charms?text=cassandra vs https://pastebin.canonical.com/91727/
<abentley> rick_h_: looking.
<abentley> rick_h_: No, I don't think API 0 ever supported that, just the pre-0 API.
<rick_h_> abentley: ah ok then wasn't used/won't be missed. 
<rick_h_> abentley: just checknig around if it was used or not. thanks for peeking
<abentley> rick_h_: np.
<bcsaller> gary_poster: export currently only works with sandbox as it defers to the backend of the impl. Improv gets the 'exportEnvironment' call and resets the connection on error. We could easily make the fakeback impl the real clientside impl, but that wasn't the intention. We can also limit the binding of the hotkey based on mode, but that also isn't the case 
<abentley> rick_h_: You can still get that output at http://manage.jujucharms.com/search/json?search_text=cassandra for now.
<gary_poster> bcsaller, ah ok cool, makes sense thanks
<gary_poster> bcsaller, you looking at crazy service stuff now?
<bcsaller> gary_poster: I suspect someone added a ton of them, there are only something like 140 or 150 units so its mostly services of 1 unit
<bcsaller> ahh, but now size is zero
<bac> gary_poster: r 689 seems responsible for the left bar but not the notifications
<rick_h_> bac: white bar fix coming in a sec. Pushing through lbox now
<bac> rick_h_: oh, cool.  what was it?
<gary_poster> bac, 689 is doc branch from nicola?
<bac> sorry, 690
<bac> i confused myself with the reverse cherry pick
<rick_h_> bac: putting the browser behind a FF means the code that it ran on startup to hide the minified version wasn't run. :)
<gary_poster> ah ok thanks bac
<gary_poster> bac, error notifications bug is older?
<bac> gary_poster: yes.  will look for it now
<gary_poster> cool thanks
<rick_h_> bac: gary_poster k, white bar fix landed in trunk. 
<gary_poster> awesome thank you rick_h_ 
<bac> gary_poster: the notifications occlusion is due to r688
<gary_poster> bac, ok, thank you.  fix obvious, or should you ask ben for direction?
<bac> gary_poster: haven't found it yet.  will bug ben if needed.
<gary_poster> thanks
<bac> hi bcsaller, in r688 (Hotkey extensions) you added 'overflow:hidden' for .navbar.  that causes the notification panel to be cut off below the navbar.  i can revert that css change but what were you trying to accomplish?  will doing that revert break something else you were fixing?
<bcsaller> bac: ahh, I didn't think that should have that side-effect. When you shrink the width of the viewport a white bar cuts the screen in half w/o something like that fix. This happens alot with the chrome dev tools open on the right side 
<bac> ok, let me try to duplicate
<bcsaller> bac: different css/clipping overflow on a child element might work, other options might be to position:absolute the notification popup and give it a z-index
<bac> ok
<bcsaller> the positioning would need to listen on the viewport size changes events so a pure CSS solution might be better if its quick to find
<bac> bcsaller, gary_poster: i'm going to land a fix to the notications panel now, though i have reproduced the problem ben talks about.  i'll make a card for fixing it.
<gary_poster> bac cool thank you
<gary_poster> bac, http server has LGTM with trivial
<bac> gary_poster: thanks
<gary_poster> bcsaller, should I just restart improv do you think?  or are you trying to figure out why the gui is exploding with 80+ services?
<bcsaller> app.db.services.get('displayName')
<bcsaller> it looks like its back up to 123 again, not sure if someone is adding those or if they are stale in the system
<bcsaller> I'd save the improv log or some of it if possible 
<bcsaller> gary_poster: ^^
<gary_poster> bcsaller, there is no improv log afaik
<bcsaller> gary_poster: it would be in the console, for example if it was being run in tmux, I don't know for sure, if its detached then there is little to be gained that way 
<gary_poster> detached
<gary_poster> killed and restarted
<gary_poster> uistage is AOK for now, thanks all
<hatch> sorry if someone was trying to msg me - I just noticed that the internet was down again, not sure how long I was off for
<gary_poster> uistage was not AOK for long :-P
<hatch> poor uistage
<gary_poster> bcsaller, uistage has only five services now and does not render :-/
<gary_poster> bcsaller, I can dupe locally with benji's branch and collected websocket output http://pastebin.ubuntu.com/5711447/
<gary_poster> so it's something to do with those messages
<benji> yay for websocket logging
<gary_poster> :-)
<gary_poster> thought you might like that
<benji> yep
<bcsaller> Yeah, I like the dev tools, network websocket,  frames thing as well for this but recording it makes it simpler to talk about 
<gary_poster> huh
<gary_poster> it's just the delta
<bcsaller> gary_poster: what do you mean?
<bcsaller> I'm able to run large.json on current improv and trunk locally fine
<gary_poster> yes, can only dupe with benji's tool atm.  with that tool discovered that after only the delta, you still do not see services.  when I restart improv on uistage it works for a bit.  I have that delta and am comparing.
<bcsaller> gary_poster: ahh, good
<gary_poster> yes, the delta diff is the issue.  new pristine delta alone renders fine.  
<gary_poster> good version
<gary_poster> http://pastebin.ubuntu.com/5711485/
<gary_poster> bad version 
<gary_poster> http://pastebin.ubuntu.com/5711488/
<gary_poster> bad version has annotations...
<gary_poster> mere presence of annotations does not trigger
<bac> gary_poster: can you ssh to uistage?
<gary_poster> bac, yes
<bac> hmm, i can't.  must not like my key
<bac> had no problem last week
<gary_poster> bcsaller, Makyo I see problem with uistage.  trivial but annoying.  guichat, and one of you can take the solution.
<bcsaller> joining
<bcsaller> server errors
<Makyo> Yeah, weird.
<gary_poster> bac please remind me tomorrow and I will set up
<gary_poster> yeah same here
<bcsaller> actual server error
<bcsaller> heh
<Makyo> gary_poster, bcsaller, Sorry, dryer guy showed up (and he's inexplicably super angry).  Let me know if I can do anything to help
<gary_poster> Makyo, !! :-( sorry,  ok thanks,
<gary_poster> bac trying jenkins rerun; looks crazy
<Makyo> Alright, have a dryer.  Doing laundry, because I'm down to T-shirts *horror*
<hatch> so what makes a dryer guy inexplicably angry?
<Makyo> He left pre-explication. :)
<hatch> haha
 * Makyo dogwalks, now that angryguy is gone.
<hatch> I know a retired guy who fixes appliances for fun
<hatch> gary_poster, still around?
#juju-gui 2013-05-29
<benji> ooh, the AttributeError: 'NoneType' object has no attribute 'clone' problem is aparently a symptom of a change to PyPI (they put it behind a CDN)
<gary_poster> hey bac, it looks like your branch *might* have broken jenkins in some new exciting way
<gary_poster> it failed twice in the same way since your branch
<gary_poster> I have no idea why your branch would trigger that error :-/
<gary_poster> but could you do a bit of investigation and see if you can dupe, maybe by running the tests locally
<gary_poster> ?
<rick_h_> benji: I thought I got that before this. Cool if there's a fix though. 
<rick_h_> benji: the thing is that it's loading a package that's locally cached isn't it?
<benji> no fix yet
<benji> I don't think we've set up any local caching.
<rick_h_> benji: the archives directory?
<rick_h_> with closure-linter and selenium?
<rick_h_> I was thinking that path was off when running in the new dir lbox creates
<benji> Maybe.
<rick_h_> benji: ah, nvm. Reading my log it's installing closure_linter, but failing on the dep python-gflags so yea...pypi
<benji> I just installed python-gflags into my system (apt-get install python-gflags) and it is happy now
<hatch> morning
<bac> hi hatch
<gary_poster> hey hatch
<gary_poster> bac I talked to you in your absence
<gary_poster> you did not reply
<gary_poster> <gary_poster> hey bac, it looks like your branch *might* have broken jenkins in some new exciting way
<gary_poster> <gary_poster> it failed twice in the same way since your branch
<gary_poster> <gary_poster> I have no idea why your branch would trigger that error :-/
<gary_poster> <gary_poster> but could you do a bit of investigation and see if you can dupe, maybe by running the tests locally
<gary_poster> <gary_poster> ?
<bac> gary_poster: ok, will do
<gary_poster> thanks bac
<benji> The PyPI CDN issue has been fixed.
<rick_h_> yay
<rick_h_> luca: jcastro heads up, url change for using the browser on uistage: https://jujugui.wordpress.com/2013/05/29/yesterday-we-landed-a-change-that-moved-the/
<jcastro> rick_h_: ok so I need to change the link on the website?
<rick_h_> jcastro: ? which website?
<jcastro> juju.ubuntu.com
<jcastro> has a link to ui stage
<rick_h_> jcastro: no, that's just to view it with the browser
<jcastro> oh, ok, nod
<rick_h_> jcastro: for your own 'how does it look, qa, wtf'ness
<rick_h_> jcastro: vs uistage:/bws/sidebar/...
<jcastro> rick_h_: I was expecting you to need the link updated, because IS just updated the website like 10 minutes ago. And you know how fate rolls.
<jcsackett> rick_h_: branch is actually updated now: https://codereview.appspot.com/9828043
<rick_h_> jcsackett: rgr, will look. Thakns
<jcsackett> hatch, Makyo: any chance one of you could take a look at https://codereview.appspot.com/9828043 ? need a second review.
<Makyo> jcsackett, sure.
<jcsackett> thanks Makyo.
<abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/shrink-mongo/+merge/165928 ?
<sinzui> abentley, this is the entire module that does the checking in pocketlint. http://bazaar.launchpad.net/~sinzui/pocket-lint/trunk/view/head:/pocketlint/formatcheck.py
<abentley> sinzui: Cool.
<rick_h_> jcsackett: feedback inbound
<benji> anyone up for a second review? https://codereview.appspot.com/9657046/
<teknico> benji: looking
<benji> hatch: is your "Create document about angular vs yui refactoring" card in review because you want people to review it?  If so, I have a moment to do so.
<benji> thanks, teknico 
<jcsackett> rick_h_: any examples of a docstring for @event with paylod? can't find one.
<rick_h_> jcsackett: yea, hmm. There were examples docs we're supposed to use for the @event stuff. Trying to see if I can find it.
<hatch> gary_poster, http://en.wikipedia.org/wiki/Anders_Hejlsberg yeah it was C#
<gary_poster> hatch, :-) cool
<rick_h_> jcsackett: per http://jujugui.wordpress.com/2013/04/26/weekly-update-matt-start-using-yuidoc-event-yuidoc/ since you don't publish the event I'm wrong. 
<rick_h_> jcsackett: so nvm I guess. 
<jcsackett> rick_h_: ok.
<teknico> benji: how about a quick call about your branch?
<Makyo> jcsackett, FYI, something's up with net, I've been pulling from npm for about 30 mins.  Promise I'm reviewing :)
<jcsackett> Makyo: dig. thanks for the update, and sorry for your net woes. :-)
<rick_h_> anyone else seeing giant request times to npmjs.org? https://registry.npmjs.org/uglify-js/1.3.4 for instance is 20s to load for me atm
 * rick_h_ regrets the make clean-all right now
<Makyo> rick_h_, ^^^
<Makyo> Guess it's not just me.
<rick_h_> Makyo: ah, missed the npm part of your comment. 
<rick_h_> Makyo: ok, glad it's not just me then
<rick_h_> Makyo: wasn't there work going on to make npm an offline cache for installs?
<rick_h_> Makyo: or did that never get into play. Or just on the charm?
<Makyo> rick_h_, I thiiink some set up a local cache for themselves a while back, but I don't think it ever became part of the actual process.
 * rick_h_ fears doing a lbox submit ... 
<benji> teknico: I just noticed your message.  Sure, how about the regular place?
<teknico> benji: guichat? ok
<gary_poster> rick_h_, Makyo benji: benji did that
<rick_h_> jcsackett: return review? https://codereview.appspot.com/9841044 hatch or bcsaller as a second please? Ignore the updated generated .json files used for sample data in the tests. 
<gary_poster> npm cache
<gary_poster> but for distributions
<gary_poster> in the charm
<gary_poster> not usable for developer
<rick_h_> gary_poster: ah ok, so not in dev. 
<hatch> rick_h_, ok I can take a look
<gary_poster> right
<rick_h_> hatch: thanks, should make your life easier. 
<hatch> I hope I don't have to QA that json file :P
<rick_h_> sinzui: abentley though in testnig I'm still getting 1.5-2s requests to /interesting so might be cool to start up some caching or such on m.j.c coming up
<rick_h_> hatch: I said not to :P
<rick_h_> hatch: two .json files generated, just trust me, they're valid ones from m.j.c 
<hatch> haha
<sinzui> rick_h_, against m.jc ?
<rick_h_> sinzui: yes
<gary_poster> manage.jujucharms.com
<gary_poster> I like it
<rick_h_> sinzui: that's locally so might not be perfect test case, but noticed it a lot in doing QA
<sinzui> rick_h_, when I browse m.jc, I often see my requests timeout ...well a timeout between apache and the proxies
<rick_h_> sinzui: and the caching from jcsackett will help as well, but still. 2s for the request and .5s for the transfer was longer than I'd hoped
<rick_h_> sinzui: :(
<abentley> rick_h_: How does that compare to requests for static files on m.j.c?
<rick_h_> abentley: looking
<rick_h_> abentley: so each icon is sub 300ms for instance
<rick_h_> abentley: the /interseting OPTIONS request was 130ms while the actual data was 2.3s in this sample load 
<rick_h_> that's 130ms including network time
<abentley> rick_h_: Gotcha.
<sinzui> damn. I cannot get m.jc to show me the timeout now. I bet its meager cache is hot right now
<rick_h_> so still all nice and better, but might be nice to stick a card/bug to look for low hanging fruit to optimize
<abentley> rick_h_: So it sounds like a genuine perf issue.  We could address it with caching, but we might be able to optimize in other ways.  I would prefer that, because that would also help users who hit /interesting when it's cold.
<sinzui> abentley, /interesting is getting a lot of related charms at this moment. Your current card may address that
<rick_h_> abentley: definitely. didn't mean to say we should implement X, just investigate. Once this branch lands we'll see it a lot easier. 
<hatch> rick_h_, donezo
<rick_h_> hatch: yay thanks
<hatch> don't thank me yet!
<rick_h_> well, maybe yay. Depends on what you found 
<hatch> jk ;)
<hatch> lol nothing to serious
<gary_poster> jujugui call in 10; kanban now pls
<rick_h_> hatch: replies inbound. I disagree :/
<hatch> NEVA!!!
<rick_h_> hatch: let me know if you need more convincing :P
<hatch> I do, I have a very thick skull
<hatch> :P
<hatch> haha going to read now
 * rick_h_ goes to get the 'agree with rick curse you' bat
<hatch> I think we can reach some middle ground
<hatch> investimagatering
<rick_h_> hatch: k, welcome to have a chat post-stand up 
<gary_poster> jujgui call in 2
<abentley> adeuring: now that there's a 'promulgated' attribute, I think charmworld.models.is_reviewed should be removed, or redefined in terms of the promulgated attribute.
<abentley> adeuring: similarly for reviewed_clause
<abentley> in ElasticSearchClient.
<adeuring> abentley: yes, renaming would make sense. I am not sure about removing the function -- could it happen that we redefine reviewed/promulgated/... again?
<abentley> adeuring: It's conceivable that we'd redefine 'reviewed', but I don't think that justifies keeping a one-liner function, especially since I think changing the def is unlikely.
<adeuring> abentley: well, changing this one-liner helps to change several views at once :)
<adeuring> I prefer to have this sort of "common definition", even in trivial cases
<hatch> rick_h_, replied - lemme know if you would like to discuss 
<rick_h_> hatch: guichat?
<hatch> yup
<rick_h_> hatch: nvm, new chat
<hatch> it's full
<hatch> :)
<hatch> r u making the new room or am I? :)
<rick_h_> hatch: tried to make one and invite you. You no show
<rick_h_> hatch: https://plus.google.com/hangouts/_/762e94644ca67de98ca216ec502111c4f338a3b2?hl=en
<abentley> adeuring: sure, and the main virtue of the "promulgated" attribute is that it can act as that common definition.  It would be even better if it were called "reviewed" instead of "promulgated"-- that would make it obvious that we should update its definition if the definition of "reviewed" changes.
<adeuring> abentley: ummm... what if the meaning of promulgated and reviewed diverges? I chose promulgated as the attribute name because it refects the things done by ptomulgation script
<gary_poster> sinzui, hey.  I have two topics.  First, I wanted to check with you as to where we are with m.j.c stability.  We had said that it would be ready to be used in production for the gui by the end of this week, as I understood it.  is that what you understand, and is that still on schedule?  Jon gave me an overview and it sounded like everything was well in hand with the possibly significant exception of mongo insanity.
<gary_poster>   That made me a bit nervous.
<jcsackett> gary_poster, sinzui: specifically, as i understood from standup, we're still looking at the mongodb size which has given us problems.
<gary_poster> Second topic was making sure that Orange and GUI are aligned in terms of incremental delivery.  While it is true that we have a big deadline and unveiling for your work in a couple of months, the GUI has many incremental deliveries before then, and we want to make sure that Orange squad is comfortable and happy and aligned with the fact that their work will be released incrementally, frequently and much sooner than 
<gary_poster> a couple of months from now.
<gary_poster> ack thanks for clarification jcsackett 
<sinzui> gary_poster, we have sorted the db issue. We still see a performance issue relating to large data transfers that will be fixed, but I think there may be other undiscovered performance issues as hinted in the channel a few hours ago
<gary_poster> sinzui, fantastic about db issue.
<rick_h_> jcsackett: not sure if you saw but I talked jeff into letting my dirty tricks go, care to second please? https://codereview.appspot.com/9841044
<jcsackett> rick_h_: looking. nervous about "dirty tricks" though. ;-P
<sinzui> gary_poster, We also need to ensure all charm data is consistent. That is to say, charm rules have changed over time, but not all charms have been updates. I want this fixed this week. I think that will give us the reliability we need
<rick_h_> jcsackett: bwuhahahahaha
<gary_poster> sinzui, reliability fixed this week: also great.  performance and reliability: will we have m.j.c updated our Friday morning so we can evaluate it and see if it is performant enough to reveal the charm browser (without flags) in the GUI?
<sinzui> yes, let's do that
<gary_poster> cool thanks sinzui 
<gary_poster> sinzui, made appt for Friday.  Gave you edit privs.  Feel free to invite all of orange, move, or do what you will.  You'll coordinate with IS to get m.j.c updated for then?
<sinzui> fab. Thanks gary_poster
<gary_poster> ty
<teknico> benji: I forgot to mention in the review that you need to add the new doc filename to docs/index.rst, for it to show up in the generated docs
<benji> teknico: that's a good one.  I already submitted the branch though.  I'll do a quick self-reviewed branch to add it to the index.
<teknico> benji: sorry for the delay :-)
<benji> teknico: we really need a test that would have failed when I added a doc file but forgot to stitch it into the doc tree
<benji> and we need another test that shows that the docs build with no errors/warnings
<teknico> benji: uhm, interesting notion. tests about docs? what next, docs about tests? OHWAIT
<benji> :)
<jcsackett> jujugui: since having to recreate my juju-gui environment, make devel sometimes requires sudo...have i screwed something up, or is that just the way it is?
<gary_poster> the former, I hope.  I don't
<benji> that is new behavior to me
<jcsackett> ok. i'll poke around and see what's happened. AFAICT it asks for sudo when doing npm get.
<rick_h_> jcsackett: sec, got a fix for you
<jcsackett> hurray
<jcsackett> rick_h_: make this go away, and you will be my new hero.
<rick_h_> jcsackett:  sudo chown -R rharding:rharding ~/.npm ~/tmp/ 
<rick_h_> jcsackett: only s/rharding/yourUser
<rick_h_> jcsackett: when you follow the hacking dock and sudo npm install the couple of deps, it creates those dirs owned by root:root and later it tries to reuse them for local use and can't
<rick_h_> jcsackett: I hit it every time I setup a new lxc/etc
<jcsackett> rick_h_: fixed it. fantastic, thanks.
<abentley> adeuring: Then IMO "promulgated" should change to with the definition of "reviewed", because "promulgated" itself is not valuable info-- it is redundant with store_url.
 * hatch lunching
<adeuring> abentley: Might make sense. The main issue is probably that we need to define better what promulgated/reviewed/approved/whatever means, and how we want to represent it in code and data. But I am meanwhile a bit tired, let's discuss this another day
<rick_h_> benji: ping, I'm trying to lbox submit and the tests complete, but right after I get a error about tornado missing in test/websockietreplay.py?
<rick_h_> benji: did that get added to a deps list or am I missing a manual step for lbox submit and the copy/dir it creates?
<rick_h_> benji: https://pastebin.canonical.com/91804/ is the trace from submit. 
<rick_h_> benji: ah, nvm. It's a sys package so nothing would have installed it. any reason we can't use a download-cache/locked python version of these things? Isolate them more and not need manual steps to build?
<rick_h_> benji: and curious how you got around the problem with the clone then so I can do this in an lxc vs my main system. 
<benji> rick_h_: I'm back from lunch and readying the scrollback.
<rick_h_> benji: rgr
<benji> ??
<rick_h_> benji: basically the how to get around the clone thing I think will fix things for now
<benji> rick_h_: I thought the recent PyPI CDN fix would have made that go away.  Hmm, you may have cached broken downloads from PyPI.
<benji> also, my work-around was to install python-gflags into the system (apt-get install python-gflags, IIRC)
<rick_h_> benji: yea, tried that but when I go to run a submit, it hits the virtualenv directory for it and fails to find it
<rick_h_> we're in this strange with a venv, but with system packages mode that isn't sync'd right it seems
<benji> rick_h_: perhaps killing the virtualenv would help; I clobbered mine mightily while fighting the same problem
<rick_h_> benji: yea, doing another make clean-all, but this is happening on lbox submit so it's creating the whole directory, merging trunk, etc all outside of my control 
<benji> I would much rather use buildout for this.  It is a bit harder to use that pip, but it has much nicer tools for making reproducable builds.
<rick_h_> we use pip with it in charmworld. 
<rick_h_> http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/head:/Makefile#L78
<rick_h_> ok, will keep hacknig at it then. I thought had you found a different fix. 
<benji> I wish I could be of more help.
<rick_h_> benji: so then if you don't have this what version of virtualenv do you use right now? I'm wondering if it's pre "all venvs will be --no-site-packages" change perhaps
<rick_h_> benji: thus why your installing of the gfalgs system wide works while mine doesn't
<rick_h_> err, gsflag or whatever it is
<benji> rick_h_: oh! that's probably it; on your advice I installed a newer virtualenv (in my account, not system-wide, but to the same effect)
<rick_h_> benji: ok, so when lbox submit runs is it using the older system one or the newer local one?
<benji> newer, local
<hatch> little concerned my laptop harddrive is cookin!
<rick_h_> time for an upgrade!
<hatch> I can feel the heat radiating off of it
<rick_h_> cook cook cook
<hatch> lol I have to completely disassemble the laptop to get to it. This thing needs to last until the new MBP comes out
 * hatch wants haswell
<bac> yay, jenkins is happy again
<bac> i wish i could report i fixed it and this will never happen again.
<rick_h_> bac: I accept your report and celebrate wildly :)
<bac> rick_h_: you better do it quickly before the next run of jenkins roulette
<hatch> lol
<gary_poster> :-/
<hatch> to add another script to the assets directory and have it combined in much like d3 do I simply need to add it to JSFILES in the makefile?
<bac> benji: on CI tests, i am seeing periodic failures on IE10 for set_test_result.  the call to connection.request results in getaddrinfo failing trying to get info for saucelabs.  (due to a bug it confusingly report "no such file or directory").  you have any thoughts?
<hatch> hmm nothing i try will get the makefile to build angular into the all-yui.js file
<hatch> O K what's the trick?
<rick_h_> hatch angular?
<hatch> to include assets into the bundle
<rick_h_> hatch the js frsmework?
<hatch> yeah
<hatch> is the trick to create a link to it in the assets dir?
<rick_h_> ok color me ingerested on whats up with pulling in another framework.
<rick_h_> bah stupif d tablet keyboard
<hatch> prototyping some stuff
<hatch> but it's no good if I have to manually include a huge script tag in the index.html
<hatch> lol
<rick_h_> jcsackett: ping, still around?
<jcsackett> rick_h_: yup.
<rick_h_> jcsackett: so I was poking at the network graph on staging http://uistage.jujucharms.com:8080/:flags:/browser_enabled/ and noticed that it's loading spin.min.js outside of the rest of the js?
<rick_h_> jcsackett: is that expected or maybe a miss in adding the file to the list of known modules, merge-files, etc?
<jcsackett> rick_h_: that's used for the intiial spinner when you open jujugui; i haven't monkied with that b/c my attempts to do so broke it locally. i have a cleanup branch that changes that initial spinner to use the spin YUI module and kill spin.min.js
<rick_h_> jcsackett: ah, makes sense I guess. I don't have a before/after atm so it just jumped out at me
<jcsackett> rick_h_: yeah, anything with spin.min.js predates my work--i left it alone while updating our spinners.
<Makyo>  *dogwalk*
#juju-gui 2013-05-30
<gary_poster> hey hatch, why don't you share your doc with bcsaller so he knows where you are going
<hatch> oh sure thing
<hatch> the documentation for angular sure is horrible
<gary_poster> that's not good hatch :-(
<hatch> no definitely not
<hatch> there is ample documentation/blogs on how to write an application starting from a typical index.html
<hatch> but almost none on doing what we are doing
<gary_poster> I see :-/
<gary_poster> I hope that is not a bad sign
<rick_h_> hatch: I'd love a copy too please :)
<hatch> hmm
<hatch> think you deserve it?
<hatch> :P
<rick_h_> hatch: hey, I've got to have some bonus points from the api change landing today :P
<hatch> haha
<hatch> pm'd the link
<fwereade> bac, quick question -- do you use the results of AddServiceUnits and similar calls, or do you just let the watchers give you the info you need?
<fwereade> frankban, gary_poster: can you offer a suggestion re my question to bac above?
<frankban> fwereade: morning, could you repeat the question?
<fwereade> frankban,  quick question -- do you use the results of AddServiceUnits and similar calls, or do you just let the watchers give you the info you need?
<frankban> fwereade: we use the results, yes
<fwereade> frankban, interesting -- how do you reconcile them with changes from the watcher?
<fwereade> frankban, it's just 2 parallel paths, I guess, so the immediate feedback lands immediately and you probably get an already-handled change out of the watcher soon?
<frankban> fwereade: we handle possible errors, we give feedback to users before the delta stream arrives. when the watcher notifies the real changes, we update our internal db
<fwereade> frankban, ok, I think I asked badly
<fwereade> frankban, ServiceAddUnits returns a list of units
<fwereade> frankban, what do yu use those units for?
<frankban> fwereade: looking
<frankban> fwereade: in case of errors, we notify the user, in case of correct response, we add the units to the db. The unit names are keys in our db, so, when the delta arrives we can do updates or inserts as required
<frankban> fwereade: the db meaning the model layer used internally by the JavaScript app
<fwereade> frankban, ok, so at least in the single-user case it's just a way of getting slightly-quicker inserts, so the subsequent insert event is effectively dropped?
<frankban> fwereade: the info from the watcher are used to update the db with all the required information. e.g. AddServiceUnit response -> just add unit names in the db with state "pending". delta -> update those records with all the info included in the stream
<fwereade> frankban, ahhh! sorry, it's just the new names
 * fwereade sees, andfeels a bit silly
<frankban> fwereade: no problem
<jcsackett> jujugui: is there a way to see what revision uistage is running?
<gary_poster> jcsackett, yes.  getting url
<gary_poster> jcsackett, http://uistage.jujucharms.com:8080/juju-ui/version.js
<hazmat> not sure there's a cronjob in place there.
<hazmat> incidentally the 8080 is finally redundant
<gary_poster> there is not, pretty sure
<gary_poster> oh cool
<jcsackett> gary_poster: awesome, thanks.
<gary_poster> welcome
 * hazmat puts a cron in place
<jcsackett> hazmat: yup, removing 8080 works.
<hazmat> gary_poster,  do you think it should be more than bzr up && make prod ... ie clean, up, make ? 
<gary_poster> hazmat, make clean has not bitten us much.  conflicts on config changes have bitten us much more
<gary_poster> hazmat, so, for cheap improvement, bzr up && make prod is sufficient.  if you are going for gold, you could make a fresh branch while the other one continues to serve, run make prod, drop in a replacement config file, and move the dir over. :-)  I appreciate the simple one.
<hazmat> gary_poster, simple one done
<gary_poster> perfect thanks hazmat
<gary_poster> jcsackett, ^^ we're on 699 now
<jcsackett> gary_poster: thanks.
<benji> Is it "make clean" that has bitten us or "make clean-all"?  I ask because I hate "make clean"; it should instead be as clean as "-all".
<gary_poster> benji, neither
<gary_poster> on uistage
<gary_poster> the only thing that has bitten us in my memory (and I'm one of the two that have to do the surgery) is the config conflict
<benji> darn, I'll have to look for another reason to hate it
<gary_poster> :-)
<hazmat> at the moment the config delta is 2 lines for credentials in app/config-prod.js
<benji> instead of "clean" and "clean-all" we should have had "clean" and "clean-some" :)
<bac> "scrub" and "just move the dirt around"
<gary_poster> :-)
<hazmat> on first load the gui seems to be making two identical queries to jujucharms, and there's a few  nav images that look like they could be sprited.
<rick_h_> hazmat: yes, the query is done on load and makes an OPTION and follow up request. Those will go away when the browser is pulled from the feature flag
<hazmat> rick_h_, ic.. and the backend doesn't distguish from options atm, so it does the query/result twice. cool re feature flag, is it still doing the options with the backend responding approriately? 
<rick_h_> hazmat: no, the new api splits OPTIONS from the second request correctly
<rick_h_> hazmat: you can see it with a /:flags:/browser_enabled/ on the url
<rick_h_> hazmat: we didn't go back and update the old view code since we're trying to replace it. 
<hazmat> sounds good
<hazmat> although looking at it with the features flag enabled.. there's some suboptimal image loading.. every charm icon is treated as distinct even when its not, causing redundant image loading.
<hazmat> hmm
<rick_h_> hazmat: 'treated as distinct'?
<hazmat> rick_h_, openstack icons for example are the same but downloaded different.. i'm trying to remember some of the things i did for www.wdl.org.. ie. image heavy site.
<hazmat> there was some image strip tile cutting, but its not particularly helpful here.
<rick_h_> hazmat: well, we don't know that. We just load the icon that the charm provides and have no insight as to the actual pixels
<hazmat> mostly about lazy image loading
<rick_h_> hazmat: basically we load them, but they're the last in the request and most are hidden by the collapsed categories so it appears a lot faster than it is
<hazmat> right now we load images for the entire result set, instead of what's visible..
<hazmat> ic
<rick_h_> hazmat: right, but you don't see them load, and then the browser will cache them since they're unique urls
<rick_h_> hazmat: the waterfall makes it look a lot worse than the real use experience. 
<hazmat> rick_h_, there's still quite a few optimizations though... ie.. http://uistage.jujucharms.com:8080/sidebar/search/~sidnei/precise/moztrap-0/:flags:/browser_enabled/ 
<sinzui> orangesquad, any looking at staging? Know why mongodb/0's agent is down?
<hazmat> will load moztrap json 4 times.. and still loads icons for the default result set, instead of the actual
<hazmat> rick_h_, looks nice though
<rick_h_> hazmat: definitely. We're not completely done. We just landed caching of switching simple view changes (fullscreen to sidebar and back) and removing the icon svg from the api data passed yesterday
<rick_h_> hazmat: so now that the icons are loaded as normal <img src=> we can start looking at optimizing that more with better headers on the back end, etc
<abentley> sinzui: I hadn't seen.
<rick_h_> hazmat: feel free to file a bug and we can look into some more tweaks going forward. Right now trying to finish features we require like the fallback to category icons, related charms
<sinzui> looks like mongodb/0 fell over 7 hours ago according to the app.log
<abentley> sinzui: I wonder what happens if we reboot it?
 * sinzui pays mongodb/0 a visit
<sinzui> abentley, might help. The db appears to be up locally. I can query it and get sensible numbers
<sinzui> I wonder if I can just restart the agent
<abentley> sinzui: My problem is I don't know what program is actually the agent.
<sinzui> me neither.
<sinzui> my hope for service juju-agent restart was dashed
<abentley> sinzui: From charmworld/3, looks like python -m juju.agents.machine
<abentley> sinzui: and juju.agents.unit
<sinzui> abentley: juju.errors.NoConnection: No zookeeper connection configured.
<sinzui> juju-admin will let me initialize a zookeeper hierarchy, but I think would be BAD
<abentley> sinzui: The full commandlines are:  https://pastebin.canonical.com/91851/
<abentley> sinzui: But if we can't find the init file, I think a reboot is better.
<sinzui> I see it
<sinzui> Same error about zookeeper connection
<sinzui> abentley, restart?
<abentley> sinzui: go for it.
<sinzui> abentley, I see "started" now
<sinzui> oh, now I see charmworld has an es relation error.
<bac> hi gary_poster, i was looking at the 'make custom ppas' card.  can we do a pre-imp?
<gary_poster> bac, sure
<bac> gary_poster: cool, in 5?
<gary_poster> bac, cool.  guichat is open, I think.
<rndm> is there a way to "deploy-to" from the gui?
<bac> gary_poster: you there?
<rndm> maybe i don't get what's going on but it seems like there's a 1-1 correspondence between services and machines
<rndm> that might be my lack of understanding, however
<gary_poster> rndm, no.  we won't support jitsu deploy-to ever, at least in my plans (except that we show it just fine).  we will support containerization in juju core this cycle, which is the expected long-term approach to the use case.
<rndm> ok, thanks
<rndm> lack of deploy-to isn't the problem for us, it's the 1-1 correspondence. when does this cycle end?
<abentley> sinzui: It looks like promulgated is not a provided attribute in http://staging.jujucharms.com/~charmers/precise/rails/json
<abentley> sinzui: basically, it's not set in the db.
<sinzui> abentley, yeah. I don't see it in the db for juju-gui
<gary_poster> rndm, 1-1 correspondence can be addressed now with jitsu deploy-to (in pyJuju) or --force-machine (in juju core).  juju gui displays this fine, we just don't support deploying with it yet.
<sinzui> I think the short_url for juju-gui is wrong. I see a ~ where I expects a simple path.
<gary_poster> rndm, that's the path for what you want now.  containerization will come sometime in the next 5 months, and the hope is that it will come within the next two months AIUI.
<rndm> thanks. i was asking when because i prefer containerization but deploy-to is okay for now
<gary_poster> cool
<sinzui> abentley, the exception log hasn't had an entry since I brought up mongo and es. The applog shows the 5 missing data branches and the 1 FileExists errors that we see every ingest. Thus i think injest is doing its job, but explicit "promulgate" just doesn't work
<abentley> sinzui: It seems like it could be aborting early.
<rick_h_> jcsackett: so looks like I can't use the icons from huw's branch. So moving them and spriting them will have to live in your branch only. 
<Makyo> Tests pass!  Further proof that I don't understand embedding as well as I should!
<frankban> Makyo: cool! tests passed for me too, maybe for the same reason?
<Makyo> frankban, Not sure.  This was embedded structs causing weird behavior that I still really don't understand.
<jcsackett> rick_h_: moving them sure; spriting them is pretty out of scope for what i'm doing. what blocks you from moving forward on that?
<benji> rick_h_: I'm trying to add a subapp, but I apparently haven't found all the places that I have to update in order to do so, here is my diff, thus-far: http://paste.ubuntu.com/5716969/
<rick_h_> jcsackett: they're not the right images I need. I've got the images I need in the assets dir of docs
<rick_h_> benji: looking
<jcsackett> rick_h_: ah, so you'll sprite with those, and i'll just move the svgs in mine.
<rick_h_> jcsackett: rgr
<benji> (this is one of the things that frustrates me when working on our app, it is not clear to me what I have to do to add a new module, and looking at existing modules never seems to give me enough information to crib)
<rick_h_> jcsackett: but the objection of adding 6 new requests for those images still stands in huw's branch so they need to get turned into png and sprited. 
 * benji will be right back.
<rick_h_> benji: subapps are init'd in the Y.App initializer
<jcsackett> rick_h_: then i think my branch is blocked? b/c there's no point in me spriting and then you spriting. sounds like my work is dependent on yours.
<benji> rick_h_: I don't follow.
<rick_h_> benji: sorry, guessing the first part of that diff is in the intializer 
<rick_h_> benji: guichat?
<rick_h_> benji: I mean that looks right. can you push the branch up to make it easier to debug. Wondering if there's a diff issue cauing it not to load?
<benji> rick_h_: pushed to lp:~benji/juju-gui/websocket-logging
<benji> rick_h_: after you take a look we can go to guichat if needed
<rick_h_> benji: rgr
 * benji thinks rick_h_ is drowning.
<benji> or perhaps would like to buy a vowel
<rick_h_> benji: so this 'works' here. It loads, runs init. logs to console that it started
<benji> yow
<rick_h_> benji: what is not working as expected?
<benji> it's not doing that :)
<rick_h_> benji: now I did flip the sandbox because I didn't have rapi running atm
<rick_h_> benji: I guess let me go back adn flip that back and run rapi
<benji> I wonder if there is some build cruft keeping the new thing from being found.  I'll make clean-all and see if it helps.
<rick_h_> benji: sounds good
<benji> are you running "make devel"?
<rick_h_> benji: yes
<benji> k
<rick_h_> benji: same success with the sandbox off and rapi running
 * gary_poster wonders if a subapp is necessary, benji--you might be able to work with something simpler.  <shrug-for-now> ;-)
<benji> gary_poster: maybe.  It looked like an easy way to draw well-defined lines around the functionality; if I ever get it to work I'll let you know
<gary_poster> :-) k
<benji> rick_h_: it was a cache problem
<benji> We *really* need to straighten out our cache story.  These sorts of things are inexcusable.
<rick_h_> benji: +1
<rick_h_> benji: I think I end up running a make clean-all at least once a day just to make sure
<gary_poster> jujugui call in 8.  please update kanban
<gary_poster> benji, if you mean browser cache, we don't have a cache any more.  appcache is gone.  if you mean filesystem copies and Make issues, dunno, but that's not a cache per se.  I have not encountered, but if others have then please identify the issue and escalate it.
<benji> gary_poster: I mean whatever caused my problem ;)  I suspect it was browser cache (though I realize the app cache is gone)
<gary_poster> :-) ok.  we don't send cache headers benji, as you know, so if there's anything wrong, on the bright side it's because we are being too simple.  or because the browsers are broken. :-P
<rick_h_> benji: heads up we did some tweaks to get things watched so http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/config.js might be of interest if you get some other files going
<gary_poster> bcsaller starting without you
<bac> jcsackett: yeah, the hangouts app isn't so stable
<jcsackett> bac: nope. 
<jcsackett> ~bac: if only i had another option.
 * jcsackett probably should buy a webcam for his computer
<abentley> sinzui: someone forgot to set charm_import_limit to -1.  That's why it stops in the middle.
<luca> gary_poster: Hi gary, are you free for a catch up with ale and i?
<sinzui> abentley, easily fixed. That someone must be me. I recreated the app server a few weeks ago
<gary_poster> luca, hey.  was about to lunch.  really quick, maybe? :-)
<luca> gary_poster: sure
<gary_poster> luca trying guichat...
<gary_poster> hangouts is bugier than it used to be :-/
<luca> gary_poster: already in :)
<sinzui> abentley, did you fix the import limit? I see it as -1. Also, I have gzipped the current logs so that we get fresh logs at the start of the next ingest
<abentley> sinzui: I adjusted the limit, then ran a manual ingest.
<abentley> sinzui: I am perplexed that this does not seem to have fixed it.
<abentley> sinzui: oh, setting the limit didn't actually rewrite production.ini â¦
<sinzui> wtf?
<sinzui> abentley, I just looked in the db an {"name": "juju-gui", "owner": "juju-gui"} does not have the promulgated attr yet. Make sense since the config is wrong.
<abentley> sinzui: Yes, it's alphabetically lower than ~charmers/precise/cinder, which I presume is charm 110
<sinzui> :)
<abentley> sinzui: Are you running debug-hooks by any chance?
<sinzui> no
<abentley> sinzui: I don't know why the config change didn't take, then.
<sinzui> yeah, I was just off to read the log
<abentley> sinzui: I just ran debug-hooks and changed the config, and the hook isn't firing.
<sinzui> the log shown two twisted exceptions originating from txzookeeper
<sinzui> abentley, these are the errors from a time I think you called set: https://pastebin.canonical.com/91875/
<abentley> sinzui: Cascading failure maybe?
<abentley> sinzui: Should we try rebooting this one too?
<sinzui> abentley, I'll do it. I cannot think of anything else to do. I'd like to trample zookeeper, but I cannot think of what can do that to full emotional satisfaction
<abentley> sinzui: Tie a steak around its neck and let the zoo's tigers out of their cages?
<sinzui> 284437
<sinzui> How did I just type those numbers? I don't even recognise them
<abentley> sinzui: Yay!  Now I can 2fa as you!
<sinzui> you can, oh, the bloody cat
<rick_h_> he still needs your password :P
<sinzui> charmworld is back.
<sinzui> abentley, I see charm_import_limit = 1000 in production.ini now
<abentley> sinzui: Me too.  I'll set it back to -1
<sinzui> I am still polling the juju-gui charm and hoping for a change
<abentley> sinzui: manually ingesting now.
<sinzui> okay
<abentley> sinzui: Up to 126 charms now.  juju-gui will probably be 127.
<sinzui> abentley, I think there about 134 promulgated charms for precise
<sinzui> surely we have a ways to go
<abentley> sinzui: juju-gui is now listed, but the entry is 501.
<sinzui> well that bad news here is the branch owned by juju-gui now states promulgated == False
<abentley> sinzui: I don't see that.  At http://staging.jujucharms.com/charms/precise/juju-gui/json it has promulgated: true
<sinzui> huh? Do I have to deal with "eventually consistent" with a single db?
<sinzui> abentley, doh, I thought the branch was still owned by juju-gui
<abentley> sinzui: The problem is it doesn't have a short_url.
<sinzui> :(
<sinzui> abentley, it does in the db: /charms/precise/juju-gui
<abentley> sinzui: You sure?  The representation at http://staging.jujucharms.com/charms/precise/juju-gui/json and the exception we get trying to load the page both indicate it's not there.
<sinzui> I see that, but yes I am sure the db knows the charm is promulgated and has the expected short_url
<abentley> sinzui: I find this very confusing, since the /json is a very lightly-edited version of the mongo representation.
<sinzui> yes. I think frustrating it the better word.
<sinzui> I have just reconfirmed ~juju-gui-charmers/charms/precise/juju-gui/trunk is promulgated and has a short url.
 * sinzui ponders restarting the app
<sinzui> abentley, did the force ingest complete?
<abentley> sinzui: Yes.
<sinzui> I will restart the app just to convince myself that we really do not have caching in the app
<sinzui> okay done, and json still shown the app cannot see the short url
<abentley> sinzui: Oh, i get it locally, too.
<sinzui> abentley, /api1/charms/interesting knows the charm is promulgated
<abentley> sinzui: The problem is not the promulgation, it's the short_url.  It's been showing promulgated since it started 501ing.
<sinzui> abentley, what do you mean started 501ing. I think this charm has never 200ed
<hatch-mobile> hello all
<abentley> sinzui: It was 404ing before, IIRC.
 * sinzui nods
<abentley> sinzui: I read the error a little closer, and I think it's due to a missing short_url in another juju-gui charm.
<sinzui> abentley, benji's?
<sinzui> he has a charm with a tab in the metadata.yaml I think
<abentley> sinzui: Could be.
<benji> I hope not.  I'm not a big fan to tabs.
<sinzui> abentley, said charm is on my list of branches to not die on for the branch I want to work on after this arduous QA
<abentley> sinzui: Yes, it is all benji's fault.
<sinzui> benji, no need to panic: ~benji/charms/precise/juju-gui/trunk is one of several charms that are broken, and pages/api calls that include them break
<hatch-mobile> bcsaller did you have a chance to read through that document?
<benji> :)
<abentley> sinzui: So I got out my torch and pitchfork for nothing?
<sinzui> benji, charmworld needs to normalise the data.
<sinzui> I think I want to join an angry mob right now. I bet it would be cathartic.
<abentley> sinzui: I have a fix.  Now I need a unit test.
<sinzui> what? how? where?
<sinzui> a hack to _charm_view?
<sinzui> oh, other short_url
<abentley> sinzui: Yes, a change to charm view so it doesn't try to list invalid charms as alternatives.  https://pastebin.canonical.com/91882/
<sinzui> benji's charm is breaking the promulgated charm
<sinzui> abentley, I cannot see how that excludes a charm without a short URL.
<sinzui> comment 4 in https://bugs.launchpad.net/charmworld/+bug/1180055 shows an example of my hack to deal with missing short_urls: https://bugs.launchpad.net/charmworld/+bug/1180055
<_mup_> Bug #1180055: KeyError: 'short_url' <oops> <charmworld:In Progress by sinzui> <https://launchpad.net/bugs/1180055>
<_mup_> Bug #1180055: KeyError: 'short_url' <oops> <charmworld:In Progress by sinzui> <https://launchpad.net/bugs/1180055>
<abentley> sinzui: This excludes charms that were not processed successfully, because valid_charms_only defaults True, and only charms that weren't processed successfully will lack short_url AIUI.
<sinzui> abentley, I see...valid_charms_only=True
<sinzui> abentley, I think we should ponder a change in my plan for bug 1180055. If ingest uses the model charm which guarantees required attributes, view call sites don't need to be so defensive
<_mup_> Bug #1180055: KeyError: 'short_url' <oops> <charmworld:In Progress by sinzui> <https://launchpad.net/bugs/1180055>
<abentley> sinzui: We should still avoid showing charms that aren't present in the charm store, which is another thing valid_charms_only gives us.
<sinzui> abentley, I think there are two cases. I agree we should not claim this bad charm is an alternate for the one being listed.
<abentley> sinzui: We could remove those.  I would be fine with that.
<sinzui> but If benji wanted to see his charm, m.jc.com could tell him it is evil and must be put down
<sinzui> abentley, your fix does not address this case http://staging.jujucharms.com/~benji/precise/juju-gui where the offending charm is primary content. If we don't want to ever show it, then instead of me creating a model, I think we want the api and charm views to know how to say 404
<abentley> sinzui: I think we should show it in that case.  For all we know, it's a working charm that just has a bad category or something.
<abentley> sinzui: Ideally, we put a warning at the top, and show the page still.
<sinzui> okay. Do you think I should proceed with yesterday's plan?
<abentley> sinzui: I think so.
<sinzui> excellent. I have purpose
 * sinzui wishes his Merida doll would arrive.
<abentley> sinzui: Once we have a class to represent charms, we should switch all the code over to use it.  Once we do that, the internal representation of the charm becomes less important.
<sinzui> yeah, that is my dream.
<abentley> sinzui: Then we probably start generating short_url on the fly, since it's redundant with (promulgated, series, owner, name)
 * sinzui nods
<sinzui> abentley, I can confirm that you dropped the charm-errors collection. I am moving the card
<abentley> sinzui: Thanks!
<sinzui> abentley, I am going to pause before moving Abel's cards to acceptance. I want to review misadventure with fresh eye.
<abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/valid-others/+merge/166578?  Technically, this is a fix for 1180055.  I did not mean to steal your bug.  Sorry.
<sinzui> abentley, yeah, it fixes 50% or more the occurrences.
<benji> umm, the "=" (shouldn't that have been "+") and "-" key bindings are a bit agressive, you now can't type either of those characters anywhere in the environment view (search box, service config, etc.), instead you get zooming all the time
<abentley> sinzui: Oh, it's not a complete fix?  I'll add another card rather than stealing yours, then.
<sinzui> abentley, your change fixes the viewing of every juju-gui charm except for http://staging.jujucharms.com/~benji/precise/juju-gui because we do want to see it and short_url is called in another place in the template
<abentley> sinzui: Cool.
<abentley> sinzui: juju-gui is now displayed properly at http://staging.jujucharms.com/charms/precise/juju-gui
<sinzui> yep. Thank you
 * benji files a bug for the above-mentioned keybinding behavior
<abentley> sinzui: I have determined that download time is a large, often dominant component of retrieval time for manage.jujucharms.com/api1/charms/interesting.  I will look at implementing API2 with a more efficient format.
<sinzui> abentley, understood.
<bac> gary_poster: if you have a sec, i'm trying to ssh to uistage and still cannot.  could you check my key?
<bac> hazmat: ^^
<hazmat> bac, user:root dir:/opt/uistage
 * hazmat double checks 
<hazmat> keys
<hazmat> bac, looks good
<bac> hazmat: did you use ssh-import-id?
<hazmat> bac, root@uistage.jujucharms.com doesn't work for you?
<bac> hazmat: when i attempt ssh it presents all of my keys but rejects them
<hazmat> bac, ic bac@brazos, bac@ubuntu.com and a few others
<hazmat> in authorized keys, works for gary and me.. yes re ssh-import-id
<bac> hazmat: yes, root@ works.  i was trying ubuntu@
<hazmat> ack
<bac> hazmat: was that a change?
<hazmat> bac, yes previously was ubuntu@ (cloud-image) now root@ 
<hazmat> bac, /opt/uistage has the checkouts / cron etc
<bac> hazmat: ok.  thanks.
#juju-gui 2013-05-31
<luca_> rick_h_: jcsackett sinzui are you guys awake yet? :)
<sinzui> I am luca_
<gary_poster> you are not luca.  you are sinzui!
<luca_> sinzui: great, I have a meeting with someone from the Webapps team to discuss how to make Juju responsive and would like someone involved with the front end to join the talk.
<sinzui> Sorry, more coffee is needed to find myself
<bac> gary_poster: the new ppa, i'd like to put it in ~juju-gui-charmers.  ok by you?
<luca_> gary_poster: haha
<gary_poster> :-)
<gary_poster> bac +1
<bac> coolio
<luca_> sinzui: its in 1 hour and would be about half an hour long
<bac> gary_poster: we need to talk also about transitioning away from python-charmhelpers
<sinzui> okay.
<sinzui> That works for me. luca_ do you want more than one person?
<bac> gary_poster: it turns out it never got promoted to an ubuntu repo as i thought.  it has only every lived as part of ppa:juju/pkgs
<gary_poster> bac, it was python-shelltoolbox that was promoted
<luca_> sinzui: anyone can come, he started asking me techy questions yesterday that I couldn't answer.
<bac> gary_poster: i had thought both were.
<gary_poster> ah, no.
<sinzui> luca_, fab.
<gary_poster> bac, anyway, we want to migrate to wedgwood's thing, right?
<luca_> sinzui: I've sent you an invite, feel free to give anyone interested the hangout link
<gary_poster> I mean, that's what you want to talk about
<sinzui> orangesquad, staging is again a victim of zookeeper/juju-agent problems. I am going to reboot the unit
<bac> gary_poster: i think so.  he is advocating for not putting in "client-side" helpers, those that we use in our tests
<bac> by advocating, i mean marked them as deprecated and not promoting them out of contrib
<gary_poster> bac, ah right, I saw that.  what's his argument, and what is his suggested approach for us?
<bac> his argument is simply client side stuff doesn't belong.  he suggested putting them in charm-tools, which is a non-starter for me.
<gary_poster> what's an example of said "client-side" helper?  what does "client-side" mean?
<gary_poster> in context
<bac> gary_poster: http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/charmhelpers/__init__.py
<bac> client-side means things that you don't use in hooks
<gary_poster> ah I see.  have we already argued against this, casting these as test helpers, and suggesting a test-helper directory?
<gary_poster> testutils
<gary_poster> something like that
<sinzui> orangesquad looks like charmworld/3 's agent is truly dead. The site is up. I will let it run for now
<benji> I tend to call the module holding things like that "testing"
<abentley> sinzui: roger.   Should we reboot so that landings don't work?  I'm not expecting to land anything soon.
<abentley> s/landings don't work/landings work/
<bac> gary_poster: no, i raised the issue in review but didn't make that specific suggestion.  i will do so now and propose a branch.
<sinzui> abentley, I did reboot it, the agent did not start
<gary_poster> great thanks bac
<abentley> sinzui: Oh.  We could remove-unit charmworld/3 and add-unit charmworld maybe?
<sinzui> abentley, after my rollback of elastic search last night, I think I want to be very cautious about next steps, but I think add-unit is right. that is what I did a few weeks ago.
<abentley> sinzui: It's certainly more convenient than destroy-service followed by deploy because no reconfiguration is needed.
<gary_poster> benji, btw, you can plan your coffeescript revolution with bcsaller.  he is sold too. :-)
<benji> bcsaller, to the coffeecave!
<hatch> good morning
<gary_poster> jujugui, heads up: npm appears to be having some pretty serious issues today.  https://github.com/isaacs/npm-www/issues/325 is making it hard to very install npm dependencies.  If anyone wants details, lemme know.
<gary_poster> morning hatch.  safe trip?
<gary_poster> very hard to install, that is :-P
<gary_poster> this will likely affect CI :-(
<hatch> it was thanks, long trip though - the planes were pretty old so none had wifi and only one had tv's :)
<gary_poster> heh
<bac> solar flares affect CI
<gary_poster> -/
<gary_poster> :-/
<hatch> bac: lol
<gary_poster> hatch, how did angular go?  working through examples slowly but still optimistic from what I see
<gary_poster> ugh, this npm thing is really annoying
<hatch> gary_poster: right now I'm trying to figure out how to 'pre compile' templates so that we can send them over the wire like we do our hbs templates
<gary_poster> cool hatch.  other things working though?
<hatch> technically yes, the passing data between angular and yui is pretty trivial
<hatch> you also need to do special techniques if you want to minify it because of how the dependency injection works
<hatch> and I'm a little concerned about performance on our apps because our DOM is huge
<matsubara> gary_poster, hi there, a question regarding the tarmac setup for juju-gui: Currently you use JUJU_BRANCH to define which branch to run tests on. if we start using tarmac, we want to run the tests from the trunk branch + the merged in changes of the approved merge proposal, right? 
<gary_poster> trivial: cool hatch, good.  looked like it.  special techniques to minify: tricky/problematic, or you have resolved to your satisfaction, at least mostly?  performance: what do you plan to show at mtg?
<hatch> the angular guys have a workaround for the minification issue
<gary_poster> matsubara, right.  the JUJU_BRANCH thing is for the post-commit CI approach
<gary_poster> ok
<hatch> my performance issues are based around the idea that it queries the whole dom for these directives
<hatch> so the time to do that will increase with the amount of elements in the dom
<gary_poster> hatch, that's one-time on load?
<hatch> on load and then any time you initiate a module
<hatch> I `think` because it's undocumented :)
<gary_poster> hatch, any time you initialize a module for the first time, or any time you instantiate a model for a given view?  I'd hope for the first.  Also, I expect we could test/time this pretty trivially, but hooking angular in to the app and finding the start of the DOM walk and the end.  just because we don't actually have any directives isn't relative to your concern AIUI. :-)
<bac> just called my ISP and she said my radio was broadcasting at too high a signal.  she's going to turn it down from 11 to 9.
<hatch> gary_poster: yeah it's probably not a valid concern
<hatch> it's quite a bit less code and easy to modulize
<hatch> I will likely need to spend the weekend reading more on it
<gary_poster> hatch, do we have something for the team to look at today, or is that premature?
<hatch> honestly I think it's a little premature - i'd like to spend the weekend on it but I have learnt a lot about how it works and still think that it is probably the right approach for such a DOM centric portion of the app
<hatch> I have found the best documentation is blogs, youtube videos, and stackoverflow
<gary_poster> hatch, ack.  I have 15 min before a call--can we hang out in 5 for about 10 minutes so I can get a bit more detail?
<hatch> yeah sure
<hatch> the build fails with window undefined if I try and use window in 3rd party files
<hatch> thought that was odd
<gary_poster> hatch, heading to guichat, if you are available
<hatch> yeah one sec I just gota grab my headset out of my bag
<matsubara> gary_poster, can you add https://launchpad.net/~jujugui-lander as part of the team allowed to change lp:juju-gui ?
<gary_poster> matsubara, done
<matsubara> thanks gary_poster 
<sinzui> gary_poster, my meeting is running over. I will be a few minutes late
<gary_poster> ok thanks sinzui, ping me when you are ready
<sinzui> gary_poster, I am coming to the meeting now
<bcsaller> gary_poster: npm is out to get me? ack. With all the deps the dir is 27M so I am reluctant to push that up but I can if you want
<gary_poster> bcsaller, :-) on call.  maybe you will need to screen share
<bcsaller> gary_poster: that can work
<hatch> the node crowd is saying it's fixed now once dns updates
<bcsaller>  that would be good
<gary_poster> bcsaller, could you fix bug 1185982
<_mup_> Bug #1185982: "=" and "-" keybingings are too agressive <juju-gui:Triaged> <https://launchpad.net/bugs/1185982>
<bcsaller> gary_poster: I can look at it after the meeting
<gary_poster> thx
<gary_poster> jujugui call in 9; kanban now
<teknico> wow, glipper got up to 1GB of resident memory
<hatch> npm is working for me again
<hatch> using googles dns at least
<teknico> does google show ads on dns too? ;-)
<gary_poster> jujgui call now, I'm coming, sorry :-)
<arosales> teknico, I am sorry I was miskta
<arosales> mistaken, marco is traveling today.
<teknico> arosales: ok, thanks
<arosales> teknico, if you are blocked m_3 may be able to assist until marco gets back.
<teknico> arosales: great, thanks again
<hazmat> teknico, there are a couple of alternatives.. opendns is one
<teknico> hazmat: that's what I used to use before moving to google dns :-) could not stand the 404 intercept
<arosales> teknico, I caught marcoceppi_ for a bit between traveling
<marcoceppi_> hey teknico 
<arosales> if you have any questions may be good to get them in now :-)
<teknico> marcoceppi_: hi, sorry to interrupt your flight :-) still having problem with selenium and display
<teknico>  marcoceppi_, does this look ok, if you can see it? http://pastebin.ubuntu.com/5719876/
<marcoceppi_> teknico: that shoudl be good enough, as long as the host as it set properly
<teknico> marcoceppi_: the host? where?
<marcoceppi_> teknico: the host being your maching
<marcoceppi_> I considered just mirroring everything in os.environ to the env in Python but figured it'd be better to piecemeal them over. I may have been incorrect in that assumption
<teknico> marcoceppi_: well, forwarding the whole env would definitely be simpler, if maybe a little cavalier :-)
<marcoceppi_> teknico: I wanted to try to make sure the env wouldnt' mess anything up between people's machines by having a set number of things, least common denominator or variables, used
<teknico> marcoceppi_: yes, it sounds like a reasonable approach
<marcoceppi_> Though, it might just be in vain. If it turns out to not really be a problem I'll just have the whole thing mirrored and amend the few env variables like JUJU_ENV, etc
<teknico> marcoceppi_: it would be worth trying it to see if it improves matters, even temporarily
<marcoceppi_> teknico: if you want to patch your local install to use the whole of the os.environ I can send you a patch. Not sure if I want to put it in trunk just yet, I would hate to set one expectation only to remove it again at a later date
<teknico> marcoceppi_: no need to commit it, just send it to me when you can, thanks
<marcoceppi_> teknico: ack, I'll send it over in a few
<teknico> marcoceppi_: thank you. don't miss flights over this, though :-)
<marcoceppi_> teknico: sadly I'm in a car. I'd be far happier flying :P
<teknico> marcoceppi_: maybe try a flying car then ;-) you're not driving, hopefully :-)
<marcoceppi_> teknico: I've not created just a patch in bzr before, so I have a bzr send, which google told me I should use
<sinzui> orangesquad, the new ES is queued to build. The issue was my merge script to repack the build. The deb contain the new and old versions of lucence jars. ES 0.90.0 is not compatible with the 4.1 jar that were from the previous repack.
<teknico> marcoceppi_: the output of bzr diff would be enough
<marcoceppi_> teknico: http://paste.ubuntu.com/5720274/
<teknico> marcoceppi_: perfect, thanks again
<marcoceppi_> teknico: np, I'll be afk for a few but feel free to ping me in here, just expect a delayed response!
<teknico> marcoceppi_: I'll be EOD in one hour anyway, have a safe trip!
<marcoceppi_> teknico: thanks! have a good weekend!
<rick_h_> hatch: api1 helping with your browser issues in dev?
<hatch> haven't tried yet :)
<hatch> somehow I managed to screw up my node install but I think it's fixed now so I'll be trying shortly
<sinzui> orangesquad: does anyone need staging? I have had three failed efforts to add-units. I want to deploy a replacement service.
<abentley> sinzui: Not I.  Perhaps this is a good time to try out Kapil's deployer thing.
<sinzui> abentley, capture the stack and redeploy it?
<abentley> sinzui: If we can.  I kind of assumed we'd have to write it by hand.
<abentley> The deployer config, I mean.
<sinzui> I don't want to write one by hand this week. I want to stop get this distraction out of the way so that I can work on the charm model branch.
<abentley> sinzui: If using deployer is not a quick fix, then I have a script you can use.
<sinzui> I was just going to deploy a new charmworld service...and remember to set the charm_import_limit
<abentley> sinzui: Oh.  Have you tried doing remove-unit first, terminating the machine, and adding a unit?
<sinzui> no, actually I haven't since I wanted to be certain I got a new machine. I don't really need a new machine. I just want a working one
<abentley> sinzui: If the agent on the machine is borken, you may need to get a new machine in order to get a working agent.
<sinzui> That is what I was thinking
<sinzui> abentley, I just used juju-jitsu export. It gave me something to deploy, but I cannot use it until the replacement ES is built. I will to remove the service for now
<abentley> sinzui: Here is my script anyhow, in case it's useful in the future. https://pastebin.canonical.com/91952/
<sinzui> thank you!
<hatch> http://gizmodo.com/hell-yes-razer-made-the-most-powerful-small-windows-la-510358373
<hatch> finally 'possibly' an alternative to a MBP
<abentley> hatch: Heh, I was thinking about it too.
<hatch> :)
<hatch> of course I couldn't buy one until the new MBP comes out anways so that I could compare lol
<hatch> abentley: this razer would probably be a lot easier to install Ubuntu on too haha
<abentley> hatch: Especially if we can get other Canonifolk to buy it :-).  My Laptop Refresh Benefit should kick in just after 13.10 is released.
<hatch> haha - I think I have to wait 2.5years lol
<benji> "TypeError: '[object BlobConstructor]' is not a constructor"... thanks
<hatch> never seen that error before :)
<bcsaller> sounds like an old browser w/export
<benji> yep; unfortunately it is the one that runs hour hedless tests (phantomjs)
<benji> this makes me wonder about the test coverage of the other code that builds blobs
<hatch> are we running an older version of phantomjs?
<hatch> current version is 1.9 and I have 1.8.1 installed
<hatch> might want to see if you can update to 1.9
<hatch> npm has 1.9.0-6
<hatch> not sure what the -'s mean
<benji> hatch: thanks for the hint.  The "-" is probably a packaging change (but not a change to the code).  I'll try to update and see if my tests start to pass.
<hatch> if that does fix let me know so I don't run into the same :)
<benji> k
<benji> well, now I can't get through a test run because phantomjs segfaults
<benji> no dice; the updated phantomjs didn't help
<bcsaller> skip that test based on UA?
<hatch> finally set up dual google accounts - wow I can't believe I didn't know about this sooner
<hatch> so much easier hah
<benji> having two may be good, but I can't recommend having a half-dozen
<hatch> I can't really see needing more than two :)
<hatch> personal & work
<hatch> and I love how it automatically picks the proper account based on the url
<bac> hatch: it hasn't always been so smart
<hatch> gary still around?
<hatch> gary_poster: ^
<gary_poster> hatch yes
<gary_poster> shoudl go now though :-)
<hatch> I have added a few things to the evaluation notes
<hatch> just wanted to fill you in on a couple things I found out today
<gary_poster> cool hatch.  quick call?
<hatch> sure
<hatch> in guichat
<gary_poster> yeah
<bac> \o everybody
<benji> bye bac
<hatch> rick_h_: hey still around?
#juju-gui 2013-06-01
<rick_h_> hatch: pong
<hatch> rick_h_: ping
<rick_h_> hatch: pong
<hatch> hows it going?
<rick_h_> hatch: weekend party time
<hatch> hah - weekend yard/housework time you mean
<rick_h_> party time sounds better
<hatch> sure - but installing eves while drunk sounds dangerous
<rick_h_> parties can be dangerous :)
<hatch> haha
#juju-gui 2014-05-26
 * frankban lunches
<rick_h_> morning
<frankban> hi rick_h_ 
<rick_h_> how goes the battle frankban
<frankban> rick_h_: I just proposed another inc step for utils. juju-core migration scheduled for Thu: at this point I'd wait before migrating packages, we still need to fix internal stuff in core. also tracking progress on the more important battle (EU elections) ;-)
<rick_h_> frankban: hah, sounds like a plan to me
<rick_h_> frankban: will be interesting to see how this move goes
<frankban> rick_h_: +1
<hatch> good morning those who didn't take today as a holiday :)
<hatch> anyone up for a big review? https://github.com/juju/juju-gui/pull/342
<rick_h_> hatch: give me 10 to get the boy settled and I'll break into it
<rick_h_> hatch: code feedback posted, will qa after standup
<rick_h_> jujugui call in 10 kanban please
<hatch> ok looking
<Makyo> jujugui call in 2
<hatch> rick_h_ comments replied to
<rick_h_> hatch: cool catching up
<hatch> Makyo working on your qa
<hatch> abentley in your email when you said git doesn't have a revno, I'm assuming the partial hash for some reason doesn't work?
<hatch> Makyo do you have a follow-up card or bug for the re-requesting icons that was introduced here?
<rick_h_> hatch: it's just a different place to get the data. We had to make the same adjustment
<abentley> It's not an integer where a higher number is more recent.  I'm not saying that *is* a problem, but at this stage, I don't know.  We often do use that property of revnos.
<hatch> ohh gotcha
<hatch> there might be a way to query the git db to find out the order of the hashs
<hatch> if that was really a requirement
<Makyo> hatch, I'm seeing that in trunk, too, FWIW, but sure, I'll make one.
<rick_h_> Makyo: please stick it in maint on deck
<hatch> Makyo really? I was sure it wasn't happening last week on comingsoon
<hatch> lemme check again just to be sure
<Makyo> It's happening locally.
<abentley> hatch: Yes, though we might just change what the script does instead.
<rick_h_> hatch: ok, replied to your replies, let me know if it'll help to chat
<hatch> Makyo interesting, I can't get it to happen on comingsoon - I wonder if it's a server difference
<hatch> charm vs not
<frankban> fwereade: I am working on a branch for preventing utils to use BaseSuite where possible. My understanding is that BaseSuite is very juju-core related, and often not required for stuff like utils. How does it sound?
<hatch> rick_h_ ok looking
<Makyo> I'm of the opinion that this is very low priority, given a) we're returning a 304, so cached assets are used, and b) it only happens in simulator envs when relation-changed hooks fail.  The root of the problem is that we're changing the xlink:href attribute on svg <image> tags, so the solution is to load every icon for every relation and show/hide them with CSS, which seems like an optimization we don't need to worry about.
<Makyo> i.e.: it's on the browser, and the browser's doing the right thing with the 304s.
<hatch> so the original issue was that on every delta the icon would flash as it reloaded - that doesn't appear to happen any longer
<hatch> so you're probably right that it's very low
<hatch> regardless I +1'd your branch with a trivial :)
<Makyo> Yeah, previously we removed the icon, then added a <image> back in, now we just change the href.
<hatch> rick_h_ Here is a response to your concerns lemme know if you'd like to chat after this https://github.com/juju/juju-gui/pull/342#discussion_r13050921
<rick_h_> hatch: yea, standup hangout?
<hatch> sure, sec
<rick_h_> Makyo: lint fun in landing
<Makyo> D'oh.  On it/.
<fwereade> frankban, we would hope to have a common BaseSuite that stripped out the core-specific bits, more than we would hope to lose it entriely
<frankban> fwereade: some of the tests in utils do not require embedding other suites, others really only require CleanupSuite
 * hatch proposes typescript 
<hatch> after using Go it would sure be nice to catch some of these type errors before refreshing :)
<rick_h_> hah
<hatch> rick_h_ can you link me to that loc where you reset the filter again? I just want to compare against what I'm attempting
<hatch> the filter is definitely not being reset on 'home'
<rick_h_> hatch: sure thing sec, have to load it up again
<hatch> this must have been a long standing bug we never ran into for some reason
<rick_h_> https://github.com/juju/juju-gui/pull/326/files 204
<hatch> rick_h_ if you click the number it will give you a link directly to that loc even in diffs
<rick_h_> hatch: doh
<rick_h_> hatch: yea, having a major monday today. You won't believe how it's gone
<rick_h_> hatch: so yea, there. I
<hatch> haha thanks
<rick_h_> hatch: so this isn't so much a bug as when the new state was setup we had no filter, when we added back filter we didn't update the Home event to fire the new way it needed to
<rick_h_> hatch: but we had this card to work on that 
<rick_h_> hatch: which is what this card originally start out as
<hatch> so...this feels like the wrong way to do this....should the state not be smart enough to see that there is no search and upate the filter accordingly?
<rick_h_> hatch: well, "Home" is like a giant erset
<rick_h_> reset
<frankban> fwereade: the change is in  https://codereview.appspot.com/101760045
<rick_h_> hatch: and it has to communicate through a 'change' event so it has to be structured somehow in there?
<rick_h_> hatch: sec, phone call. back in a sec
<hatch> I'm just wondering if it makes sense to move this search.clear = true bit into the state parsing 
<hatch> sure np
<hatch> so if metadata.search === undefined || null then wipe the filter
<hatch> it requires less discovery for the developer then if they ever want to clear the search, they just null it out in the state object
<fwereade> frankban, cheers
<rick_h_> hatch: yea, I felt like there was some reason. I think it's because you have to change more than just the search term, you have to clear the category stuff and anything else in that filter object over time
<rick_h_> hatch: so the clear() was a way to tell the filter object to just reset entirely
<hatch> right - but now that we have this fancy state object can we not safely say that if metadata.search is undefined or null then filter should be cleared and drop the requirement for metadata.search.clear ?
<hatch> another way to say it is, when would we not want to clear filter if metadata.search is undefined or null
<rick_h_> hatch: because the way a search via the api works is you can have a category without a search term
<rick_h_> hatch: when the user picks the autocomplete drop down for 'databases' it doesn't send a term that I recall
<hatch> so the category isn't entered into the metadat.search object? 
<hatch> your right, term is empty
<rick_h_> hatch: so I think keying off the one field is dangerous and limiting scope too much
<hatch> ok lemme check the state object when I search a category
<rick_h_> ok
<hatch> rick_h_ ok good news - the filter data is present in the metadata.search object so we can safely check that if it's null, undefined, or an empty object to clear the filter
<rick_h_> hatch: ok, and if you make a change, like clicking on a charm in the results to get the details open, it won't be effected by not having a search key?
<hatch> it looks like it mixes properly...checking the execution
<rick_h_> hatch:  ok cool, just want to make sure that we don't accidently break other cases
<hatch> the search object is correcly left untouched
<rick_h_> cool
<hatch> nice
<rick_h_> so that's cool then, I think it'll simplify things and make them more direct/explicit
<rick_h_> thanks for chasing that down
<hatch> agreed
<hatch> np
<hatch> lazyPower marcoceppi is there a website somewhere which shows the status of charm reviews so I can see where my ghost charm is in the queue? 
<hatch> rick_h_ this is hard to grep for....do you remember when you'd want to do filter replace vs filter update? 
<rick_h_> hatch: thinking
<hatch> as far as I can see the search widget always uses replace true
<rick_h_> hatch: I think the idea was around categories. If you picked a new category, we'd clear out the search term, filters, etc, and just create a new filter with only the category selected
<rick_h_> hatch: yea, I think that harkens back to the filter/series/etc UI
<hatch> could this be the bug which causes new search queries to always use the old category? 
<rick_h_> hatch: it's part of it. The old system was checkboxes that built on each other
<hatch> ahh
<rick_h_> you'd check "category X" and then click "series Y"
<rick_h_> and it would build the search
<rick_h_> so in this case you pick category from the drop down, but there's no way to unset it like you could back in the checkbox day
<rick_h_> and then the replace was to "reset all the other checkboxes and use this new search"
<hatch> ok thanks looks like you're right
<rick_h_> so it's more "do this whole search, no do this one instead, no do this one" vs the build a search "do this, now limit that by this other thing, and add this 3rd condition"
<hatch> ok I can simplify this part of the filter code, looks like the bug is actually in the data the search widget is sending out
<hatch> thx
<hatch> we can re-implement this later, it's going to need to be refactored anyways
<hatch> the cascading category stuff that is
<rick_h_> yea
<hatch> darn UI changes
<hatch> haha
 * hatch gets his picketing signs "Down with Agile!"
<rick_h_> lol
<rick_h_> "design spec document or bust!"
<hatch> haha
<rick_h_> jujugui I'm going to cut out a bit early and comp my weekend time. I'll check in to help unblock hatch's branch, but be afk. 
<hatch> lata!
<rick_h_> maybe I'll tear down and rebuild my rack setup for the gui maas hehe
<lazyPower> hatch: http://manage.jujucharms.com/tools/review-queue
<hatch> lazyPower so how do you determine where in the queue it is? :)
<lazyPower> hatch: Community take priority over canonical, otherwise its order in the queue.
<lazyPower> as in, if its at the top, it goes first
<hatch> Average wait time: 6 weeks 
<hatch> ouch haha
<hatch> :)
<hatch> do all updates to a charm take 6 weeks?
<lazyPower> I had it cut down to 3 weeks. older items that come back into the queue after being nacked inflate that number
<hatch> ohh
<lazyPower> its not entierly accurate
<lazyPower> but kinda sorta
<hatch> FYI: the last time I submitted the ghost charm I was all gung ho and had time to do it, the review took a long time and then when the review came back it was months before I got back on it again - I'd imagine a similar problem to happen with the community too
<lazyPower> hatch: its a byproduct of the solutions team having 8 moving targets to track
<lazyPower> i dont disagree with you - i feel that whole heartedly
<hatch> do updates to charms already in the store also enter this queue? 
<lazyPower> yep
<lazyPower> Pretty much everything but the OpenStack charms enter this funnel
<hatch> yikes - that's not going to be scalable 
<lazyPower> This is why automated testing and poliicy change is emminent. If you dont pass charm tests, it doesn't enter the queue. A bot updates your MP and its rejected from the queue
<lazyPower> that way we are only looking at well formed, fully linted, and tested charms.
<hatch> yeah that's a good idea
<lazyPower> its on our radar, and we're working towards a solution. We just haven't reached terminal velocity with it yet. 
<hatch> right now are tests required to get into the store?
<lazyPower> Since our testing story isn't that strong - we cant really enforce it.
<hatch> ok good because mine doesn't have any tests :)
<lazyPower> Once we have an established best practice, you bet. 
<lazyPower> we've already emailed the list back in December about the policy change and heard crickets on the thread. So chances are it will get another notice sent before its enforced.
<hatch> I'll write tests when someone external uses the charm
<lazyPower> We're looking to push ghost over WP as our demo charm. Because lets face it, ghost is a nicer platform if you're not sold on the 8 billion plugins for wp.
<lazyPower> Ceppi is on review queue this week. Maybe give him a friendly poke when he's about that you're looking for feedback
<hatch> it's also written in JS, so I'm not sure how a python test suite will work
<hatch> :)
<lazyPower> I tend to review charms that are getting a lot of attention over queue priority..
<lazyPower> Your tests dont have to be in python
<lazyPower> so long as the tests are executeable and live in tests/  charm test will run them.
<lazyPower> just make sure you have your dependencies mapped in 00-setup so they get installed on the test harness instance.
<hatch> ok I'll have to revisit the testing procedure, I thought they had to be in python
<lazyPower> we prefer it, but dont require it.
<lazyPower> mostly because we have a strong python story in juju right now. A good majority of the store charms are bash, but you won't see us pushing bash - the second most popular language is python
<lazyPower> followed by some of the specific Config Management frameworks... but by a wide margin
<hatch> yeah - I'd just like to keep this charm all js because it's a full js stack app
<lazyPower> Not a bad plan of action. 
<lazyPower> If you need anything, such as pointers in testing or what not dont hesitate to ping hatch
<hatch> I figured it would be better for the ghost community
<lazyPower> I'm going to bail and go code from the porch while my brats and steak char on the grill
<hatch> :) enjoy
<Makyo> jujugui small review/QA: https://github.com/juju/juju-gui/pull/343
<hatch> Makyo on it - heh the test is huge compared to the code
<Makyo> Yeah, lots of container to prep.  After il is removed, that can be moved to beforeEach/
<Makyo> Or even setUpInspector
<hatch> Makyo so I'm guessing we just forgot to add this in when we did the switchover?
<hatch> all done
<Makyo> hatch, yeah, I think so.
<hatch> ok now that the state>filter stuff is fixed 
<hatch> now to move the rendering trigger into the charmbrowser view
<hatch> and boy is it nice when a rebase is just a simple FF
<hatch> rick_h_ are you around by chance? I have pushed the new revision 
<hatch> jujugui anyone around for a review/qa? https://github.com/juju/juju-gui/pull/342
<rick_h_> hatch: will look tonight. 
<rick_h_> hatch: updates go ok?
<hatch> thanks
<hatch> yeah works well
<rick_h_> hatch: quick run through leads to just one question on the shouldRender stuff
<rick_h_> hatch: will QA probably after dinner time
<hatch> sure, replied to one, just reading the other now
<rick_h_> hatch: and replied, yay interwebs
<hatch> haha
<hatch> replies replies replies
<hatch> oops lint
<rick_h_> hatch: ok, any feedback on the name suggestion?
<hatch> umm sorry reviewing huws branch, looking
<rick_h_> hatch: all good thanks for peeking at his branch
<hatch> don't like it, I replied actually :)
<hatch> https://github.com/juju/juju-gui/pull/342#discussion_r13057884
<rick_h_> right, didn't see it as a direct comment sorry
<rick_h_> see, you should never not render. You might not update an existing rendered view though
<rick_h_> oh well, it's a naming thing. Don't want to cause a stink over it but as an api it's kind of meh in my head. Thanks for the other updates. Will QA and :+1: after that fact
<hatch> hmm - hmmmmmmmm
<hatch> rick_h_ I'm still trying to convince myself of the name change :) In the mean time, do you know if huwshimi will be working today?
<rick_h_> hatch: I believe so
<rick_h_> hatch: as far as I know 
<hatch> ok cool, I just finished his review/qa 
<hatch> I'll leave IRC on in case he has any questions
<rick_h_> hatch: cool
<hatch> https://www.trulyergonomic.com/store/index.php
<hatch> that's a pretty cool looking keyboard
<hatch> looks like it might be a good layout for coding
<rick_h_> yea, the big thing is the lack of windows key that I use for my window manager
<rick_h_> my kenisis works well. If I go off of it for a few weeks my wrists hurt, going back to the kensis helps
<rick_h_> I do have a kensis split I'm going to try out for travel arriving wed
<hatch> there is that odd juju looking button in the middle top
<rick_h_> https://www.kinesis-ergo.com/shop/freestyle2-for-pc-us/ curious how that works out
<rick_h_> yea, but that's not going to be a decent keycombo key
<hatch> oh no
<rick_h_> hitting that plus hjkl to move windows will be awkward
<hatch> haha yeah it would
<hatch> I'd like to give a kinesis a try but at $300 it's an expensive test
<hatch> haha
<rick_h_> anyway, I've seen it a few times but can't get convinced enough to try it out
<rick_h_> well you should let me know. I'll send you my older model to try out
<rick_h_> I've got an old ebay one I used to justify getting the nicer new one
<hatch> everyone I know who uses one loves it, I should really just bite the bullet
<rick_h_> but yea, it took me over a year of eye'ing it before I could pull the trigger. Most expensive keyboard I've owned by far
<rick_h_> exactly, not really many I know that rant against it once they get over the learning curve
<rick_h_> it feels a ton different for sure
<hatch> heh, not sure what I'd use as a macro though
<hatch> I wonder what people set up macros in their keyboards for
<hatch> it's been thundering for almost 5 minutes non stop
<hatch> very weird 
<hatch> one continuous rumble 
<rick_h_> yea, I don't use the macros
<rick_h_> it is cool to reprogram keys at the keyboard level though
<rick_h_> "this is an alt key regardless of wtf I plug it into"
<rick_h_> and not worry about os level mappsing
<hatch> http://weather.gc.ca/lightning/index_e.html?id=WRN#mapTop
<hatch> heh
<hatch> https://twitter.com/PQuinlanGlobal/status/471063686694445056
<hatch> purple must mean bad things
<hatch> here comes the hail https://twitter.com/PQuinlanGlobal/status/471065379062571008
<hatch> well at least I wasn't going nuts https://twitter.com/PQuinlanGlobal/status/471064268901580801
<hatch> good morning huwshimi 
<huwshimi> Morning
<huwshimi> hatch: Any ideas about this bug? https://bugs.launchpad.net/juju-gui/+bug/1323199
<_mup_> Bug #1323199: Dropping unplaced units errors <juju-gui:New> <https://launchpad.net/bugs/1323199>
<hatch> https://twitter.com/PQuinlanGlobal/status/471065968290979840 heh, yep it's comin down hard
<hatch> huwshimi looking
<hatch> huwshimi I can reproduce, looking into it now
<huwshimi> hatch: You can see the line I tracked the error back to in that bug
<hatch> looks like the issue is that https://github.com/juju/juju-gui/blob/develop/app%2Fstore%2Fenv%2Fgo.js#L930 is returning a string not an object like it used to
<hatch> hmm that's not ie
<hatch> it*
<huwshimi> hatch: Could it have anything to do with this branch? https://github.com/juju/juju-gui/pull/339/files
<huwshimi> hatch: Note the change from id to unit.
<hatch> so the issue is that the unit no longer has all of the attributes it once had
<hatch> looking at that pr
<hatch> yeah that does look like the problem
<hatch> huwshimi this should be `attrs.unit.id` https://github.com/juju/juju-gui/blob/develop/app%2Fwidgets%2Fserviceunit-token.js#L132
<hatch> man files are hard to find....half of the views are under /widgets
<huwshimi> hatch: A brilliant. Want to land a branch to fix that or do you want me to?
<huwshimi> I could also land it as a drive-by in my next branch
<hatch> nope I'm done for the day today
<hatch> cleaning the kitchen atm :)
<huwshimi> hatch: Sure, I'll do it :)
<huwshimi> hatch: Thanks for figuring it out!
<hatch> no problem 
<hatch> I see you saw that I reviewed your branch - if you have any questions about that just lemme know
<huwshimi> Sure, no problems.
<huwshimi> hatch: The funny thing is you reviewed the branch that added all these click handlers and now you don't like the names :)
<hatch> I have more context now
<hatch> **excuses level 100 achievement unlocked**
<huwshimi> hehe
<hatch> lol
#juju-gui 2014-05-27
<rick_h_> hatch: sorry for the late, did qa and noted issues. 
<hatch> rick_h_ np, looking at comment
<hatch> replied
<hatch> ugh I hate trying to balance such a complicated switch between the feature flags
<hatch> so many wasted hours on this one
<hatch> oh now I see why
<rick_h_> yea, I'll bet these are small ones
<rick_h_> ok, time to run away for the night. 
<rick_h_> have a good night all
<hatch> it's using the new code for the curated but the old code for the search so it doesn't notice the change
<hatch> I may just have to hack this to work 
<hatch> cyaz
<hatch> nice I found a non hacky solution
<hatch> yay finally landing this
<hatch> huwshimi I'm going to head out - any q's before I do?
<huwshimi> hatch: All good. I'll leave any questions on the pr if need be.
<hatch> sounds like a plan, have a good one
<rogpeppe> mornin' all
<huwshimi> rogpeppe: Morning
<rogpeppe> huwshimi: hiya
<frankban> hi fwereade, thanks for the review! I am available for a live chat when you want
<frankban> morning rogpeppe, how is it going?
<rogpeppe> frankban: hiya
<rogpeppe> frankban: not bad, thanks
<rick_h_> morning everyone
<rick_h_> rogpeppe: morning, did you get the invite to the interview today? Are you able to participate?
<rogpeppe> rick_h_: hi rick
<rogpeppe> rick_h_: yes, i saw the invite on my phone and forgot to respond this morning. i can come.
<rick_h_> rogpeppe: awesome, appreciate it.
<frankban> rogpeppe: FYI after lunch I'll start working on creating a BaseSuite in github's testing. The next step is to make utils/* stuff use the new generic suite.
<rogpeppe> frankban: that might be ok. i'm not entirely sure about BaseSuite though as a name - it doesn't really imply any particular semantics and it kind of implies that it's the centre of the universe :-) what does it mean when we've got two BaseSuites, one in juju-core and one in github/juju/testing?
<frankban> rogpeppe: from a pre-emp with William the idea is 1) BaseSuite in github includes logging, osenv reset/restore (all vars) and cleanup, and it's not juju-core related: this is a generic base for having base isolation for all the tests. and 2) BaseSuite in core will be eventually replaced by 1, after potentially fixing the juju-core tests which depends on the env vars not currently removed
<rogpeppe> frankban: perhaps IsolationSuite might be a better name
<bac> rick_h_: did we get advance copy of homework from candidate?
<rick_h_> bac: yes, I thought he copied everyone /me looks
<rick_h_> bac: sorry, that was the afternoon interview. I'm working on it. 
<frankban> rogpeppe: both BaseSuite and IsolationSuite sgtm, fwereade? ^^^
<luca> rick_h_: is there another charm that someone can use instead of NodeJS?
<luca> rick_h_: could someone use Ruby on Rails for doing similar stuff?
<luca> rick_h_: broadly speaking of course :D
<rick_h_> luca: yea, there's a rails charm, a django charm
<luca> rick_h_: brilliant, thanks
<fwereade> rogpeppe, frankban: I'm easy, IsolationSuite sounds fine to me
<frankban> fwereade: cool thanks
<fwereade> frankban, rogpeppe: except, ha
<fwereade> frankban, rogpeppe: no forget it, even the Cleanup stuff is all about isolation really
<rick_h_> jcsackett: ping
 * rogpeppe wishes that the setup and teardown stuff wasn't so reflection-driven. i'd like to be able to do gc.RegisterSuites(c, &mySuite.LoggingSuite, &mySuite.CleanupSuite)
<rogpeppe> or something like that
<rogpeppe> without needing to do the painful SetUpSuite/TearDownSuite calling of underlying suites
<rogpeppe> 'cos that pain is the only real reason we combine suites into super-suites
<rogpeppe> IMO
<rick_h_> frankban: rogpeppe reminder call in 3. 
<rogpeppe> rick_h_: yup
<rogpeppe> rick_h_: ta
<fwereade> rogpeppe, I feel your pain, but I don't think it's quite the only reason -- it's quite useful to have them all batched up together *anyway*, imagine the hassle of adding network isolation to every single suite -- even without manual setup/teardown, it'd be way too easy to have them drift out of sync
<rogpeppe> fwereade: i definitely think that isolation is useful to have in its own suite
<rogpeppe> fwereade: but logging is a bit of an outlier there, as is cleanup, really.
<jcsackett> Morning, all. 
<frankban> rick_h_: I do not have access to the google doc
<frankban> (Presentation of homework)
<rick_h_> frankban: his doc? yea, I'll ask him to open it up. I think it's just his bullet notes to go through
<frankban> rick_h_: OIC, ok  so nevermond
<frankban> nevermind even
<rick_h_> I think he's doing this more a 'conference presentation' model or lightning talk
<rick_h_> it's not really specified, but first time we've had this route 
<rick_h_> rogpeppe: stay on the call please
<hatch> afternoon luca
<hatch> rick_h_ when you get a chance I'd like to chat about moving the search over to the consolidated view - it's going to be a considerable amount of work to keep both the unflagged and flagged functionality
<rick_h_> hatch: rgr, on a call atm but will ping when I'm free
<rick_h_> hatch: I'm basically going to ask you about the other remaining cards up there for IL
<rick_h_> hatch: so maybe check how many of those apply and they need to happen first?
<hatch> yeah - I'm doing a qa on it right now
<hatch> rick_h_ i've created cards for all the bugs ive found and placed them in the order I think they should be completed behind the green il card
<rick_h_> hatch: cool thanks
<rick_h_> hatch: we can chat after the standup
<hatch> sounds good
<hatch> rick_h_ for il can we go back to having the inspector render by default on ghost?
<rick_h_> hatch: sounds good to me
<Makyo> jujugui call in 10
<Makyo> jujugui call in 1
<rick_h_> jujugui I'm going to be a couple of min late, hatch please run with it
<hatch> on it
<hatch> jujugui call now
<kadams54> Fighting with Google, will be in in a moment
<frankban> rogpeppe: quick call?
<rogpeppe> frankban: sure
<rogpeppe> frankban: wanna start a hangout?
<frankban> rogpeppe: https://plus.google.com/hangouts/_/gz42gpplaq7jndtftpitkl3oeaa?authuser=0&hl=en
<rick_h_> Makyo: after your card can you coordinate with hatch on helping move towards getting rid of the il flag please? He's got notes and such to help coordinate which can be done in parallel vs serial
<rick_h_> jcsackett: standup hangout?
<hatch> Makyo here is the diff for the card I'm working on right now https://gist.github.com/8bc67fa011aeecd7aaa3 I just need to write tests for it then it'll be up for review 
<Makyo> rick_h_, sure thing.  Thanks hatch 
<rick_h_> jcsackett: ok leaving that hangout. Shoot me a message when you're back
<luca> hatch: heya, I was in an interview
<hatch> did you get the job?
<hatch> kehehe
<luca> hatch: rofl
<luca> hatch: how goes it?
<hatch> it's going, it's going, summer finally so getting some time outside :)
<hatch> well, time outside without 3" of insulation 
<luca> hehe nice
<luca> hatch__: do you need anything from me? :)
<hatch__> luca I don't think so
<hatch__> have anything I want?
<luca> hatch: not at the moment :)
<luca> hatch: looking forward to QAâing MV and IotL
<hatch> are you sure? Maybe we disregarded everything you said :P
<luca> hatch: ha, that could be an improvement
<hatch> lol
<hatch> nah it's good :)
<luca> :D
<hatch> luca I've been working on getting il ready to go and it looks awesome on the left - I've been wondering if we maybe shouldn't also have the charmbrowser black to match too
<luca> hatch: hehe yeah
<hatch> huw is going to kill me for suggesting that he redo all the css :P
<rick_h_> hah, I think it's nice to have some clear seperation of things, and that has nothing to do with the fact that I'm not a fan of the black :P
<hatch> haha - I was also thinking of that
<hatch> I however am a fan of black
<hatch> :P
<rick_h_> but it's so mushy, the scroll boundries are so unclear and soft.
<hatch> with the black?
<rick_h_> hatch: yes
<hatch> whaaat, it's a very high contrast to the grey compared to grey on grey, how is that MORE squishy? 
<hatch> me thinks you've gone cra'cra'
 * hatch is learning the kids lingo
<rick_h_> hatch: but the scrollbar is darker and stands out. The boundry from charm to charm is done with lines. and studies show reading black on white > white on black for eye fatigue and such
<hatch> well the dividers would also need to be adjusted accordingly. I thought that the studies showed the opposite? I much prefer reading white on black for coding
<hatch> jujugui lf a review/qa for a small diff https://github.com/juju/juju-gui/pull/345
<Makyo> On it.
<hatch> thanks
<hatch> remember that storm I was posting about yesterday.....yeah it rained a bit https://twitter.com/J_Dubs83/status/471083954754572288
<rick_h_> heh, that's a few oz of water
 * rick_h_ runs away for lunch 
<hatch> :-)
 * Makyo runs to grab prescription.
<hatch> oh look we use YUI's DataSource, how did this get in here
<rick_h_> hatch: charmworld api stuff in store
<hatch> yeah :-) I've never actually found a use for it before
<hatch> I'm not sure we actually use it for anything beyond an IO call though right?
<hatch> this might actually make my current task much easier
<hatch> I was wrong *sadface*
<rick_h_> hazmat: ping, trying to run the deployer on a mac for this demo purpose and getting a bzrlib. 
<rick_h_> hazmat: does this run on a mac? Is there a bzrlib way to do that off the top of your head? 
<hazmat> rick_h_, pip install bzrlib
<hazmat> er.. pip install bzr
 * rick_h_ doesn't see it in pypi
<hazmat> rick_h_, traceback
<rick_h_> ah, bzr
 * rick_h_ smacks head for searching for wrong lib
<hazmat> rick_h_, alternatively we could fix bzr cli to support what's needed  ;-)
<hazmat> might be worth checking if its supported.. i'm looking at the comment and its a little unclear.. its about detecting working copy changes when the branch/checkout is pinned at a rev
<rick_h_> hazmat: cool yea working on trying to get it to work. we'll see
<hazmat> rick_h_, so bzr status on a branch that's not on head rev goes.. 'working tree is out of date, run 'bzr update'
<hazmat> rick_h_, but yeah osx is supported and has worked  b4
<rick_h_> hazmat: yea working around pip atm 
<rick_h_> sudo pip install juju-deployer bzr --allow-all-external --allow-insecure=bzr
<rick_h_> wheeee
<hazmat> rick_h_, oh yeah.. pip got sane about security
<rick_h_> for not upload builds to pypi
<hazmat> rick_h_, we just need to upload a bzr src tarball to pypi
<rick_h_> hazmat: running juju-deployer -c xxx.yaml and getting a tsl error? "alert protocol version"? ring any bells?
<rick_h_> ssk
<rick_h_> bah
<rick_h_> ssl error that is
<hazmat> rick_h_, likely your using an old version of jujuclient
<rick_h_> hazmat: k
<hazmat> rick_h_, pip install -U jujuclient
<rick_h_> yea, just intsalled, already up to date
<hatch> of course, when I need charmworld to be slow it's blazing fast lol
<rick_h_> bah, man this guy is finding every broken pita thing we've got. 
<rick_h_> and now my lunch is cold boooo
<hatch> internet throttled....oh boy this is slow
<rick_h_> whooops
<hatch> on purpose
<hatch> i mean
<rick_h_> lol
<rick_h_> what are you trying to replicate?
<hatch> I'm working on the charm list headers rendering over the inspector
<hatch> but the results were coming back faster than I could click on the service icon
<hatch> the silver lining is that the GUI works well on a throttled network connection
<hatch> :)
<hatch> it's slow, no doubt about that, but functional
<hatch> there are definitely some improvements to make on the slow loading side of things
<hatch> nice, it works
<hatch> hey rick_h_ , CI merge hung so I killed it but now I think you'll need to go in and killall node processes
<hatch> ahhh back to full speed again
<hatch> rick_h_ yeah EADDRINUSE
<rick_h_> hatch: sorry, missed the ping looking
<hatch> rick_h_ maybe before you go on holidays you add a killall at the start of the CI script? :)
<hatch> ya know....cuz I'm sure you have nothing else to do right? haha
<rick_h_> hatch: killed
<hatch> thanky
<rick_h_> hatch: well I put the ssh key in the wiki for others to be able to ssh in and kill :P
<hatch> oh ok cool
<kadams54> guihelp: Need review and QA on https://github.com/juju/juju-gui/pull/346
<hatch> sure i'll take it
<hatch> kadams54 you commented on a loc but it didn't expand in the conversation or show in the code.....odd
<kadams54> Hmm, that is odd
<kadams54> I've never seen that happen.
<kadams54> https://github.com/kadams54/juju-gui/commit/a9744286283696056dcae11eaec92cd3213a126a#commitcomment-6462503
<hatch> ahhh you commented on the commit not on the PR
<hatch> interesting
<kadams54> Oops, yeah, you're right
<kadams54> I clicked on the commit hash in the PR "Conversation" rather than using the "Files changed" tab.
<kadams54> Moving it to the PR.
<hatch> I think the failure is a lint issue
<kadams54> Yeah, forgot to "document" initializer. It's fixed and pushed.
<rick_h_> man I can't wait until quickstart works on osx, it'll make this crap so much nicer
<rick_h_> don't appreciate how nice something is until you have to work without
<kadams54> afk to pick the kids up from school. Should be back around 3:30-ish.
<kadams54> (Eastern)
<rick_h_> hazmat: filing some deployer bugs. We will probably check them out as part of quickstart on osx fyi
<rick_h_> Makyo: call
<hatch> kadams54 I made a comment in your PR, lemme know if you want to chat about it in more detal
<kadams54> hatch: yeah, that was essentially my thought in that comment about splitting out into a handlebars template
<kadams54> I was also tempted to make the header label a widget with a render method
<hatch> that's probably overkill
<kadams54> hatch: hah, OK, when you think it's overkillâ¦ ;-)
<hatch> because if the label is a template all you need to do is ` var label =  this.labelTemplate(e.newVal); this.get('container').one('.label-span').setHTML(label); `
<hatch> haha
<kadams54> yeah ill go that route
<hatch> your current approach is just 'too good'
<hatch> haha
<hatch> rick_h_ with your kinesis how do you hit the ctrl + alt buttons? Did you remap them?
<rick_h_> yes, ctrl is caps lock, alt is a thumb based key
<hatch> ahh ok - I was looking at the key layout and I didn't think it would work at all for coding with the defaults
<rick_h_> hatch: it works pretty well, the only thing is that the curved layout makes ; a little harder for my little pinky
<rick_h_> but you get used to it
<hatch> I spent too much time last night researching it and the TECK keyboard
<hatch> heh
<rick_h_> heh, been there done that
<rick_h_> ok, I'm out for now. Dog to the boarding place so I can go on holiday!
<rick_h_> have a good night all
<hatch> lataz
<kadams54> hatch: switched to using a template. Much simpler: https://github.com/kadams54/juju-gui/commit/dd60b784bb7802a7149a5e7df89da7083eab12bd#diff-30cfb18f4179247092a96597a449670dR55
<hatch> looking
<hatch> :)
<hatch> gota love it
<hatch> kadams54 lint error again :)
<hatch> you should have a pre-commit hook that runs the linter lol
<kadams54> I really should
<hatch> handlebars helpers in the template sure look odd
<hatch> `pluralize label count` heh
<hatch> kadams54 I have another suggestion for simplification, sorry I should have seen this before
<kadams54> Go for it
<kadams54> hatch: ^
<hatch> I made it in the PR :)
<kadams54> Ah yes, I see that now :-)
<kadams54> I like that.
<hatch> don't worry, we'll have removed 90% of the code you wrote by the end of the day!
<hatch> lol
<hatch> sorry haha
<huwshimi> Morning
<hatch> jujugui looking for a review for bug #1322255 https://github.com/juju/juju-gui/pull/348
<_mup_> Bug #1322255: Sticky headers render over inspector <juju-gui:In Progress by hatch> <https://launchpad.net/bugs/1322255>
<hatch> morning huwshimi 
<huwshimi> hatch: Morning
#juju-gui 2014-05-28
<rogpeppe> mornin' all
<frankban> hi rogpeppe 
<rogpeppe> frankban: hiya
<frankban> rogpeppe, fwereade: isolation suite stuff proposed in https://github.com/juju/testing/pull/5
<rogpeppe> frankban: looking
<frankban> thanks
<rogpeppe> frankban: if you're going to have a new package (not a bad thing), perhaps isolation.Suite might be a better name
<rogpeppe> frankban: although testing.IsolationSuite would probably work fine too
<frankban> rogpeppe: testing.IsolationSuite introduces an import loop
<rogpeppe> frankban: what's the loop?
<frankban> rogpeppe: logging requires testing, isolation (testing) requires logging
<rogpeppe> frankban: logging requires testing? how come?
<frankban> rogpeppe: the old LoggingSuite (that we need to preserve for backward compatibility) embeds testing.CleanupSuite
<rogpeppe> frankban: that seems spurious to me
<rogpeppe> frankban: can't we change all the places that use LoggingSuite to use IsolationSuite instead?
<frankban> rogpeppe: we can, but that would require fixing all the  LoggingSuite tests using env vars. I guess we want to eventually do it anyway, but the idea is to have an incremental step in the direction of our current goal: separate utils/*, charm etc from juju-core/testing
<rogpeppe> frankban: alternatively, just pull LoggingSuite into testing. it's easy to break out later.
<rogpeppe> frankban: and it's all pretty trivial stuff
<frankban> rogpeppe: I like this more, then we have everything into testing: testing.CleanupSuite, testing.Logging(Only)Suite and testing.IsolationSuite
<rogpeppe> frankban: that sounds good to me
<frankban> rogpeppe: +1, I'll do that. Please let me know when your review is done, and I'll start moving thos eparts
<fwereade> frankban, rogpeppe: yeah, that sounds reasonable, it doesn't feel like such an awfully large package -- but I note that it's this sort of thing that causes packages to gradually grow (not wanting to create lots of tiny ones) and makes them hard to split up (because the loops often mean you can't split off *one* package, you have to split off two or three)
<fwereade> frankban, rogpeppe: but I reiterate that in this case I think it's ok
<rogpeppe> fwereade: i'd like to move towards loggingsuite not embedding cleanupsuite, and then we can factor out things.
<rogpeppe> fwereade: i agree that it's not great that testing is likely to accumulate a big bag of deps
<fwereade> rogpeppe, yeah, that is the plan
<fwereade> rogpeppe, but starting by preserving LoggingSuite is the chosen first step on that path
<frankban> fwereade, rogpeppe: MP updated, and it also seem juju-core must be changed in only one place to use the new logging suite path
<rogpeppe> frankban: i'm not that familiar with github comments - i'm *thinking* that each comment is published the moment I click "Comment on this line", but please let me know if you haven't seen any review comments.
<frankban> rogpeppe: yeah github comments are "real time" (and I don't like that since I usually iterate a lot when reviewing)
<rogpeppe> frankban: yeah, i agree - i very often go back and change mments
<rogpeppe> earlier comments
<frankban> rogpeppe: except for juju-core, are we aware of other projects using the LoggingSuite?
<rogpeppe> frankban: no, i'm pretty sure that juju-core is the only one (well, some of my stuff might do, but ignore that)
<frankban> rogpeppe: just another question about your comments: I know the fixture methods are just methods, I used embedding because it seemed sane to me to rely on the gocheck runner, without simulating its behavior (which I agree is not likely to change, but who knows...)
<rogpeppe> frankban: i don't think that calling the method is "simulating behaviour" to any meaningful degree. if gocheck doesn't call the methods, we're stuffed, so unit testing by calling the methods seems fine to me.
<frankban> rogpeppe: ok I am convinced, this way I can also separate the two tests there
<rick_h_> morning all
<frankban> rogpeppe: re-proposed with the changes
<frankban> rick_h_: morning
<rogpeppe> frankban: looking
<rogpeppe> rick_h_: hiya
<frankban> thanks
<rogpeppe> frankban: do you know if it's possible to see just the new changes, with the comments shown too?
<rogpeppe> frankban: (like codereview allows)
<frankban> rogpeppe: I don't think it's possible, there is no history when rebasing. I agree reitveld is much better
<rick_h_> the comments are still there and you can click on them to see the old code that was commented on
<rogpeppe> frankban: i mean, it doesn't matter much here, but in more complex changes, it's really useful to be able to see the comments and the changes that were made in response.
<rick_h_> but you don't get just the diff in the new changes
<rick_h_> it's an argument for saving rebase until landing I suppose. 
<rogpeppe> rick_h_: so it's not actually possible to see what changes have been made since a comment (without downloading the patch directly, i guess)
<rogpeppe> ?
<rick_h_> rogpeppe: yea, so if we didn't rebase down until after you got the :+1: then you could view commit by commit
<rogpeppe> FWIW, that was something that i would do on almost every review
<frankban> rogpeppe: that's unfortunate in github
<rick_h_> it's something we can talk about. 
<rick_h_> rogpeppe: yea, I've been trying to find time to investigate running reviewboard in our CI environment to help but time hasn't been overflowing lately. 
<frankban> rick_h_: that's an idea, assuming the final rebasing does not require reviewers eyes
<rick_h_> frankban: yea, in theory it shouldn't
<rogpeppe> rick_h_: could you view that on github itself? or would you need to pull down the (unrebased) patch?
<rick_h_> rogpeppe: reitveld left a lot of sour tastes in people's mouth though much of that blame lies more in LP->reitveld
<rick_h_> rogpeppe: so a partial step would be a policy not to rebase your branch down until just before you submit it for merging
<rogpeppe> rick_h_: yeah, the lp->rietveld bridge was a bit awkward
<rick_h_> rogpeppe: that would be in GH itself and would get you much closer to what you want
<rick_h_> frankban: I'll add a friday card and you guys can discuss?
<frankban> rick_h_: sure, +1 thanks
<rogpeppe> rick_h_: i'd find that useful, i think - for complex changes it can be very hard to see what changes have been made in response to a comment, and whether the correspond with what's wanted
<rogpeppe> s/the correspond/they correspond/
<rick_h_> rogpeppe: understood, it's something we fight with LoC limits and multiple reviews required to land on larger branches
<rick_h_> rogpeppe: so we don't always feel that pain ime
<rogpeppe> rick_h_: what are the LoC limits, BTW?
<rick_h_> in the GUI 400 LoC and less you need one review and one QA
<rick_h_> over 400 LoC you need two reviews and one QA minimum...possibly 2
<rick_h_> over 800 ish LoC you need to break it down or bribe reviewers and beg for forgiveness
<rick_h_> rogpeppe: that is more diff LoC than actual LoC 
<rick_h_> LoD (lines of diff)
<rogpeppe> rick_h_: that's including context, right?
<rick_h_> rogpeppe: yea
<rogpeppe> rick_h_: so a one line change would be ~10 LoD
<rick_h_> it's usually closer to 5ish but yea
<rick_h_> hmm, GH doesn't report the real diff size does it. Looking at https://github.com/juju/juju-gui/pull/348 it just has the +69/-14
<rogpeppe> rick_h_: i get 9 lines, not including the file header
<rick_h_> oh yea, hover it I see
<rick_h_> so https://github.com/juju/juju-gui/pull/348 is an 83 LoC diff technically
<rick_h_> rogpeppe: ok, sounds good then. Not normally checking the size of a one line change. It's under any limits :) Then you just need to figure out if self-review is possible. 
<rogpeppe> rick_h_: the 83 lines looks like 69+14, not the diff output line count
<rogpeppe> rick_h_: i suspect git diff | wc will be considerably larger
<rick_h_> rogpeppe: ah right bah
<rick_h_> rogpeppe: I guess it's just habit these day. We're used to breaking down small enough. You're right that we don't currently have a good number in GH like we did in LP
 * rick_h_ makes a mental note to figure out how to port the old rules to GH 
<rogpeppe> rick_h_: tbh, i prefer lines without context - it doesn't penalise changes which change quite a few individual lines in a simple way
<frankban> FWIW my branch in review has +204  â67 and "git diff master | wc -l" returns 425
<frankban> rogpeppe: the magic calldepth value was pre-existing, I don't have that answer, if you do I'd be happy to add a comment there
 * rogpeppe hates the "publish immediately" thing
<frankban> rogpeppe: heh, ok I'll add a todo
<frankban> rogpeppe: also, when a review is completed, we usually add a final comment (not inline) so that the author knows when to start looking for comments
<rick_h_> frankban: yea, we used to have different limits based on language back in launchpad. JS could have more than python in that case. 
<rick_h_> +1 for the overall comment after all the in-lines are done
<rogpeppe> frankban: where do you add that final comment?
<frankban> rick_h_: yes, also go diffs can be longer than python ones (gofmt stuff etc)
<rogpeppe> frankban: oh, i see, on a different pae
<rogpeppe> page
<frankban> rogpeppe: yeah, in the conversation tab
<rogpeppe> i think there should be an exception for low complexity diffs, particularly mechanically generated changes
<rick_h_> definitely
<rogpeppe> for instance, in Go, you may well change an import path which might affect 1000s of lines, but it can still be a trivial change
<rogpeppe> it's got to be a judgement call in the end, i think
<frankban> yeah
<frankban> rogpeppe: how do you merge stuff in github? just use the big green button?
<rogpeppe> frankban: i've no idea :-)
<rogpeppe> frankban: i am an utter git newbie
<frankban> :-) I'll ask on #juju-dev
<rick_h_> yea, just hit the green button
<rick_h_> until we get the libraries in CI and using the :shipit: lander
<frankban> rick_h_: cool, merged
<frankban> rogpeppe: ok, golxc uses logging.LoggingSuite, I'll update that and then juju-core
 * rick_h_ heads to take the boy to day care
<rick_h_> rogpeppe: if you get a sec can you add a card to the board please for your current work?
<rogpeppe> rick_h_: ah yes, will do
<frankban> rogpeppe: could you please take a quick look at https://code.launchpad.net/~frankban/golxc/fix-logging-suite/+merge/221210 ?
<rogpeppe> frankban: not on codereview?
<frankban> rogpeppe: no lbox files in golxc
<rogpeppe> frankban: you can still use lbox
<frankban> rogpeppe: you are right, let me create that
<rogpeppe> lbox propose -for lp:golxc/trunk
<frankban> rogpeppe: https://codereview.appspot.com/92660046
<rogpeppe> frankban: i'm not sure about hardcoding /usr/bin there
<rogpeppe> frankban: who's to say whether that's the location that the user is using for their lxc binaries?
<rogpeppe> frankban: i think that probably commandArgs.SetUpSuite should save the value of $PATH, then TestCreateArgs etc can restore it
<frankban> the errors are like this: http://pastebin.ubuntu.com/7536121/
<frankban> rogpeppe: +1 on saving the PATH
<frankban> rogpeppe: updated
<hazmat> frankban, afaics bug 1324097 is still an issue (just filed that)
<_mup_> Bug #1324097: charm get api doesn't work with store charms <juju-core:New> <https://launchpad.net/bugs/1324097>
<rick_h_> hazmat: cool will add that to our maintenance backlog to look at
<rick_h_> hazmat: or is that related to the recent refactor work?
<hazmat> rick_h_, its been a bug in that implementation since it was done
<rick_h_> hazmat: ok cool, added to our on deck maint. 
<frankban> hazmat: we are now working on breaking the store into a separate project. rick_h_: is the goal to have the store itself expose an API for getting charm files?
<rick_h_> frankban: yes, it'll be part of the api v4
<hazmat> frankban, not related
<rick_h_> frankban: speaking of going to share a doc with you to keep an eye on
<hazmat> frankban, unless your going to remove the broken api method
<rick_h_> frankban: but as hazmat says, this is more a store bug issue and with us working on the store it's something we should keep an eye on and be willing to update as we bring up ownership. 
<rick_h_> frankban: and things like this will be great for bringing up new go/store devs
<frankban> hazmat: that's what I was asking, we'll take a look at that, thanks
<frankban> rick_h_: +1
<hazmat> its not really a store api atm, the bug is against the state server api.. 
<hazmat> rick_h_, apiv4 of charmworld? what's the delta on that? i was looking at implementing v3 api against the env to be able to support demos
<rick_h_> hazmat: TBD
<hazmat> ic
<rick_h_> hazmat: once we pull the store out we'll be working on defining api v4 to fix issues with v3, add current store functions required, and adding new ones for bundles/etc so that they're loaded like charms
<hazmat> rick_h_, what version of osx were you on?
<hazmat> re bug 1323803
<_mup_> Bug #1323803: ssl handshake fails on osx  <juju-deployer:New> <python-jujuclient:New> <https://launchpad.net/bugs/1323803>
<rick_h_> hazmat: hmm, latest? /me checks
<rick_h_> 10.9.3
<rick_h_> hazmat: and the openssl version matched the linked url discussion
<hazmat> rick_h_, so this is an osx and python issue.
<rick_h_> hazmat: yes
<rick_h_> hazmat: and webcocket library issue perhaps
<rick_h_> hazmat: I chased it down enough to get close but filed a bug from there. Was trying to help that stein guy get notes on doing his demo stuff from osx and it's more work than I've got time for before I leave tomorrow
<hazmat> rick_h_, no.. its deeper than that
<rick_h_> hazmat: I've added it to our board to look into as we'll hit this with our current work to make juju-quickstart work on osx
<rick_h_> hazmat: right, but it sounds like there might be config/ways to enforce ssl3 at handshake?
<rick_h_> and skip ssl2
<hazmat> rick_h_, its an libssl issue.. the best fix we can do without modifying python or osx version of ssl
<hazmat> is to change the server to only do ssl3 or tlsv1
<rick_h_> hazmat: cool, yea I'm not sure if there's a decent work around for the client or it requires server changes. I figure we can't be the first to hit this stuff (and a google search proves we're not)
<hazmat> rick_h_, there is no workaround for the client
<hazmat> without changing python versions, patching py2.7, bundling a new libssl
 * hazmat upgrades his osx machine to 10.9
<kadams54> guihelp: I haven't seen this kind of failure in a CI build before and I'm not really sure what went wrong: http://ci.jujugui.org:8080/job/juju-gui/1108/console
<rick_h_> kadams54: looking
<rick_h_> kadams54: so your failure was in IE https://saucelabs.com/jobs/fc4e2430d0da47ae8d17960df1bd795d to go look at the sauce data
<rick_h_> kadams54: and the failure was in the notifier widget, which has a giant "FIX ME" because it causes spurious failures so this means just retry. 
<kadams54> Damn you notifier!
<rick_h_> :)
<rick_h_> kadams54: so get that link you have to find the top of that suite run where the link is output
<kadams54> Yeah, this is one of the tests that consistently fails inconcistently in local dev
<kadams54> Ah yes, I see the URL now. Thanks.
<kadams54> How do I trigger a retry? Delete the "Test FAILed" comment?
<rick_h_> yep, notifier is the one place we still have some timeout based stuff that doesn't clean up well and hits race conditions. To fix it means to really refactor the code heavily so it's a maint. card of work to do
<rick_h_> kadams54: no, you have to actually login to jenkins and "build with parameters" and put the sha in 
 * rick_h_ checks of kadams54 has a jenkins account
<rick_h_> heh, guess not
<rick_h_> kadams54: can you please help look at the review backlog and grab one or two please?
<kadams54> rick_h_: I would if this wasn't my swap day :-)
<rick_h_> kadams54: oh right, wtf get out of here
<kadams54> I'm just here to try and get my branch landedâ¦
 * rick_h_ boots kadams
<kadams54> LOL
<kadams54> Will do.
<rick_h_> yea, don't worry about it. run away. I'll make sure it gets landed today
<rick_h_> jcsackett: class based views
 * jcsackett blinks
<jcsackett> did i miss some chatter?
<rick_h_> :P
<rick_h_> jcsackett: no, but it just popped in my head
<rick_h_> Makyo: hatch halt the line, we need to clear out reviews please before working on anything else. 
<rick_h_> Makyo: hatch kadams is out today so really need your help to clear the backlog. I'll help out after my call at the top of the hour
<hatch> rick_h_ sure
<frankban> rogpeppe: any idea about why the new suite produces tons of errors? https://code.launchpad.net/~gz/juju-core/logging_dep_fixes/+merge/221228
<rogpeppe> frankban: almost certainly because it's calling an external command that relies on some environment variables
<rogpeppe> frankban: for example, $HOME will not be set
<frankban> rogpeppe: we are using LoggingCleanupSuite, not IsolationSuite
<rogpeppe> frankban: ah. hmm.
<rogpeppe> frankban: can you reproduce the errors yourself?
<frankban> rogpeppe: yes
<rogpeppe> frankban: hmm, seems a little odd to me - i'd try rolling back selectively to see where the problem started
<frankban> rogpeppe: oh maybe I've found something
 * rick_h_ changes location back to the house. back in a sec
<rick_h_> ccccccdilrkrtfngcdcubbvfldjujftufgbrdufvirfj
<rick_h_> ccccccdilrkrgknbcenkijtgtjflrffcrdlivielkfrr
<rick_h_> bah, yubikey by the headphone jack fail
 * rogpeppe authenticates as rick_h
<rick_h_> bah, was my password so obvious?
<hatch> lol
<rick_h_> jujugui call in 2
<rick_h_> bac: around today?
<bac> y'all sounded amazing on my new noise cancelling earbuds!  so lifelike, except for the lack of ambient noise.
<hatch> next time I'll whisper at you so it's like i'm IN your head
<rick_h_> bac: <3 those. I got those before my last trip and use them a ton now
<bac> hatch: hah.
<bac> rick_h_: got them mainly for flights.  they have to do all instructions in english and spanish and it goes on forever.
<rick_h_> bac: yep, why I got them
<hatch> luca how did you make that Las Vegas story on G+?
<luca> hatch: itâs made automatically from the pictures I took on my phone.
<hatch> so you just upload them into the same album and it 'just works' ?
<hatch> because that's really cool!
<luca> hatch: Iâm not sure, I take the pic, it uploads on wifi, I then usually add it to a public album (this one: https://plus.google.com/u/0/photos/113969209489447903536/albums/6006958803479294513) and then it makes it
<luca> hatch: I think itâs triggered off of a series of photos
<hatch> cool, must be a new type of auto-awesome
<luca> hatch: so if you take a lot of a certain period of time it knows your somewhere special
<luca> yeah
<hatch> maybe it also requires the GPS to be on 
<hatch> so the photos are geo tagged
<luca> it did one for my holiday in Italy too which is better https://plus.google.com/113969209489447903536/posts/Vr6GLXYdkT6
<luca> yeah, I think it needs GPS
<luca> My italy holiday story is all based around location
<hatch> cool - so were you biking in that race?
<luca> hatch: No, thats the Giro, the second biggest professional race.
<luca> hatch: I followed it for 5 days
<luca> itâs like the tour de france
<hatch> ohhh cool, I didn't know people did that :)
<hatch> you're like a bike groupie :P
<luca> just the Italian version of it which has more climbs and worse weather
<luca> haha yeah
<hatch> Looks like it was a great time
<hatch> and this story is really awesome :)
<luca> it was great, a lot of fun, a lot of riding and driving
<luca> I was really tired after it hehe
<luca> the story came out really good
<hatch> So how does one follow a bike race? You fly there then bike behind them? 
<luca> itâs difficult
<luca> and complex
<luca> I took my bike over
<luca> and a rucksake of cycling clothes and a few casual stuff
<luca> you canât cycle the routes because they move too fast
<luca> and the roads get cloased off about an hour before they come through
<luca> usually you get up early in the morning, find a good spot of the course to watch them and spend the time waiting by cycling a part of the course
<luca> every night is a different hotel
<hatch> then after they pass drive ahead?
<rick_h_> hatch: luca yea it goes back through all your photos and builds a story using time/location info
<luca> yeah, you shoot round to a different part of the course
<luca> every morning you check out of a hotel
<luca> so in 5 days we covered 1000âs of kmâs, rode about 250km, slept in 4 different hotels and got up every morning at 6:30
<hatch> heh sounds like an awesome trip :)
<hatch> and makes for a great story :)
<luca> hehe
<luca> thanks
<Makyo> jujugui quick review/qa https://github.com/juju/juju-gui/pull/347
<hatch> I can do it
<hatch> #3 for today :P
<hatch> I feel a little like a gatekeeper
<rick_h_> today is review day in the UIEng house
<hatch> Makyo I THINK your CI failures are the spurious ones
<Makyo> Oh, it hadn't loaded the comment.  Let me check.
<Makyo> I still had the "This can be automatically  merged"
<Makyo> I'll rerun.
<rogpeppe> frankban: what commands have you been using to propose a change to github.com/juju/testing ?
<rogpeppe> frankban: are you using the command line or the web UI?
<frankban> rogpeppe: web UI
<rogpeppe> frankban: ok :-\
<rogpeppe> anyone know how to create a pull request from the command line?
<hatch> onnne moreeeee
<rogpeppe> frankban: also, what command do you use to do the rebase? i always try to read the help for rebase and get totally flummoxed by the maze of flags and possibilities
<hatch> code reviews all caught up and shipping the ones that can be shipped
<frankban> rogpeppe: rick_h_ can help you more with rebasing, I hate that. I created a script which helps me collapsing changes into a single commit without rebasing, but I am sure it can be considered exotic.
<frankban> rogpeppe: anyway, here it is, I called that git-prepare (so that you can run it with "git prepare"): http://pastebin.ubuntu.com/7537428/
<rogpeppe> frankban: thanks
<rogpeppe> frankban: wow
<frankban> rogpeppe: oh, it uses git sync: http://pastebin.ubuntu.com/7537446/
<frankban> rogpeppe: it assumes origin is your own remote (e.g. github.com/rogpeppe/testing) and juju is the central remote (github.com/juju/testing)
<rogpeppe> frankban: BTW your first sed command could be a little simpler: sed -n 's/^\* //p'
<rogpeppe> frankban: ah, i've only got one remote - i've been pushing to github.com/juju
<rogpeppe> frankban: is that considered bad form?
<frankban> rogpeppe: yeah, it is really just a quick hack to make me at least understand the process, because I really don't get rebasing
<frankban> I have to spend some time learning it I guess
<frankban> rogpeppe: it seems a more usual workflow is 1) fork the project on github 2) work on a branch of your fork and 3) propose your branch for merging into the original one (usually develop, but in the juju case I saw master is used)
<frankban> rogpeppe: to do that, I basically removed github/juju/testing in my $GOPATH, cloned from my remote, then added the juju remote
<rogpeppe> frankban: i *think* you should just be able to do git remote add
<frankban> rogpeppe: and you can use my "git sync" to sync the two remotes if you like it
<rick_h_> sorry was afk
<rogpeppe> rick_h_: just being my usual git-confused self :-)
<frankban> rogpeppe: yeah, but I wanted origin to be my fork, not juju, and I haven't looked at how to rename remotes
<rick_h_> rogpeppe: heh, it takes some learning for sure
<hatch> git makes a lot of sense once you understand wtf is going on under the hood :D
<rick_h_> rogpeppe: we've got a workflow in the gui hacking doc to help. It has some helpful aliases, process, etc
<rick_h_> https://github.com/juju/juju-gui/blob/develop/HACKING.rst#typical-github-workflow
<hatch> of which, I use none because I'm a masochist 
<frankban> hatch: other versioning systems make a lot of sense even before understanding C
<rick_h_> rogpeppe: it tries to work through setting up the two remotes, sync'ing between them, and keeping your branch up to date
<hatch> frankban haha, well git is special :P
<hatch> Makyo not sure if you noticed - I assigned a card for you under Project 1
<rogpeppe> i just wc'd the combined output of all the git help commands. 21480 lines.
<hatch> today is the day I break non-il flag
<rogpeppe> that's quite something for something that's just a glorified fs
<hatch> rogpeppe lol!!
<hatch> rogpeppe actually it's a glorified db
<hatch> :)
<frankban> rogpeppe: this can help: http://git-man-page-generator.lokaltog.net/
<hatch> ^ hahaha 
<rick_h_> :P
<rogpeppe> frankban: ha ha. is that markov chained from the git man pages?
<rick_h_> jcastro: sent a nice github link out
<hatch> rogpeppe https://www.youtube.com/watch?v=ZDR433b0HJY This video is a great intro to git and actually uses git without any of the git commands to show you how it works
<rogpeppe> hatch: i think part of the problem is that everyone these days seems to learn by example, whereas i think i learn best by understanding the primitives
<frankban> rogpeppe: sadly that's absolutely realistic, the real git help is stackoverflow IMHO
<hatch> rogpeppe then that video is your Yellow Sun
<hatch> holy crap I'm a nerd
<rogpeppe> hatch: i do actually understand how the *underlying* primitives work (well, mostly) - but the primitives we have to work with are the actual git commands
<rogpeppe> hatch: http://en.wikipedia.org/wiki/Yellow_Sun ?
<hatch> rogpeppe http://en.wikipedia.org/wiki/Superman
<hatch> :D
<hatch> superman gets his powers from the yellow sun
<rogpeppe> hatch: ah, ok. i'm not big on comic book fiction
 * rogpeppe watches the video
<hatch> lemme know what you think
<hatch> :)
<Makyo> hatch, okay, thanks.
<hatch> luca Paolo sounds like someone who uses Reddit :P
<luca> hatch: rofl
<hatch> haha
<hatch> looks good luca 
<rogpeppe> hatch: does the video cover rebasing, BTW?
<luca> hatch: thanks :)
<hatch> rogpeppe it has been a long time since I've seen it so I can't remember. 
<rogpeppe> hatch: ok
<hatch> was there a certain question you had about rebasing though that I might be able to answer?
 * rick_h_ goes for food
<hatch> Makyo just FYI you'll need the il flag for your branch
<hatch> it doesn't happen with the inspector on the right
<Makyo> Alright
<rogpeppe> hatch: specifically, if i want to rebase my commits before upstream merging, what would be the usual options and arguments that i'd need?
<hatch> ok assuming you haven't merged anything into this branch since you branched it from develop(or master or whatever your source is) you will run `git rebase -i HEAD~3` where 3 is the number of commits you want to rebase
<hatch> say some new code landed in the source branch that you wanted in yours, ----do not merge that branch in---- run `git rebase develop` where develop is the source branch, this will re play your commits on top of the newly updated branch
<rogpeppe> hatch: what if i *did* merge that branch in? or is that a "you're fucked now, boyo" kind of thing?
<hatch> well....not totally....but it's considerably more work :) 
<hatch> think of git commits always wanting to lay layers on top, if you smush some in the middle it's going to break your sandwich 
<hatch> (at least the way we do it)
<rogpeppe> hatch: ok, so in general i should *never* merge trunk when developing a branch?
<rogpeppe> hatch: (unlike standard bzr usage, for example)
<hatch> correct - if you really need code thats landed use `git rebase trunk` and, assuming this branch was branched from trunk, it will update your branch to the latest code in trunk and re apply your commits on top
<hatch> btw not everyone agrees with using rebase - the git world is really of two camps, the rebasers, and the not :)
<rogpeppe> hatch: IME, you almost always want code that's landed, because you need to check that your changes work in the context of all the changes that have landed since you started work on the branch
<rogpeppe> hatch: i think given the lack of nested commits, rebase is the only reasonable way
<hatch> yep, so running `git rebase trunk` will get you that
<hatch> assuming your branch was branched from trunk
<hatch> git rebase <source branch>
<rogpeppe> hatch: so the source branch argument must be a direct ancestor of the current head?
<rogpeppe> hatch: ah, no, i see
<hatch> no, but to keep a clean commit history it should be
<hatch> cool
<rogpeppe> hatch: where's the HEAD~3 syntax documented?
<hatch> hmm, not sure, lemme look
<rogpeppe> hatch: and why do you want to make it interactive (the -i arg) ?
<hatch> say you had 5 commits, and you wanted to keep 2 outside ones but smush the other 3, this will let you pick and choose ( you can even re order the commits )
<rogpeppe> and otherwise it smushes them all down to one, right?
<rogpeppe> hatch: one other thing: does rebase actually commit anything, or do you have to rebase, then commit?
<hatch> I think you need to use --autosquash to have them automatically smushed
<hatch> rogpeppe it rewrites history so it will be committed but not pushed - if you have pushed those old commits to a remote repo you'll now have to do `git push -f` as the histories won't line up
<rogpeppe> hatch: ah, so when people say "rebase before proposing", that's what they're implying?
<hatch> rogpeppe well some people code with checkpoint commits and you should only commit logical commits into the main repo - so they want you to get rid of the checkpoint commits and turn them into 'topic commits'
<rogpeppe> hatch: (--autosquash, that is)
<hatch> and when I say rebase rewrites history...it only rewrites the high level history so if you screw up you CAN get stuff back http://stackoverflow.com/questions/134882/undoing-a-git-rebase
<hatch> that's why you never want to commit passwords/keys etc into GIT because it's VERY hard to truly delete something
<rogpeppe> hatch: ah, i didn't know about the reflog
<hatch> if you think of git as an api on top of a database you realize that you can do pretty much anything once you figure out how the commands work :)
<hatch> rogpeppe sorry I can't find where the HEAD~3 syntax is documented. But it means from HEAD move two commits back 
<hatch> HEAD~1 points to head
<hatch> weird I know...
<rick_h_> it's like array negative syntax
<rick_h_> [-1]
<rick_h_> is the last char
<rick_h_> [:-3] is the last three chars or commits in this case
<rick_h_> inclusive of HEAD
<rogpeppe> hatch: so if i want to do the equivalent of "bzr push", squashing all the commits i've made into one commit message, i look in the log to find out how many commits i've made, count them (call it $n), do "git rebase HEAD~$n", then do "git rebase origin" ?
<rogpeppe> hatch: hmm, but i don't see a place to specify the commit message there
<hatch> close but not quite
<hatch> :)
<rogpeppe> hatch: and "git rebase HEAD~$n" isn't going to do anything, is it?
<rogpeppe> hatch: hence the -i flag
<hatch> `git checkout <souurce branch>` `git pull <remote> <source branch>`
<rogpeppe> hatch: but i hate interactive commands (i almost never use them) so i'd like to know how to do this non-interactively
<hatch> `git checkout <branch>`
<hatch> `git rebase --autosquash <source branch>`
<hatch> I think it'll take the last commit message
<rogpeppe> hatch: the help for --autosquash says that "This option is only valid when the --interactive option is used."
<hatch> oh wait
<hatch> yeah autosquash looks for a special commit message
<hatch> sorry I use interactive :) one sec lemme look into this
<hatch> kadams54 hey I had one quick comment on your branch then it's gtg mind checking that out :)
<kadams54> hatch: Yeah, I actually hopped on to ask you about that. I posted a reply in the PR.
<hatch> cool looking
<hatch> doh I missed that
<hatch> ok you can shippit
<hatch> thanks
<kadams54> Great
<hatch> rogpeppe doesn't look like it's possible without some extra scripting :/ sorry
<rogpeppe> hatch: ok.
<hatch> rogpeppe I've found that I typically don't want to merge them all into a single commit, but instead to a few 'topic commits' so I've become accustomed to using -i
<rogpeppe> hatch: ok, interesting
<rogpeppe> hatch: can you group all the changes in a particular directory into one commit, for example?
<hatch> rogpeppe there IS a way to commit only blocks of code but I can't remember how to do that. 
<hatch> git has a VERY awesome feature called bisect
<rogpeppe> hatch: ok. so in general you'll be squashing contiguous sequences of commits
<rogpeppe> hatch: bzr has that too
<hatch> oh? oh cool
<rogpeppe> hatch: (well, it may be quite different i guess)
<hatch> git bisect allows you to bounce between commits automatically to test where something broke
<rogpeppe> hatch: for finding the commit that introduced a particular thing
<hatch> so you want commits which help speed this process up
<hatch> if you end up with one 2000 line commit, that's not going to be very helpful
<hatch> or if you end up having to bisect through 100 broken wip commits
<rogpeppe> hatch: the other side of the coin is that it's useful having a commit that corresponds to a given code review
<hatch> for that we have PR's and a merge commit
<hatch> see https://github.com/juju/juju-gui/commits/develop
<rogpeppe> hatch: i found it incredibly great to be able to look at a given commit in the log and jump to the review to see what was going on in people's minds when they made that commit
<hatch> yep you can do that with the merge commits
<rogpeppe> hatch: so the log we're seeing on that page isn't the set of commits we'll see in the git log?
<hatch> rogpeppe that's identical to what's in the git log, but github 'enhances' it to provide links directly to the pr's in question 
<rogpeppe> hatch: so, some of the entries there are of the form "Merge pull request #xxx from..." and some are like "This thing happened". Why the difference, and how can I make my commits look like the latter rather than the former?
<hatch> here is the git log and the github output https://www.evernote.com/shard/s219/sh/3878c3c3-b935-41ac-8a88-50f6d5f6a9fc/fe800bfa9baa93a8a89fa6f8886a3c65
<hatch> although I just noticed it's using the wrong email for my git commits :/
<hatch> anywho - when our CI merges the commits it intentionally creates these merge commits so that you can see what commits line up to the PR's
<rogpeppe> hatch: i don't understand. the merge commits are created by jujugui (which presumably is the CI bot, right?), but how do they match up with the other commits, which seem arbitrarily sequenced in between those commits?
<hatch> they are ordered by time
<hatch> that's why they don't match
<rogpeppe> hatch: oh, that's a bit weird.
<hatch> yeah - it makes sense the first time you have to bisect something though :D
<hatch> easy to find the commit which caused the problem and then the PR associated with it
<rogpeppe> hatch: so the history there doesn't actually correspond to the commit log history, but to when people actually made those changes?
<hatch> well no this is identical to the git log history 
<rogpeppe> hatch: and that's ordered by time?
<hatch> yeah, but remember that people can rebase things, that's why the timestamps are out of wak
<hatch> also - if you rebase incorrectly you can screw up the order too :)
<rogpeppe> hatch: but... this feels really odd to me. so you're saying that the log is essentially arbitrarily order?
<rogpeppe> ordered
<hatch> there is no 'order' to a git log, it's essentially a flattened tree
<hatch> it's not like bzr with revno's
<rogpeppe> hatch: flattened by time-of-commit, right?
<hatch> it's a little more complicated than that....like flattened by tree position
<Makyo> Here's a helpful alias for logs, if it helps: lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
<hatch> rogpeppe to run that copy and paste this : git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
<hatch> Makyo good call, that does make it easier to reason about
<rogpeppe> Makyo: ah, that --graph is useful, thanks
<rogpeppe> ha, less(1) doesn't seem to display colours
<hatch> rogpeppe you may also find this interesting http://nvie.com/posts/a-successful-git-branching-model/
<rogpeppe> hatch: so if it's flattened by tree position, then i still don't see how successive commits to the tree can get spread out
<hatch> yeah I don't truly understand it either
<rogpeppe> hatch: hmm, yeah, it's definitely not strictly time-ordered
<hatch> no, if you rebase commits they can get assigned old dates for new commits
<hatch> it's kind of funky
<hatch> it's like, it's position in the graph 
<rogpeppe> hatch: i was just looking at the dates of the commits in the log
<hatch> I'm sure if you followed the merge step by step through the graph it would make sense
<hatch> yeah - if you rebase new commits into old commits, they get assigned the old timestamp not the new one
<hatch> which puts the timestamp and graph position 'out of sync' I suppose
<rogpeppe> i have to say it's not entirely clear which commit corresponds to which pull request (for example, I *presume* that 002d86d094977ff33880a126a46b9876a11534ea corresponds to 90a1f669d8885c5fd0f6c7d9c0c591a749ab6c0a but it's just a guess
<rogpeppe> )
<Makyo> Huh, didn't notice it until I went back inside to work on a brighter monitor, but the spinner stays overlaid on the inspector in the instance where the sticky headers used to overlay.  I'll see if I can driveby it.
<hatch> Makyo really? Darn that didn't happen to me, should be a quick fix :) definitely drivebyable
<Makyo> hatch, yep, I'll take a look.  I've got the slow connection.
<rogpeppe> perhaps the algorithm is "for a given entry in the log, go forward in the log until you find a jujugui commit with the same author"
<hatch> rogpeppe that does seem like a reasonable technique :)
<rogpeppe> hatch: but is it actually fail-safe?
<hatch> Makyo heh :) who knew there was an advantage to slow internet
<hatch> rogpeppe hopefully you don't need to bisect that often
<hatch> :)
<Makyo> hatch, yeah :)  Can only see it on the nice screen, it's so close to the background color.
<rogpeppe> hatch: it's not necessarily about bisecting, just finding relevant discussion on changes
<hatch> ohh - yeah we typically don't have that many commits between merges so it's pretty easy to find
<hatch> YMMV I suppose
<rogpeppe> hatch: BTW, is there an equivalent of "bzr qannotate" (i.e. git blame but with a nice place to view the commits corresponding to different lines of code)?
<hatch> rogpeppe there IS but I don't know how to get to it, you'll have to hit the googles
 * rogpeppe is done for the day, having failed to propose his PR. oh well.
<Makyo> hatch, Going through the DOM, there are two whole inspectors and the charm browser all rendered in the left hand side, and it's just the z-index on the expose button making it show through.
<rick_h_> the new state stuff isn't cleaning up old views on state change
<rick_h_> ?
<hatch> Makyo ok thats...od
<hatch> d
<hatch> yeah sounds like the inspector isn't being destroyed properly
<Makyo> rick_h_, perhaps.  Still digging to find out what's happening.  z-index seems to be the problem with the spinner overlay, too.
<hatch> maybe check _emptySectionA method in browser.js
<hatch> moving this search is a headache - it breaks darn near everything heh
<hatch> I wish the watchers worked in vagrant
<hatch> CSSSSSSSSSSSS
<jcastro> hey rick_h_
<jcastro> since frankban isn't here:
<rick_h_> jcastro: howdy otp but what's up? 
<hatch> uh oh
<jcastro> juju git-deploy charms/mysql
<jcastro> :D
<hatch> yuss the search widget is placed inside the charmbrowser view now
<hatch> now to make it work
<hatch> poo premature celebration 
<hatch> Makyo I need to edit the spinner rendering code in the charmbrowser, mind if I do that driveby?
<hatch> to avoid conflicts
<hatch> Makyo https://github.com/hatched/juju-gui/commit/9c03ac923b9e92fa97be1ba1ebe873f6f3fe828e
<Makyo> hatch, go ahead, I'm still digging, haven't gotten that far yet.
<Makyo> +1 on the change
<hatch> :) If you have any q's about how that stuff works lemme know, I might have an idea :P
<hatch> rick_h_ i'm in the hangout whenever
 * rick_h_ steps away for a few 
<hatch> back
<hatch> Makyo hey, any luck on the dual render front? I'm curious :)
<Makyo> hatch, not yet, I was thinking it was due to reloadInspector adding an event after destroy
<Makyo> But that doesn't appear to be it.
<hatch> Makyo maybe if you put a debugger in the initializer and turned on async tracebacks you'll be able to see when they get called
<Makyo> Alright, will try that out.
<Makyo> I just can't tell if it's getting reinitialized or if it's being left in place by destroy
<hatch> ahh - well as I understand it, you cannot re-initialize a Y.Base derrived object
<hatch> but that doesn't mean that it's not being destroyed properly or that it's not being double-rendered or something
<hatch> or double initialized for that metter
<Makyo> hatch, it just looks like a destroy thing, but I can't quite pick it apart, there's a lot of hidden stuff going on.  https://gist.github.com/makyo/ab415ea871490c001b59 seems to fix it, but I'm not sure if it's right or not.
<hatch> looking
<hatch> ahhh
<hatch> ok lemme dig into this for a sec
<hatch> Makyo here is the problem https://github.com/juju/juju-gui/blob/develop/app/views/inspectors/service-inspector.js#L96
<hatch> I think
<Makyo> That's what I was thinking, but debuggers never hit in there.
<hatch> really?
<hatch> hmm wth
<Makyo> Yeah, I have no idea.  It's like that's never called under the il flag.
<hatch> so removing the inspectors container and detaching it's events solve the issue...
<Makyo> Yeah, which has me wondering if destroy is doing all its supposed to.
<hatch> well destroy always leaves the container in the DOM in Y.View's which I think is crazy but it's never been an issue for us before because we always pass one in
<Makyo> Yeah.
<hatch> does this 'hidden' inspector work? 
<Makyo> I guess I was thinking something else.
<Makyo> Let me check.
<hatch> or are the events detached
<Makyo> They're still attached.
<hatch> ok so that tells me that the destructor isn't being called at all
<hatch> http://yuilibrary.com/yui/docs/api/files/app_js_view.js.html#l146
<Makyo> Yep.  That's why I was thinking it had been intercepted by something.
<hatch> if you create a destructor method in the service-inspector.js file and put a debugger in there does it get called?
<Makyo> Yeah
<Makyo> Wait, hmm.
<Makyo> It's destroyed properly when you click close, just not when you open a second inspector. 
<Makyo> I noticed that before, but forgot about the state thing,  Let me see if it's destroyed there.
<hatch> ahah!
<Makyo> hatch, if I changestate to null (thus emptySectionA), then changestate to the new inspector, everything's golden.
<Makyo> So I need to see about destroying previous inspectors if the inspector changes state.
<Makyo> The only downside is that there's a brief flash of the charm browser
<hatch> ahh that would make sense
<hatch> yeah
<hatch> we can probably write a nicer way to render the new one then destroy the old one later on maybe
<Makyo> Yeah.  For now, let me focus on that.
<Makyo> Thanks for being a sounding board
<hatch> :-) no problemo
<Makyo> Three line fix.
<hatch> :D and 100 line tests
<hatch> lol
<Makyo> Half frustrating, half relieved.
<Makyo> Right? :{
<Makyo> :P
<hatch> yeah I feel your pain
<hatch> https://www.humblebundle.com/books I just bought this....hope they don't -all- suck :D
<Makyo> hatch, https://github.com/juju/juju-gui/pull/349 if you're still around
<hatch> I am
<hatch> heh nice 
<Makyo> I'll take a quick look at getting rid of the flash before EoD
<Makyo> Thanks
<Makyo> ...that was easy.
<Makyo> Well, quick follow up, then.
<hatch> haha that was an easy fix after tracking it down :)
<Makyo> Yeah, exactly.  Destroy wasn't being called because destroy wasn't being called :)
<hatch> lol
<hatch> dangit where is Huw I have a CSS organization question
 * hatch hopes his ears are burning so he comes online
<huwshimi> Morning
<hatch> A HAH there he is
<hatch> see I told u Makyo  ^ 
<huwshimi> Uh oh
<hatch> :P
<hatch> lol
<Makyo> Haha
<hatch> dangit where is Huw I have a CSS organization question
<hatch> [16:59:20]
<hatch> hatch
<hatch> hopes his ears are burning so he comes online
<huwshimi> :)
<hatch> huwshimi see line 10 https://gist.github.com/hatched/0584d2ae4d9726a148e8
<hatch> why doesn't this work? 
<hatch> shouldn't it?
<hatch> I CAN move it out....it just seems like this should be the right way to do it
<hatch> or does that syntax only work in SASS and not LESS
<huwshimi> hatch: & equals the parent, so you you're trying to find an element that is '.charm-list .with-home [parent] {...}'. I guess that translates to '.charm-list .with-home .charm-list {...}'
<hatch> ohhh
<hatch> I se
<hatch> e
<hatch> dug
<hatch> duh
<hatch> thanks for making me look stupid
<hatch> :P
<huwshimi> hatch: If you're trying to select a .charm-list that has the class .with home you need to do &.with-home
<hatch> https://gist.github.com/1c327a656d3c9af423bb is what I'm trying to do
<hatch> I was just hoping I could keep it more contained
<hatch> because it effects the charm-list element
<huwshimi> hatch: Oh yeah, I hate having do do that sometimes.
<huwshimi> hatch: No solution that I'm aware of.
<hatch> drat, alrighty
<hatch> huwshimi lemme know if my comments on your PR's don't make sense
<hatch> I'll be working a bit past EOD today to make up for some lost time
<huwshimi> hatch: Sure, just taking a look.
<huwshimi> hatch: Makes sense.
<hatch> sounds good - I have no idea why your other branch wouldn't land....
<huwshimi> hatch: Yeah, strange...
<huwshimi> hatch: How do I bind the moveToken event? Something like this? this.addEvent(this.get('unitTokens').on('moveToken', this._placeServiceUnit, this));
<huwshimi> hatch: Will that bind to new unitTokens?
<hatch> moveToken is fired from the token?
<Makyo> hatch, quick driveby on that flash: https://github.com/juju/juju-gui/pull/350
<hatch> huwshimi: the tokens set the machine view panel to be a bubblle target so in the machine view panel you would go `this.on('*:moveToken', this._placeServiceUnit, this)`
<hatch> Makyo nice, I can't QA now because I'm in a middle of some search switchover stuff but I'll try later on
<Makyo> Cool, lemme know.  I'll be around
<huwshimi> hatch: Great, that works. Did you want to review this last set of changes (I know there's a +1 already)?
<huwshimi> (haven't pushed up yet)
<hatch> sure I'll take a peek once you push
<hatch> I'm sure it's good :)
<huwshimi> hatch: One sec, I've broken a test.
<hatch> np
<huwshimi> hatch: I'll let you know once phantomjs stopps crashing
<huwshimi> stops
<hatch> oh...good luck, I have to run my tests in the browser because it crashes 100% of the time for me
<hatch> Makyo I've queued you up another card - this one's going to take some architecture planning :)
<Makyo> Eeeexcellent.
<hatch> we should have a pre-imp whenever you want to get started on it
<huwshimi> hatch: Changes are up.
<hatch> cool I'll take a look
<Makyo> Tomorrow, hatch. Dinner time
<hatch> yeah definitely :)
<hatch> huwshimi looks good 
<hatch> huwshimi happy with where the branch ended up?
<huwshimi> hatch: Yeah, it was a bigger branch than I thought it would be, but it seems OK
<hatch> yeah almost 1000 line diff haha
<huwshimi> hatch: There's a lot of tests in there...
<hatch> haha yes, yes there are
#juju-gui 2014-05-29
<hatch> Makyo +1'd
<hatch> after moving the search into the new view I can only pass 11% of our tests with 16 failures before it crashes
<hatch> lol
<hatch> woops
<hatch> thats for another day!
<huwshimi> hatch: Nice!
<hatch> Yeah I'm pro like that
<hatch> here is to hoping your NEW old branch lands heh
<huwshimi> :)
<hatch> annnnd I'm out
<hatch> have a good one
<hatch> wow we have no outstanding PR's go us! lol
<rick_h_> a good day's work :)
<hatch> haha yup
<hatch> rick_h_ you still around?
<rick_h_> hatch: kinda, packing, loading, playing with toys
<hatch> heh, I actually just figured it out
<hatch> :)
<rick_h_> woot
<hatch> continue playing with toys
<rick_h_> you should be figuring out how to get done for the day and go relax :P
<hatch> been there, done that, it's either read this make file or do the dishes
<frankban> hi rogpeppe: I am working on migrating to IsolationSuite in utils
<frankban> rogpeppe: what do you think about removing the TestPackageDependencies tests from the two or three places in utils/*?
<rogpeppe> frankban: (sorry, was afk)
<frankban> rogpeppe: np
<rogpeppe> frankban: you mean removing the tests entirely?
<rogpeppe> frankban: from the github.com/juju/utils repo?
<frankban> rogpeppe: well, either removing them or waiting for you to refactor FindJujuCoreImports -> FindImports in github/juju/testing. The former can make sense since we are going to split the package, and we "can" assume juju-core is not imported. Anyway, in utils we have several packages, and only two or three define a dependency test
<rogpeppe> frankban: i'm just in the process of proposing the FindImports change
<rogpeppe> frankban: (having spend most of the morning trying to come up to speed with git stuff)
<rogpeppe> s/spend/spent/
<frankban> rogpeppe: with any success?
<rogpeppe> frankban: i think i have a better idea now, but we will see when i try to actually put stuff into practice...
<frankban> rogpeppe: heh, I mean, I'd also like to improve my understanding of rebasing stuff
<rogpeppe> frankban: i think removing the tests can make sense
<frankban> rogpeppe: cool, then in my branch I can just update the testing dependency and refactor the utils test to use the new helper
<rogpeppe> frankban: we could possibly have a test at the root of utils that checks that nothing in utils depends on juju-core, i suppose
<rogpeppe> frankban: sgtm
<frankban> rogpeppe: yeah, that make sense
<rogpeppe> frankban: it should probably just be a pre-commit check though (a recursive grep would do it)
<rogpeppe> frankban: do we have any precommit checks any more, with the demise of .lbox.check ?
<rogpeppe> i guess i mean a pre-propose or pre-merge check
<frankban> rogpeppe: yeah, I'll delete the tests. I think we can set up git hooks
<rogpeppe> frankban: sounds like a good idea. we should continue to check that code is correctly gofmt'd, for example
<frankban> rogpeppe: I am also putting package_test.go files where missing in utils, and replacing juju-core/testing.(Short|Long)Wait with actual values or internal constants when required
<frankban> rogpeppe: so that at the end of the process we'll have a self contained utils/*
<rogpeppe> frankban: you could have local longWait and shortWait constants
<rogpeppe> frankban: great
<frankban> rogpeppe: exactly, when they are used once, I'll replace them with actual values, otherwise I used local constants
<rogpeppe> frankban: perhaps better to always keep them as local constants so that new tests can use them, but YMMV
<frankban> rogpeppe: cool
 * frankban lunches
<rogpeppe> frankban: i found this useful w.r.t. rebasing and other stuff: https://www.youtube.com/watch?v=qh-R0-7Ii_U
<frankban> rogpeppe: thanks I'll take a look
<rogpeppe> frankban: it's the only place i've found so far that talks usefully about git rebase -i
<rogpeppe> frankban: (which, BTW, isn't as "interactive" as i feared - it just uses $EDITOR)
<frankban> yeah
<frankban> rogpeppe: I think FakeHomeSuite should got to github testing as well
<rogpeppe> frankban: i'm not sure there - most of FakeHomeSuite is about core-specific stuff
<frankban> rogpeppe: FakeJujuHomeSuite is clearly core specific, FakeHomeSuite seems to just create a fake home dir with a .ssh and other stuff
<rogpeppe> frankban: ah yes, i didn't notice the distinction there
<frankban> rogpeppe: we might need that later, for utils/ssh
<rogpeppe> frankban: i'm still not sure
<rogpeppe> frankban: it seems like a very specific kind of isolation which is accomplished anyway by clearing the environment, i think
<rogpeppe> frankban: i'm open to arguments the other way though
<frankban> rogpeppe: looking at ssh test, it seems they need both clearing the env and creating/setting a HOME. I am sure we can decouple them easily from FakeHomeSuite by implementing a suite which embeds IsolationSuite and adds the missing bits. My argument is that this kind of suite could be generic enough to be in github testing, but I am ok either way
<rogpeppe> frankban: i *think* i'd prefer something that starts with IsolationSuite and adds the missing bits. what i don't really want to see is every single test adding and removing a bunch of files and directories just because...
<frankban> rogpeppe: also consider that for our goal we don't need to move utils/ssh
<rogpeppe> frankban: indeed so
 * rogpeppe is still struggling with git
<frankban> :-/
<rogpeppe> frankban: how do i create a new repo on github (not through the web UI)
<rogpeppe> ?
<rogpeppe> frankban: git push says "repository not found"
<frankban> rogpeppe: do you need to push a new branch to an existing repo?
<rogpeppe> frankban: i've forked juju/testing, and i want to push it to my own github account so i can make a pull request
<rogpeppe> frankban: (i pushed it to juju before, but it's been deleted from there, i think)
<rogpeppe> s/forked/branched/
<frankban> rogpeppe: try "git push -f origin {featureBranchName}:{featureBranchName}" assuming origin is your fork
<rogpeppe> frankban: isn't that pushing it to github.com/juju ?
<rogpeppe> frankban: i thought the usual practice was to push it to one's own account and then send a pull req from that
<rogpeppe> frankban: ah, i see
<frankban> rogpeppe: it depends on your remote name: i set origin to my fork, if origin is trunk, then replace it with the name of your remote
<rogpeppe> frankban: so in my case, i've added a new remote
<rogpeppe> frankban: i'll try -f
<frankban> rogpeppe: e.g. git push -u rogpeppe {featureBranchName}:{featureBranchName}
<frankban> rogpeppe: -f should not be reuqired
<rogpeppe> frankban: no, still doesn't work
<rogpeppe> frankban: perhaps i have to use the web UI to make the repo
<frankban> rogpeppe: -u should set the tracking reference, so that next time you should be able to just "git push"
<rogpeppe> frankban: (but i was trying to avoid that)
<frankban> rogpeppe: ah! you still don't have the repo! so yes, you need to for from github and then push your branches from the command line
<frankban> rogpeppe: bah, you need to fork the repo from github. good news is that you need to do that only one time for each project
<frankban> rogpeppe: and then push your own branches from the command line, with the command above
<rogpeppe> frankban: i did install a github command line client (ghi), but it doesn't seem to work at all
<frankban> rogpeppe: FWIW https://developer.github.com/v3/repos/forks/#create-a-fork
<rogpeppe> frankban: ah, finally succeeded. part of the problem is i was using github.com/~rogpeppe not github.com/rogpeppe
<frankban> heh
<frankban> rogpeppe: could you please review https://codereview.appspot.com/92700044 ?
<rogpeppe> frankban: i will plough on to try and get this pull request actually submitted first, then i'll look, if that's ok
<frankban> rogpeppe: np and thanks
<rogpeppe> frankban: do you know how to delete a branch on github?
<frankban> rogpeppe: git branch -D $branch
<frankban> git push origin :$branch
<frankban> rogpeppe: first line to delete it locally, second to delete on github, e.g. "git push rogpeppe :my-old-branch"
<rogpeppe> frankban: i don't want to delete it locally, just in github.com/juju/testing
<frankban> rogpeppe: ok so the second one: "git push rogpeppe :my-old-branch"
<frankban> rogpeppe: push takes the remote name and then a pair of local:remote branches. so you are basically saying push nothing to that remote branch
<rogpeppe> frankban: but i still have to delete it locally?
<rogpeppe> frankban: i am still confused about the branch name space
<frankban> rogpeppe: I don;t think so
<rogpeppe> frankban: is it per-repository or per git-database?
<frankban> rogpeppe: I think you can just delete the remote one
<rogpeppe> frankban: so the ":my-old-branch" is a refspec?
<frankban> rogpeppe: yes
<frankban> rogpeppe: so it is source-ref:destination-ref
<rogpeppe> frankban: yeah, i was just reading the manual
<rogpeppe> frankban: now i'm failing dismally to create a pull req
<rogpeppe> frankban: i'm in "create a pull request", which wants a repo to compare against, but it's not clear how to refer to the original repo
<rogpeppe> s/repo to compare/branch to compare/
<rogpeppe> it doesn't seem to let me enter a branch SHA hash
<rogpeppe> or to select juju/testing
 * rogpeppe feels inadequate
<frankban> rogpeppe: uhm... when I create a pull request from github it usually automatically recognizes the destination (I guess using the fork source)
<rogpeppe> frankban: perhaps because i didn't use github itself to fork the repo, it won't let me do a pull req
<rogpeppe> frankban: i guess there's other metadata that github uses outside the repo itself
<frankban> rogpeppe: yes, that can be the case. what did you use?
<rogpeppe> frankban: i created a new repo, then pushed my forked branch to it
<hatch> rogpeppe select 'compare across forks'
<hatch> then select 'edit' again
<hatch> then in the final dropdown select your branch
<hatch> it's a poor UX
<rogpeppe> hatch: i did that, but i don't see an "edit" button
<hatch> on the far right?
<rogpeppe> hatch: nope
<rogpeppe> hatch: (just searched for the text "edit" and no match)
<rogpeppe> hatch: i see four popups ("base fork", "base", "head fork" and "compare")
<hatch> moved discussion...
<rogpeppe> frankban: finally: https://github.com/juju/testing/pull/6
<rogpeppe> hatch: does that look like a plausible pull request?
<hatch> looking
<frankban> rogpeppe: you'll rebase it later, right?
<rogpeppe> frankban: yeah
<hatch> rogpeppe so with these commits i'd probably rebase them all into 1
<hatch> but other than that
<rogpeppe> hatch: ok
<hatch> the rational is that formatting isn't really a commit anyone cares about - and if someone was bisecting through a one line comment change that's kind of irritating :)
<rogpeppe> frankban: since imports.go is essentially moved from juju-core, i thought it should probably keep the same copyright year.
<frankban> rogpeppe: ok
<hatch> jujugui call in 10
<hatch> kanban it up
<frankban> rogpeppe: :+1: == LGTM (at least that's what we do for the gui)
<hatch> jujugui call now
<hatch> kadams54 call
<kadams54> Working on it
<hazmat> made the news http://thevarguy.com/ubuntu/052814/canonical-designers-work-mobile-friendly-ubuntu-cloud-tool
<bac> hi frankban, proposal up at https://codereview.appspot.com/102870043 -- i have not QA'ed it on OS X yet as I am working through and documenting the installation of dependencies before i can get quickstart built.
<frankban> bac: cool I'll take a look
<bac> ty
<bac> jcsackett: maybe you can get paul and deryck to answer your convoy questions via twitter
<jcsackett> bac: it's a thought.
<jcsackett> looks like it was rick and ian doing the work.
<bac> why does the phone hangout app make joining hangouts so difficult?
<hatch> hazmat wow I had no idea that was public
<hatch> jcsackett every time we bring something from LP it seems it wasn't written to be portable heh - (the textarea resziser) :P
<kadams54> hatch: would like to chat about state when you have a few minutes
<hatch> kadams54 sure, couple mins
<hatch> kadams54 ok ready, link me
<kadams54> https://plus.google.com/hangouts/_/gxykkr3joazsb2prf5fdw2j5bea
<hatch> party is over?
<kadams54> https://plus.google.com/hangouts/_/gxykkr3joazsb2prf5fdw2j5bea?authuser=2&hl=en
<hatch> no luck
<hatch> https://plus.google.com/hangouts/_/gwks23a34eatqqhdu46mbaeqiia?hl=en
<hatch> try that
<hatch> evening anthonydillon 
<hatch> luca thx for the new design - but is the 'Local charm' heading supposed to not be centred vertically in the 'header area'
<luca> hatch: now that you mention it, it does look weird, Iâll ask Spencer to have a look and get back to you
<hatch> sounds good :)
<hatch> luca it would be rockin if you could also get him to add dimensions/hex codes ect
<hatch> I know it's more work, but saves us from guessing :)
<luca> hatch: thats fine, he has a tool that does that for him so wont take long
<hatch> oh nice, now I won't accept anything but :P
<frankban> bac: review done
<luca> hatch: lol
<hatch> haha
<frankban> rogpeppe: I had a similar idea re ExcludeEnvVars, that sounds good. I'd be inclined to add that later, in another branch
<rogpeppe> frankban: sgtm
<frankban> data, err was tricky. data was defined globally in another test file, which was not even executed. When I fixed the test, I saw data was not the expected value :-/
<frankban> rogpeppe: ^^
<rogpeppe> frankban: ha
<rogpeppe> frankban: so was the other data value actually used?
<frankban> rogpeppe: yes, causing the test to fail
<frankban> rogpeppe: it seems to me a good practice for tests is to not pollute the global namespace, especially with generic names like "data", correct?
<rogpeppe> frankban: *definitely* with generic names like data
<rogpeppe> frankban: i think it's fine for tests to create globally named tables when they are named explicitly after the tests
<frankban> rogpeppe: yeah
<rogpeppe> frankban: and i actually think it can aid readability
<rogpeppe> frankban: although this is a topic on which there has been some debate :-)
<hatch> oh man I love this new state code
<kadams54> :-)
<kadams54> guihelp: https://github.com/juju/juju-gui/pull/352 is ready for review and QA
<hatch> SEE!!!
<hatch> that's why it's so awesome
<hatch> lol
<hatch> sorry I'm in the middle of some stuff if someone else could pick up that review
<rogpeppe> frankban: BTW, do we have a LGTM convention for replies to PR's on github? or is that thumbs-up symbol automatically created from the word "LGTM" ?
<frankban> rogpeppe: thumbs up is :+1: , and that's just our convention for the gui development.
<frankban> rogpeppe: http://www.emoji-cheat-sheet.com/
 * rogpeppe tries to see a thumbs up in those characters
<frankban> rogpeppe: in the GUI, having CI connected to github,we also use :shipit: to automatically start the CI/landing process
<rogpeppe> frankban: do you know what the convention is in github.com/juju?
<frankban> rogpeppe: no
<hatch> it would be nice if they were the same convention :)
<anthonydillon> hatch, Hey, hows it going?
<hatch> motoring along
<hatch> crazy storms here lately, hoping I don't have to deal with water in the house
<hatch> and yourself?
<hatch> it's rained 6" in 24H lol
<rogpeppe> ha, i *think* i've done my first successful rebase and push
<rogpeppe> the review conversation is lost though. i guess that's inevitable, though sad.
<rogpeppe> i think i'll try to include a link to the pull request in the commit message in future
<rogpeppe> hatch, frankban: could you sanity check this repo please, just to make sure i haven't been stupid? https://github.com/juju/testing
<hatch> sure
<hatch> you guys don't have a CI so you clicked the big green button?
<hatch> ^ rogpeppe 
<rogpeppe> hatch: that's right. actually i just did "git push" but same difference, i presume
<hatch> oh ok, no you did it wrong
<hatch> :D
<frankban> hatch: no CI there
<hatch> rogpeppe https://github.com/juju/testing/pull/6 scroll to the bottom
<hatch> see the big green button
<frankban> hatch, rogpeppe: yeah there is no "Merge pull request" message in the commit history
<hatch> you were supposed to rebase, push back to the pr branch, then push the big green button
<rogpeppe> hatch: but if i did that, all the conversation on the PR would be lost, wouldn't it?
<hatch> this isn't horrible, but now you don't have reference to the PR in the commit history
<hatch> rogpeppe no, it's just hidden
<rogpeppe> hatch: but by rebasing, won't i have lost the items from the commit history?
<hatch> rogpeppe see this one https://github.com/juju/juju-gui/pull/341
<rogpeppe> hatch: so presumably after rebasing i'd need to do push --force onto my branch, right?
<hatch> correct
<hatch> git push -f
<hatch> rogpeppe it's ok, you'll get it :)
<rogpeppe> so many ways to get it wrong. so few ways to get it right :-)
<hatch> lol truth
<hatch> we tried to find a way to disable the wrong ways
<frankban> rogpeppe, hatch: we definitly need to add CI and :shippit: to github/juju stuff
<hatch> but it looks like you just have to be careful
<hatch> frankban agreed
<hatch> maybe after this cycle.....*snicker*
<rogpeppe> hatch: so the reason the comments say "outdated diff" is because the commit has been lost by rebasing, right?
<rogpeppe> hatch: but i'm guessing that github should keep the commits from being GC'd because they've got comments referring to them, yes?
<hatch> correct
<hatch> they are in the reflog
<hatch> so nothing is really 'lost' it's just very well hidden heh
<rogpeppe> hatch: the reflog doesn't prevent things from being GC'd
<rogpeppe> hatch: after 30 days, *gone*
<rogpeppe> hatch: at least that's my current understanding
<hatch> oh....well no the comments are always there
<rogpeppe> hatch: but can i retrieve the branches they're referring to?
<hatch> if you wanted to dig through the reflog
<rogpeppe> hatch: for example if i want to see the entire context of someone elses conversation
<hatch> it's not like bzr in that they are still first class citizens
<hatch> it's quite difficult to get that back
<rogpeppe> oh
<rogpeppe> hatch: for example, i very often need to look at the entire file to see the context, rather than just a limited window. the standard diff view doesn't seem like it provides that.
<hatch> if you're worried about rebasing after reviews you can make logical commits after the fact and if you don't rebase those out, then those commits and comments will still be there
<hatch> I typically rebase those out because the original commits are no longer valid without the review changes
 * rogpeppe found the rietveldt model worked pretty well for this stuff.
<rogpeppe> i very often would do a diff between different stages of the code review
<hatch> rogpeppe the BIG difference now is that we really try and make much smaller commits
<hatch> er
<hatch> PR's
<hatch> when possible
<rogpeppe> hatch: we always tried to do that. sometimes it just doesn't work out.
<hatch> I've noticed that our PR size has dropped dramatically since switching from bzr to git
<kadams54> guihelp: I probably missed this in standup, but anyone know what the status is on Huw's "Wire existing containers and machines into the unit token." card? It's in the review lane but I don't see an associated PR.
<hatch> kadams54 hmm I wonder if that's one of the ones that landed
<hatch> lemme check
<kadams54> It seems to have landedâ¦ there are dropdowns with machines/containers in the unplaced unit now
<hatch> rogpeppe so the issue you have is that commits after putting up for review get rebased out without their comments?
<hatch> kadams54 yeah I think there was some mixup with the card naming
<hatch> you can probably drag that over
<rogpeppe> hatch: that's a potential issue raised by others, yes.
<rogpeppe> hatch: i don't know if it's actually the case or not.
<kadams54> hatch: Good. It'll save me from having to come up with an explanation for exceeding max WIP :-)
<hatch> kadams54 my explanations are usually "jus tryin to get work done man"
<hatch> :P
<rogpeppe> hatch: i just want to make sure that a) the commit history looks sane and b) all the conversations are available indefinitely after the merge has been done.
<kadams54> hatch: should his card go in Daily Accountable or Landing?
 * rogpeppe needs to stop for the day
<rogpeppe> g'night all
<hatch> rogpeppe tbh it hasn't been an issue with the GUI, but you can play it by ear 
<hatch> gnt
<hatch> kadams54 landing
<jcastro> hey hatch
<jcastro> since rick is missing I shall bug you ...
<jcastro> I have an odd request
<jcastro> is there a way we can slow do then deployment animation on jujucharms.com?
<jcastro> to kind of make it not so fast/instant?
<hatch> hmm
<hatch> no
<hatch> well not without some time investment in it
<hatch> jcastro you could hook it up to a local env, then it'll be much slower :)
<jcastro> yeah
<hatch> jcastro the issue is that when you're on a fake env it doesn't go through the typical lifecycle stages
<hatch> so those would have to be simulated on top of the deployment
<hatch> which is not a trivial fix
<jcastro> well, it doesn't need to be realistic
<jcastro> just not instant
<jcastro> like, add a few seconds
<hatch> yeah the problem is that just flips a switch to deployed, there is no system in place for simulating the steps
<Makyo> hatch, got a sec for a call?
<Makyo> It can wait, too.
<hatch> yeah link me
<Makyo> standup is empty: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<hatch> oh will these tests ever end!!!!
<kadams54> guihelp: looking for a review and QA on https://github.com/juju/juju-gui/pull/352
<hatch> kadams54 I'll get to it before EOD if noone else does, I'm still powering on these darn tests
<hatch> 3 more to write then fixes (I'm sure)
<kadams54> :-)
<hatch> 3 failures
<hatch> left
<hatch> jujugui looking for two reviews and qa's https://github.com/juju/juju-gui/pull/353 plz and thanks
<hatch> kadams54 I can do yours now
<hatch> kadams54 done - one comment
<Makyo> jujugui splitting my day to run down and pick up stuff for the move, will be back on this evening.
<Makyo> hatch, will likely miss the Australian call; you planning on heading to that?
<hatch> yep
<huwshimi> Morning
<huwshimi> hatch: Do you know if the AU call is happening today?
<hatch> huwshimi well it's just me
<hatch> :)
<hatch> I think everyone else has left me
<huwshimi> haha, ok
<hatch> I have a branch which you can review and qa though
<huwshimi> hatch: Sure
<hatch> https://github.com/juju/juju-gui/pull/353
<hatch> doh!
<hatch> I committed stuff I shouldn't  have
<hatch> fixing
<huwshimi> np
<hatch> updated
<hatch> I want to get this branch landed when I get in tomorrow so I can start switching over the il flag
<hatch> kadams54 the card that you have in starting is already done
<hatch> Makyo had fixed it yesterday 
#juju-gui 2014-05-30
<hatch> huwshimi I replied to your comments
<huwshimi> I'll take a look
<kadams54> hatch: Thanks for the heads up on my card. I got it to happen once or twice but then had a hell of a time reproducing. Now I know why :-) I suspect the first few times were due to cached JS.
<hatch> kadams54 yeah :) 
<hatch> huwshimi thanks, so pending that other issue it qa'd ok?
<hatch> I'll take a look into it, but because it's pre-existing I might push it to a follow-up
<huwshimi> hatch: Yep.
<hatch> thanks, can you +1 it :)
<huwshimi> hatch: Done.
<hatch> thanks!
<hatch> kadams54 I don't suppose you're up for some late night reviewing? :D
<kadams54> hatch: sure!
<hatch> sweet https://github.com/juju/juju-gui/pull/353
<hatch> thanks
<hatch> it's big....:)
<hatch> huwshimi I made a card for the double render issue, fyi
<kadams54> hatch: so why the extension for the search widget?
<hatch> kadams54 because the charmbrowser view was getting too big
<hatch> and all of those methods were directly related to the widget
<hatch> so it was a nice place to split it up
<kadams54> Why go with plain prototypical object in the extension, instead of Y.Base.create()?
<hatch> that's all extensions are
<hatch> they are simply a collection of methods which get mixed in
<hatch> anything that's Y.Base.create'd is actually a subclass
<hatch> think of extensions as mixins
<kadams54> (y)
<hatch> it's a really confusing name, extension
<kadams54> I like what I see so far
<hatch> eggcellent
<kadams54> Much cleaner
<hatch> good thing I've used skype so I know what (y) is :D
<hatch> yeah I think this refactoring turned out pretty well
<kadams54> Review looks good. I'm assuming you also want the snot QA'd out of it?
<hatch> that would be nice :) huwshimi found an issue but it was pre-existing so keep that one in mind
<hatch> I've got to run for supper, I'll bbl, thanks again for the reviews
<kadams54> np
<rogpeppe> mornin' all
<frankban> morning fwereade and rogpeppe: I updated https://codereview.appspot.com/92700044, do you want to take another quick look before I approve the branch?
<rogpeppe> frankban: looking
<frankban> thanks
<rogpeppe> frankban: couldn't echoCommand and echoScript still be constants?
<frankban> rogpeppe: like const echoCommand = "/bin/echo"
<frankban> 	s.echoCommand = echoCommand
<frankban> ?
<rogpeppe> frankban: is there a need for SSHCommandSuite to have either of those fields?
<rogpeppe> frankban: i'm thinking: const (echoCommand = "/bin/echo"; echoScript = "#!/bin/sh\n"+echoCommand+" $0 \"$@\" | /usr/bin/tee $0.args")
<rogpeppe> frankban: it's pretty trivial, but i had to look to see if the fields were variable (included a c.MkDir for example) or not.
<fwereade> frankban, rogpeppe: yeah, global constants don't bother me the way global vars do
<frankban> rogpeppe: ok
<fwereade> frankban, LGTM anyway
<rogpeppe> frankban: LGTM too. feel free to change that or not.
<frankban> rogpeppe: updated. rogpeppe, fwereade: thank you both for the reviews
<frankban> fwereade: filed 1324841
<frankban> bug 1324841
<_mup_> Bug #1324841: Improve isolation in utils/file_test.go <juju-core:Triaged> <https://launchpad.net/bugs/1324841>
 * frankban lunches
<rogpeppe> afk
<rogpeppe> back
<kadams54> Morning all. guihelp: Need a review and QA on https://github.com/juju/juju-gui/pull/354
<frankban> kadams54: on it
<kadams54> frankban: Thanks!
<frankban> kadams54: is it expected that each time I close the inspector the search results are reloaded?
<kadams54> Right now it gets destroyed and re-rendered, so yes.
<kadams54> Might be worth talking about whether to just hide/re-show it.
<frankban> kadams54: uhm, is it difficult to do that? reloading remote contents does not seem so good to me, also from a UX perspective
<kadams54> Not sure how easy/hard, but it seems like a new card to me, since it would be a significant change to the current behavior. This card is just about fixing the current behavior.
<kadams54> The behavior around these will change significantly once hatch's branch lands, so I'm trying to avoid changing too much in this card.
<frankban> kadams54: +1
<kadams54> I'll circle back after hatch's branch is merged and if the content is still re-loading I'll make a card to be more efficient.
<frankban> kadams54: sounds good, review done, could you please create a bug/card for this issue?
<kadams54> Will do.
<frankban> thanks
<kadams54> Thanks!
<kadams54> hatch: when you get a chance, I'd like to chat quickly about stubbed methods in PR#352â¦
<hatch> frankban kadams54 The caching branch that Makyo  is working on right now fixes that issue
<hatch> right now there is 0 caching
<kadams54> hatch: good to hear :-)
<hatch> kadams54 replied to comments in #353
<hatch> let me know if I cna land it
<hatch> looking at #352
<kadams54> hatch: go ahead and land it. If you want, I can look into the CSS issue so you can focus on removing the il flag.
<hatch> sounds good, I need a +1 and a QA OK in the PR :)
<kadams54> Yup, it's in there.
<kadams54> Though I just noticed that the merge build is failing?
<hatch> replied to #352
<hatch> looking
<hatch> looks like an IE10 failure, I'll have to pop into that
 * kadams54 sees much pain in hatch's future.
<hatch> we'll see, we'll see
<hatch> ugh it's a dependency issue.....stupid YUI
<bac> jujugui stand up in 8:16
<kadams54> hah
<jcsackett> :14
<jcsackett> :12
<jcsackett> ...we need a really annoying IRC bot that does a countdown in the last 10 seconds.
<jcsackett> "need" may be the wrong word there. :p
<Makyo> Hahah
<Makyo> jujugui call in 2
<hatch> jujugui call now
<hatch> frankban rogpeppe 
<rogpeppe> hmm, i seem to be in the wrong hangout
<frankban> rogpeppe: https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso
<rogpeppe> i'm here: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<rogpeppe> frankban: ok
<bac> jcsacket: can you not bookmark https://plus.google.com/hangouts/_/canonical.com/daily-standup ?  (not trying to beat this to death, just curious what you meant.)
<bac> jcsackett: ^^ oops i somehow misspelled your nick
<bac> Makyo: did the candidate submit the homework in advance?  i don't see it.
<hatch> yay no failures in IE10 locally
<hatch> brb going to get coffee
<Makyo> bac, not that I can see.  I'm assuming we'll get that first thing.
 * bac wants to ask him Big Green Egg bbq questions
<frankban> rogpeppe: could you please merge trunk and repropose? https://codereview.appspot.com/99670045/diff/20001/testing/testbase/log.go?context=10&column_width=80 imports from github testing/logging which is confusing now
<rogpeppe> frankban: ah, ok, will do
<frankban> thanks
<hatch> bak
<rogpeppe> once upon a time, i had a computer that was able to multi-task without preventing me from using the mouse
<hatch> rogpeppe haha
<hatch> when launchpad sends updates from bugs I wish it included a link to the bug
<rogpeppe> it's aaaalll brooken
<hatch> well I hope those IE failures in the CI don't show up again because I coudln't reproduce them locally
<hatch> kadams54 you can't work on your current card until my branch lands :D
<hatch> sorry I forgot to put the blocked symbol on it :)
<hatch> and the IE tests are starting
 * hatch crosses fingers
<hatch> looks like it passed them
<jcsackett> bac: if i bookmark it, and then go to it, it won't let me in.
<jcsackett> even if i switch authuser
<hatch> I -always- have to click the link in the calendar
<hatch> else it won't let me in
<hatch> so it's been 45 minutes since I bought my coffee and I can finally drink it....I think they make it too hot
<rogpeppe> doh! loggo doesn't print anything below warning level by default
<frankban> rogpeppe: review done
<rogpeppe> frankban: thanks!
<rogpeppe> hmm, what's the equivalent of "bzr revert" in git?
<rogpeppe> hatch: %
<rogpeppe> ^
 * hatch looks up bzr revert
<rogpeppe> hmm, i guess "git stash; git drop" will do it
<hatch> well, do you want to keep the changes?
<hatch> or throw them away
<rogpeppe> hatch: throw 'em away
<hatch> `git reset --hard HEAD`
<kadams54> I'm guessing: "git reset --soft HEAD^" if you want to keep the changes, "git reset --hard HEAD^"
<hatch> :)
<kadams54> HEAD goes the latest
<kadams54> HEAD^ goes back one commit
<hatch> I never thought of using stash though...that's a cool technique 
<kadams54> HEAD^^ back two commits
<hatch> I prefer the ~ syntax :)
<rogpeppe> hatch: it's less characters to type :-)
<hatch> haha
<kadams54> out for a bit
<Makyo> jujugui Those participating in the Thibaut Colar interview call in 5
<Makyo> 4
<hatch> 321 go
<hatch> !
<bac> Makyo: attempting to join.
<hatch> il runs deep with this one
<Makyo> jujugui https://github.com/juju/juju-gui/pull/355 quick review, but would like two QAs just to be sure.
<hatch> Makyo did you forget a file or something?
<hatch> I don't see it cancelling the in flight request
<Makyo> hatch, the problem was that even though it was calling the success callback with the cached data, it was still returning a new request, which was then failing.  Returning undefined got rid of that problem.
<hatch> ohh ok
<Makyo> So, not seeing a request to cancel, that becomes a noop.
<hatch> sounds good
<hatch> Makyo couple qa issues https://github.com/juju/juju-gui/pull/355
<Makyo> Cool, thanks, will take a look.
 * rogpeppe is done for the week
<rogpeppe> happy weekends all
<hatch> enjoy!
<hatch> I should have known that after deleting all those loc's the app wouldn't run
<hatch> :P
<hatch> one line fix
<hatch> awww yeah
<hatch> go url flags!
<hatch> oh boo, we were relying on old code and didn't know it
<hatch> down with url flags!
<hatch> jujugui anyone available to help me qa this remove il branch before I spend 100h fixing the tests :)
<hatch> kadams54 my branch landed so you can style away
<hatch> also I noticed the category listing also looks 'off'
<kadams54> I noticed, thanks :-)
<hatch> kadams54 I've removed/modified some css in my il branch https://github.com/hatched/juju-gui/commit/1ffead59a0eea58f915f3a6e3b8b6629752e807c just so we can try and avoid conflicts, (if there are going to be any)
<kadams54> OK
<kadams54> Good to know. Still tracking down the problem on my side, so not sure yet what I'll need to change.
<hatch> css is such a mess of a language
<hatch> I hope one of these days we can switch to sass from less 
<hatch> it'll help a bit I think
<kadams54> hatch: how do you think it'll help?
<kadams54> guihelp: Very small, CSS-only PR that needs review/QA: https://github.com/juju/juju-gui/pull/356
<hatch> well first, I think the less syntax is a little ridiculous so it'll be nicer to read
<hatch> sass also provides much nicer functions and the like to work with
<hatch> which will help with some of our nested modules stuff
<kadams54> We used sass on my previous job; my experience with less started on my first day here :-)
<hatch> on the top level it's pretty much identical, it's when you really get into it that sass starts to shine
<hatch> I'll review/qa your branch
<hatch> kadams54 review and qa done
<kadams54> hatch: FYI, I tried to create a higher specific rule, but !important worked out to be the simpler solution.
<kadams54> I can switch back if that's the standard.
<kadams54> I changed the padding because it broke the inside of the list + I don't see the same breakage that you're seeing.
<hatch> kadams54 well !important is considered bad practice because it's a smell that the specificity of something else is incorrect
<kadams54> Yeah, I understand that
<kadams54> I just take what I consider to be a pragmatic approach
<kadams54> I'll try to fix specificity as a first resort, but I'm not a zealot about avoiding !important either.
<hatch> I am because it's almost impossible to override later, you end up with higher specific !importants hah
<hatch> hmm you're not seeing that spacing issue....what browser are you in?
<kadams54> Chrome Canary
<kadams54> This is what I see: http://cl.ly/image/0I2K3Y1s0r1i
<hatch> ok can you try stable?
<hatch> interesting, even in FF I get the spacing issue
<hatch> safari too
<kadams54> Spacing looks good to me in all browsers
<kadams54> FF, Safari, Chrome
<hatch> weird....
<hatch> and the bottom border is across the whole sidebar?
<hatch> doesn't stop 30px away?
<kadams54> Yes, bottom border is across the whole thing and the searchbox is nicely centered in the column
<hatch> well then....
<kadams54> That's in private mode across all those browsers, which should eliminate caching as a suspect.
<hatch> lemme check in Ubuntu
<hatch> and IE
<hatch> gimme a few
<kadams54> Yup
<kadams54> FYI, I pushed a switch to a higher specificity rule, so you may want to re-pull
<kadams54> Not a force push yet
<hatch> checks out in Ubuntu, checking IE
<hatch> I can't believe I need whole separate vm's to try different versions of IE lol
<kadams54> It's integrated with the OS!
<kadams54> :-)
<hatch> ok so it's showing off for me in Win 8 IE 10, OSX Chrome 35.0, OSX Safari 7.0.4, OSX FF 29.0.1 (only the bottom border)
<hatch> hmm
<hatch> kadams54 do you have an ubuntu or windows vm?
<kadams54> Yes
<hatch> mind giving those a check
<hatch> I can't seem to figure out why we would be getting different results from the same codebase heh
<kadams54> Looks fine to me in all.
<kadams54> Tried FF and Chrome in Ubuntu, FF, Chrome, and IE in Win7
<hatch> hmm ok we need a tie breaker
<hatch> jujugui anyone else in atm?
<kadams54> FYI, I'm going to be traveling in 10.
<hatch> yeah np - I'm assuming you're working off the latest develop as well?
<kadams54> My vote is shipit
<kadams54> Even if it is broken, it's less broken than it currently is :-)
<kadams54> Yup
<kadams54> Just double checked
<kadams54> Also a make clean
<hatch> ok I'm trying from a fresh clone - will see if it gets better
<hatch> kadams54 ok question, what is the width of the #bws-sidebar element? and the input[name=bws-input][type=search]
<kadams54> 198 for the input
<kadams54> 290 for the sidebar
<hatch> input: 233px sidebar: 291px 
<hatch> :/
<hatch> wth is going on!!!!!
<hatch> lol
<kadams54> <div class="search-widget"> is 250px with 20px padding all around, which is what the total width of the search widget needs to be. It's what the padding was in the old world.
<hatch> yeah it's 233px wide here
<hatch> er no
<hatch> it's 273px here
<hatch> including the padding
<hatch> 233px is the 'computed' width
<hatch> if I set the width on .search-widget to 250px then it looks good 
<hatch> but why....
<hatch> whyyyyyyyy
<kadams54> There should be no width set on it at all
<hatch> yeah and there isn't
<kadams54> Or rather, width: auto
<kadams54> Your sidebar width is 1px off, but that's not enough to worry about
<hatch> ahh I think I found it
<kadams54> Do you have the mv flag enabled?
<hatch> nope
<kadams54> Hmm, doesn't seem to make a diff for me.
<hatch> the search result list has an inline style on it for 233px
<kadams54> Seems like you're triggering some logic that sets that, while I'm not.
<hatch> yeah - I don't even know what that could be
<hatch> well lets wait for a third party here - if that comes back ok then we will just shippit
<hatch> it's entirely possible my clone is borked somehow
<hatch> I'm going to try once more
<hatch> for good luck
<kadams54> Heh
<hatch> nothin
<hatch> damn
<hatch> FOUND IT
<hatch> WOOOO
<kadams54> What was it?
<hatch> deleting this rule fixes it https://github.com/juju/juju-gui/blob/develop/lib/views/browser/main.less#L59
<hatch> it overrides https://github.com/juju/juju-gui/blob/develop/lib/views/browser/bws-searchbox.less#L6 which must have been put there for a reason
<kadams54> That makes me very nervous
<hatch> yeah, right?  why would the width be specified in two different places, one of which works.....the other doesn't (for me anyways)
<kadams54> Giving it (deleting) a whirl to see how it works for me
<kadams54> Looks good.
<kadams54> Let's roll with it and hold our breath ;-)
<hatch> haha sounds good, want to push it, I'll qa it again and then shippit
<hatch> this is why I hate css
<hatch> :P
<hatch> I suppose it's not entirely the languages fault
<hatch> haha
<kadams54> It's pushed
<kadams54> Once you +1, I'll rebase and squash
<hatch> +1'd!
<kadams54> OK, shipped
<bac> have a good weekend jujugui-peeps
<kadams54> bac: you too
<kadams54> And with that, I'm out
<kadams54> I'll be back on tonight
<hatch> cyall
#juju-gui 2014-06-01
<huwshimi> Morning
<rick_h_> party
<huwshimi> hatch: Are you around by any chance?
<hatch> huwshimi depends....
<hatch> :P
<hatch> wassup?
<huwshimi> hatch: A friend of mine is trying to hook up the ghost charm to nginx, but he can't create a relation. Any ideas why he can't, or how he can make them work together?
<hatch> huwshimi there is a nginx charm?
<hatch> :)
<hatch> The only one I know of is old and unsupported so I didn't even look at making the relation work
<hatch> rick_h_ get back to vacationing! 
<huwshimi> hatch: Ah right.
<hatch> huwshimi does this friend happen to have nginx experience? :)
<huwshimi> haha
<rick_h_> hatch: working on it :P
<hatch> huwshimi I sent an email to the peeps list about my remove il branch - if you have time that would be awesome :)
<hatch> rick_h_ we haven't burnt it all down -YET-
<rick_h_> hatch: lalalalala I'm not looking
<hatch> haha good
#juju-gui 2015-05-27
<frankban> marcoceppi, lazyPower: could you please promulgate https://jujucharms.com/u/juju-gui/redis/trusty/ ?
<marcoceppi> frankban: we can review it ;)
<frankban> marcoceppi: that would be great
<marcoceppi> frankban: can you go ahead and have it added to the review queue? https://jujucharms.com/docs/stable/authors-charm-store#submitting-a-new-charm and I'll have a look at it tonight during my review time
<marcoceppi> frankban: do you want it to be under ~charmers or should it be promulgated under the juju-gui group?
<frankban> marcoceppi: I guess ~juju-gui works ok, we already have the juju-gui charm that way I think
<frankban> marcoceppi: so, should I just file the bug?
<marcoceppi> frankban: yah, and link your branch to it
<frankban> marcoceppi: https://bugs.launchpad.net/charms/+bug/1459345
<mup> Bug #1459345: Review/promulgation request for the Redis charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1459345>
#juju-gui 2017-05-29
<ddd> oracle 
#juju-gui 2017-06-01
<dhruv> juju-model
