[00:13] <lifeless> wow
[00:13] <lifeless> some hair shows up when you dig
[00:13] <lifeless> found a code path that disables prejoins for speed
[00:13] <lifeless> (ok, fine so far)
[00:13] <lifeless> then, in the inner code it was calling, there is an if block that uses Storm rather than sqlobject joins, and so the prejoins don't get disabled ...
[00:26] <wgrant> Slow branch scanner makes me sad :(
[00:26] <lifeless> latency, throughput or capacity?
[00:27]  * rockstar picks all three
[00:27] <wgrant> Well, it took nearly four minutes from push to bug link.
[00:27] <rockstar> wgrant, that's odd.  I've never seen it take more than two.
[00:28] <thumper> rockstar: call?
[00:29] <rockstar> thumper, I thought you'd never ask.
[00:30]  * rockstar repeatedly slaps skype and pulseaudio
[00:45] <lifeless> oh ffs
[00:46] <lifeless> sqlobjectresultset is evil
[00:53] <rstat1> why's that?
[00:54] <lifeless> because it doesn't implement IResultSet
[00:54] <wgrant> Isn't that the point?
[00:54] <lifeless> so stuff like canonical.lib.components.decoratedresultset fail spectacularly when wrapping SQLORS
[00:54] <lifeless> wgrant: well, we want to migrate
[00:54] <lifeless> wgrant: yes
[00:54] <rstat1> you'd think it would be...given the name
[00:54] <lifeless> rstat1: yes
[00:55] <rstat1> got anymore ideas as to why my openid doesn't work?
[00:55] <lifeless> rstat1: I don't, sorry : I haven'ted poked at openid at all yet
[00:56] <rstat1> ahh...well ok.
[00:56] <Ursinha> lifeless, hi
[00:56] <lifeless> Ursinha: hi!
[00:57] <Ursinha> lifeless, so, are you willing to work on the rollback thing? :)
[00:57] <lifeless> yes, I'd love to
[00:57] <lifeless> I'm putting it in my queue right after fixing the fallout from trying to use DRS around a SQLRS
[00:57] <Ursinha> lifeless, cool
[00:57] <wgrant> rstat1: What if you revert to the stock LP Apache config?
[00:57] <lifeless> as its a different branch, I can work on it concurrently
[00:58] <lifeless> Ursinha: remind me of the log
[00:58] <Ursinha> lifeless, mars worked today on buildoutifying qa-tagger
[00:58] <lifeless> qa-rollback means 'it has been rolledout
[00:58] <Ursinha> I'm merging then you can branch it
[00:58] <rstat1> wgrant: I could try that..One seccond
[00:58] <lifeless> and thus qa-rollback means 'can deploy'
[00:58] <Ursinha> lifeless, yes, qa-rollback is, well, a rollback, so it's safe to land
[00:59] <Ursinha> I guess it's well described on a wiki page
[00:59] <Ursinha> let me find the link
[00:59] <lifeless> Ursinha: so, its a one-liner I think.
[00:59] <lifeless> one sec
[00:59] <Ursinha> lifeless, https://dev.launchpad.net/QAProcessContinuousRollouts
[01:00] <Ursinha> lifeless, tagger also has to identify which revision they're rolling back
[01:07] <lifeless> lp:~lifeless/qa-tagger/qa-rollback
[01:08] <lifeless> Ursinha: devs can manually tag that initially though, right? same as tagging qa-ok ?
[01:08] <rstat1> well of course it'd work when I did the default config
[01:08] <Ursinha> lifeless, no, the script sets that
[01:08] <rstat1> So its definitely an apache issue
[01:08] <lifeless> Ursinha: does or should
[01:08] <Ursinha> lifeless, should
[01:08] <lifeless> Ursinha: how should it ?
[01:09] <Ursinha> that's what you're supposed to change
[01:09] <Ursinha> lifeless, identifying a [rollback] tag in the commit message
[01:09] <lifeless> ok, let me look at that stuff
[01:11] <lifeless> Ursinha: how are you generating your test data for test_commit -
[01:11] <Ursinha> lifeless, in sample_data.tar.bz2 there's a branch
[01:12] <lifeless> :(
[01:12] <lifeless> you might like to migrate to self.make_branch_and_tree; its much more convenient IMO
[01:13] <lifeless> Ursinha: how do you propose rollback will mark what commit its rolling back ?
[01:13] <Ursinha> lifeless, when a person submits a branch that is a rollback, it marks the commit message as such
[01:13] <lifeless> I get that
[01:13] <Ursinha> that's adding [rollback]
[01:14] <Ursinha> ah
[01:14] <lifeless> but how do you propose we determine *what* branch is being rolledback
[01:14] <Ursinha> lifeless, sorry
[01:14] <lifeless> if you said
[01:14] <Ursinha> lifeless, by bug number
[01:14] <lifeless> but the rollback doesn't have one itself, does it ?
[01:14] <lifeless> we have two commits, A and B
[01:14] <lifeless> A says 'bug X'
[01:14] <lifeless> B says 'rollback'
[01:14] <lifeless> according to the wiki page
[01:14] <Ursinha> if a branch/bug is stuck with qa-needstesting or qa-bad, and the next commit is a rollback, you allow that last stuck revision to be rolled out
[01:15] <lifeless> we can look for tags in bug X when we're looking at commit A
[01:15] <lifeless> Ursinha: it won't be the next commit though
[01:15] <lifeless> Ursinha: it will be many commits - the pqm queue depth - later
[01:15] <Ursinha> lifeless, hm, right, so we would need to guarantee that all the others in between are ready to land
[01:15] <Ursinha> hm...
[01:16] <lifeless> Ursinha: well thats a separate problem.
[01:16] <Ursinha> I recall discussing that on the epic
[01:16] <lifeless> Ursinha: here's what I think
[01:16] <lifeless> developers should land a rollback branch
[01:16] <lifeless> and manually mark the bug as qa-rollback
[01:16] <lifeless> the rollback commit *itself* gets treated as deployable
[01:16] <Ursinha> right
[01:16] <lifeless> so if we have three commits
[01:17] <lifeless> A - faulty
[01:17] <lifeless> B - ok
[01:17] <lifeless> C - rollback
[01:17] <lifeless> when we process them, we see
[01:17] <lifeless> A:-> bug X -> tagged rollback
[01:17] <lifeless> B:-> bug Y -> tagged qa-ok
[01:17] <lifeless> C:-> rollback
[01:17] <lifeless> and we let all three past in this case
[01:18] <lifeless> if C has landed but bug X is still tagged qa-bad, we assume that C was rolling back something else.
[01:18] <lifeless> what do you think?
[01:18] <lifeless> we can look at a fancy way to figure out what C rolled back later
[01:18] <Ursinha> reading
[01:19] <lifeless> but right now we have a many branches with revnos that differ etc, so I'd be worried about adding a revno to the rollback message, or a bug.
[01:19] <lifeless> OTOH we could add [rollback=X]
[01:19] <lifeless> to mean 'rolls back bug X'
[01:20] <Ursinha> that was the idea, but indirectly, marking the commit as [rollback] and it having a bug linked
[01:20] <lifeless> linking a bug to it would be hard today, as neither bzr nor lp support links other than 'fixes'
[01:20] <Ursinha> lifeless, so your idea is to not depend on the script to identify which bug it's rolling back?
[01:20] <lifeless> Ursinha: as a first iteration
[01:21] <lifeless> Ursinha: I want to achieve 'ready to switch to this layout' _asap_; and improve once we're ready.
[01:21] <Ursinha> lifeless, ok
[01:21] <lifeless> spm: btw ping
[01:21] <Ursinha> so we have rollback and bad in the same bug, or only one of them?
[01:21] <Ursinha> tags, that is
[01:22] <lifeless> Ursinha: I think for sanity we should only have one qa-STATE tag at a time
[01:22] <lifeless> if its bad, we're blocked on a matching rollback
[01:22] <Ursinha> right
[01:22] <lifeless> hmm
[01:22] <Ursinha> that was my understanding
[01:22] <lifeless> actually - ah, got it.
[01:22] <lifeless> so, I propose we say [rollback=REVNO-ON-DEVEl]
[01:23] <lifeless> it is more work than I'd like
[01:23] <lifeless> but if we don't do that, we'll deploy something broken, I guarantee it.
[01:23] <spm> lifeless: yo
[01:24] <lifeless> and when we set qa-bad we need a revno too
[01:24] <lifeless> Ursinha: what time is it for you ?
[01:24] <Ursinha> lifeless, 9h24pm
[01:24] <lifeless> spm: heya. Staging prod shema QA environment
[01:24] <lifeless> Ursinha: ok, I'll write up a proposal for you
[01:24] <lifeless> and mail it to you and mars.
[01:24] <Ursinha> lifeless, are you doing this right now?
[01:25] <lifeless> I need to play on staging a bit and see if what I have in mind will work, and I don't want to keep you up late just waiting on me :)
[01:25] <spm> lifeless: I'll need a little more context than that :-)
[01:25] <Ursinha> lifeless, because I'm merging two branches to trunk that would be better for you to write code on top of them
[01:25] <lifeless> Ursinha: I'll deal
[01:25] <lifeless> if you want me to work on em, land em now :)
[01:25] <Ursinha> lifeless, okidoki
[01:25] <lifeless> spm: rt 40482 or something like that
[01:27] <lifeless> spm: yes, thats the one
[01:28] <lifeless> spm: we've missed you for a week, I wants to monopolise you now :)
[01:28] <spm> ....
[01:28] <lifeless> welcome back ?
[01:28] <spm> it's good to be 'needed'; for values of 'need' :-)
[01:31] <lifeless> :)
[01:31] <lifeless> Ursinha: basically what I'm going to arrange is enough data flow that commits in devel that are messed up are persistently recorded as messed up
[01:31] <lifeless> Ursinha: and commits that fix messed up ones record in their commit message that they do that
[01:33] <Ursinha> lifeless, right
[01:34] <lifeless> Ursinha: is it ok with you if I just edit the wiki page and ask you, Diogo and mars to tell me if I messed up ?
[01:34] <Ursinha> lifeless, that's ok, we have history there :)
[01:35] <lifeless> Ursinha: we'll need to change the lp-land stuff for rollback
[01:35] <lifeless> to take a parameter
[01:35] <Ursinha> lifeless, I was expecting that
[01:35] <lifeless> ok cool
[01:35] <Ursinha> lp-land and ec2 land
[01:40] <lifeless> Ursinha: ok, updated the page: qa-rollback state is gone
[01:40] <lifeless> Ursinha: please see if it makes sense :)
[01:40] <lifeless> spm: ok, so jocularity aside: are we there yet ? :)
[01:41] <jam> wgrant, lifeless: of course now I'm getting "Couldn't find a distribution for 'zope.publisher==3.12.0'" *sigh*
[01:42] <wgrant> jam: update your download-cache.
[01:42] <wgrant> Or just run rocketfuel-get, which does all that for you.
[01:51] <jam> wgrant: well, through a mix of various voodoo incantations, it finally works. Thanks for your help
[01:51] <jam> (rocketfuel-get isn't quite enough because it assumes you have an unpacked 'devel' working tree, etc. but it seemed to do what I needed)
[02:24] <Ursinha> lifeless, seems ok
[02:24] <rockstar> thumper, around?
[02:25] <rockstar> I needs a query run on staging: http://pastebin.ubuntu.com/479695/
[02:25] <rockstar> lifeless, maybe you can help? ^^
[02:28] <rockstar> spm, ^^
[02:30] <spm> rockstar: not without the magic word
[02:30] <rockstar> spm, even on staging?
[02:30] <rockstar> Oh, er, please?
[02:30] <spm> hahaha
[02:31]  * rockstar is American, so forgets his manners often...
[02:31] <spm> rockstar: actually, the magic word, so SWMBO tells me: is **NOW**!!. fwiw...
[02:31] <rockstar> spm, oh, then I should have gone with my instinct.
[02:31] <rockstar> :)
[02:31] <spm> heh
[02:31] <spm> rockstar: 0 rows
[02:32] <rockstar> spm, boo...
[02:33] <lifeless> Ursinha: thanks
[02:33] <lifeless> Ursinha: nearly done
[02:34] <Ursinha> lifeless, I'm feeling ill, I'll talk to mars and matsubara-afk tomorrow to be sure I'm not missing anything :)
[02:34] <lifeless> Ursinha: go sleep!
[02:36] <rockstar> spm, can you please try http://pastebin.ubuntu.com/479698/ **NOW**!!
[02:37] <thumper> rockstar: whazzup?
[02:37] <spm> rockstar: same; 0 rows
[02:38] <rockstar> thumper, I just needed some SQL queries run.
[02:38] <rockstar> spm, and how close to production is the staging db?
[02:38] <wgrant> Doesn't staging have its build queue cleared during the restore?
[02:39] <rockstar> wgrant, ooh...
[02:39] <spm> wgrant: along with several other tables of 'do stuff', I'd hope so.
[02:40] <rockstar> spm, can lifeless give the okay to run the first query on production?
[02:40] <lifeless> I can
[02:40] <lifeless> thumper should by the new policy in preference to me, as hes your tl
[02:41] <thumper> lifeless: I could but I'm multi-tasking with non-laptop tasks
[02:41] <rockstar> lifeless, yeah, but thumper's got his hands full.  :)
[02:41] <lifeless> ok
[02:41] <spm> rockstar: aiui, we only need approval to run modification queries; selects are fine. happy to be corrected.
[02:42] <lifeless> for now its mods that must get approval and be logged as incidents with high pri bug about not repeating it
[02:42] <rockstar> spm, could you run the first query on production then?
[02:43] <spm> rockstar: see. there's that missing magic word again. tsk tsk tsk.
[02:43] <rockstar> spm, **NOW**!!
[02:43] <spm> rockstar: 86 rows; need a paste?
[02:43] <spm> heh
[02:43] <rockstar> spm, not yet.  Lemme get a better query first, one that actually tells me more.
[02:44] <spm> 85... <== it's going down.
[02:44] <rockstar> spm, wait, what?
[02:44]  * rockstar is confused
[02:44] <rockstar> wgrant, around?
[02:46] <rockstar> spm, point of clarification: you ran http://pastebin.ubuntu.com/479695/ correct?
[02:46] <wgrant> rockstar: Indeed.
[02:46] <wgrant> Why wouldn't it be going down?
[02:46] <wgrant> You're looking for unstarted jobs.
[02:47] <lifeless> sometimes b-m builds stuff
[02:47] <mars> lifeless, nice performance tuesday follow-up mail, especially the steps you went through while solving.  I learned a thing or two from it.
[02:47] <lifeless> mars: cool, thanks
[02:47] <wgrant> lifeless: Occasionally.
[02:47] <lifeless> of course, now I'm fighting all sorts of shitty aqlobject-half-transition pain
[02:48] <spm> rockstar: hrm. no. was using the '698 paste, but doing so with 695.
[02:48] <wgrant> lifeless: Well, you could always port the problematic callers to something that isn't ancient.
[02:48] <spm> rockstar: and 78 rows now.
[02:48] <rockstar> spm, okay, I'd be interested to know if that one changes.
[02:48] <rockstar> (I suspect it won't)
[02:50] <lifeless> wgrant: have a look at BugTaskSet.search() and its callers
[02:50] <lifeless> wgrant: (e.g. yes, I want to)
[02:51] <wgrant> lifeless: Looks Stormy to me already...
[02:52] <lifeless> return SQLObjectResultSet
[02:52] <lifeless> in what possible world is that storm ? :)
[02:53] <lifeless> wgrant: its got some bits one way and some another - and its /callers/ are depending on some particular behaviours
[02:53] <lifeless> wgrant: its nuts.
[02:53] <wgrant> lifeless: Ah, true.
[02:53] <wgrant> Missed that bit.
[02:53] <spm> rockstar: 73 now... :-)
[02:53] <rockstar> spm, oh crap...
[02:54] <wgrant> rockstar: This must be the first time I've heard someone complain about buildd-manager being too fast.
[02:54] <thumper> rockstar: need to talk about it?
[02:55] <rockstar> wgrant, I'm complaining about the fact that my queries are proving my hypothesis wrong, and I don't like square one.
[02:55] <thumper> spm: is staging up?
[02:55] <rockstar> thumper, possibly.  One more query.
[02:55] <lifeless> thumper: end of an upgrade cycle I think
[02:55]  * thumper waits
[02:56] <spm> thumper: I suspect not. looks like we're in the security.py part of a DB restore/setup
[02:56] <thumper> spm: ETA?
[02:57] <rockstar> Oh wait, crap.
[02:57] <spm> "RSN"
[02:57] <spm> it's been going for around 1h 45 atm. so soonish.
[02:57] <lifeless> thumper: are we there yet. ""
[02:57] <rockstar> thumper, yes, I'd like to talk about it, if you have some time.
[02:58] <thumper> spm: I know RSN means NFI but soon
[02:58] <thumper> ish
[02:58] <thumper> rockstar: sure
[02:58] <spm> thumper: damn. you're onto me....
[02:59] <wgrant> rockstar: What's going on?
[02:59] <rockstar> wgrant, investimigating the cause of https://bugs.edge.launchpad.net/launchpad-code/+bug/618860
[03:00] <wgrant> rockstar: What's the traceback?
[03:01] <wgrant> That suggests that either the actual or estimated start time are wrong.
[03:01] <wgrant> s/wrong/None.
[03:01] <wgrant> Neither of which your query will identify.
[03:02] <rockstar> wgrant, http://pastebin.ubuntu.com/479708/
[03:03] <wgrant> rockstar: So you're searching for WAITING with a NULL date_started. Every waiting build should satisfy that. Don't you really want to look for non-WAITING with NULL date_started?
[03:04] <rockstar> wgrant, *facepalm*
[03:04] <wgrant> In fact, you probably want RUNNING.
[03:04] <rockstar> spm, can you please run http://pastebin.ubuntu.com/479709/ on production **NOW**!!
[03:04] <lifeless> sadness, /participants on staging still timesout
[03:05] <spm> lifeless: staging may not be up atm... is doing a DB restore/setup
[03:05] <spm> rockstar: woo. 3 rows.
[03:06] <rockstar> spm, okay, great.  Let's wait a bit, I'll tweak the query, and we'll run that again to see if it changes.
[03:06] <wgrant> What's their status? 1?
[03:06] <lifeless> spm: I know
[03:06] <lifeless> spm: the frontend is back
[03:06] <lifeless> whats the oops sync freq for staging ?
[03:07] <spm> it was 3 min at one point...
[03:07] <lifeless> sigh
[03:07] <lifeless> 1691S10
[03:07] <lifeless> when you have a cycle.
[03:08] <spm> 6 minutes
[03:08] <lifeless> hmm, I probably asked at 5 minutes...
[03:08] <lifeless> its there
[03:08] <lifeless> thanks
[03:08] <lifeless> SQL time: 10011 ms
[03:08] <lifeless> -sql time: 73 ms
[03:08] <lifeless> Total time: 10084 ms
[03:08] <lifeless> Statement Count: 8
[03:09] <lifeless> \o/ select count(*) ...
[03:09] <lifeless> OTOH 8 queries is fairly good
[03:13] <lifeless> so yeah, its finished the updated, still timing out :P
[03:13] <lifeless> probably we want something more sophisticated than decoratedresultset here
[03:14] <lifeless> because - count(*) doesn't need all the left joins
[03:14] <lifeless> (OTOH count(*) there is a bad idea anyway)
[03:23] <mtaylor> thumper: "Compare with another revision" in loggerhead doesn't seem to do what I was assuming it would do
[03:23] <mtaylor> thumper: that being - to compare this revision with another revision
[03:23] <thumper> mtaylor: loggerhead has issues
[03:23] <thumper> mtaylor: but it does work, but the ui for it is hard to understand
[03:23] <mtaylor> thumper: ok. :)
[03:31] <lifeless> \o/ 5.8 seconds to do the count(*) :<
[03:32] <mtaylor> lifeless: that's not good
[03:33] <lifeless> I'll paste you the query
[03:34] <lifeless> mtaylor: its not entirely unexpected
[03:34] <lifeless> we have some attributes that are 1:M and we're selecting the first-one in correlated subqueries for a team with 174 folk in it
[03:35] <lifeless> denormalasing and caching the preferred email and default archive would save a batshit amount of time, I suspect
[03:36] <lifeless> or
[03:36] <lifeless> it may be bad indexes or something on some component
[03:36] <lifeless> I'm pulling sections of the query out and its staying the same ;)
[03:37] <lifeless> also, I bet sodium just shat itself
[03:38] <lifeless> so, back to qa tagging
[03:38] <lifeless> spm: please time http://pastebin.com/CV4wDPE1 on a prod slave
[03:40] <spm> lifeless: 8.5 seconds
[03:41] <lifeless> spm: grah
[03:41] <lifeless> spm: need to find out why
[03:41] <spm> and 2 x 6 seconds on repeats.
[03:41] <lifeless> when sodium comes back I'll pokey pokey there
[03:42] <spm> lifeless: https://pastebin.canonical.com/35966/ fwiw....
[03:42] <lifeless> oh god I hate views
[03:42] <lifeless> have I mentioned that?
[03:43] <lifeless> can probably make this fractional-second without that view in there
[03:44] <spm> i do str you mentioning a mild dislike of views a few weeks back....
[03:45] <wgrant> Which view is it today?
[03:45] <lifeless> validpersoncache
[03:45] <wgrant> Ah, ValidPersonCache?
[03:45] <lifeless> which is a LIE
[03:45] <wgrant> is that really a view?
[03:45] <lifeless> a stinking lie
[03:45] <wgrant> It's not a view in the dev schema.
[03:45] <wgrant> Or.
[03:45] <wgrant> Wait.
[03:45] <wgrant> It *is* a view, not a cache. That's right.
[03:46]  * wgrant headdesks.
[03:49] <mwhudson> !
[03:49] <thumper> heh
[03:50] <wgrant> rockstar: How is it Fix Released?
[03:51] <wgrant> It was broken just an hour ago...
[03:51] <thumper> mwhudson: how do you specify a layer for the create_initialized_view?
[03:51] <thumper> mwhudson: what form does the layer param take?
[03:52] <thumper> mwhudson: class? or string?
[03:52] <rockstar> wgrant, that's the glory of running sql to fix the bug.  :)
[03:53] <mwhudson> you can probably haul what the view is checking into the rest of the query?
[03:53] <wgrant> rockstar: But isn't there still a bug that created the broken data?
[03:53] <rockstar> wgrant, the corrupted records were from before we added the cancel build button, and we were cancelling builds with raw sql.
[03:53] <wgrant> Ah, right.
[03:54] <wgrant> Sorry, I'm just a little wary about people waving away buildfarm data corruption bugs without explanation.
[03:54] <mwhudson> thumper: um, probably class
[03:54] <wgrant> That tends to come back to bite us and cause things to burn down.
[03:55] <mwhudson> thumper: i'd lean to passing a request that provided the appropriate layer though, i think
[03:56] <thumper> mwhudson: attempting to pass the CodeLayer through
[03:56] <thumper> lets see...
[03:56] <thumper> I've been a bit more strict on where the views live
[03:56] <thumper> now all the tests fail :)
[03:56] <rockstar> wgrant, yeah, I'm not about to sweep buildfarm bugs under the road.
[03:56] <thumper> yep that works
[03:56] <mwhudson> thumper: haha
[03:56] <mwhudson> good though
[03:56]  * thumper ndos
[03:56]  * thumper nods even
[03:59] <lifeless> SELECT COUNT(*) FROM Person JOIN TeamParticipation ON TeamParticipation.person = Person.id LEFT JOIN KarmaTotalCache ON KarmaTotalCache.person = Person.id LEFT JOIN PersonLocation ON PersonLocation.person = Person.id LEFT JOIN Archive ON Archive.owner = Person.id LEFT JOIN EmailAddress ON EmailAddress.person = Person.id LEFT JOIN ValidPersonCache ON ValidPersonCache.id = Person.id WHERE TeamParticipation.team = 238131 AND NOT (Te
[03:59] <lifeless> bah
[03:59] <lifeless> anyhow
[03:59] <lifeless> sorry
[03:59] <lifeless> 19ms without validpersoncache
[03:59] <lifeless> :)
[04:00] <lifeless> mtaylor: ^
[04:00] <lifeless> wgrant: ^
[04:00] <thumper>  LEFT JOIN ValidPersonCache ?
[04:00] <thumper> I thought you said without?
[04:02] <wgrant> lifeless: I wonder how hard it is to drop that view.
[04:02] <mtaylor> lifeless: lovely
[04:02] <lifeless> thumper: as I said, paste fail
[04:02] <lifeless> thumper: thats not the query without it
[04:03] <lifeless> without it, and with the logic put back in via account directly
[04:03] <lifeless> its 32ms
[04:03] <lifeless> LEFT JOIN account on person.account=account.id  WHERE TeamParticipation.team = 238131 AND NOT (TeamParticipation.person = 238131) AND (Archive.id IS NULL OR Archive.id = (SELECT MIN(Archive.id) FROM Archive WHERE Archive.owner = Person.id) AND Archive.purpose = 2) AND (EmailAddress.status IS NULL OR (EmailAddress.status = 4 AND account.status=20));
[04:03] <lifeless> is the end of the updated query
[04:03] <wgrant> lifeless: How does the view make the plan so bad?
[04:03] <wgrant> Also, EmailAddress.status IS NULL?
[04:03] <lifeless> dunno
[04:03] <wgrant> WTF?
[04:04] <lifeless> wgrant: teams
[04:04] <wgrant> status is NOT NULL.
[04:04] <wgrant> Ah, right.
[04:04] <wgrant> Fair point.
[04:04] <wgrant> But I'd rather you checked Person.owner explicitly.
[04:04] <lifeless> so, this isn't *quite* right, we're losing 4 participants somewhere, but I know the general shape that needs changing
[04:05] <lifeless> wgrant: if you want to do this follow on fix, I'd be delighted
[04:06] <lifeless> oh, I know why, I need an ACCOUNT.status is NULL in there
[04:06] <lifeless> wgrant: you have to be very careful otherwise you exclude rows you don't want to
[04:06] <lifeless> wgrant: or generate a torturous query plan
[04:07] <lifeless> wgrant: semantically though, status is NULL IFF no row was returned
[04:07] <lifeless> thats the correct end bit : AND (account.status is NULL or account.status=20)));
[04:08] <lifeless> so you'd need a pretty deep nested check on person.owner to do it your way.
[04:08] <wgrant> lifeless: I know. But you don't want to check that there's no emailaddress; you want to check that it's a team.
[04:09] <wgrant> Why would it need a deep check?
[04:09] <lifeless> so
[04:10] <lifeless> consider this:
[04:10] <lifeless> AND (EmailAddress.status IS NULL OR (EmailAddress.status = 4 AND account.status=20));
[04:10] <lifeless> assuming we don't have data corruption
[04:10] <lifeless> mmm
[04:10] <lifeless> let me get back to you in a sec
[04:11] <lifeless> you are suggesting
[04:11] <lifeless> AND (person.teamowner IS NULL OR (EmailAddress.status = 4 AND  account.status=20));
[04:11] <lifeless> right ?
[04:11] <lifeless> to replace the whole email address and account status checks
[04:12] <jtv> hi folks
[04:12] <spm> heya jtv
[04:14] <lifeless> wgrant: the problem is that that generates 663 rows, not 174
[04:14] <wgrant> lifeless: What.
[04:15] <jtv> hi spm
[04:15] <wgrant> Something's not doing what we think it is, clearly.
[04:15] <jtv> whoo-hoo, FakeLibrarian just landed
[04:15] <wgrant> lifeless: What are the two complete queries?
[04:15] <wgrant> And what is their purpose?
[04:15] <lifeless> wgrant: see the pastebin above for the current one in devel
[04:15] <lifeless> for /participants
[04:15] <lifeless> Person._all_members
[04:16] <lifeless> wgrant: http://pastebin.com/1iQZhpSJ is a hand updated one to discard the view
[04:17] <lifeless> spm: ^ could you time that on a prod slave please?
[04:19] <spm> lifeless: meh. try again. only 30ms on the first run; 15ms on the repeats. still too slow.
[04:19] <lifeless> sorry
[04:20]  * spm can spot a lack of sincerity at 100 paces
[04:20] <lifeless> we're going to spend 10 times that parsing into python
[04:20] <lifeless> so yeah
[04:20] <lifeless> its hard to be concerned
[04:20] <spm> :-D
[04:22] <wgrant> lifeless: I wonder if we can just delete Person.archive and hope nobody notices.
[04:22] <lifeless> wgrant: quite possibly, but note that we're delivering it pretty darn quickly
[04:23] <wgrant> Yes, but it's awful.
[04:23] <lifeless> wgrant: sure, I'll let soyuz folk worry about that :)
[04:23] <lifeless> its simpler for me to just make it fast than worry about whether folk are using it.
[04:23]  * wgrant stabs.
[04:24] <thumper> mwhudson: I think I've found a problem :)
[04:25] <thumper> canonical_url has a bug
[04:27] <lifeless> sigh
[04:27] <lifeless> sodium, you suck
[04:27]  * jtv bates breath until thumper elaborates, and is now turning purple
[04:28] <thumper> gah
[04:28] <thumper> canonical_url(some_branch, view='+edit') now fails
[04:28] <thumper> because the edit view is only on the CodeLayer
[04:28] <lifeless> spm: could you try http://pastebin.com/ev56h4eY ? I would on staging, but devpad is dead
[04:28] <thumper> even though the canonical_url(some_branch) specifies the code subdomain
[04:28] <lifeless> and we don't have access to sourc
[04:30] <thumper> not sure how to fix this one...
[04:30] <lifeless> isn't that what curtis was talking about yesterday?
[04:30] <lifeless> in his review of one of jc's things?
[04:31] <thumper> lifeless: I don't know
[04:31] <thumper> do you remember which review?
[04:31] <lifeless> sorry no
[04:31] <lifeless> but he was saying that our same-host url logic was rather strict
[04:32] <lifeless> or something like that
[04:32] <lifeless> sounds very similar
[04:32] <lifeless> spm: ^
[04:36] <mwhudson> thumper: um
[04:36] <mwhudson> thumper: canonical_url looks at the current request
[04:36] <thumper> mwhudson: yeah
[04:36] <thumper> mwhudson: any idea how to create a request based on the rootsite?
[04:36] <mwhudson> are you calling canonical_url while a request is 'going' in your tests?
[04:37] <mwhudson> thumper: LaunchpadTestRequest() i hope?
[04:37] <mwhudson> if not
[04:37] <mwhudson> request = LaunchpadTestRequest()
[04:37] <thumper> there is probably an anonymous interaction going
[04:37] <mwhudson> directlyProvides(LaunchpadLayerOrWhatever, request)
[04:38] <thumper> hmm...
[04:38]  * thumper goes to make a coffee to help think
[04:42] <jtv> thumper: can I get some?
[04:42] <jtv> lifeless, I was just wondering about another side of canonical_url that might have interested you yesterday.
[04:43] <jtv> It basically interates a singly-linked list of ICanonicalUrlData(foo).inside.
[04:43] <jtv> Then for each of those, it gets ICanonicalUrlData(foo).path.
[04:43] <lifeless> O(N^2)
[04:44] <jtv> But it's essentially a recursion: walk from "here" to the root of a tree.
[04:44] <lifeless> or worse
[04:44] <lifeless> jtv: yes, I think its rather terrible :)
[04:44] <jtv> I don't see the n² part there tbh
[04:44] <jtv> …but why not cache the cumulative paths to cut short the iterations?
[04:45] <lifeless> well, things get renamed
[04:45] <jtv> This is all browser code.  It only live for the duration of the request.
[04:45] <lifeless> so a good case to consider
[04:45] <lifeless> 'rename this branch
[04:46] <jtv> Not much renaming going on in a GET, and not much URL rendering going on in a POST
[04:46] <lifeless> start of the request, its foo
[04:46] <lifeless> end of the request its bar, and we issue a redirect to the canonical url
[04:46] <lifeless> so, its cachable, just have to invalidate
[04:46] <lifeless> does canonical_url show up in profiling for us ?
[04:46] <jtv> well, the link formatter does.
[04:47] <lifeless> what does kcachegrind think is using up the time
[04:47] <jtv> I don't know, tbh; I'd have danilo & adi who looked into a page where the link formatter was a deadly source of delays.
[04:48] <jtv> Link formatters and menu… thingies were the big ones IIRC
[04:48] <jtv> And I'm guessing the same principles apply.
[04:49] <lifeless> so, I'm open to this sort of thing; theres no reason many things can't be cached; just need an invalidation strategy - and to understand *why* it needs a cache.
[04:49] <thumper> jtv: sure, fly here and I'll make you a coffee
[04:50] <jtv> lifeless: right, imagine a branch listing for a project.  Each branch link will probably repeat the same steps for the same project or person.
[04:50] <lifeless> yes
[04:50] <lifeless> if thats cheap, doesn't matter
[04:50] <lifeless> if its not, it does
[04:50] <jtv> thumper: the best part of that idea is, I think I can get a decent coffee at the airport on the way
[04:50] <lifeless> I'm not saying I'm for or against, I'm saying lets get the data
[04:51] <jtv> lifeless: no worries, I'm just adding some illustration I happened to have at hand before I get off my figurative arse to get data.
[04:53] <jtv> lifeless: I do remember one thing, i.e. that MenuAPI was definitely a big killer there.  Very costly.
[04:55]  * jtv wonders if just turning some of its hugely expensive-looking @property's into @cachedproperty's would be enough to shortcut repetitive computations
[04:55] <thumper> ✁☹
[04:55] <jtv> thumper: don't stick it in your ear, it's bad
[04:55] <jtv> 8< :-(
[04:55] <thumper> jtv: no shit sherlock
[04:57] <thumper> mwhudson: I can't really use a LaunchpadTestRequest for the canonical_url fix
[04:58] <thumper> mwhudson: what I really need to do is to create a valid request for the base url part of the canonical_url
[04:58] <thumper> or should I say, the urlparts
[04:59] <thumper> or rootsite, which is valid by the time we need to create a request
[05:03] <mwhudson_> yay flaky wifi
[05:05] <thumper> mwhudson_: can I skype you to talk this through?
[05:08] <mwhudson_> thumper: ok
[05:09]  * thumper waits for mwhudson_ to come online
[05:09] <mwhudson_> oh yeah
[05:11] <mwhudson_> thumper: i'm online now
[05:11] <lifeless> spm: ping
[05:12] <lifeless> spm: could you please apply 11370 from lp:~lifeless/launchpad/registry onto staging's appserver? its a teeny tiny patch
[05:15] <lifeless> mwhudson_: pear seems rather uhm, unhappy
[05:19] <mwhudson_> lifeless: context?
[05:19] <mwhudson_> hardware -> losa
[05:19] <mwhudson_> software -> a launchpad-code developer
[05:19] <mwhudson_> >:)
[05:22] <lifeless> mwhudson: cron mails
[05:22] <mwhudson> lifeless: i don't get them any more
[05:22] <lifeless> ah
[05:22] <lifeless> File "/srv/importd.launchpad.net/production/launchpad/cronscripts/code-import-dispatcher.py", line 46, in <module>
[05:22] <lifeless>    script.lock_and_run()
[05:22] <lifeless>   File "/usr/lib/python2.5/xmlrpclib.py", line 787, in close
[05:22] <lifeless>    raise Fault(**self._stack[0])
[05:22] <lifeless> xmlrpclib.Fault: <Fault -1: 'OOPS-1691XMLP15'>
[05:22] <wgrant> mwhudson: Don't worry, you are forever branded as a Code developer :P
[05:23] <lifeless> with a ... in the middle
[05:23] <mwhudson> lifeless: that's a serverside oops
[05:24] <mwhudson> lifeless: it's a timeout
[05:24] <mwhudson> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1691XMLP15
[05:24] <lifeless> SQL time: 8125 ms
[05:25] <lifeless> bit worrying
[05:25] <lifeless> that it sat around for 8 seconds after that before trying another query
[05:25] <lifeless> also worrying that it took 8 seconds to issue an update
[05:26] <lifeless> possibly just another slow page killing it
[05:36] <mwhudson> it's probably contention
[05:36] <mwhudson> there was a short thread on the mailing list about this
[05:36] <lifeless> a while back?
[05:37] <mwhudson> just before the epic i think
[05:37] <lifeless> you're updating the same page or something?
[05:37] <lifeless> or the same rows
[05:37] <mwhudson> yeah, same rows
[05:38] <wgrant> Was it something about multiple jobs updating the machine heartbeat?
[05:38] <wgrant> I forget.
[05:39] <poolie> lifeless: you asked before about running multiple vms
[05:40] <poolie> i don't think there's much to it is there?
[05:40] <poolie> the best thing i learned was to use vm-builder
[05:40] <poolie> as i described on https://dev.launchpad.net/Running/VirtualMachine
[05:40] <poolie> and then there's just the sadly usual fluff of getting dependencies set up properly
[05:46] <poolie> losa ping, could you please hurry up my builds in https://edge.launchpad.net/~bzr/+archive/proposed/+packages
[05:48] <wgrant> You know, it would be interesting to have a graph of build farm queue depth.
[05:48] <wgrant> And build farm throughput.
[05:48] <spm> poolie: did you have a priority of "really wants" there? cause that's about 5 mins of clicky pain you're inflicting on me
[05:49] <poolie> urk, really?
[05:49] <poolie> in that case never mind
[05:50] <spm> click the page; open the build; click to arch; click to edit score; edit score; save; repeat. fun fun fun. :-/
[05:51] <spm> wgrant: I think we do... or something similar at any rate
[05:53] <lifeless> spm: hi
[05:53] <lifeless> spm: 16:12 < lifeless> spm: could
[05:53] <lifeless> bah
[05:53] <lifeless> 16:11 < lifeless> spm: ping
[05:53] <lifeless> 16:12 < lifeless> spm: could you please apply 11370 from lp:~lifeless/launchpad/registry onto staging's appserver? its a teeny tiny patch
[05:53] <spm> lifeless: yo, that patch should have just finished restarting
[05:54] <lifeless> thanks!
[05:54] <lifeless> \o/
[05:54] <spm> works?
[05:54] <lifeless> yeah
[05:55] <lifeless> Total Bytes	159653 bytes
[05:55] <lifeless> Request Timing	@0ms for 2510ms
[05:55] <lifeless> Response Timing	@2510ms for 851ms
[05:55] <lifeless> still slower than I'd like, but well within my stage 1 perf targets
[05:56] <lifeless> spm: you can back that out now, if yo ulike
[05:56] <spm> lifeless: is it problematic if it stays and just gets wiped in the next staging update?
[05:56] <lifeless> fine by me
[05:56] <spm> cool; I'll leave it in then
[05:56] <lifeless> of course, it hasn't been qa'd etc yet
[05:57] <poolie> lifeless: i'm getting repeated timeouts copying packages, is that known?
[05:57] <lifeless> yes
[05:57] <wgrant> poolie: Copy fewer each time.
[05:57] <wgrant> And hope that it works.
[05:57] <poolie> yes, that's what i was going to do
[05:58] <poolie> just wondered if it was already known
[05:58] <wgrant> yes, the copy checker is slow :(
[05:58] <wgrant> The copy itself is tiny.
[05:58] <thumper> mwhudson: thanks, but I think we're done
[05:58] <mwhudson> thumper: i think so too
[05:58] <mwhudson> frigging wif
[05:58] <mwhudson> i
[05:59] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/32953
[05:59] <lifeless> meh
[06:02] <wgrant> spm: Do you know if there's a ticket about setting up the PPA log parser on germanium?
[06:06] <stub> spm: We have a choice of 1) upgrade sourcherry to Lucid with both PostgreSQL 8.3 and PostgreSQL 8.4 installed and do a test migration and switch staging to PostgreSQL 8.4, or, 2) Do a test migration from PostgreSQL 8.3 on sourcherry to PostgreSQL 8.4 on another box, then upgrade sourcherry to Lucid and PostgreSQL 8.4
[06:07] <lifeless> evening stub
[06:07] <stub> Morning :)
[06:08] <lifeless> stub: do you have any opinion on validpersoncache ?
[06:08] <lifeless> stub: using it in /participants vs using account directly gave 6second queries vs 35ms ones
[06:10] <lifeless> stub: (its a view now, even it if wasn't in the past)
[06:11] <stub> I tend to consider it legacy - Storm makes things nicer so we don't need views as a crutch. However, they should perform pretty much identically as validpersoncache isn't doing anything your direct query isn't.
[06:12] <stub> lifeless: Have you confirmed your join criteria matches validpersoncache's, or did you not need to join with emailaddress for instance?
[06:13] <lifeless> stub: same row count
[06:13] <lifeless> stub: https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/32953 shows the transition
[06:13] <lifeless> (same row count executing the sql by hand, the patch should get the same but I haven't hand-checked the generated sql yet)
[06:14] <poolie> wgrant: there is a graph of build queue length in lpstats
[06:14] <stub> So you have removed the check for a preferred emailaddress.
[06:14] <poolie> not updated for a while
[06:14] <lifeless> stub: no
[06:14] <stub> lifeless: but I see emailaddress is joined earlier and filtered later..
[06:14] <lifeless> stub: still check that - the query returns teams as well
[06:15] <wgrant> poolie: Ah.
[06:16] <poolie> i have a note here to make tuolumne more robust
[06:16] <poolie> at the moment if any monitor method fails, nothing gets updated
[06:16] <stub> I'll have a look at the function... I'm missing context
[06:17] <lifeless> stub: https://lp-oops.canonical.com/oops.py/?oopsid=1691S10
[06:18] <lifeless> shows the vpc based query
[06:19] <stub> So yes, unpacking the view worth doing here as the emailaddress table may already be joined with
[06:20] <stub> lifeless: The check for result.preferredemail concerns me though as I suspect it will do a database query. There is some magic there though, so maybe it is prepopulated.
[06:20] <lifeless> stub: its prepopulated by the row before
[06:20] <lifeless> decorator-thing-before
[06:20] <lifeless> so its fine
[06:21] <lifeless> and there is a test on the query count for the API
[06:23] <stub> Ok. The query might be a little more efficient if you add 'EmailAddress.status == 4, EmailAddress.person == None' so you don't see invalid rows in the first place.
[06:26] <lifeless> stub: the new one performs at 35ms for ubuntu-dev :)
[06:27] <stub> Yes, and adding the extra filter might be even faster
[06:27] <lifeless> stub: remember that it returns teams too, deliberately.
[06:27] <lifeless> so we want those rows
[06:28] <stub> So Or(Person.teamowner != None, And(EmailAddress.status == 4, EmailAddress.person == None))
[06:28] <lifeless> stub: I agree that when it gets generalised to prepopulating any person query, that we'll want to conditionalise that on whether we expect teams or not
[06:28] <lifeless> stub: for some reason, doing something very much like that cut off rows we want
[06:29] <wgrant> person == None? Huh?
[06:29] <stub> Which could be another bug.
[06:30] <stub> An emailaddress might be linked to just an account, not an account and person. Checking for person == None is probably unnecessary.
[06:30] <wgrant> Also, can we please shoot ShipIt in the face so we can delete this whole Account mess?
[06:30] <lifeless> we can also switch to inner joins when we don't want teams back
[06:30] <stub> wgrant: +1
[06:30] <wgrant> It is the only reason all this crap still exists.
[06:30] <lifeless> wgrant: is *that* where it comes from?
[06:30] <stub> Oh right... its an outer join for teams
[06:30] <wgrant> lifeless: Not where it comes from, but why it still exists.
[06:30] <stub> But my expression should be fine for that
[06:31] <lifeless> stub: yes, which is why comparing a field needs a (field is NULL or field=xx) otherwise all the NULL rows disappear
[06:31] <lifeless> even inside an OR, for reasons I don't remember right now
[06:31] <stub> lifeless: There would be a 1:1 relationship between person and account except for shipit, as you don't need to use Launchpad to use shipit.
[06:32] <lifeless> I wonder if shipit could move onto the SSO
[06:32] <lifeless> and just use LP for karma checks
[06:32] <stub> lifeless: EmailAddress is only checked if Person.teamowner is NULL, so only for people.
[06:32] <stub> lifeless: ISD was going to rewrite it in Django, but I don't think it is scheduled.
[06:32] <lifeless> I'll dig up the exact queries and debug with you later
[06:33] <stub> lifeless: But what you have is already an improvement.
[06:33] <lifeless> stub: separate from a rewrite, I mean :)
[06:33] <lifeless> stub: ok with me landing it? jtv has reviewed
[06:33] <stub> lifeless: Could do, yes. Simplest to give it its own database.
[06:33] <stub> lifeless: sure
[06:33] <lifeless> \o/
[06:33] <wgrant> lifeless, stub: If we can convince SSO to send karma in the OpenID response, or ShipIt to use the API for karma checks, we can just run ShipIt off in its own little DB with a static copy of the LP codebase.
[06:33] <stub> lifeless: I'm +1 on expanding all our views.
[06:35] <stub> urgh. And here I am thinking shipit was already separate from the LP tables except for Account and EmailAddress. Karma too :-P
[06:35] <wgrant> It also uses TeamParticipation, but SSO provides that.
[06:35] <wgrant> So it's not much of a blocker.
[06:35] <lifeless> stub: thats why I said 'lp for karma checks' :)
[06:36] <lifeless> API for karma checks makes a great deal of sense to me
[06:36] <lifeless> wgrant: want to patch it ?
[06:36] <lifeless> wgrant: I bet a patch to the pre-breakout code would apply.
[06:37] <lifeless> stub: care to note the expanding-views thing in dev.lp.net/Database/Performance ?
[06:37] <wgrant> Heh.
[06:38] <lifeless> any us folks still around?
[06:39] <lifeless> would like to know how long https://api.staging.launchpad.net/1.0/~ubuntu-dev/participants takes for you (before staging updates blow it away)
[06:40] <wgrant> 0.9s to wget it.
[06:40] <lifeless> hmm, nice
[06:40] <wgrant> edge is still waiting.
[06:40] <lifeless> yes, it will be
[06:40] <wgrant> Oh.
[06:40] <wgrant> No, it's only 1.0s from edge.
[06:41] <lifeless> hmm
[06:41] <wgrant> First negotiation just took a while. Not sure why.
[06:41] <lifeless> theres something wrong there
[06:41] <wgrant> Might be cached, since I'm anonymous.
[06:41] <lifeless> yes
[06:41] <lifeless> this exact url is hit by some client
[06:42] <lifeless> showed up in oops reports a while back, I put my branch together but was blocked on cachedproperty and rollouts n stuff
[06:42] <wgrant> 2.6s for staging uncached.
[06:43] <lifeless> tolerable
[06:43] <wgrant> production ~7
[06:43] <spm> wgrant: yeah there is - to re-enable it. but it needs some manual love to verify it doesn't go bananana's on us again.
[06:43] <wgrant> What's required for that manual love?
[06:43] <lifeless> wgrant: prod and edge are still running the pre-refactored code
[06:44] <lifeless> wgrant: which means their count(*) is on the teamparticipation table only
[06:44] <spm> stub: I'd be in favour of option 1; if it breaks hard, we learn. worst case, recover from backup (wheee)
[06:44] <lifeless> and then you're seeing the lookup time for 50 people only
[06:44] <spm> wgrant: *time*
[06:44] <wgrant> spm: Ah :(
[06:45] <lifeless> I really want to look at a kcachegrind of it
[06:45] <lifeless> because theres just no justification for it taking more than a second ><
[06:45] <lifeless> I mean
[06:46] <lifeless> 35 ms + 35ms = 70ms, so wtf is the time going
[06:47] <wgrant> From right next to the DC, it takes 80ms for a cached response, ~2s uncached.
[06:47] <wgrant> Oddly slow.
[06:48] <wgrant> Sometimes up to 3.5s...
[06:48] <stub> spm: Ok. I should RT this or discuss on losas@ ?
[06:49] <spm> stub: probably email; it's kinda a funky one.
[06:50] <lifeless> that fix is ec2ing
[07:12] <lifeless> poolie: by multiple vms I meant
[07:12] <lifeless> poolie: glue to run 1/8th per vm, or whatever
[07:12] <poolie> oh, no, i haven't done that
[07:12] <poolie> wbn
[07:13] <poolie> i have one vm running the whole suite, one vm for actual development, and then a host OS running a browser and at 2mb/vm that's about it
[07:13] <lifeless> stub: thanks
[07:41] <lifeless> Ursinha: present for you: https://code.edge.launchpad.net/~lifeless/qa-tagger/qa-rollback/+merge/32959
[07:50]  * wgrant mutters something along the lines of "why is the QA tool private?"
[07:50] <lifeless> wgrant: told you already
[07:50] <lifeless> wgrant: and will be fixed, but not top of the pops
[07:51] <wgrant> Oh, right, I remember now.
[07:51] <wgrant> Sorry.
[07:51] <lifeless> you know what would be neat
[07:52] <lifeless> the revisions list in mps and branch pages linking each rev with an expander
[07:52] <lifeless> like on loggerhead
[07:52] <wgrant> You mean having a code browser not completely unintegrated with LP?
[07:52] <lifeless> that would show the lh list of changes in the rev
[07:52] <lifeless> and that clickable to expand into a full diff
[07:52] <lifeless> should be easy thanks to mwhudson jsonifying the guts
[08:02] <lifeless> .count is storm, right ?
[08:05] <wgrant> Yes.
[08:06] <lifeless> man this is a mess
[08:06] <lifeless> (I'm back on bug search)
[08:07] <wgrant> At least you only have to fix it once.
[08:08] <lifeless> doubtful
[08:08] <lifeless> this is going to take stabs and stabs
[08:08] <lifeless> also
[08:08] <lifeless> search
[08:08] <lifeless> great name in a typed language
[08:08] <lifeless> fffffreaking painful in python
[08:26] <poolie> spm, if you're still here, can you add or check my gpg key
[08:26] <spm> poolie: oh sorry - I completely forgot about that from this morn. 1001 apologies.
[08:26]  * spm chases...
[08:37] <spm> poolie: actually I'm not going to get to that. I'm about 8 levels deep in critical fail interrupts atm. afaict, the prob is you don't actually have access in the config; irrespective of the key. suggest an RT is in order; it's relatively easy to do.
[08:38] <poolie> spm, no problem at all, it's not critical
[08:38] <poolie> mostly just wondered if i was doing it wrong, as often happens :)
[08:39] <poolie> is it just me or did lp lose all its icing?
[08:39] <wgrant> poolie: See #launchpad.
[08:39] <wgrant> edge update broke things.
[08:44] <poolie> i see
[08:45] <adeuring> good morning
[08:54] <lifeless> poolie: reminder (assuming I didn't miss it) - talk up your awesome flags stuff to the list
[08:56] <poolie> lifeless: my last thing for today is to bump the docs along a bit then post
[08:56] <poolie> then cook a pumpkin, etc
[08:57] <lifeless> \/ pumppkins
[08:57] <lifeless> its scary how tolerant storm is of different ways of spelling shit
[08:58] <poolie> maybe i'll reorder that
[08:58] <poolie> crap, poopie, poop, poo, ...
[08:58] <lifeless> I have a bastard hybrib frankensteins monster of sqlobject & storm ... and its still working
[08:59] <bigjools> morning all
[09:00] <wgrant> Morning.
[09:01] <poolie> lifeless: ok, mail sent, please followup with anything else you thing ought to be said about it now
[09:09] <lifeless> poolie: done and thanks.
[09:09] <lifeless> this is huge ;)
[09:09] <poolie> will pydoctor interpret rest correctly?
[09:09] <poolie> or something else?
[09:10] <poolie> actually what i mean is, what markup can i use in docstrings?
[09:12] <lifeless> I've just been doing the bzr thing
[09:12] <lifeless> and assuming I'll fix it up later
[09:12] <wgrant> I think pydoctor does ReST. But I'm not sure what the Zope apidoc thing wants.
[09:13] <poolie> lifeless: good question in mail
[09:17] <mrevell> Hallo
[09:17] <poolie> hi mrevell
[09:17] <poolie> mrevell: francis suggested you might help me do a UDD user surevy
[09:18] <poolie> to help us get some data on what to do next
[09:18] <wgrant> That initialism makes me sad.
[09:18] <poolie> ?
[09:19] <lifeless> abbrev. perhaps ?
[09:19] <wgrant> UDD means Ultimate Debian Database.
[09:19] <lifeless> anacronynm
[09:20] <StevenK> wgrant: Just as well they didn't call it Debian Ultimate Database
[09:24] <mrevell> poolie, I'd be happy to. Were you thinking something Surveymonkeyish?
[09:25] <lifeless> hey
[09:25] <lifeless> is store = getUtility(IStoreSelector).get(MAIN_STORE, DEFAULT_FLAVOR)
[09:25] <lifeless> what Class.select(...) does in the sqlobject compat layer ?
[09:25] <poolie> yes
[09:25] <lifeless> what is the recommended store lookup means
[09:26] <lifeless> the one that uses slaves for gets
[09:26] <wgrant> lifeless: IStore(SomeClass)
[09:26] <bigjools> IStore(blah)
[09:26] <lifeless> thanks guys
[09:26] <wgrant> You can also say IMasterStore(SomeClass) if you really want a master object.
[09:26] <bigjools> you can force IMasterStore(class) or ISlaveStore(class)
[09:26] <lifeless> why would someone use StoreSelector ?
[09:26] <bigjools> old skool
[09:26] <wgrant> lifeless: Because IStore wasn't invented yet.
[09:26] <poolie> are fixtures already an lp dependency, or likely to be soon?
[09:27] <mrevell> poolie, I can either give you access to the LP team's paid Surveymonkey account or if you give me an idea of what you want to know, I'll be happy to set something up for you and then get your approval before I publish it.
[09:27] <poolie> the second sounds like less work (for me :)
[09:28] <mrevell> :) No problem. Do you want to email me with what you'd like to know?
[09:29] <StevenK> bigjools, wgrant: I'm using IStoreSelector).get(MAIN_STORE, MASTER_FLAVOR) in InitialiseDistroSeries, should I fix that?
[09:29] <poolie> mrevell: so handwaving, because i have to stop soon
[09:29] <wgrant> StevenK: Yes.
[09:29] <wgrant> StevenK: it's deprecated. Kill it if you see it anywhere.
[09:29] <poolie> we just want to know: did they use it, did they hit problems, if so where, is it any better than what they're doing now, what would make it so, are there any particular niches where it is good, bad, potentially but not actually good,
[09:30] <wgrant> StevenK: I was guilty of using it when I started. I'm not sure if IStore didn't exist yet, or whether it just wasn't known commonly enough.
[09:30]  * bigjools wonders if IStore() will work when we get more stores.
[09:30] <wgrant> bigjools: Why would we have more stores?
[09:30] <wgrant> Unless we're completely rearchitecting everything.
[09:30] <bigjools> scalability
[09:30] <StevenK> wgrant: So, IStore(self) ?
[09:31] <wgrant> StevenK: I think so.
[09:31] <bigjools> is just one reason
[09:31] <wgrant> Or maybe just Store.of(self). Not quite sure.
[09:31] <mrevell> poolie, Thanks for that. I'll work something up this (my) morning and email you with a link to the draft survey.
[09:31] <wgrant> StevenK: But you could just IMasterStore(class you're looking for)
[09:31] <bigjools> StevenK: IStore() needs a class, not an object
[09:31] <poolie> wow
[09:31] <poolie> lazyness pays off :)
[09:31] <wgrant> bigjools: But we can't do multi-master...
[09:31] <poolie> thanks
[09:31] <bigjools> wgrant: we *could* given the motivation
[09:32] <wgrant> bigjools: Could we?
[09:32] <wgrant> I mean, is it actually possible?
[09:32] <wgrant> I don't think we can do multi-master without splitting the DB.
[09:32] <bigjools> correct :)
[09:32] <wgrant> At which point we are changing everything.
[09:33] <mrevell> np @_)
[09:33] <mrevell> er, didn't mean to do the psychadelic smiley there...
[09:33] <bigjools> wgrant: if we add more publishers we're going to need to scale writes
[09:33] <bigjools> anyway, otp
[09:34] <wgrant> The publisher does just about no writes!
[09:34] <wgrant> Just a crapload of reads.
[09:35] <wgrant> Unless you're publishing a fresh new copy of the archive or series.
[09:35] <wgrant> I guess.
[09:35] <wgrant> But that's rare.
[09:35] <bigjools> think about deathrow etc
[09:36] <wgrant> deathrow doesn't do too much writing either. But it does a lot more stuff that it doesn't need to do.
[09:36] <wgrant> I get the feeling that nobody has really touched it since it was first written.
[09:36] <wgrant> Because some of what it does is just wrong.
[09:40] <wgrant> Like trying to remove every binary publication until the last publication of that binary is gone.
[09:40] <wgrant> Similar with sources.
[09:40] <wgrant> And not removing overridden files.
[09:40] <lifeless> wgrant: BugTaskSet.search is freaking nasty to convert
[09:41] <wgrant> And just generally being pathetically inefficient in various other ways.
[09:41] <lifeless> I don't suppose you know of a parser for sql order by constraints
[09:41] <wgrant> lifeless: Howso?
[09:41] <wgrant> No, why, and will it make me sick?
[09:41] <lifeless> *yes, it takes SQL as an input*
[09:41] <wgrant> Oh, right, that one.
[09:41] <wgrant> Yay.
[09:41] <wgrant> You can't pass that into Storm directly?
[09:41] <lifeless> sure
[09:42] <lifeless> once you find every users of BugTaskSearchParams that sets orderby
[09:42] <wgrant> :(
[09:42] <lifeless> exactly
[09:43] <lifeless> hmm
[09:43] <lifeless> perhaps outputting a warning and using the storm helper...
[09:45] <StevenK> lifeless: I've forgotten your Storm notes. :-( Select -> compile, and then what?
[09:45] <noodles775> Hi mrevell... I'm just finishing the diff UI changes at https://dev.launchpad.net/LEP/DerivativeDistributions and bigjools has already updated the 'Creating a new derived distroseries' mockup, so I think you could start organising the next round when you've time.
[09:46] <lifeless> StevenK: compiler(expr, State())
[09:46] <lifeless> bah
[09:46] <lifeless> compile()
[09:46] <lifeless> mumble
[09:46] <lifeless> look at store.execute for inspiration
[09:46] <wgrant> Do you actually need to manually compile it?
[09:47] <lifeless> eventually no
[09:47] <StevenK> lifeless: Yes, I've done the compile(), it's what I do after that
[09:47] <lifeless> first cut yes
[09:47] <lifeless> StevenK: you should have a string now. execute it
[09:47] <lifeless> wgrant: needs an InsertInto Expr with compile-hook to DTRT
[09:47] <lifeless> StevenK: if your string doesn't have INSERT INTO ... SELECT FROM
[09:48] <lifeless> StevenK: then do a single simple string insertion at this point
[09:48] <lifeless> wgrant: the built in on in storm wants VALUES, not SELECT
[09:48] <lifeless> s/on/one/
[09:48] <wgrant> Ah.
[09:49] <mrevell> wonderful, thanks noodles775
[09:52] <lifeless> wgrant: not hard to whip one up. ETIME, Diminishing returns.
[09:53] <lifeless> hmm
[09:56] <poolie> it seems to want epytext
[10:04] <bigjools> wgrant: lamont enjoyed* rolling back the buildd package yesterday
[10:04] <lifeless> whats the storm equivalent for SQLConstant?
[10:05] <bigjools> have a look in storm.locals
[10:05] <lifeless> or rather, maybe I should say
[10:05] <lifeless> its SQL
[10:05] <lifeless> what I actually mean though
[10:05] <lifeless> is
[10:05] <lifeless> is 'sqlobject.sqlbuilder' coming from storm, or sqlobject
[10:05] <lifeless> like, do we still have sqlobject around?
[10:06] <lifeless> if this works
[10:06] <lifeless> I'm going to be a) happy , b) very very very very scared
[10:07] <bigjools> oh awesome, I can't search for numbers in bugs, it thinks it's a bug number
[10:08] <lifeless> theres a bug on that :P
[10:08] <lifeless> try +filebug
[10:08] <bigjools> heh
[10:08] <wgrant> bigjools: yeah, so I heard :/
[10:08] <bigjools> I used to use the dupe finder for searching all the time
[10:08] <wgrant> It wasn't QA'd on DF first?
[10:09] <bigjools> wgrant: we don't have any amd64 builders on DF
[10:09] <wgrant> Ah. Yay.
[10:09] <lifeless> bigjools: why did you stop ?
[10:09] <bigjools> lifeless: it stops after so many bugs
[10:10] <bigjools> although I'd really, really like some of the "advanced" options on the first search page
[10:10] <bigjools> and I'd like the default page to present on newness like it always used to
[10:10] <wgrant> bigjools: I missed it because I did some tiny cleanup after an amd64 test, and then my amd64 machine became unavailable so I only tested the final trivial changes with i386/lpia. :/
[10:10] <lifeless> bigjools: you might like to try again, with the relevance changes etc, *might* get what you want higher up
[10:10] <lifeless> bigjools: I'd like that too
[10:10] <wgrant> And managed to get the arguments around the wrong way in the process, which only breaks amd64-on-amd64 builds :(
[10:11] <lifeless> bigjools: I have the feeling that some of the 'remove X its slow' we've done are treating symptoms not causes and can be put back in.
[10:11] <bigjools> wgrant: shit happens :(
[10:11] <bigjools> lifeless: yeah
[10:11] <wgrant> Anyway, the builds are all retried and we'll QA the fix it on dogfood today.
[10:12]  * bigjools can't wait for a fast LP
[10:12] <lifeless> hey its coming
[10:13] <wgrant> It's coming more rapidly than I expected.
[10:13] <bigjools> wgrant: so that 404 bug you moved to Soyuz, it's a dupe but I can't find the bug it's duping
[10:13] <bigjools> lifeless: \o/
[10:13] <wgrant> bigjools: That's what I said.
[10:13] <lifeless> wgrant: what di dyou expect?
[10:13] <wgrant> bigjools: I know there's a bug about it.
[10:13] <wgrant> At least one.
[10:13] <wgrant> But I cannot find it.
[10:14] <bigjools> lifeless: I expected nothing less from you :)
[10:14] <wgrant> lifeless: Um, not immediate timeout decreases and massive speedups that you're achieving.
[10:14] <wgrant> I was expecting more inertia.
[10:14] <lifeless> wgrant: I've removed a couple of small roadblocks I think
[10:15] <lifeless> wgrant: but I know *everyone* wanted it faster
[10:15] <lifeless> so I really can't take much credit
[10:15] <lifeless> hell, its taking me days to land each of my patches
[10:15] <lifeless> learning curves etc
[10:16] <lifeless> wgrant: bigjools: Thanks though, its nice to be blamed for good stuff :)
[10:16] <bigjools> lifeless: it's more about bringing the impetus and the culture change.
[10:16] <wgrant> lifeless: You may not be entirely to blame, but things certainly seem to have been happening a lot more since you arrived.
[10:16] <wgrant> Right, what bigjools said.
[10:16] <bigjools> I've wanted a culture change for ages, but a lot of devs seem happy to throw stuff out there without thinking about performance
[10:17] <wgrant> Gah.
[10:17]  * bigjools used to work on stuff that *had* to perform well
[10:17] <wgrant> To make matters worse, bug #404 is private.
[10:17] <bigjools> lol
[10:17] <wgrant> (yes, yes, I just ran into that trap myself without thinking)
[10:17] <bigjools> I can't believe I just search for "missing link"
[10:18] <lifeless> :)
[10:19] <bigjools> I found a long-lost ancestor :)
[10:19] <wgrant> I still can't find the bug.
[10:19] <bigjools> me neither!¬
[10:19] <wgrant> I looked a couple of hours ago when the guy appeared in #launchpad.
[10:19] <bigjools> I know it's there
[10:19] <wgrant> I thought it had 404 in the summary.
[10:19] <wgrant> But maybe not.
[10:20] <lifeless> is there an existing 'take the first element of this tuple' adapter around ?
[10:21] <lifeless> itemgetter.duh
[10:21] <wgrant> I was about to say.
[10:21] <bigjools> thing[0] ? :)
[10:22] <lifeless> closures
[10:28] <wgrant> bigjools: So, I thought I'd found it. But then I realised it was the one filed a few hours ago.
[10:28] <wgrant> I am mystified as to the location of the old one.
[10:28] <bigjools> if you find it, let's change its title so we can find it again (and the dupe finder can find it more to the point)
[10:34] <lifeless> one dupefinder issue
[10:34] <lifeless> - it does not search comments
[10:36] <wgrant> bigjools: There's bug #522800. I thought there was another, but I may be wrong.
[10:36]  * wgrant kicks the bot.
[10:36] <lifeless> \i/
[10:36] <bigjools> _mup_: bug #522800
[10:36] <wgrant> However, your analysis isn't quite correct.
[10:37] <wgrant> The old file is expired, which is arguably right.
[10:37] <wgrant> The problem is that getFileByName returns the oldest matching LFA, when it should probably returned the oldest unexpired.
[10:37] <bigjools> yeah I suspected I might be wrong
[10:37] <wgrant> Each upload has its own LFA.
[10:38] <wgrant> With the same LFC.
[10:38] <wgrant> I think.
[10:40] <lifeless> ok, time to see the damange with this storm sqlobject frankenquery
[10:40] <lifeless> see you all tomorrow
[10:40] <bigjools> nn
[10:41] <wgrant> Night.
[10:51] <wgrant> bigjools: Thanks, you added the term we couldn't search for :P
[10:51] <bigjools> wgrant: the dupe finder gets it nicely ;)
[10:51] <wgrant> True.
[10:51] <bigjools> "broken" is the word I missed when looking before
[11:51] <jml> it takes far too long to get an EC2 image ready to run LP tests.
[11:57] <noodles775> james_w: Hi! I've just been updating some of the derived distro mockups, but had to make some assumptions while doing so, and I'd like you to check that they're valid.
[11:57] <noodles775> In particular, with: https://dev.launchpad.net/LEP/DerivativeDistributions#Derived%20series%20differences
[11:59] <noodles775> For various reasons (details in the comments that follow the mockup), I've made the assumption that you'll only want to add a comment on a row when you mark it as ignored... is that an invalid assumption, or ok?
[12:00] <wgrant> Oh wow, this looks awesome.
[12:01] <noodles775> Thanks wgrant! (or are you talking about something else :) )
[12:01] <wgrant> I'm talking about this.
[12:01] <wgrant> Hopefully we'll eventually be able to make Ubuntu a derivative of Debian...
[12:02] <noodles775> Yeah, that'd be exciting :D
[12:02] <wgrant> Then I can kill off mdt.
[12:02] <deryck> Morning, all.
[12:29] <wgrant> thumper: Hm, I thought Translations did some layer-specific views.
[14:17] <benji> gmb: a question came up in a review of one of my branches yesterday that I want to run by you; the MP is at https://code.edge.launchpad.net/~benji/launchpad/bug-580035/+merge/32917
[14:17] <benji> gmb: the question is: the branch adds a section to a doctest, is that acceptable to you guys?
[14:20] <gmb> benji, I think so. deryck can give you an authoritative answer though.
[14:20] <deryck> is it a doc or a test? :-)
[14:21]  * deryck looks at MP
[14:21] <benji> it's more testy than docy
[14:24] <deryck> benji, yeah, I'm sorry to be a pain, but I would prefer this be a unit test.  Especially given two things -- we're trying to get doc tests that are tests converted to unit tests and we're especially doing this around email and subscriptions currently.
[14:24] <deryck> my rule of thumb, if it's primarily a test, it should be a unit test.  A doc with testable parts is, of course, okay.
[14:24] <benji> I'll convert it then.
[14:25] <deryck> benji, thanks!
[14:32] <jml> hmm hmm hmm.
[14:40] <james_w> noodles775: hi, have you looked at merge-o-matic?
[14:42] <noodles775> james_w: Is that what normally displays at https://merges.ubuntu.com/main.html ? If so, yep. Otherwise no.
[14:43] <noodles775> what in particular have we missed?
[14:51] <james_w> noodles775: yeah, that's the site. I just wondered if you had looked at the sort of comments people left there
[14:52] <james_w> my belief is that they leave them for things such as "I'm working on this", or "This depends on foo", in which cases you wouldn't hide the row
[14:52] <james_w> noodles775: the mockups are looking great though, thansk
[14:53] <noodles775> james_w: no, I hadn't looked at the comments. Right... I'll update then, thanks.
[15:02]  * jml lunches
[16:38] <Ursinha> bigjools, I'm confused, is bug 618231 really won't fix?
[16:38] <bigjools> Ursinha: yes
[16:39] <bigjools> check the diff for the patch that was landed :)
[16:39] <Ursinha> bigjools, I wonder why that branch mentioned the bug :)
[16:40]  * bigjools shrugs
[16:46] <jml> \o/
[16:46] <jml> just locally reproduced a failure I previously had to spin an ec2 instance to get
[17:48] <henninge> bac: Is the case ignored when imports are sorted?
[17:48] <henninge> Aaa, Bbb, aaa
[17:48] <henninge> or
[17:48] <henninge> Aaa, aaa, Bbb
[17:49]  * henninge looks in ... somewhere
[17:51] <henninge> hm, one example in PythonStyleGuide suggests aaa, Aaa, Bbb
[17:55] <jml> henninge, I think that example is true to form
[17:55] <jml> henninge, c.f. https://dev.launchpad.net/EmacsTips
[17:56] <henninge> jml: it's a shame though that "sorted" sorts the other way round ...
[17:56] <jml> henninge, sorted(imports, key=lambda x: x.lower())
[17:57] <henninge> hm, that will simply ignore case
[17:57] <jml> henninge, anyway, if you are changing *everything*, then I think you get to make up the new rule :)
[17:57] <henninge> oh, cool! ;-)
[17:58] <henninge> since that seems to be the natural sorting order in Python ...
[17:59] <jml> I'm ok with the change. But do let people know, so dev scripts can be updated.
[18:26] <jml> Python sucks.
[18:26] <jelmer> jml: What's it done wrong this time?
[18:27] <lifeless> existing?
[18:27] <cody-somerville> lol
[18:27] <jml> jelmer, why is "lambda: foo.append(None)" acceptable but "lambda: count += 1" not?
[18:27] <lifeless> expr, statement
[18:28] <lifeless> hysterical raisins
[18:28] <jml> lifeless, yeah, I know the expr / statement thing.
[18:29] <jml> of course, lambda: foo.__iadd__(1) is ok
[18:29] <jml> get your act together, Python
[18:29]  * jelmer tries hard not to mention the H word
[18:30] <jml> jelmer, I know the word you're thinking of, of course
[18:31] <jml> jelmer, but I'd reach for Lisp before that if I were looking for a language that gets this right.
[18:31] <jml> ffs, even Javascript gets it right.
[18:34]  * jelmer wonders if vala does closures
[18:35] <lifeless> jkakar: hi
[18:42] <jml> lifeless, if I were to write something that made graphs based on subunit stream, to which project should I submit it?
[18:42] <lifeless> subunit or tribunal come to mind immediately
[18:49] <jml> OK. I'm ec2 landing my branch which completely changes ec2test/remote.py and as such is likely to break other people's "ec2 test" experiences
[18:50] <lifeless> cool
[18:50] <lifeless> did you find a reviewer ?
[18:50] <jml> I'll try to send out an email when it hits devel, but in case I don't and weird things start happening, at least there'll be an IRC record.
[18:50] <jml> lifeless, yeah, jelmer reviewed it.
[18:51] <lifeless> \o/
[18:51] <jml> once it lands & is on stable, I'll then move on to the bit where I deliberately change the behaviour.
[18:52] <lifeless> thank you for staging it
[18:53] <jml> np.
[18:54] <jml> any other way and it will only end in tears.
[19:01] <jkakar> lifeless: Hiya
[19:02] <lifeless> jkakar: would like your input on https://bugs.edge.launchpad.net/launchpad-foundations/+bug/618019
[19:02] <lifeless> jkakar: I think perhaps gustavo hasn't understood our concerns
[19:04]  * jkakar looks
[19:08] <jkakar> lifeless: I see.
[19:09] <jkakar> lifeless: I would like to see time-to-fetch measured, probably as a separate measurement to time-to-execute-statement.
[19:09] <jkakar> lifeless: I sometimes wonder if I'd also like to see time-to-instantiate-objects, since I *believe* the cost there is non-trivial.
[19:11] <jml> jkakar, ime, .values() is much faster
[19:12] <jkakar> jml: Yep, exactly.
[19:12] <jkakar> At that point Storm is just generating a query and then handing you almost the exact result received from the Python DB driver.
[19:28] <lifeless> jkakar: so, do you know why gustavo is pushing back here?
[19:29] <lifeless> jkakar: it astounds me
[19:29] <lifeless> deryck: hey
[19:29] <bac> henninge: sorry, i didn't see your question.  yes, existing coding standards say case-insensitive sorting (is that what you'd call it?) but we have lots that are not.
[19:30] <deryck> hi lifeless
[19:30] <jkakar> lifeless: I'm not sure I understand either.  Have you talked to him directly about it?
[19:31] <lifeless> deryck: are you aware of any reason why stormifying BugTaskSet.search would be a bad idea?
[19:31] <lifeless> deryck: other than it being hard because its big :)
[19:31] <lifeless> jkakar: not yet
[19:31] <deryck> lifeless, I'm not aware of any reasons against.  I suspect it wasn't done only because of the amount of work.
[19:32] <lifeless> so SQLObjectResultSet hates DecoratedResultSet
[19:32] <lifeless> guess what thats lead me down the path to do...
[19:33] <deryck> ah, ok.  Sure, I see no problem with doing this.
[19:35]  * jkakar needs to learn about DecoratedResultSet since it seems to get mentioned a lot.
[19:36] <jkakar> I don't know what it is but I wonder if whatever it does shouldn't be in Storm proper.
[19:41] <lifeless> jkakar: have a look
[19:41] <lifeless> ./lib/canonical/launchpad/components/decoratedresultset.py
[19:43] <lifeless> jkakar: it lets you do
[19:43] <lifeless> DRS(store.find((Foo, Bar, Baz)), adapt)
[19:43] <lifeless> where adapt is
[19:43] <lifeless> def adapt(row):
[19:44] <lifeless>     person = row[0]
[19:44] <lifeless>    person.friends = row[1]
[19:44] <lifeless>   person.has_geolocation = len(row[2] > 0)
[19:44] <lifeless>   return person
[19:44] <lifeless> so it becomes a result set yielding persons with stuff setup about them
[19:45] <jkakar> lifeless: Oh, very nice.
[19:45] <lifeless> Ursinha: hi
[19:46] <Ursinha> lifeless, you just read my mind
[19:46] <lifeless> :)
[19:46] <lifeless> <- talented
[19:46] <Ursinha> hahaha
[19:46] <Ursinha> lifeless, what do you intend with the bad-commit-xxx tag?
[19:46] <Ursinha> is that a replacement or a complement for qa-bad?
[19:46] <lifeless> complement
[19:46] <Ursinha> (or needstesting, because a rollback can also be a rollback for a untested revision)
[19:47] <lifeless> we have to remember that the *commit* is bad even when the bug becomes qa-ok
[19:47] <lifeless> we can't *ever* rollout that commit without its rollback=xxx commit
[19:49]  * lifeless wants a whiteboard
[19:54] <Ursinha> lifeless, that's ok, understood
[20:20] <lifeless> Ursinha: so
[20:20] <lifeless> Ursinha: where does this leave us
[20:20] <Ursinha> lifeless, branch is merged
[20:20] <lifeless> like
[20:21] <lifeless> if we said 'we're switching to this workflow now', what would be missing
[20:21] <lifeless> *) A QA environment for it
[20:21] <lifeless> anything else?
[20:21] <lifeless> mthaddon: still around ?
[20:21] <Ursinha> lifeless, now, production_stable is a branch that has merges from db-stable
[20:21] <Ursinha> I'm thinking aloud
[20:22] <lifeless> Ursinha: that fine :)
[20:22] <Ursinha> we'd need a QA environment, right
[20:22] <lifeless> I'm wondering if we could change staging to use stable
[20:22] <lifeless> and change it back for release week
[20:23] <Ursinha> that would be our "stable"
[20:23] <Ursinha> hmm
[20:23] <Ursinha> lifeless, problem is staging is where people test db changes now (I guess)
[20:23] <Ursinha> because it's db-stable, basically
[20:24] <Ursinha> so we'd need another QA environment for that
[20:24] <Ursinha> wait
[20:26] <Ursinha> lifeless, where do you intend to have db changes landing to be tested?
[20:26] <lifeless> staging
[20:27] <lifeless> :)
[20:27] <Ursinha> lifeless, so I don't get it :)
[20:27] <lifeless> ok
[20:28] <lifeless> have you seen my most recent mail to the list - just this morning
[20:28] <Ursinha> ah, no
[20:28] <lifeless> flacoste: this may interest you as well
[20:28]  * Ursinha looks
[20:32] <lifeless> Ursinha: I'm proposing a temporary thing by reusing staging
[20:32] <lifeless> Ursinha: long term we definitely want two environments
[20:32] <lifeless> flacoste: ^ thinking this might reduce the work needed by losas before we can *start* RFWTAD
[20:49] <Ursinha> lifeless, so, stable would be deployed to staging
[20:49] <Ursinha> with db and no-db changes
[20:50] <Ursinha> and if qa-go-ahead, revision is also deployed on prod
[20:50] <Ursinha> right?
[20:50] <lifeless> I don't parse your second line, so I'll rephrase it
[20:51] <lifeless> 'with a copy of the prod db and only schema changes contained in stable itself'
[20:51] <lifeless> and yes
[20:52] <Ursinha> "only schema changes contained in stable itself"
[20:52] <lifeless> yes
[20:52] <lifeless> like
[20:52] <Ursinha> where else the schema changes would be?
[20:52] <lifeless> someone might land a db patch that would have no downtime
[20:52] <Ursinha> hm
[20:52] <lifeless> like a brand new table
[20:53] <lifeless> as per RFWTAD
[20:53] <lifeless> flacoste: now I have your attention
[20:53] <lifeless> flacoste: quick call ?
[20:53] <flacoste> lifeless: sure
[20:56] <benji> deryck: do you mind looking at my doctest to unittest translation (http://bazaar.launchpad.net/~benji/launchpad/bug-580035/revision/11319) and -- if you like it ;) -- commenting at https://code.edge.launchpad.net/~benji/launchpad/bug-580035/+merge/32917
[20:58] <deryck> benji, looking now....
[20:58] <benji> thanks
[21:01] <deryck> benji, looks great.  Thanks for doing this work!  I'll update the MP now.
[21:01] <benji> thanks much
[21:02] <deryck> And with that, I'll EOD. :-)
[21:03] <deryck> Later on everyone.
[21:19] <lifeless> Ursinha: just chatted with francis
[21:20] <lifeless> Ursinha: my idea was not taking enough consideration of the the time spent doing non-db dev on db-devel
[21:20] <lifeless> Ursinha: so we'll still be blocked on the existing RT ticket
[21:21] <lifeless> Ursinha: but thats ok, I'm increasing my concern for db agility as a result :)
[21:21] <lifeless> flacoste: thanks :)
[21:24] <Ursinha> lifeless, ok, I was wondering that too... but that's ok now
[21:25] <Ursinha> I'll keep soketesting what we have
[21:25] <Ursinha> and grab a coffee now :)
[21:26] <thumper> sinzui: can you rename lp.registry.enum to lp.registry.enums ?
[21:27] <sinzui> I can
[21:27] <thumper> sinzui: it matches our directory naming, and will be consistent with lp.code :)
[21:27] <thumper> sinzui: thanks
[21:27] <sinzui> you mean right now, stop writing this boring report and do something to feel good?
[21:27] <thumper> sinzui: great induction sprint write up
[21:27] <thumper> sinzui: I'll be grabbing ideas from it
[21:28] <thumper> sinzui: I'm not going to say that you should do it this instant, but ASAP would be good
[21:28] <sinzui> thumper, We need to update the wiki with a sane example bazaar.conf and locations.conf. jcsackett had trouble working that out
[21:28] <thumper> sinzui: where do you think it should go?
[21:28] <thumper> sinzui: I could look to edit it
[21:28] <thumper> sinzui: somewhere off the dev wiki I guess
[21:29] <sinzui> I think so
[21:29] <sinzui> There used to be stuff like that in  the old wiki
[23:11] <lifeless> thumper: ping
[23:11] <lifeless> sourcepackagename.path - I'm getting an error with that having 'distribution' set to None
[23:11] <lifeless> in its repr()
[23:11] <wgrant> sourcepackagename.path?
[23:11] <wgrant> That doesn't exist.
[23:12] <lifeless> sorry, sourcepackage.path
[23:12] <lifeless> I get confused easy
[23:12] <wgrant> That really shouldn't exist either, but it does.
[23:12] <wgrant> A SourcePackage is a SourcePackageName in a DistroSeries.
[23:13] <wgrant> So it's not valid to have one without a Distribution.
[23:13] <lifeless> right
[23:13] <lifeless> and an invalid one is being repr() in a traceback
[23:13] <wgrant> Hmm.
[23:13] <lifeless> making the traceback blowup
[23:13] <wgrant> I wonder how that was obtained.
[23:13] <lifeless> and thus being hard to debug
[23:13] <lifeless> BugTaskSet.search misbehaving
[23:13] <lifeless> that much I know, because, well, I'm overhauling the damn thing
[23:15] <lifeless> distribution is itself a property
[23:15] <lifeless> via distroseries
[23:18] <wgrant> Hm.
[23:18] <wgrant> So people can no longer subscribe to Ubuntu's bugs. Great.
[23:18] <lifeless> to the whole feed ?
[23:18] <wgrant> Yes.
[23:18] <lifeless> feel free to weigh in on the MP / bug - I did
[23:18] <thumper> lifeless: pong
[23:19] <lifeless> they can subscribe to the list that gets all the mail
[23:19] <lifeless> thumper: nvm, sorry - was teh sourcepackage thing above
[23:19] <lifeless> but I'm just going to change the repr
[23:19] <wgrant> lifeless: Yes, but surely making the UI suck less is a better general solution than just disallowing it for distributions.
[23:19] <thumper> lifeless: I would like a chat with you sometime about the project cloud
[23:19] <lifeless> thumper: sure.
[23:20] <lifeless> thumper: anytime - now if you like
[23:20] <thumper> lifeless: ok now, skype?
[23:20] <lifeless> wgrant: this isn't a dichotomy
[23:22] <wgrant> If people are doing things that only negatively affect them, permission changes are not the solution!
[23:22] <wgrant> We need to work out why they are being stupid and remove the cause of the stupidity.
[23:22] <wgrant> Not block the stupidity outright.