[11:48] <bac> hi luca, do you have assets for the new expose slider?
[11:49] <luca> bac: hmmm
[11:49] <luca> bac: I'll have to have a look, Jamie (Vis designer) is on holiday this week...
[11:50] <bac> luca: it's ok if you don't as i'll just use the old ones and sub them out later.
[11:50] <luca> bac: it might be best to use the old ones
[11:50] <bac> hey, good idea!  :)
[12:08] <rick_h> jcsackett: jujugui can I get a second review on huw's design rework initial branch please? https://codereview.appspot.com/10902044/
[12:08] <benji> rick_h: I'll take a look
[12:08] <rick_h> benji: thanks
[12:09] <rick_h> benji: qa-wise it leaves the old toggle button, but my branch (second in the series) will remove it. 
[12:09] <benji> I assume that's the browser toggle button
[12:09] <rick_h> benji: actually it leaves the min/max button in the upper right corner of the browser bit
[12:10] <benji> k
[12:11] <gary_poster> benji, did you see hatch's email?
[12:12] <benji> gary_poster: I saw his branch land, but I didn't see a human-generated email.
[12:12] <gary_poster> benji, "Critical drag & drop preventing release," I'm afraid
[12:12] <gary_poster> that is the subject
[12:13] <gary_poster> to peeps list

[12:13] <gary_poster> rick_h, why don't you bring up the clear search thing to UX?
[12:14] <gary_poster> might as well see if it was an oversight at the least
[12:14] <rick_h> gary_poster: ok, will do. 
[12:14] <rick_h> oh luca... :)
[12:14] <benji> Either my approach to this task is wrong or our code in this area has some systemic issue (or both!).
[12:19] <gary_poster> benji, it certainly has highlighted what appears to be some major fragility.  If the necessary steps for proper deployment are abstracted into a few functions that would be a win for the future, at least.
[12:23] <benji> rick_h: do I need to QA that branch too?
[12:24] <rick_h> benji: you can, but I've done qa. I should have marked that in the comment sorry. 
[12:24] <rick_h> benji: why I mentioned the one known qa issue atm
[12:24] <benji> cool
[12:25] <rick_h> my follow up that fixes that qa issue is already reviewed yesterdy and I'll land right after this one gets the ok and I submit for him. 
[12:27] <rick_h> thanks benji 
[12:27] <benji> my pleasure
[12:56] <gary_poster> rick_h, fwiw, I clarified the new search widget behavior mocked up by ant with luca yesterday.  If the charm browser is minimized, environment (service) search results come first, and charm search results come second.  Otherwise, the order is reversed.  This is the only difference.
[12:56] <gary_poster> (between minimized and not minimized)
[12:57] <rick_h> gary_poster: ok, but do we have environment search?
[12:58] <gary_poster> rick_h, nope :-)
[12:58] <gary_poster> rick_h, I suggest punting on it for OSCON
[12:58] <gary_poster> rick_h, it will probably be trivial to implement
[12:59] <gary_poster> but we have too many "probably trivial to implement" things in the queue, and some serious burns from some of them
[12:59] <rick_h> gary_poster: yea, the big thing I know we waited on was that you can search, but then when you click you can't load all the data we need to fill out a charm view
[12:59] <gary_poster> rick_h, what do you mean?
[12:59] <gary_poster> oh
[12:59] <rick_h> gary_poster: so there was talk of trying to get juju to enable access to file content like config.yaml/etc but that never picked up priority from juju
[13:00] <gary_poster> rick_h, I *think* that the search of services is supposed to focus the environment view on the service, not open the charm.  I'm pretty sure that's the case actually.  the inspector is responsible for showing charm info for a service
[13:00] <gary_poster> not the charm browser
[13:02] <gary_poster> so the service search would walk through the services in the local JS db, and if it finds some that seem to match, include it in the result list.  If the user clicks on the service in the list, the environment pans to the service and opens its inspector
[13:02] <rick_h> gary_poster: ok. 
[13:02] <gary_poster> if we don't have the inspector, we simply pan for now
[13:09] <luca> gary_poster: I'm working through the dirty input thing and worked out a solution for saving or discarding unsaved changes but I was thinking about the multiple settings in 1 input field problem. I've always had a system in the wireframes that allow users to save each individual setting but you mentioned a while ago that it wouldn't really be a good idea to do that. I've now catered for a "savE
[13:10] <luca> save" feature for settings but if we get multiple settings per input field then it gets really complex to sort out which setting to choose from
[13:10] <luca> gary_poster: I'm not sure if I've worded this at all coherently
[13:10] <gary_poster> :-)
[13:11] <luca> gary_poster: what I;m saying is, if we have each setting input field saveable then it's an easier process if you get multiple inputs. Is it even a problem now that we came up with a solution for the scale units thing?
[13:12] <gary_poster> luca, yeah, I'm not sure what you mean about multiple settings per input field.  Do you mean the case when you are editing a field and someone else has changed the field since you started?
[13:12] <luca> gary_poster: yes
[13:12] <gary_poster> ok
[13:14] <gary_poster> I'm still not entirely caught up with you I think, but getting there. :-) scaling units is a separate control.  The "save" would need to apply to, say, all of the configuration options together, or all of the constraints.
[13:14] <gary_poster> basically the sections you have in the UX divide things up pretty well.
[13:14] <gary_poster> if there is one control, we can do it immediately
[13:14] <gary_poster> if there are multiple controls, we need a save
[13:14] <luca> gary_poster: yeah but if I'm editing "Setting X" and Steve edits "Setting X" do we need to offer conflict resolution?
[13:15] <gary_poster> if it is changed, yes
[13:15] <luca> gary_poster: ok, so
[13:15] <gary_poster> and generally that is the case within a section
[13:15] <gary_poster> so if I am editing config
[13:15] <gary_poster> and changing setting X
[13:15] <luca> gary_poster: If I edit 10 settings, and Steve edits 6 of those settings we should offer conflict resolution on those 6 settings?
[13:16] <gary_poster> then I want to know if config setting X changes, or any other config setting
[13:16] <gary_poster> luca, we need to handle the situation, yes.
[13:17] <luca> gary_poster: ok, It's a tricky one to solve
[13:17] <gary_poster> luca, similarly, if I edit 1 setting, and Steve edits another setting in the same section, I should see Steve's change, and it should be highlighted.
[13:18] <luca> gary_poster: I imagine saving after each setting change would be the easiest way to A) check for a conflict and B) solve a conflict. It could get really messy if we're dealing with multiple conflicts.
[13:18] <gary_poster> it is not a direct conflict, but I should be aware of the world changing, as it might interact poorly with what I'm doing
[13:19] <gary_poster> luca, that is not a good solution practically because (A) settings can work together and (B) saving settings can trigger arbitrary amounts of work.
[13:19] <gary_poster> we don't want to trigger work for an incomplete command
[13:19] <gary_poster> where a "command" would be a set of settings
[13:20] <luca> gary_poster: ok, so we need a solution that can handle multiple conflicts
[13:20] <luca> gary_poster: which shows when the settings were last updated
[13:20] <luca> gary_poster: and can highlight new changes
[13:20] <gary_poster> luca, single setting works for unit target count FWIW
[13:20] <gary_poster> luca, shows when the settings were last updated?
[13:22] <gary_poster> luca, I would be *very* fine with a simple practical solution.
[13:22] <luca> gary_poster: yeah to show whoever goes into the GUI if it was updated recently or not
[13:23] <gary_poster> luca, we won't have that info in many cases.  The GUI could have it if it has been running, but juju will not deliver it
[13:23] <luca> gary_poster: I see, ok
[13:27] <gary_poster> luca, simple practical solution: for instance, we could simply warn the user of different settings as they arrive. If they can see what they are, they can deal with them.  We might not need to stop their flow, just let them know that something else is going on.  We could always show saved values, and then highlight when those "saved" values change.  Alternatively, I would even be OK with heavy-handed solutions as an interim
[13:27] <gary_poster>  solution, like forcing the user to select between the form values and the saved values en masse
[13:27] <gary_poster> Though I'd prefer to be a bit more flexible than that, at least
[13:51] <luca> gary_poster: no cross team meeting today
[13:52] <gary_poster> ok cool luca, works for me, though please ask ant to tell us if he is ok with Huw's SASS plan
[13:52] <luca> gary_poster: He's writing an email as we speak :)
[13:52] <gary_poster> luca, cool thanks :-)
[13:57] <hatch> morning
[14:00] <hatch> hey benji I see you have picked up that card - any luck? need a hand?
[14:01] <benji> hatch: no particular luck but I may have some questions in a bit that you can help with
[14:02] <hatch> alright
[14:29] <hatch> benji: how are those questions coming? :)
[14:30]  * hatch is itching to get this released
[14:30] <hatch> tbh I'm not sure how much help I'll be
[14:30] <benji> hatch: none at the moment; we can pair if you want
[14:30] <hatch> sure just let me grab a coffee
[14:34] <hatch> benji: i'm in guichat
[14:39] <hatch> Makyo: in yet?
[14:41] <Makyo> hatch, yep.
[14:41] <hatch> mind poping in guichat for a quick sec?
[14:42] <gary_poster> hatch when you are available lemme know and we can have a weekly call.  No rush: I'm available up until the team call.
[14:43] <hatch> gary_poster: ok I handed off to Makyo for the time being
[14:57] <sinzui> orangesquad. I just reported https://bugs.launchpad.net/charmworld/+bug/1197435 . I will fix this now and then update the rt to deploy because I don't want this bug to go to production.
[14:57] <_mup_> Bug #1197435: KeyError 'summary' accessing a key that is now an attr <oops> <regression> <charmworld:In Progress by sinzui> <https://launchpad.net/bugs/1197435>
[14:59] <matsubara> gary_poster, hi there
[15:00] <gary_poster> matsubara, hey! on call will ping
[15:00] <matsubara> gary_poster, I'd like to test the tarmac setup for juju-gui. 
[15:01] <matsubara> I'll wait for your ping then :-)
[15:03] <benji> gary_poster: update, Makyo recognized the problem and has a one-line fix.  He'll be adding a test and proposing the branch soonish.
[15:03] <hatch> figures it would be a one liner lol
[15:03] <gary_poster> yay benji and Makyo!
[15:14] <Makyo> Hmm, this was actually fixed by my second branch, yesterday, but the test was stumping me.  Think I've got it now.
[15:39] <Makyo> benji, quick +1 on tests?  One added to check that positions and hasBeenPositioned are set if provided, another checking that annotations are set if hasBeenPositioned is set. https://codereview.appspot.com/10876044/
[15:40] <benji> Makyo: sure, looking
[15:41] <gary_poster> matsubara, hey
[15:41] <gary_poster> you need a branch to test, I'm guessing?
[15:46] <hatch> this fix looks like a lot more than one line ;)
[15:48] <Makyo> hatch, We renamed 'dragged' to something more indicative that the service has been intentionally positioned, plus I added tests per benji.  Same code, in the end.
[15:48] <hatch> reviewing
[15:48] <Makyo> I'm in the process of landing, FWIW.  I have three LGTMs, one from you :)
[15:49] <hatch> Makyo: so how does changing the name fix the issue....or is this just an enhancement on this branch and a fix is in another?
[15:49] <hatch> ohh nm
[15:49] <hatch> ln288
[15:50] <Makyo> jujugui call in 10 kanban now.
[15:50] <hatch> benji Makyo thanks for tackling that issue.....here is to hoping I can finally do the release ;)
[15:51] <matsubara> gary_poster, yes
[15:58] <Makyo> jujugui call in 2
[16:15]  * benji wonders aloud if rick_h is in today.
[16:23] <hatch> shoot things have changed in trunk since yesterday
[16:24] <hatch> I think going forward we need to start making release branches
[16:25] <hatch> and holy smokes I think this QA will pass
[16:25] <matsubara> gary_poster, the jenkins job just finished. Would be ok to disable it and set up the tarmac one in its place so we can test pre commit landing for the next branch?
[16:26]  * hatch grumbles about the lack of a 'home' button in the charm browser
[16:26] <gary_poster> matsubara, sure, though let's wait till Jeff makes a release, which will hopefully be soon.  hatch, agree?
[16:26] <hatch> gary_poster: matsubara very soon, just finishing up the QA
[16:26] <matsubara> ok. hatch, please let me know when you're done so we can continue. :-)
[16:28] <hatch> QA ..... passed *he says expecting it to explode*
[16:28] <hatch> matsubara: ok will do, probably 15-20
[16:29] <matsubara> thanks hatch 
[16:29] <hatch> gary_poster: there is some wako url stuff goign on but I don't think it should block the release....
[16:30] <hatch> when viewing a service and then you click relations the url is
[16:30] <hatch> localhost:8888/:gui:/service/haproxy/relations/#/:gui:/service/haproxy/relations/
[16:30] <hatch> not sure where the # is coming from...
[16:32] <hatch> jujugui ^ anyone know what's up with that
[16:34] <gary_poster> seen that before hatch.  not worth blocking release.  seeing if I can find source really quickly
[16:36] <gary_poster> hatch:
[16:36] <gary_poster> app/views/service.js:              charmUrl = (charm ? getModelURL(charm) : '#');
[16:36] <gary_poster> ?
[16:36] <gary_poster> mm probably not
[16:38] <hatch> shall I make the changes to changes.yaml in trunk then push or should I create a new branch then merge the changes in?
[16:38] <hatch> ^ process pedantics :)
[16:38] <gary_poster> hatch I suggest the former
[16:39] <hatch> sounds good
[16:41] <hatch> in the changes.yaml there is a - > on some lines
[16:41] <hatch> oh that's multiple lines
[16:41] <hatch> nm
[16:48] <hatch> gary_poster: are we talking about the new inspector in the changelog?
[16:48] <gary_poster> hatch, sure can, but clarify it is hidden behind feature flag and in progress
[16:50] <hatch> gary_poster: sounds good https://gist.github.com/hatched/e0ac58187f4bbc544273 did I get all the points?
[16:52] <gary_poster> hatch: "Export environment to YAML from keyboard shortcut." -> "Export environment to Juju deployer YAML format from keyboard shortcut (shift-d)".
[16:52] <gary_poster> or similar
[16:53] <gary_poster> hatch: "Added relations to Go sandbox." -> "Added relations to Go sandbox (Go sandbox still in progress)."
[16:57] <hatch> fixed
[16:57] <hatch> thanks
[17:00] <gary_poster> thanks hatch good
[17:00] <hatch> hmm the make distfile is failing
[17:01] <hatch> there are no uncommitted changes
[17:01] <hatch> there is a shelve (that probably shouldn't matter)
[17:01] <hatch> does the FINAL=1 need to be an environment variable?
[17:03] <gary_poster> hatch, the commands as given wfm
[17:03] <gary_poster> or have in the past I mean
[17:03] <gary_poster> Make will usually do the right thing
[17:03] <hatch> I wish it gave me a real error
[17:04] <hatch> can I clear out the bzr shelve?
[17:04] <hatch> maybe that's what's going on
[17:04] <hatch> parent branch: bzr+ssh://bazaar.launchpad.net/+branch/juju-gui/
[17:06] <hatch> ahah
[17:06] <hatch> it was the shelve
[17:10] <hatch> alrighty qa'ing the tarball
[17:12] <hatch> arg
[17:12] <hatch> drag and drop doesn't work in FF
[17:13] <hatch> I was sure it did in the first QA
[17:13] <hatch> ^ gary_poster
[17:13]  * gary_poster whimpers
[17:14] <hatch> of course this is after I already tagged a release
[17:14] <gary_poster> hatch, wfm on uistage
[17:14] <hatch> hmm ok lemme clear the cache again
[17:15] <gary_poster> hatch, no it failed after I cleared the cache
[17:15] <hatch> *grumble grumble grumble*
[17:15] <hatch> WELL then
[17:16] <hatch> so the drop target is no longer getting caught
[17:17] <gary_poster> hatch works for me again? :-/
[17:17] <gary_poster> nack soon
[17:17] <gary_poster> b
[17:19] <hatch> hmm something is wrong here... the icons are sticking around too
[17:22] <hatch> *sigh*
[17:31] <gary_poster> hatch I don't see problem any more
[17:31] <gary_poster> as I said
[17:32] <hatch> isn't working for me in OSX FF
[17:32] <hatch> lemme try in Ubuntu
[17:33] <hatch> ok works in Ubuntu FF
[17:34] <hatch> ok so works in OSX Chrome and Ubuntu Chrome/FF
[17:34] <hatch> heh
[17:34] <hatch> I suppose that's releaseable
[17:34] <hatch> I'll create a bug right now
[17:35] <gary_poster> hatch I can get it to fail intermittently in Ubuntu FF
[17:35] <gary_poster> it *seems* to be a timing issue
[17:36] <gary_poster> hatch, if I drag it and hold it for a second or two and then release it always works
[17:36] <hatch> ok let me try that in OSX
[17:36] <gary_poster> if I drag it and release it as fast as I can it fails intermittenty
[17:36] <gary_poster> l
[17:36] <hatch> ok even that doesn't help in OSX
[17:37] <hatch> when I drag as fast as I can in Ubuntu it works every time haha
[17:37] <gary_poster> heh
[17:37] <gary_poster> and sigh
[17:37] <gary_poster> ok release it and make the bug, I agree
[17:37] <gary_poster> thanks
[17:37] <hatch> can do!
[17:37]  * hatch pushes the release down the stairs
[17:38] <hatch> oops
[17:38] <gary_poster> quick lunch
[17:38] <hatch> :)
[17:38] <gary_poster> :-)
[17:39] <jcsackett> rick_h, jujugui: can i get two reviews on https://codereview.appspot.com/10916043/
[17:42] <hatch> benji: https://bugs.launchpad.net/juju-gui/+bug/1197486 ;)
[17:42] <_mup_> Bug #1197486: Charm drag and drop does not work in OSX FF <juju-gui:New> <https://launchpad.net/bugs/1197486>
[17:42]  * hatch waits for a laptop to be thrown through my window
[17:42] <hatch> :D
[17:43] <benji> I'll requisition a new MBP immediately.
[17:43] <hatch> lol
[17:43] <hatch> benji: just fyi - I am still releasing just pointing that out :)
[17:44] <sinzui> rick_h, your download count changes are in production now
[17:44] <hatch> uuuuuuugh!
[17:46] <hatch> can someone check out trunk, fire up rapi, try and drag and drop in FF on Ubuntu ?
[17:46] <hatch> It's refreshing the page when I do that
[17:47] <Makyo> wfm, hatch
[17:47] <Makyo> Oh, rapi, just a sec.
[17:48] <Makyo> hatch, reproduced.  It refreshes to eg http://localhost:8888/precise/glance-17
[17:49] <hatch> ok we clearly can't release with that
[17:49] <hatch> son of a
[17:49] <benji> oh man
[17:50]  * benji tries to reproduce the bug.
[17:50] <hatch> I'm starting to get irritated heh
[17:50] <hatch> (at dd)
[17:51] <hatch> hey my numpad works in my vm's now.....
[17:51] <hatch> silver lining?
[17:52] <Makyo> It's feeling race-condition-y caused by the relative slowness of rapi as compared to sandbox
[17:53] <hatch> but it only happens in FF
[17:53] <hatch> ok I fixed it
[17:54] <hatch> benji: Makyo can you please add evt.preventDefault(); into the canvasDropHandler method
[17:54] <hatch> (after evt is defined of course)
[17:55] <benji> hatch, Makyo: I will.
[17:55] <hatch> thanks /me hopes it helps
[17:55] <Makyo> benji, hatch will test on my branch, just to have a third set of eyes
[17:55] <hatch> excellent
[17:56] <hatch> I have no idea why the heck this just started now
[17:56] <Makyo> Good so far.
[17:58] <hatch> great - it looks like it's working here too (OSX FF still broken but whatever)
[17:58] <Makyo> hatch, good with rapi and sandbox, FF and Chrome
[17:58] <hatch> excellent - benji any issues to report?
[17:59] <benji> hatch: I am still seeing the refresh. I'm investigating.
[17:59] <hatch> that's not comforting
[17:59] <jcsackett> sinzui: can you take a look at https://codereview.appspot.com/10916043/
[18:00] <benji> hatch: it was a typo on my part; it works fine with the preventDefault()
[18:00] <hatch> ok awesome
[18:00] <hatch> so now how do I remove the pushed tag heh
[18:01] <gary_poster> hatch you don't.  Just call this 0.7.1 and trash 0.7.0
[18:01] <hatch> sounds like a plan
[18:01]  * hatch restarts the process
[18:01]  * hatch smashes hands with hammer
[18:01] <hatch> :P
[18:02] <hatch> I'll rename 0.7.0 to 0.7.1  ?
[18:02] <benji> ok, I'm going to go get lunch now and try not to drag or drop anything while I'm at it
[18:02] <hatch> lol
[18:06]  * sinzui looks
[18:15] <sinzui> jcsackett,  Why is next() removed from the sidebar method?
[18:23] <hatch> Makyo: I have proposed the fix branch - mind giving it a quick sanity check before I submit? https://codereview.appspot.com/10920043
[18:25] <Makyo> hatch, LGTM
[18:25] <hatch> thanks
[18:25] <hatch> submitting
[18:31] <jcsackett> sinzui: typo. i'll fix it.
[18:31] <jcsackett> well, not typo so much as misdirected delete.
[18:32] <sinzui> jcsackett, once we arrive at the sidebar we are done?
[18:32] <sinzui> jcsackett, I think you mean next() still belongs there...you had an errant dd
[18:32] <jcsackett> sinzui: that is what i am trying to say, yes.
[18:33] <jcsackett> sinzui: if isJujucharms is true, sidebar doesn't get called by default.
[18:33] <jcsackett> sidebar should not be modified.
[18:33] <sinzui> jcsackett, okay. LGTM. I need to step away to rescue my wife from a garage.
[18:33] <jcsackett> sinzui: ok, thanks.
[18:45] <jcsackett> jujugui: can i get one review of https://codereview.appspot.com/10916043/, please?
[18:51] <hatch> sinzui: jcsackett I am concerned that next() was removed and noone noticed, that should have broken something
[18:51] <hatch> (reading from the sidelines)
[19:04] <gary_poster> hatch!  you didn't yell/scream/whoop-n-holler about actually making a 0.7.1 release successully!  yay! :-)
[19:04] <bac> hatch: call when you get chance?
[19:04] <hatch> gary_poster: I haven't compared the tars yet....it could still screw up
[19:04] <hatch> lol
[19:04] <hatch> bac: sure....5 mins
[19:05] <gary_poster> heh
[19:05] <hatch> gary_poster: I'll also post to the blog with the release once I have finished the checklist
[19:07] <hatch> w00t w00t!!! RELEASED
[19:07]  * hatch does a little jig
[19:09] <hatch> bac: ok guichat?
[19:10] <bac> sure
[19:21] <gary_poster> sinzui, questions for you.  (1) on http://uistage.jujucharms.com:8086/ if you look at the new charms, it includes 10 charms that you cannot click on and that you cannot find in search results.  What is the intent there?  (2) the openvpn charm has an icon, it seems, even though it is not reviewed.  how can that happen?
[19:21] <gary_poster> Other bugs:
[19:21] <gary_poster> (not for any particular audience, but tied to Huw's branch)
[19:21] <gary_poster> - the config panel is 10 pixels down from the proper location
[19:22] <gary_poster> - the tab does not expand to the right of the charm details
[19:22] <gary_poster> - the tab does not change color to orange when minimized
[19:22] <sinzui> gary_poster, Anyone can add a charm, it is up to the subapp to ignore it.
[19:22] <hatch> benji: how did you do the bullet points in your release blog post? manually?
[19:22] <sinzui> I think 2 is a regression
[19:22] <gary_poster> - the search field changes size when you minimize
[19:23] <benji> hatch: I don't remember exactly.  I do recall it involved vim though. 
[19:23] <hatch> oh hah ok I'll do it manually
[19:23] <hatch> thanks
[19:23] <hatch> oh they are li's
[19:23] <hatch> it must accept html
[19:24] <hatch> Makyo: is that how you got your headings on your blog post? raw html in the input?
[19:24] <Makyo> hatch, no.
[19:24] <Makyo> Go to /wp-admin, posts, new post
[19:25] <Makyo> That'll give you the full WYSIWYG editor.
[19:25] <hatch> ohh ok
[19:25] <hatch> thanks
[19:25] <Makyo> There'll be a dropdown for paragraph types, etc.
[19:26] <sinzui> gary_poster, I am not certainly about http://manage.jujucharms.com/~nextrevision/precise/openvpn
[19:27] <sinzui> gary_poster, I can see the charm is new, so it is shown. It is not reviewed. Few new charms will ever be reviewed, so they will not show up in search unless you choose to see all
[19:27] <sinzui> gary_poster, so http://uistage.jujucharms.com:8086/fullscreen/search/~nextrevision/precise/openvpn-2/?series=precise&text=openvpn will show it
[19:29] <gary_poster> sinzui, fwiw that url does not show it
[19:29] <sinzui> rick_h, jcsackett ^ per gary_poster's question to me. I think there is a regression. We are showing icons for unreviewed charms. Note that new charms are rarely/never reviewed, so while they are shown on the home page, search will only reveal them if [ ] Reviewed charms is unchecked.
[19:30] <gary_poster> sinzui, if you expand the 10 new charms, none of them will display
[19:30] <gary_poster> http://uistage.jujucharms.com:8086/~james-page/precise/nvp-transport-node-28/
[19:30] <gary_poster> http://uistage.jujucharms.com:8086/~maarten-ectors/precise/storm-0/
[19:30] <gary_poster> http://uistage.jujucharms.com:8086/~med/precise/squid-rp-mirror-0/
[19:30] <gary_poster> http://uistage.jujucharms.com:8086/~daisy-pluckers/precise/hadoop-cassandra-0/
[19:31] <gary_poster> etc.
[19:31] <sinzui> gary_poster, when I tap Storm in the new section I see the details
[19:32] <gary_poster> sinzui, all of them work in fullscreen ("browse") mode
[19:33] <gary_poster> sinzui, none of them work in GUI/sidebar/"build" mode
[19:33] <sinzui> ah
[19:34] <sinzui> rick_h, jcsackett ^ gui is not getting the details for new charms from the sidebar
[19:41] <jcsackett> sinzui: looking.
[19:44] <gary_poster> jcsackett, if the sidebar thing is a quick fix I'd love to have it today.  The icon thing we can push to next week without issue
[19:44] <jcsackett> gary_poster, sinzui: i agree there is an error, i am not sure it is a regression. i have never actually seen behavior on paths with '~' in the charmbrowser, tbh.
[19:44] <jcsackett> unless someone else confirms a path like this used to work, it's possible this was never parsed correctly.
[19:46] <jcsackett> but that does provide a clue.
[19:46] <sinzui> jcsackett, indeed. New are very different from the kind of charms most users work with
[19:46] <gary_poster> jcsackett, I'm messing around. search uses a sightly different approach, fwiw... http://uistage.jujucharms.com:8086/sidebar/search/~juju-gui/precise/juju-gui-68/?series=precise&text=gui
[19:47] <gary_poster> jcsackett, I'm pretty sure that the urls used to look like this:
[19:47] <gary_poster> http://uistage.jujucharms.com:8086/sidebar/~nextrevision/precise/openvpn-2/
[19:47] <gary_poster> that works fine
[19:48] <jcsackett> yeah, we removed showing the default viewmode in urls a little bit ago, and i don't know that we ever looked at '~' paths then.
[19:48] <gary_poster> gotcha
[19:48] <jcsackett> i have a clue where it's breaking.
[19:48] <gary_poster> yeah I like that change
[19:49] <gary_poster> jcsackett, please let me know if you have time to get this out before EoD.  You want me to file a bug with this or the icon thing?
[19:49] <gary_poster> I mean, let me know when you think you know :-)
[19:54] <gary_poster> matsubara, release was made about 40 minutes ago.  I suspect this is your EoD about now?
[19:54] <jcsackett> gary_poster, sinzui, i have a fix.
[19:54] <gary_poster> awesome thanks jcsackett 
[19:54] <hatch> blogs posted birds tweeted
[19:54] <jcsackett> need to put tests in for it, then i'll put it up.
[19:55] <gary_poster> cool
[19:55] <gary_poster> thank you
[19:55] <jcsackett> yw.
[19:55] <hatch> ....0.7.2 /me stomps his feet and grumbles
[19:55] <hatch> :)
[19:55] <gary_poster> sorry :-)
[19:55] <matsubara> gary_poster, nope, not yet.
[19:55] <jcsackett> in the meantime, jujugui, can anyone please review https://codereview.appspot.com/10916043/ ? :-P
[19:55] <jcsackett> i have one, just need a second.
[19:55] <gary_poster> heh
[19:56] <Makyo> jcsackett, on it.
[19:56] <jcsackett> awesome, thanks Makyo.
[19:56] <hatch> jcsackett: why did you not notice that it failed with next() gone?
[19:56] <hatch> something should have seriously broken
[19:56] <benji> jcsackett: do you need a second?
[19:56] <matsubara> gary_poster, so, can I disable the job and put the tarmac one in place? It'd be nice to test with jcsackett branch
[19:56] <gary_poster> matsubara, go for it
[19:56] <jcsackett> benji, nope, just the one, Makyo got it.
[19:56] <benji> k
[19:56] <jcsackett> hatch: i suspect that got deleted in a quick fix for lint, which didn't break tests.
[19:57] <jcsackett> benji: thanks for asking, though. :-)
[19:57] <bcsaller> hatch: ping me when you can have that call
[19:57] <hatch> hmm routing is tough to test too
[19:57] <hatch> I suppose the review was enough this time
[19:57] <hatch> bcsaller: lets do it!
[19:58] <bcsaller> gary_poster: if you're still interested we'll have that call now
[19:58] <hatch> in guichat
[19:58] <hatch> bac: your in guichat
[19:58] <gary_poster> cool thanks bcsaller .  I'll join for a bit, though I'll try to make myself drop out to finish up doc before EoD
[20:01] <abentley> sinzui: Could you please give me a mid-implementation review of https://code.launchpad.net/~abentley/charmworld/slow-migrations/+merge/172895 ?
[20:01]  * sinzui looks
[20:04] <matsubara> gary_poster, ok. changes done. once there's a new MP, tarmac will pick it up
[20:04] <gary_poster> matsubara, when is your EoD?
[20:04] <gary_poster> how long from now?
[20:05] <matsubara> gary_poster, I'll be around for another 2h
[20:05] <gary_poster> perfect thanks matsubara 
[20:08] <matsubara> gary_poster, my last test was done with this branch: https://code.launchpad.net/~juju-gui/juju-gui/juju-gui-test 
[20:08] <gary_poster> cool
[20:11] <matsubara> gary_poster, so basically the tarmac jenkins plugin branches from lp:juju-gui, merges the changes in the MP, pushes the branch to ci branch on LP (https://code.launchpad.net/~jujugui-lander/juju-gui/jenkins-branch) and then passes that branch to the juju-gui test runner to use as --origin. Once the tests pass, it merges the changes into juju-gui or notify failures in the MP. Does that sound like what you needed?
[20:12] <sinzui> abentley, while I review your branch, do you have time for my MP? https://code.launchpad.net/~sinzui/charmworld/charm-object-damn-it-2/+merge/172898
[20:12] <abentley> sinzui: Sure.
[20:15] <abentley> sinzui: r=me.
[20:23] <gary_poster> matsubara, sounds perfect!  thanks!
[20:23] <matsubara> gary_poster, don't thank me yet. let's see if works first :-)
[20:23] <gary_poster> lol, ok
[20:41] <bac> hatch: thanks for the help.  the data binding update worked.
[20:49] <hatch> no problem glad it worked :)
[20:49] <abentley> sinzui: any thoughts so far?
[20:49] <sinzui> yes. I will save what I have so far
[20:50] <hatch> gary_poster: I think that bcsaller and I have come to a great middle ground between what we need now and what will provide us with an easy-upgrade-path later
[20:50] <sinzui> abentley, I add my first comments. I have 100 more lines to go
[20:50] <gary_poster> hatch, bcsaller, great!  I look forward to reading about it. :-)
[20:51] <hatch> and I actually haven't had lunch yet so I think I'll head out to grab some
[20:51] <gary_poster> heh, ok, enjoy
[20:51] <hatch> have a great holiday everyone
[20:51] <gary_poster> thank you!
[20:51] <hatch> see ya Monday
[20:51] <hatch> annnnd anytime :)
[20:52] <gary_poster> :-)
[20:55] <sinzui> abentley, I don't have any other comments
[21:00] <gary_poster> jcsackett, I see the MP.  Should I review?
[21:01] <jcsackett> gary_poster, that would be awesome. i was just about to ping.
[21:01] <gary_poster> cool, on it
[21:01] <jcsackett> gary_poster: hm, looks like it hit LP, but not rietveld yet.
[21:02]  * jcsackett is looking at the terminal still sitting on the rietveld step.
[21:02] <gary_poster> :-)
[21:02] <gary_poster> s'ok, trying qa
[21:03] <abentley> sinzui: Thanks!
[21:08] <jcsackett> sinzui: can you look at https://codereview.appspot.com/10914044 it's the new charms fix.
[21:08] <jcsackett> gary_poster: review is up on rietveld ^
[21:08] <gary_poster> ack on it thanks jcsackett 
[21:09] <Makyo> Update on unit controls: https://codereview.appspot.com/10763045 Fixes ghost inspector (something leftover from an old branch), and also squashes a bug where the units attr of a ServiceModel wasn't updating on ServiceUnitModel.remove.
[21:10] <Makyo> bac is tagged on the card, but anyone from jujugui..? ^^^
[21:10]  * sinzui looks
[21:11] <gary_poster> jcsackett, qa == thing of beauty, joy forever.  will look at code now.  Makyo if it is fast will look.  need to go soon to get back for call with Huw
[21:11] <Makyo> gary_poster, not terribly fast, would like QA.  Go call :)
[21:12] <jcsackett> "qa == thing of beauty, joy forever" is going to be my new slogan.
[21:12] <gary_poster> Makyo, ack :-)
[21:12] <gary_poster> heh
[21:12] <Makyo> gary_poster, Cheers on the Keats, too :)
[21:12] <gary_poster> :-)
[21:14] <sinzui> jcsackett, LGBT
[21:14]  * jcsackett laughs
[21:14] <sinzui> oh damn
[21:14] <sinzui> LGTM
[21:14] <gary_poster> lol
[21:14] <gary_poster> jcsackett, LGTM :-)
[21:40] <sinzui> jcsackett, do you have 2 minutes to look at https://code.launchpad.net/~sinzui/charmworld/charm-object-damn-it-3/+merge/172916
[21:40] <jcsackett> sinzui: yes.
[21:42] <jcsackett> sinzui: r=me.
[21:42] <sinzui> thank you jcsackett
[21:51] <bac> Makyo: i'm looking
[21:51] <Makyo> bac, cheers.
[21:55] <bac> Makyo: is clicking on 'details' supposed to do *that*?
[21:56] <Makyo> bac, This is only implementing the units list and the add/remove unit controls.  We don't have an inspector viewlet for that yet.
[21:56] <bac> Makyo: whew
[21:57] <Makyo> read: I sure hope not in the future :)
[21:59] <bac> Makyo: ah, it is 'env' in both config base and derived configs that cause that recursion error
[21:59] <Makyo> bac, Yeah, something leftover from before, I guess.
[22:02] <bac> Makyo: done
[22:02] <Makyo> bac, cheers, thanks.
[22:24] <huwshimi> Morning
[22:30] <gary_poster> jujugui, call now in guichat for weekly call australian edition
[22:40] <huwshimi> rick_h: Around, by any chance?
[22:59] <huwshimi> gary_poster: Pushed that change.
[23:01] <huwshimi> gary_poster: Would you like me to sneak the change to fix the config panel top positioning into this branch? That way I can  land both of them today...
[23:01] <gary_poster> huwshimi, yes please :-)
[23:02] <huwshimi> gary_poster: OK, give me a couple of minutes
[23:02] <gary_poster> will do
[23:05] <huwshimi> gary_poster: Pushed.
[23:05] <huwshimi> well... I'm in Australia so it's still pushing
[23:05] <huwshimi> OK, complete :)
[23:41] <gary_poster> huwshimi :-) back and looking
[23:41] <huwshimi> gary_poster: Thanks