[03:52] hi huwshimi [03:53] hatch: Hey [03:53] so what's monday looking like? [03:53] I'm trying to decide if I should fake sick tomorrow [03:54] kidding of course :P [03:55] hatch: haha. [03:55] I actually need some code that's on bcsaller's computer lol [03:57] hatch: That's gonna be a long drive. [03:57] haha you're tellin me! [03:58] so instead I played way to much MTG [03:59] hatch: MTG? [03:59] Magic The Gathering [03:59] Ah [03:59] bought the new planeswalker game for Android [04:01] it's $10 and still has in app purchases lol [04:01] oh and ads :/ [04:01] ads for their own stuff mind you [04:01] but still ads [04:02] hatch: is that a MTG game? [04:03] https://play.google.com/store/apps/details?id=com.stainlessgames.D14&feature=nav_result#?t=W251bGwsMSwxLDMsImNvbS5zdGFpbmxlc3NnYW1lcy5EMTQiXQ.. [04:03] ^ huwshimi I'm going to assume it's available there too [12:33] morning [12:36] morning [12:36] gary_poster: did my last reply to the icon bug report clear that up? /me goes to get the link [12:36] #1197772 is the one [12:36] <_mup_> Bug #1197772: Weird charm icon in GUI

[12:37] thanks, haven't gotten to that in mail yet. looking [12:37] k, no hurry. I'll bring it up on our stand up about the proof tools side of things. [12:38] rick_h_, read, got it. so, can we treat that bug as the css issue you described? [12:38] gary_poster: well I'd like to treat it as charmworld provides poor data bug [12:39] gary_poster: otherwise we have to double up logic on 'what categories are valid' in several projects in several places [12:39] rick_h_, because the proof thing won't stop that kind of error from happening, right? it will just inform the user? if they don't do anything then we lose [12:39] gary_poster: well charmworld should not load known bad data on injest [12:39] oh [12:39] gary_poster: so it should either strip the categories or something [12:39] oh [12:39] ok [12:40] I'm ok with stripping the bad categories rick_h_ as a solution, yeah [12:40] so I'd like to move the bug up there. Still a bug, but not really about the icon but allowing bad categories in [12:40] sure [12:40] thanks! [12:46] rick_h_, I think I have some bugs I want to report to ecosystems and ux, but wanted to run them past you. when I search for mysql and then filter to databases, I get no results. It appears that mysql is not categorized as a database. so, related bugs. (1) ecosystems: we should categorize mysql as a database. (2) ux: we should be able to see the category of the charm when we browse it (agree? is that already fixed in ne [12:46] w ux? I don't think so...). Then I dug around a bit more. If you click on a category and then do a search, you are searching within the category. that makes sense, but you can't see anything alerting you of that in the sidebar unless you expand the filter section or look at the URL. (3) UX: fix that <--- (agree? is this already addressed somehow?) [12:47] gary_poster: so definitely think we need to audit approved charms for categories pre-launch. Those at least, should be updated. [12:47] gary_poster: and for the filter UX, I really don't like the auto collapsing because of that. It's not clear what's going on, but it's what UX has requested we try out. [12:47] gary_poster: so I'm up for helping defend the user that it's a bad experience [12:48] gary_poster: in fullscreen (browse now) it's much nicer. [12:48] gary_poster: one thing we tossed out was that searching with filters/etc would require the fullscreen UX to help make it work? [12:50] rick_h_, ok, thanks. I'll send an email about those bits to the various parties, cc-ing the juju-gui list. you didn't reply to #2 though. Maybe it was not clear? [12:51] gary_poster: ah, well not sure on #2. It's never really come up as categories were really only intended to help us group for the browse experience. Charms can have multiple, and they're completely optional. So display is a bit...unclear [12:51] gary_poster: issues with category are more for the charm authors to know/correct and that's more in the back end than for all users of the gui [12:51] imo and all that :) [12:54] rick_h_, ack. I thought of that but felt that, if someone were purely exploring it might be nice ("'storm'? is that the twitter hadoop thing I read about? ...oh, no, it is a database, nevermind"). I'll leave it alone for now. [12:58] rick_h_, apache2 has no icon now. no idea why. maybe another thing to raise on team call? [12:59] gary_poster: last time I looked they had a bad image as their icon. It was an issue with the charm source [13:00] rick_h_, ack, but can we do better on our side is the question (i.e., is this something it would be relatively easy to detect and provide a default image for?) if it is not easy maybe a bug would be reasonable. But I think we ought to treat an empty image as a bug in the GUI of one sort or another. [13:01] gary_poster: yea, we're still working out how we're supposed to note issues we know about to charms upstream. [13:01] gary_poster: so in this case, the svg is invalid or something. I cannot download/load it locally from the source. [13:01] gary_poster: the only 'good' way I can think to prevent this is to find some sort of svg validation/sanity check library on injest. If the icon fails, don't load it into the charmworld backend [13:02] gary_poster: in this case it's not that it's 0 bytes, named wrong, etc [13:02] http://bazaar.launchpad.net/~charmers/charms/precise/apache2/trunk/view/head:/icon.svg [13:04] rick_h_, cool, ack. I wonder if simply trying to convert it (e.g. https://pypi.python.org/pypi/svglib/) and handling conversion errors as the sanity check would be reasonable. I'll file a bug for the GUI side for now, and send an email to ecosystems about the immediate problem. thanks [13:04] gary_poster: well, I'd file it against charmworld [13:04] rick_h_, ah good point thanks [13:04] gary_poster: that's where the convert/validate would need to be updated to occur [13:04] right === teknico1 is now known as tekNico [13:32] gary_poster: if we need like an apache2 icon we ask alejandra's team, then I can just add it to the charm right? [13:34] jcastro, hey. yeah, I am pretty sure you can ask alejandra's team for the icon, and I know you can just add it to the charm once you have it. Was the previous working icon we had bad for some reason? [13:34] I don't know, I could have sworn I remember seeing the feather icon in the store at some point [13:34] It was definitely there jcastro, I remember it too [13:34] yea, I thought it had an icon at some point but did it get 'updated' and removed? [13:34] can we just go back and pull the old icon from the bzr history? [13:35] gary_poster: mysql category is easy, on that. [13:35] cool thanks jcastro [13:35] jcastro: make sure it's the plural please. We've got some that are invalid atm using database vs databases [13:35] k [13:36] category: ["databases"] [13:36] is in mysql [13:36] jcastro: rgr [13:37] jcastro: orly? /me goes to look [13:37] I'm looking in lp:charms/precise/mysql [13:38] categories: - databases [13:38] jcastro: http://bazaar.launchpad.net/~charmers/charms/precise/postgresql/trunk/view/head:/metadata.yaml is working in pgsql charm [13:39] jcastro: yea, it's categories [13:39] that format appears totally different than what I have been doing [13:39] plural plural plural [13:39] everything in the metadata is plural. [13:39] provides, requires, etc [13:40] ok pushed [13:43] morning all [13:53] jujugui: review ahoy! https://codereview.appspot.com/11001043 [13:53] I'll take one [13:53] benji: does this branch have trunk merged in prior to proposing? [13:53] some of this diff looks like trunk code [13:54] hatch: ooh, good catch; it does not. I'll fix that right now. [13:54] thanks :) [13:54] hatch: can I look over your shoulder? :-) [13:55] hatch: I mean, how about you comment loudly what you see while you review, and I get to listen and maybe even ask questions? [13:55] I guess that might count as a second review of sorts :-) [13:56] teknico1: heh well I don't think there will be that large of a diff [13:56] oh benji does this fix the drag&drop bug in FF osx? [13:56] hatch: nope [13:57] ok didn't think so, just wanted to check [13:57] (not intentionally at least) [13:59] otoh, today's net connection instability is not very conducive to these sorts of things :-/ [14:01] hatch: merged branch pushed [14:01] teknico: you think you have bad wiring... http://www.networkworld.com/gibbsblog/IW2.jpg :) [14:01] * benji makes an overdue coffee. [14:01] thanks benji [14:01] heh [14:03] benji: topology/service.js:425 where is the code that we hack the DOM to make the icon show? [14:03] * hatch will see if there is a better way [14:04] hatch: app/widgets/charm-token.js:99 [14:06] thanks [14:07] ohhh right that hack [14:08] benji: did you try setting display to none on the icon? [14:08] or would that have caused the dragged icon to not show up? [14:08] (thinking out loud) [14:08] hatch: I don't recall. I tried a myriad of things. [14:09] heh i bet :) [14:16] hatch: "display: none" doesn't work in FF, the drag image reverts to the default [14:16] benji: ahh ok well thanks a lot for trying :) [14:16] most browsers have very limiting restrictions requiring the drag image to really, truely be visible [14:17] yeah the spec is such a mess [14:18] the webdev community really needs to start relying on polyfills first to iron out the bugs before they make it into the browsers [14:30] sinzui: The mimetypes.guess_type function does not accept contents, just a url: http://docs.python.org/2/library/mimetypes.html [14:31] gary_poster: so as it turns out the position fixed idea won't work for us, and the position sticky polyfills all need to be.....modified... to work :) [14:32] I could fork one of them and enhance the polyfill -or- I can write a module which just absolutely positions the headers when required [14:35] sinzui: However, for this use case, the imghdr module should suffice. [14:35] fab [14:37] abentley, in the proof tool case I wanted to validate the xml, check that it is SVG, and maybe check for evidence that it uses the template [14:38] abentley, The xml validation code we have in charmworld's test suite could be extracted as a helper for ingest and test [14:39] abentley: did you want to have a chat then before I go to far into this autocomplete stuff? [14:40] rick_h_: sure. [14:45] hatch on extended call run...trying to read... [14:45] gary_poster: no problem, whenever you get a chance [14:46] hatch not polyfill because it is not standard [14:46] IMO [14:46] module makes sense to me [14:47] that's what I was thinking - I'll see if I can extract some of the code out of the polyfills to save some dev time [14:51] +1 [14:53] hatch: will you unpack this sentence a bit for me "I believe if you use @property it will automatically pick the closest class" (from https://codereview.appspot.com/11001043/diff/4001/app/widgets/charm-token.js?column_width=80) [14:53] benji: sure :) [14:54] because you're assigning a property to the instance if you use @property I believe that YUIDoc will reach out of the method and pick the closest class that it's being added too [14:54] so then when we look at the api docs for that class that property will be available [14:56] sinzui: Thanks for the reviews. [14:56] np [14:58] sinzui: You may have been thinking of the "magic" package. It's not part of the standard library, but I think it really should be. [14:58] abentley, bingo. I was [15:01] gary_poster: if you noticed on the boards I haven't deleted the cards yet from the last release - wondering what the procedure was for that [15:05] hatch: I will need an unpacking of your unpacking. Are you propsoing I add an @property comment to the initializer (or the class)? [15:05] comment the this. using @property [15:05] just like you would with @method or @attribute [15:07] (the rest of the words after that was just explaining why I expected it to work) :) [15:08] jujugui Can I get one last look at https://codereview.appspot.com/10763045 ? Has two LGTMs, but I'd like a +1 on the tests bac requested. [15:08] Makyo: looking [15:08] hatch, cool, thanks. [15:08] rick_h_: Is the output of charmworld's "make doc" online anywhere? [15:09] hatch: ah, that clears it up; thanks [15:09] abentley: no, one of those things meant to do. Just does it locally. make doc-open I think will open in a browser [15:09] Makyo: this diff is wako [15:09] rick_h_: Okay, thanks. [15:10] hatch, blah, did it do that again? [15:10] I'll just do the tests [15:10] hatch, https://codereview.appspot.com/10763045/diff/27001/test/test_inspector_overview.js is all that was added [15:11] * hatch thinks there are too many people working on the same code, codereview can't keep up ;) [15:18] Makyo: lgtm'd [15:18] one q in there [15:18] hatch, cheers. [15:19] hatch, copied bac on that (restructured my tests to look like his since he landed first), will look into it. [15:19] teknico: did you ever land that branch was supposed to cache the IO requests for the json charm data? I still see them in the test-debug logs [15:20] Makyo: alright cool - it's probably not an issue but using real data is always going to be better of course :) [15:20] Sure. [15:21] hatch: I'm not recalling any such branch right now, more context/timing? [15:22] teknico: umm a couple weeks ago - around when you were doing the test cleanup [15:22] maybe we talked about it but it was never implemented [15:24] hatch: yeah, I can't dig up anything of the sort [15:25] ahh ok then [15:26] I'm looking for one more review of https://codereview.appspot.com/11001043 [15:27] benji, on it. [15:27] thanks [15:27] Makyo, hatch, do you think we can steal any styling from the inspector of https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html ? add a charm and then click on it [15:29] ^ doesn't work in Chrome [15:29] heh [15:29] hatch, Makyo sorry, yes known. Firefox only [15:29] cool they have icons [15:30] we need those [15:30] For just styling, yeah, probably. [15:30] yeah was going to say we could take the styles [15:31] I'm not sure the markup would work with what we want [15:31] but it could.... [15:31] we actually know what the colour codes are using this ;) [15:34] darn I was hoping that service icon was an svg already :D [15:34] Although that's curious, it looks like both service box SVGs are being used there. [15:35] holy all of this html is like super semantic [15:35] Will clarify with luca before I implement. [15:35] I don't think I've ever seen code this semantic before [15:38] usually when I see prototype code (mine included) it's a bunch of divs with tons of classes lol [15:46] is Ben going to be in today? [15:50] jujugui call in 10, kanban now. [15:51] sometimes javascript irritates me [15:52] seriously why do I have to do Array.prototype.forEach.call(elements, function() { ...}); when elements is a nodelist [15:52] that's it! We are switching the GUI to.... to... to... [15:52] hmmm [15:52] Flash! [15:55] Fiiiiired. [15:55] rofl [15:55] so that's where they draw the line eh? [15:56] jujugui call in 4 [15:57] kanban now [15:57] oh sorry [15:57] already done :-) [15:57] thanks [15:58] hatch: so why do that over nodelist.each? [15:59] jujugui call now [15:59] ish [16:00] rick_h_: I'm using raw js [16:00] hatch: but elements is a NodeList? or something else then? [16:00] hatch: nvm, I thuoght you were saying you had a Y.NodeList [16:00] confused me [16:01] funny enough they are both called NodeList heh [16:01] so yeah it is confusing [16:08] bcsaller: so I should have asked if you have actually implemented that cleanup stuff yet [16:08] I just didn't want to duplicate work [16:09] hatch: makes sense, I have some of it done, I should be wrapping it up this morning, happy to talk about it after the call [16:09] sure thing [16:49] gary_poster: who would be a good person to do pre-imp call with for "destroy controls to service inspector" [16:50] benji, jeff or ben for tech. me for goals, but on call for another 10 min. [16:50] gary_poster: cool; let me know when you have a minute [16:50] will do [16:52] gary_poster: http://jsbin.com/evehit/1/ - (prototype) it only works for the top right now but I don't foresee any issues adding the bottom as well - just scroll up and down in the scrolly box [16:55] hatch, cool. heading 2 and 3 hide behind upper headers before they stick for me, and heading 4 pushes 1 2 3 and off. first fixable, second intentional? [16:57] both fixable [16:57] and both unintentional :) [16:58] :-) [16:58] http://jsbin.com/evehit/2/ [16:58] that should fix the second [16:58] the first will take a little bit more js [16:58] but regardless - I just wanted to confirm this was the functionality you were looking for [16:59] hatch, cool, yeah that's the right direction. can we also not obscure the scrollbar? [16:59] I'm going to go with.....probably [16:59] :) [17:00] :-) seems important [17:00] agreed [17:00] heh ok I'll keep adding the remaining features and fixing the known bugs [17:00] will report back with a fully functional proto [17:24] writing raw js is hard [17:24] I keep writing YUI methods by habit [17:24] setStyle() [17:24] heh [17:27] * benji lunches. [17:43] abentley, are you deloying/testing mongodb changes to staging? [17:44] * sinzui sees a mongodb database relation error [17:48] sinzui: No, I'm not doing anything with staging at the moment. Got failing tests on slow-migrations-2. [17:48] abentley, okay. I will kick staging [17:57] benji, whe you are ready for call I am [17:57] n [17:58] sinzui any word from IS on the GUI deployment? [17:58] gary_poster, They are one person today and it is unlikely to happen [17:59] I reminded then that we want to do regular deployments over the next two weeks culminating with a DNS change for OSCON [18:00] I will press this issue again tomorrow morning [18:00] sinzui, ack. Could you keep me in the emails for that? also, what's the plan for comingsoon.jujucharms.com--those are part of the planned DNS change? [18:01] I expect them to do that with this deploy or inform me that they want to treat it separately [18:01] gary_poster, There is no documentation about how to deploy the gui to prodstack. I think this contributes to the delay. [18:02] sinzui, DNS change: cool [18:02] I get better service when I can point webops to the OSA doc about the standard practice [18:04] sinzui, docs: dunno. we got great service from wedgwood before. Would it be helpful to try and dig up emails from stuff we did at the time? Alternatively or in addition, can you draft these docs for the GUI charm, or ask us to do so? [18:05] wedwood isn't a webops now. Its a new squad. Old emails or the original rt would be grand, Rt would be best since they love rt [18:05] ok lemme see what I can find [18:06] * sinzui ponders writing the OSA draft as a subtle prod. [18:12] gary_poster: guichat is open [18:15] benji https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1dEFVSWh3TWtQOUk [19:20] orangesquad: anyone have time to review https://code.launchpad.net/~sinzui/charmworld/sane-categories/+merge/173570 [19:20] sinzui: sure. [19:26] sinzui: Code looks good. I don't understand why handling it in "proof" would harm backward compatibility. Even if it's not an error, it could be a warning. [19:27] abentley, I could be [19:27] sinzui: Either way, if the API wants to guarantee that only official categories pass, it must enforce sanity, because the mongodb document isn't guaranteed to be sane. [19:28] abentley, I took the list from the very warning that proof uses [19:28] sinzui: Oh. Then I don't understand the comment. [19:28] We didn't have final sign-off on categories when proof was changed [19:33] sinzui: Perhaps you should update the API doc to indicate that specific categories are enforced. [19:34] sinzui: When you test categories, I think you should test API 2 as well. [19:34] abentley, okay [19:35] sinzui: In fact, I wouldn't expect the old API to be affected by the change. [19:36] We never promised that the categories property would be verbatim or contain rubbish [19:36] sinzui: No, I don't see how your changes could cause the old API to be affected. [19:36] abentley, the charm's YAML can contain categories: "misc" but we always represent that as a categories: ["misc"] [19:37] I see my change as a true bug fix rather than a change in contract [19:37] sinzui: I'm not saying your change is wrong, I'm saying I don't think it will have any impact on the old API, because the old API doesn't use the Charm model object. [19:41] ah, okay [19:53] orangesquad: Could you please review https://code.launchpad.net/~abentley/charms/precise/charmworld/slow-migrations/+merge/173580 ? [19:54] * sinzui looks [19:54] sinzui: btw, tarmac is down and matsubara is looking into it. [19:55] abentley, that's fine. I will be doing qa without apache it seems anyway [19:55] abentley, Do we dare destroy our apache instance? I have given up trying to access it from the nova level [19:56] sinzui: I think we dare destroy it. We will retain control of the external IP address. [19:58] abentley, I had to file an RT to get the VM checked. Larry is on holiday today and he usually takes care of that for me [20:00] matsubara: Ack. [20:05] sinzui: I will do a manual merge of the charmworld branches, since Tarmac will not be ready for a while. [20:07] abentley, ack [20:16] sinzui: Any thoughts on https://code.launchpad.net/~abentley/charms/precise/charmworld/slow-migrations/+merge/17358 ? [20:16] sinzui: nm [20:17] sinzui, will you have a chance for a 15 min call in the next 45 minutes or so? [20:18] I can talk now if you like [20:20] cool sinzui thanks. guichat is free [20:44] arg this header thing is so frustrating [20:57] hatch, if it takes too much time we can (A) toss it to ant and see what he can give us and/or (B) push back on UX and request a cheaper initial approach [20:57] I wish I liked the look of the scroll bar more in the FF demo :-/ [21:52] bcsaller: will review [21:52] hatch: thanks, I expect there will be some questions, if you want to talk about anything lemme know [22:04] bcsaller: O KAY [22:04] I almost have this rediculous scrolling behavior cased [22:04] lol [22:04] * hatch actually thinks it's pretty cool [22:04] http://jsbin.com/evehit/4/ [22:05] header 3 and 4 'trigger' at the wrong spot however [22:08] hatch, cool :-) [22:09] yeah 1 and 2 work really well [22:10] for some reason the height calculation is off on 3 and 4 [22:15] bzr sure put some odd diff splits in here heh [22:18] bcsaller: I see you moved the databinding into the view container - I remember we explicitly did not want to do that [22:19] are you saying now that, for all intensive purposes, required of one another? [22:19] vc state is needed to trigger some operations at the right time. We don't currently have any use-case for viewlets w/o databinding either [22:20] alright that's fine - I just wanted to make sure that decision was intentional [22:21] that databinding is one complex beast :) [22:22] its getting more complex, yes :( [22:47] bcsaller: review done - mostly trivial but a few larger requests [22:47] hatch: thanks, reading now [23:03] header calculations solved [23:03] bcsaller: it's my EOD so I'm stepping out for a bit but I should be back in about 15-20 if you have any q's or would like to chat about my comments [23:04] hatch: I should have the reply + changes done in that timeframe [23:04] Morning [23:37] bcsaller: the reply looks good - I'm going to go through it again then QA after supper then I"ll LGTM it [23:37] hatch: cool, thanks [23:37] afterwards I'll merge it into my branch so that I can start on that in the AM [23:38] I could also LGTM it now if you think you can get another review tonight :) [23:39] I don't think anyone that can do it is still around [23:39] alright np :) after supper it is [23:39] talk to you in the am