=== Ursinha is now known as Ursinha-afk [09:09] gmb, hi, do you happen to know if we are using ~yellow/lp/accordionoverlay branch for both feature work 1 and 2, or should I branch off something else for 2? [09:09] (i.e. devel :) [09:29] danilos: I can't wholly certain, but I *think* that that's the canonical branch to work from. [09:30] gmb, k, thanks [09:30] danilos: It was last touched ~2 hours ago by Brad, which seems like a good sign. [09:31] gmb, heh, not for Brad though :) [09:31] :) [09:58] gmb, do you happen to have any idea how to best test error handling in JS? [09:59] danilos: Not really. You could maybe force an error and then check that the right error message is displayed, but I don't know how error handling is set up for the accordion overlay, so I can't be of much help there. [09:59] gmb, well, it's not set up at all yet, but I generally want to test it works properly with things like XHR failures [10:00] gmb, (and I am trying to implement it, but I want to do TDD :) [10:01] danilos: Best of luck :). But yeah, if you're checking that the overlay handles the error correctly then what you're basically checking is that it displays something sane to the user. So using the mock IO features to trigger the error and then checking the contents of the overlay should work reasonably well. [10:02] gmb, thanks for the suggestion, it sounds good, got any example of using mock IO features to that purpose? :) [10:03] danilos: Let me see if I can find one in the tree. I remember writing something, but that may have been deleted. Gimme a sec. [10:03] gmb, cheers [10:06] * gmb digs out an old branch [10:09] danilos: So, this is a (now removed) test of the (now removed) bug subscription widget. http://pastebin.ubuntu.com/583265. See the use of Y.lazr.testing.MockIo.makeXhrSuccessResponse() (I assume there's a corresponding makeXhrFailureResponse()) and simulateXhr() functions. [10:10] gmb, great stuff, thanks a bunch! [10:11] np [10:12] gmb, btw, you probably have found this out already, other than shutting down LP before getting the JS executed, any other suggestions for simulating this on a running instance? [10:13] danilos: Well, you could probably use MockIO in your code (though that seems a bit nasty). Usually I just kill LP though, like you say. [10:13] danilos: deryck might have a better answer for you. [10:13] gmb, k [12:31] hey gmb. mute button has no more bugs? If so, (1) yay! (2) I'll move it along to track the last bug (737648) and close the lane [12:32] gary_poster: Yep. Final branch is landing now. [12:32] awesome, congrats [12:34] :) [12:46] hi gary_poster -- i'm going to work now on putting the subscribe link on the bugs page [12:47] bac, great. [12:48] danilo, +1 on X-Launchpad-Subscription [12:49] sorry, danilos ^^^ [12:49] help text: will get you file name... [12:49] gary_poster, cool, it's reviewed already, and the ec2 test is almost complete :) [12:49] gary_poster, excellent, I tried grepping but nothing turned up in the entire tree [12:50] danilos, lib/lp/registry/help/structural-subscription-name.html in the ~yellow accordionoverlay branch [12:50] gary_poster, aaah :) [12:50] danilos, reviewed/ec2 test: awesome :-) [12:51] gary_poster, I did this thing against "devel" branch, that's not a problem? [12:51] gary_poster, I can land it on both, or just on accordionoverlay if you think that's better [12:51] danilos, no. We should just merge devel once what you have done has landed [12:51] gary_poster, ack [12:51] "no" as in no problem to be clear :-) [12:51] yeah [12:54] gary_poster, btw, should I update the LEP as well? (just to avoid confusion) [12:54] danilos +1 thank you === Ursinha-afk is now known as Ursinha [13:02] danilos, did you ever file a bug for the make jsbuild problem? I don't even remember what it was any more :-P [13:03] gary_poster, heh, I didn't, I haven't been able to reproduce it lately, but I want to try another thing (create a new .js file and see if that one gets included in the generated launchpad.js) before I consider it 'resolved/obsolete' [13:04] ack danilos. I'll leave it as an action until you do. [13:04] gary_poster, the problem was that I had to run "make" for some changes since 'make jsbuild' wouldn't pick them up [13:04] ah ok [13:04] gary_poster, it's likely not to be a problem, but I'll try to get to checking it out later today [13:04] cool danilos thanks [13:07] gary_poster, re help text, should we add anything about the text in the body of the email? [13:07] danilos, yeah +1 thanks [13:20] bac, btw I looked at the Cancel button styling over the weekend. The issue is that some of the LP CSS sets padding to 0 for buttons, but not for input[type="submit"]. Therefore cancel has 0 padding, and submit has browser-native padding (6 3 2 or something like that on Chrome). [13:21] The way to fix is to set padding to both explicitly. There is no "auto" for padding so we can't tell the button to get the same browser-native styling. We could turn off the padding directive in LP, or add input[type="submit"] to the same list as the button directive; or we could set something explicitly just for our form overlay. [13:21] Since I have a complete absence of a feeling of authority over our launchpad CSS, I lean towards the last approach. [13:21] But anyway, that's the story. Maybe you knew it already. [13:21] gary_poster: interesting. i did not know as i only noted the problem but hadn't investigated [13:21] cool [13:26] bac, I tried to think about the tag validation problem this weekend too. I'm inclined to figure out a good solution for our overlay first, and contemplate refactoring it for the general tag packer later, maybe on bug rotation if it is marjed as critical (ha ha?). I'd rather not pay for the time right now. [13:26] But as to options for our overlay, I came up with showing an error indicator; normalizing after the field loses focus and telling the user what you did (my preference ATM); and disallowing characters as they type. I suspect there are many other options too. [13:26] Would you like to be my pre-imp for this, or should I approach someone else (Graham being an obvious option)? [13:27] gary_poster: i'd like to talk about it [13:27] cool [13:27] maybe after the call [13:27] though feel free to write on IRC any thoughts now [13:28] bac benji danilos gmb, kanban/mumble in 2 [13:28] Yup [13:30] danilos yoo hoo [13:43] benji, irc or mumble? [13:43] gary_poster: mumble would be good; you can either wait for me to review what I was doing or we can do it real time, performance art style [13:44] :-) k 1 sec [13:45] benji, which would you prefer? I can run do someting else for a sec if you like, or I can talk now. [13:46] gary_poster: I'm up to date now, lets go. [13:46] k [14:01] gary_poster, bac: Is there any reason not to style the submit and cancel buttons as they're styled on all the other FormOverlays? (i.e. Green tick for OK, Red cross for cancel)? [14:04] * benji reboots. [14:06] gmb: sounds good tome [14:06] to me [14:07] Cool. [14:13] gmb +1 fwiw [14:13] RIghto. [14:16] gary_poster, bac: How should I go about getting this into the ~yellow/accordionoverlay branch? Should I just push it up there? [14:17] that's what i've done but it seems now we need to be more coordinated. how do we handle splitting off the 'server' changes? [14:22] bac: I don't know the answer to that, TBH. [14:22] I'll merge and push for now. It's a smallish change. [14:34] bac, gmb: don't worry about the server changes. I'll split those out when I get to it. If I discover that coordination would help then, I'll mention it then. For landing, actually having a local checkout to which we merge would probably make the most sense, but as long as you don't --overwrite, I don't think it's a huge deal. [14:34] I've been doing something similar but a bit different. [14:46] gary_poster: Does the card go in the review lane or somehwere else? [14:47] (How I love using two different apps to track development) [14:47] gmb, review, but let me clean outthe ones we talked about today one sec [14:48] eh, sorry, I was just afraid you didn't have enough room, gmb. You can put it in review now [14:48] Cool [14:48] * gmb does some more Kanban gardening. [15:17] gmb, bac, danilo, 9 JS tests in ~yellow accordionoverlay branch fail. I get several alerts that say '"Subscribe to bug mail" link not found'. [15:17] If that doesn't ring a bell for anyone I'm happy to dig in [15:17] but I want to check first [15:17] gary_poster: i'll look. sounds like my handiwork [15:17] thanks bac [15:18] bac, please lemme know when it is resolved, or if you want me to take over. I have something to land that is waiting. [15:18] gary_poster: are the failures all in test_structuralsubscription.html? [15:18] yes bac [15:18] * gary_poster didn't notice the other one [15:18] or, barely did [15:19] gary_poster: That might be to do with my update just now. [15:19] Let me check. [15:19] oh ok [15:20] Oh. [15:20] Hmm. [15:20] No, I don't think it is. [15:20] * gmb digs some more [15:21] bac, benji, gmb, danilos, I'm going to start figuring out a server side branch from ~yellow...accordionoverlay, so please let me know from here on out if you have a server-side bugfix (or otherwise important change) going in to that branch. [15:22] ok [15:22] Right [15:26] gary_poster: So, that alert is because there's no link in hte test HTML page for the setup code to bind events to. Easy to fix. It doesn't acutally make all the tests pass though. [15:26] gmb, ok, one step at a time, I guess [15:26] gary_poster: Right. Anyway, I've fixed the initial problem and pushed it. Do you want me ot take a look at the test failures themselves too? [15:27] bac said he was looking at those, so let's check with him. bac? [15:28] gary_poster, gmb: when i changed the code to generate a hidden menuu link (rather than just looking for the global actions portlet) i failed to update the tests [15:28] so i just need to create the expected element in the fake test html page [15:28] bac: I fixed the tests by just bunging a link into the page HTML. [15:28] I've pushed that, FWIW. [15:28] oh, ok [15:28] you added a menu-link-subscribe_to_bug_mail? [15:28] on another topic, here's my plan for the server side branch. Please object/counsel sanity if necessary. [15:29] I'm going to branch devel, then bzr merge accordionoverlay, then bzr revert --forget-merges, then take out the changes that are not pertinent to the server side, and then commit. Then I'll merge the new branch into accordionoverlay, and resolve any conflicts. IME bzr is usually pretty good at handling identical changes. [15:29] At that point we should be in pretty good shape for merging accordionoverlay itself as the clientside branch [15:29] gmb: ^^ ? [15:29] (sorry for mixing topics :-/ ) [15:29] bac: Yes. [15:29] gmb: what other test failures are you referring to? [15:30] gary_poster: I'm going to just nod vacantly at this point about your plan. It sounds fine - I didn't know about --forget-merges - and I trust bzr to DTRT 9 times out of 10. [15:30] we should probably throw an error when the link isn't found rather than an alert [15:30] gmb :-) ok [15:30] bac: Yes, I think so. [15:31] bac: Let me paste the test log for you. [15:31] gmb: thanks [15:32] bac: Anything that is using simulateMouseEvent(), it seems. I'm guessing it's trying to do things to elements that don't exist in the test html. [15:43] diff in our branch in test_milestone_table.js: [15:43] + filter: 'raw', combine: false, fetchCSS: true // Do not check in [15:43] :-P [15:43] I'll fix later if no one else does (in the middle of something else) [15:46] benji, I can't decide whether to include expose_user_administered_teams_to_js, expose_enum_to_js, expose_user_subscription_status_to_js, and any other similar friends from lp.bugs.browser.structuralsubscription in the server-side branch. [15:46] I'm inclined to include them, because right now the server-side changes are <1200 lines and the client-side changes are >1800 lines, so favoring the server-side doesn't sound too bad. Any thoughts? [15:47] if it doesn't make the branch too large, I would be include them [15:48] gmb: i fixed the tests and am about to push. ok with you? [15:48] hmm, 1200 is a bit big, but I guess Graham asked for it ;) [15:48] gary_poster: i'll fix the test_milestone [15:48] heh [15:49] benji, cool, thanks. Well, my point was that 1200 < 1800 :-) [15:49] gmb: you ok with me pushing those fixes? [15:57] bac: Sure. [15:57] done [15:57] Sorry, was OTP. [15:57] np, just didn't want to duplicate effort [15:58] Right. === Ursinha is now known as Ursinha-lunch [16:23] gary_poster: which card would you like for me to work on between reviews? "Hook up filter-display subpage into a page for bug targets." is non-low priority. [16:38] * gmb -> afk for a short while [16:53] benji sorry was otp [16:54] * gary_poster looks [16:54] np [16:55] benji that's a good one. Let me do a pre-imp with you, because it touches on notes from conversation with Jono [16:57] benji, do you want to talk now? If not, I might get some lunch 'cause I am hungry [16:57] gary_poster: I could use some lunch too; we'll do it afterward [16:58] cool benji === Ursinha-lunch is now known as Ursinha [17:14] * gmb returns [17:14] * gmb returns [17:32] bac, gary_poster: Is there any tasks you'd particularly like me to pick up? [17:32] * gmb winces at "Is" before a plural form, commits ritual suicide. [17:33] gmb: i'm in the middle of trying to figure out where to put the link on the bugtarget page. if you want to pick up the feature-flagging you could do that. [17:34] bac: Won't those two collide? [17:34] bac: Oh, sorry [17:35] You're working on the BugTarget:+index page. I'm thinking about the Pillar+index page. [17:35] bac: Sure, I'll take that on. [17:35] ok [17:35] I assume we want a separate feature flag from malone.advanced-subscriptions.enabled, since this work isn't ready to go live yet and most of that is. [17:36] bac, gary_poster ^^ [17:37] gmb: i'd assume so, though tied to that team [17:37] Right. [17:37] if that makes sense [17:37] Yep. [17:37] I agree. [17:37] * gmb goes, does [17:54] ok gary, ready when you are [17:59] benji, ok. Actually, on reflection over lunch, I think that one should wait on bac finishing what he is working on. So...what should you do. [18:00] * benji looks. [18:00] (the reason why it should wait is that AFAIK you will want to follow the pattern he has started [18:00] ) [18:00] gmb, sounds reasonable. [18:01] gary_poster: how about "If an error occurs while patching a newly created filter, remove the filter." [18:01] benji +1 [18:01] k [18:01] gary_poster: what task are you talking about waiting for me [18:01] ? [18:01] I have some notes from the call with jml. I'm kind of in the mood to get some coding done, so I'll wait to get that out, but will make myself do it soon. :-P [18:02] bac, benji was going to look at adding edit links (e.g. links to https://bugs.launchpad.dev/firefox/+subscriptions) whereever you are adding add links [18:03] gary_poster: ah, ok [18:09] pushed to ~yellow [18:24] merged devel, merged my initial server bits, pushed to ~yellow again [18:29] benji, is there a reason why BugSubscriptionListView initializes the request in __init__ rather than initialize? I think "initialize" is more typically where we put view initialization. If this was any kind of considered choice, even in a very small way, I'll leave it as is and see what the reviewer says. If it was not a considered choice, I'll switch it to initialize. [18:30] gary_poster: nope, no good reason at all; I am only vaugly aware of initialize and it didn't cross my mind at the time [18:30] cool thanks benji. [18:31] what is the gestalt of initialize? [18:31] it is formlib initialize/render (literally--we use formlib) [18:32] benji, make sense, or would you like more detail? [18:32] yeah, makes sense [18:33] cool [18:47] hi gary_poster, question on scope. [18:47] bac, hi [18:48] are we enabling structural subscriptions on any bug target? i.e. product, project group, distro, etc? [18:48] thus far we've concentrated on product only [18:48] bac, yes [18:48] ok, that actually makes some things easier [18:48] they are already enabled for all of those [18:48] good [18:48] (I mean, structural subscriptions are, not our work) [18:49] but means more page templates will need tweaking [18:49] ok [18:49] but the existing links to +subscribe will be removed, right? [18:49] such as seen on bugs.lp.dev/firefox [18:51] * gary_poster looks [18:51] bac, yes [18:51] excellent [19:09] benji, expose_user_administered_teams_to_js has an argument absoluteURL=absoluteURL. Nothing uses it. Should I remove it? [19:09] remove it and then run the tests, you will be enlightened [19:10] benji, ah! where are the tests? I was going to try and write tests for those expose_* things and was staring glumly at the prospect. [19:10] gary_poster: oh wait, you mean the function body doesn't use absoluteURL, yeah, sure remove it [19:10] oh ok [19:10] no [19:10] function body does [19:10] yeah, they should be tested [19:11] ok. [19:11] I'm confused now though [19:11] heh [19:11] could you take a glance at browserstructuralsubscription.py line 373 ff? [19:11] sure [19:11] thank you [19:12] it is used in the body [19:12] but grepping for that function shows that nothing in the tree uses the pluggability it implies [19:12] I doubted you were using it for Jim's old speed hack [19:13] gary_poster: heh, no; the tests are in lib/lp/registry/browser/tests/test_expose.py [19:13] yay! [19:13] looking [19:14] benji, is that not checked in, maybe? [19:14] let me double-check [19:15] oh, no there it is [19:15] somehow I missed it in my server branch. sorry for the noise. Why are the tests in registry but the code in bugs? [19:16] benji ^^ [19:17] gary_poster: so did you talk with jml? [19:17] gary_poster: I have no idea why it's where it is... oh wait, didn't the code move at one point? I may have started when the code was in one place but failed to move the tests when the code moved. [19:17] benji, ack. will move it. thanks [19:19] bac, yes. big picture: please with what we have done. A few small tweaks here and there. I intend to write it up fully, when I get the energy. here are some medium-level picture bullet points from jml: [19:19] * I've filed bug 739515 about the pixel shifting. [19:19] * Huw should look at the accordion dialog & make it pretty [19:19] <_mup_> Bug #739515: Portlet contents shift down while loading bug subscription form < https://launchpad.net/bugs/739515 > [19:19] * Gary will ask gmb about whether we can push the + / - thing on [19:19] muting bug mail down further [19:19] * Gary will ping Diogo & I when accordion work is deployed, at which [19:19] point we'll decide to do another meeting [19:19] * Unsubscribe in anger should handle the case where I'm getting bug [19:19] mail for a project because of team membership, allowing me to not get [19:19] bug mail that project [19:19] "I" is jml in that list) [19:20] gary_poster: cool. didn't mean to force a brain dump but was curious if you met [19:20] Then there are some little picture things like making sure that selct all and select none are the right colors ("Huw should look at the accordion dialog & make it pretty" is the subsuming poiint) [19:20] bac, np. That was some copy-pastable bits [19:21] i'm +1 with huw making a prettifying pass [19:21] absolutely [19:36] gary_poster: an IDistributionSourcePackage is an IBugTarget -- but it doesn't look like you can have a structural subscription to it, e.g. https://bugs.launchpad.net/ubuntu/maverick/+source/mandvd [19:37] duh, i should be looking at IStructuralSubscriptionTarget-s instead [19:37] nm [19:37] bac, you can't because of code? [19:37] ah yes, cool [19:37] * gary_poster needs to pick up kids from school. back soon [20:07] pushed another branch to ~yellow [20:07] another revision I mean === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [21:00] hi gary_poster, i'm making progress but the task has grown in scope. unfortunately there is not much uniformity across all of the IStructuralSubscriptionTarget views and templates. i think i'm working on the final set. [21:00] ack bac [21:01] sounds good [21:01] and i'm calling it a day, for now. spent the weekend installing wood floors and i'm beat [21:01] Yeah, I was going to say I was quitting too [21:01] I'm tired too [21:01] Talk to you later [21:01] have a good evening