[01:49] https://oops.canonical.com/oops.py/?oopsid=OOPS-493eb7067f568cde87767956e4f8ce24 is impressive [01:50] 1061 repetitions of a query to check if the current user is affected by a bug [01:51] It wants to be REALLY sure [01:51] # Loop over dupes. [01:51] for dupe in self.duplicates: [01:51] if dupe._getAffectedUser(user) is not None: [01:51] dupe.markUserAffected(user, affected) [01:52] Oh [01:52] That seems pretty pointless... [01:53] I guess it might be helpful to unaffect dupes when unaffecting the master [03:33] wgrant: I've fixed the test failures in destroy-old-bugactivity, I'll be landing it shortly. [03:35] StevenK: Great [03:35] Now go away :) [03:36] Haha [03:39] what? haha. [03:39] nigelb: I'm on holidays this week. [03:39] So wgrant is telling me to stop caring about work from last week. :-) [03:39] StevenK: Aha. yes, go away. [03:40] But it hasn't landed yet! [03:40] Where's a freenode staff when you need one. [03:40] Oh, don't even joke about that. [03:40] Waitaminute [03:40] They've k-lined me twice 'by accident' [03:40] I'm sure your SO can arrange that ;) [03:41] Hah [04:29] wgrant: does it make sense that when auto confirming a bug, any duplicates of that bug should be confirmed also, without the need for affected user checks against each individual dup? [04:34] wallyworld_: No. In fact it's a bug (probably already reported) that duplicates get autoconfirmed at all [04:35] wallyworld_: Launchpad supports autoconfirmation only provisionally and begrudgingly; don't feel like you have to go too far out of your way to make it smooth [04:35] wgrant: ok, so if i do a bulk update for affects user, i can ditch the need for any recursive call processing [04:35] Right [04:35] what about heat? [04:35] can dupe heat be set to master heat? [04:35] No [04:35] i may need to to a stored proc which bulk updates heat [04:36] instead of just one bug id at a time [04:36] Nah [04:36] See the garbo job [04:36] oh, ok. didn't realise there was one [04:36] You can do eg. some_result_set_of_bugs.set(heat=SQL('calculate_bug_heat(Bug.id)') [04:36] And it'll construct a single UPDATE [04:37] ok, nice [04:37] thanks [04:37] Calling the function a thousand times isn't a problem, as (particularly after I last took an axe to it) it's quite fast. The problem is making a bazillion roundtrip queries. [04:37] yes [04:37] A quick fix to this also wouldn't go near the heat issue at all [04:38] Since it's very unlikely that the user has clicked the affectsme button on more than a couple of dupes [04:38] So it won't be triggered more than a couple of times a request [04:38] But batchifying more code is always good, so why not do the comprehensive fix, I guess :) [04:38] well, i'm lookin at ditching the recursive call and bulk updating all dupes in the tope level affectsMe all [04:38] Note that it's not quite like that [04:39] It sets the affectsme status of any dupes that already have an affectsme status [04:39] sure, i'm handling that [04:39] Great [04:39] Just confirming [04:39] np :-) [04:40] but it means ditching the confirm of dupes, which you say above is ok [04:40] and i'll do a single update for heat [04:40] So yeah, I'd just find all the dupes that have a BugAffectsPerson for the user, set them, set their users_affected_count to AutoReload (or amybe not, it might mean we don't care), and then bulk update the heat [04:40] an invalidate and flush will do the same thing? [04:40] as setting to AutoReload [04:40] Yeah, but it's excessive [04:41] So it's nice to avoid it [04:41] it's used already [04:41] Yes [04:41] so i'll see if i can ditch it maybe [04:41] It's already excessive! [04:41] Right [04:41] not sure [04:41] To some extent we really don't care that the dupe counts are off by one [04:41] (for the current transaction) [04:42] ok, i may see what ec2 comes back with perhaps [04:42] But if we do care, then just set the affected columns to AutoReload, as it's much cheaper than invalidating the entire object [04:42] not sure if this will help the other bug 925937 [04:42] <_mup_> Bug #925937: Does this bug affect you: Timeout error popup < https://launchpad.net/bugs/925937 > [04:42] maybe [04:43] since auto confirm for dupes is not going to be dome now [04:47] wallyworld_: No, sadly [04:47] wallyworld_: That's autoconfirming the main bug [04:47] oh well [04:54] Oh. Now I realize wallyworld_ is Ian Booth. [04:54] Throws me off every time I read your real name :) [04:55] i like to be different [04:55] Heh [04:55] ianb would be such a boring nick [04:55] boothi sounds more fun ;) [04:56] there's a few other words that suit better, but they're not for a family channel [04:56] hahaha [04:57] right, off to pick up kid from school [05:11] wallyworld_: you could go for ixb [05:35] spm: i could, but it's too late now [05:37] it's never too late [05:37] you could have ixb_formally_known_as_wallyworld [05:38] wallyworld's his legal name? :) [05:38] i'm too lazy to change it [05:48] Hmm [05:48] SQLObjectResultSet.__bool__ irks me [05:51] Er, __nonzero__ [05:51] That's the one [05:51] Still evil [05:58] SQLObject needs to be destroyed [06:02] Your internet access needs to be destroyed. Until after vacations. [06:02] Yep [06:03] But I needs it for Steam! [06:03] Anyway, I lose Internets on Wednesday [06:04] You need to take a vacation on some island with poor internet connectivity. But, you already live in Australia. [06:05] So yeah, mission accomplished? [07:53] good morning [08:26] purple you guys were busy yesterday [08:26] *today [08:26] We're always busy [08:28] my inbox says very busy :) === almaisan-away is now known as al-maisan === gmb_ is now known as gmb === al-maisan is now known as almaisan-away === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: ~260 [12:11] gm Alice [12:12] seems you are well informed, hadn't heard about Sam until I saw your mail [12:16] wrong channel === Ursinha-afk is now known as Ursinha [14:07] rick_h_: On https://qastaging.launchpad.net/bzrtools/+edit I see a green flash when I change information type. I believe that's supposed to mean that the change has been applied to our server. [14:18] abentley: looking [14:19] abentley: ah, gotcha. will file a bug/card [14:21] rick_h_: Cool. [14:21] do we have a tag we're using for privateproject work? [14:22] ah, see private-projects [14:26] abentley: I also looked into that bug from friday and filed that bug along side this one [14:26] where without JS you saw all of the radio buttons for all info types vs the 3 valid options [14:27] rick_h_: Thanks. I experienced that bug with JS enabled, though. [14:27] abentley: hmm, well I figured there mus thave been a JS error in your local env since I didn't see it on qastaging but you mentioned you had it with js disabled [14:28] abentley: I guess if you can repeat it with JS enabled let me know and we can look if something in the JS to build the widget failed since you shouldn't see radio buttons [14:29] rick_h_: We should also fix JS errors that affect local dev environments. [14:29] abentley: agree, but I don't know what your JS error was which is why I'm saying if you hit it please let me know more details [14:31] rick_h_: Reproduced. [14:31] abentley: awesome [14:32] rick_h_: The console shows Error: extend failed, verify dependencies [14:32] ugh...ok so this is on a project/+edit you're getting this in your local dev env? [14:33] rick_h_: Yes, https://launchpad.dev/firefox/+edit [14:33] abentley: ok, loading up a clean trunk dev env to peek at [14:33] rick_h_: I am using firefox, btw. [14:34] abentley: ok, checking. Not seeing it in chrome [14:34] rick_h_: I'm seeing the radio buttons in chrome. [14:35] abentley: ok, trying to see if I can replicate. make clean/make run and such. [14:36] abentley: the error you hit is generally because there's a missing new SomeObject when creating an instance [14:36] or a missing dep in the list of requires for some module [14:37] rick_h_: This is on line 10 of https://launchpad.dev/+combo/?yui/yui/yui-min.js&lp/meta.js&yui/loader/loader-min.js [14:38] abentley: does your line 10 look anything like: https://pastebin.canonical.com/76544/ [14:39] abentley: have you updated your feature flags locally? Are you running yui 3.5? [14:39] I wonder if it's broken for you since I used Y.View which is yui 3.5 and you might still be set in your dev env for 3.3 [14:39] abentley: that would explain why it works in qastaging/production [14:39] rick_h_: No, it looks like https://pastebin.canonical.com/76545/ [14:40] abentley: yea, I bet you're running the old YUI locally still via either lack of make clean/clean-buildout or via forced feature flag setting [14:41] rick_h_: One should never have to run make clean. I can confirm I'm still running 3.3 [14:42] abentley: ok, I guess that's a failing on my end then. I tend to run make clean whenever I bzr switch so didn't realize this [14:43] rick_h_: Yeah, I only run make clean as a last resort. [14:43] abentley: so the make commands around JS build check for the existing of the build/js/yui and build/js/lp and they existed [14:43] Not when I switch or anything. [14:44] and only rebuild around them missing so I guess we can look at a more robust or always rebuilding them [14:47] rick_h_: So I guess 3.3 is obsolete now, and we should remove support for it. [14:48] abentley: yes, it's on the JS clean up todo. SteveK talked about working on some of it, removing some of the jsbuild bits and such [14:48] rick_h_: Now that I've "make clean"ed, I'm seeing the JS widget, not the radio buttons. [14:48] granduating combo build up to full status and cleaning up the yui-deps.py [14:48] abentley: cool, good to hear [15:07] abentley: I'm working on trying to get InformationType to show up for new blueprints UI locally. I've enabled the feature flag, there's nothing in +configure-blueprints about adjusting the information types, but I don't get the field in the list as I do on qastaging/production. [15:07] abentley: is there another step I'm missing to enable the field? [15:07] rick_h_: OTP [15:07] abentley: rgr [15:26] jcsackett, do you have time to hangout? [15:30] rick_h_: Have you enabled the blueprint-specific flag? [15:31] rick_h_: i.e. blueprints.information_type.enabled ? [15:31] abentley: yes [15:31] blueprints.information_type.enabled default 1 on [15:32] rick_h_: Have you enabled private blueprints under +sharing? [15:36] abentley: ah I think I see. Since this new project is public and doesn't have a commercial subscription it can't immediately set a non-public blueprint? [15:37] rick_h_: Indirectly. If your specification sharing policy is "Public", you can't set non-public, so you don't get the field. Non-public policies should only be available if you have a commercial subscription. [15:37] abentley: got it [15:37] abentley: yea, had to get a commercial subscription to get the edit UI for the +sharing to change the policy [15:38] abentley: thanks [15:38] rick_h_: np [15:40] abentley, deryck, rick_h_: sorry, I just saw another EC2 test failure that I missed earlier today; fixed now, but the new EC2 test is starting just now [15:41] adeuring, no worries. thanks for the heads-up. [15:41] adeuring: cool thanks. Yea I'm just holding off until your stuff hits pqm and I'll merge/submit to ec2 EOD/tomorrow morning [15:42] rick_h_: thanks. I'll ping you once my stuff lands. [15:42] adeuring: ty much [16:01] sinzui: ping [16:02] hi rick_h_ [16:21] which squad is doing maintenance at the moment? [16:22] jml: purple [16:22] czajkowski: ta [16:23] jml: why.. what have you broken :) [16:23] czajkowski: time. [16:24] \o/ [16:24] lifeless: :D [16:26] jml, you broke time? [16:27] sinzui: time is out of joint. === deryck is now known as deryck[lunch] [16:32] sinzui: wanted to check on if you filed a bug for the JS inline stuff around https://bugs.launchpad.net/launchpad/+bug/1052551 The inline stuff was in the NullChoice side of the widget so wasn't sure if the bug was valid and wanted to check it out [16:32] <_mup_> Bug #1052551: Specification sharing policy is not honored by the edit information_type widget < https://launchpad.net/bugs/1052551 > [16:34] rick_h_, why can't we change the info type of this blueprint. We own it and the project allows public :https://blueprints.qastaging.launchpad.net/launchpad-help-moin-theme/+spec/testing-proprietary-1 [16:34] sinzui: yea, there's bug in the JS/css setup in the .pt [16:35] I've got that fixed, but was looking at the comment you made about the choiceedit.js doing manual style setup on 'inline' [16:35] sinzui: https://code.launchpad.net/~rharding/launchpad/info_portlet_1052551/+merge/129706 for the .pt and setup issues I'm fixing currently [16:35] ah, I reported that as a separate issue. [16:35] sinzui: right, so tring to find that separate issue atm to look at it and my search-fu is failing me [16:36] rick_h_, this is definitely separate: https://bugs.launchpad.net/launchpad/+bug/1064555 [16:36] <_mup_> Bug #1064555: choicedit assumes icons are inline and tampers with the style.display < https://launchpad.net/bugs/1064555 > [16:36] wondered if you had it handy and if you had realized the setStule stuff was in the NullChoice widget and if it still applies [16:36] rick_h_, all feature bugs should be tagged private-projects, that will narrow the search [16:36] sinzui: yea, so the cause was manually adding display:inline to the .pt file [16:36] not the JS in choiceedit [16:36] ok cool, I'll reply to this one as well as I wrap things up here [16:37] sinzui: note line #47 of my diff in my MP I'm working on [16:37] sinzui: cool thanks for the link that helps [16:38] rick_h_, I would exepct the choicesource bug to appear more frequently. It may affect your feature, but it definitely pre-exists a lot of feature work by about 3 years [16:39] sinzui: right, but in this case it wasn't a bug in choicesource, but in the JS manually run in specification-index.pt and boostrap html in blueprint-portlet-privacy.pt [16:41] rick_h_, oh, so maybe the error I saw about manipulating style.display is actually from the template...which may mean we have dead code in choice source [16:41] sinzui: right, the code in choicesource you grepped pertains to a NullChoiceSource widget [16:42] so maybe there's still a bug there, but that's why we don't see it much as it's not used as often [16:42] rick_h_, yes, I think you have fixed the real bug I experienced [16:43] sinzui: ok cool. Thanks for the link to the other bug. Want to make sure I catch all the parts here [16:44] rick_h_, if you can edit, and after the edit the text "Edit" does not appear, you have fixed my use case. I will remove the tags from the other bug. I guess it is tech-debt [16:45] sinzui: yea, the only thing now is that edit always shows even when there's only one value "Public" so I'll probably fix this bug but then file a bug about hiding that all together when there's only the one choice [16:45] ah [16:46] rick_h_, toggleClass('hidden') was the intent then...and choice source does not do it. [16:47] sinzui: gotcha. Yea, so I'll file a new bug about that then with this as the specific use case [16:49] rick_h_, so maybe the choice source should know to hide EDITICON when the length of choices are 1? [16:50] How do proprietary only bugs and branch portlets solve this? [16:51] sinzui: yea, that's what I would expect. [16:51] sinzui: I'm going to check out how branches solve this. It's not jumping out at me and I want to get this fix in asap. [16:58] rick_h_, This is not your problem...or at least this is not about blueprints. [16:58] rick_h_, https://code.qastaging.launchpad.net/~launchpad/launchpad-help-moin-theme/moin_launchpad shows a choice of 1 [16:58] sinzui: agreed which is why it'll be a new bug for now. I've got to wrap this up and move onto some more private project stuff [16:59] sinzui: ah, good to know then. Thanks [16:59] okay [17:07] benji: https://code.launchpad.net/~rharding/launchpad/info_portlet_1052551/+merge/129706 for your eyeballs if you get a sec please [17:08] rick_h_: sure === matsubara is now known as matsubara-lunch === BradCrittenden is now known as bac === deryck[lunch] is now known as deryck === matsubara-lunch is now known as matsubara === vednis is now known as mars [19:00] benji: could you please review https://code.launchpad.net/~abentley/launchpad/workitems-for-private-blueprints/+merge/129736 ? [19:01] abentley: sure [19:44] benji: Thanks. [19:44] my pleasure [19:51] rick_h_: Are you using my getProductPrivacyFilter for fixing bug #1063272 ? [19:51] <_mup_> Bug #1063272: Cannot view +related-projects because of private-project <403> < https://launchpad.net/bugs/1063272 > [19:54] rick_h_: my branch landed finally [20:53] wgrant, ping [20:54] wgrant, looking for a reviewer for a python-oops-tools branch: https://code.launchpad.net/~beuno/python-oops-tools/show-newest-oopses/+merge/129752 [20:59] beuno: on call reviewer is benji [21:00] czajkowski, this may be a tad specific to throw in the general review queue === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~260 [21:19] benji, thanks [21:19] benji, I'll reply in the merge proposal but the spaces after the comma are pep-8 complaints [21:20] beuno: right, but the commas themseleves are what stood out to me [21:21] benji, ah, yes, there's a bunch of XXXs warning that it needs refactoring [21:21] didn't look into it [21:22] beuno: I figured a code formatting tool or search/replace was used and the strange comma-after-a-single-item-list threw it off [21:23] right [21:23] no, all the crazy is hand-crafted! [21:28] * benji starts selling t-shirts with "all the crazy is hand-crafted!" on them. [21:45] beuno: I'm happy to review that, but any Launchpad reviewer can also do it [21:45] As benji suggests :) [21:52] wgrant, cool, thanks [21:54] abentley: Do you have a branch in progress to stormify Person.specifications? I have a branch that needs it, so if not then I'll do it today. [21:55] wgrant: Yes, I do. [21:55] wgrant: ~abentley/launchpad/user-blueprints [21:55] abentley: Thanks [21:56] Although it's mysteriously empty [21:56] wgrant: I just pushed it now. [21:56] Ah [21:56] abentley: Is it likely to land in the next day or so? [21:56] wgrant: I'm just in the middle of adding unit tests for the existing behaviour. [21:57] Right, it certainly needed it :/ [21:57] wgrant: Yes, ideally it will land tomorrow. [21:57] Great, thanks. [21:58] wgrant: What is your branch doing? [21:58] abentley: Fixing the +specworkload timeouts, which needs that query to be reworded and run over multiple people [22:00] wgrant: Okay. So where I'd naively put "Specification.drafter = user.id", you [22:00] want to do "Specification.drafter.is_in(user_ids)" etc? [22:00] benji, addresed and pushed [22:01] abentley: Right, I'll need to extract it out to separate function/method [22:03] wgrant: I should have *something* in the next couple of hours, but likely won't finish 'till tomorrow. [22:04] beuno, doesn't the db have the information on newest oopses? [22:04] james_w, I don't actually know :) [22:04] It does :) [22:04] wasn't sure if the oopses get processed and stored in PG as they come in [22:04] I haven't actually looked at the branch yet [22:05] You can find the latest with a simple Django ORM query [22:05] that would of been much simpler [22:05] benji, they do [22:05] beuno I mean [22:05] and much more efficient :-) [22:05] indeed [22:05] ok [22:05] so I need to change everything! [22:06] Well, "everything" == "one 10 line method", but yes :) [22:06] well, not everything :-) [22:06] no, EVERYTHING [22:06] or not [22:07] test should still pass, so forced TDD! [22:07] but, at this stage I [22:07] I'll add what I was going to in my follow up branch [22:07] relative time since the oops and some data about it [22:09] I want to add a similar thing to show the latest OOPSes for a pageid on a particular instance. [22:09] But haven't got around to it yet [22:28] wgrant: Initial implementation is pushed. Lots more to go. [22:29] abentley: Lovely. Thanks [23:19] abentley: didn't get that far before EOD to tell yet [23:21] rick_h_: I expect that it will want to use it, so I was leaving it alone until the other branch lands. [23:21] abentley: abel's branch? [23:21] rick_h_: No, mine. [23:21] abentley: I just merge his stuff and going to get my stuff waiting on that to ec2 for the night [23:21] abentley: ah ok [23:22] abentley: thanks for the heads up. I'll take a peek then at your stuff you've got in the wings [23:52] win 43 [23:53] 44