[00:09] jelmer: the diff on https://code.launchpad.net/~jelmer/launchpad/bzr-code-imports/+merge/70684 *still* seems to have extraneous changes [00:09] jelmer: which must be quite frustrating by now :) [00:09] jelmer: ah, seems you merged db-devel? [00:17] mwhudson, yeah, as it has the bzr-2.4b4 branch merged, which is targetted to db-devel [00:17] mwhudson, let me resubmit [00:19] pop quiz [00:19] who cares about informational oopses? [00:19] lifeless: people presumably care about the ones made with ++oops++ [00:20] mwhudson: I don't think they would suffer if that was not 'informational' [00:20] jelmer: does the code change depend on schema changes that are not yet deployed ? [00:24] lifeless: No, but it has merged some revisions from an older revision of db-devel which seems to confuse the MP code [00:25] so we don't deploy from db-devel [00:25] -ever- [00:25] -at all- [00:25] landing it on db-devel will just cause conflicts and pain [00:25] ok [00:25] (conflicts when folk changing devel conflict with your code) [00:25] (pain when conflicts happen :P) [00:26] is it perhaps triggering a criss-cross merge case? [00:26] what happens when you merge (but don't commit) devel into it ? [00:27] conflicts :P [00:27] jelmer: so, I would fix that :P [00:27] and propose to devel [00:27] mwhudson: I'm thinking to nuke the 'informational' flag [00:27] mwhudson: and just use specific exceptions like 'ProfilingOops' instead to filter them on the reporting side [00:28] lifeless: ah i see [00:28] mwhudson: things like the hwdb code that logs an oops when it gets a POST missing a field [00:28] suggest that the informational side has been misunderstood and misused [00:29] lifeless: I think it is useful to have an OOPS-like mechanism for non-critical logging. [00:29] wgrant: well, I'm going through our uses [00:30] wgrant: so far I've found one case that makes sense - profiling / ++oops++ - both of which use a custom exception [00:35] the disconnected handling in publisher, for instance - that deserves to be a real oops [00:35] its a problem if its happening [00:35] (it should never be happening) [00:52] yep, all uses were either a) noddy or b) trivially classified on the exception anyway. [00:52] *nuke* [00:55] wallyworld_, did you need me to look at something? [00:55] sinzui: yes, just to approve the ff request: https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus#Feature_Flag_Changes [00:55] thanks [01:44] Project devel build #976: STILL FAILING in 6 hr 7 min: https://lpci.wedontsleep.org/job/devel/976/ [01:47] jelmer: lol; meep - your branch is really confused isn't it :) [02:07] StevenK: want a trivial review? https://code.launchpad.net/~wallyworld/launchpad/remove-answer-contact-827051/+merge/71632 [02:32] wallyworld_: heya [02:32] nigelb: hi, got your email, still catching up with things, sorry haven't replied yet [02:33] speaking of reviews [02:33] wallyworld_: still pending on loggerhead;sorry [02:33] https://code.launchpad.net/~lifeless/python-oops-datedir-repo/extraction/+merge/71633 and https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71634 [02:33] lifeless: np. i was going to remind you later today :-P [02:33] are the next stage of my ripping oops out of LP [02:33] wallyworld_: great thanks :) [02:34] nigelb: will look very shortly [02:34] \o/ [02:34] I think the only thing left is an http module and either a canonical module or some sensible-defaults copied into the core oops system. [02:52] Any reviewers in the house? Got a job for you! https://code.launchpad.net/~jtv/launchpad/bug-826659/+merge/71636 [02:53] Short diff, long cover letter because I vent some steam and formulate some rules for testing. [02:59] jtv: i'll look if someone can mentor [02:59] hi wallyworld_! Thanks. I see a slight conflict of interest with me doing that, obviously. :) [03:00] jtv: yep :-) i and looking at something for nigelb just now but will do the review asap after that [03:01] Thanks. Let me know if you need any mentoring for branches other than mine. And maybe it's time to look at graduation — I have a feeling we may have lost our procedure for that. [03:09] nigelb: your @call_with(user=REQUEST_USER) is having no effect since it's in the wrong place. [03:10] nigelb: you need to add this to an interface method and register the interface with the web service parsing infrastructure so it gets slurped up [03:10] wallyworld_: oh. *thats* why. [03:11] nigelb: there's various webservice.py files in the code base which is where the webservice stuff looks to see what it needs to register [03:11] with your code at the moment, user is set to None [03:11] ah, that explains that. [03:12] you could pick an example interface what is exported to the web service and model what you need to do on that [03:13] so, write a wrapper over the search function using a webservice interface? [03:13] you also should write a test for the web service side of it [03:13] I should write a javascript test too. I've been lazy ;) [03:14] nigelb: you don't need to write a wrapper - you just need to figure out how to get the current logged in user inside your check_bug_links method. [03:15] ah! [03:15] your code looks ok so long as you know the user [03:16] we uased to use ILaunchbag to arbitarily get the user for a given interaction but that's frowned upon now [03:16] That's because ILaunchBag needs to die horribly. [03:16] And painfully. [03:16] the @call_with is one way of doing it if the method is an existing web service [03:17] there may be a better way without having to export teh method as a web service but i'm not sure off hand what that would be [03:17] this has been done before? and I just need to find some example code and work my code the same way? [03:17] StevenK: yes, agree about ILaunchbag. do you know any other way to get the logged in user other than @call_with ? [03:18] nigelb: @call_with is used in many places [03:18] wallyworld_: heh, except I didn't understand the correct way of using it :) [03:19] if you are in a view, you can type self.user i think. but we are not in a view here [03:19] i don't know enough about the zope machinery to understand how the user is extracted from the request [03:21] the only place call_with works is in interfaces? [03:21] nigelb: LinkChecker is initialised with the request object [03:21] nigelb: i think you can get the user from in there [03:21] nigelb: afaik, all web service decorators need to be added to interface methods [03:22] ah, cool. [03:23] nigelb: try user = request.principal.person [03:23] not sure if that's kosher but it works [03:23] heh, okay :) [03:24] nigelb: for anonymous requests, i suspect principal will be None so check for that [03:24] sure, will do [03:25] so forget the web service stuff [03:28] i think IPerson(request.principal) might be more kosher [03:29] wallyworld_: @call_with for web service methods/properties is best practice. [03:29] mwhudson: ah, thanks [03:29] lifeless: it's not exposed as a web service method atm [03:30] otherwise @call_with would be the best solution i agree [03:31] nigelb: see mwhudson's comment above - use IPerson(request.principal) [03:32] wallyworld_: already changed code :) [03:32] excellent [03:32] wallyworld_: ah, I didn't think it could be anything -other- than a web service clal [03:32] wallyworld_: :) [03:34] lifeless: it's defined in zcml as a browser:page implementation [03:34] and the __call__ method is implemented [03:34] yeah, I can imagine [03:36] web service is sort of overkill for what it does perhaps, it's only an "internal" api [03:36] in principle the web service would take care of encoding, auth checking, marshalling etc [03:37] doing it by hand is, well, by hand. [03:37] err, what's the result of a searchBugIds call? I don't seem to be able to understand this. [03:38] Here's the call I'm making and its associated traceback http://paste.ubuntu.com/666969/ [03:38] a list of ids :) [03:39] nigelb: your bug_ids set is full of strings. [03:39] nigelb: also, that python loop will be -very- slow [03:40] nigelb: you need to map it into a set - [03:40] found_ids = set(bug_ids) [03:40] missing_bugs = found_ids - bugs [03:40] oh. [03:40] I didn't know I could do that :| [03:41] nigelb: I wouldn't use an english description either, you want minimal data flowing - this is an implementation detail, not a UI [03:41] so the thing you serialise out should just be the ids of the inaccessible bugs, no explanation why [03:41] lifeless: the why explanation shows up as tooltips. [03:41] nigelb: there is only one explanation [03:41] that's how the javascript end of things seem to be configured. [03:42] nigelb: sure, but you can do that on the client. [03:42] jtv: you and your fancy latin words [03:42] nigelb: disclosing whether the bug was private or just a gap in the bug sequence would leak information about the bug. [03:42] heh, that means creating a new javascript function on the client ;) [03:42] wallyworld_: I'm sorry if I urinated you off, amice [03:43] nigelb: well, up to you where you do it; just saying what I see ;) [03:43] jtv: no, you didn't, just saying :-P [03:43] :) [03:43] lifeless: heh, my first non-trivial branch, so I think I might aim for perfection or as much close to it as I can get. [03:45] nigelb: as long as its fit for purpose [03:45] nigelb: beyond that, shrug :) [03:45] heh [04:14] lifeless: for some reason the missing_bugs = found_ids - bugs isn't working [04:17] nigelb: break in with pdb and have a look around [04:18] in the middle of doing that [04:26] wait, what. [04:26] search returns bug ids as int. [04:26] * nigelb cries [04:26] is there a way to convert that to string or make it return strings? [04:27] nigelb: like I said, your thing was full of strings [04:28] nigelb: no, you should be converting your strings to ints before you query in fact ;) [04:28] lifeless: bug numbers can't exceed the length of ints, can't they? [04:28] [because the data type is int] [04:28] nigelb: do you mean as in MAXINT ? [04:28] yeah [04:29] we can upgrade the column to 64-bit before that [04:29] but we'll be a few decades yet [04:29] oh. ok. [04:35] IT WORKS \O/ [04:36] lifeless: So I should write a loop to create 200,000 bugs to help it along? [04:38] StevenK: ... [04:39] poolie: around ? [04:41] lifeless: :-P [04:44] hi lifeless, otp atm [04:44] to statik [04:44] kk [04:45] wgrant: you are terrible at leave. [04:45] lifeless: like you can talk [04:45] Haaha [04:45] wallyworld_ is right, you so can't. [04:45] mr pot, meet mr kettle [04:45] wallyworld_: I'm talking from a position of knowledge. [04:47] so I'm thinking about oopses here [04:47] lifeless: And I've just fallen into the trap of correcting incorrect question answers. [04:48] wgrant: i hope you take time in lieu :) [04:48] Hah. [04:48] It will only take a few minutes. [04:48] cognitive overhead :) [04:48] I *know* it takes me a fortnight +- to spin down from work, so I plan leave accordingly [04:49] that's a loooong time [04:49] wallyworld_: yes, and if you think back to last december - after about two weeks I was around much less [04:49] Indeed. [04:50] wallyworld_: if I take < 2 weeks leave with the intent of relaxing, its an utter fail [04:50] lifeless: i was in NZ for most of Dec, so didn't notice :-) [04:50] wallyworld_: nice, did you drive around ? [04:50] wgrant: btw, talking about generic names [04:50] http://pypi.python.org/pypi/Products.Collage/1.3.6 [04:51] wgrant: 'Products' as a top level package in python. [04:51] yes, started in Dunedin, all through south island, then onto north island [04:51] lifeless: Sounds like Zope. [04:51] Is it? [04:51] wgrant: plone, so more or less yes [04:51] I think Zope 2 is allowed to have the global namespace. [04:51] RIght. [04:52] Since Zope invented just about everything, and they use sensible namespaces now :) [04:52] so anyhow [04:52] I'm thinking about how to pass in things like the request object, urls, exc_info [04:53] the generic way to wire up for DI would be to supply a container callback [04:53] but this is going to be fuugly for the simple case [04:54] so I'm thinking of having a 'context' parameter to config.create()', and documenting that on_create hooks will receive this, and it can be used to psas things to the hooks, and some well known hooks will look for things there. [04:54] like - attaching exception info would look for context['exc_infp'] [04:54] lifeless: is the preforking server unblocked now? or almost? [04:54] poolie: not until we have the disconnect stuff done [04:55] wgrant: what do you think? The alternative seems to be tighter coupling between report population/creation and the point the report is created. [04:55] StevenK: wallyworld_: ^ [04:56] lifeless: i'm not sure i have enough context - you want to do IOC with the new oops module? [04:57] to allow the oops module to poke stuff back into the container? [04:57] wallyworld_: I want it to play with IOC environments (like lp's) and with non IOC stuff (like LaunchpadScript, loggerhead, gpgverify) [04:57] wallyworld_: so here is an example case [04:58] in LP we use zope.exceptions.exception_formatter to format the traceback in an oops report [04:58] this is pretty zope specific [04:58] even though, thankfully, its a the edge of the dependency graph I think. [04:59] yes, i can imagine it would be zope specific [04:59] so oops *could* use that [05:00] and have config.attachException(report, exc_info) [05:00] this would drag in zope.exceptions and zope.interfaces [05:00] which isn't too bad [05:00] Did you know that imposing Zope dependencies aparent from zope.interface and zope.component is considered a crime against humanity? [05:00] s/aparent/apart/ [05:00] wgrant: well this is why the thought going into this [05:01] an alternative would be to say 'if you want to attach an exception, do it yourself', but thats cruel. [05:01] a third way would be to have an explicit config knob 'call this function to configure the traceback formatter' [05:01] lifeless: i'd rather pass in some sort of context with redirects to the preferred implementation as you say [05:01] the way I am considering is to say 'put your exception in content['exc_info'], and your exception on-create hook will format [05:02] if you want a different formatter, don't put the supplyed on-create hook in there, instead put your own one. [05:02] supplied. [05:02] this kindof shifts the complexity around [05:02] but [05:02] I think it starts to pay off when you consider handling of 'request' objects [05:02] and the like. [05:03] where the core really shouldn't have any concept of such a beast. [05:03] i don't think it introduces too much extra complexity any simple case [05:04] so create(content=dict(request=current_browser_request(), exc_info=sys.exc_info(), program=sys.argv[0]) [05:04] ) [05:04] and let the hooks suck out what they want [05:05] I'm down to *one function* to pick apart [05:05] and then launchpadloggerhead can lose a canonical import, and gpgverify can work. [05:05] maybe a namedtuple rather than a dict? [05:05] wallyworld_: blah :) [05:06] wallyworld_: theres no particular reason to make it immutable [05:06] not so much to make it immutable but for type safety and extensibility [05:06] How's that more typesafe or extensible? [05:06] you'll need to expand on how it gives those in a way a dict would not ? [05:07] i guess you could subclass dict if you needed to [05:07] To do what? [05:07] add extra functionality besides name-values pairs to the context [05:07] wallyworld_: uhhh, you've *totally* lost me. [05:08] wallyworld_: so the point of the context is to pass data from outside 'create' to each on_create hook, without needing create-and-every-callbacj to take **kwargs [05:08] context could be more than just a container for name-value pairs- it couild actually provide some other encapsulated functionality [05:08] wallyworld_: it could; what do you have in mind ? [05:08] just a sec, otp [05:13] lifeless: i dont' have any specific functionality in mind for this case, but in practice such context objects can be used for more than data passing - they can provide useful behaviour such as access to container specific services [05:13] so a dict may be too simple [05:13] wallyworld_: so, I would say that if someone in a container environment needs access to the container, they do: [05:13] context=dict(container=realcontainer, exc_info=sys.exc_info(), ... etc) [05:13] wallyworld_: and have their custom on_create hook do content['container'].containerservicecall() [05:14] wallyworld_: or even implement __getitem__ on their container and pass it in directly, if the protocols line up well enough [05:15] wallyworld_: remember we're duck typed, so there is no need for it to *be* a dict, not even a subclass :) [05:15] that would work. i guess it comes down a little to personal preference. i tend to dislike using simple data structures as integration "glue" since often i find more is needed [05:15] I've come to really appreciate minimalism [05:16] but maybe duck typing removes the need for that as you say [05:18] anyhow, that can be iterated on [05:18] given we have 1(1!) user so far :P [05:18] sure, so +1 for option 3 :-) [05:20] however it's done, we just need to be clear on the contract between the modules and ensure that is satified from both sides [05:20] Now now, clear and sensible contracts are not the Launchpad way. [05:22] lifeless: i'm off the phone but i might have some lunch now [05:22] will ping you after [05:30] lifeless: quick question - what's the storm syntax for a query term checking for "is null" that I can pass to "where=And(*terms)"? instead of [MyClass.property == 'name'] I want [MyClass.property is null] or whatever [05:34] poolie: ok [05:34] wallyworld_: ==None [05:34] wallyworld_: == None [05:35] lifeless: StevenK: thanks! [05:36] wallyworld_: I think you've broken devel on buildbot [05:36] Failure in test lp.answers.tests.test_questiontarget.QuestionTargetAnswerContactTestCase.test_canUserAlterAnswerContact_owner [05:37] StevenK: i'll look [05:43] StevenK: ffs. i didn't remove a test when i did the revert earlier [05:43] FAIL [05:43] yes :-( [05:43] There's a JS test and a python test both failing [05:44] i'll check the js one [05:45] RARGH [05:45] Stupid librarian logs attached to test failures [05:45] USELESS [05:46] StevenK: which js test? bb only shows 1 failure, the py one [05:47] StevenK: You should fix the fixture to only attach the log for the current test. [05:47] wgrant: I should fix the fixture to not attach the log in the first place! [05:47] wallyworld_: Read the summary, there are two. [05:48] StevenK: attaching the log is great [05:49] StevenK: what needs to change is to only attach the *new entries* for a test. [05:49] Sure, great. 3,800 lines between the test failure and the traceback [05:56] Any review mentors available? https://code.launchpad.net/~jtv/launchpad/bug-826659/+merge/71636 [05:57] Well. Bugger. [05:58] Calling the column sourcepackagename hurts when you join against SPR [05:58] :-( [06:02] StevenK: can you possibly +1 this? do I land with 'testfix' now or wait till bb barfs? https://code.launchpad.net/~wallyworld/launchpad/remove-tests-for-badrev-13696/+merge/71642 [06:02] wgrant: are you reviewing today? [06:02] jtv: wgrant is on holidays [06:02] Then he shouldn't be here! [06:03] jtv: *supposed* to be [06:03] Ah yes [06:03] wallyworld_: r=me [06:03] Well, I'll just go have lunch then or something. [06:03] wallyworld_: If you land it now, you may have to force buildbot when it finishes. [06:04] wallyworld_: I added a follow-up note on my MP, even though I'm not formally mentoring that one. :) [06:04] jtv: thanks, will look [06:05] StevenK: i'll be at soccer when it barfs but will force as soon as i return, about an hour later. so i'll land now so it's all ready [06:06] StevenK: since you're familiar with the code... https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71510 please? [06:07] lifeless: 1169 lines!? [06:07] StevenK: bah, thats the old one. [06:07] one sec [06:07] StevenK: https://code.launchpad.net/~lifeless/python-oops-datedir-repo/extraction/+merge/71633 is the one I meant. [06:08] lifeless: So, calling the new column on SPPH sourcepackagename leads to problems [06:08] StevenK: existing queries barf ? [06:08] Right [06:08] StevenK: lets use a different name; easier and safer than fixing all queries in advance. [06:08] spn_cache or something [06:09] lifeless: I've switched to 'name' [06:09] StevenK: I'd prefer something other than that, because of 'name' being the url component in so many other classes. [06:09] StevenK: however, up to you. [06:09] lifeless: 'spn' / 'bpn' ? [06:09] StevenK: sure [06:11] Subject: RETURNED MAIL: DATA FORMAT ERROR [06:11] heh [06:12] lifeless: r=me, with a slight wrist-slap [06:14] sexy times [06:15] ah yes, the version number. [06:15] that was oversight in the move before [06:48] StevenK: if you are around in about 1hr30 and force a build, i'll buy you a beer :-) [06:50] wallyworld_: You should have landed it with [testfix] [06:51] StevenK: bollocks. can i change it now? [06:52] No, it's landed. [06:52] bollocks x 2 [06:53] * wallyworld_ gotta run to soccer [07:05] lifeless, hello? [07:09] can has reviews? tiny: https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71644 and getting big but its really simple stuff... just rearranged code: https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71634 [07:09] poolie: hi [07:09] poolie: sure, if you want to ring the landline ? [07:25] poolie: ? [07:35] Project db-devel build #812: STILL FAILING in 5 hr 50 min: https://lpci.wedontsleep.org/job/db-devel/812/ [07:42] oh sorry, sure [07:48] good morning [08:09] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/view/head:/lib/canonical/launchpad/webapp/dbpolicy.py?file_id=x_Andrew_Bennetts_%3Candrew.bennetts%40canonical.com%3E_Fri_Oct__1_11%3A57%3A48_2004_12702.0 is failing for me, but otherwise code browse was reasonably snappy [08:10] "redirecting the request for this address in a way that will never complete" [08:12] stub: bug 819444 [08:14] stub: O hai. I've had to rename {binary,source}packagename to {b,s}pn, but you think an index on just that column is fine to start with? [08:15] Why the rename, apart from long names suck? [08:15] An index on just that column is fine. If you know the queries it is needed for, we might be able to make a compound index that satisfies those queries as well as the population job. [08:16] stub: Breaks existing queries that join against SPR and SPN [08:16] I'm not sure I like that rationale. We know we need to fix code when changing the schema. [08:17] stub: we can't be sure we've caught all the existing queries [08:17] I would go for 'because the long names suck, so we should just use spn and bpn everywhere' but that doesn't solve your problem. [08:18] stub: the reason for the breakage was a previously unique column name becoming non-unique + hand crafted queries not putting the table name in place [08:18] lifeless: You could say that about every new column addition we make, and it has never been a problem in the past. [08:18] stub: previously we did code + schema changes in lockstep, with several days (or more) qa on staging [08:18] stub: we're explicitly not doing that now... [08:19] Yes, and now we need to run the test suite with both /stable and /db-devel [08:19] Or we are going to have to start naming new columns with UUIDs [08:19] stub: well, its a risk assessment. [08:20] Yes, and next time we denormalize further we are going to call the column spn2? [08:20] stub: I guess I'm saying I'm fine with a name that reduces the risk; if you want a more risky but more consistent name, I can live with that [08:20] stub: I'd hope that we don't use spn unqualified, having learnt that lesson [08:21] stub, lifeless: So, I will kill this ec2 run, and I will investigate fixing the queries that use the full name of SPN and BPN unqualified. [08:21] I want consistent names. If we want to switch to spn/bpn I'd like it to be consistent. This also gets tied up with migrating to text strings over integer ids [08:22] stub: such a migration might be a pessimisation for some queries (absent trigrams...) [08:22] Yes. We don't know yet. [08:22] stub: I think we need more investigation on that particular thing (though I know I was one of the proponents of it before :P ) [08:23] For now, I'd rather stick with the full names and do two ec2 test runs (-b launchpad=stable, -b launchpad=db-devel) [08:23] stub: given stable is merged to db-devel all the time, just db-devel should be robust [08:24] stub: I know the test failures for db-devel anyway, so I will investigate those tomorrow. [08:24] True. So this isn't any different from before then? [08:24] stub: remember that someone could land a break in devel at any time; we probably need a deploy rule 'can only deploy a schema change if the current *live* revno has been tested by buildbot on db-devel' [08:24] stub: we'll figure out all the corner cases soon :P [08:25] matsubara-afk: are you around ? === matsubara-afk is now known as matsubara [08:25] Yes. We knew there would be extra landing complexity and more branches for allowing live patches. People thought the trade off was worth it. [08:25] lifeless, hey, yes. I'm in the QA sprint [08:25] stub: yup, and I still do :P [08:26] Which reminds me, I have branches to land since I couldn't get my branch to push last night due to major sucky 'Net. [08:26] matsubara: I want to patch oops-tools. It wants its own db cluster - is that still correct ? [08:27] lifeless, what do you mean by it wants its own db cluster? [08:27] matsubara: are there any docs on hacking it ? [the README.txt only talks about running locally...] === almaisan-away is now known as al-maisan [08:28] lifeless, hmm README.txt is the closest I have for docs. [08:28] StevenK: So you need to do what I was doing yesterday - separate branch from stable containing the required test fixes to land on devel, which gets merged into your db-devel so you can run the tests to ensure the required fixes really are the required fixes. And don't use devel for the source of your fixes or you risk leaking untested changes from devel -> db-devel. [08:31] lifeless, are you not able to run it locally to test your changes? [08:33] matsubara: I don't know how to run its test suite ;) [08:33] lifeless, make check [08:36] let me have another go at it :) [08:39] matsubara: I want to get rid of the custom oops parser [08:42] lifeless, right. basically you'll have to add your package to the download-cache, update versions.cfg and setup.py with the new package, remove the code from src/oopstools/oops/models.py and update it to use the code in the package. Do you need help with this? [08:42] matsubara: hopefully not :P [08:44] wallyworld_: my MP now works. I think I'll spend tonight / tomorrow morning writing tests. Is there any more clean up that you'd suggest? === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 238 - 0:[#######=]:256 [09:13] jml: Hi! [09:13] Dear Thunderbird, why are you taking up 1.2 cores? [09:13] StevenK: you will have to email that question, not put it on irc ... [09:14] Bwaha [09:14] gmb: oh hai [09:14] lifeless: Wotcher [09:14] can haz review? [09:15] https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71644 [09:15] and [09:15] https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71634 [09:15] lifeless: Sure. I'll attend to those presently. [09:15] * gmb grabs a cup of tea before getting down to work. [09:16] gmb: thanks! [09:16] np [09:28] hey guys :) [09:29] I have a team subscribed to several packages, is it possible to mute bugmail in only one of them? [09:32] Ursinha: yes [09:35]