[00:01] <wgrant> Hm, so staging just slept for 3 hours.
[00:05] <thumper> wgrant: everyone needs a break now and then :)
[00:06] <lifeless> I'm chatting to elmo about it. Or maybe just depressing him, I dunno.
[00:07] <lifeless> thumper: https://lpstats.canonical.com/graphs/OopsEdgeHourly/20100712/20100811/
[00:07] <lifeless> https://lpstats.canonical.com/graphs/OopsLpnetHourly/20100712/20100811/
[00:17] <lifeless> wgrant: so, staging did a 5.5 hour update
[00:17] <wgrant> lifeless: Looks like it did a 2.5 hour update, as usual.
[00:18] <wgrant> It normally goes right back to checking for updates...
[00:18] <wgrant> Or was this case special, in that it logged completion then did more stuff?
[00:21] <lifeless> wgrant: that log doesn't log start + finish
[00:24] <lifeless> http://www.newscientist.com/article/dn19287-p--np-its-bad-news-for-the-power-of-computing.html
[00:47] <wgrant> lifeless: No, but look what it does normally.
[00:47] <wgrant> lifeless: It disappears for 2.5 hours, then logs the update.
[00:47] <wgrant> Then makes the next 14/44 check.
[01:05] <lifeless> how does one subscribe on the dev wiki? I get an error about permissions
[01:05] <lifeless> when I do 'subscribeUser'
[01:06] <wgrant> lifeless: The subscribe action isn't shown.
[01:06] <wgrant> You have to hack the URL.
[01:06] <wgrant> ?action=subscribe
[01:06] <lifeless> so, we expose a subcribe action that doesn't work, and don't show the one that does?
[01:06] <lifeless>  /win
[01:06] <wgrant> That's correct.
[01:07] <lifeless> could you please file a bug on that ?
[01:07] <wgrant> I think there might be on already.
[01:07] <wgrant> Let's see.
[01:07] <wgrant> ('Subscribe User' is for admins to subscribe others)
[01:08] <wgrant> Bug #586601
[01:08] <_mup_> Bug #586601: dev wiki toolbar has 'subscribe user' but not plain 'subscribe' <Launchpad Development Wiki Moin theme:Triaged> <https://launchpad.net/bugs/586601>
[01:15] <thumper> lifeless: I just go to the user preferences and edit the subscribed pages list
[01:31]  * thumper looks for mwh
[01:52] <lifeless> hmm, prose is hard.
[01:52] <lifeless> I can has code?
[01:52] <lifeless> anyone want to read a draft? https://dev.launchpad.net/Performance
[01:59] <lifeless> hmm
[01:59] <lifeless> staging go boom ?
[02:00]  * ajmitch reads up on performance
[02:01] <wgrant> Interesting.
[02:01] <wgrant> I wouldn't have expected the update to finish for a while yet.
[02:01] <wgrant> Oh, wait, yes it should have.
[02:01] <lifeless> wgrant: I'm not sure it has :P
[02:02] <lifeless> it still says 9644
[02:02] <wgrant> It's been updating to 9646 for nearly two hours.
[02:02] <lifeless> where are you looking
[02:03] <wgrant> successful-updates.txt. 9646 was in db-stable at the time it should have started the last update, at 00:14 BST.
[02:04] <wgrant> It would normally have finished the update a few minutes ago.
[02:05] <wgrant> But it seems to be running slightly late. Or has failed during the restart. One of them.
[02:05] <wgrant> Ah, it's back.
[02:05] <wgrant> r9646.
[02:06] <lifeless> \o/
[02:06] <lifeless> time to see if the distroseries page is fixifies
[02:06] <wgrant> Oddly late.
[02:06] <lifeless> \o/
[02:06] <lifeless> didnae timeout
[02:06] <wgrant> Also, why is it that staging takes longer to update than a full production rollout?
[02:06] <lifeless> no idea
[02:07] <lifeless> check the script
[02:07] <lifeless> ... oh :P
[02:07] <wgrant> Heh.
[02:07]  * wgrant tries getBuildRecords.
[02:08] <wgrant> Hm, and both +distrotask fixes should be active now./
[02:08]  * wgrant tries that too.
[02:15] <wgrant> Ah, crap.
[02:15] <lifeless> nada?
[02:15] <wgrant> No, it's nice and fast.
[02:15] <lifeless> \o/
[02:15] <wgrant> Just with a bug.
[02:15] <lifeless>  /o\
[02:17] <lifeless> top oops yesterdat
[02:17] <lifeless> on edge
[02:17] <lifeless> 32 https://api.edge.launchpad.net/1.0/ubuntu/maverick (DistroSeries:EntryResource:getBuildRecords)
[02:17] <wgrant> That should be fixed now.
[02:17] <lifeless> 63 cases
[02:18] <lifeless>  https://edge.launchpad.net/ubuntu/maverick/+index (DistroSeries:+index
[02:18] <lifeless> second at 11
[02:18] <wgrant> Also, I hate doctests, particularly when they're not comprehensive.
[02:18] <lifeless> s/sive/sable/ ?
[02:18] <wgrant> No.
[02:19] <wgrant> The only tests for this method are doctests. And they don't cover the case that I missed.
[02:20] <lifeless> whats the bug
[02:22] <wgrant> Distribution.guessPackageNames takes a package name, and tries to resolve it to a (sourcepackagename, binarypackagename) pair. It first tries to look up a source with the given name, then tries to find a binary within that source with the given name. If it can't find such a binary, it returns (sourcepackagename, None). If it can't find any published source with that name, it looks for a binary under any source. If it finds such a binary, ...
[02:22] <wgrant> ... it then takes the binary's source name.
[02:23] <wgrant> Now, for that last case, order is critical, since binaries can move between sources.
[02:23] <wgrant> So now 'libgcc1' maps to the 'gcc-3.3' source, rather than 'gcc-4.5' as it should.
[02:23] <wgrant> I dropped the (imperfect, but better than nothing) order from the old query.
[02:24] <wgrant> Oops.
[02:25] <lifeless> ah
[02:25] <lifeless> and perhaps the order is what made it work ?:)
[02:25] <lifeless> thumper: you have staging access right ?
[02:25] <wgrant> Yes :(
[02:25] <wgrant> But there are no tests.
[02:25] <wgrant> Nasty thing.
[02:26] <lifeless> thumper: You might need to do explain analyses for wgrant, I've got to pop out @3:39
[02:26] <lifeless> bah 3:39
[02:26] <lifeless> bah 3:30
[02:30] <thumper> lifeless: I have school parent-teacher interviews this afternoon
[02:33] <lifeless> ah, well poolie_ has turned up so he can do that too :)
[02:42] <poolie_> hi lifeless
[02:42] <poolie_> teacher-parent interviews? ok
[02:42] <thumper> mwhudson_: got a few minutes?
[02:42] <lifeless> poolie_: no, explain analyze's for wgrant on staging
[02:42] <mwhudson_> thumper: yeah
[02:43] <thumper> mwhudson: can you skype?
[02:43] <mwhudson> thumper: perhaps :-)
[02:43] <thumper> mwhudson: I have a problem with the sftp acceptance tests
[02:43] <wgrant> I can has statement log from OOPS-1684S39?
[02:43] <thumper> and trying to work out where to start
[02:43] <poolie_> oops
[02:43] <poolie_> so lifeless, to update you on feature flags
[02:44] <poolie_> i think they passed all tests last night, aside from one to do with twisted test runners that looks timing dependent
[02:44] <mwhudson> thumper: it appears i can skype
[02:44] <poolie_> i can't seem to get into my home server from spiv's house
[02:44] <poolie_> which is a bit annoying
[02:48] <lifeless> wgrant: 27 statements
[02:48] <poolie_> can we put wgrant into a team that lets him see oopses?
[02:48] <lifeless> no
[02:48] <poolie_> wgrant, if you want anything run, just ak
[02:48] <poolie_> *ask
[02:48] <wgrant> lifeless: I need to see one of the statements.
[02:48] <lifeless> the problem is urls that reference private teams
[02:48] <wgrant> Well, a couple of them.
[02:48] <lifeless> and in future other things
[02:48] <lifeless> wgrant: any in particular, or do you want the full 27
[02:48] <wgrant> lifeless: Ideally the full 27.
[02:51] <lifeless> enjoy
[02:51] <lifeless> poolie_: until we have automated stripping/identifying of those, we can't share it
[03:16] <thumper> mwhudson: found it
[03:16] <thumper> mwhudson: I was checking for path.startswith('.bzr/')
[03:17] <thumper> mwhudson: and the sftp server steps through '.bzr'
[03:17] <thumper> so no trailing slash
[03:19] <poolie_> lifeless,  can you try to re-send the feature flags branch, if you're happy with the later changes?
[03:19] <mwhudson> thumper: :-)
[03:19] <poolie_> if you didn't do that last night
[03:20] <lifeless> poolie_: 'release-critical' mode - launchpad has a 1 week stall
[03:20] <lifeless> poolie_: no, we can't till friday
[03:26] <lifeless> poolie_: I am happy with your changs though
[03:26] <lifeless> poolie_: but as we want this for development going forward, not for something on lpnet immediately, I think its non-rc
[03:27] <lifeless> poolie_: once its landed we can use it on edge immediately, which will be sufficient till edge->lpnet, and at that point it will be universally available
[03:28] <lifeless> spiv: https://bugs.edge.launchpad.net/launchpad-code/+bug/84838
[03:28] <_mup_> Bug #84838: code browser should use oops system <Launchpad Bazaar Integration:In Progress by spiv> <https://launchpad.net/bugs/84838>
[03:28] <lifeless> spiv: is the bug status stale ?
[03:29] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/bug-616154-guessPackageNames-order-fix/+merge/32285 is RC. db-devel closes soon. What do I do?
[03:31] <thumper> :(
[03:32] <lifeless> wgrant: please add it to https://dev.launchpad.net/CurrentRolloutBlockers
[03:33] <wgrant> Ah.
[03:33] <thumper> mwhudson: it seems that faults raised in the xmlrpc server *DO NOT* cause a transaction.abort
[03:33] <lifeless> I'm sending it to ec2 land now
[03:33] <mwhudson> thumper: raised or returned?
[03:33] <mwhudson> thumper: but either way :(
[03:34] <mwhudson> thumper: i can probably tell you where to fix this, btw
[03:34] <thumper> mwhudson: I'm tempted to use the @return_fault adapter and have a try except block
[03:34] <thumper> mwhudson: fix the cause perhaps?
[03:34]  * thumper shakes head
[03:34] <thumper> not what I ment
[03:34] <thumper> fix at the root?
[03:35] <thumper> ENOTENOUGHSLEEP
[03:35] <lifeless> thumper: can you 'approve' that merge above, ec2land is whinging
[03:35] <mwhudson> thumper: PublicXMLRPCPublication.endPublication in servers.py?
[03:35] <lifeless> thumper: we need release-critical *and* a normal approve, or it blows up
[03:35] <thumper> lifeless: --force
[03:35] <lifeless> no
[03:35] <lifeless> different bug
[03:35] <lifeless> humour me
[03:35] <thumper> ah, which?
[03:35] <lifeless> ec2 land https://code.edge.launchpad.net/~wgrant/launchpad/bug-616154-guessPackageNames-order-fix/+merge/32285 --force
[03:35] <lifeless> ec2: ERROR: Cannot land branches that haven't got approved code reviews. Get an 'Approved' vote so we can fill in the [r=REVIEWER] section.
[03:35] <lifeless> it has an approval from me
[03:36] <lifeless> but its labelled 'release-critical' (which it has to be to get past pqm)
[03:36] <wgrant> I suppose I need to mark the original bug qa-bad, too.
[03:36] <wgrant> Is there anything special involved in that?
[03:36] <thumper> doen
[03:36] <lifeless> thumper: thanks
[03:38] <thumper> mwhudson: how do we know whether to commit or abort?
[03:38] <mwhudson> thumper: i'm now confused
[03:38] <mwhudson> thumper: an excellent question
[03:39] <lifeless> thumper: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/616164
[03:39] <_mup_> Bug #616164: ec2 land refuses to land approved rc patch <Launchpad Foundations:New> <https://launchpad.net/bugs/616164>
[03:39] <thumper> mwhudson: publication afterCall
[03:40] <lifeless> transaction.doom() ?
[03:40] <mwhudson> thumper: but it only seems to abort for a read-only request or for a doomed transaction
[03:40] <mwhudson> ah right
[03:40] <thumper> doom?
[03:40] <lifeless> when something goes wrong we doom the transaction
[03:40] <mwhudson> it doesn't seem that simply raising an error causes an abort
[03:41] <lifeless> if we try to commit a doom transaction storm blows up as a safety measure
[03:41] <thumper> mwhudson: no...
[03:41] <mwhudson> unless there's a doom() in there somewhere
[03:41]  * mwhudson greps
[03:42] <lifeless> whats up?
[03:42] <thumper> lifeless: I have a method in the xmlrpc server that tries to create a branch and link it
[03:42] <thumper> lifeless: the branch is created, the link fails due to permission checks
[03:42] <thumper> I expected the transaction to be aborted
[03:42] <thumper> but it isn't
[03:42] <lifeless> fun!
[03:43] <lifeless> what sort of permission check
[03:44] <thumper> launchpad.edit on the product
[03:44] <thumper> I can manually abort it
[03:44] <thumper> but it seems weird that I'd have to
[03:45] <lifeless> do you catch it ?
[03:45] <thumper> I would have thought that if the xmlrpc server is returning a fault, that it would be aborted for me
[03:45] <lifeless> or rather how far up is it propogating
[03:45] <thumper> lifeless: I catch it to return a fault
[03:45] <lifeless> then you have to abort
[03:45] <lifeless> I'm pretty sure we don't glue returned objects to db aborts
[03:45] <thumper> I can.
[03:45] <thumper> ok
[03:45] <lifeless> not saying we shouldn't, just that thats my understanding
[03:46] <thumper> faults are special though aren't they?
[03:48] <mwhudson> really
[03:48] <mwhudson> we should fix the problem that makes raising a fault cause an oops in the logs
[03:49] <lifeless> thumper: a raised object would trigger an abort I think, not a returned one.
[03:49] <mwhudson> maybe it should just log an informational oops
[03:49] <lifeless> mwhudson: why shouldn't it have the same rules as web server oops
[03:49] <lifeless> mwhudson: that is, we apply logic to it ;)
[03:50] <mwhudson> lifeless: not sure quite what you're asking, suspect only having square tuits though
[03:51] <lifeless> I mean we don't file OOPS for permission issues on the main appserver
[03:51] <mwhudson> right
[03:51] <lifeless> if you try something naughty, tsk, your problem.
[03:58] <thumper> clucking bells
[04:02]  * thumper afk for school stuff
[04:03] <spiv> lifeless: no, in that I still haven't spoken to the losas about the production config for it
[04:03] <lifeless> poolie_: lynne has bought red dead redemption for ps3 :) (and we've bought a ps3)
[04:03] <lifeless> spiv: can you please shoot that mail off to losas @ c.c then ? that should be trivial to do...
[04:04] <spiv> lifeless: ok, although I feel a bit like I'm drowning in distractions from the bzr bug I'm working on :/
[04:05] <lifeless> So, the reason I'm nagging is that its not clear in the bug what needs to happen next; noone else can move it forward without chatting with you.
[04:05] <lifeless> If you make it clear there, someone (me?) will move it forward sometime, otherwise its going to stay in your pile indefinintely.
[04:07] <lifeless> And I must go, builder to give instructions to.
[04:07] <lifeless> BBIAW
[04:08] <poolie_> lifeless, i think that means i can't shoot lynne :-(
[04:08] <spiv> lifeless: that's fine, just grumbling to the world in general rather than you
[04:08] <poolie_> being on a ps3
[04:08] <spiv> lifeless: thanks for the nag
[04:08] <poolie_> lifeless, nice performance doc, though i have to confess the "3*SD + mean" really squicks me for some pedantic reason
[04:09] <poolie_> i wish it just computed the 99% value
[04:09] <poolie_> lifeless>> caches (unlike memos) are populated by the first request for the data
[04:10] <poolie_> isn't that exactly what a memo does?
[07:24] <lifeless> spiv: thanks
 lifeless>> caches (unlike memos) are populated by the first request for the data
 isn't that exactly what a memo does?
[07:27] <poolie_> also
 lifeless, nice performance doc, though i have to confess the "3*SD + mean" really squicks me for some pedantic reason
 i wish it just computed the 99% value
[07:27] <lifeless> poolie_: so do I
[07:28] <lifeless> poolie_: I plan to hack on it some shortly
[07:28] <poolie_> that would be nice
[07:28] <poolie_> in particular if we have just a few outlier results (because they do hard io, or they miss a normally-reliable cache) there might be a big difference
[07:28] <poolie_> briellant
[07:30] <lifeless> poolie_: you might like the email I just sent off
[07:30] <lifeless> wgrant: your branch has landed
[07:30] <lifeless> wgrant: sorry, it has ec2 passed, pqm time now
[07:31] <lifeless> poolie_: I'm not sure that 99% != mean+3SD here. I know it *might not*, but actually its pretty accurate so far when I have compared
[07:32] <lifeless> poolie_: as for memoisation vs caching; I'm trying to distinguish things that are redundant that we store in advance vs things that are redundant that we calculate just-in-time-and-remember
[07:32] <lifeless> poolie_: better terms appreciated
[07:36] <wgrant> lifeless: Thanks.
[07:43] <jtv> lifeless: just made some superficial changes to your new Performance wiki page…  to be clear: are the cases of "its" where I'd expect "it's" mistakes (as I believe they probably are), or is there a rationale behind it?
[07:44] <jtv> lifeless: also, it may be worth mentioning the distinction between responsiveness and completion speed earlier on.
[07:46] <stub> The report is two wide already, so +1 replacing columns with something more generally useful.
[07:46] <jtv> lifeless: then, where it says the bugs database is write-only, do you mean append-only?
[07:47] <jtv> stub: wrong window?
[07:50] <lifeless> jtv: thanks
[07:50] <lifeless> jtv: I'm terrible on my its'
[07:52] <lifeless> jtv: what bit of the distinction would you put earlier? just the idea of responding quickly, doing the work, then completing ?
[07:56] <jtv> lifeless: no, the point about getting a response not meaning that you're all done—e.g. "loading the page a bit faster at the cost of having parts follow a bit more slowly is a win in responsiveness whenever the user doesn't feel held up by the slower bits."
[07:57] <jtv> I believe you mention this under memoisation, where the relevance isn't immediately clear to me tbh
[07:57] <jtv> (look for "red flag")
[07:58] <jtv> BTW don't worry about the "it's"; I went through all the itses on the page.
[07:58] <lifeless> wgrant: its through pqm now
[07:58] <jtv> it's!
[07:59] <jtv> it's through pqm!
[07:59] <lifeless> see, terrible
[07:59] <jtv> :-)
[07:59] <lifeless> jtv: ah yes
[08:00] <lifeless> doing background processing in an interactive context
[08:00] <lifeless> the caveat being that sometimes we have to do it to be 'complete'
[08:02] <jtv> lifeless: saw a good point about responsiveness back in the 20th century: the important thing is that you know that things are going on and can sympathize—at the time a flurry of disk seeks was very audible but an http connection to (as I believe the poster put it) Outer Mongolia was not.
[08:03] <lifeless> lol! I love it!
[08:03] <lifeless> did they have a wav file of chattering disks ?
[08:03] <jtv> So waiting 10s for disk seeks was fine, but waiting 7s for a page to load was not.
[08:04] <jtv> lifeless: this was in the days when you didn't just add some huge binary file just for the hell of it.
[08:04] <jtv> It was also in the days when anyone likely to read the message could easily produce the noise for themselves!
[08:36] <henninge> jtv: https://code.launchpad.net/~henninge/launchpad/bug-595925-second-attempt
[08:37] <henninge> jtv: The last revision makes the Windmill test fail in a strange way and I don't have a clue.
[08:41] <jtv> henninge: diff generation is broken today… do you have a diff somewhere?
[08:43] <henninge> jtv: shure. Hang on...
[08:43]  * henninge turns on speakers for a start
[08:49] <henninge> jtv: http://paste.ubuntu.com/476320/
[08:49]  * jtv looks
[08:49] <henninge> jtv: I included the first part from the factory so you can see what makeSuggestion does.
[08:50] <henninge> jtv: The windmill test produces an OOPS with this change.
[08:50] <henninge> lemme do that again
[08:50] <adeuring> good morning
[08:51] <jtv> hi adeuring
[08:51] <henninge> adeuring: Hallo!
[08:54] <jtv> henninge: what kind of oops does it give you?
[08:54] <henninge> jtv: here is the test command and the oops that appears in the windmill browser window:
[08:54] <henninge> http://paste.ubuntu.com/476322/
[08:55] <jtv> henninge: nasty traceback.
[08:55] <henninge> what is a "LocationError" about, anyway?
[08:56] <jtv> damned if I know
[08:56] <jtv> But I would guess that the problem is that we're creating a TM without a pofile.
[08:56] <henninge> We do?
[08:56] <jtv> In this case, yes.
[08:57] <jtv> But we never completed the new +translate page, so we have some hacked-in workarounds that rely on the field being set.
[08:58] <jtv> Again theoretically, we set those completely in-memory without bothering the database, but as I found in my experiments a few months back, nulling the database field will produce oopses.
[09:00] <lifeless> stub: remind me where the ppr code is again ?
[09:01] <henninge> jtv: so I'd have to check the view code to see where it uses tm.pofile?
[09:01] <stub> utilities/page-performance-report.py (half are reports are in utilities and half in scripts)
[09:01] <jtv> henninge: it might be anywhere
[09:01] <henninge> ouch
[09:01] <lifeless> stub: thanks
[09:01] <jtv> henninge: otp
[09:02] <jtv> henninge: and so should you be :)
[09:02] <lifeless> stub: now, I'm thinking of doing a 'timeout-candidates summary
[09:02] <lifeless> stub: showing just page ids and 99%
[09:02] <lifeless> stub: is that controlled entirely in the source, or is it going to be partly how its deployed?
[09:02] <lifeless> stub: and, do you think such a summary can be published publically ?
[09:02] <stub> consider dropping the varience and stddev columns
[09:03] <stub> I can't see what we consider private on the existing report.
[09:03] <lifeless> stub: top-urls
[09:03] <stub> Oh, right.
[09:03] <lifeless> the urls might be for a private team like ~vendor-supplier or something
[09:04] <lifeless> stub: 'just page ids and 99%' includes dropping the mean and stddev :)
[09:04] <stub> page-performance-report-daily.sh is the script I run each day to generate the reports in the relevant locations
[09:05] <lifeless> ok
[09:05] <stub> lifeless: I mean that the variance and stddev might be irrelevant if we output the 99% on the existing reports
[09:05] <lifeless> stub: ack
[09:05] <lifeless> stub: uhm, I think they are useful to have somewhere
[09:06] <stub> Or maybe JS love to hide unwanted columns might be better
[09:06] <lifeless> otoh the graph is a pretty good visual aid for same
[09:16] <lifeless> hmm thats interesting
[09:16] <lifeless> what happened on the 29th https://lpstats.canonical.com/graphs/OopsLpnetHourly/20100712/20100811/
[09:16] <lifeless> something causing both exceptions and timeouts got changed
[09:18] <lifeless> mrevell: I'm happy with your changes to the oops wiki page btw
[09:18] <mrevell> Hello
[09:18] <lifeless> mrevell: thank you for doing them!
[09:18] <stub> lifeless: maybe me rebuilding the bug full text indexes?
[09:18] <lifeless> stub: could be it
[09:18] <lifeless> nothing leaps out at me from the production-stable branch changelog
[09:19] <mrevell> Thanks for writing it lifeless!
[09:20] <bigjools> morning all
[09:20] <lifeless> morning bigjools
[09:26]  * bigjools loves seeing last minute RCs
[09:27] <wgrant> bigjools: Sorry :(
[09:30] <bigjools> c'est la vie
[09:39] <lifeless> !oops
[09:44] <lifeless> stub: am I correct - no tests for the script ?
[09:55] <stub> lifeless: Yes.
[10:02] <lifeless> stub: how can I be sure I haven't stuffed it up ?
[10:02] <lifeless> stub: or will you do that if I get you something approximate ?
[10:02] <stub> I've run it against a log and looked at the output.
[10:03] <stub> We could write a test for it, but it would be incredibly fragile.
[10:03] <stub> So put if off until it stabalized
[10:04] <lifeless> lp:~lifeless/launchpad/foundations - I added a column (sorry!) but it should give us one report most devs can focus on.
[10:04] <lifeless> which will be pretty short
[10:05] <stub> So that will need a merge proposal
[10:06] <lifeless> firing one up
[10:08] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/foundations/+merge/32299
[10:10] <stub> numpy doesn't have a magic 99th percentile helper?
[10:11] <stub> doesn't look like it
[10:14] <lifeless> http://docs.scipy.org/doc/numpy/reference/routines.statistics.html is less than completely helpful
[10:18] <elmo> https://pastebin.canonical.com/35707/ <-- it may be trivial/obvious, but there's one I had to hand, FWIW
[10:18] <lifeless> elmo: hah! thanks.
[10:18] <lifeless> I'm using stddev*3 + mean atm
[10:18] <lifeless> which may be more useful
[10:19] <lifeless> as grabbing the Nth can be much higher/lower than the curve fitted approach
[10:20] <stub> Beyond my recollections of high school anyway.
[10:20] <stub> Need food.
[10:58] <bigjools> mrevell: when logging in to the dev wiki, it doesn't redirect back to the page you were on, do you know if that's fixable?
[10:58] <mrevell> bigjools, Yeah, that's a pain. I don't know if it's fixable but I can certainly ask.
[10:59] <bigjools> ok cheers
[11:01] <wgrant> bigjools: I would have loved to rewrite the doctest, but I opted for a less invasive change as a last-minute RC!
[11:01] <bigjools> wgrant: I know, it's the right thing in this case
[11:02] <bigjools> doesn't stop me being sad about it though :)
[11:02] <wgrant> Heh.
[11:18] <lifeless> gmb: hi
[11:18] <lifeless> gmb: I think it was a bug of yours I touched today - about +filebug timing out doing large blobs.
[11:19] <lifeless> gmb: I wanted to check that that is out of the webapp request now ?
[11:22] <gmb> lifeless, Err, let me check...
[11:24] <gmb> lifeless, In that case it's just that the dependencies are done. At the moment the polling (such as it is) is by way of a page refresh.
[11:24] <gmb> I'll note that on the bug.
[11:24] <lifeless> gmb: there were two
[11:24] <lifeless> gmb: thanks for adding a note to the one about the polling
[11:25] <lifeless> the other bug I closed off which was tagged timeout because of those blos
[11:25] <lifeless> blobs
[11:25] <lifeless> I figure that that is fixed, no ?
[11:25] <gmb> lifeless, Can you give me a number for the other bug?
[11:26]  * gmb might have marked it as read by mistake
[11:27] <lifeless> hmm
[11:33] <lifeless> gmb: https://bugs.launchpad.net/malone/+bug/357907
[11:33] <_mup_> Bug #357907: +filebug is timing out when processing large blobs <timeout> <Launchpad Bugs:Fix Released> <https://launchpad.net/bugs/357907>
[11:34] <gmb> lifeless, Yes, that's fixed.
[11:42] <lifeless> mrevell: hey, so the changes to the +filebug and answers search  - I documented them reasonably well, but there isn't a blog post ready-to-roll with the release.
[11:42] <lifeless> mrevell: how do you feel about writing that up, so that in the release folk aren't taken aback ?
[11:44] <lifeless> mrevell: failing that, I'll be up for the team leads meeting tomorrow am and can make writing a blog post a priority then, but I may need a hand connecting to the lp blog etc etc, if you could email me the necessary that would be grand.
[11:44] <mrevell> lifeless, Heh, I had it on my list for today to email you about those. I can write the posts. To summarise, rather than getting 10 or so results in the dupe-finder you're more likely to get 3 or 4 and the results may be slightly different to what you'd have seen before. Is that right?
[11:44] <lifeless> mrevell: user visible behaviour - yes, thats right.
[11:44] <lifeless> slightly different *should* be 'more relevant'
[11:44] <lifeless> as in, yes its different, but we hope its better too.
[11:44] <lifeless> its /also/ much faster.
[11:45] <lifeless> like 15 seconds faster for /ubuntu/+filebug
[11:45] <mrevell> lifeless, Cool :) What would be really helpful to me, if you have time, would be a quick email with very rough notes on this. Or just paste them here are you are now :)
[11:45] <lifeless> for many searches
[11:45] <lifeless> so the arch is
[11:45] <lifeless> arc
[11:45] <lifeless> +filebug and answers were both performing terribly, with the search engine at the core
[11:46] <lifeless> we're going to replace the search engine, but that takes time - and by horribly I mean timing out *a lot*. Nearly unusable.
[11:46] <lifeless> So as a band aid we've made the searches with the current engine narrower.
[11:46] <lifeless> This makes it faster, and - due to how we've changed it - slightly more relevant at the same time.
[11:47] <lifeless> We *can* switch this off easily if we have to, so we *do* want feedback about how people find this.
[11:47] <mrevell> Cool. This is very helpful, thanks. Can you give me some detail of how you've changed it? Also, what's the best way for people to provide feedback to you?
[11:47] <lifeless> We *want* to stick with the band aid for 5-6 months while we replace the search engine.
[11:47] <lifeless> The change specifics
[11:48] <lifeless> the old search did a pre-pass over *every possible hit*, which is 400000 items for ubuntu - thats very slow to do, and then did a search matching *any document* which had a rare search term in it.
[11:48] <lifeless> Where rare == 'turns up < 50% of the possible hits'
[11:49] <lifeless> so if you searched for firefox crashes on <website> in flash
[11:49] <lifeless> on /ubuntu/+filebug
[11:50] <lifeless> it would search for any bug with *any of* 'firefox' (< 50% of bugs are firefox), 'crash' (<50% of bugs say crash), '<website>' (<50%...), 'flash' (< 50%..)
[11:50] <lifeless> however, *many many* bugs mention firefox, *and* many many bugs mention crash and many many mention flash
[11:51] <lifeless> so the total the search return could be 10000 or 100000 quite easily
[11:51] <lifeless> and - unlike other search engines - the more terms you typed in, to make it more precise, the *less precise* it became.
[11:51] <lifeless> because it started bring back bugs from anywhere that happened to mention any search term
[11:52] <lifeless> and the relevance weighting - well, it added confusion to it.
[11:52] <lifeless> What we do now is:
[11:52] <lifeless> if you sesarch for firefox crashes on <website> in flash
[11:52] <lifeless> we search for any bug continaing 3 of the 4 non stopwords
[11:52] <lifeless> that is firefix,crashes,website,flash - if a bug mentions any 3, it will be returned.
[11:54] <mrevell> Thanks Rob.
[11:54] <mrevell> lifeless, As for the LP blog ... it's hooked into LP's OpenID stuff, so you need to log in at https://blog.launchpad.net/wp-admin (igoring the invalid cert) and it'll generate an account for you. I can then upgrade that to author status.
[11:55] <lifeless> contacting us about this? launchpad-users list, tweet to launchpadstatus, faccebook page, irc
[11:55] <lifeless> I'll take point on any heat
[11:55] <lifeless> but I think we'll all be interested in feedback
[11:56] <lifeless> mrevell: I've logged in with openid
[11:57] <deryck> Morning, all.
[11:57] <mrevell> lifeless, Okay, you should now be able to makes posts on the blog.
[11:57] <mrevell> Howdy deryck.
[11:58] <lifeless> thanks mrevell
[11:59] <lifeless> I'll give that a spin on the next bit I redefine from ground up :)
[11:59] <lifeless> gnight
[11:59] <deryck> gmb, your heat timeout patch is on staging now?
[11:59] <mrevell> :) Night Rob.
[12:07] <lifeless> deryck: I qa'd the heat timeout patch
[12:07]  * lifeless finds leaving the keyboard tricky
[12:07] <deryck> heh, ok, thanks.
[12:08] <deryck> Was just curious since the timeout was blocking other qa for me.
[12:08] <lifeless> deryck: (I mentioned it in the patch :P)
[12:08] <lifeless> s/patch/bug/
[12:10] <bigjools> wgrant: still around?
[12:12] <wgrant> bigjools: Sure.
[12:13] <bigjools> wgrant: your fix got through buildbot, I'm going to see if I can get staging refreshed so you can QA it
[12:13] <wgrant> bigjools: That would be excellent. Thanks.
[12:21] <bigjools> wgrant: losas are at lunch I think, are you around much more today?
[12:22] <wgrant> bigjools: I'll be around for another 2-3 hours at least.
[12:22] <bigjools> great, thanks
[12:41] <deryck> I *really* wish we didn't do subscriber notifications in app.
[12:43] <bigjools> totally
[12:44] <bigjools> deryck: we have the same problem, indirectly.  When accepting packages that close bugs it calls your notification code.
[12:45] <deryck> yeah, it bites everyone.  I think that's what killed sinzui's one-click release work.
[12:47] <wgrant> What's the time spent on? Creating BugNotificationRecipients?
[12:49] <deryck> wgrant, yes, mostly there
[12:49] <sabdfl> hi folks, do the project aliases enable redirects? if i rename a project from foo to bar, with foo as an alias, will stuff just work? only care about bug links
[12:54] <maxb> I know they do for https://launchpad.net/<foo> links
[12:54] <jelmer> sabdfl: hi. Yes, they enable redirects. https://bugs.launchpad.net/alias/+bug/42 will redirect to https://bugs.launchpad.net/name/+bug/42
[12:54] <_mup_> Bug #42: Bug description listed in task is not the correct description <Launchpad Bugs:Fix Released by bradb> <https://launchpad.net/bugs/42>
[12:54] <_mup_> Bug #42: Bug description listed in task is not the correct description <Launchpad Bugs:Fix Released by bradb> <https://launchpad.net/bugs/42>
[12:56] <sabdfl> brilliant, thanks jelmer
[12:56] <sabdfl> now that we've solved bug #42, everything else should be easy :-)
[12:56] <_mup_> Bug #42: Bug description listed in task is not the correct description <Launchpad Bugs:Fix Released by bradb> <https://launchpad.net/bugs/42>
[12:58] <wgrant> bigjools: Hm, it's not there yet.
[12:58] <bigjools> :/
[12:58] <wgrant> I need r9648
[12:58] <wgrant> It's r9647 now.
[13:01] <bigjools> wgrant: check again in a while, it'll update soon
[13:01] <wgrant> bigjools: ... and take 2.5 hours to do so :/
[13:02] <bigjools> wgrant: 20 minutes
[13:02] <wgrant> Ah, that's a little better.
[13:13] <stub> sabdfl: Yes. https://bugs.edge.launchpad.net/launchpad-translations/+bug/615673 for an example.
[13:13] <_mup_> Bug #615673: IPOTemplate.path says it's not required <oops> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/615673>
[13:44] <wgrant> bigjools: staging's been saying 'Code Update In Progress' for nearly half an hour now...
[13:45] <jelmer> stub: hi. Can you allocate a database patch id for me?
[13:46] <stub> jelmer: lp:~jelmer/launchpad/613468-xb-ppa-db ?
[13:46] <jelmer> stub: yep
[13:48] <stub> Reviewed. Suspect that won't be landing this cycle though.
[13:51] <mars> wgrant, staging code updates take an average of 100 minutes
[13:51] <mars> we have a graph of it
[13:52] <wgrant> mars: It's always down for the whole time?
[13:52] <mars> That I do not know
[13:59] <bigjools> wgrant: ok I'm chasing it, thanks
[14:00] <jelmer> stub: No, that wasn't the intention. Thanks.
[14:35] <bigjools> wgrant: can you QA that bug on dogfood?  it's up to date
[14:35] <bigjools> stub: did you get any ideas with that query that's timing out?
[14:37] <wgrant> bigjools: DF still says r9644.
[14:37] <bigjools> wgrant: ignore it
[14:37] <bigjools> I didn't rebuild the revision file, it takes too long
[14:37] <wgrant> Ah, heh.
[14:37] <bigjools> (as it rebuilds the wadl too)_
[14:37] <wgrant> The fix is good.
[14:38] <bigjools> yay
[14:56] <salgado> EdwinGrubbs, IIUC, you'd then run that query once for every superteam, is that right?
[14:58] <EdwinGrubbs> salgado: oh, I didn't think about that. If the superteam is a member of another super-super-team, you have to update its teamparticipation also. bleh.
[15:00] <EdwinGrubbs> salgado: it might be possible to get that to run in a single query if I just join teamparticipation table with itself. It would be a joining a list of all the new members with all the new superteams.
[15:01] <EdwinGrubbs> of course, the performance impact of that could be surprisingly high.
[15:03] <wgrant> bigjools: Anything else before I disappear?
[15:03] <bigjools> wgrant: no, thanks for hanging around
[15:03] <bigjools> sleep well
[15:03] <wgrant> Thanks.
[15:03] <wgrant> Night.
[15:16] <stub> bigjools: Can you run on dogfood: explain analyze SELECT COUNT(*) FROM BuildFarmJob
[15:16] <stub> JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id
[15:16] <stub> JOIN Archive ON PackageBuild.archive = Archive.id
[15:16] <stub> WHERE BuildFarmJob.builder = 106;
[15:17] <bigjools> stub: yep, one sec
[15:18] <bigjools> stub: http://pastebin.ubuntu.com/476455/
[15:19] <stub> bigjools: So the weird way of doing the join was slowing things down
[15:19] <bigjools> figures
[15:20] <bigjools> noodles775: ^
[15:20] <bigjools> thanks stub
[15:26] <noodles775> stub, bigjools: erm, doesn't it need to be a left join? (not all BuildFarmJobs have a related PackageBuild)
[15:27] <noodles775> s/have/will have
[15:27]  * noodles775 looks for the code.
[15:28] <stub> noodles775: Hmm
[15:29] <noodles775> bigjools, stub: see comment in lp/buildmaster/model/buildfarmjob.py:BuildFarmJobSet.getBuildsForBuilder
[15:29] <stub> So the actual query should just be 'select count(*) from buildfarmjob where builder=106;'
[15:30] <jtv> bigjools: then why did you ask in -code?
[15:30] <bigjools> jtv: because I suck
[15:31] <jtv> stub: heh… we both converted the join but you converted to inner-join whereas I left out Archive.  Together we should rule.
[15:31] <noodles775> stub: if we updated the count to include private builds (and just display them as 'Private build' on the history, yes. But currently (we don't know the history) it only displays the builds you are allowed to see... hence the joins.
[15:31] <stub> I never use implicit outer join so misparse 'left join'
[15:32] <jtv> stub: doesn't your version change the zero case though?
[15:32] <stub> noodles775: But that isn't the query we are looking at
[15:33] <jtv> And it often pays to keep "private, visible" queries completely separate from "public" queries.
[15:33] <noodles775> stub: I think it is..., if you check the code, you'll see why what you're expecting is missing (the oops was generated by a df admin, so it doesn't bother adding the extra where clauses)
[15:34] <stub> I can't really optimize a partial query
[15:34] <noodles775> I'll generate one as a non-admin.
[15:35] <danilos> stub, you are lame, I can optimize even bits like "FROM Prod" ;)
[15:36] <jtv> danilos: go play with mysql—the /real/ men are talking here
[15:37]  * danilos blinks and powers up mysql
[15:38] <jtv> danilos: you did realize I was joking, right?  I wouldn't do that to you.
[15:38] <danilos> :)
[15:39] <jtv> (So once it's started up, please just shut it down again)
[15:39] <danilos> (aptitude is still installing it, how do I break that?)
[15:40] <bigjools> don't use aptitude? :)
[15:40] <jtv> Pull all plugs and cables out, then wait for battery to drain if applicable.
[15:44] <noodles775> stub: I've added https://pastebin.canonical.com/35735/ to the bug - an oops for the same page when logged in as a non-admin.
[15:45] <stub> explain analyze SELECT COUNT(*) FROM BuildFarmJob
[15:45] <stub> LEFT OUTER JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id
[15:45] <stub> LEFT OUTER JOIN Archive ON PackageBuild.archive = Archive.id
[15:45] <stub> WHERE BuildFarmJob.builder = 106;
[15:45] <stub> That has a much nicer explain on production
[15:53] <jtv> stub: I have a feeling I was responsible for the COALESCE…
[15:53] <stub> noodles775: Do you know what the constants would be in the COALESCE(Archive.private, ???) = ???
[15:53] <noodles775> stub: nope, I just followed jtv's review.
[15:54] <stub> They wouldn't have been in jtv's review...
[15:54] <jtv> stub: it was a boolean
[15:54] <stub> True or False?
[15:54] <stub> I'm guessing False
[15:54] <jtv> bigjools would know
[15:54] <bigjools> can point me at the code for context?
[15:54] <jtv> https://pastebin.canonical.com/35735/ I believe
[15:55]  * bigjools tries to work out wtf that is in the code
[15:56] <jtv> bigjools: this is the bit you asked me about isn't it, where I suggested COALESCE?
[15:56] <stub> Yes, false
[15:56] <bigjools> jtv: different query I think
[15:56] <jtv> ah
[15:56] <stub> lib/lp/buildmaster/model/buildfarmjob.py
[15:57] <jtv> stub: so in that case, Archive.private IS NOT FALSE would do as well?
[15:57] <stub> So we are just trying to return the number of buildfarm jobs that are visible?
[15:57] <bigjools> yes
[15:57] <bigjools> we should be returning all of them and displaying private ones differently really, but that's another matter
[15:57] <jtv> stub: you're right, the %s must be false
[15:58] <jtv> In which case, leaving out that join can still make sense here
[16:01] <stub> explain analyze
[16:01] <stub> SELECT COUNT(DISTINCT BuildFarmJob.id)
[16:01] <stub> FROM BuildFarmJob
[16:01] <stub> LEFT OUTER JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id
[16:01] <stub> LEFT OUTER JOIN Archive ON PackageBuild.archive = Archive.id
[16:01] <stub> LEFT OUTER JOIN TeamParticipation ON TeamParticipation.team = Archive.owner
[16:01] <stub> WHERE
[16:01] <stub>     BuildFarmJob.builder = 106
[16:01] <stub>     AND (Archive.private IS FALSE OR TeamParticipation.person = 1)
[16:01] <stub> (I'm not sure of who a suitable owner would be, so using '1')
[16:01] <jtv> (note to self: I was talking nonsense earlier)
[16:02] <bigjools> noodles775: I am guessing that we won't be able to make a branch for this in the next few minutes.
[16:02] <noodles775> Thanks stub: I'll try the storm equivalent.
[16:02] <noodles775> bigjools: no.
[16:02] <bigjools> noodles775: ok, we'll have to release with this broken, and do a re-roll or CP
[16:03] <bigjools> how it got broken is a good question though!
[16:04] <jtv> bigjools: I don't suppose you could dig up an older oops with the pre-broken query?
[16:04] <stub> It might just be the data changing things. My query could suck for instance if we end up with archives owned by a team with a large membership.
[16:05] <noodles775> As per the bug, the data that we know changed on dogfood/staging is that we now have other types of BuildFarmJob's... but there could be other data changes too of course.
[16:06] <bigjools> ah of course, new job types trying to get displayed
[16:08] <jtv> I don't see job types playing here, at least not directly
[16:12] <jtv> bigjools, stub, noodles775: actually, looks to me like the "flattening" of that Archive join at least is very easy to do.  It's explicit in the code.
[16:13] <jtv> left_join_pkg_builds… defined then used immediately, and never again.  Contains the whole drama.
[16:14] <stub> Might be worth someone running that explain on dogfood though... the plan on production looks ok, but that isn't terribly useful since the problem is on dogfood.
[16:15] <noodles775> jtv: easy to do in storm? Great... can you paste an example? And what do you mean never again? (isn't it required for the later conditions on archive.private?
[16:15] <noodles775> stub: doing so now.
[16:15] <jtv> noodles775: just saying there are no boundaries of encapsulation, responsibility etc. to complicate changing this.  Hang on.
[16:17] <noodles775> stub: https://pastebin.canonical.com/35741/
[16:18] <stub> ok - that seems good for dogfood.
[16:18] <jtv> hmm this rain is _cooling_ my laptop, but is it good for the laptop _overall_?
[16:18] <stub> There is an alternative version where we remove the DISTINCT and do the teamparticipation check in a subquery
[16:19] <stub> you have rain? Its hot outside here.
[16:19] <jtv> stub: I'm North of you, but not far
[16:20] <jtv> Not a lot of rain, mind you; just enough to make the screen a bit harder to read
[16:20] <stub> Yup. Dry here. I think you have a leak.
[16:21] <jtv> (I'm in front of the house, under an awning and further shielded by those big umbrellas we used to have out on the balcony in Din Daeng)
[16:22] <jtv> noodles775: this is definitely not my first litre of beer, so I may not be the right person to rewrite your storm query right now.  But if you look at BuildFarmJobSet.getBuildsForBuilder, you see essentially the whole problem query spelled out, inner-join-nested-in-outer-join and all.  If you can rephrase that, you've got stub's change.
[16:23] <noodles775> jtv: yes, I'm in the process of converting it now based on stub's query above.
[16:23] <jtv> delightful
[16:27] <jtv> noodles775: what sort of row counts would you expect out of this?
[16:27] <noodles775> jtv: if it helps, the review discussion we had is here: http://irclogs.ubuntu.com/2010/06/16/%23launchpad-reviews.html#t15:26
[16:28] <jtv> So that *was* the Coalesce I suggested, just not to bigjools!
[16:28] <noodles775> Yep, that's what I meant earlier when I referred to the review.
[16:29] <jtv> right—got it now.
[16:29] <jtv> My God, did I really spell it as FULLYBUILD?
[17:20] <leonardr> james_w, question about your launchpadlib test failures
[17:20] <james_w> hi leonardr
[17:20] <leonardr> are you also getting test failures in toplevel.txt where httplib2 prints out debug messages when it's not expected
[17:20] <leonardr> ?
[17:42] <leonardr> wgrant, would you try running the tests with lp:~leonardr/launchpadlib/616055 and see if the test failures all go away?
[17:46] <james_w> leonardr: yes, that was one of the bug reports I filed I thought
[17:46] <james_w> leonardr: it appears to now GET earlier than the tests are expecting
[17:47] <leonardr> james_w: ok, try the new branch and everything should work
[17:50] <james_w> leonardr: your cover letter should probably explain how to get launchpad to use that branch when running the tests. Just running the command there will run the old version.
[17:54] <james_w> leonardr: anyway, they are running, I'll let you know after lunch
[17:55] <leonardr> james_w: great
[18:58] <james_w> leonardr: you missed one it seems: http://paste.ubuntu.com/476544/
[19:05] <leonardr> james_w: ah, that's an error in launchpad, not launchpadlib. that's why i didn't see it
[19:05] <leonardr> was that the only one?
[19:06] <james_w> leonardr: with -r launchpadlib, yes
[19:06] <leonardr> james_w: oh, actually the launchpad branch i'm working on already fixed that error, _that's_ why i didn't see it
[19:07] <lifeless> https://devpad.canonical.com/~stub/ppr/edge/latest-daily-timeout-candidates.html
[19:13]  * rockstar goes for a walk
[19:19] <bryceh> $ make lint-verbose
[19:19] <bryceh> ...
[19:19] <bryceh> ./bin/lint.sh: line 163: pocketlint: command not found
[19:19] <bryceh> aha nevermind
[19:23] <jml> lifeless, please review my testr branches
[19:23] <lifeless> flacoste: elmo: if you want to move the foundations call up, fine with me - as elmo is sprinting it might be easier/worse
[19:23] <lifeless> jml: thanks!
[19:24] <flacoste> elmo: i'm free, so it's your call
[19:26]  * jml off
[19:26] <lifeless> night jml
[19:27] <jml> g'night.
[19:27] <jml> I might be back later to land some patches for some testing tools. :)
[19:28] <lifeless> Ursinha: I'm sorrry, I haven't written the rollback patch yet
[19:29] <lifeless> Ursinha: if its not in your inbox your tomorrow am, please assume I'm swamped and won't get to it
[19:29] <Ursinha> lifeless, I can do that, if you don't have plans to do that soon
[19:29] <Ursinha> ah, sure
[19:29] <Ursinha> :)
[19:29] <lifeless> Ursinha: well, if you wanted to do it today that would be awesome
[19:29] <Ursinha> lifeless, I can do that
[19:29] <lifeless> \o/ thanks
[19:46] <lifeless> mthaddon: I kind of wish that https://lpstats.canonical.com/graphs/OopsEdgeHourly/20100712/20100811/ included the request count, to make me feel better :)
[19:46] <lifeless> but I know it would make the graph much less useful
[19:58] <flacoste> lifeless: given that elmo is in Madrid on a sprint, i'm not sure he'll make the conf call
[19:58] <lifeless> ok
[19:58] <lifeless> well, we can ring his mobile ;)
[20:01] <flacoste> lifeless: hmm, do you have an agenda?
[20:01] <lifeless> for the first meeting ? ;)
[20:02] <lifeless> rfwtad; lucene;
[20:02] <lifeless> the first implies an 'are we blocked on all lucid stuff, or just per machine', 'are we there yet' style annoying question, which I know he'd just -love-
[20:02] <lifeless> :P
[20:03] <flacoste> lifeless: unless you insist, i'd skip this one :-)
[20:03] <lifeless> its fine
[20:03] <lifeless> skipped, I'll be back in a bit
[21:50] <lifeless> ok
[21:51] <lifeless> who really understands the prejoin code
[22:22] <elmo> flacoste/lifeless: sorry I didn't intend to make the call but failed at timezone math and was afk at the scheduled time
[22:23] <flacoste> lifeless: jamesh does
[22:23] <lifeless> elmo: do you mean 'did intend' ?
[22:23] <lifeless> flacoste: I shall stalk him!
[22:23] <elmo> lifeless: yes
[22:23] <lifeless> elmo: no worries
[22:23] <elmo> apparently I also fail at English
[22:26] <lifeless> all I had for the meeting I put in the channel :)
[22:27] <elmo> AFAIK, lucid stuff is at the 'can do machines any time we want', but the LOSAs want to wait till they aren't sprinting for me to do the upgrades
[22:27] <elmo> the lucene one was a little dense for me
[22:29] <lifeless> elmo: I want to move forward on evaluating it
[22:30] <elmo> lifeless: ok - what do you need from me/us?
[22:30] <lifeless> need to coordinate temporary use of a machine or two with the grunt to reindex all of LP's content, to see how it performance and evaluate search results
[22:31] <elmo> *choke*
[22:31] <lifeless> may need a slave replica along the lines of staging to read the content to reindex from
[22:31] <elmo> is that all? :-P
[22:31] <lifeless> elmo: or we need to figure out a way to do a sensible evaluation
[22:31] <elmo> what's the grunt?  disk, memory or both?
[22:31] <elmo> if you know
[22:32] <lifeless> elmo: I'm raising this now so that we can figure out how to do it without panicing ;)
[22:32] <lifeless> Well, we don't /really/ know yet.
[22:33] <lifeless> Disk wise we need a copy of LP's DB - thats 250GB IIRC? And we'll need ~ that again for the index (to allow learning space)
[22:33] <elmo> ok
[22:33] <elmo> I'll let my brain background on WTF to do that
[22:33] <lifeless> memory I have no idea
[22:34] <lifeless> it might be so damn great that 1GB will do
[22:34] <elmo> and pigs might fly given sufficient thrust
[22:34] <lifeless> porcine aviators unite!
[22:34] <lifeless> ... pigs in space
[22:34] <lifeless> anyhow :)
[22:35] <lifeless> I suspect we'll need several GB to get the content out of pg efficiently, and lucene will want a few hundred MB, maybe a GB, to index as we go
[22:35] <lifeless> when we move onto test querying, we'll find out how good the index locality is.
[22:35] <lifeless> there is no schedule for this yet - as I say, I'm raising it to give you plenty of warning
[22:36] <lifeless> the broad plan I have is: evaluate it, and if its as good as all the feedback I've been getting, get a performance profile for it; then we will have some idea about how big a machine we need, and can start to talk deployment/migration/staging etc etc etc
[22:37] <lifeless> the goal is to take a lot of load off pgsql doing this
[22:37] <lifeless> so we might even free up a slave box or something : we don't know yet though.
[22:37] <lifeless> s/the goal/a goal/
[22:37] <elmo> sure, ok
[22:39] <lifeless> I'd be happy to evaluate on a really small memory/cpu box, and scale up if its not enough - but that may imply a bunch of fiddling and so on that isn't particularly helpful.
[22:39] <lifeless> I will be totally guided by you
[22:39] <wgrant> leonardr: Did you really mean me?
[23:08] <lifeless> wgrant: was the ppr useful ?
[23:09] <wgrant> lifeless: I was just reading it when #launchpad-meeting took my attention, so I forgot.
[23:09]  * wgrant looks.
[23:09] <lifeless> the stats are a little bong - I've sent stub a mp to fix em
[23:09] <wgrant> That is a wiide table.
[23:09] <lifeless> yeha
[23:09] <lifeless> sort by the 99% column
[23:10] <wgrant> There is no sorting. I guess I'll grab the JS manually.
[23:10] <lifeless> hmm
[23:10] <lifeless> it should be coming from people.canonical.com
[23:11] <wgrant> Ah, yes, it is, but Evo doesn't follow external links.
[23:11] <wgrant> Works fine in a web browser.
[23:12] <wgrant> That is an interesting page, certainly.
[23:17] <jml> good night all
[23:20] <mwhudson> night jml
[23:23] <leonardr> wgrant: sorry, i meant james_w
[23:23] <wgrant> Ah :)
[23:52] <poolie> lifeless: back to feature flags for a bit today
[23:54] <lifeless> cool