[13:09] gmb, to your knowledge is there a way to get to https://qastaging.launchpad.net/~gary/+structural-subscriptions right now? [13:09] I mean, via a link exposed in Launchpad? [13:10] and hi btw :-) [13:10] gary_poster: Hi. Nope, you can only get there by URL hacking. [13:10] ok cool thanks gmb [13:11] gary_poster: btw, I took on adding a mute button as it's a relatively simple change for me to tackle before the end of the week and won't block anyone if I don't finish it. [13:11] gmb, sweet, thanks [13:11] heh, the kanban representation is a bit unorthodox, but whatever :-) [13:14] bac, benji, danilos, gmb, hi. We'll do our delivery meeting after the standup (https://dev.launchpad.net/yellow#Due%202011-02-18). If you need us to get a particular branch to show off your work (or some other preparation) please let us know beforehand. [13:21] danilos, Benji and I talked yesterday about "Every structural subscription should have a filter." He'll also need it for his work. I said you'd be working on it, and lo and behold, you are. :-) He suggested that we could have a script that we could do this in three steps: 1) make a script that gradually adds a "include everything" filter to all structural subscriptions that do not have a filter, and get that [13:21] running on the production database. 2) get a devel branch that makes a filter whenever you create a structural subscription (i.e., enforced in Python). 3) make a db patch that enforces this for next db rollout. That sounded like a nice plan, because it would mean that we could rely on a filters being around after step 2 was rolled out and step one reported that it didn't see any more structural subscriptions [13:21] without filters (and before a db rollout, which would help him). So I pass that along for your consideration, if you haven't thought of it already. [13:22] gary_poster, we have only around 23k StructuralSubscriptions atm, so we can create matching BugSubscriptionFilters during a DB rollout as well [13:23] gary_poster, also, just having a BugSubscriptionFilter is enough for it to be all-inclusive (i.e. no need to set it to all statuses or something like that) [13:24] gary_poster, so, I already have a branch where I am doing 1 and 2, and I thought about enforcing it in the DB directly, but that kinda gets ugly (multi-table constraints are ugly) [13:24] danilos, ok. The only advantage of the other plan is that we don't have to be blocked by a db rollout for work on bug 674422. Ack and agree on just having a BugSubscriptionFilter [13:24] <_mup_> Bug #674422: Add a workflow to update StructuralSubscriptions

< https://launchpad.net/bugs/674422 > [13:24] gary_poster: my branch is at lp:~bac/launchpad/accordionoverlay -- i added it to the wiki page along with a screenshot [13:24] gary_poster, I can still land it on devel, sure :) [13:24] danilos: ack and awesome, sounds perfect [13:25] * gary_poster has not written multi-table constraints so was speaking naively [13:25] bac, awesome thank you [13:25] gary_poster, as for the migration for existing data, we can ask for a manual DB query run as well [13:25] danilos, you don't think it would produce a particularly long transaction? [13:26] gary_poster, it'd be best to check it, I'll prepare a query and have it tested on staging [13:26] cool thanks danilos [13:26] np [13:28] bac, benji, danilos, gmb, apologies for spamming you with IRC messages today, but here's the usual reminder: mumble/kanban in 2 [13:28] I like reminders. [13:28] :-) [13:28] +1 [13:45] lib/lp/bugs/javascript/bugtask_index.js [13:46] lib/lp/bugs/javascript/bugtask_index_portlets.js [14:01] gmb, benji: I'd like to have a mid-imp sanity-check call today at your conveniences [14:02] bac: cool, I'll get with you after this call [14:02] bac: I'll be available at the same time as benji [14:26] hum, any suggestions for a catch-all BugSubscriptionFilter.description that we'll be creating? I am thinking 'Default', 'Catch-all' or empty [14:26] (Catch-all might be inappropriate if for the first actual filter we reuse this one) [14:28] gary_poster, fwiw, a transaction on staging to insert 23k BugSubscriptionFilters took 3.5s (iow, a full "migration"), so I believe we can do it live on the production DB as well [14:31] danilos OK awesome. I suspect we need to clear it with lifeless and/or stub? [14:32] gary_poster, yeah, we'll need to clear it with a TL, and I'd definitely like to have stub look it over and confirm replication won't have trouble catching up either [14:33] gary_poster, at least it was previously a policy for a TL to be able to approve queries :) [14:33] gary_poster, so it can be you as well :) [14:33] danilos, ok, I'm happy to give it a TL OK if stub approves. :-) [14:33] gary_poster, excellent, thanks [14:34] gary_poster, the only thing I need to come up with is the BugSubscriptionFilter.description value we want these entries to have [14:34] benji, considering you had a need for this as well, any opinion? :) [14:35] ...I'm inclined to not put in a description (or empty string if necessary) [14:35] because that's how a subscription will look like be default when you add one manually [14:35] IIUC [14:36] danilos, so you see any issues with that? [14:37] gary_poster, no, it's one of the options I considered as well, the only worry I have is that we'll have to make sure our implementation reuses this filter when a first "real" filter is created (or people will get all emails without realizing it is due to this catch-all filter) [14:38] gary_poster, though, we'd want to make sure our implementation does that for more than this reason, so I don't see it as a real issue [14:40] precisely, danilos [14:56] hi benji, gmb: i'm having some issues on my desktop. if you proposed a meeting time i missed it. [14:56] bac: any time [14:57] benji: ok, let's wait for gmb [14:57] k [14:57] I'm free any time too. [14:58] Let me re-headphone myself and I'll join you on mumble [14:58] bac, benji : Ready when you are [14:59] gmb: can you grab that branch i posted earlier on the wiki? [14:59] bac: The accordionoverlay branch? [14:59] yes [15:16] hey gmb, I thought malone-alpha team people would have the new JS widget on production now, but I don't see it. Is that expected? [15:16] Hrm. [15:16] * gmb looks [15:16] you are probably on call--no worries, reply when you can [15:16] I'm not, actually [15:16] Surprisingly :) [15:16] oh ok cool [15:16] :-) [15:17] gary_poster: Hmm. WFM. [15:17] oh! [15:17] Let me check your membership of malone-alpha... [15:17] I'm a member of https://launchpad.net/~malone-alpha [15:18] Yeah. [15:18] gary_poster: What page are you looking at that you're not seeing the overlay on? [15:18] Maybe it's a jS problem. [15:19] Maybe it's user problem. https://launchpad.net/lazr.restful , clicking "Subscribe to bug mail...oh!!! duh. :-P [15:19] There we go [15:19] direct subscriptions work finr [15:19] fine [15:19] sorry :-P [15:19] gary_poster: Yeah, it's bac and benji who are on the hook for the other one :) [15:19] :-) [15:20] cool, thanks gmb [15:20] np [15:20] gmb, have we announced to malone-alpha people? Should I do that next week or today or something? [15:20] gary_poster: I meant to do it earlier this week but mockups ate most of my time. If you could announce it that would be awesome. [15:21] cool, will do. [15:21] Thanks [15:21] np [15:39] danilos, with your work for bug 720826, it will be trivial to then have the email link back to "unsubscribe" include information on what filters caused the email to be sent, right? The information will already have to be available. [15:39] <_mup_> Bug #720826: Add subscription description header for bug notifications < https://launchpad.net/bugs/720826 > [15:39] gary_poster, that's what I expect, yes [15:40] cool thanks danilos [15:40] gary_poster, i.e. I will be introducing a link to the actual BugSubscriptionFilter on BugNotification table [15:40] danilos, I was wondering about that, only one? [15:40] may need to be many to one [15:41] one way r another [15:41] or [15:41] gary_poster, well, each notification is for one action, so when we construct the email, we should worry about that side [15:41] gary_poster, one email includes multiple BugNotifications, so that's how you get one-to-many [15:41] danilos, but an action may have been sent because of multiple filters [15:41] I'm not sure we have to worry about this, but it should be a conscious decision not to [15:41] gary_poster, hum, right, good point [15:42] gary_poster, I am not going to even start on that today (I hope only to finish auto-creation of BugSubscriptionFilter by the EOD) [15:42] danilos, cool, I won't stop you, but it can be in the back of your head for Monday [15:44] gary_poster, right, I'll have to think about it, though I am pretty sure that we'd have to restructure our code for that as well (i.e. maybe a notification gets sent atm when a first filter is matched), but I don't expect that to be a big deal [15:45] danilos, yeah, was thinking similarly, though I was merely *hoping* it was not going to be a big deal ;-) [15:46] gary_poster, heh :) [15:56] benji, I have this in my notes from this morning: " * We Should Do Something about mentioning that request/features always works in templates, and features only sometimes works." Can I change that to "Benji will announce or document that request/features always works in templates, and features only sometimes works, and propose that request/features be the One True Way."? [15:57] May I change that. :-) [15:58] gary_poster: sure; I'll do so by replying to Marin Pool's recent documentation effort email. [15:59] cool thanks benji [16:02] * benji lunches. [16:25] gmb, unless you mind, I'm gonna move the kanban card for bug 204980 into quick jobs, so feature work 1 is more focussed. I'm then going to add a card for an API to get a person's structural subscriptions for a bug's tasks, as we described on the call. Can I move the two mockup related cards in feature work 1/review over to Done/Done? [16:25] <_mup_> Bug #204980: bug contacts should be able to unsubscribe from implicit subscriptions

< https://launchpad.net/bugs/204980 > [16:26] oh and another hand-off: can you make sure that we know how to qa the two cards in QA/landing? [16:26] (the two cards of yours, I mean) [16:27] gary_poster: In order: 1) Well, you can move it, but I don't think it's a quick job after all (will explain in an email, but basically it breaks things in an intereting fashion). 2) Okay, 3) Sure, 4) Certainly. [16:27] 1,huh, ok [16:27] and the rest, ok thanks :-) [16:28] gary_poster: Quick summary of problem #1: All the JS works fine, but Zope subsequently says "LOLWUT?" when you've muted a bug, due to the validation we do for the +subscribe page. [16:28] Oh! So, you have a nice way to turn everything on and off, but the muting itself is a problem [16:28] Right. [16:29] I see. :-/ [16:29] BUT. [16:29] I think I can see ways through it. [16:29] So I'll file bugs (oh for bug relationships) about that and summarise the order I think things need to be addressed in an email to the team. [16:30] cool thanks gmb. um...I wonder what we should do about the janban board. [16:30] or kanban [16:30] gary_poster: Well, can we move that card back to the backlog without breaking stats or something? [16:30] no not really :-P :-) [16:30] Ah. [16:30] Bother. [16:30] gary_poster: Well, let's do this: [16:31] 1. Update the card to reflect that what I'm *actually* going to do today is land incremental but non-user-impacty stuff [16:31] I was going to suggest we delete it and remake it, or change it to "investigate" and move it to archive/done [16:31] Or that. [16:31] That seems simpler [16:31] Simple wins. [16:31] gary_poster: I'll do the latter. [16:32] ok cool [16:32] that sounds like a reasonable compromise between easy and reflecting reality [16:32] Right. [16:32] (change it into a task card too please, and remove the bug number or the kanban board will whine and complain) [16:33] (or at last it does in my experience, when you try to make a new one with the same number) [16:33] Done [16:33] cool thanks [16:34] then if you could claim a backlog lane for the tasks/bugs for this, with a new feature card for the bug number, that would be fab [16:34] Sure, will do. [16:42] * gmb -> afk for half an hour or so to braindump my thoughts about hte mute button [16:42] cool [17:08] * gary_poster lunching [17:09] https://wiki.canonical.com/Launchpad/Strategy/2011RelCalDraft <- maybe useful [17:09] Might become https://dev.launchpad.net/Releases/2011Calendar [17:30] gary_poster: Brain dump: https://dev.launchpad.net/yellow/MuteButton. Filing bugs now. [18:18] * gary_poster no longer lunching, now reading. Thanks [18:21] gmb, reading that page, one of the first thoughts I had was "I wonder if the enumeration is the wrong way to express muting" [18:21] gary_poster: Possibly. I can't remember what we said we were going to do with the enumeration on direct subscriptions. [18:21] A BugMuteTable that contains records of person, bug for thinsg that should be muted might be better [18:22] I suspect so. My thinking is couched in terms of years of "oh, we used to have Ignore Subscriptions" cruft. [18:22] The BugMute table solves more problems. OTOH, it needs yet another DB patch, but maybe that's not so terrible. [18:23] my branch for always creating a BugSubscriptionFilter when a SS is created is up for review, though I'm about to leave for the week [18:23] At this point, I think that's a sunk cost [18:23] gary_poster, fyi ^ [18:24] True. [18:24] danilos, ok cool. Do you want me to try and land it if the review flies by? [18:24] gary_poster, query already approved by Stuart, and I'll have it added as a special rollout requirement [18:24] great danilos [18:24] gary_poster, yeah, that'd be nice, I am putting it through ec2 test anyway (already under way) [18:25] cool danilos. [18:25] gary_poster: I'm sanguine about going either way with muted subscriptions. Simpler is better, and BugMute seems simpler. [18:25] cheers, enjoy the weekend all [18:25] cheers danilos [18:26] gmb, are you still here for another 34, or are you 26 over? [18:26] gary_poster: I'm 26 over and about to head down for dinner. [18:26] OK cool, then I won't bother you [18:26] Have great vacation! [18:26] Will do, thanks. [18:27] * gmb -> exeunt, in pursuit of not thinking about JavaScript [18:27] :-) [22:18] I've decided to take Monday off, so I'll see y'all Tuesday. Have a great weekend.