[00:10] <wgrant> wallyworld: https://code.launchpad.net/~wgrant/launchpad/better-createManyTasks/+merge/105422 should be pretty quick
[00:11] <wgrant> When you have a sec
[00:11]  * wallyworld looks
[00:11] <wgrant> Thanks.
[00:15] <czajkowski> gmb: ping
[00:16] <gmb> czajkowski, Hi
[00:16] <czajkowski> gmb: coming int san fran @ 6:30
[00:16] <czajkowski> shopping n dinner
[00:16] <wgrant> How'd the clinic go?
[00:16] <gmb> czajkowski, Can't; too much to get done. Thanks for the invite, though.
[00:16] <czajkowski> 2 people asked for help to fix bugs today
[00:16] <czajkowski> gmb: np
[00:17] <czajkowski> gmb: too much retouching to do to my pic :)
[00:17] <czajkowski> wgrant: how tied are ppas into builds?
[00:17] <wgrant> czajkowski: How do you mean?
[00:18] <czajkowski> wgrant: someone was sayign debian would like to have ppas
[00:18] <czajkowski> but mentioned that they are tied into builds
[00:19] <wgrant> I believe that's Launchpad's bug with the most me-toos...
[00:19] <wgrant> Bug #188564
[00:19] <_mup_> Bug #188564: Build also packages for Debian in PPA's <feature> <lp-soyuz> <ppa> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/188564 >
[00:20] <wgrant> Technically it's easy.
[00:20] <wgrant> The resources and social aspects are less so.
[00:20] <czajkowski> well its been brought up todayin session
[00:24] <bigjools> one of my goals is to allow people to use their own machines to build packages in their own ppas
[00:25] <bigjools> which would open up the possibility of debian ppas
[00:29] <rick_h_> wgrant: so the flush() business on the createTask just isn't necessary to maintain?
[00:29] <czajkowski> bigjools: ah good to know
[00:30] <bigjools> czajkowski: but that's totally unofficial :)
[00:30] <bigjools> czajkowski: but it's a place where maas could shine
[00:31] <wgrant> rick_h_: createManyTasks uses create(), which does that implicitly -- it runs a manual explicit Insert and then loads the tasks from the DB.
[00:31] <wgrant> rick_h_: Creating with BugTask() just adds it to the list of pending add operations.
[00:32] <rick_h_> wgrant: ah, ok gotcha
[00:33] <wgrant> We also probably should rewrite validate_new_target and validate_target to be set-based, as they can be somewhat expensive, executing a few queries per target.
[00:33] <wgrant> Eventually.
[00:34] <rick_h_> wgrant: while you're in there with this can you hit lifeless's suggestoin on removing the BugTask middleman?
[00:34] <wgrant> rick_h_: I didn't see that... is it a comment on the MP?
[00:34] <rick_h_> https://code.launchpad.net/~rharding/launchpad/bugnom_874250/+merge/105317
[00:34] <rick_h_> yea, after it was merged, so was going to do a follow up branch in the moring, but while you've got changes going
[00:35] <rick_h_> it'll be more LoC reduction
[00:35] <wgrant> Ah, it being post-merge would explain why I didn't see it.
[00:35] <wgrant> Will fix, thanks for the pointer.
[00:35] <rick_h_> ty much for the work, looking it over for education purposes
[00:36] <wgrant> It can seem nice to have helpers on Bug like that, but then you end up with multi-thousand line classes like Person :/
[00:36] <wgrant> np
[00:36] <wgrant> Thanks for working on these damn timeouts.
[00:36] <rick_h_> yea, well consistant vs "right" so oh well, guessed wriong
[00:36] <wgrant> I might land a followup to drop Bug.addTask too
[00:37] <wgrant> There's only a few dozen callsites.
[00:37] <wgrant> Mostly tests.
[00:37] <rick_h_> heh, this is awesome, so when I looked at removing the _init_ didn't want to dupe some of the code, but by doing that you get to remove it all
[00:37] <rick_h_> wgrant: yea, that seems like it'd be the best plan, but trying to wrap this up by EOD torrow
[00:37] <wgrant> Exactly :)
[00:37] <rick_h_> so wasn't goint to go all the way through the clenaup atm since we've got a full plate starting next week
[00:38] <wgrant> rick_h_: Eventually we probably want to move the nomination stuff into createManyTasks as well, but that opens a bit of a can of worms which I didn't really want just yet.
[00:38] <rick_h_> wgrant: so the next timeout issue there is on the notification subscriber stuff
[00:39] <rick_h_> it queries person 100's of times for 100's of subscribers, that's the next point after this one lands
[00:39] <wgrant> BugNotificationRecipient?
[00:39] <wgrant> Oh
[00:39] <wgrant> That, right.
[00:39] <rick_h_> sec, wonder if I still have the paste
[00:39] <wgrant> That's going to be a fun one -- I'll be surprised if you get it done this week. But worth a try.
[00:40] <rick_h_> yea, this is all for now
[00:40] <rick_h_> I've got to finish the bugtask.txt killing tomorrow
[00:40] <wgrant> Yep
[00:40] <wgrant> Good riddance :)
[00:40] <wgrant> Death to doctests, and all that
[00:40] <rick_h_> damn straight
[00:41] <rick_h_> http://paste.mitechie.com/show/650/ is a sucky paste of the oops post this change
[00:42] <rick_h_> the select Person seems to be the next target
[00:42] <wgrant> Inserting 242 bugtasks may still be too slow, given the exponential behaviour of bugsummary. But this has to be better than before.
[00:42] <wgrant> And I'm rewriting bugsummary today to not be exponentially complex.
[00:43] <rick_h_> cool
[00:43] <wgrant> Ah, I misread the OOPS, there's not 242 in that case.
[00:43] <wgrant> But we do have insane numbers like that sometimes.
[00:43] <wgrant> The Ubuntu kernel team always manages to find new ways to break LP :(
[00:43] <rick_h_> right it was taking 240ms per insert, now it's one inesrt to hopefully this helps a ton
[00:44] <wgrant> Most of that's likely to be bugsummary, but we'll see.
[00:44] <wgrant> wallyworld: Thanks.
[00:45] <wallyworld> np
[00:53] <wgrant> rick_h_: Ah, can't actually remove addTask, since it's exposed on the webservice.
[00:55] <StevenK> return None!
[00:55] <StevenK> WCPGW
[02:10] <rick_h_> wgrant: booo, oh well
[05:38] <wallyworld__> wgrant: did you have a pre-impl with anyone re: the sample data change? it sounds reasonable
[05:39] <wgrant> wallyworld__: I polled lifeless and StevenK in -ops and nobody complained.
[05:40] <wgrant> 15:05:17 < StevenK> wgrant: When I last used it, which was yesterday, I expected it to write to current{,-dev}.sql.
[05:40] <wgrant> etc
[05:40] <wallyworld__> wgrant: ok, thanks. r=me
[05:40] <wgrant> wallyworld__: Thanks
[06:16] <lifeless> wgrant: I suggested a larger sample size...
[06:17] <wgrant> My sample size covered a third of the active team.
[06:17] <wgrant> That's sufficient.
[06:17] <StevenK> Haha
[06:31] <lifeless> wgrant: so, I've just mailed the list in reply to curtis; I may be confused on some stuff... feel free to unconfuse me :)
[06:33] <wgrant> lifeless: I can't disagree with anything you said.
[07:15] <lifeless> kk
[09:25] <adeuring> gmb: would something explode if I increase the version number for testresources in versions.txt to 0.2.5?
[09:36] <stub> adeuring: I think everything using testresources is using the package or buildout, so bumping the version is pretty much a requirement before anything can see your changes.
[09:38] <adeuring> stub: right
[10:16] <stub> wgrant: We should be able to write a script to generate the bugtaskflat indexes by now :)
[10:17] <wgrant> stub: Indeed.
[10:17] <wgrant> I'll hopefully drop 2/3 of bug and bugtask's indices next week.
[10:18] <StevenK> And hopefully DROP COLUMN bug.private soon after
[10:18] <stub> wgrant: r=stub. Does this go live now?
[10:18] <stub> Or staging first?
[10:18] <wgrant> stub: I've tested them on DF, so live would be nice. Nothing will use them until Monday.
[10:19] <stub> I'll apply it live now, assuming everything is quiet.
[10:19] <wgrant> Should be.
[10:19] <wgrant> Given that we killed everything 20 minutes ago
[10:24] <wgrant> I'm surprised BugTaskFlat inserts are still performing OK, with 63 indices.
[10:24] <wgrant> Although I guess most of them are very partial.
[10:25] <stub> Launchpad is very low write.
[10:25] <stub> And PG has been optimized over decades :)
[10:25] <wgrant> Indeed.
[10:25] <wgrant> Speaking of which, when can we upgrade to 9.2? :)
[10:25] <wgrant> Index-only scans ftw.
[10:26] <stub> It will take a while with librariangc and apache-log-parser running
[10:26] <stub> wgrant: Sometime after it is released I think.
[10:26] <wgrant> Bah
[10:26] <wgrant> Live a little.
[10:51] <gary_poster> wgrant, hey.  it looks like the sampledata change breaks a lot of tests.  The parallel runner shows 197 errors (http://ec2-23-20-37-133.compute-1.amazonaws.com:8010/waterfall) and the standard one shows 6 so far (https://lpbuildbot.canonical.com/waterfall)
[10:56] <gary_poster> actually the errors seem very different
[10:56] <gary_poster> http://ec2-23-20-37-133.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/4/steps/shell_8/logs/summary
[10:56] <gary_poster> vs.
[10:56] <gary_poster> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/2054/steps/shell_6/logs/summary (which is, wow, hard to read)
[10:58] <gary_poster> lp.codehosting.puller.tests.test_scheduler.TestPullerMasterIntegration causes everything to fall over in the official buildbot
[10:58] <wgrant> gary_poster: Odd, I've had two ec2 runs with those revs without a problem.
[10:58] <wgrant> The production thing looks unrelated.
[10:58] <wgrant> It's just normal flakiness
[10:58] <wgrant> Looking at parallel
[10:59] <wgrant> That looks unrelated as well
[10:59] <gary_poster> wgrant, agreed.  sorry for bothering you; I saw the seeming correlation and assumed.
[11:00] <wgrant> Quite a reasonable assumption... it's a more spectacular failure than we normally see spuriously :/
[11:00] <gary_poster> heh, yeah
[11:00] <wgrant> Worrying.
[11:01] <gary_poster> we'll look into the ones we encounter on parallel.  As you probably saw, I forced a build on parallel, so hopefully that will show a green build
[11:01] <wgrant> Well
[11:01] <wgrant> TBH I hope it fails the same way :)
[11:02] <wgrant> Having 200 spurious failures like that is ungood.
[11:02] <gary_poster> Well, we generally file a bug and try to fix them anyway, if we can.  Sometimes it's harder to dupe than others.
[11:02] <wgrant> Yeah.
[11:14] <wgrant> stub: Thanks.
[12:14] <bac> morning adeuring
[12:23] <bac> adeuring: i'm going to start on wgrant's review
[12:25] <adeuring> bac: ok (and good morning :)
[12:25] <wgrant> Thanks bac.
[13:32] <rick_h_> deryck: ping for stand up party time
[13:32] <deryck> rick_h_, yup, on the way, thanks
[13:57] <noodles785> Hi! Do the production LP updates happen at specific times during the day?
[14:02] <rick_h_> noodles775: no, they occur as they're ready to go usually
[14:03] <noodles775> k, thanks rick_h_
[14:04] <rick_h_> noodles775: has some info https://dev.launchpad.net/LEP/FastDowntime
[14:07] <abentley> rick_h_: I'm getting "ImportError: No module named convoy.meta" http://pastebin.ubuntu.com/981754/
[14:09] <rick_h_> abentley: your download cache is up to date?
[14:09] <abentley> rick_h_: yes.
[14:09] <rick_h_> sorry, mean your deps, it's in the lp ppa
[14:11] <abentley> rick_h_: I'll check.
[14:12] <rick_h_> abentley: yea, looking for the -deps
[14:12] <rick_h_> abentley: looks like it's in apt-cache show launchpad-developer-dependencies
[14:12] <abentley> rick_h_: Not seeing convoy listed by apt-get upgrade.  I do see other LP deps.
[14:13] <rick_h_> abentley: it's listed as python-convoy if that helps at all
[14:16] <czajkowski> morning
[14:23] <abentley> rick_h_: looks like I had uninstalled launchpad-developer-dependencies.
[14:23] <rick_h_> abentley: ah ok. Yea, debugging here, I've got some many copies floating around with dev version, pypi versions, etc
[14:51] <abentley> allenap: How does with-xvfb compare to xvfb-run?
[16:45] <rick_h_> jcsackett: ping, so is the issue with the dupe banners a matter of cleaning up the creators of banners is a pita?
[16:45] <rick_h_> jcsackett: one other way to do the single method is to stick a variable in the module file and to store the $node so you don't have to query again.
[17:00] <jcsackett> rick_h_: oh, i like the idea of just storing the node.
[17:01] <jcsackett> although, come to think of it, that won't actually work.
[17:02] <rick_h_> jcsackett: yea, I started thinkering in a branch but it's a bit messier
[17:02] <rick_h_> you'd have to store a dict key'd by the class.NAME
[17:02] <rick_h_> but then it looks funky when you pull it out and .set(text)
[17:02] <rick_h_> and I don't have a full view of the scope so I'll just shush
[17:02] <jcsackett> rick_h_: well, and there's still the problem of what happens if a banner object is created in another module.
[17:03] <jcsackett> like, there's a banner created in the js in base-layout-macros on any private page.
[17:03] <rick_h_> right, but this is tracked in the YUI.add() so there's only one
[17:03] <rick_h_> you can stick 'private' vars inside that .add() code
[17:03] <rick_h_> just how var ns = Y.namespace... each module has that ns. and it's a single value for all of that module definition
[17:04] <rick_h_> no matter where it's used/messed with
[17:04] <jcsackett> rick_h_: ah, got it.
[17:04] <jcsackett> i think when i read "in module" i thought "in class".
[17:04] <rick_h_> but yea nvm...forget me. Ugh on the need to deal with it, but understand
[17:04] <rick_h_> right, no I mean in module
[17:04] <jcsackett> rick_h_: yeah, it's still not perfect, but it's better.
[17:04] <jcsackett> sometimes i'll take better. :-)
[17:04] <rick_h_> a module can contain private stuff, mutliple classes, etc
[17:04]  * jcsackett nods
[17:05] <rick_h_> anyway, sorry I stuck my nose in it, my curiosity got peaked
[17:05] <jcsackett> all good. you didn't happen to read enough of the MP to vote "approve" on it, did ya? :-P
[17:05] <rick_h_> yea, I guess I'm there might as well eh
[17:05] <jcsackett> *i* certainly wouldn't mind. :-)
[17:06] <jcsackett> and i'm sure bac would be happy to let someone else help clear out active reviews. :-P
[17:06] <rick_h_> k, sec, will do
[17:13] <rick_h_> jcsackett: ok, approved with comments
[17:13] <jcsackett> thanks, rick_h_.
[17:34] <sinzui> bac ping
[17:35] <bac> hi sinzui
[17:36] <sinzui> bac , have you looked at https://code.launchpad.net/~dooferlad/launchpad/upcoming_view_show_all_work_items/+merge/105495 yet
[17:36] <bac> sinzui: no
[17:37] <sinzui> bac: I just investigated it. I will take it
[17:37] <bac> sinzui: ok.  do you know what happened to wgrant's branch?
[17:38] <sinzui> The one replaced methods to create fast queries of new bugs?
[17:38] <bac> sinzui: ah, i see you got to it.
[17:38] <bac> i got tied up before lunch.  thanks for handling it
[17:38] <sinzui> I did. He made some changes for me and merged it 30 minutes later
[17:38] <bac> cool
[18:00] <lifeless> morning
[18:18] <rick_h_> jcsackett: thanks for giving that a shot, sucky it didn't help
[20:18] <lifeless> flacoste: ping; any chance of a quick call ?