| danilos | hum, on launchpad.dev/firefox "Subscribe to bug mail" doesn't turn to "Edit bug subscription" anymore, but I guess that's a design decision (so you can add more subscriptions) | 12:10 |
|---|---|---|
| gary_poster | hey benji, danilos. We have two important things that need to happen that are on my plate, and I'd like to reduce that number by 1. :-) one is to respond to gmb's review to get the client side branch landed, and the other is to work more on the sql that may have contributed to the mail incident yesterday. | 12:30 |
| gary_poster | I am going to focus first on the sql for the mail incident, because I want to get that squashed, and the fix I did yesterday may have helped but was not enough. When one of you is ready to take something else, we should rearrange. | 12:31 |
| danilos | gary_poster, ack | 12:31 |
| gary_poster | thanks | 12:31 |
| benji | gary_poster: well, I can't think of anything reasonable to do for the email bug I was working on so I should either start doing unreasonable things or put it on the back burner | 12:32 |
| gary_poster | benji, I vote for back burner :-) Please indicate on the bug what you've tried and looked at so far; maybe also ask for a way to dupe; and then mark as incomplete. Then check back, and we'll coordinate | 12:34 |
| danilos | gary_poster, btw, what should we do for the server side of the BSF.description XSS thing? throw an exception (if so, which one?) or silently ignore disallowed characters? | 12:34 |
| benji | k | 12:34 |
| danilos | ValueError seems like a good candidate, but not sure how well it works with our API | 12:34 |
| gary_poster | danilos, was going to say ValueError also. Benji, I foget how the exception import thing works. Do you have a recommendation? | 12:35 |
| gary_poster | sorry, lower-case, "benji" :-) | 12:35 |
| benji | yep, ValueError will work fine, you just need to wrap it in a call to expose() | 12:36 |
| gary_poster | danilos ^^ cool? | 12:37 |
| benji | danilos: from lazr.restful.error import expose | 12:39 |
| danilos | gary_poster, benji, thanks, I'll look it up | 12:39 |
| gary_poster | cool | 12:39 |
| benji | gary_poster: I assume https://code.launchpad.net/~gary/launchpad/accordion-client-1/+merge/54715 is the right MP. If so I'll start now. | 12:45 |
| gary_poster | benji, that's the one | 12:48 |
| gary_poster | I guess I'll have to merge your work in | 12:48 |
| gary_poster | so that it is a ssociated to the right MP | 12:48 |
| benji | k | 12:49 |
| === gary-lunch is now known as gary_poster | ||
| gary_poster | benji did you get my message? My internet connection had a hiccup when what sounded like a neighborhood transformer blew | 12:54 |
| gary_poster | That, or someone took a shotgun to some power equipment | 12:55 |
| gary_poster | It was "I guess I'll have to merge your work in"..."so that it is a ssociated to the right MP" | 12:55 |
| danilos | gary_poster, fwiw, benji said "k" to that earlier :) | 12:56 |
| gary_poster | heh, ok thanks danilos :-) | 12:57 |
| danilos | gary_poster, also, since we are getting stuff reviewed should we propose additional branches for merge using regular process using accordionoverlay as a dependency, or perhaps propose for merging into accordionoverlay? (so we can get independent reviews) | 12:58 |
| benji | gary_poster: yep I got it | 13:00 |
| gary_poster | danilos, yes, I was thinking about that too, earlier. bac, benji, danilos, I propose that all future client-side work go to devel, and not out integration branch (despite the fact that I labeled this branch for MP review as a -1) and that we go through the normal review process. | 13:00 |
| gary_poster | The only possible exception would be the link branch bac is working on and that I touched on, as bac prefers. Agreed? | 13:00 |
| gary_poster | thanks benji | 13:00 |
| bac | ok | 13:00 |
| gary_poster | cool | 13:01 |
| danilos | gary_poster, sounds good | 13:01 |
| gary_poster | cool | 13:01 |
| benji | +1 | 13:01 |
| gary_poster | great. thanks all | 13:01 |
| gary_poster | benji I moved your bug card to Cancelled. If we get an actionable reply fro Robert we can schedule that separately | 13:02 |
| danilos | gary_poster, also, just to make sure it's not forgotten, the fact that link "Subscribe to bug mail" on launchpad.dev/firefox doesn't turn into "Edit bug subscription" anymore is a design decision, right? (and we'll be solving editing existing ones differently) | 13:02 |
| benji | k | 13:03 |
| gary_poster | danilos, yes, there are two cards for this in FW 1 (I just tweaked the wording of one of them): "Link bug target subscription edit page from target's main page and bug pillar main page." and "Structural subscription edit/delete page should also allow adds". | 13:06 |
| gary_poster | Then also I just added one in the backlog for work on turning off the subscriber list: "Make sure users can easily see summarized information about *their* subscriptions on bug page and bug target page." | 13:06 |
| danilos | gary_poster, ok, just wanted to make sure it's there since I just noticed it :) | 13:07 |
| danilos | ok, I'm back to preparing an MP for my branch dealing with two cards | 13:08 |
| gary_poster | danilos, yes, thank you, your question made me clarify some things on the board, and that needed to be done, so cool. | 13:08 |
| gary_poster | danilos, I was wrong. Your filter code did make it to production, though I'm not sure how since it was not part of the diff merged to the tree from devel. I must have missed a second merge. So that, I assume, is the source of 1/2 of the large amount of SQL that Ian found last night: https://bugs.launchpad.net/launchpad/+bug/742230 . | 13:18 |
| _mup_ | Bug #742230: Too much repeated SQL in send-bug-notifications job <Launchpad itself:Triaged by gary> < https://launchpad.net/bugs/742230 > | 13:18 |
| gary_poster | Could I have a call with you to talk over approaches? I think I understand what is going on, and I *don't* think I see how to make it dramatically better--just combining those two sql bits for each person (which might be a bit nasty code wise). | 13:18 |
| gary_poster | oh, mup, *now* you want to say hi. I see how it is. | 13:18 |
| danilos | gary_poster, sure thing, let me get mumble going | 13:18 |
| gary_poster | thank you | 13:18 |
| benji | .set("text", desc); | 13:57 |
| * danilos -> food | 14:21 | |
| bac | gary_poster: i forgot to mention i am OCR today, though i have mostly ignored it | 15:59 |
| gary_poster | bac :-) ok | 15:59 |
| benji | gary_poster: would you have expected the Windmill tests to pass on lp:~gary/launchpad/accordion-client-1? | 17:43 |
| gary_poster | benji, I would have had no idea. :-/ | 17:43 |
| benji | I'll give you one guess. ;) | 17:44 |
| gary_poster | benji, I felt I was kind of the messenger on that branch, if you know what I mean | 17:44 |
| gary_poster | heh, got it | 17:44 |
| benji | yep, just wanted to make sure that they weren't passing for you and failing for me | 17:44 |
| gary_poster | no, never even ran them I'm afraid. :-/ | 17:44 |
| benji | on the other hand, if I get them to pass again then I'll have a 500 line diff of lint fixes | 17:45 |
| gary_poster | woo hoo! | 17:45 |
| === Ursinha is now known as Ursinha-lunch | ||
| bac | hi gary_poster | 19:52 |
| gary_poster | hey bac | 19:52 |
| bac | working with curtis we think we've tracked down the problem | 19:52 |
| gary_poster | fantastic! I hope? | 19:52 |
| bac | though i'm not fully understanding it | 19:52 |
| gary_poster | assuming the problem is not something like "we use Python" | 19:52 |
| bac | take the works 'layers', 'getMultiAdapter', 'monkeypatch', 'directlyProvides' and mix them until frothy | 19:53 |
| bac | so... | 19:53 |
| gary_poster | heh | 19:53 |
| bac | at one point in MenuAPI there is a comment "we should get the layer from the request" | 19:54 |
| bac | i think that is the crux of the problem | 19:54 |
| gary_poster | ah | 19:54 |
| bac | we set the layer using directlyProvides | 19:54 |
| bac | but i'm unclear wth that is doing and how to interrogate the request to get it back | 19:54 |
| gary_poster | ok | 19:54 |
| bac | thoughts? | 19:54 |
| gary_poster | directlyProvides manipulates a private bucket of interfaces off of an object, IIRC | 19:55 |
| gary_poster | layer interfaces are generally supposed to provide an interface themselves | 19:55 |
| gary_poster | which is slightly mindblowing | 19:55 |
| gary_poster | but can help when you are trying to interrogate | 19:55 |
| gary_poster | let me see if I can find an example, because I don't remember precisely how to take advantage of that | 19:56 |
| bac | ok | 19:56 |
| * gary_poster wishes that the word layer were not so common | 19:58 | |
| * gary_poster finds ./zope.publisher-3.12.0-py2.6.egg/zope/publisher/skinnable.py and ./zope.publisher-3.12.0-py2.6.egg/zope/publisher/skinnable.txt in the grep list...feel free to follow along, or not... | 20:00 | |
| * gary_poster has headache | 20:03 | |
| gary_poster | ok bac. what interface are you directly applying? | 20:06 |
| bac | app layers like BugsLayer, etc | 20:07 |
| gary_poster | k | 20:07 |
| gary_poster | 1 sec, seeing if this works | 20:07 |
| bac | a la from lp.bugs.publisher import BugsLayer | 20:08 |
| gary_poster | yeah, found it thanks | 20:09 |
| gary_poster | nope, we don't do the expected thing. However that would have only slightly improved things. | 20:13 |
| gary_poster | So bac, the way you do it is you iterate over the interfaces that might be a layer and ask if the request implements it. Yup, dumb. The improvement that vanilla Zope provides is that you can make a call to get all the layers ("getSiteManager().getUtilitiesFor(IBrowserSkinType)") and iterate those. We don't play that game. | 20:15 |
| gary_poster | So... | 20:15 |
| gary_poster | there's also the question of whether you are removing the previous layer interface | 20:16 |
| gary_poster | I dunno if you are | 20:16 |
| gary_poster | May I see the menu code in question, bac? | 20:16 |
| bac | lib/lp/app/browser/tales.py | 20:17 |
| bac | gary_poster: look for "We should be retrieving" | 20:17 |
| gary_poster | got it thanks | 20:17 |
| gary_poster | bac, so the Zope solution for this is the following: | 20:18 |
| gary_poster | you register all layer interfaces as utilities providing IBrowserSkinType, with the facet names | 20:18 |
| gary_poster | as the utility name | 20:19 |
| gary_poster | then you get the registered interfaces and their names from the CA (using getSiteManager(). getUtilitiesFor(IBrowserSkinType)) | 20:20 |
| gary_poster | and iterate over them until you get an interface that the request provides | 20:20 |
| gary_poster | that's the one (as long as old layers have been removed) | 20:20 |
| bac | wow | 20:20 |
| gary_poster | and you have the name and the interface | 20:20 |
| gary_poster | heh, I suspect that's not a good wow | 20:21 |
| bac | i was hoping for request.layer | 20:21 |
| gary_poster | the zope approach had that automated | 20:21 |
| gary_poster | nope | 20:21 |
| bac | curtis also suggested to ditch the views-based testing i'm doing and use a test browser | 20:22 |
| bac | i think i may investigate that | 20:22 |
| bac | since it will allow our publisher's monkeypatching to be used | 20:22 |
| gary_poster | it's an idea | 20:22 |
| gary_poster | alternatively you could implement our own version of setting a layer on the request | 20:23 |
| gary_poster | that stashes layers | 20:23 |
| gary_poster | and gives them back and does the right thing and so on | 20:24 |
| gary_poster | but that's probably not what you want to do | 20:24 |
| === Ursinha-lunch is now known as Ursinha | ||
| gary_poster | I'm out. I'll be working a bit this weekend because I didn't get my self-eval done, so I'll probably look at email if anyone needs anything. Have a great weekend | 21:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!