[00:03] yo [00:03] lifeless: we aren't yet. mb was unable to get to it; I've been fixing a few reds. [00:08] lifeless: any idea where https://dev.launchpad.net/PolicyAndProcess/ReleaseManagerRotation went? had a bunch of things we refer to on it. [00:09] spm: we got rid of it, no more rm [00:09] spm: this was announced [00:09] i see [00:10] what are you looking for ? [00:10] huwshimi: also i was quite curious about your thoughts on bug 800361 [00:10] <_mup_> Bug #800361: The consequences of choose an item in a picker is not obvious < https://launchpad.net/bugs/800361 > [00:10] - whether you agree with me; also whether you perhaps have some more alternatives [00:11] poolie: Thanks, I'll take a look and comment [00:12] ta [00:50] lifeless: Ah, so we *are* going for tiny DB patches now. [00:50] lifeless: I was discouraged last week from optimising below a couple of minutes :( [00:56] wgrant: yes, this has gone from discussion to action [01:06] wgrant: bug 809651 filed [01:06] <_mup_> Bug #809651: Person picker link text is confusing < https://launchpad.net/bugs/809651 > [01:08] wallyworld_: Ah, thanks! [01:09] wgrant: any opinion on what the default "Remove" text should be. I think it needs to be two words (I don't like just "Remove"). "Remove xxx" where xxx=? [01:10] maybe huwshimi has an opinion :-) [01:13] wallyworld_: Is there a problem with "Assign me" and "Remove assignee"? [01:14] huwshimi: they only really make sense in the context of assigning to bugs. what about other times were a person is chosen eg security contact for a project [01:14] or perhaps that terminology is acceptable everywhere? [01:15] wallyworld_: Ah I see [01:15] the default text for "assigning" is currently "Pick me" [01:15] but the case is wrong and needs changing, it is "Pick Me" and need sto change to "Pick me" [01:16] wallyworld_: Are we able to customise for each case (team/person etc.) [01:16] not at the moment - that would require extra code [01:17] hence the current "Remove person" is wrong sometimes :-( [01:17] wallyworld_: Hmmm... ok [01:17] wallyworld_: What's wrong with extra code? [01:17] but if the desire is to have "Remove person" and "Remove team" depending on whether the current value is a person or team we could do that i'm sure [01:18] huwshimi: nothing wrong, just saying we don't currently support it in the current implementation [01:18] huwshimi: so "Remove person" and "Remove team" would be ok? [01:18] wallyworld_: To me that makes the most sense [01:19] wallyworld_: I would talk to mrevell as well though as this is his area [01:20] huwshimi: ok. i think it makes sense too. i'll look at doing something assuming we will go ahead. feel free to comment on the bug if you decide something after talking [01:20] oh, i can ask him too [01:20] s/too/instead [01:22] * wallyworld_ hates qastaging timeouts occuring *every* time a link is clicked :-( [01:23] wallyworld_: means there is slow code there [01:23] lifeless: but even qastaging.lp.net itself just timedout [01:23] exactly my point [01:23] it happens all the time, for just about any page [01:24] surely *all* of lp pages are not slow [01:24] the same pages work fine on lp.net [01:24] 87 queries/external actions issued in 2.10 seconds - hot qa.l.n [01:25] actually, medium, 0.26 hot hot [01:25] still -slow- [01:25] i got this after initially timing out and hitting refresh: 98 queries/external actions issued in 8.25 seconds [01:25] yup, slow [01:25] -way- too many queries [01:25] but the figures are waaay less on lp.net [01:26] yes, it has a 128GB disk cache [01:26] not the query count, the execution time [01:26] so you saying the only reason lp.net even runs is the huge cache? [01:26] yup [01:26] :-( [01:38] wallyworld_: sorry, I was OTP before [01:38] wallyworld_: LP is broadly inefficient, we are getting better. [01:38] wallyworld_: an efficient frontpage would be 4 queries + a memcache lookup for the blog posts [01:39] wallyworld_: we are doing *twenty times* that work. [01:40] wallyworld_: qastaging has 32GB of ram shared between *three* LP db instances, each of which is 300GB in size [01:43] Are we are are we not still in RC? [01:43] we should be out of rc [01:45] I don't believe we are. [01:54] Can't stop using 'utilities/ec2 land', but to check on my instances I run 'bin/ec2 ls' [01:54] I'd drop the symlink, but I suspect I'd get lynched. [01:55] are there docs on creating lazr projects anywhere ? === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 220 - 0:[######=_]:256 [01:56] lifeless: Why, so you can delete them? :) [01:57] fold-in :) [01:58] wallyworld_: Did you intend to delete a couple of dozen JS test? [01:58] wgrant: yes, they were duplicated [01:58] flacoste: huh, we missed some lazr components in the move to lp - smptptest, publisher, authentication amongst others, I think [01:58] they were moved and a rollback put them back to the original place [01:58] Ah, great. [01:59] lifeless: At least publisher and authentication were never used, IIRC. [01:59] by anyone? [01:59] And canonicalurl and a couple of others that I don't recall. [02:00] They were just placeholder projects. [02:00] lifeless: sounds like a major part of the perf issue on qas is that it's running 3 db instances in 1/4 the memory [02:00] grah, so we need to delete them [02:00] Oh, they have code now. [02:00] wallyworld_: its part of it yes; but our pages generally touch - way - more data than needed. [02:00] When did that happen... [02:01] lifeless: agreed. but still, stuffing 3 db instances into so little memory.... [02:01] wallyworld_: indeed; things will get better once we can drop staging [02:01] will get us down to 2 instances [02:01] I am amused that 32GiB is 'so little memory' [02:02] epsecially since no-one could possibly need mnore than 640kb [02:02] lifeless: Ah, that's right. lazr.canonicalurl and lazr.publisher have branches, but they are just empty lazr templtes. [02:02] wallyworld_: for now, you need to try any page on qa staging at least 3 or 4 times [02:02] lifeless: lazr.authentication is real. [02:02] yes :-( [02:02] wallyworld_: but you *cannot* assume that timeouts on [qa]staging are not a problem for prod [02:02] wallyworld_: there was a thread on this a couple weeks back on -dev [02:02] sure, that lesson was mentioned at the epic :-) [02:19] lifeless, +1 to emeritii [02:30] lifeless: thanks for making me open a dictionary [02:30] wallyworld_: de nada! [02:30] i was hoping (expecting?) that we would do such a thing [02:30] look in dictionaries ? [02:31] lp is hard enough as it is without all that combined knowledge walking out the door [02:31] lifeless: no, the team thing you emailed :-) [02:31] :P [02:37] wallyworld_: dict(1) ? [02:38] StevenK: i used google [02:38] :-P [03:13] https://dev.launchpad.net/CreatingNewProjects could use a proof read [03:38] Is there a workable YUI3 calendar yet? [03:38] This embedded copy of YUI2 irks me. [03:41] wgrant: ^ thats what I wanted existing docs for [03:41] Looking. [03:45] lifeless: Looks reasonable, although you don't seem to discourage namespace packages. [03:49] wgrant: I figure most folk know the terrible pain [03:49] wgrant: perhaps I should add some notes to that effect [03:49] lifeless: You figure incorrectly. [04:07] wallyworld_: How do I get a traceback from a YUI test failure? [04:16] wgrant: not easily afaik [04:16] i normally stick in a breakpoint just before [04:16] the failure and poke around from there === nigel is now known as nigelb [05:09] Does anybody know where SystemErrorView is tested? [05:11] It doesn't look to be tested. [05:11] From a quick bzr grep [06:31] stub: hi [06:31] stub: I found a new bug for the fastdowntime - dealing with landed but not deployed db patches [06:31] stub: I think we want to avoid causing a pipeline-halt on appserver deployments [06:39] lifeless: What is the problem? launchpad/devel & launchpad/db-devel split handles that doesn't it? [06:40] We rollout launchpad/devel everywhere except the databases. We rollout db-devel to the databases, and merge it into /devel after the rollout. [06:48] stub: thats probably a decent day one answer, letting the bug go to back burner [06:48] stub: It seems to me that eventually db-devel probably wants to be either 'big downtime' patches only, or to be dropped altogether === mthaddon changed the topic of #launchpad-dev to: Launchpad down/read-only from 08:00-09:30 UTC for a code update | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 220 - 0:[######=_]:256 [07:04] spm: That's not leakage. [07:04] It's cache. [07:06] 18:31 < lifeless> stub: I think we want to avoid causing a pipeline-halt on appserver deployments [07:06] 18:39 < stub> lifeless: What is the problem? launchpad/devel & launchpad/db-devel split handles that doesn't it? [07:06] 18:40 < stub> We rollout launchpad/devel everywhere except the databases. We rollout db-devel to the databases, and merge it into /devel after the rollout. [07:06] 18:48 < lifeless> stub: thats probably a decent day one answer, letting the bug go to back burner [07:06] 18:48 < lifeless> stub: It seems to me that eventually db-devel probably wants to be either 'big downtime' patches only, or to be dropped altogether [07:08] Yup. Tackle the landing workflows as a separate problem. [07:09] We can avoid the split if upgrade.py is smarter, being able to apply just the live patches or the live + heavy patches, and having buildbots run the test suite against both schemas. [07:11] k, how about fastdowntime2 or something as a tag for 'later' items ? [07:12] Sure, although technically how we land stuff doesn't affect downtime at all. Its just a developer time saver. [07:16] Won't this obfuscate code changes that depend on "big downtime" patches? [07:17] stub: well, given that that (dev efficiency) is ultimately why we're doing this :) [07:17] jtv: ideally there will be no big downtime patches [07:18] jtv: as of today they require signoff by me / flacoste [07:18] Yer, but a nice split means smaller solvable projects. No need to pile them together in a big project. [07:18] stub: agreed [07:18] stub: pick a tag name for the $next-piece ;) [07:22] landing-workflow [07:23] Or as it is probably a standalone bug, no need for a tag. [07:24] stub: I'd like to be able to find them later; its tightly related to the downtime thing - I was suggesting to remove the fastdowntime tag so its not in the burndown for the inital feature [07:25] Sure [07:25] Are these milestones? [07:27] stub: mmm, more we have a single large theme, and stages of work [07:28] stub: of which right now we know 'step 1' and 'not step 1' ;) [07:28] Two moving milestones - stuff to do now, stuff to do later :) [07:29] sure; though milestones are heavier. Lets stay with tags for now ? [07:30] I've given it fastdowntime-later [07:30] if we find all the later stuff is landing workflow, I'll take the bullet for updating the labels === jtv changed the topic of #launchpad-dev to: Launchpad down/read-only from 08:00-09:30 UTC for a code update | https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugs: 220 - 0:[######=_]:256 [07:34] good morning [07:37] morning [08:11] Project devel build #882: FAILURE in 6 hr 0 min: https://lpci.wedontsleep.org/job/devel/882/ [08:11] Project devel build #883: STILL FAILING in 0.8 sec: https://lpci.wedontsleep.org/job/devel/883/ [08:21] Hello === almaisan-away is now known as al-maisan [08:28] hi mrevell [09:15] bigjools: you'll appreciate this; just got the human stopwatch trophy :) [09:15] lifeless: it's easy :) [09:16] bigjools: I figured it would be hard - and wasn't trying for it :) [09:16] lifeless: karts FTW :) [09:16] heh, i was in ? daytona superspeedway? the big O course, in a formula one car [09:17] ah yeah that's the other easy way [09:17] lifeless: tune the F1 car so it's got almost no wing on that track [09:26] bigjools: yeah, I was topping out at 358kph, and maintained that on the corners === mthaddon changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugs: 220 - 0:[######=_]:256 [09:53] thanks mthaddon, and hi :) [09:53] o/ === henninge_ is now known as henninge === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [10:39] henninge: Isn't IDiff['diffstat'] clearly wrong, making this a trivial fix? [10:39] wgrant: what do you mean? [10:40] henninge: It's a dict, not text... [10:40] So IText is not right. [10:40] wgrant: what I mean [10:41] t [10:41] wgrant: I was just wondering if the interface can be changed like that, the whole thing about api consistency. [10:42] but obviously nobody has been using this as text or else it would have been noticed earlier. [10:42] Exactly. [10:42] ok [10:43] easy fix then, I just hope we don't hit any more of these. === jam1 is now known as jam === almaisan-away is now known as al-maisan === danilo_ is now known as danilos === matsubara_ is now known as matsubara [12:42] jtv: still around? [12:42] yes [12:42] got an MP for me? [12:42] I think you've earned a review, what with all the ones you do for me. :) [12:42] jtv: yes, a small one: https://code.launchpad.net/~adeuring/lazr.batchnavigator/short-read-for-backwards-batch/+merge/67823 [12:42] Coming up. === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv, danilos | Critical bugs: 220 - 0:[######=_]:256 === dobey_ is now known as dobey === mrevell_ is now known as mrevell [13:08] henninge: I don't understand why the fact that IDiff.diffstat is a serialized dict breaks the marshaller. A serialized dict is text... [13:08] abentley: because it is not [13:08] it is just a dict. [13:09] See the implementation. [13:09] henninge: Ah, it's wrongly-exported? [13:09] well, it is stored as a json string in the database but the model implements an attribute that de/serializes it. [13:10] so that implementation does not match the interface anymore, hence the wrong export. [13:10] abentley: I have to run to the doctor's now. ttyl [13:10] henninge: ttyl [13:33] deryck: Hi! [13:33] deryck: I am here but on 3G so no voice ... ;( [13:33] henninge, no worries. [13:35] abentley, http://developer.yahoo.com/yui/3/api/ArrayAssert.html#method_isEmpty [13:37] Once more we require a library to makeup for the deficiencies of the language. [13:42] sinzui: one measure of a language's strength is the degree to which that is possible. [13:42] granted [13:43] henninge, I've seen your mail and the card move.... looks like the obfuscated email work is on track to land now? [13:56] nice blog post mrevell! [13:57] bac, Thanks. I thought it was about time to announce :) [14:06] sinzui: you available to chat? [14:07] yes. I will start mumble? [14:07] sinzui: sure. === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv, danilos, abentley | Critical bugs: 220 - 0:[######=_]:256 [14:07] jtv: still OCR? [14:11] yes, abentley, still OCR! [14:11] adeuring: not getting a diff for your branch at all. :( I'll go for manual. [14:12] jtv: I guess you're not on Thailand time right now? [14:12] No. [14:12] jtv: yeah, seems that LP is a bit slow today.... [14:13] Oh, it may have got caught in the release of course. [14:13] * deryck is switching offices, back online in 20 minutes [14:14] adeuring: no, it seems that something's wrong with the script that does those diffs. [14:17] adeuring: oh well, I just looked at the diff. Done. [14:17] jtv: cool, thanks [14:31] mrevell, sorry :( I spent my morning getting my computer to work. I can talk now if you like [14:32] bigjools: I noticed that process-accepted commits its changes, in its inner loop, even in a dry run. Accident? [14:34] is it supposed to be downtime right now? [14:35] I have a merge-proposal page that hasn't updated for 45 minutes +, and I tried to link a branch to a bug and it timed out after 9s. [14:35] jam: problem with the MP diff script, apparently. [14:37] Although… I just got a timeout as well. [14:38] jtv: the last status updates I see are "degraded performance" followed by "performance should be back to normal" [14:38] (from 45min ago) [14:38] I don't know if what I'm seeing is just long-term fallout [14:38] or whether something is still broken [14:39] jtv: there's an outer abort though right? [14:39] bigjools: yes, but that won't help much if the inner loop's already committed. :) [14:39] I just succeeded in linking the branch, but it took 4.27s [14:39] jtv: doesn't the partial commit get aborted? [14:40] There is no partial commit — not without 2-phase, which we don't use. [14:40] Commit is commit. [14:40] jtv: :/ [14:40] then it's borked [14:40] At least it's good to see my design decisions for libpqxx justified. [14:40] jtv: although we don't use dry run for anything [14:40] Well, it's fixed now. Up for review. [14:40] cool [14:40] (I needed some cleanups before I could confidently mess with the script) === al-maisan is now known as almaisan-away [14:43] I hate it when I see bugs in a security adapter [14:43] bac, flacoste -- hi, Sumana here asking whether a blog entry about Launchpad's code review process is in the works. flacoste I think you said you & Brad are working on it? [14:43] (or rather that bac is working on it) [14:43] sinzui, Does 15 minutes from now suit you? [14:43] sumanah: i have it on my todo list. :( [14:44] mrevell, yes [14:44] sumanah: i will try to set aside time on friday to do it. [14:44] bac: if I interviewed you, would that help? [14:44] sumanah: i'd like to talk to you some time! [14:44] thanks bac -- we in #mediawiki are looking forward to hearing about your example before a code review training on Tuesday [14:45] bac, Francis's email was very useful but graphs would be even better :) [14:45] sumanah: maybe we can talk tomorrow? [14:45] bac: ok! and I'd also love any documents about how Canonical people train each other in code review -- if you ask reviewers to write down any lessons learned about how to teach/learn how to code review, I would be very enthusiastic to read them. [15:01] flacoste, for bug 777874, can we regard that policy ("If a new bug, has >2 duplicates associated with it, or >2 people have indicated that this bug affects them, then automatically mark it confirmed.") as vetted and approved for all Launchpad users, or should addressing the bug include trying to confirm whether it is appropriate, or considering how to make it configurable/choosable? [15:01] <_mup_> Bug #777874: If multiple reports on new bug, mark it confirmed

< https://launchpad.net/bugs/777874 > [15:02] all Launchpad *projects [15:07] matsubara, bug 803996 and bug 283167 [15:07] <_mup_> Bug #803996: person picker widget doesn't show link to unassign myself

< https://launchpad.net/bugs/803996 > [15:07] <_mup_> Bug #283167: Private branch owner cannot unsubscribe someone

< https://launchpad.net/bugs/283167 > [15:11] Yippie, build fixed! [15:11] Project devel build #884: FIXED in 5 hr 29 min: https://lpci.wedontsleep.org/job/devel/884/ [15:30] mrevell, I saddled you with https://answers.launchpad.net/launchpad/+question/164474 . If you'd rather me kick it somewhere else, let me know (and a suggestion would be lovely :-) ) [15:31] * gary_poster mixes metaphors blithely === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos, abentley | Critical bugs: 220 - 0:[######=_]:256 [15:33] abentley, while we're on the subject, care to review one of mine? https://code.launchpad.net/~jtv/launchpad/bug-676103/+merge/67852 [15:33] gary_poster, :) I'll take a look now. [15:33] jtv: sure. [15:33] thanks. [15:37] gary_poster: consider it vetted and approved, but you might want to feature flag it ;-) [15:37] gary_poster: Ubuntu wants it for sure [15:40] we might need some more scope controller: project:name [15:40] I get search warnings, if I ignore them, I can't see the failures :( [15:40] err, sorry [15:40] wrong channel [15:45] mrevell, thanks :-) [15:45] flacoste, ack, makes sense, thanks [15:45] np [15:46] abentley: I need to go somewhere. I expect it'll be an hour or two. === jtv is now known as jtv-afk === beuno is now known as beuno-lunch [16:08] danilo_: you win the best commit message of the year award! [16:08] flacoste: linky? :) [16:08] flacoste, heh, thanks :) [16:17] Throwing this out here, from #launchpad. It would be nice if, for a PPA, we could specify a URL to a downstream archive. This archive would be consulted whenever a package is uploaded to the PPA or copy/rebuilt. If the package with that name and version already exist downstream, the upload / copy and rebuild is rejected. The reason is to prevent package collisions before they propagate. [16:18] This may be a new way of thinking of a PPA in terms of how they were originally purposed, but, would like to get some thoughts anyway [16:19] timrc: you need Derived Distros [16:19] talking of which I need to catch up with you guys about that [16:20] bigjools, yes and yes [16:20] timrc: I want to know how attached to your crazy custom suite names you are and whether we can work around that === salgado is now known as salgado-lunch [16:25] bigjools, I think what we need to do is fully understand derived distrobutions today and then develop a migration plan identifying the gaps [16:25] distributions, too [16:26] timrc: right. I want to see if I can help minimise gaps by suggesting different practices for you if I think you can do better [16:27] timrc: we can enable DDs on staging so you can blast away, there's a couple of bugs to fix first though. [16:28] nigelb: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/13419 [16:30] bigjools, I would love to push all our problems on to you, so I'm definitely supportive of moving towards a launchpad solution in that regard :) [16:31] timrc: I don't want your problems which is why I want to help now, rather than later :) [16:32] bigjools, even if we could work around naming and what not, I think our biggest issues are security and responsiveness... we have to be able to react very fast if shit-hits-the-fan for a customer, so having this aspect of our commercial operations managed by launchpad adds another dimension (but that's something for you and smagoun to discuss)) [16:33] so the LEP on derived distributions did not cover privacy and last I heard there was a privacy rewrite going on? [16:33] both of which make, at least me, nervous [16:34] flacoste: heh, I agree :-) [16:36] timrc: private distributions (and derived) is on the roadmap (~3-4 months) === beuno-lunch is now known as beuno [16:37] flacoste, completed and in production in 3-4 months? [16:38] I have a date with some chicken wings, bbiab === timrc is now known as timrc-lunch [16:40] flacoste: we are still having massive performance issues in production === matsubara is now known as matsubara-lunch [16:46] bigjools: yes, i've hit a few timeouts === mrevell is now known as mrevell-afk [17:47] hi folks, anyone have a moment for a class design question? [17:47] cr3: sure. === almaisan-away is now known as al-maisan [17:50] abentley: awesome! so, lets say I'm adapting Product with FooProduct which delegates(IProduct, "product"), which works well so far. now, the design problem is what if I want methods like newSeries and getSeries in FooProduct to return an adapted ProductSeries, eg FooProductSeries? might there be an alternative to overriding each of those methods explicitly in FooProduct and adapting each return value, eg def newSeries(self, name): return IFooProductSeries(se [17:51] abentley: i'm working on the JSON cache branch again. [17:51] bac: cool. [17:52] abentley: did you open any bugs for tracking this work? [17:52] cr3: I don't think there's an alternative to explicit overrides in that case. [17:53] abentley: darn, where's my pattern book when I need it the most :) [17:53] cr3: delegation is not as cool as true inheritance, because the delegated class does not have access to methods on the delegating class. [17:54] cr3, i.e. Product.newSeries will not have access to FooProduct.asdf [17:54] cr3: so you can't use the "template method". [17:55] bac: I didn't open any bugs for this work. === salgado-lunch is now known as salgado [17:55] thanks abentley === al-maisan is now known as almaisan-away [18:07] cr3: I imagine it is technically possible if you override __getattr__() or extend delegates(), to decorate methods to adjust their return types, but it would be a pretty nasty hack. [18:08] abentley: yeah, I'm looking more for a pattern to do this nicely otherwise suckup repetitive code rather than hack it === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugs: 220 - 0:[######=_]:256 [18:08] abentley: even if the pattern might be slightly overkill, my example only mentionned two methods but I actually have more which would benefit from a good pattern [18:10] abentley: if Product.newSeries did something like getUtility(IProductSeries).create(self, name), then I was thinking that in my context I could potentially subscribe my own adapter for that interface, but then I think I puked a bit in my mouth :( [18:10] cr3: if you were using inheritance, not delegation, you could use template method http://en.wikipedia.org/wiki/Template_method_pattern [18:10] err, s/IProductSeries/IProductSeriesSet/ [18:16] cr3: You could add a member of Product that is a class used to retrieve the ProductSeriesSet, and then override it on your instance. But that is gross, because Product is an ORM object. [18:17] cr3: s/ProductSeriesSet/ProductSeries/ [18:29] abentley: I'm not sure I follow, since I use adaption rather than inheritance, it wouldn't make a difference if I override that ProductSeries class in my adapted class because, if I understand correctly, Product.newSeries would do something like self.product_series_class(*args, **kwargs)... but self would be Product, not FooProduct [18:30] abentley: if I misunderstood, I'd appreciate clarification because, even if it might be gross, it might be worth considering :) [18:31] cr3: In FooProduct.__init__ or similar, you'd do self.product.product_series_class = FooProductSeries. [18:31] abentley: ah, gotcha, that would work [18:32] abentley: is there any precedent of something like that somewhere in Launchpad where it might've made sense to do so? [18:32] cr3: it's gross because Product is cached by Storm, so that Product with its custom product_series_class could show up somewhere else, where it wasn't expected to have that override. [18:33] abentley: I was thinking the other way around, if it was once a FooProduct, it might also make sense for it to remain as such. since it delegates IProduct, it should still behave the same as far as callers are concerned [18:34] cr3: No, we don't usually try to do polymorphism via delegation, so I don't know of anywhere we're doing this. [18:34] abentley: but I can appreciate how that could be a nasty side effect :( [18:35] cr3: re "I was thinking the other way around", the delegated-to Product was never a FooProduct, so it shouldn't remain as such. [18:35] abentley: touche! :) [18:36] does storm cache store.find or only store.get? === timrc-lunch is now known as timrc [18:37] cr3: I have no idea, but... 1) Something may *already* be using that instance 2) Something in the FooProduct.* call tree may acquire that instance. [18:39] cr3: Can we take a step back and question the assumption of adaptation? What's the adaptation trying to solve? === jtv-afk is now known as jtv [18:42] thanks abentley — back now but glad to see my absence hasn't held things up. [18:42] jtv: np === matsubara-lunch is now known as matsubara [18:45] abentley: it's trying to solve extending product with stats information with a single query, so FooProduct takes a product, number_of_test_runs, first_test_run_date, last_test_run_date, etc.. I have FooProductSet.create/get/search which take care of returning a FooProduct where the decorated result or resultset returns a product with all the other stats information already retrieved [18:48] abentley: ideally, I don't want to have to pollute the registry product with that information, it shouldn't have to know about these stats [18:50] abentley: so, the reason why these bleeds into ProductSeries is that this class also has an adapted class providing finer grained stats just for the series [18:51] cr3: In general, we *do* pollute classes. If you want to avoid that, perhaps a mechanism that lets you look up the stats for a given Product or ProductSeries would work. [18:53] abentley: is it just me or did QuestionsPerson originally adapt person? I see how that it pollutes Person with QuestionsPersonMixin now :( [18:53] I'd love to understand why... [18:54] cr3: After all this difficulty with other options, the reason why seems clear to me :-) === mrevell-afk is now known as mrevell [18:55] * cr3 sheds a tear for adaption :( [18:57] naive adaption will perform poorly in an ORM environment [18:57] you need fairly deep integration to avoid death by a thousand queries scenarios [18:58] lifeless: this adaptation is being done to avoid additional queries. [18:58] abentley: my concern about Mixins is that high level classes (like project) endup having to know about low level classes (like project series), so a person for example ends up becoming all knowing :( [18:59] cr3: I agree with you. [19:00] abentley: they're alright within a component, like classes within lp.answers could mixin among themselves as much as they like, but not across components [19:00] an alternative is to have an explicit mapping phase, and that can move away from using the ORM obtained object [19:01] e.g. truely map into plain old python [19:01] lifeless: is that what you mentionned a few months ago to decouple launchpad from its database backend which would have the nice side effect of being to run tests without the database? [19:02] yes [19:02] lifeless: I'm very excited about that project, especially to see the design at work, any plans to have it implemented? [19:03] lifeless: actually, is there a LEP I could keep track of? [19:04] cr3: probably never going to do it - splitting LP into small services will take a year or two and after that we can reconsider [19:05] lifeless: I'm patient :) [20:48] flacoste: I've replied to your review of https://code.launchpad.net/~benji/launchpad/bug-781600/+merge/67704 and made several changes. [20:49] benji: ack, will look at it shortly [20:49] k [20:52] cr3: why is checkbox making an OPTIONS call ? [20:53] actually, its someone in a browser hitting api pages. [20:53] we should probably block that on the api domain [20:56] lifeless: I'm not sure I follow where this call is originating from... [20:57] cr3: someone is poking at the api with a browser, on the checkbox project. [20:57] cr3: and triggering an oops [20:59] lifeless: weird, I wonder if that might be the results tracker integration. can I get more information? [21:00] https://bugs.launchpad.net/launchpad/+bug/810113 [21:00] <_mup_> Bug #810113: TypeError constructing page id: cannot concatenate 'str' and 'list' objects < https://launchpad.net/bugs/810113 > [21:01] sinzui: i will be at the meeting tonight. [21:01] fab === matsubara is now known as matsubara-afk [21:09] flacoste: do you want to look at lp.net/lazr and sort it out then ? [21:14] lifeless: that oops doesn't seem to be related to the results tracker and I looked at some of the scripts used by my team to generate bug coverage reports, likely candidates to generates oopses against checkbox, but they all seem to use lpltk which uses launchpadlib [21:15]