[02:57] <thumper> mwhudson: care to take a look at a change for me?
[02:58] <thumper> mwhudson: it is in resposne to BjornT's comments on the job runner oops tests
[02:58] <thumper> mwhudson: I'd feel happier if someone else took a look at the changes before I submit
[02:58] <mwhudson> thumper: ok
[03:04] <thumper> mwhudson: I've replied to the original review with a diff, which you should get
[03:05] <thumper> RSN
[03:06] <thumper> hmm, a spike in scanner load?
[03:07] <thumper> my branch isn't being scanned
[03:07] <thumper> heh
[03:07] <mwhudson> it's the distro branches
[03:07] <thumper> yeah
[03:08] <thumper> mwhudson: you should see the email now
[03:13] <mwhudson> yep
[03:29] <thumper> mwhudson: what oops related apis?
[03:30] <mwhudson> thumper: getLastOopsReport, maybe?
[03:30] <thumper> mwhudson: it is still used
[03:30] <mwhudson> oh ok
[05:13] <jtv> mwhudson, are you free for a tiny but urgent review?  https://code.launchpad.net/~jtv/launchpad/bug-572497/+merge/24514
[05:15] <jtv> Hmm... why isn't that diff updated?
[05:15] <mwhudson> jtv: the diff isn't updated yet, probably because the scanner is behind with all the new distro branches
[05:16] <jtv> mwhudson: all I did was make the unit tests that exercise the failing code switch to the right db user.  Maybe the diffs should be updated SJF.  :-)
[05:17] <mwhudson> jtv: well it generally sounds fine to me
[05:17] <mwhudson> (apart from 'fiera' being a terrible username)
[05:18] <jtv> Yes, but it made me use the config instead of a hard-coded name.  :)
[05:52] <jtv> mwhudson: at last, my diff has updated!
[05:55] <mwhudson> jtv: approved
[05:55] <jtv> mwhudson: ta
[08:41] <noodles775> intellectronica: /w 4
[08:42] <noodles775> hrm... sorry intellectronica, I meant to say, very simple RC MP if you've got a minute: https://code.edge.launchpad.net/~michael.nelson/launchpad/ppa-deletion-oops/+merge/24580
[08:43] <noodles775> Or anyone else who fancies a simple review ^^ :)
[08:44] <thumper> noodles775: You'll probably find the diff takes many hours to generate as the scanner tries to catch up with 36k branch scans
[08:44] <thumper> due to mavrick
[08:44] <thumper> noodles775: I suggest pastebin
[08:44] <noodles775> thumper: thanks, doing so now.
[08:44] <thumper> please pass the information on to the europeans
[08:45] <thumper> I expect the scanner to catch up sometime in the next day or two :-|
[08:45] <thumper> good thing we've fixed this for next time
[08:45] <noodles775> And here's mine: http://pastebin.ubuntu.com/426871/
[08:47] <thumper> noodles775: I'd strip the _bug_574246 from the method name
[08:47] <thumper> noodles775: but other than that r=me
[08:47] <noodles775> thumper: Done.. thanks :)
[08:51] <noodles775> BjornT: when you've time, a simple RC: https://code.edge.launchpad.net/~michael.nelson/launchpad/ppa-deletion-oops/+merge/24580
[08:54] <BjornT> noodles775: approved
[08:55] <noodles775> BjornT: Ta.
[09:48] <thumper> jml: ping
[14:52] <leonardr> abentley, can you review https://code.edge.launchpad.net/~leonardr/lazr.restfulclient/delete-entry/+merge/24421 ? diff is in mp
[14:52] <abentley> leonardr, okay.
[14:53] <abentley> leonardr, what happened with your Vary header branch?
[14:53] <leonardr> abentley: i was able to land it on thursday
[14:54] <abentley> Cool.  I'm eager to see how my lp clients perform with that changed.
[15:01] <abentley> noodles775, your branch looks okay on its own merits, but it is part of an effort that I am concerned may duplicate or contradict our own efforts.
[15:02] <noodles775> abentley: ok, good to know... in what way?
[15:02] <abentley> noodles775, well, I want to have a system that provides an overview of jobs that are running, have run, etc.  I termed it the "Job console".
[15:04] <noodles775> Aha (btw: we're not getting rid of the link to services.job with this work, contrary to the diagrams).
[15:04] <abentley> This seems to be basically the same goal as https://dev.launchpad.net/LEP/GeneralBuildHistories
[15:05] <abentley> I tried to start an LEP for it a couple of  months ago, but jml decided we don't need that feature yet.
[15:05] <abentley> I am glad that the link to Job hasn't been severed.
[15:05] <noodles775> abentley: I think it might be different... this is just ensuring that in the context of a PPA, we can show different types of builds (binary, recipe etc.)
[15:06] <noodles775> There may be convergence in the future though... currently what I see happening after this current work:
[15:06] <noodles775> 1) getting rid of our special tables that link 'builds' to services jobs and instead just having a reference to the job directly from BuildFarmJob, and then:
[15:06] <abentley> noodles775, the LEP discusses using the context of the builders
[15:07] <noodles775> 2) eventually merging as much of BuildFarmJob off (as it duplicates what you've already got on Job).
[15:07] <noodles775> abentley: yes, sorry, and teh buildmaster builders context.
[15:08] <abentley> noodles775, But we already have a display in the context of the builders, and I'm working right now on a home page for individual sourcepackagerecipe builds.
[15:08] <noodles775> (but (1) and (2) are just speculation on my part atm., the current focus is just to enable general builds to display in those contexts).
[15:08] <noodles775> abentley: a display that presents both binary and recipe builds batched together?
[15:08] <abentley> noodles775, yes.  AFAICT, It Just Works.
[15:09] <noodles775> Where can I see it?
[15:09] <abentley> noodles775, dogfood.
[15:10] <noodles775> abentley: hrm, which branch should I merge in?
[15:11] <abentley> I don't think you need to merge anything in.  When I started creating sourcepackagerecipe builds, they just started showing up in that listing.
[15:11] <noodles775> abentley: I expected them to show up in this listing: https://edge.launchpad.net/builders
[15:12] <noodles775> but am surprised that they've shown up in the build history: https://edge.launchpad.net/builders/rothera/+history
[15:12] <noodles775> as it currently is a list of Soyuz binary package builds afaik.
[15:14] <abentley> noodles775, it seems like the results of my earlier experiments on dogfood have been destroyed, so I can't be certain either way, but that's what I recall.
[15:15] <noodles775> abentley: the results will still be there, I just had to disable the config as per email, because it was expecting a SourcePackageRecipeNavigation class which isn't present in db-devel?
[15:15] <noodles775> (which is why I assumed a branch needed to be merged in that includes that class?)
[15:17] <abentley> noodles775, Yes, Julian had merged in my recipe-build-index branch.
[15:17] <noodles775> (it could just be that it was renamed to SourcePackageRecipeNavigationMenu and the config on dogfood hadn't been updated?)
[15:17] <noodles775> Ah.
[15:20] <noodles775> abentley: if you look at lib/lp/soyuz/browser/builder:BuilderHistoryView and follow it, you'll end up at IBuilder.getBuildRecords() which currently returns IBinaryPackageBuildSet.getBuildsForBuilder() (ie. only soyuz binary builds), so I'm guessing what you saw was just https://edge.launchpad.net/builders displaying your recipe builds (which I'd hoped Just Worked and am glad it did :) ).
[15:22] <abentley> Okay.
[15:25] <abentley> So you suggested that my Job Console and your General Build History are different because the build history is filtered by PPA or Builder context.
[15:26] <abentley> I think that the filtering isn't terribly important.
[15:27] <abentley> I have no problem imagining filtering the Job Console per builder or per archive.
[15:28] <abentley> The Job Console meant to be filterable by branch, and General Build History would fall down a bit there, because it would show only Jobs that were also Builds.
[15:30] <abentley> noodles775, so I see the Job Console as a more general idea.  I would hate for us to end up with duplicate systems: a Job Console and a "Job Console for Builds".
[15:32] <noodles775> abentley: no, I was thinking they were different because currently (in devel/db-devel), builds have nothing to do with service jobs. They are only temporarily related while they are queued.
[15:33] <noodles775> The generalised build history doesn't change that, it is just refactoring all the common info on the different build classes, so that a builder .... actually, do you mind calling? It might be easier to find out where the convergence might be?
[15:33] <abentley> noodles775, sure.
[15:35] <abentley> noodles775, did you mean Skype?
[15:35] <noodles775> abentley: yep, just call when ready.
[15:35] <abentley> noodles775, I am ready, but I don't see you online.
[15:36] <noodles775> Skype lag ;)
[15:55] <noodles775> abentley: https://code.edge.launchpad.net/~michael.nelson/launchpad/db-build-generalisation-db-changes/+merge/22527
[16:30] <abentley> noodles775, could distro_series go on IPackageBuild instead of IBinaryPackageBuildView?
[16:33] <noodles775> abentley: it's based on the db-column, BinaryPacakgeBuild.distro_arch_series?
[16:34] <abentley> noodles775, it's a field that SourcePackageRecipeBuild and BinaryPackageBuild will have in common.
[16:35] <abentley> noodles775, of course, the implementation on SourcePackageRecipeBuild will not be based on distro_arch_series.
[16:35] <noodles775> Well, SPRecipeBuild has a db-column for distro_series, where as BinaryPackageBuild has a db-column for distro_arch_series.
[16:35] <noodles775> Yeah.
[16:36] <noodles775> We looked at adding distro_series to PackageBuild, but couldn't see how to do it without redundant info for a binary package build (I was chatting with Julian about it the other day).
[16:37] <noodles775> We'd thought we could instead store something on BPB that just represented "architecture", but that didn't seem right either (as it would have to be a text arch_tag, afaics).
[16:37] <abentley> noodles775, this seems to be a similar problem to the IPackageBuildDerived ones.
[16:38] <abentley> noodles775, basically, it's interfaces being limited by the implementation.
[16:45] <abentley> noodles775, diff lines 342-343 need to be re-indented.
[16:45] <noodles775> abentley: Right. So do you mean that we should provide IPackageBuild.distro_series (even if it raises NotImplementedError), and just have implementations on BPB/SPRecipeBuild?
[16:46] <abentley> noodles775, I think that would make sense.
[16:47] <noodles775> Great, will do (you'll update the MP with all this right?)
[16:47]  * noodles775 has to run out the door.
[16:49] <abentley> noodles775, Okay.
[17:02] <abentley> leonardr, what does the "lp" in lp_delete stand for?
[17:03] <leonardr> abentley: shamefully, it stands for 'launchpad'
[17:04] <leonardr> or rather, 'launchpadlib'
[17:04] <leonardr> it's a naming convention used to distinguish lazr.restfulclient (formerly launchpadlib) methods from the named operations defined by the web service
[17:05] <abentley> leonardr, I see.  If it's already established  as a convention, I'll let that be.
[17:05] <leonardr> abentley: i wish you could tell me to change it and i'd be able to change it, but it's too entrenched
[17:06] <abentley> leonardr, r=me
[17:06] <leonardr> cool
[17:07] <leonardr> i've got a wadllib branch for you in a minute
[17:41] <leonardr> can i get someone to review my and james's wadllib branch?
[17:41] <leonardr> https://code.edge.launchpad.net/~leonardr/wadllib/fix-bind-to-anon-collection/+merge/24613
[17:42] <leonardr> gary, maybe you'll take it?
[18:18] <gary_poster> leonardr: On lunch now, and a bit swamped when I get back.  Maybe I'll get a chance to look at it later today, but if you can get someone else to do it that would probably be better for you.
[18:21] <leonardr> gary, ok
[18:21] <leonardr> bac: can you do a quick review for me?
[18:24] <leonardr> or maybe barry or jml?
[18:24] <leonardr> https://code.edge.launchpad.net/~leonardr/wadllib/fix-bind-to-anon-collection
[20:02] <sinzui> flacoste, I have an RC request. BjornT agreed it was RCable. bac reviewed the change
[20:06] <flacoste> sinzui: merge proposal?
[20:06] <sinzui> flacoste, https://code.edge.launchpad.net/~sinzui/launchpad/enable-project-suggetions/+merge/24608
[20:07] <bac> flacoste: i have an RC request too.  i believe sinzui already ran it by bjorn and sinzui has reviewed it: https://code.edge.launchpad.net/~bac/launchpad/bug-574142/+merge/24625
[20:08] <flacoste> sinzui, bac: unless you already know ran it through EC2, it will have to be cherry-picked though
[20:08] <bac> flacoste: it has not been through ec2
[20:09] <sinzui> bac: flacoste: I did discuss the bug with BjornT The oopses over the weekend were caused by Edwin's landing on Friday that wrongly reverted the ProductSeries branch link
[20:10] <flacoste> sinzui: is your branch passing all tests?
[20:10] <flacoste> now, i mean
[20:10] <sinzui> flacoste, yes mine does
[20:10] <flacoste> sinzui: ok, land it now
[20:10] <flacoste> bac: your's will have to wait tomorrow