[01:46] <sharms> anyone know how to change the importance of a bug?
[01:53] <iGama> sharms its not you that decide
[01:53] <iGama> ;)
[01:54] <sharms> iGama: so if I file a bug, and leave it as untriaged, I cannot go back later and change it?
[01:54] <sharms> Doesn't make much sense that I can confirm it fixed but not change priority
[01:54] <iGama> maybe i can be wrong
[01:55] <sharms> you're probably right
[01:55] <sharms> because I have searched high and low for it
[02:22] <lifeless> sharms: so priority is assigned by the folk that work on the bug
[02:22] <lifeless> sharms: because they have the 'global view'
[03:11] <jamesh> lifeless: have any luck getting the company voip stuff set up at your end?
[05:01] <mpt_> Goooooooooooooooooooood afternoon Launchpadders!
[05:03] <stub> Yo
[05:15] <mpt_> Feeling better, stub?
[05:32] <stub> 40C  fever broke last night taking most of the symptoms with it. Just left with a sore throat and aches after medication.
[06:19] <mpt_> yay, another spurious PQM failure
[09:02] <SteveA> morning
[09:03] <stub> yo
[09:04] <carlos> morning
[09:11] <spiv> Hello.
[09:15] <stub> spiv: Got a review for me yet?
[09:16] <spiv> stub: it's about half done by lines of diff, although I think probably the second half will be less interesting (the changes to the tests are less interesting than the infrastructure)
[09:17] <stub> Yup. Mostly noise. 
[09:17] <stub> It isn't a complete overhaul, but I think it is a step or two in the right direction.
[09:18] <cprov> BjornT_: ping
[09:18] <BjornT_> hi cprov 
[09:19] <cprov> BjornT_: hi dude, about the testBrowse hint you gave me.
[09:20] <cprov> BjornT_: the 500 exception appeared, however the contents is empty ans screams
[09:20] <cprov> line 185, in contents
[09:20] <cprov>         old_location = response.tell()
[09:20] <cprov>     AttributeError: 'NoneType' object has no attribute 'tell'
[09:22] <sivang> morning
[09:22] <cprov> sivang: morning 
[09:24] <BjornT_> cprov: oh, that's not good. i was quite sure that you could look at the error page, but maybe you can't. i'd say that's a bug, though.
[09:25] <cprov> BjornT_: can you check this soon for us ?  I don't realy need to check the pages contents, the fact it is a 500 is enough
[09:29] <BjornT_> cprov: sure, i'll take a look at it today. although i'd think that the UFD part is the important one, so i'd rather check for the UFD exception rather than checking for a 500 page.
[09:31] <cprov> BjornT_: I can't get the UFD in the pagetest :(
[09:31] <BjornT_> cprov: what exeption do you get if you set browser.handleErrors = False?
[09:32] <cprov> BjornT_: ohh, indeed, it's UFD
[09:34] <cprov> BjornT_: back on the former topic, I cannot use this approach for POST vars, can I ?
[09:36] <BjornT_> cprov: well, it depends. for some you can, but for some you can't.
[09:39] <cprov> BjornT_: how do you mean ? can you give some example, or better can you check the bad-usage in soyuz/26... ?
[09:47] <BjornT_> cprov: for the http() calls in 26-queue-pages.txt it'd be hard to convert them to new-style tests. it would be possible to do it (without modifying testbrowser), but i don't think it's worth the effort.
[09:51] <cprov> BjornT_: uhm, so the limitant factor is that they use POST ? 
[09:53] <BjornT_> cprov: actually, you might be able to do it. try passing the POST variables as a dict to browser.open(), like >>> browser.open('http://...', data={'QUEUE_ID': '1', 'Accept': 'Accept'})
[09:54] <cprov> BjornT_: let me check
[10:01] <cprov> BjornT_: see https://chinstrap.ubuntu.com/~dsilvers/paste/filenHwIoU.html
[10:01] <cprov> BjornT_: it failed 
[10:04] <doko> cprov, elmo: two Friday uploads: fontconfig (unsigned, but didn't get any mail), libxt-java (signed, I do have an upload file, but it's not in the archive). any hints?
[10:05] <cprov> doko: will check, do you remember the time you uploaded them ?
[10:07] <doko> cprov: libxt-java: 15:30:29 UTC -2, just did overwrite the fontconfig .upload file
[10:07] <BjornT_> cprov: ok, so the data should be a string. passing in data='QUEUE_ID=1&Accept=Accept' could work then, but you might have to set the Content-Type header as well, and i don't see a way of doing that. (i'm also not sure if it will be a GET or POST request)
[10:09] <cprov> BjornT_: let's give up for a while, bug #52487 will remember us later.
[10:09] <Ubugtu> Malone bug 52487 in soyuz "Current pagetest environment doesn't support hand-made URLs" [Medium,Confirmed]  http://launchpad.net/bugs/52487
[10:09] <BjornT_> cprov: sounds good
[10:16] <cprov> doko: libxt-java_0.20050823-2ubuntu1_source.changes -> 'edgy.' (the ending DOT !!) REJECTED
[10:17] <cprov> doko:  the fontconfig was "nearby" the last ?
[10:18] <ddaa> jamesh: ping
[10:18] <jamesh> ddaa: pong
[10:18] <ddaa> are you aware that the branch scanner is currently broken?
[10:19] <jamesh> ddaa: yes.  I have a branch waiting for review to fix it
[10:19] <SteveA> jamesh, spiv, stub
[10:19] <SteveA> conf call time!
[10:19] <jamesh> ddaa: there were some differences between the test environment and production so an error slipped by
[10:19] <jamesh> ddaa: my branch fixes those env differences and the problem (plus makes some other cleanups)
[10:19] <SteveA> as soon as stub has explained to me how to drive it
[10:19] <ddaa> jamesh: fantastic, thank you
[10:20] <doko> cprov: "nearby": don't know exactly, the changes file is from 10:00 -2.
[10:20] <jamesh> ddaa: I moved the bzrsync.py code to lib/canonical/launchpad/scripts as part of the cleanups
[10:20] <doko> cprov: I didn't get the rejected message ...
[10:20] <jamesh> ddaa: and it now gets run by the main zope test runner
[10:21] <ddaa> jamesh: great! I had already done some preparatory work for that
[10:21] <ddaa> I'm very happy to hear that you completed the move :)
[10:21] <cprov> doko: nevermind .. let's check at 10
[10:22] <doko> cprov: yes, fontconfig was unsigned, that should be the reason
[10:25] <cprov> doko: alright, upload them again now, we can check for anything weird, but yes, unsigned changes do not generate any email.
[10:26] <stub> We appear to have lost James and Steve. 
[10:26] <stub> Straight after a machine gun sound
[10:27] <SteveA> i can hear all three of you
[10:27] <SteveA> but you cannot hear me
[10:27] <SteveA> maybe it is my NAT flavour
[10:27] <SteveA> i had this with ekiga before on stun
[10:30] <stub> I'm here
[10:30] <stub> You can't here me?
[10:30] <spiv> stub: no.
[10:30] <SteveA> stub: turn off STUN and NAT Traversal in the prefs
[10:32] <cprov> doko: fontconfig and libxt-java were accepted, did you get emails ?
[10:33] <stub> I feel all alone
[10:34] <SteveA> everything's gone choppy
[10:34] <SteveA> and you can't hear me
[10:34] <SteveA> ...
[10:35] <stub> Declare SIP a failure for the time being?
[10:35] <SteveA> yeah
[10:36] <stub> I prefer IRC meetings anyway :)
[11:09] <lifeless_> jamesh: no, wanted to chat with you about local asterisks - I get -crap- audio via either a local asterisk or siproxd to the loopback service @ canonical, and with a local asterisk to the local asterisk
[11:10] <lifeless_> ddaa: what time is our bzr meeting ?
[11:10] <ddaa> mh
[11:10] <lifeless_> as in, hours from now
[11:10] <ddaa> thanks for reminding me
[11:10] <ddaa> I think last time we discussed times, it was UTC 1200, that is 170 mins from now
[11:11] <lifeless> no way
[11:11] <lifeless> 1000 perhaps
[11:11] <lifeless> it was before the review meeting
[11:11] <ddaa> hu
[11:11] <lifeless> and the review meeting is 1100
[11:11] <ddaa> right
[11:11] <lifeless> so, in 50 minutes, cool
[11:11] <ddaa> as you can see, my meeting muscle is a bit rusty
[11:13] <SteveA> gah... a day of meetings again!
[11:13] <SteveA> at least ddaa and lifeless know how to keep them brief :-)
[11:13] <ddaa> SteveA: lifeless: if you guys do not mind, I'm happy to skip it
[11:13] <SteveA> ddaa: after EP, it's important to get things back on track
[11:13] <ddaa> I have a very short week, and I'd like to get some actual productive work out of it.
[11:14] <SteveA> i think 45 mins for a meeting will make little difference
[11:14] <SteveA> even including 15 mins to stick a summary of action items and decisions on a mailing list
[11:15] <ddaa> okay, I'll start preparing the agenda
[11:49] <SteveA> https://launchpad.net/products/launchpad/+bug/50743
[11:49] <Ubugtu> Malone bug 50743 in launchpad "sqlobject SelectResults.__contains__ generates bad SQL for some conditions" [Untriaged,Fix released]  
[11:49] <SteveA> https://launchpad.net/products/launchpad/+bug/39814
[11:49] <Ubugtu> Malone bug 39814 in launchpad "Misleading login hint" [Medium,Fix released]  
[12:08] <glatzor> Hi carlos. Rosetta seems to completely ignore me. I cannot upload any po files nor request them.
[12:08] <carlos> glatzor: hi
[12:08] <carlos> URL?
[12:09] <glatzor> https://launchpad.net/distros/ubuntu/dapper/+source/nautilus/+pots/nautilus/de/+export
[12:10] <glatzor> or https://launchpad.net/distros/ubuntu/dapper/+source/kdebluetooth/+pots/kbtobexclient/de/+upload
[12:11] <glatzor> The uploaded translations do not appear in Rosetta and I don't get any confirmation e-mail.
[12:11] <carlos> glatzor: but you got the confirmation email, right?
[12:12] <glatzor> When I request a po file, Rosetta says that I will receive it by email, but this doesn't happen
[12:12] <glatzor> carlos: No not even the confirmation e-mail.
[12:12] <carlos> no, I'm talking about the confirmation after the upload
[12:12] <glatzor> I checked my spam folders twice
[12:12] <carlos> what you get in our Web UI
[12:13] <glatzor> All looks fine in the web interface
[12:13] <carlos> ok
[12:20] <carlos> stub: hi, could you check if Rosetta's scripts are enable on production ?
[12:31] <stub> oops. I remember disabling them for some maintenance.
[12:31] <stub> carlos: Fixed.
[12:32] <stub> Who wants to review or approve https://launchpad.net/products/launchpad/+spec/stop-spurious-test-failures ?
[12:32] <carlos> stub: ok, thanks
[12:32] <carlos> glatzor: you should get the email soon, seems like we had the scripts to do the imports disabled
[12:32] <glatzor> thanks a lot, carlos
[12:35] <SteveA> stub: "eternal libraries." ?
[12:36] <stub> spelling optional
[12:36] <SteveA> stub: looks good, but the spec should state what the 2-way deps are
[12:43] <stub> SteveA: I don't know what they are. That is why the spec explicitly states the initial rule will be the current minus the two that are failing.
[12:44] <SteveA> which two are failing?
[12:44] <stub> cscvs and bzr
[12:44] <spiv> cscvs and bzr currently both have issues due to the time issues.
[12:45] <spiv> I think it wouldn't be hard to figure out the dependencies though.
[12:45] <SteveA> okay.  i'm happy with it.  i'd like lifeless to say whether he is happy about it.
[12:46] <spiv> Lots of them are obvious: sqlobject, twisted, zope are all clearly not dependent on launchpad.
[12:48] <lifeless> I'd like a wiki page that describes all the branches and what the depend on
[12:48] <lifeless> then I'd like a proposed consistent way of managing the tests-to-run-for-each-branch
[12:48] <lifeless> i.e. 'sqlobject: run all', 'launchpad: run X,Y,Z' etc
[12:49] <lifeless> and at that point I'll say whether I'm happy, or if not, what it will take ot make me happy
[12:50] <stub> I'd like a solution we can turn on now.
[12:50] <lifeless> last time we did this we shot ourselves in the foot.
[12:50] <stub> That works for us and meets our goals.
[12:50] <lifeless> I'm in anothe rmeeting right now.
[12:51] <lifeless> but what I'm suggesting is really no more than the bare minimum: we have to analyse our branches and decide
[12:51] <stub> Why?
[12:51] <stub> It doesn't address our immediate concerns any better
[12:52] <SteveA> lifeless: we're concerned only about merges into the launchpad branch right now
[12:53] <SteveA> the rest can proceed as they currently do
[12:53] <spiv> If you define our immmediate concerns as "don't run cscvs or bzr tests on launchpad merges", then stub's right ;)
[12:53] <lifeless> SteveA: in which case, someone needs to analyze all the branches from the p.o.v. of 'can break by lp changing'
[12:54] <SteveA> no
[12:54] <SteveA> that's overdoing things up front
[12:54] <SteveA> we first need a mechanism for running only the tests we want
[12:54] <SteveA> then we can make the choice incrementally as we go along
[12:54] <SteveA> starting with "run it all"
[12:54] <SteveA> then analysing each one in turn as we need to
[12:54] <SteveA> the two we want to analyze first are bzr and cscvs
[12:55] <stub> We know cscvs and bzr are one way dependancies, so the spec explicitly states they are the only things that get turned off initially.
[12:55] <SteveA> there really is no need to have either a perfect technological solution or to analyze all the cases before making this initial improvement
[12:56] <spiv> stub: <spiv> Lots of them are obvious: sqlobject, twisted, zope are all clearly not dependent on launchpad.
[12:56] <lifeless> is there a spec now ?
[12:56] <lifeless> link me up
[12:56] <lifeless> SteveA: the second point I made was to have a mechanism for doing it.
[12:56] <spiv> stub: So, changing check_merge isn't trivial -- the extra tests are run from a seperate makefile.
[12:56] <stub> (17:32:11) stub: Who wants to review or approve https://launchpad.net/products/launchpad/+spec/stop-spurious-test-failures ?
[12:56] <SteveA> stub has proposed a mechanism
[12:57] <spiv> stub: take a look at sourcecode/Makefile
[12:57] <stub> spiv: Sure - you need to add a new rule to the sourcecode/Makefile too.
[12:57] <spiv> Ok.  I didn't see any mention of that in the spec.
[12:57] <stub> I would have assumed it was obvious to anyone attempting to implement it
[12:58] <stub> Added Makefiles for dummies to code changes
[12:59] <spiv> Ta :)
[12:59] <lifeless> review meeting in 1 minute
[12:59] <lifeless> stub: +1
[12:59] <lifeless> that looks fine to me, tell me when the new target is present, I'll update pqm.conf
[12:59] <lifeless> or you can
[01:00] <stub> Ok. I mentioned the idea to kiko so he might have already started. I'll point him at the spec and get him to assign an implementer
[01:00] <lifeless> may I suggest spiv
[01:00] <lifeless> as he has done Makefile tweaking there already
[01:01] <stub> Fine by me. I suck at Makefiles ;)
[01:01] <spiv> stub: So do I, just no-one has noticed yet ;)
[01:02] <spiv> But sure, I can do this, it looks straightforward.
[01:02] <lifeless> who is here for the review meeting ?
[01:02] <lifeless> * agena
[01:02] <lifeless> * next meeting
[01:02] <jamesh> me
[01:02] <lifeless> * queue status
[01:02] <BjornT_> me
[01:03] <SteveA> all these strange people whose names start with "* "
[01:03] <SteveA> i am here
[01:03] <spiv> me
[01:03] <lifeless> next meeting - 17th Jul, same time & place ?
[01:04] <SteveA> i may or may not be here, depending what's going on at the management meetings
[01:04] <spiv> sure
[01:04] <lifeless> SteveA: please add an apology as appropriate when you know
[01:04] <lifeless> ok, queue status
[01:04] <lifeless> spiv: whats up with 9 days ?
[01:05] <spiv> lifeless: it's big.
[01:05] <spiv> I'm nearly done.
[01:05] <lifeless> ok
[01:05] <lifeless> I see you have another big on
[01:05] <lifeless> *one*
[01:05] <lifeless> I'll be interested to see the time it takes
[01:05] <lifeless> I'm wondering if its non-linear to review big branches
[01:05] <spiv> I think I may punt salgado/launchpad/real-karma-context back to rejected, I'll take a look and decide very soon.
[01:06] <spiv> I'll make sure to include the review time, I haven't added it up yet (it's been done over several sessions).
[01:06] <SteveA> it may be helpful for the author of the code to summarize their changes at a higher level
[01:06] <SteveA> sort of do a self-review first
[01:06] <SteveA> this could help a reviewer get the idea of what's going on quicker
[01:06] <spiv> by "back to rejected", I mean rejected from my queue, rather than rejecting the code...
[01:07] <jamesh> that was definitely useful when I was reviewing the mega-soyuz branch back in London
[01:07] <SteveA> particularly if there is a higher-level pattern of refactoring that is implemented in a bunch of changes
[01:07] <lifeless> ok
[01:07] <spiv> SteveA: You mean more than the one or two sentences people add to PendingReviews?
[01:07] <lifeless> other than that its in good shape
[01:07] <jamesh> Kinnison and cprov were able to give an overview and suggest an order to review the parts of the patch in
[01:07] <SteveA> spiv: not really
[01:08] <spiv> I find the descriptions on PendingReviews help my understanding quite a lot.
[01:08] <SteveA> spiv:  I mean for the author to take a diff and reply to it, like in an email, like reviewers do
[01:08] <SteveA>  with > + whatever
[01:08] <SteveA> at the start of lines
[01:08] <SteveA> btw, lifeless, I find reviews easier to read when they have email-style indenting "> + whatever" rather than just "+ whatever"
[01:08] <SteveA> I think all the reviewers use the former style except you
[01:09] <lifeless> spiv: I'm moving malc's branch to jamesh if thats ok, as its at 5 days 
[01:09] <lifeless> SteveA: interesting. I find the > gets in the way of reading the code.
[01:09] <lifeless> as I'm using to looking at normal diffs on my screen.
[01:09] <SteveA> I find its absence gets in the way of reading the comments
[01:09] <spiv> jamesh: Yeah, I often wish the diff was in a slightly better order -- e.g. doctests for a feature before the code implementing the feature.  Although the "added files first" heuristic bzr has is a good approximation of that.
[01:09] <spiv> lifeless: ok
[01:09] <spiv> I agree with SteveA.
[01:09] <SteveA> also, its presence reflects the review as a conversation that starts with the code diff
[01:10] <SteveA> and is followed by a reply / comments
[01:10] <lifeless> in which case, jamesh - can you make pending-reviews spit it out in that format please ?
[01:10] <SteveA> and is followed by more replies to the comments
[01:10] <BjornT_> i wouldn't like pending-reviews to automatically indent it, though
[01:10] <SteveA> I actually asked for the following a while ago...
[01:10] <spiv> lifeless: oh no, you'll break my "copy, paste, highlight, quote" muscle memory!
[01:10] <lifeless> BjornT_: why not ?
[01:10] <SteveA>  - a link on the pending reviews page that serves up the diff
[01:10] <SteveA>  - indented appropriately
[01:11] <jamesh> spiv: I think the added files, removed files, changed files ordering is just an artefact of the way it generates a diff
[01:11] <lifeless> BjornT_: actually, I've given pagetest-tweaks to you to review.
[01:11] <SteveA>  - with a custom mime-type x-code-to-review
[01:11] <spiv> jamesh: it might be an accident, but it's a good one
[01:11] <SteveA> this would allow me to register a helper app to handle the review with a single click
[01:11] <danilos> hi SteveA 
[01:11] <lifeless> SteveA: I'm +1 on the rest, but not the mimetype. I'd prefer it stays text/something
[01:11] <BjornT_> when i review i find it easier to read the real diff. but in a review email, it's easier to read if the diff is indented, since it makes it easy to see what the comments are.
[01:11] <SteveA> I'd prefer to have the ordering semantically meaningful like: changed interfaces, changed tests, changed code
[01:11] <lifeless> SteveA: if you mean text/x-code-to-review, then thats fine by me
[01:12] <SteveA> lifeless: yes
[01:12] <spiv> lifeless: I think I agree with Bjorn -- for reading a straight diff, indentation/">"-quoting is pointless.  "> " helps if you're reading comments on a diff.
[01:12] <SteveA> I want to keep the links to diffs as plain diffs, as they are now
[01:12] <SteveA> hi danilos
[01:13] <lifeless> spiv: I do the review in an editor window, so I'm reading the plain diff - thats how I find it easiest to review.
[01:13] <lifeless> spiv: which is why my comment is about reading the code.
[01:13] <lifeless> moving on, as there is a clear route forward
[01:14] <lifeless> Actions from the last meeting: * stevea to add note about operator.attrgetter being better than trivial lambdas to lp coding guidelines
[01:14] <lifeless> SteveA: did you do that ?
[01:14] <SteveA> yes
[01:14] <spiv> lifeless: Ah, I keep it in the browser, so I can refer back to code I've elided from the review, and possibly re-include it if I realise due to later code I have a comment on iot.
[01:14] <SteveA> i'll also note that guido said at EP
[01:14] <SteveA> and at PyCon
[01:14] <SteveA> that lambda is staying for python 3
[01:14] <lifeless> spiv: I find that awefully cumbersome. Still, I'm going to change to be like the rest of the boys
[01:14] <jamesh> spiv: I do similar.
[01:15] <jamesh> browser + editor
[01:15] <spiv> lifeless: it's not ideal, but it's the best system I've found for me.
[01:15] <jamesh> works well with two monitors :)
[01:16] <SteveA> carlos: ping
[01:16] <SteveA> lifeless: you ought to be able to just post-process your review
[01:16] <SteveA> lifeless: to use sed or awk to insert the quoting
[01:16] <BjornT_> for me it works quite well to use only an editor, >-indenting the part that i comment on in a first run. then the second run i delete what's not needed.
[01:16] <lifeless> SteveA: sure, its just cumbersome - its an extra tool.
[01:17] <lifeless> rather than brower + email, its browser + vim + email.
[01:17] <spiv> lifeless: vim is my email ;)
[01:17] <SteveA> set up procmail to filter it ;-)
[01:17] <lifeless> shoo
[01:17] <lifeless> meeting over in 3
[01:17] <SteveA> ah
[01:17] <SteveA> i have a point
[01:17] <lifeless> meeting countup on hold
[01:17] <SteveA> lifeless: there's a spec somewhere about better messages from pqm
[01:18] <SteveA> and tied into that, the bzr httpd running on the place we keep our branches
[01:18] <SteveA> so that we can do things like have links to see what's in a [trivial]  patch
[01:18] <SteveA> what do we need to do to make it happen?
[01:18] <SteveA> (1. find the spec)
[01:19] <SteveA> https://launchpad.net/products/launchpad/+spec/pqm-commit-messages
[01:19] <lifeless> find the spec, let me review it by the next meeting
[01:19] <lifeless> then assign it to a team or person
[01:19] <SteveA> it's rated "low" by mark/kiko
[01:20] <lifeless> that one I have read, so, I will review in detail for next meeting.
[01:20] <SteveA> but I think it is important to make incremental improvements in that direction
[01:20] <SteveA> particularly as we're getting non-trivial trivials landing
[01:20] <lifeless> one thing we can do right now is setup bzr webserve
[01:20] <lifeless> that will allow click-through analyse of the commits with no code changes
[01:20] <spiv> lifeless: that's a great idea
[01:20] <lifeless> so is a cheap win
[01:21] <SteveA> great.  please.
[01:21] <lifeless> ok
[01:21] <SteveA> also also, when do we move to the new box?
[01:21] <SteveA> stub: ^^^^ ?
[01:21] <SteveA> I don't know who is involved
[01:21] <lifeless> anything else for this meeting ?
[01:22] <SteveA> but I heard the new dev box to replace launchpad team use of chinstrap is ready
[01:22] <lifeless> 2
[01:23] <lifeless> 1
[01:23] <SteveA> lifeless: I believe you have something to do with the new box, and moving all old branches to knit format on it.
[01:23] <SteveA> maybe tell me what's happening after this meeting
[01:23] <lifeless> nothing to do with getting onto the new box
[01:24] <lifeless> probably I need to be involved, but am not at the moment
[01:24] <SteveA> ok
[01:26] <jamesh> SteveA: as part of the review fixes for one of my branches, I needed to expose the SQLObject syncUpdate() operation.  I did it by adding a new canonical.launchpad.interfaces.ISQLObjectSyncable interface
[01:26] <jamesh> SteveA: spiv was okay with it but wanted another reviewer's opinion on the naming.  Does it sound okay to you?
[01:27] <lifeless> works for me
[01:27] <SteveA> I think any sqlobject should by syncable by the application code.
[01:28] <SteveA> But also, this API isn't really about the content objects.
[01:28] <SteveA> So, I have two things to suggest:
[01:28] <spiv> (The original issue is that foo.syncUpdate() often more appropriate than flush_database_updates(), but security proxies tend to disallow that at the moment)
[01:29] <jamesh> hmm
[01:29] <SteveA> 1. Check to see if an object is an instance of the base sqlobject class we use, in the security policy, and allow that method for all of them. 
[01:29] <SteveA> or
[01:29] <jamesh> adding the method to canonical.database.interfaces.ISQLBase would probably be cleaner
[01:29] <SteveA> 2. have a function that you apply to an instance, removing its security proxy and calling that method
[01:29] <jamesh> (since sync() and syncUpdate() can't be destructive)
[01:29] <SteveA> the function is used for just that
[01:30] <stub> SteveA: If you mean a new box for bzr hosting Launchpad code, I have not been involved.
[01:30] <SteveA> because of the way security works today, adding this to an interface isn't really involved in making that call available
[01:31] <SteveA> so, it would be more just for documentation
[01:31] <SteveA> stub: okay.  so, who is involved, I wonder...
[01:31] <lifeless> replacement chinstrap for us AFAIK
[01:31] <SteveA> lifeless will have to be involved for ensuring our place for branches is correct
[01:31] <SteveA> spiv on running a smartserver on there, eventually
[01:32] <SteveA> someone for setting up the bzr web server on there
[01:32] <SteveA> jamesh to set up pending reviews etc.
[01:32] <SteveA> moving error reports rsyncing over...
[01:32] <stub> So will smartserver and pqm coexist, or will smartserver supersede the PQM functionality we use?
[01:32] <lifeless> coexist
[01:32] <SteveA> they're different
[01:32] <jamesh> SteveA: how would (1) be done?
[01:33] <SteveA> jamesh: there's a module inside webapp... authorization.py I think
[01:33] <SteveA> inside there, the security policy code needs a check added to say
[01:33] <SteveA>   if name == 'syncUpdate' and  isinstance(obj, SQLBaseWhatever):
[01:33] <SteveA>        return True
[01:34] <SteveA> this code, being some of the oldest in Launchpad, probably isn't properly tested
[01:34] <SteveA> at least, not explicitly
[01:34] <stub> (I missed the earlier discussion, but I would have thought we could just make SQLBase implement an interface defining that method and make it available to logged in users.)
[01:35] <SteveA> not really
[01:35] <jamesh> SteveA: thanks.  I'll look at doing that then.
[01:35] <SteveA> because of how the security system works with interfaces
[01:35] <SteveA> that's roughly how things will work in the future
[01:36] <SteveA> there's some zope stuff to change first, and that's a new-webapp thing
[01:36] <jamesh> stub: would security declarations for SQLBase apply to the subclasses though?
[01:36] <jamesh> stub: (for reference, SQLBase does implement an ISQLBase class)
[01:37] <SteveA> jamesh: the adaption wouldn't work out right
[01:37] <jamesh> SteveA: that's what I thought.
[01:37] <SteveA> the interface would apply on subclasses, but most likely the right adapter would not be chosen
[01:37] <glatzor> carlos: thanks. I just received my emails from Rosetta.
[01:37] <carlos> glatzor: cool
[01:38] <SteveA> so, stick it in the global security policy, and we'll refactor later on
[02:02] <stub> My fever is returning so I'm off for the evening.
[02:02] <stub> (no - not disco fever)
[02:11] <stub> Are we supposed to arrive the Saturday or the Sunday before our sprint?
[02:21] <carlos> danilos: hi
[02:21] <danilos> hi carlos
[03:21] <salgado> SteveA, around?
[03:42] <salgado> or BjornT?
[03:42] <BjornT> hi salgado 
[03:44] <salgado> hi BjornT. can you help me with some vhosting issues?
[03:44] <BjornT> sure
[03:48] <salgado> in shipit, all browser:url declarations are meant to work only when using a setup similar to the production one. that is, it assumes the root url is /shipit-ubuntu
[03:49] <salgado> this means that, if you access shipit through launchpad.dev/shipit-ubuntu/something, you'll get some broken links pointing to launchpad.dev/something-else
[03:50] <salgado> this is a problem when I use getLink('foo').click() on new pagetests
[03:51] <salgado> I was wondering if it'd be possible to configure a new rootsite that would allow me to test this properly, without breaking it in production
[03:54] <BjornT> salgado: i think it's better for SteveA to answer that question, i'm not sure how shipit is setup in production.
[03:56] <salgado> we use some apache RewriteRules there
[03:58] <kiko> morning
[04:04] <flacoste> morning kiko!
[04:04] <kiko> how are you francis?
[04:05] <danilos> g'morning kiko :)
[04:05] <flacoste> fine for a monday morning :-)
[04:05] <kiko> danilos!
[04:06] <kiko> good to see you around
[04:06] <kiko> flacoste, you know your adapters idea? I think you should talk to SteveA about it. I think it's a great idea but there is a caveat in doing so...
[04:07] <flacoste> kiko: do you remember what caveat?
[04:07] <kiko> :)
[04:07] <kiko> yes, I do, but let's see what SteveA says first. :)
[04:08] <flacoste> kiko: OK, I'll mail SteveA with a request for comment
[04:08] <kiko> remember to nag him
[04:08] <kiko> or he will take 1000 years
[04:09] <flacoste> kiko: should I move on with adding the search method then?
[04:09] <kiko> well
[04:10] <salgado> has anybody seen something like https://chinstrap.ubuntu.com/~dsilvers/paste/filenNkpXQ.html?
[04:10] <salgado> BjornT, maybe you know what's going on there ^^?
[04:10] <salgado> I think I've seen this before, but I'm not sure
[04:11] <kiko> flacoste, is that work going to be useful no matter what high-level design you choose
[04:11] <flacoste> kiko: it will, we need to be able to search tickets
[04:11] <salgado> BjornT, yeah, it's bug 49905
[04:11] <salgado> https://launchpad.net/products/launchpad/+bug/49905
[04:12] <kiko> flacoste, then fine. but try getting in a phone call with stevea
[04:12] <mdke> when I am getting bug notifications by virtue of being subscribed to a duplicate of the bug, is there an easier way for me to unsubscribe except for going through all the duplicates of the bug to see which one it is that I am subscribed to?
[04:13] <kiko> mdke, not yet, but that's a bug and bradb_ and I have discussed a solution for it.
[04:13] <flacoste> we even have a bug for that, bug 50564
[04:13] <Ubugtu> Malone bug 50564 in launchpad-support-tracker "No way to search support requests" [Medium,Confirmed]  http://launchpad.net/bugs/50564
[04:13] <mdke> kiko: coolio
[04:13] <flacoste> kiko: phone call with Steve, for the adapter refactoring or for the search method?
[04:13] <kiko> flacoste, for the former
[04:14] <mdke> kiko: how about that, it was the first duplicate :)
[04:15] <kiko> mdke, see, sometimes our luck just holds
[04:18] <mdke> :)
[04:24] <kiko> bradb, have a time to glance at that patch of mine?
[04:25] <bradb> kiko: The one on launchpad@? I saw stub responded to it.
[04:25] <kiko> yeah
[04:25] <carlos> SteveA: hi, around?
[04:25] <kiko> bradb, do you want to take a look at it or should it just go
[04:26] <bradb> kiko: Hm, maybe I should do a once-over.
[04:26] <kiko> hey ddaa?
[04:26] <kiko> bradb, good idea
[04:37] <bradb> kiko: so, I'd add a comment to _processOrderBy, for PEP 8 compliance
[04:38] <kiko> bradb, sure, good point.
[04:39] <bradb> kiko: punctuation/spelling:  "This list's columns which are, in practical terms, unique."
[04:39] <bradb> s/  / /
[04:40] <bradb> kiko: The next comment, I'd write as "Bug ID is unique within bugs on a product or source package."
[04:41] <ddaa> kiko: pong
[04:42] <bobbin> Is it possible to flie bugs with attachments? When I was filing a report at launchpad.net I couldn't see how.
[04:43] <ddaa> bobbin: There's an "add attachement" link in the top left box
[04:43] <ddaa> there's work in progress to make that more visible
[04:44] <bradb> kiko: I might tighten up the stable sorting comment to:
[04:44] <bradb> # Sort keys that guarantee (with rare exceptions, like test data) a
[04:44] <bradb> # stable sort. If not provided, we will make the sort stable by
[04:44] <bradb> # appending BugTask.bug and BugTask.id later on.
[04:47] <bobbin> ddaa: thanks. I quickly got 'flamed' & works for me'd for filing a short bug (not too clearly), to which I would've attached clarifying screenshots, had I seen the link.
[04:47] <kiko> bradb, cool -- anything else?
[04:47] <ddaa> kiko: repong
[04:47] <kiko> ddaa, matsubara told me of bug 52313. do you know about it?
[04:47] <Ubugtu> Malone bug 52313 in launchpad-bazaar "Importing a CVS repository as a bzr branch does not work at all" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52313
[04:48] <ddaa> kiko: sure I know about it, it's my cross
[04:48] <kiko> ddaa, does this bug essentially bzr-native-imports?
[04:48] <ddaa> it works, about as much as a tetraplegic newborn
[04:49] <bradb> kiko: My other main concern is the assumption about datecreated being stable, but I guess the test suite will tell, because I /think/ it would mainly be an issue in the test suite.
[04:49] <ddaa> kiko: nope, it's "make imports not require manual driving from a vcs-imports member"
[04:49] <kiko> bradb, agreed.
[04:49] <ddaa> kiko: which depends on bzr-native
[04:49] <kiko> ddaa, ah. okay.
[04:49] <kiko> ddaa, can you kick that one manually?
[04:49] <bradb> (likewise with dateassigned, etc.)
[04:50] <ddaa> kiko: I can give it some love, I hoped to get some code done today, but apparently it's not the day :(
[04:50] <bradb> kiko: What's the plan there? Wait and see?
[04:51] <kiko> bradb, yep. I'm about to land it with your suggestions
[04:51] <bradb> kiko: ok, sounds good, thanks.
[04:53] <ddaa> kiko: interestingly, it's also a case of "+source for CVS confuses people utterly"
[04:53] <ddaa> root=:pserver:anonymous@beaver.cvs.sourceforge.net:/cvsroot/beaver
[04:53] <kiko> that page is utterly confusing indeed
[04:53] <ddaa> module=cc
[04:53] <ddaa> branch=MAIN
[04:53] <ddaa> module should be "beaver" (sourceforge naming policy)
[04:53] <ddaa> actually, branch=HEAD
[04:54] <ddaa> branch should be MAIN (no other value is legal here since Montreal)
[04:54] <ddaa> kiko: also, I _still_ cannot post +sourceadmin!
[04:55] <kiko> ddaa, remind me why is that broken? permissions?
[04:55] <ddaa> yeah
[04:55] <kiko> ddaa, land the one-liner dude
[04:56] <ddaa> it's probably more involved than you think
[04:57] <ddaa> ahttps://launchpad.net/products/launchpad-bazaar/+bug/42928
[04:57] <Ubugtu> Malone bug 42928 in launchpad-bazaar "vcs-imports needs tests" [High,Confirmed]  
[04:57] <ddaa> I can get things done by poking the db manually anyway
[04:59] <kiko> carlos, what is the potranslation table?
[05:00] <kiko> ddaa, I thought it was just a permissions fix
[05:00] <ddaa> it is just a permission fix, a very large one, with accompanying tests
[05:01] <carlos> kiko: the table that stores all translations
[05:02] <carlos> kiko: pomsgid table stores the english ones and the other the translations
[05:02] <kiko> carlos, what is it used for? I thought we stored these in posubmission?
[05:02] <carlos> no
[05:02] <kiko> carlos, why is having potranslation separate from posubmission useful?
[05:02] <carlos> posubmission link those translations with pomsgset
[05:03] <carlos> kiko: because you can have the same translation for different pofiles
[05:03] <carlos> for instance, evolution in hoary vs. evolution in breezy
[05:03] <kiko> carlos, sure. but does that matter?
[05:04] <SteveA> salgado, BjornT: pong
[05:04] <carlos> kiko: a lot, unless you want to repeat again and again the same string
[05:04] <SteveA> kiko, flacoste: pong
[05:04] <SteveA> carlos: pong
[05:04] <carlos> kiko: one potranslation row could be used 3-4 times
[05:04] <kiko> carlos, hmmm. I don't see that being such a big advantage, but ok.
[05:05] <carlos> kiko: if we don't use a separate table, we would need it 3-4 times inside posubmission
[05:05] <flacoste> SteveA: do you have time to discuss https://launchpad.canonical.com/ITicketTargetAdapter
[05:05] <carlos> SteveA: do you have time for the meeting with danilos ?
[05:06] <SteveA> flacoste: I can discuss it briefly today.  There are some caveats, as kiko pointed out.
[05:06] <SteveA> carlos: yes, how about at 30 minutes past?
[05:07] <SteveA> it is 6.07pm for me now
[05:07] <flacoste> SteveA: how do you want to do this: phone, irc, mail?
[05:07] <carlos> danilos: is that ok for you?
[05:07] <SteveA> so at 6.30
[05:07] <carlos> SteveA: that's fine for me
[05:08] <danilos> SteveA, carlos: that sounds a bit too late
[05:08] <carlos> danilos: it's 5.30 for you
[05:08] <SteveA> 22 mins from now
[05:08] <danilos> I need to be in the British embassy before 19h, and it depends on how long it takes
[05:09] <danilos> SteveA: sure then, lets try it then
[05:09] <SteveA> ok
[05:09] <SteveA> flacoste: let's try irc to start with
[05:09] <SteveA> flacoste: after my call with danilo and carlos
[05:09] <flacoste> SteveA: fine, just ping me when you're ready
[05:09] <SteveA> kiko: are you available on irc then too?
[05:11] <carlos> SteveA: hmm, I think danilo told me that he lacks a headset so this meeting should be on irc
[05:11] <SteveA> ok
[05:11] <danilos> carlos, SteveA: that's right, I don't have it with me
[05:12] <kiko> SteveA, not really, I'm quite busy
[05:13] <SteveA> kiko: ok, np.  we should have a call sometime, btw
[05:14] <kiko> sure thing
[05:18] <ddaa> mh, I'm the one confused, the beaver cvsmodule was correct
[05:29] <danilos> SteveA, carlos: ping?
[05:30] <SteveA> hey
[05:30] <SteveA> let's hop over to #launchpad-meeting
[05:32] <danilos> SteveA: I'm in
[05:33] <SteveA> carlos_: -> #launchpad-meeting
[05:33] <carlos_> SteveA, danilos: Hi, sorry, I don't know what's going on with my irc connection today...
[05:33] <Kreuger> hi
[05:33] <Kreuger> I was wondering if osmeone can help me
[05:34] <carlos> Kreuger: just ask and we will try to help you
[05:34] <Kreuger> how do I close a project and team I created?
[05:39] <ddaa> mh... looks like svn://opensource.ikse.net crashed...
[05:48] <ddaa> kiko: can you tick the checkbox there, please https://launchpad.net/products/picard/main/+sourceadmin
[05:51] <ddaa> kiko: can you also copy the svn details from there https://launchpad.net/products/wormux/0.7 to there https://launchpad.net/products/wormux/trunk
[05:52] <kiko> ddaa, it's unauthorized for me too.
[05:52] <ddaa> you're admin?
[05:52] <kiko> yes
[05:53] <kiko> ddaa, looks like a real bug
[05:53] <ddaa> man
[05:53] <kiko> or something in the security handlers
[05:53] <kiko> ddaa, if you explain /how/ this should work matsubara should be able to fix it.
[05:53] <carlos> Kreuger: I don't think we have a way to do it
[05:53] <ddaa> this form is thoroughly broken, something like the last 10 "fixes" have been done by folks not understanding what it should do, based on summary information
[05:54] <carlos> Kreuger: Why do you want to do it?
[05:54] <ddaa> kiko: that's why there's a bug saying that it should have tests
[05:55] <ddaa> I think I'll bump this bug to critical and pub bzr-native and do it before doing anything more on bzr-native...
[05:56] <Kreuger> because I've found it much too confusing, you have to link to external bugtrackers and such. a friend has set up another system that I will be using instead.
[05:57] <kiko> ddaa, doesn't sound like a bad idea given it won't be as much work as bzr-native!
[05:57] <ddaa> matter of priorities...
[05:58] <kiko> ddaa, prioritizing short tasks is often wise
[05:58] <ddaa> the boss made it absolutely crystal clear that I'm not to do anything but get good native-bzr imports from svn, and anything distracting me from getting there should be offloaded.
[05:58] <ddaa> Well, I think the +sourceadmin breakage got to the point when I need to spare the time to spec it out enough to offload it...
[06:00] <carlos> Kreuger: ok, please, mail launchpad-users@lists.ubuntu.com with your request
[06:00] <carlos> Kreuger: also, would be really helpful if you could add some comments about why did you choose the other system instead of launchpad
[06:00] <carlos> but it's not a requirement, just some input to see what would we improve
[06:00] <Kreuger> alright
[06:04] <kiko> BjornT, ping?
[06:05] <SteveA> flacoste: ping
[06:05] <flacoste> SteveA: pong
[06:06] <SteveA> BjornT, salgado: there was a vhosting issue.  I'd like to discuss it after I have a brief chat with francis.
[06:06] <SteveA> flacoste: #launchpad-meeting please
[06:06] <flacoste> /joing #launchpad-meeting
[06:09] <Kreuger> thanks for the help carlos
[06:09] <carlos> Kreuger: you are welcome
[06:29] <SteveA> salgado: ping
[06:30] <salgado> SteveA, pong
[06:31] <kiko> BjornT, ping?
[06:31] <SteveA> salgado: you pinged me earlier about some vhosting issue with shipit
[06:31] <SteveA> I have 30 mins before going to the gym
[06:32] <salgado> SteveA, yeah. I wanted to check with you if we can do something similar to what we do with blueprint to have a shipit.launchpad.dev
[06:32] <SteveA> salgado: yes, i'd like to do that, one for each shipit domain
[06:33] <SteveA> salgado: we need to plan it carefully to check on localhost, on staging, and in production
[06:33] <SteveA> it also needs a slightly different setup than blueprint
[06:33] <salgado> exactly. that was my concern
[06:33] <SteveA> because it has a different root object
[06:34] <salgado> I guess you don't have time for this planning now?
[06:34] <SteveA> if things aren't causing a problem right now, I'd like this to wait for me to do it.  but if you want to get this done, I can give you some pointers and then I can review later.
[06:34] <SteveA> I'm fine with either, if you want to do shipit maintenance
[06:35] <SteveA> I'm a bit concerned about doing it for next week, if everything is working fine now
[06:35] <SteveA> because I may not be around next week for the rollout
[06:35] <salgado> it can wait, no problem
[06:35] <SteveA> otoh, if bjorn is around, he'll be able to handle it
[06:35] <SteveA> as he knows that code well
[06:35] <SteveA> salgado: would you file a bug about it?
[06:35] <SteveA> the basic sketch is:
[06:35] <salgado> the only trouble it causes is that I can't use the new-style pagetests' getLink() and co
[06:36] <SteveA>  - add three shipit host lines to the conf files
[06:36] <SteveA>  - add a new publications that knows about the shipit root objects
[06:36] <SteveA>  - tell people to update their /etc/hosts if they need to test locally
[06:37] <SteveA>  - change apache setup on staging not to to vhosting in the URL 
[06:37] <SteveA> you should be able to use the new-style pagetest stuff
[06:39] <carlos> see you!
[06:45] <BjornT> kiko: pong
[06:47] <SteveA> the solution is to replace shipit's custom canonical_url data implementation with one that uses the new conf file + siteroot in browser:url
[06:47] <SteveA> then new style testbrowser tests can be written for shipit
[06:48] <SteveA> and this is half way to having full new-style vhost support for shipit
[06:49] <kiko> BjornT, too late, I need to hop out for lunch, ping you when I'm back
[07:07] <salgado> BjornT, do you know the circunstances in whith we pass request=None to canonical_url()?
[07:08] <doko> bradb: ping
[07:15] <BjornT> salgado: well, what do you mean? we usually pass request=None to canonical_url
[07:17] <salgado> yeah, that was confusing, sorry BjornT. my questions actually is, in what circunstances we can reach the end of canonical_url() having a request == None
[07:19] <BjornT> salgado: ah. basically when you use canonical_url from a script you don't have a request, so it will be None and we'll use root_url instead.
[07:20] <Mez> whats up with Rosetta ?
[07:24] <Mez> OOPS-191B468
[07:24] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/191B468
[07:25] <jordi> ugh, I really am quite uninspired to write stuff today
[07:25] <jordi> can anyone cluebat me at https://help.launchpad.net/RosettaNewImportPolicy?action=diff&rev2=2&rev1=1 ?
[07:27] <salgado> Mez, I think it's a reported bug.
[07:27] <salgado> BjornT, ah, I see. I guess I have a problem, then
[07:28] <matsubara> Mez: carlos is looking into that problem. We'll have a fix for it this week I think.
[07:28] <bradb> doko: pong
[07:28] <salgado> BjornT, have you seen Steve's sugestion to solve the vhost issue we talked about earlier?
[07:28] <Mez> matsubara, cool - I was bored and started translating it into english
[07:32] <BjornT> salgado: yeah, i saw it. i can't see what the problem is, though.
[07:34] <kiko> BjornT, ping
[07:34] <BjornT> pong
[07:35] <kiko> BjornT, so I'm doing the fix for bugcomment optimization
[07:35] <kiko> BjornT, part of that requires me moving BugComment to database/
[07:35] <kiko> are you okay with that?
[07:37] <salgado> BjornT, the problem is that the layer we're in is stored in the request, and we need different root URLs for each layer
[07:38] <BjornT> kiko: well, it depends on what changes you did. but if it really requires you to move it, i don't have a problem with it.
[07:38] <kiko> BjornT, basically, I need to construct the message objects inside a method in bugtask.
[07:39] <kiko> BjornT, I construct them in a way which requires only 2 queries instead of N*2 queries.
[07:39] <kiko> but to do so I need to issue two special queries -- one on attachments and one on chunks
[07:39] <kiko> then I amalgamate the two together into bugcomments
[07:41] <BjornT> ok, sounds good.
[07:43] <kiko> that's why I need them to be created in database code
[07:43] <kiko> and to maintain code dependency policy..
[07:46] <salgado> BjornT, you see the problem? I need a single new rootsite (shipit), but I need three new root_urls, and I need to decide which root_url to used based on the request
[07:55] <BjornT> salgado: aren't you going to add three config items as for the blueprint site? (i.e both hostname and root_url)
[07:56] <salgado> BjornT, yes, I think a need bogh hostname and root_url for each of shipit-ubuntu, shipit-kubuntu and shipit-edubuntu
[08:02] <salgado> BjornT, but then I can't have three new rootsites --I need to have a single one
[08:14] <BjornT> salgado: hmm, better check with steve how he wants it. for now you should be able to get it to work if you leave rootsite as None. that way it will pick up the correct url from the request.
[08:15] <matsubara> anybody seen this before: OOPS-190B176?
[08:15] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/190B176
[08:16] <kiko> matsubara, not be
[08:39] <SteveA> matsubara: that's an interesting exception.  have you seen it in any other reports?
[08:39] <matsubara> SteveA: nope, first time and only once.
[08:40] <matsubara> SteveA: have any idea of what could have caused that?
[08:41] <SteveA> I have an idea what it's about.
[08:41] <SteveA> I'm asking jim fulton.
[08:55] <CarlFK> how do I reject a bug I reported ?  (I am logged in to lp, looking at the bug)
[08:56] <matsubara> CarlFK: click on the name of the product/source package under Affects columns
[08:58] <CarlFK> thanks 
[09:02] <bradb> bug 1095, fwiw
[09:02] <bradb> CarlFK: ^^
[09:03] <CarlFK> yup
[09:10] <SteveA> matsubara: I have an idea
[09:10] <matsubara> SteveA: what is it?
[09:11] <SteveA> it looks like a combination of an edge case in the component architecture (zope adapter registration stuff) and perhaps a leaky sqlobject cache.  BugTask has some interesting stuff in its _init where it uses alsoProvides to stick extra interfaces on an object
[09:11] <SteveA> it's possible that was an edge case of some sqlobject problem combined with a component architecture "being too paranoid" problem
[09:12] <SteveA> if it happens again, let me know
[09:12] <matsubara> SteveA: ok, I'll. Should I report a bug about it to keep track of that issue?
[09:12] <SteveA> sure, can do.
[09:14] <LaserJock> what's currently the best way of getting info from LP for scipting use? wget URls?
[09:16] <bradb> LaserJock: Imagination. But http://ploum.frimouvy.org/?115-conseil-001-in-the-middle-of-the-boxes might give you some ideas.
[09:17] <LaserJock> bradb: oh, I've already got the imagination, it's just a matter of getting anythin useful out of it ;-)
[09:17] <bradb> heh
[09:18] <LaserJock> bradb: I doubt people will be happy with me if I start uploading imaginary bug fixes :-)
[10:25] <kiko> BjornT, bradb: have a working fix for the bugcomment performance issue.
[10:29] <flacoste> is there an example of a reusable interface test in launchpad?
[10:30] <flacoste> i would like to define a base interface tests for ITicketTarget and use it on the three implementation we have
[10:30] <flacoste> instead of copy/pasting the basic test across implementation
[10:31] <flacoste> i guess that was a question for BjornT or kiko...
[10:33] <kiko> flacoste, I think there are things in ftests that are reusable. I'm not familiar with them, though
[10:37] <bradb> kiko: Cool. I'm just reviewing my diff for the security/privacy collapsing + some other refactoring + fixing some related bugs along the way (like making sure the correct radio button is selected when making an error entering the package name)
[10:39] <kiko> cool.
[11:09] <kiko> bradb, BjornT: have time for a review?
[11:10] <bradb> kiko: I can do it, if it's short.
[11:10] <kiko> bradb, it's short-ish, but you scratch my back etc
[11:11] <kiko> https://chinstrap.ubuntu.com/~dsilvers/paste/file4AodVa.html
[11:12] <bradb> Just adding my branch to PR, then will look.
[11:16] <bradb> kiko: what bug is this meant to fix?
[11:19] <kiko> bradb, one of the performance bugs, one sec.
[11:19] <kiko> bug 42755