=== Ursinha-afk is now known as Ursinha [13:08] * gary_poster needs to get back in the habit of joining IRC first thing... [13:08] * gary_poster enjoyed getting out of the habit :-P [13:09] * gmb -> grabbing a bite to eat; back for the call [13:09] cool [13:29] benji, gmb, finishing an email, but Skype in just a sec. Please make sure kanban is OK now. [13:34] gary_poster: https://bugs.launchpad.net/launchpad/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&fiel [13:52] gary_poster: Are we still having a call? [14:15] gary_poster: the official name for those things seems to be "embroidery hoop" [14:29] benji, cool, thanks :-) [14:29] gmb, call in 1? [14:29] gary_poster: Yep. [14:29] cool === Ursinha is now known as Ursinha-afk [14:47] gmb, we do handle things properly for sending emails, pretty sure... [14:48] (in lp.bugs.model.structuralsubscription, get_structural_subscription_targets looks at bugtask.target.parent_subscription_target, which for a product will be a project) [14:48] Ok. [14:49] I'll double-check, but I'm 95% certain that we have tests to cover sending structural subscription emails for project groups. [14:49] yeah, I would have expected it [14:49] The UI and the email stuff are worlds apart, really. [14:49] I was just concerned because I hadn't thought of it [14:50] I know that feeling all too well. [14:50] :-) [14:58] gmb, lp.bugs.model.structuralsubscription has the problem in two methods: get_structural_subscriptions_for_target and get_structural_subscriptions_for_bug . Fixing the latter will also affect a bug's also_notified_subscribers, fwiw. [14:58] * gary_poster leaving you alone now :-) [15:00] gary_poster: Thanks for the guidance :) [15:00] np :-) [15:00] * gary_poster should have said two *functions* [15:01] Hah. Indeed. [15:42] benji, crazy idea: if the team's contact address is a mailing list controlled by Launchpad, and we can tell this (I expect we can), and we can tell that the person is or is not a member of the mailing list, then we could offer a link to unsubscribe from the mailing list as a remediation action. [15:43] rephrase: if the team's contact address is a mailing list controlled by Launchpad, and the person is subscribed to the mailing list, then we could offer a link. [15:43] An interesting question then is what to do if the person is not subscribed to the mailing list [15:43] gary_poster: good idea; and I assume that if they aren't a member of the mailing list we would act as if the team didn't have a contact address at all (?) [15:44] in that case, it would seem that the subscription might not be pertinent then... [15:44] we could not render it, or render it with some "grayed out" visualization or something [15:44] I think we should still render it somehow [15:45] so people can see that it exists and why it does not affect them...*especially* after they have made a change [15:45] (e.g., unsubscribed from mailing list) [15:46] hmm, that could work; would strike-through be too much? it only really works for short bits of text [15:46] yeah, this is a whole box [15:46] I don't think strike-through would be good [15:46] being grayed out sounds decent, the more I think about it [15:47] we wouldn't offer an in-page change for this [15:47] so we wouldn't have to worry about too many controls on a "diabled" box [15:47] disabled [15:53] benji, if we gray this out, we have to gray the "opt out from this subscription" too, I just realized. [15:53] k [15:55] so I suppose another option is just having extra text like we do for the opt-out thing. [15:56] benji, I'm cool with you making a call. If I'm around, I'd love to see what you decided on for the chance to make tweaks, but don't block on me. [15:57] sounds good [15:59] gary_poster: I just filed https://bugs.launchpad.net/launchpad/+bug/781729, hopefully it captures the problem in a reasonable way. [15:59] <_mup_> Bug #781729: Direct subscription controls are (mostly) ineffectual if subscribed via a team with a contact address < https://launchpad.net/bugs/781729 > [16:00] Cool, thanks benji. Looks good. I'll add a comment [16:00] k [16:30] benji, are you ok with having our performance review report tomorrow @4 (the same time as our Thursday call)? [16:30] performance review report *call* that is [16:30] gary_poster: sure [16:30] cool [16:45] benji, I just carefully composed an email to you, and then sent it from our family email address. :-P . Maybe even twice for good measure, though I'm not sure how I managed that. I'll resend from Canonical; apologies for the dupes. [16:46] heh [16:46] I've come close to doing the same thing. [16:47] benji, ok resent [16:47] gmb, also sent you one. [16:47] gary_poster: Just got it, thanks. I'll take a look shortly. [16:47] cool [16:48] gary_poster: Separately, amusing one-line fix for part of bug 777783: http://pastebin.ubuntu.com/606538 [16:48] <_mup_> Bug #777783: Project +subscriptions doesn't show subscriptions to the project group < https://launchpad.net/bugs/777783 > [16:48] gary_poster: got them; tell Karyn that I appreciate her input on my review [16:50] Quick version, having the __helper cached for products means that when get_structural_subscription_targets() is called, and it looks up the parent_subscription_target, it gets None back, because the __helper was initialised before the Product knew about its Project. [16:50] I do not know why this happens in the real world, however. [17:01] gmb, fix: heh and argh [17:01] benji, I'll pass that along :-) [17:02] gmb, that means somebody is asking for that value and getting the wrong answer though :-( [17:03] I think that cachedproperty doesn't cache unless somebody asks for the value [17:03] gary_poster: You're right, it doesn't. [17:03] So yes, something is asking for it somewhere. [17:03] I'm going to carry on fixing this, but I'm also going to push this into ec2 and see what breaks. [17:03] * benji lunches. [17:04] So I think that the test is right, but it should stay a cachedproperty [17:04] (And if nothing breaks, I will be slightly concerned). [17:04] gary_poster: Yes, I agree. Some pdb fun might have to happen here, I thikn. [17:04] and we should fix why it is not being initially set properly [17:04] yeah [17:04] That's what makes the least sense to me. [17:04] if you need another pair of eyes, ask [17:04] I mean, in the case of the test, I understand it. [17:04] Because i create the product and then set the project. [17:05] But even if I do something like: [17:05] ... ah, no. The factory does the same thing. [17:05] I wonder what happens if I re-fetch the project from the store... [17:05] * gmb goes to try that [17:06] ack [17:06] I'm going to go for a walk, and have lunch and such. biab [17:06] gary_poster: Do you know how to invalidate the storm cache for an object? [17:06] try committing transaction and just getting it again? [17:06] IOW, no :-P [17:06] Heh. [17:07] Okay, I'll try the big hammer first. [17:07] k :-) === Ursinha-afk is now known as Ursinha [19:49] gary_poster: you may be on the phone, but it just occurred to me that we're going to have the same changing-your-direct-subscriptions-might-not-reduce-your-mail-level problem with the mute link on the bug page [19:49] benji, yes. I think that's already handled in the mockups for bug 772754 though [19:49] <_mup_> Bug #772754: After better-bug-notification changes, list of bug subscribers is confusing < https://launchpad.net/bugs/772754 > [19:50] ah, cool [21:00] benji, ready whenever you are