[11:02] danilos: Can I just check something about the team subscription opt-out story that I'm working on (I'm assuming you'll be able to answer this question based on my vague memory of what Gary said yesterday; if you can't, no worries) [11:02] danilos: Is the opt-out supposed to be for team *structural* subscriptions or for direct team subscriptions or both? [11:51] E_BRAIN_NOT_FIRING. Lunch [12:08] gmb, I think this was mostly about structural subscriptions [12:17] gmb, but, you are making a good point about direct team subscriptions [12:47] danilos: Damn, I was hoping you'd say "no, we don't care about direct subscriptions." [12:47] But thanks anyway :) [12:47] gmb, :) [13:09] gary_poster: Just the man! To repeat my question to danilo earlier: Is the opt-out from team subs supposed to be for team *structural* subscriptions or for direct team subscriptions or both? [13:09] gmb, only structural [13:10] HURRAH [13:10] I mean, cool. [13:10] :) [13:10] if it is direct, people can just mute the bug [13:10] :-) [13:10] Right. [13:10] * gmb goes to finish the DB patch. [13:18] gmb...spanner in the works, but thinking about how we are presenting this, either we need to be able to mute *filters* or we need to think about a good UI for muting the entire structural subscriptions [13:19] filters are the natural way to approach this from a UI perspective [13:19] from the DB perspective, that's no biggie... [13:19] gary_poster: Hmm. At the moment I've got a StructuralSubscriptionMute table; it doesn't take much to tie it to the filter rather than the subscription. [13:19] And I agree, filters are what we present to the user as "subscriptions" [13:20] from the perspective of how the muting would work, and efficiency, that's a bit more concerning... [13:20] You mean in terms of things-to-check-for-mutes-when-sending-emails? [13:20] yeah [13:20] Hmm. [13:21] lemme look at the code I'm trying to get reviewed... [13:21] ok [13:22] ok, so here's the good news... [13:22] we already have code that gets the pertinent filters for each person [13:22] and hopefully it is fairly efficient [13:22] with my branch that is to be reviewed [13:23] Ah, cool. [13:23] it will need slight tweaks but no big deal [13:23] So we could adapt that code so that "pertinent" doesn't include "muted"? [13:24] hi gary_poster, my branch didn't get reviewed. do you want to do it or shall i hit up gavin who is OCR? [13:24] well, sort of, yes. It would always start out by giving all of the filters per person; then we would need to look for any mutes [13:24] bac, try gavin first; if he has a backlog, I can get to it within an hour I'd guess [13:25] will do [13:25] thanks [13:25] Okay, cool. [13:25] so gmb, I *think* that we will be adding a single query per person [13:26] gary_poster: Right, okay. First things first, I'll update my DB patch, then I can come back to the code surrounding it. I think that updating your code will come late on in the process, so we've time to thrash out a solution to any performance issues. [13:26] something like "given this person and all of the possible filters that might be involved, [give me the ones that are muted and I'll subtract them and if they are all muted then nevermind OR give me the ones that are not muted] [13:26] " [13:26] cool [13:27] Right. That makes sense. [13:28] bac benji danilos gmb, mumble/kanban in 2 [13:28] yep [13:29] ack [13:44] this https://wiki.canonical.com/2011Calendar shows week of june 27 [13:45] Question for the Committee: [13:45] based on danilos' problem with the renaming of the feature flag i think we should move to defining a symbol and never use the actual string in code [13:45] I have a test failing thusly: [13:45] + ERROR Unhandled exception [13:45] + -> http://localhost:56152/96/oG1i6vRy0DfzXWgDOpRsv7iAq4e.txt (permission denied for relation account [13:45] + ) [13:46] bac, good idea, +1 [13:46] hmm, that might be hard in the template... [13:46] could be request/feature_flag_names/THE_NAME maybe [13:46] but that would take a bit of doing [13:46] not much [13:46] but some [13:47] alternatively we could say that views should expose the constant [13:47] so it could be view/THE_NAME [13:47] that would be a bit lighter weight but also require a bit more coding for every template [13:48] so anyway, about my failing test... [13:48] I've looked for the file that is mentioned [13:48] in . and in tmp [13:48] not there [13:48] I assume that it is about SQL security [13:48] but it would be nice to actually see the traceback [13:49] gary_poster: what is the failing test? [13:50] lp/registry/doc/distribution-mirror.txt line 650 [14:05] gary_poster: we won't be breaking the assurances you made to wgrant about xss if we turn on the feature flag on qastaging, will we? [14:06] bac, I thought about it and I don't see how. qastaging does not use the prod db. Please share your concerns! Thinking about it some more... [14:06] turning on the feature flag for ourselves (~yellow, say) means that we might be able to be evil and hack data from the db [14:07] but there would presumable be much easier ways for us to di that than this XSS thing [14:07] gary_poster: my concerns are ill-formed and i need to re-read the thread. i just recall part of your argument for leaving the code in was that it wasn't turned on [14:07] true. In this context, I would say this: [14:07] gary_poster: well, i had intended to do malone-alpha [14:07] 1) It is not turned on in prod [14:07] but i can request ~yellow instead -- a much better lpan [14:07] plan [14:08] 2) qastaging for ~yellow sounds ok [14:08] ok cool bac [14:11] gary_poster: while i wait on my review to be done i'm going to work on peer reviews. i've got a bunch. [14:11] cool bac [14:12] Hah, Marianna has just emailed the list about Dublin. So now we know. [14:14] gmb, she seems to have forgotten to mention the month :) [14:14] danilos: It's in the subject. [14:14] 27th June. [14:14] (Week beginning) [14:14] gmb, ah, true :) [14:14] But yeah, that threw me for a moment :) [14:25] danilos or someone else, if I change security.cfg that means I have to land on db-devel (not good for this branch) right? [14:28] gary_poster, I don't think you do, but I might be wrong; maybe LOSAs know if security.py is run on "stable" rollouts if stub is not around [14:28] ack danilos, I'll check, thanks [14:29] gary_poster, (also, there's the pqm check which stops landing certain changes on devel, not sure if that includes security.cfg changes) [14:36] ack danilos. I thought that code was actually in the tree somewhere but can't seem to find it [14:36] gmb, mumble? now, or in a few? [14:40] danilos, security.py is in fact run for no-downtime deploys, so good. If I want to just run the security changes such that tests will see them, will running "./database/schema/security.py" do the trick? [14:42] gary_poster, you'll have to do it for all the appropriate databases (i.e. launchpad_ftest_template I think), check "--help" :) [14:42] danilos, ack, I just did it "./database/schema/security.py -d launchpad_ftest_template" and "./database/schema/security.py -d launchpad_ftest_playground" ....we'll see [14:43] gary_poster, good luck :) [14:43] thanks :-) [14:46] worked, yay (both the security.py call, and the fix for at least one of the two failures) [14:46] boo, not the other one, but should be same idea... [14:50] gary_poster: Sorry, dropped offline for a bit... you were talking to my proxy. [14:51] I'm free now if you are. [14:51] :-) ok, 1 min the I'll be ready gmb. thanks [14:56] crap, I'll need Irish visa (or, alternatively, I can land in Belfast and then travel to Dublin by bus/train :) [15:19] gary_poster: no need for me to email about Windmill tests; Ian has a branch to fix them (although I do worry a little about our process: why didn't I know they were broken and how could I have found out (if I'd thought to go looking)) [15:22] gary_poster, I've noticed that in JS setup_bug_subscriptions() wraps everything inside Y.on('domready') and it's further wrapped in Y.on('domready') in all callsites in templates; if I am to remove one, which one would you prefer? :) [15:29] benji: good point and not the first time. :-/ [15:29] benji, I guess I'll bring it up to flacoste unless you want to take the initiative? I think it bears raising [15:30] have at it [15:30] k [15:30] danilos, I thought I vaguely remebered something like that. We can talk about it on call :-) [15:30] (which I'm ready for anytime) [15:31] gary_poster, not sure what's wrong, give me a minute [15:32] I can [15:33] gary_poster, I don't get to see any input from my microphone [15:33] danilos, hm :-( [15:33] so Skype would not work either, I assume [15:33] gary_poster, let me try the test call [15:33] k [15:34] I hope my headset didn't die in the middle of the day [15:34] or just try me, whatever is convenient, danilos [15:34] I just logged on [15:35] gary_poster, nothing in the test call :( [15:35] :-( [15:35] ok... [15:35] maybe the computer mic? [15:35] gary_poster, I am looking if anyone of my friends have it here [15:35] sometimes headset output plus computer mic input is OK [15:35] ok cool [15:36] a desktop here, no mic on it :( [15:36] I'll try a windows technique now, rebooting [15:36] heh [15:42] gary_poster, didn't seem to have helped, I guess I am microphoneless right now :( [15:43] danilos, :-( [15:43] ok [15:44] gary_poster, just tried the headset on my friends computer, microphone is apparently dead [15:44] danilos, as to your question above, I'd prefer we do things similarly, and the .setup function uses domready on the template. I don't really have a preference as to which approach we use [15:44] it would be easier to just use the one on the template [15:45] gary_poster, right, I'll make sure it's consistent across setup/setup_bug_subscriptions [15:45] because then you only change one thing [15:45] but do whichever you want [15:45] gary_poster, ack, was just wondering if you have any preferences [15:45] danilos, I'll make a card for us to have a replacement call tomorrow, assuming you have the mic sorted out by then [15:45] gary_poster, yeah, I'll make sure I do [15:46] gary_poster, sorry about this (I hope the fact that I muted on the headset and never silenced or muted mumble itself didn't kill it, because that would be very weird) [15:46] danilos, preference: naah, make a choice and I'll be happy with it. I have reasons to prefer both approaches. [15:46] gary_poster, heh, ok, thanks for the input [15:46] danilos, np. comuters suck ;-) [15:47] :) [15:51] ok gmb, I actually can start work on the mute thing now. So, let's see: we need code that handles the muting, and we need to expose the table in the webservice, and we need JS changes. I'm probably being crazy, but I think we can get this done pretty quickly. [15:51] The webservice part is the only thing I'm not sure how to do, amusingly enough given my Foundations background. [15:51] So...what should I do? I think one of us should work on the webservice exposure, and one of us should work on the script. I'm interested in the webservice change, but I also have a fair amount of knowledge of the email-sending script, so either would work for me. [15:51] I'd say my default choice would be the email, because I think I know exactly where the bodies are buried for that one. What do you think? [15:52] gary_poster: I'm happy to work on the webservice side of things since it's close to the front of my brain right now. [15:52] ok cool [15:52] I'm just making final tweaks to my DB patch (so that it, yanno, works) [15:52] what's your branch, gmb? [15:52] oh ok [15:52] ping me when it's ready for me to run with it [15:52] SQL doesn't take kindly to missing keywords. [15:52] :-) [15:53] gary_poster: Sure. Should be ready in < 5 mins. [15:53] awesome [16:05] bac, are you able to QA any stuff on qastaging? (I can see the flag should be on for malone-alpha but the links don't turn green) [16:06] danilos: you see a similar but different feature flag. ours is not yet turned on. [16:06] tom said he'd do it but was very busy ATM [16:06] apparently some ISD issues are on fire [16:06] bac, ah, ok [16:08] ZCML, I hate you. [16:10] gary_poster: Branch is up here: lp:~gmb/launchpad/team-subscription-opt-out. It contains the DB patch and model / interface definitions. [16:11] awesome gmb, thanks. I'll merge it with my optimization branches under review and work from there for the script. [16:11] Cool. [16:11] I'll ping you as I update things that might have an impact on what you're doing. [16:16] cool [16:23] danilos: here is the FF request i made: http://paste.ubuntu.com/587806/ [16:25] bac, looks good, shall we try with other LOSAs or are they all busy with the same emergency? [16:25] Weird. Getting Graham's branch is taking the most work of any LP branch I've had in a long time [16:25] Fetching revisions:Inserting stream:repacking chk:chk node 422334/559643 [16:25] most work in bzr I should say [16:25] bizarre [16:25] heh. heh. [16:25] bac, btw, what does 16 indicate here? (I know I have 10 in my local set-up) [16:26] it is the priority. TBH i just stole the line from the other related FF. it only comes into play if there are other flags with the same name in other scopes...maybe? [16:27] bac, ah, ok, thanks for the clarification, I was just wondering what it was supposed to be in the first place [16:28] wow... it is *still* going... [16:30] gary_poster: Might be something to do with it being a db-devel branch [16:30] I noticed the same thing when I pushed. [16:37] huh [16:37] danilos: as to the LOSAs, i peeked into lp-ops a bit ago and they still seemed quite busy. ping them later if you want. [16:37] well, I got it now [16:41] bac, yeah, I will thanks [16:57] biab === _mup__ is now known as _mup_ [18:18] gary_poster: I'm about to EoD. I haven't added anything of note to my branch. If you need to add any APIs or what have you to IBugSubscriptionFilter or *Mute just add them and send me an email so I know to merge the changes. [18:19] gmb, sweet. [18:49] danilo, you around? I have database things to ask you, if you are :-0 [18:49] :-) [18:50] Storm, to be precise [18:50] gary_poster, I am [18:50] cool [18:50] so, if I want to get only fields as results from storm [18:51] gary_poster, you get tuples of actual values :) [18:51] gary_poster, but I suppose that's not the question [18:54] :-) yeah sorry someone came to door [18:54] so yesterday I had a bit of annoyance [18:54] Storm was trying to cast values [18:54] and the values were sometimes None [18:55] which the casting didn't like so much [18:55] They were None for expected reasons [18:55] but the fields couldn't handle it [18:55] gary_poster, ah, interesting, did it happen with foreign references? [18:55] yeah [18:55] maybe [18:55] :-) [18:55] gary_poster, you should probably use "columnID" then [18:56] gary_poster, and probably file a bug against storm if there isn't one already [18:56] That worked well, actually, but...oh, here's my concrete example... [18:56] gary_poster, I am guessing it's a left join then :) [18:57] right [18:57] I had a left join [18:57] and I wanted to get a status [18:57] EmailAddress.status to be precise [18:58] and sometimes it would be None [18:58] because of left join [18:58] and things would fall over [18:58] and I wondered if there were a way to get the value without processing [18:58] like you can do columnID [18:59] Is there a trick like that? [19:00] gary_poster, how about coalesce? [19:00] ooh, sounds magic :-) [19:01] gary_poster, basically Coalesce(Something, -1) will return -1 if Something is NULL [19:01] I'll try googling storm coalesce [19:01] gary_poster, it's regular SQL COALESCE, just wrapped in Storm as Coalesce I believe [19:02] I'll play with it. Thanks danilos! [19:02] gary_poster, it's probably no surprise that most of the occurrences are in lp/translations :) [19:02] :-) [19:03] danilos, btw, I had another idea on how to reduce SQL in sending email. I think it might be important, since we are going to be adding yet more for the team subscription mute [19:03] gary_poster, ah, sounds nice :) what is it? [19:05] I'm trying to get all of the data for each notification batch at once (roughly), only retrieving the columns I want, and then divide things up in Python. I'm not sure if its a win in the big picture yet, but it should certainly reduce our SQL. [19:05] I keep thinking I should make a harness to produce something like what we have in production...I'm not even entirely sure what that would look like. [19:06] Anyway, I'm experimenting. I'll show you if I think it looks OK to see if you have any thoughts [19:07] gary_poster, yeah, probably having a script which creates a number of targets with a bunch of bugs, adds a few structural subscriptions and then does a few changes on existing bugs and files new ones would be nice for testing all this [19:08] The test factory seems like the easiest way to do that [19:09] gary_poster, yeah, definitely [19:09] I did a little bit of that for my last branch. Maybe I'll do some more this time around [19:09] gary_poster, and, on the topic of getting everything once, what do you mean with "notification batch"? for a single bug notification? [19:10] the notification batch that construct_email_notifications gets [19:10] gary_poster, fwiw, that's also why we have split-up sample data between test and playground, you can probably commit some of it if you use nice product names and such :) [19:11] danilos, I was just going to write a "test" and use that, rather than anything permanent. that way I can change things more easilt [19:11] y [19:11] do you suggest something diff? [19:12] gary_poster, I like the idea behind notification batches with a small finite number of queries, so big +++1 on that [19:12] cool [19:12] (that was stupid, +1000 is more like it :) [19:12] :-) [19:12] only stupid to a mathematician like you :-) [19:13] it won't be finite everywhere, but this last main loop can be finite, yeah [19:13] heh, yeah, to a developer like me, it evaluates to +(++1)==+2 :) [19:13] :-) [19:14] anyway, regarding testing, a test is good, but I always miss the actual data to easily test stuff, though it's probably better to have scripts that produce the data at will instead of including it in sample data [19:15] ok cool [19:18] gary_poster, the biggest win, though, will be from getting stuff for multiple persons at the same time, but as we all know, that's a "bit" more work [19:19] :-) well, that's what I'm trying to do. Like I said, I'll ping you for your thoughts later. [19:21] gary_poster, but isn't a batch construct_email_notifications gets restricted to a single person? [19:21] gary_poster, or are you changing that to take batches with different recipients as well? [19:21] danilos, it's restricted to a single "owner" or "actor". There are many recipients [19:21] gary_poster, aaaahhhh [19:22] gary_poster, sorry then, yeah, that'd be very good then :) [19:22] cool :-) [19:32] bac, no rush, but ready for call when you are [20:00] bac, Skype test call did not have static when I called them. :-/ [20:00] just now I mean [20:00] i'm all for using skype again [20:00] Yeah ok [20:59] benji, can you give me 10? [20:59] sure [20:59] thx [21:05] if anyone needs a task I have some html generation refactoring I can farm out [21:18] benji, sorry, took longer than expected but ready now. [21:20] benji: i'm up for share cropping [21:20] bac: can you take on setup_overlay [21:20] sure. branch? [21:21] bac: lp:~benji/launchpad/better-HTML-generation (pushing now) [21:21] benji: ok. i'm in the middle of something ATM but can look soon [21:25] gary_poster: doesn't this seem like an easier way to go that should be more efficient? http://pastebin.ubuntu.com/587978/ [21:27] bac, if that is transitive, then yes, looks great, thank you [22:03] bac, please don't forget to claim "potential performance" card and move it into "Coding" [22:04] gary_poster: ok [22:04] thanks [22:05] done