[12:04] hey benji: you working on getting "resolved" landed in go? [12:04] hi rogpeppe1, have you had a chance to review my deploy branch? [12:05] bac: hiya. not yet. i'm actually taking a swap day today, but i might be able to take a look anyway... [12:05] rogpeppe1: ok, it would be nice to get it completely resolved, especially since it is in trunk already. [12:05] bac: ok [12:06] frankban, I moved unexpose up to project 1 :-) I will review in a sec. frankban bac teknico I could use two reviews of https://codereview.appspot.com/7741043 [12:06] * bac looks [12:06] card is in review land at top of board [12:08] Makyo, frankban I mentioned the difficulty in landing the annotation branch to Mark Ramm as an opportunity for process improvement and I think he will run with it, at least for a bit. [12:13] gary_poster, is there anything I can read about purpose and usage of an in-memory juju environment? [12:16] teknico, not pre-written, no. The primary initial usage will be in the charm store for 13.04: people will use this as an in-browser "improv" rather than having everyone actually connect to some shared or not-shared server process. We also think it will be interesting for testing, and we think we need it to implement the presentation (and perhaps creation or editing) of bundles and generally allowing an import that [12:16] someone can look at before actually deploying. [12:21] gary_poster, thanks. so is it going to mimic the behavior of both pyjuju and gojuju, and then be kept in sync with both? [12:23] teknico, the component here is intended to be raw behavior, irrespective of py or go. It should need to change little, except for big conceptual changes like changing no longer subscribing to all changes. We will have py and go "wire protocols" that will speak to this component, and yes, they will mimic and be kept in sync. The expectation is that keeping pyjuju in sync right now will be cheap, and we will only k [12:23] eep go juju in sync if it is actuvely helping our testing. [12:24] s/like changing no/like changing to no/ [12:24] gary_poster: yep, that's my first priority [12:24] cool thanks benji [12:32] gary_poster: the daily call time sprung forward, correct? [12:33] right, what's the UTC time for the call? [12:33] uhm, reitveld barfs with "Can't parse the patch to chunks" on app/assets/javascripts/js-yaml.min.js , ok [12:34] bac, yeah, that worked for everyone yesterday, but I'm happy to wait to switch until Europe moves if anyone prefers (teknico?). If we do move forward, the UTC time is 1430 [12:34] teknico: that is a new file so there is no diff [12:34] teknico, ok. that's a minified version of packaged code, so I don't think it needs review. Project is https://github.com/nodeca/js-yaml [12:34] teknico: you can see it by using the first link [12:35] bac, yes, I saw it in the lp diff anyway [12:36] gary_poster, I didn't get what the alternative time is for the call, as opposed to 14:30 UTC [12:36] teknico, the old time, which was 1530, right? [12:36] I'm fine with 14:30 UTC, btw [12:36] ok thanks [12:36] gary_poster, oh, ok [12:41] * benji prepares his vast collection of DST-supporting lawmaker voodoo dolls. [12:41] hatch: around this morning? Still fighting valueChange and curious if you have a sec to take a peek. [12:43] * teknico lunches [12:56] rick_h_, he'll probably be around in 5 or 10 minutes [12:56] gary_poster: thanks [13:35] rick_h_: yup back to work today [13:45] hatch: when you get a sec we should check the logs on the CI charm install again, seeing issues there [13:47] hatch: otp, but want to bug you about the valueChange test in https://code.launchpad.net/~rharding/juju-gui/search-widget/+merge/152737 [13:51] bcsaller_: yeah I saw your email - was just grabbing the creds, do you want me to reply with them? [13:51] hatch: sounds good [13:51] did DST change today? [13:53] hatch: sunday [13:53] hatch, Sunday :-) [13:53] hatch, not for you yet? [13:53] hatch, US has gotten excited about DST lately--we start early and end late [13:53] Canada may not have gotten in on the fun [13:54] Maybe you switch on the 30th like Europe? [13:55] gary_poster: Saskatchewan doesn't observe DST [13:55] hatch, better watch out, benji might move up there [13:55] it's one of the few things the whole prov can agree on :P [13:55] :-) [13:56] lol - not a lot of southerners can handle the winters ;) [13:56] yeah, costa rica might be a better option to escape DST... [13:57] so anyway hatch, is it still OK to have a call in 34 minutes? And will your starting time be typically in 4 minutes? [13:57] now that sounds like a plan [13:57] gary_poster: yes and yes - I can probably work towards starting an hour earlier if it's needed [13:57] hatch: got time for a quick hangout? [13:57] gimme 5 just getting a few things setup [13:58] hatch: rgr [13:58] hatch, great. Only start an hour earlier if you want to. Let me know if you decide to, but for now I'll assume that you will start as before, in 2 minutes [14:04] rick_h_: ok in guichat? [14:04] hatch: sec [14:14] * bac purges cobzr from system. \o/ [14:15] rick_h_: gota hate it when fresh eyes look at something and pick out the problem within seconds eh? ;) [14:16] bac, oh, nice. :-) what are you using instead, the pipes bzr plugin? did thumper put out the write up he mentioned at the sprint? [14:16] teknico: yes, they are in the doc directory of juju-core [14:16] hatch: works for me. Better something simple I didn't see vs doing it completely wrong or trying to make it do something it can't [14:16] both bazaar-*.txt docs are worth reading [14:16] very true very true [14:17] hatch: but yea, I should propose some changes to the docs that note that though. You'd think it'd be pretty much bold'd [14:18] yeah that has come up so many times in the chats but nobody has ever updated the docs [14:18] heh [14:18] is there a company address book that I can download into thunderbird so it will autocomplete the emails? [14:19] yes hatch, looking [14:19] thanks, my search fu was failing me [14:19] hatch: https://wiki.canonical.com/AddressBook?action=show&redirect=LDAP [14:20] yeah that [14:21] eggcelent [14:21] I think I might dual boot this computer into Ubuntu instead of VMing, after a week on my laptop the VM lag is driving me bonkers :) [14:27] jujugui, call in 2 in guichat [14:30] benji, pingy ping ping ping [14:31] gary_poster: coming [14:43] frankban, Getting broken diffs in the 'Support unexpose' code review (error: old chunk mismatch). Can you try reproposing, maybe after merging with trunk? [14:43] Makyo: sure [14:47] Makyo: done [14:47] frankban, Thanks. [14:47] Works now. Review. [14:47] ...reviewing. [14:48] Apologies for not attending. I've been caught up in discussions [14:51] np goodspud. Everything ok? [14:52] gary_poster, all is good in the world [14:52] :-) cool [14:52] gary_poster, and thanks for your comments on the user testing findings [14:53] welcome goodspud. I also commented on an older one from jovan2 that I had missed but it was just to try to clarify. I maybe should have been more helpful [14:54] but hopefully it was at least somewhat helpful :-) [14:54] It's always helpful, even if it challenges us or raises new questions [14:55] :-) [14:55] gary_poster, actually we hate it when people challenge us. [14:56] We are always right damn it! [14:56] :) [14:56] of course! [14:56] all bow! [14:56] :-) [14:56] Actually there is nothing better than seeing a designer react when someone doesn't like their work [14:56] It's quite funny [14:56] lol [14:56] gary_poster: Ben now has all of the information that was in my head that he needed to continue on solo - what would you like me to move onto next? [14:57] hatch, there's nothing to help on with the CI/Windows stuff--it [14:57] 's just wrapping up on both sides? [14:58] thanks for the reviews Makyo and bac [14:59] gary_poster: yeah there is a deployment bug but now that Ben can get into the slave and the instances I'm sure he'll be able to get that going pretty soon [14:59] *famous last words* [14:59] :) [14:59] hatch and IE is working otherwise? [14:59] all tests passing and suchlike? [15:00] well right now we can't run the tests - but they will need some adjustment once they are back up and running [15:00] saucelabs times out if they run to long [15:00] so we'll need to split them up because IE is slower than the rest of the browsers [15:00] hatch, you can run those locally, yeah? Let's talk on guichat, that will be faster :-) [15:03] goodspud: joining the hangout? [15:13] benji, you applied for the juju-gui saucelabs account to be open source, right? [15:13] gary_poster: right (or that was my intent; your question raises doubts) [15:14] ack benji [15:17] benji it is, all good thx [15:17] cool [15:30] bcsaller_, could you join hatch and me in guichat please? [15:32] jcsackett hatch if you get a few min can you look over https://codereview.appspot.com/7519044/ ? See the notes in the comments to help explain why a couple things are the way they are [15:41] yup === deryck_ is now known as deryck === teknico_ is now known as teknico [16:11] rick_h_: this._events.push() is sure ugly...we should pool our brains at some point and come up with a better solution - don'tyathinks? [16:11] hatch: yea, I had thought about a wrapper like this.addEvent() [16:11] and sticking that on Y.Widget, but didn't go that far yet [16:11] maybe an extension! :) [16:12] Y.WidgetEventCleaner [16:12] haha yeah I'd like to almost see that as part of event [16:12] Luke is rewriting event in his spare time so maybe I can chat with him about adding something along those lines [16:12] hatch: hmm...you'd have to get it into the Widget destructor though so not sure how that would work [16:13] it seems you'd just be able to auto/pretty up the Widget side. [16:13] good point.... a base extension then [16:13] because view, widgetm and plugin would bennefit from it [16:13] ugh, not sure...guess I'd have to see how that would work [16:13] yeah I have no idea [16:13] :) [16:13] I only thought so far as a wrapper around _event since I agree it's fugly [16:14] and doesn't minify very well [16:14] meh, gzip ftw ;P [16:19] hey hatch, what's your charm branch? I want to see if something I have merges cleanly [16:20] ~hatch/charms/precise/juju-gui/trunk [16:20] thank you [16:20] that's from memory :) sorry for the lack of link [16:20] heh,np [16:25] rick_h_: review done - just a few small things [16:26] hatch: thanks for the feedback. === matsubara is now known as matsubara-lunch [16:31] rick_h_: oh - I wasn't sure exactly where the notes about the events applied to so I just made the comments anyways :) [16:32] hatch: yea everything looks all good. [16:34] my laptop has an expansion slot thats 3.5cm x 0.5cm - anyone have any idea what it's called? [16:35] I'm wondering if I can get a display port card so I can use my laptop as my daily computer [16:35] ExpressCard [16:35] hah - figures, right after I ask I find it :D [16:39] looks like I'd have to do a ExpressCard USB3>DisplayPort now that sounds like a driver nightmare [16:54] therve, hi. we have a release of juju-gui with landscape bits. https://ec2-50-17-161-4.compute-1.amazonaws.com/ is example with landscape annotations (that I plan to shut down soon ;-) ). password is "admin" but I don't think you'll need it. You may want to use our ~juju-gui charm (juju deploy cs:~juju-gui/precise/juju-gui) rather than the default charmers now; we have a merge pending, and have some other change [16:54] s coming. [16:55] gary_poster, cool, looking [16:57] gary_poster, there are some additional bits in the URL, I don't know if it's your tests data: computers/criteria/environment:env0/computers/criteria/service:mediawiki[...] [16:58] oh, the doubled up bits [16:58] looking [16:59] when everything is artificial it's hard to notice that :-/ [17:00] therve, I think it is the data: annotations are being produced according to the pre-Kapil approach and our code is working with the post-Kapil approach [17:00] that is, our fake annotations are old, but gui code is new [17:00] gary_poster, ok. we'll see how it goes with the real deployment then :) thanks [17:01] cool therve. I look forward to hearing, and we'll jump on fixes if needed. [17:02] * gary_poster declares that url as no longer open. :-) messing with some other things there now. [17:04] gary_poster: the changes you made to lbox would those have come down in the PPA? [17:04] hatch they are in our (gui) trunk. it is just an lbox config [17:04] in a .lbox file [17:04] ohh ok [17:05] therve confirmed it is the old data, fwiw [17:13] I can't seam to propose bcsaller_'s branch because it's saying there is no diff [17:13] hatch, branch of which? [17:13] the ie-cuts branch [17:13] charm or gui [17:13] gui [17:13] looking [17:14] you may have just got an email that shows a 0 diff too [17:14] :/ [17:14] oh [17:14] hatch, you are trying to propose ititself [17:14] it's trying to merge itself [17:14] :) [17:14] yeah that :-) [17:15] so I need to branch trunk, merge ie-cuts then propse that? [17:15] hatch, try merging trunk [17:15] that would be easiest [17:15] and probably best [17:15] alright I'll try that [17:27] rick_h_: did you forget to add the input.focus() in charm-search.js ? [17:27] your comment says that you added it but it's not there :) [17:28] hatch: looking, sec [17:30] hatch: bah, pushing up now. [17:30] :D [17:30] hatch: actually will add a test for that as well so that I don't miss it again. [17:31] that sounds good [17:31] hatch, I saw your ie-cuts mp, cool. will review in a minute. that's a pair branch so you only need 1. [17:31] gary_poster: yeah the propose got all messed up, so I'm trying again [17:31] for your charm branch, I have a change I'd like to either make after you or with you [17:31] lp:~gary/charms/precise/juju-gui/bug1117896 [17:31] hatch, oh! [17:31] ok [17:31] I won't look at it then, nm :-) === deryck is now known as deryck[lunch] [17:32] hatch, for charm branch do you want me to propose the combined branch, to take that off your plate? We could probably all then look at stuff and approve it and move on :-) [17:32] I just verified that it worked [17:32] with staging and building [17:33] and default [17:33] rick_h_: there is one issue with focusing though - if the user has something else focused and then all of a sudden that input is in focus they may be all 'wtfyo where my focus go?' [17:33] gary_poster: sure that would work [17:33] ok [17:33] unless bcsaller_ has made any changes to it ? [17:33] besides logs that is [17:33] hatch: right, so the comes about by something in the UI thinking that the search needs to be udpated. If they click on smoething that does that (category link) the UI will change around anyway. [17:33] rick_h_: gotcha - just wanted to point that out [17:34] :) [17:34] hatch: yea, ideally I'd not have to focus first, but I think it's a good trade off and if I'm wrong we'll tweak it another way [17:34] gary_poster: ok the patch set two diff'd properly in codereview [17:34] ok cool [17:35] rick_h_: yeah I would like some way to trigger the valuechange without focus, but I"ve wanted that for a long long time heh [17:36] hatch: I'll probably have to tweak things as it is once I tie in autocomplete into that search input [17:37] but works for the moment [17:38] oh yeah for sure - I was just mentioning in general - requiring a focus creates issues when a manual value set should also trigger it [17:39] in $project~1 I had that issue [17:49] gary_poster: did you propose the combined branch? I haven't received an email yet [17:49] hatch, I had some escapades of my own, but it is here (no rietveld): https://code.launchpad.net/~gary/charms/precise/juju-gui/bug1117896/+merge/152973 [17:51] ahh gotcha :) [17:52] bac, anyone, we have a juju-core branch. Who do we ask and where to get a review? [17:52] sinzui: ask in #juju-dev === BradCrittenden is now known as bac [17:53] thanks [17:53] sinzui: you'll need two reviews that say *exactly* "LGTM". no other combination of english words or characters are accepted [17:53] "this is the most awesome branch ever and i demand you land it now" does not count [17:54] bac, yep, We've been through that [17:54] sinzui: the reviewers over there are pretty good about watching their email and handling reviews without bugging htem [17:54] * sinzui now type lgtm, r=m, just fucking land it [18:13] gary_poster: looks good - although I think the print's under first_path_in_dir() probably aren't needed - I am pretty sure we only added those for debugging [18:13] 192, 195, 197, 198 [18:16] taking lunch === matsubara-lunch is now known as matsubara [18:59] hatch, ack thanks, will remove === deryck[lunch] is now known as deryck [19:02] I'm pretty sure the changes to the charm require our changes to deploy_charm_for_testing.py to function [19:02] so hopefully ben is making headway on that deployment issue [19:05] hatch, other way around. deply_charm....py needs the charm. [19:05] oh...right, that's what I meant [19:05] :) [19:05] my head is just full of circular references [19:05] pretty soon I'll run out of ram and explode [19:06] :-) [19:06] gary_poster: where you going to bump the WIP limit on 'story 1'? [19:07] not 'where' but 'were' [19:07] bac I got cold feet, but yes, done. [19:07] well, saving [19:07] now it is done [19:07] k, thx [19:08] hatch: The tests are running again, I've been looking into the IE failures, I still see timeouts [19:09] oh ok I was just about to start on that using EC2 [19:09] glad you poped in :D [19:09] what was the issue with the deployment? [19:09] hatch, you can land the ie fixes branch I think [19:09] if the branch was in a pair then we only need one review [19:10] sounds good [19:10] gary_poster: any preferences for my next card? [19:11] benji, cool that you landed the go thing. I think I'd vote for you working on the go stuff: implementing existing go commands in JS, or working on additional go commands [19:13] sounds good [19:14] That destroy-service branch was so much easier than the addunits one. Should've started with that. [19:14] bac: do you have your ubuntu vm disk shared with osx? [19:15] hatch: no [19:15] ahh ok, I wasn't sure if you were actually working in ubuntu or osx [19:15] u [19:15] i think gary used to do the other a long time ago [19:19] hatch it is a pain because of file permissions and changed owners and such. I ended up mounting nfs in OS X and it was ok. [19:20] ahh ok that's what I was thinking of doing - I am trying to find the best @home dev env with my current hardware [19:20] I liked the nfs solution pretty well, actually [19:20] getting it set up was a bit of a pain but not too bad iirc [19:21] things like email might be a little bit of an issue [19:21] so that might have to stay in the VM [19:21] hatch, I actually used server Ubuntu only [19:21] I did everything else in OS X [19:21] and forwarded ports and such [19:21] that was the annoying part [19:22] ahh [19:22] sometimes I just mucked with my /etc/hosts filein OS X [19:22] that sometimes worked ok too [19:24] I hate spending time making things work instead of being productive [19:24] heh [19:24] yeah [19:24] maybe I'll make my own 'ubuntumini' :P [19:25] looks like dual booting them now isn't has hard as it once was [19:27] could pick one of these up http://www.newegg.ca/Product/Product.aspx?Item=N82E16856102001 [19:27] it has a tbolt port [19:59] so should I write this documentation in markup? [20:00] markdown [20:00] heh [20:00] :) [20:00] hatch, where are you going to write it? The charm uses markdown, the gui uses ReST, and the wiki uses...something that I forget [20:01] hatch, so if you want to write the main docs in markdown, I guess you ought to decide that the charm is the best place to write the docs :-) [20:01] then you could add links in the other places [20:01] I'm writing it in a google doc but then I'll likely save it into the gui as that's likely where people would be initing the tests from [20:01] Yeah [20:01] ReST should be target them [20:02] We consume them and make a site with them [20:02] hatch, basics are simple. http://docutils.sourceforge.net/docs/user/rst/quickstart.html [20:02] ReST was a very pooly chosen acronym haha [20:03] alrighty rest it is [20:04] cool [20:58] am I to keep to an 80 char limit in rst files? Does the parser know not to break the lines in the middle of a sentence ? [21:00] hatch: yes (or 79, like the more refined among us) and yes [21:01] ok so I don't or do need to leave a space at the end? [21:01] Here's a reST quick reference: http://docutils.sourceforge.net/docs/user/rst/quickref.html [21:01] don't [21:01] nope, no space at the end of lines [21:01] maybe I'll do 78 just to be extra refined :P [21:02] r [21:02] e [21:02] f [21:02] i [21:02] n [21:02] e [21:02] d [21:02] lol [21:32] bcsaller_, when is your EOD now? [21:32] 32 mins ago? :) [21:33] hatch: still going [21:34] oh alright - things going ok with the tests? I saw that the deploy worked so that's good :) [21:35] hatch: yes, that all seems to be working again, but I haven't figured out why the other isn't working still [21:35] and it still takes a long time to try something [21:36] well...why don't you manually set up the canonistack instance from the jenkins slave and then manually fire off the selenium tests? [21:36] that way you can avoid the instance setup time [21:37] I know that we ran into issues with the deploy leaving things around - but if you ssh into the canonistack instance you 'should' be able to avoid that [21:37] if I am thinking correctly [21:40] jcsackett, review completed [21:40] hatch: yeah, I was thinking that as well. I'm also thinking of adding to the wait_for primitive to support a retry count [21:47] jcsackett ping [21:48] sinzui when you do the hangout with can you invite me manually? on the mobile side atm. [21:48] yes [21:48] thanks [22:05] sinzui are we on [22:05] ? [22:06] I'm just pinging huw [22:06] k [23:03] bcsaller_, were you able to get the sauce labs tests to run locally on your machine? Without going through EC2 or Canonistack? [23:04] I remember you mentioning something about it but I'm not sure what the result was :) [23:09] gary_poster, bcsaller_ first draft http://bazaar.launchpad.net/~hatch/juju-gui/ci-documentation/view/head:/docs/continuous-integration.rst [23:19] Great start hatch, thank you! Perfect [23:20] I will look at it more closely tomorrow