[00:05] Yeah, I knew it would be bad, and we've been down some IS staff here for the last couple of weeks, otherwise I would have done it myself. [00:05] Thanks :) [00:12] StevenK: https://code.launchpad.net/~wgrant/launchpad/builderinteractor-updateBuild/+merge/182600 [00:44] wgrant: So there's no code changes, just moving it? [00:46] StevenK: Apart from porting TTBB to override handleStatus instead, yeah. [00:47] Otherwise it's basically just s/self._interactor/self/ [00:49] wgrant: r=me with a small niggle [00:50] Commenting circular imports is pointless. [00:50] I've never understood why we do it [00:50] Need to know whether an import is circular? If it's inside a function, it's circular. [00:51] Need to find all circular imports? bzr grep '^\s+import' [00:54] True. But currently, we tend to comment on them. [00:54] It might become more reasonable if we have a sane code structure such that they don't appear in almost every file. [00:55] That would be nice. [00:55] But now you can barely read a notable function without seeing at least one, so commenting them is silly. [00:56] Right. [00:57] wgrant: How about http://paste.ubuntu.com/6038589/ as a refactoring of the Sources/Packages path handling in series-alias (untested, but general idea)? It's more LOC than before, but perhaps that's worth it. I'm on the fence. [00:57] I thought about making it a method on the publisher config. Not sure about that. [00:58] cjwatson: I think that's clearer. I think having them as functions is fine. [00:59] I like keeping the path joining and string formatting rules in one place [00:59] * cjwatson sets the archivepublisher tests going and really goes to bed, then [00:59] Thanks [00:59] Thanks, and night [02:47] wgrant: excellent downtime announcement email BTW. I saw one from Microsoft the other day and the difference is palpable. [03:00] I think our announcements win simply by not quoting the times in some random timezone [03:00] Particularly when someone quotes an outage time in PST when they actually mean PDT... [03:00] Seriously? [03:00] It's a bit like that ad a friend spotted in late 1999... [03:00] Yeah, Americans don't do timezones, even their own. [03:01] "Even in the year 2000 we will be there for you 365 days." [03:01] Heh [03:02] He was itching to call them and ask: given that 2000 is a leap year, and surely you have dealt with Y2K bugs such as mistaking it for a non-leap year, which day will you be unavailable?" [03:02] * jtv was sad to discover at a quiz that only one other contestant knew how to calculate leap years [03:05] Doubly sad: one, a room full of teachers was largely unaware; and two, there was the bare minimum of awareness to rob our team of that 1-point advantage. [03:07] Well, everyone'll hopefully learn by 2100 :) [03:07] They'd better! [03:08] Loved that Sun joke at the time... "Y5K bug (or whatever the number was) discovered in Java. A team at Sun is reportedly rushing to fix the problem." [04:21] StevenK: https://code.launchpad.net/~wgrant/launchpad/builderinteractor-cookies/+merge/182813 https://code.launchpad.net/~wgrant/launchpad/axe-the-ibb/+merge/182814 [04:54] wgrant: r=me for both [04:55] StevenK: Thanks. [04:57] Nearly disentangled. === jam1 is now known as jam [05:01] wgrant: One more branch [05:01] ? [05:02] I've got one more branch of cleanups, and then I think I can start pulling the DB dependencies up. [05:03] That mostly involves heavily caching a few builder attributes and the slave build cookie. [05:03] and then a SlaveScanner should be able to handle most operations other than the start and end of a build without touching the DB. [05:03] So its another 3 or 4 branches, right [05:03] And I will have succeeded in stopping the commits. [05:03] Something like that. [05:07] wgrant: So why was there an IBB, that's what I can't understand [05:08] StevenK: BuildFarmJobBehavior used to have updateBuild etc. on it [05:08] Including updateBuild_IDLE [05:08] Every scan would go through to a BFJB. [05:09] And the BFJB could do with the result whatever it wanted. [05:09] But nothing ever overrode anything except updateBuild_WAITING, and I don't want to have to create a BFJB from the DB for every scan. [05:09] So I moved those general methods up into the new BuilderInteractor. [05:09] In related news, https://code.launchpad.net/~wgrant/launchpad/direct-action/+merge/182818 [05:10] It sorta made sense back in 2009 when it was designed, as not everything was going to have a BuildFarmJob. [05:11] So the original TTBJ implementation overrode a couple of the others. [05:11] But that's long fixed. [05:13] StevenK: Do you vaguely see what I'm working towards here? [05:15] BuilderInteractor will cache enough information to do normal scans without hitting the DB. A single new worker in buildd-manager will scan the DB every n seconds and update all the cached information on each SlaveScanner's BuilderInteractor, and another new worker will grab the logtail from each SlaveScanner and flush them all to the DB at once. [05:31] wgrant: r=me [05:31] Thanks. [11:30] wgrant: I don't suppose you fancy canonicalising the spelling of "behaviour" in your buildmaster rearrangements? :-) [11:30] * cjwatson was just bitten by that again [11:31] cjwatson: I think I've been consistent, but I will happily switch to the real spelling now that we've exterminated the Americans :) [11:32] Though knowing my luck that will cause lots of extra lines to wrap, giving me a good excuse to rename current_build_behavior to something less silly too. [12:04] cjwatson: That branch will fail with devel merged [12:04] The middle argument to handleStatus is gone. [12:04] (it was an ILibrarianClient that hadn't been used in 3 years) [12:08] I'd better merge devel into buildmaster-cancel-properly then [12:10] It won't conflict with that [12:10] As the new handleStatus was added in the branch you landed a couple of weeks ago. [12:12] Yeah. Fixed now. === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha