[00:12] <thumper> can you use with_ on a storm select?
[00:13] <lifeless> yes
[00:13] <thumper> yup
[00:14] <thumper> hmm... I'm wondering how though
[00:15] <lifeless> well, maybe you mean something different than I do
[00:15] <lifeless> I suggest starting with my use of it
[00:15] <thumper> lifeless: I have it working on the general store.find
[00:15] <thumper> but now I need a subselect for blueprint exclusion
[00:15] <thumper> I've got the underlying sql tested on staging
[00:16] <thumper> so I know that the syntax I want is allowed
[00:16] <thumper> just trying to get it into storm
[00:25] <lifeless> wgrant: you mean stevenk's patch ?
[00:25] <wgrant> lifeless: Yes.
[00:26] <lifeless> thumper: I'm not sure what you're talking about here
[00:26] <thumper> lifeless: that's ok
[00:26] <lifeless> thumper: but I wrote something to gary that /might/ be relevant so I'm going to forward it to you
[00:26] <thumper> ok
[00:27] <lifeless> thumper: if it doesn't seem relevant, perhaps you can pastebin me some details about what you're trying to glue together
[00:28] <thumper> lifeless: I'm chatting with jamesh on #storm
[00:38] <lifeless> now we're getting somehwere https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1899E29#repeatedstatements
[00:46] <thumper> lifeless: if I have problems, I'll poke you
[00:46] <lifeless> thumper: I hope the reformulation of the subselect is useful to you
[00:46] <thumper> lifeless: it is actually
[00:47] <lifeless> thumper: it will run faster because it doesn't need to look at specification
[00:47] <thumper> lifeless: yep, got that
[00:47] <lifeless> cool
[00:48] <lifeless> wgrant: were you going to tackle NBT this week ? wondering if I should ignore oopses on it
[00:56] <lifeless> hmm
[00:56] <lifeless> need to test [r=lifeless][bug=732481] [bug=732496] oops_middleware should call start_response for success, even if there is no body.
[00:57] <StevenK> Isn't that a fix for the haproxy call?
[00:57] <lifeless> n
[00:57] <lifeless> no
[00:57] <lifeless> its a fix for head
[00:58] <StevenK> ... which haproxy calls? :-)
[00:58] <lifeless> not at the moment
[01:07] <StevenK> wgrant: Er, yes it is.
[01:08] <wgrant> StevenK: Aren't the DSD scripts not running yet?
[01:08] <StevenK> wgrant: DSD.new() calls update(), which calls _updateVersionsAndStatus(), which calls _updateBaseVersion()?
[01:09] <StevenK> Ah, well, that is likely true
[01:09] <wgrant> lifeless: I will probably get around to deleting it this week.
[01:09] <StevenK> I was going to QA that on mawson, after I find a good victum
[01:14] <thumper> anyone know of a place in the code where we do "like" queries with storm?
[01:21] <wallyworld_> thumper: registry.model.distribution.Distribution.searchSourcePackageCaches
[01:26] <thumper> OMG, this vocab was so... broken
[01:26] <wallyworld_> which vocab?
[01:26] <lifeless> note that we should not do like queries
[01:26] <lifeless> they are slow
[01:26] <lifeless> fti or exact matches only
[01:28] <thumper> lifeless: how do I find what text is indexed for blueprints?
[01:28] <lifeless> look in database/schema/fti.py
[01:28] <lifeless> name, title, summary, whiteboard
[01:30] <thumper> lifeless: how do we do a fti query in storm?
[01:30] <lifeless> SQL(...) or use the fti helpers
[01:31] <thumper> lifeless: also, is the fti case insensitive?
[01:31] <lifeless> I think it is
[01:32] <thumper> in which case the like queries that were used, were useless
[01:32] <thumper> as they were covered by the fti anyway
[01:32] <lifeless> not surprising
[01:34] <mwhudson> yay lp.blueprints!
[01:34] <thumper> lifeless: in order to say "id not in (...)" we use Not(Table.Column.is_in(...)) ?
[01:36]  * thumper tries to remember left joins in storm
[01:37] <mwhudson> thumper: if you're looking at SpecificationDepCandidatesVocabulary, those LIKEs look completely pointless
[01:37] <thumper> mwhudson: yes, I've figured that out
[01:37] <mwhudson> for at least two reasons :)
[01:37] <mwhudson> wow
[01:38] <mwhudson> thought they might be so pointless that the query planner can turn them into =
[01:39] <lifeless> thumper: I've not needed to say 'id not in' using storm syntax
[01:39] <lifeless> thumper: and tbh, storm syntax vs literal sql is rarely an improvement IMO
[01:40] <lifeless> thumper: other than the object deserialisation, I don't find writing the expressions using storm to be generally beneficial
[01:40] <lifeless> thumper: I guess I mean: write it in the simplest way possible
[01:41]  * thumper doesn't need the left joins
[01:41] <thumper> d'uh
[01:42] <thumper> WTF do we have an __iter__ on our IHugeVocabulary?
[01:42] <thumper> that's just stupid
[01:42] <thumper> I know that we "technically" need it
[01:42] <lifeless> we have __iter__ on Distribution
[01:43] <lifeless> and thats equally bogus
[01:43] <thumper> but having to provide an implementation is fucked up
[01:43] <thumper> lifeless: I agree that __iter__ on any model class is bogus
[01:43] <mwhudson> it helps accidentally OOM the appservers?
[01:43] <lifeless> thumper: we shouldn't have __iter__ on things that we don't expect actual complete iteration of
[01:43] <lifeless> thumper: but removing it may be problematic
[01:44] <lifeless> thumper: __iter__ on model classes is fine, *if* the model is a container
[01:44]  * mwhudson remembers a bug to do with materializing a list containing all Persons
[01:44] <thumper> lifeless: the reason we need it there is because IVocabulary defines an __iter__
[01:44] <lifeless> Distribution isn't obviously a container of any one specific thing
[01:44] <thumper> I'm pretty sure we don't use it though
[01:44] <lifeless> thumper: yes, I know - IVocabulary is buggy
[01:44]  * thumper will raise not implemented
[01:44] <wgrant> I thought HugeVocabulary existed mostly to avoid having __iter__ :./
[01:44] <lifeless> wgrant: yes, but we didn't fix zopes assumptions
[02:32] <lifeless> anyone want to eyeball https://code.launchpad.net/~lifeless/launchpad/bug-711104/+merge/53188 before I land it ?
[02:33] <wallyworld_> what's the magic command to run yui tests?
[02:33]  * wallyworld_ goes to look on the wiki
[02:36] <wallyworld_> ah, it's manual - load it up in a browser
[02:53] <thumper> :(
[02:53]  * thumper skips fixing that design problem
[03:23] <thumper> part one: https://code.launchpad.net/~thumper/launchpad/blueprint-dependencies/+merge/53191
[03:23] <lifeless> thumper: Thanks
[03:23] <thumper> np
[03:23]  * lifeless gambles on lp-land
[03:24] <StevenK> lifeless: Re facebook, PICTURES!
[03:25] <lifeless> thumper: so my refactored clause was slightly wrong ?
[03:25] <lifeless> thumper: ( I don't see why you need specification s there at all
[03:25] <thumper> lifeless: it is needed in the next bit :)
[03:26] <thumper> lifeless: https://code.launchpad.net/~thumper/launchpad/blueprint-dependency-vocabulary/+merge/53192
[03:26]  * thumper afk for shopping and kids ice-skating
[03:26] <thumper> back later
[03:27] <lifeless> thumper: still don't see it
[03:27] <thumper> lifeless: leave a comment, I'll get back to you
[03:27]  * thumper needs to go now
[03:27] <lifeless> kk
[03:27] <huwshimi> lifeless: The last few days I've really noticed a speedup on Launchpad. Did you do something significant or am I only just noticing?
[03:28] <lifeless> huwshimi: we've brought some more appserver instances online, and moved to an active-passive haproxy config, and we landed a bunch more fixes late last week
[03:30] <wgrant> The latency on top of generation time and RTT is normally <100ms now, which is nice.
[03:31] <huwshimi> lifeless: It's awesome, I'm finding I'm waiting for pages now instead of clicking on links and going elsewhere while they load.
[03:31] <huwshimi> wgrant: That's great. That was like 2.5 seconds before right?
[03:31] <wgrant> I frequently saw it up to 2s, yeah.
[03:32] <lifeless> we still have queues
[03:32] <lifeless> but its a lot better
[03:32] <lifeless> it will be up to 2 weeks before we get the next stage of fixing this done
[03:32] <wgrant> lifeless: It's been 5 years.
[03:33] <wgrant> 2 weekse isn't that bad.
[03:33] <huwshimi> I feel like we might actually get there with our speed :)
[03:34] <StevenK> lifeless and wgrant beat you with feeling that.
[03:34] <lifeless> well
[03:34] <wgrant> Eeh, 6 months ago I knew it was hopeless.
[03:34] <wgrant> Now I'm not so sure.
[03:35] <poolie> here's a slightly interesting thing:
[03:35] <lifeless> wgrant: we're a great team, as long as we give ourselves the space to do things, we can move mountains
[03:35] <poolie> google search results contain the url https://code.launchpad.net/bugs/490148
[03:35] <_mup_> Bug #490148: License details for "Other" are displayed even if not selected <chr> <confusing-ui> <lp-registry> <qa-ok> <Launchpad itself:Fix Released by sinzui> < https://launchpad.net/bugs/490148 >
[03:35] <poolie> hi wgrant, huwshimi, lifeless
[03:35] <wgrant> poolie: That's a bit interesting.
[03:35] <StevenK> poolie: Hi! Are you back from holidays?
[03:36] <huwshimi> poolie: Hey mate
[03:36] <poolie> i am back
[03:36] <poolie> it was good
[03:36] <poolie> searching for {launchpad licence field} fwiw
[03:37] <lifeless> poolie: hi
[03:38] <StevenK> wgrant: Given DSD.base_source_pub() only searches the child for the SPPH, do you think there is value in having it also search the parent?
[03:38] <wgrant> StevenK: It should search both archives.
[03:38] <wgrant> It will normally only be in the parent.
[03:39] <wgrant> Rarely the child.
[03:39] <StevenK> Right, so I'll change it to search the parent first, and fall back to the child.
[03:39] <huwshimi> poolie: That's strange. It appears you can replace that subdomain with others and it still works (although I tried with blueprints.lp and it didn't load the subscribers list).
[03:39] <StevenK> As it is today, I thought it was a little naive.
[03:40] <poolie> huwshimi, i would guess that we send a "moved temporarily" from that url to the real location
[03:40] <huwshimi> poolie: I think they must be indexing on the wrong url. For code.lp it redirects to bugs.lp (blueprints.lp didn't)
[03:40] <poolie> and google therefore caches the orginila
[03:40] <huwshimi> poolie: Yeah that was my guess
[03:40] <poolie> strange
[03:40] <lifeless> huwshimi: most things are published in all domains
[03:40] <poolie> i wonder where they first found a link to that thing
[03:40] <lifeless> huwshimi: only a few things aren't (and that results in bug reports)
[03:40] <poolie> perhaps someone made up that url by hand and google decided it was more important
[03:41] <huwshimi> lifeless: Which makes me think our subdomains are even more redundant :)
[03:42] <lifeless> huwshimi: right
[03:42] <lifeless> huwshimi: as I said, for me at least, its mainly a technical exercise for removing if/when jml wants us to
[03:42] <lifeless> we'd certainly save on redundant ssl handshakes and js overhead
[03:45] <huwshimi> lifeless: Is this something we should start putting a LEP together for?
[03:46] <StevenK> wgrant: Can haz help crafting a query?
[03:46] <lifeless> huwshimi: only if we want to do it
[03:46] <wgrant> StevenK: I'm not here, but OK.
[03:47] <huwshimi> lifeless: So do we need to talk to jml about it then?
[03:47] <lifeless> huwshimi: I think there are three aspects to it
[03:47] <StevenK> wgrant: I'd like to find all SPPHs that are in both Ubuntu and Debian that have changelogs set, 'AND spph.status IN (1, 2)' and have the same SPN.
[03:47] <wgrant> 1) Kill them.
[03:47] <wgrant> 2) Kill them.
[03:47] <wgrant> 3) Kill them.
[03:47] <lifeless> there is a political aspect: in the past mark was very pro this layout
[03:47] <wgrant> Those are the three aspects.
[03:48] <wgrant> StevenK: So you can find good things to test with?
[03:48] <lifeless> there is a technical aspect: what exact actions are needed to /permit/ consolidation
[03:48] <lifeless> and there is a design aspect: how should things that are currently different in the same relpath on different domains look
[03:48] <StevenK> wgrant: Right.
[03:49] <lifeless> lastly, there is the scheduling thing: how important is this : when should we do it
[03:49] <lifeless> huwshimi: so, last I spoke to jml its not at the top of the roster - and I don't think its a one-man task (but I may be wrong)
[03:50] <lifeless> huwshimi: I don't think putting a lot of effort into things that aren't schedule-next priority is sensible
[03:50] <lifeless> if the schedulability of it is related to the size of the task, then investing long enough to figure out the size is worth doing
[03:51] <huwshimi> lifeless: Is this topic on a list of things that need to happen then?
[03:52] <lifeless> huwshimi: we practice a LEAN approach of not queuing things up if we can avoid it
[03:52] <wgrant> StevenK: SELECT spn.name FROM sourcepackagename spn JOIN sourcepackagerelease sprd ON sprd.name = spn.id JOIN sourcepackagepublishinghistory spphd ON spphd.sourcepackagerelease = sprd.id JOIN sourcepackagerelease spru ON spru.name = spn.id JOIN sourcepackagepublishinghistory spphu ON spphu.spr = spru.id WHERE spru.changelog IS NOT NULL AND sprd.changelog IS NOT NULL AND spphu.status IN (1, 2) AND spphd.status IN (1, 2);
[03:53] <wgrant> s/spphu.spr/spphu.sourcepackagerelease/
[03:53] <huwshimi> lifeless: OK, as long as we remember to talk about it :)
[03:53] <wgrant> And you want to actually constrain the archives too.
[03:53] <StevenK> wgrant: *and* I have to run it through sed? :-(
[03:53] <lifeless> huwshimi: so no - its not on any list : because we're trying not to have such lists :) - I'm aware of the discussion, and jml /may/ have a list somewhere with it on it
[03:53] <wgrant> AND spphu.archive = 1 AND spphd.archive = 3
[03:53] <lifeless> huwshimi: there may well be a bug saying 'this makes things slower'
[03:54] <lifeless> huwshimi: (and if there isn't such a bug, such a bug would be reasonable to have)
[03:55] <StevenK> ERROR:  operator does not exist: name = integer
[03:55] <StevenK> LINE 2: ...           sourcepackagerelease sprd ON sprd.name = spn.id J...
[03:55] <lifeless> grr testfix
[03:55] <StevenK> wgrant: ^
[03:55] <lifeless> StevenK: nameID
[03:55] <wgrant> StevenK: sourcepackagename, not name.
[03:55] <lifeless> or yeah
[03:56] <lifeless> I strongly encourage not using reference columns in queries.
[03:56] <lifeless> this will help us when we start to detangle the layers
[03:56] <wgrant> lifeless: This is SQL.
[03:56] <lifeless> oh
[03:56] <lifeless> :)
[03:57] <lifeless> Failure in test /srv/buildbot/slaves/launchpad/lucid-devel/build/lib/canonical/lazr/tests/../doc/pidfile.txt
[03:57] <lifeless> Traceback (most recent call last):
[03:57] <lifeless>   File "/usr/lib/python2.6/unittest.py", line 279, in run
[03:57] <lifeless>     testMethod()
[03:57] <lifeless>   File "/usr/lib/python2.6/doctest.py", line 2152, in runTest
[03:57] <lifeless>     raise self.failureException(self.format_failure(new.getvalue()))
[03:57] <lifeless> AssertionError: Failed doctest test for pidfile.txt
[03:57] <lifeless>   File "/srv/buildbot/slaves/launchpad/lucid-devel/build/lib/canonical/lazr/tests/../doc/pidfile.txt", line 0
[03:57] <StevenK> wgrant: Ah, right.
[03:58] <lifeless> anyone seen that before?
[03:58] <StevenK> It could have said "This column doesn't exist, you berk."
[03:58] <lifeless> StevenK: did you have 'name' or 'spr.name' ?
[03:58] <huwshimi> lifeless: I can't find a bug like that. I can report one, but you would be able to write a much better description of the problem if you want to and have the time.
[03:59] <lifeless> huwshimi: sure, I can do that
[03:59] <huwshimi> lifeless: Thanks mate
[03:59] <StevenK> lifeless: sprd.name, so it should be sprd.sourcepackagename, as wgrant pointed out.
[04:00] <lifeless> StevenK: was wondering about the context the sql parser had
[04:01] <StevenK> ... 14,000 rows. I don't believe you, SQL
[04:01] <lifeless> huwshimi: its covered in https://bugs.launchpad.net/launchpad/+bug/703134
[04:01] <_mup_> Bug #703134: Launchpads SSL performance is substandard <Launchpad itself:Triaged> < https://launchpad.net/bugs/703134 >
[04:03] <StevenK> I think we should edit the bug number to be 10 or something :-P
[04:04] <lifeless> bug 10 ?
[04:04] <_mup_> Bug #10: It says "displaying matching bugs 1 to 8 of 8", but there is 9 <lp-bugs> <Launchpad itself:Invalid> < https://launchpad.net/bugs/10 >
[04:04] <lifeless> hah. 'are'
[04:05] <lifeless> in the isf call on thursday we talked about the ssl cache sharing component - its a prerequisite for LVS, and LVS is up second on (IIRC) spads' queue
[04:06] <wgrant> How is that a prereq?
[04:07] <wgrant> Mm, I guess.
[04:07] <lifeless> wgrant: browsers don't switch ip per-request with round-robin setups
[04:07] <wgrant> Anyway, /me vanishes.
[04:07] <lifeless> so its [relatively] rare to do ssl renegotiates
[04:07] <lifeless> lvs would make it a common event unless we did source ip pinning (but you don't want to do that because of the impact of nat'd conferences)
[04:22] <lifeless> huwshimi: I like that you've been writing up a bunch of docs
[04:25] <huwshimi> lifeless: Starting to. It's mostly just stubs and a collection of links to other places... but I have to start somewhere.
[04:25] <huwshimi> lifeless: I'm trying to add things as I think about them
[04:28] <lifeless> huwshimi: one thing I'd like to suggest
[04:28] <lifeless> huwshimi: more things to remember makes development harder
[04:28] <lifeless> huwshimi: if possible, finding ways to make things automatic would be better than proscribing how things should be
[04:28] <lifeless> huwshimi: e.g. if all popup forms automatically set their first entry widget as focus, that would be a no brainer win
[04:31] <huwshimi> lifeless: Yes, that was exactly my thought
[04:31] <huwshimi> lifeless:  I do want to list the rules for the way things should behave though
[04:34] <lifeless> huwshimi: it may be nitpicking, but its probably worth rephrasing from 'rule' to 'sane default which solve problem X'
[04:35] <lifeless> huwshimi: this future proofs discussions: if problem X goes away, the default to solve it is clearly not relevant, whereas rules tend to age less gracefully IME
[04:36] <huwshimi> lifeless: Nitpick away :)
[04:37] <huwshimi> lifeless: So I want to have documentation with those guidelines about how to solve or how they are already solved within Launchpad
[04:37] <lifeless> huwshimi: I basically think we're rule heavy: we /still/ have way to many nonfunctional review rules, and I'm jumping the gun trying to avoid the same problem in a different guise
[04:41] <lifeless> sigh
[04:41] <huwshimi> lifeless: That makes sense, I wonder how we can make sure we have a consistent interface if we don't have a bunch of guidelines that should be followed though.
[04:41] <lifeless> 10/33 POFile:+translate
[04:42] <huwshimi> lifeless: Or am I misunderstanding something
[04:42] <lifeless> huwshimi: less code, more reuse
[04:42] <lifeless> huwshimi: additionally, i don't think following guidelines results in a high quality interface: I find it extremely weird that consistency is axiomatic with ease of use and high quality
[04:43] <lifeless> huwshimi: ease of use is directly measurable as is quality : clarity, performance, uptake of information are all measurable
[04:44] <lifeless> huwshimi: time to perform task, time to learn task etc
[04:47] <lifeless> huwshimi: as a for-instance on less-code,more-reuse: one of the genius things gnome's desktop stack did years ago was to ditch pixel positioning for widgets: instead it uses packing horizontally and vertically: the /default/ for a developer using the toolkit will be to be consistent with most other gnome apps
[04:49] <huwshimi> lifeless: What I'm trying to solve is that we don't really have enough docs on what we do or why we do them (for UI stuff). For example, I've been reviewing a form that rvba is working on. He would have know exactly how to create the form without a fair bit of back and forward over the last week if there was a doc he could have looked at that said "when creating a form don't use tables, use classes instead of inline
[04:49] <huwshimi> styles and here's where to look for appropriate styles".
[04:51] <lifeless> huwshimi: so I think this breaks into a few issues
[04:51] <lifeless> huwshimi: firstly, we're way to manual in our forms :( - long term issue
[04:51] <lifeless> huwshimi: secondly, there isn't really a 'right place' to cargo cult from.
[04:52] <lifeless> by which I mean its massively easier to take a good form from elsewhere and adjust than to start from scratch, but there isn't a 'known good' form that is fully ajaxified, uses all the right styles etc etc
[04:52] <lifeless> there *are such forms*, but nothing guiding folk to them
[04:52] <lifeless> I would have expected bigjools to guide rvba to the right place though
[04:53] <lifeless> huwshimi: using classes seems like standard html-since-2005 to me though, rather than something we need to formally write down :)
[04:54] <huwshimi> lifeless: Actually this is just a small filter form, of which we have a few, but this one had an extra option which none of the others do, so this was a special case that ended up being quite a bit more complex.
[04:55] <huwshimi> lifeless: except that we do have a lot of inline styles. So when he wanted to know what to do he looked at our existing code and noticed a lot of inline styles and assumed that was ok
[04:55] <lifeless> huwshimi: this correlates with what I am saying
[04:55] <lifeless> huwshimi: its *easier* to copy existing stuff than to follow procedures about what we *should* do
[04:56] <lifeless> huwshimi: so to get new contributions to be as we want them, its most effective to fix our existing stuff
[04:56] <lifeless> huwshimi: cheat sheets can still be useful, but I guarantee the first step isn't read-the-cheat-sheet
[04:57] <huwshimi> lifeless: I totally agree with all that, I just think it is helpful to also have some docs to refer to. Maybe though I need think about having them very general rather than specific cases
[04:58] <lifeless> huwshimi: lets say you retain 10% of stuff you read once
[04:58] <lifeless> huwshimi: think about how much stuff you read when you started
[04:58] <lifeless> huwshimi: and how much of the details you remember now :)
[04:58] <lifeless> huwshimi: I'm not saying 'do not write docs' : I started saying I'm glad you are writing docs up
[04:59] <lifeless> huwshimi: I am saying: rules that must be followed become a process burden, so we should demand *real value* from any rules we add.
[04:59] <lifeless> huwshimi: *and*
[05:00] <lifeless> huwshimi: making a few /really good/ forms and offering them up as 'copy this' examples (e.g. via the list, in your docs etc) would be a really good way to help your improvements propogate
[05:00] <huwshimi> lifeless: Alright that sounds good.
[05:01] <lifeless> huwshimi: I've done something similar with my query scaling tests: I took a single example that was in the code base from a while back, generalised and reused it, and wrote it up on the mailing list - other folk are writing such tests now
[05:01] <lifeless> huwshimi: and the infrastructure has incrementally improved to make writing them easier.
[05:02] <lifeless> huwshimi: I simultaneously tried some rule-based improvements, which have had approximately zero impact on the code base: the communication, examples, and continual focus on the one thing have however had a massive impact.
[05:06] <huwshimi> lifeless: I guess really most people don't refer to docs unless they get stuck with something.
[05:07] <huwshimi> lifeless: Or they really don't know where to begin
[05:09] <StevenK> Didn't Julian add a boolean that we can use to check if something returned any rows? I can't recall what it is called.
[05:16] <lifeless> huwshimi: exactly
[05:16] <lifeless> StevenK: its __nonzero__ and only on sqlobjecresultset : don't use it.
[05:17] <lifeless> StevenK: storm result sets have .empty()
[05:17] <lifeless> StevenK: but note that this is a query: *if* you are going to ask for any rows, just ask, don't check for emptiness
[05:22] <lifeless> here stubby stubby stubby
[05:23] <lifeless> StevenK: can you run a query on df for me
[05:23] <StevenK> Certainly
[05:23] <lifeless> I'd like an explain analyze of
[05:23] <lifeless> https://bugs.launchpad.net/launchpad/+bug/734642/comments/3
[05:23] <_mup_> Bug #734642: POFile:+translate timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/734642 >
[05:23] <lifeless> I'm looking for cold cache performance
[05:24] <StevenK> Can't get much colder than DF
[05:24] <lifeless> right
[05:24] <lifeless> it is about 30 times faster than the current hot performance
[05:24] <lifeless> but if its not hotter cold, the win isn't very important
[05:25] <lifeless> s/hotter/faster/
[05:26] <StevenK> lifeless: 1345.664 ms, do you want the output?
[05:27] <lifeless> please
[05:27] <lifeless> I wonder if we just need a tonne of ram
[05:27] <StevenK> Let me apologise in advance, I didn't turn off the pager, so it's going to look like crap, and re-running it won't give the same values
[05:28] <lifeless> thats fine
[05:28] <lifeless> pastebomb away
[05:28] <StevenK> http://pastebin.ubuntu.com/580007/
[05:29] <lifeless> thanks
[05:29] <lifeless> so, no worse
[05:29] <lifeless> but not substantially better
[05:31] <StevenK> lifeless: I'd welcome your comments on https://code.launchpad.net/~stevenk/launchpad/dsd-base_source_pub-search-parent/+merge/53194 . Mostly interested in your thoughts re lines 27-51 of the diff
[06:00] <lifeless> StevenK: commented
[06:00] <lifeless> StevenK: not pubs.empty() would be better than using count() btw
[06:01] <lifeless> StevenK: only use count() if you need a count and won't be querying all the rows.
[06:07] <StevenK> lifeless: Thanks, I've taken your suggestion with a little tweak.
[07:36] <lifeless> jtv: you might like the new plan in bug 734642
[07:36] <_mup_> Bug #734642: POFile:+translate timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/734642 >
[08:21] <rvba> stub: Hi Stuart. I've just done my first db changing branch and I'd like you to review it when you get a chance.
[08:21] <rvba> It's been approved by sinzui and the change is really not controversial but since I'm fairly new to the code (joined Canonical 2 weeks ago) please don't hesitate to give me any recommandation.
[08:21] <rvba> https://code.launchpad.net/~rvb/launchpad/db-add-distro-registrant/+merge/53001
[08:21] <stub> yup.
[08:22] <stub> yer - this one looked trivial
[08:22] <rvba> stub: it is yes.
[08:22] <jtv> lifeless: Took me a while to decypher what you pasted there… do you think it's the WITH that does it?  Or is it mostly that the "potmsgset <> $INT" check moved from the TM part to the POTMsgSet part?  I'm pretty sure we had it in the POTMsgSet part at one point.
[08:22] <lifeless> jtv: its the with
[08:23] <jtv> Just acting as an optimization barrier?
[08:23] <lifeless> jtv: comment 2 is the first iteration of the with, and when I then move the potmsgset I cap the upper estimate too
[08:23] <stub> rvba: So people decided to keep both owner and registrant, or will owner be dropped in the future?
[08:23] <jtv> Frankly I don't even see much reason to have the potmsgset <> $INT check… because we query the ones with potmsgset = $INT separately anyway.
[08:23] <lifeless> with alone is 350->690 or whatever, with + move potmsgset is 350..350
[08:24] <jtv> lifeless: are those numbers estimated costs?
[08:25] <lifeless> jtv: yeah
[08:25] <rvba> stub: Owner will stay and be the field still used for perm checking (owner = maintainer for distributions). Registrant is just a historical record of who created the object.
[08:25] <thumper> https://code.launchpad.net/~thumper/launchpad/blueprint-dependency-vocabulary/+merge/53192 anyone?
[08:25] <lifeless> jtv: actual execution with the with is ~ 30 times faster than the existing query
[08:25] <jtv> That's great.  It's too hard to read so I'll just take your word for it.
[08:25] <lifeless> jtv: :>
[08:25] <lifeless> jtv: with seems to be a very useful thing, was the main point
[08:25] <jtv> So… any takes on implementing it?
[08:26] <lifeless> jtv: I figured you'd be interested with your joint rosetta + postgresql interests
[08:26] <jtv> Of course I am!  But I'm on feature rotation.  :(
[08:26] <lifeless> jtv: Its about 15 minutes to code up, I'll do it tomorrow morning if noone beats me to it
[08:26] <jtv> Great, thanks!
[08:27] <jtv> Can I take it the "with" mainly serves as a way to force the planner to materialize that subquery?
[08:28] <lifeless> it creates a temporary table
[08:28] <lifeless> so yes, in this context I think that that is what its doing
[08:30] <stub> rvba: Is 'registry' actually a good default registrant of the existing Distributions? We might want to be more selective if it gives any genuine power.
[08:30] <lifeless> the registrant is just to make our db work a bit harder rendering the thing
[08:32] <lifeless> meep yesterday was busy
[08:32] <lifeless> non-opstats pages: 7574479
[08:32] <rvba> stub: AFAIK the whole idea (sinzui is the one driving this) was to separate clearly who registered the object (and this should not give real power) and who the maintainer is. The only use of the registrant field is to display inside the 'Registered by' slot.
[08:32] <stub> Sounds fine.
[08:33] <rvba> this might sound silly (and only made to have an extra query) but I think it makes sense because the same thing will have to be done for distroseries.
[08:33] <stub> Approved. Some things to change listed in the review.
[08:35] <rvba> here is sinzui's opinion on this (for distroseries):
[08:35] <rvba> sinzui "Since distros series do not have a direct owner, it seemed okay in the past to reuse the field for registrant. but owner is intended to be mutable. It is not possible BTW to change a series owner. We removed the field from edit forms"
[08:35] <stub> It sounds silly if we will only ever have Distributions registered by the registry team (which is silliness we have done for years unfortunately). If random users can register distributions, fine.
[08:36] <lifeless> heh, i just tried to use 'y' to archive this channel :P
[08:39] <rvba> I'm not sure it's very frequent for random users to register distributions... but AFAIK the whole thing is to cleanup the owner field for distro, distroseries (and also productseries and productrelease) which has been 'reused' in the past to store other things (sometimes the registrant) than what it should store.
[08:44] <rvba> lifeless: you're right when you say that the current displayed registrant for a distro is the owner. And if we want the changes to be without effect on existing distro we should use the owner instead of ~registry. But I think sinzui's point was that in order to normalise the registrant of objects we should set it to ~registry in the migration script.
[08:49] <lifeless> rvba: why normalise it?
[08:49] <lifeless> rvba: surely the existing data is more accurate than ~registry
[08:50] <rvba> lifeless: since this is a read-only field I guess it's really not a problem to set the registrant to user instead of ~registry.
[08:50] <rvba> and it might be more informative ....
[08:50] <rvba> lifeless: I think sinzui's argument of cleaning things up really makes sense. But as you can imagine, being still fairly new to the code, I can't say that I have a personal opinion on this.
[08:50] <rvba> lifeless: but I really understand your point
[08:51] <lifeless> rvba: setting it to registry would discard what data we have
[08:51] <lifeless> I think its wrong.
[08:51] <rvba> lifeless: right
[08:51] <lifeless> if we want it to be registry it would be a lot easier to just hardcode that in the templates :)
[08:51] <rvba> lifeless: it wont be registry for newly created objects
[08:52] <StevenK> henninge: Hi! Are you good to be OCR today?
[08:52] <adeuring> good morning
[08:52] <lifeless> rvba: I know, but if we don't want it to be registry for new ones, we don't need it to be registry for old ones :)
[08:52] <rvba> lifeless: again, I really understand your point.
[08:52] <henninge> StevenK: I am.
[08:53] <StevenK> henninge: Are you up for reviewing https://code.launchpad.net/~stevenk/launchpad/dsd-base_source_pub-search-parent/+merge/53194 ?
[08:53] <henninge> StevenK: sure ;)
[08:54] <lifeless> rvba: where does that leave us?
[08:54] <rvba> lifeless: I'll just make sure with sinzui (he's really the one driving this) that there is no secret reason why he wanted to set the registrant to ~registry :-)
[08:54] <rvba> lifeless: but I think you're right
[08:55] <thumper> lifeless: where's that page that shows the revisions blocking the rollout?
[08:55] <rvba> lifeless: is that ok with you?
[08:55] <lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[08:55] <lifeless> rvba: sounds great
[08:55] <thumper> ta
[08:55] <lifeless> rvba: I suggest optimistically changing it now to get stubs ack on the update script change
[08:56] <rvba> lifeless: ok
[08:56] <thumper> lifeless: when is the next rollout?
[08:56] <rvba> I'm actually doing it right now.
[08:56] <lifeless> thumper: I have one up on LPS
[09:00] <lifeless> thumper: but we have no losa until US come on
[09:01] <henninge> StevenK: Sounds to me like there is a "not" missing somewhere in this comment:
[09:01] <henninge>  98	+        # Passing in a base version to makeDistroSeriesDifference() creates
[09:01] <henninge> 99	+        # it in both distroseries, so we need to do it ourselves.
[09:02] <lifeless> henninge: the test is testing the case where one side is missing the base
[09:02] <lifeless> henninge: so the statement is correct
[09:02] <thumper> :(
[09:03] <lifeless> thumper: I enquired about gsa vg doing it, but they felt uncomfortable
[09:03] <henninge> hm, then I don't understand it
[09:03] <thumper> fair enough
[09:03] <StevenK> henninge: Would you prefer I re-word it?
[09:03] <henninge> lifeless: wht is "do it" referring to?
[09:04] <henninge> StevenK: I don't think I understand the comment yet
[09:04] <StevenK> henninge: "do it" in that context refers to creating the publication.
[09:06] <lifeless> thumper: what rev do you want live ?
[09:06] <thumper> 12571
[09:08] <StevenK> The deployment is for 12582, so that's okay
[09:08] <StevenK> I want 12569 deployed, so I've also been looking.
[09:13] <henninge> StevenK: I am sorry, I may be missing some understanding about DSDs here and the implication of that comment.
[09:14] <henninge> which kind of tells me I might not be understanding what this branch is all about in the first place ...
[09:14] <StevenK> henninge: Okay, so makeDistroSeriesDifference() can take a 'base' version in the versions dict. That will create a publication in both the parent and the child distroseries. I don't want it to do that, so I need to create the publication myself in only the child.
[09:15] <StevenK> henninge: The reason for the change is that it is much more likely for the parent distroseries to contain the base publication than for the child too -- hence the change to look in the parent first.
[09:16] <StevenK> "than for the child to" even
[09:16] <lifeless> thumper: are both your bp branches ready for review?
[09:16] <lifeless> thumper: if so I can eyeball your second one for you
[09:16] <henninge> StevenK: but you are doing that *after* the call to make DistroSeriesDifference, so does that change its behavior?
[09:17] <StevenK> henninge: Not at all, but it is why I have to call ds_diff.update() after doing so.
[09:17] <henninge> ah!
[09:18] <StevenK> Doh, forgot to triage
[09:19] <henninge> StevenK: so "update" will remove the base version from the parent?
[09:19] <StevenK> henninge: update tells the DSD "stuff has changed, please look again and update your internals as necessary"
[09:19] <henninge> I understand that bit.
[09:20] <StevenK> henninge: I think you're close -- do you want a have a quick chat on Mumble to close the gap?
[09:20] <henninge> StevenK: that would be helpful, I think
[09:21] <henninge> let me set that up real quick
[09:21] <bigjools> wgrant: hello.  Did you see OOPS-1897PPA11 ?
[09:22] <StevenK> bigjools: It's a public holiday in VIC today
[09:22] <wgrant> bigjools: As StevenK said, I'm not here today.
[09:22] <wgrant> But let me look.
[09:22] <bigjools> those lazy victorians
[09:22] <StevenK> Haha. Sarah said exactly the same thing.
[09:22] <bigjools> :)
[09:23] <wgrant> bigjools: Isn't that just the usual unsigned changes file?
[09:23] <bigjools> wgrant: hard to tell from that oops
[09:23] <bigjools> also OOPS-1898PPA5
[09:23] <wgrant> Missing Files section usually is.
[09:23] <wgrant> bigjools: That was a manually constructed changes file.
[09:23] <wgrant> Had only a dsc and a deb.
[09:23] <bigjools> 1st one is "InvalidEmailAddress: master@ussr.htv4"
[09:23] <wgrant> I presume that's relevant.
[09:24] <wgrant> Oh, got them mixed up.
[09:24] <wgrant> Right, I was looking at 1897PPA5 instead of 1897PPA11
[09:24] <bigjools> both look like bugs either way, we should respond to the uploader
[09:24] <bigjools> someone is causing Archive:+delete to time out as well :/
[09:25] <wgrant> lifeless filed a bug on Archive:+delete earlier.
[09:25] <bigjools> cool
[09:25] <wgrant> Both are bugs, yes.
[09:25] <lifeless> some guy tried to delete packages
[09:25] <lifeless> that timed out
[09:25] <rvba> stub: lifeless just pushed the corrections (https://code.launchpad.net/~rvb/launchpad/db-add-distro-registrant/+merge/53001)
[09:25] <lifeless> so he tried to delete his ppa with 435 active publications
[09:26] <lifeless> 9 seconds in one update statement
[09:27] <lifeless> bigjools: I've got a patch up for oops-tools that will get rid of the 'top 10' limit on exceptions
[09:27] <bigjools> Oo
[09:27] <lifeless> bigjools: once thats live I plan to get rid of the dedicated soyuz report, because we'll see them easily in the main report.
[09:27] <bigjools> sounds sensible :)
[09:28] <bigjools> lifeless: as long as they stick out like very sore thumb, that's ok
[09:29] <lifeless> bigjools: well, how about we get the patch live, wait a day, and I'll see how it looks to you
[09:29] <lifeless> bigjools: AFAICT you're the only person wanting a broken out soyuz report now
[09:30] <lifeless> bigjools: if it looks clear enough in the main report, we can then close off the dedicated report. If its not clear enough, we can revisit in another few weeks.
[09:31] <bigjools> lifeless: so there's a few OOPSes that should not be oopses and there's bugs filed about that.  When they are fixed, *any* oops after that is genuine and critical.  As long as they are obvious in the report I have no issues.
[09:31] <bigjools> lifeless: that's a good plan
[09:43] <LPCIBot> Project windmill build #47: STILL FAILING in 1 hr 15 min: https://hudson.wedontsleep.org/job/windmill/47/
[09:50] <StevenK> henninge: Thank you for the review. :-)
[10:03] <henninge_> StevenK: you are welcome ;)
[10:05] <lifeless> mpt: oh hai
[10:05] <mpt> lifeless, hi ho
[10:05] <lifeless> mpt: how did that paperwork go?
[10:05] <mpt> lifeless, excellent, thank you, I have a shiny new passport
[10:06] <jml> Good morning Launchpadders
[10:06] <lifeless> mpt: cool
[10:06] <lifeless> jml: hai
[10:06] <lifeless> mpt: how is lp coming along, from your disinterested perspective ;)
[10:07]  * bigjools waves at jml
[10:07] <mpt> lifeless, more speed is good. I haven't noticed any other changes recently.
[10:08] <mpt> Oh, except that heading color changed for some reason.
[10:08] <lifeless> mpt: are you noticing speed changes?
[10:08] <stub> rvba: The repush is fine too. I think you are good to send it off to ec2 to land.
[10:09] <rvba> stub: great, just need a few words with sinzui about this (he's driving this) and I'll land it.
[10:09] <lifeless> hmm
[10:09] <lifeless> isd branch mangler probably doesn't do what they want ><
[10:09] <mpt> lifeless, no, more like I'm no longer noticing slowness. I guess the bane of performance work is that if you do it right, people end up not noticing.
[10:10] <lifeless> mpt: thats excellent new
[10:10] <lifeless> s
[10:10] <lifeless> mpt: theres another step to get to 'snappy'
[10:10] <mpt> yes
[10:10] <lifeless> mpt: but eliminating the negative feeling is still a big step forward
[10:11] <mpt> I still notice that <https://bugs.launchpad.net/ubuntu> takes a while
[10:12] <jml> mpt: sometimes that bane comes to UX work too
[10:12] <mpt> oh, sure
[10:12] <jml> (incidentally, what is the proper verb for 'bane'?)
[10:12] <mpt> I hope there isn't one
[10:13] <lifeless> mpt: thats https://bugs.launchpad.net/launchpad/+bug/618406
[10:13] <_mup_> Bug #618406: Distribution:+bugs-index time outs <lp-bugs> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/618406 >
[10:13] <mpt> Launchpad's default font size is tiny now
[10:14] <lifeless> mpt: we're going to drop the bugtask.id secondary sort, which makes the query 2000 times cheaper
[10:14] <mpt> I always have to Ctrl + after arriving
[10:15] <lifeless> yeah
[10:15] <lifeless> sinzui has a Plan
[10:31] <jam> lifeless: is there something I'm supposed to be subscribed to so that I get notification when I can QA a given fix?
[10:31] <jam> I don't want to be holding up the pipeline, but it often just seems like guesswork to me
[10:34] <lifeless> jam: the bug
[10:34] <jam> lifeless: so when it changes to "qa-needstesting" it is supposed to be readi?
[10:34] <jam> ready
[10:34] <lifeless> https://bugs.launchpad.net/launchpad/+bug/732481/comments/6
[10:34] <_mup_> Bug #732481: internal error trying to serve HEAD <qa-untestable> <Launchpad itself:Fix Committed by jameinel> <loggerhead:Invalid> < https://launchpad.net/bugs/732481 >
[10:35] <lifeless> thats done by a bot that watches what is deployed to qastaging and staging
[10:35] <lifeless> when it comments, the fix is on qastaging and testable - and needs testing
[10:35] <lifeless> allenap: speaking of qa
[10:41] <allenap> lifeless: The js thing? I'm doing that now, as much as I can, and I'll be sending out an email shortly to request some help.
[10:44] <bigjools> gah, we really need to fix bug change conflicts
[11:04]  * bigjools identifies a 4-digit bug that will need to be fixed for derived distros
[11:04] <deryck> Morning, all.
[11:05] <gmb> allenap: The changes to the way that lp.js is built don't have anything to do with the error that I'm seeing on https://launchpad.net/launchpad, do they?
[11:05] <gmb> Uncaught TypeError: Cannot read property 'pillar' of undefined
[11:06] <lifeless> gmb: no
[11:06] <lifeless> gmb: allenap's changes deployd have not been
[11:06] <gmb> Ah, right.
[11:06] <gmb> Bugger, that means danilos and I have to Do Work.
[11:06] <allenap> What he said :)
[11:06] <gmb> Thanks anyway.
[11:16] <lifeless> jml: lp:~tseaver/subunit/py3-hacks may interest you
[11:17] <jml> lifeless: yeah, it deos.
[11:17] <rvba> henninge: Hi, I'd appreciate a review of https://code.launchpad.net/~rvb/launchpad/fix-missing-addseries-link/+merge/53219
[11:18] <rvba> henninge: really trivial refactoring of a few tests.
[11:26] <henninge> rvba: I am happy to do that
[11:26] <rvba> henninge: thx
[11:33] <bigjools> Does anyone have any thought on how useful it is to have a Subscribers portlet on a bug page?
[11:35] <gmb> allenap: I see a lot more stuff in my JS console today on lp.dev. Is that something to do with your changes?
[11:36] <allenap> gmb: Can you paste? In what environment?
[11:37] <allenap> bigjools: You want to ditch it?
[11:37] <gmb> allenap: Firebug or WebKit. Paste coming up...
[11:37] <wgrant> bigjools: I think the direct subscriber list is handy... the structural subscribers not so much.
[11:37] <gmb> allenap: This kind of stuff: http://pastebin.ubuntu.com/580089/
[11:37] <bigjools> I agree with wgrant
[11:37] <bigjools> it takes up loads of space and it's fairly useless
[11:37] <allenap> I'm with wgrant on that, though it might be interesting to know if someone has a structural subscription when adding them as a direct subscriber.
[11:37] <wgrant> I want to be able to see the strucsub list.
[11:38] <wgrant> But not always.
[11:38] <wgrant> There should be a button or something.
[11:38] <allenap> gmb: Is this in dev?
[11:38] <gmb> allenap: Yes
[11:39] <allenap> gmb: That's probably because it uses the debug builds of YUI by default. That's a bit too noisy isn't it? That's readily fixable. If it's a problem I'll file a bug.
[11:40] <gmb> allenap: That would be great, thanks. Can you tell me how to make it STFU for the sake of the debugging I'm doing now?
[11:41] <allenap> gmb: No idea :)
[11:41] <allenap> gmb: Let me see...
[11:42] <gmb> allenap: I'm happy to prod at stuff until it shuts up, I just thought that you might know. Unless "readily fixable" is Norfolk-speak for "Eh, I dunno."
[11:49] <allenap> gmb: Can you try the following as a workaround? make clean_js; make JS_BUILD=min jsbuild_lazr; make JS_BUILD= -W jsbuild_lazr jsbuild
[11:49] <gmb> Sure.
[11:50] <gmb> allenap: That worked. Thanks.
[11:50] <allenap> gmb: Woohoo :)
[11:50] <allenap> gmb: I'll reply to my message to the list to let others know.
[11:51] <gmb> allenap: Thankee kindly.
[11:56] <allenap> gmb: Btw, if you s/min/raw/ then it'll unminify lazr.js too.
[11:56] <gmb> allenap: Cool, ta
[12:03] <henninge> rvba: Approved but with a few formatting issues that I'd like you to fix, please.
[12:04] <rvba> henninge: will do, thx.
[12:24] <jtv> benji, are you up for a review?  https://code.launchpad.net/~jtv/launchpad/bug-733245/+merge/53230
[12:25] <benji> jtv: sure
[12:25] <jtv> great
[12:33] <jtv> bigjools: I guess I'll need help from someone privileged to Q/A the creation of DSDs during package publication.
[12:46] <wgrant> jtv: What sort of performance penalty does that entail?
[12:57] <jtv> wgrant: whatever it takes to compute base_version, basically, plus change
[12:58] <wgrant> jtv: Erm.
[12:58] <wgrant> Can't do that while creating the publication.
[12:58] <jtv> Oh sorry, right, I create jobs, not DSDs.
[12:58] <wgrant> Right. How expensive is that?
[12:58] <jtv> My head was still in a different branch.  :)
[12:59] <jtv> Shouldn't be very expensive… just create a tiny little record holding the distribution, distroseries, and a little bit of json that holds the sourcepackagename id.
[12:59] <jtv> Oh, and check for duplicates first.
[12:59] <wgrant> Does it query for existing ones?
[12:59] <wgrant> Right.
[12:59] <jtv> Yes
[12:59] <wgrant> Hopefully that's cheap.
[13:00] <benji> jtv: I'm done with https://code.launchpad.net/~jtv/launchpad/bug-733245/+merge/53230
[13:00] <jtv> It's something we can add an index for.
[13:00] <jtv> thanks benji!
[13:00]  * jtv reloads
[13:00] <benji> np
[13:00] <danilos> anyway knows anything about how LP loads JS and specifically, when/how does LP.links.me and LP.cache gets preloaded? (I see links['me'] is defined in lib/canonical/launchpad/rest/me.py through some event magic, but that doesn't really tell me how that gets assembled into JS)
[13:00] <deryck> henninge-lunch, adeuring -- is standup time now for you guys?  Or in an hour?
[13:01]  * deryck suspects DST fail
[13:01] <danilos> deryck, Europe's got another two weeks of non-DST time, yay :)
[13:01] <deryck> ah, fun calendaring ahead then
[13:02] <deryck> :-)
[13:04] <adeuring> deryck: I assumed the standup starts in 56 minutes
[13:05] <deryck> adeuring: ok, cool.  Since abentley and I can't have it without you guys, we'll do it then. ;) :)
[13:05] <deryck> adeuring: we're okay to keep it at this time, until you and henninge-lunch join DST in a couple weeks.
[13:05] <adeuring> deryck: well, I wouldn't mind to do it right now, but i think henning has lunvch right now
[13:06] <deryck> adeuring: no worries.  Probably easier to keep it the same for you guys.
[13:15] <StevenK> I'm on my way to bed, would someone mind forcing db-devel and mailing the list -- it failed to checkout source code.
[13:15] <danilos> deryck, hi, do you know if there is a special event that is triggered when LP data is populated in JS? (i.e. LP.links.me, LP.cache)
[13:15] <danilos> deryck, or, how can one ensure that his code runs only after that happens? (asking you because you have touched some JS lately, I understand that this may be inappropriate :)
[13:18] <abentley> deryck: is there a way to run a launchpad.dev instance using the un-minified javascript?
[13:22] <deryck> abentley: get latest devel and run `make JS_BUILD=raw clean_js jsbuild`
[13:22] <deryck> and thank allenap for that :-)
[13:23] <deryck> abentley: if you want more log output you can do "debug" instead of "raw."  I think it does debug by default right now.
[13:23] <abentley> deryck: Cool.  I just saw that too.
[13:24] <deryck> danilos: I don't think there is any event when the cache is setup.  thumper added a bunch of event stuff for in page updates a couple weeks back, but I haven't looked at it yet.  So don't know for sure.
[13:25] <danilos> deryck, right, so what I have is basically some page setup code that wants has a conditional on whether user is logged in (using LP.clients.me [13:26] <deryck> danilos: I would have done it that way, too.
[13:26] <danilos> deryck, except that it doesn't work because it is undefined all the time, and gets populated later (or so it seems) :(
[13:26] <danilos> anyway, thanks, won't bother you any longer about this, I guess it's all the same for all of us :)
[13:26] <deryck> hmmm
[13:27] <deryck> danilos: ah, right.  It's probably not populated until domready itself.  So you're in a race with it.
[13:28] <deryck> danilos: if thumper's work didn't add and event for that.  it would be pretty easy to add one to the client code and hook into it.
[13:28] <danilos> deryck, yeah, so what I want to do is have that code fire something like "lp-event" and than use that, but I don't even know where that code is :)
[13:28] <deryck> right
[13:28] <deryck> it's in lib/lp/app/javascript/client.js I think
[13:29] <deryck> danilos: yeah, that's it:  lib/lp/app/javascript/client.js
[13:30] <danilos> deryck, yep, found it now, I was looking for clients.me stuff, when it's all about the "cache"
[13:30] <deryck> right
[13:36] <deryck> danilos: so it looks like this is setup manually in lib/lp/app/templates/base-layout-macros.pt.  I would think a sniff for it would work.  Did you check it as:   LP.links.me [13:37] <danilos> deryck, yes
[13:38] <deryck> danilos: after domready?
[13:38] <danilos> deryck, well, it works just fine if you are not inside domready event handler (i.e. after it really loads :)
[13:39] <deryck> danilos: ok, that was going to be my next question, if doing it after load mattered?  if it works after load, then I'd do that.
[13:40] <danilos> deryck, right, that's what I want to do but just need to figure how to best do it
[13:42] <danilos> deryck, so, do you think it would be outrageous to fire something like "lp-ready" even in base-layout-macros.pt when all LP elements are loaded?
[13:42] <danilos> s/even/event/
[13:45] <deryck> danilos: I think that would be fine.  The problem you might have, though, is that the links and cache objects are constructed outside of YUI.  So I'm not sure of the timing if you add a YUI block after them.  Seems like it should work, though.
[13:46] <danilos> deryck, right, I'll try it out and see if it seems stable
[13:46] <deryck> danilos: ok, cool.  good luck with it!
[13:47] <danilos> thanks :)
[13:52] <LPCIBot> Project windmill build #48: STILL FAILING in 1 hr 9 min: https://hudson.wedontsleep.org/job/windmill/48/
[14:00] <danilos> deryck, actually, domready was not the problem! we forgot to make the event handler for domready a closure, so it was run right after it was passed
[14:01] <danilos> deryck, I figured that out when I noticed that even with my event I was getting undefined
[14:08] <deryck> danilos: ah, good catch.  So that makes it simpler for you now, too! :-)
[14:10] <danilos> deryck, yeah, ta
[14:17] <deryck> I'm working on Windmill today.  See if I can get it stable enough to re-enable.
[14:17] <deryck> Just FYI, for anyone watching the Jenkins builds and concerned.
[14:19] <jcsackett> bac: ping.
[14:19] <bac> hi jcsackett
[14:19] <jcsackett> hi, bac. so, about that lp.registry.pillar.
[14:20] <jcsackett> once upon a time, that was using a separate "activate_collapsible_div" function defined in a file called pillar.js
[14:20] <jcsackett> but it was later realized that activate_collapsible could just be refactored to allow a more general case.
[14:21] <jcsackett> that refactor done, i appear to have then forgotten to kill that call in the template, and didn't see an error b/c the functionality i was looking at still worked.
[14:21] <jcsackett> so, you should be able to totally whack that in what you're looking at and see no ill effect, bac.
[14:21] <bac> jcsackett: understandable.
[14:21] <bac> jcsackett: ok.
[14:21] <bac> i'm landing a branch today so i'll include the whackage
[14:21] <jcsackett> awesome.
[14:22] <jcsackett> and sorry for the confusion on this part; i just had to look 40 revisions deep in a really confused branch of mine to figure it out. :-)
[14:25] <jcsackett> bac: i replied to the email thread so the rest of your team is up to date.
[14:26] <bac> thanks again
[14:26] <jcsackett> no worries. my mess in the first place, sorry you stepped in it. :-)
[14:26] <henninge> adeuring: I am here, btw.
[14:26] <henninge> ;)
[14:29] <henninge> adeuring: nu aba
[14:47] <abentley> adeuring: so this model method you want.  I think it could be a method on TranslationMergeJob that accepted a Packaging and returned the JobStatus of the next pending or running job.  It would return None if there was no matching job.  How does that sound?
[14:49] <adeuring> abentley: right, that would work. But we start from a package context, so we would also need a package method "list pending translation merge jobs"
[14:49] <adeuring> well, ok, that coudl also be done in browser code...
[14:50] <abentley> adeuring: Why do you want a list?
[14:50] <abentley> adeuring: I meant that it would be a classmethod on TranslationMergeJob.
[14:50] <adeuring> abentley: I just thought that we basically do a SQL query, and that returns a sequence
[14:51] <adeuring> and right, a classmethod for TMJob would be fine.
[14:51] <sinzui> rvba: I replied to your emails. I hope I helped.
[14:52] <abentley> We would do an sql query, and that would return a sequence, but you don't want a sequence, so why are you asking for a method that returns a sequence?
[14:52] <rvba> sinzui: I'm reading them right now
[14:53] <rvba> sinzui: do you want to talk to Rob about the ~registry thing? (the branch is really to land but I really can wait for the final thought on this ;-))
[14:53] <sinzui> No
[14:53] <rvba> sinzui: ok then
[15:27] <rvba> sinzui: (question unrelated to the whole registrant thing): is there a reason why "make lint" does not use format-imports to warn about imports needing to be formatted?
[15:27] <sinzui> rvba: no reason.
[15:28] <sinzui> rvba: I certainly could. and do the copyright update too
[15:28] <sinzui> s/I/It/
[15:28] <rvba> sinzui: I'll do it then, and thus take this opportunity to lean a little bit more about the build system
[15:29] <rvba> sinzui: copyright update? you mean automatically warn about the date in the header?
[15:30] <sinzui> rvba: utilities/update-copyright will update all the dates in the changed files if they need it
[15:30] <rvba> I like the idea of "make lint" not doing anything by itself but warning, and maybe giving commands to be executed to do the actual stuff ...
[15:31] <rvba> sinzui: should the format be done automatically or just warn (like make lint already does with the sample data files)?
[15:33] <bac> benji: can you review https://code.launchpad.net/~bac/launchpad/accordion-style/+merge/53259?
[15:33] <benji> bac: sure
[15:33] <bac> benji: great, thanks.  i'm going to have to be gone a bit but can answer questions when i return
[15:34] <sinzui> rvba: It would be lovely if it could do it automatically. I think that would be surprising though. The the scripts behave differently when there are uncommitted files in the tree. I think lint should warn when when everything is committed.
[15:34] <benji> k
[15:36] <danilos> sinzui, hi, fwiw, I think the sharing stuff you CCed jtv and me about is best known by henninge and/or deryck (it seems to be the new stuff they worked on)
[15:36] <rvba> sinzui: sounds strange to break existing habits though ... why not create a "make format" that would do this, then if new tools are added to the tool set, they could be added here.
[15:37] <sinzui> danilos: okay, i will do that now. Thank you.
[15:37] <sinzui> rvba: +1 `make format` that does code cleaning
[15:37] <rvba> sinzui: ok
[15:38] <sinzui> rvba: our linter uses pocket-lint which also has code cleanup features like fixing whitespace, line endings, doctests, css etc...
[15:39] <rvba> sinzui: I saw that you are the driver for the project yes, that's why I was asking you
[15:44] <jml> sinzui: do you want to have a call today?
[15:45] <sinzui> I have nothing to bring today. Maybe next week?
[15:45] <jml> sinzui: sure.
[15:47] <sinzui> rvba: okay. pull tip. I landed a fix for py 2.7 recently. I have not packaged it. I thought I wold do it over the weekend, but I needed to not hack for a could days to collect my mind.
[15:49] <rvba> sinzui: you mean in pocket-lint?
[15:55] <sinzui> rvba: yes. Lp is using an older version.
[15:56] <rvba> latest revision was on 2011-03-03
[15:58] <sinzui> rvba: yes
[15:59] <sinzui> jcsackett: do you have a few minutes to discuss my branch to enable the person merge job: http://pastebin.ubuntu.com/580164/
[16:01] <jcsackett> sinzui: ten minutes, then sure.
[16:01] <sinzui> okay thanks
[16:02] <gary_poster> hey deryck, can you by chance point me to some JS somewhere that I can decipher that manipulates something that is exported as a CollectionField, or in some other way point me to figuring out the preferred way to delete something from a CollectionField in js?
[16:02] <gary_poster> heh, sorry for the convoluted sentence
[16:02] <deryck> heh, np. thinking....
[16:02] <gary_poster> didn't sleep well last night :-/
[16:07] <gary_poster> Looks like maybe we don't do that now, and we need to add a method on Collection in client.js to do it "right"?
[16:09] <deryck> gary_poster: was just about to reply with that same statement.  I don't see that we do it anywhere.  We mostly fetch objects directly and mess with them.
[16:11] <gary_poster> ok deryck, thank you!
[16:11] <deryck> np!
[16:13] <jcsackett> sinzui: i am on mumble.
[17:43] <matsubara> An indirect member of a team that owns a private branch can't access the private branch. Shouldn't the user be allowed? Is there a restriction for indirect members?
[17:44] <abentley> deryck: I've gotten though the display side of doing the checklist, about to move onto the webservice part.  I sent you an email with some screenshots.  Just wanted to get your take on it.
[17:44] <deryck> abentley: yes, just about to respond....  looked at the screenshots and they looked great.  Just wanted to peak at the code before I responded.
[17:44] <abentley> deryck: cool.
[17:50] <deryck> abentley: yeah, I think this is good.  Any specific questions?
[17:50] <abentley> deryck: how do I test the controller, especially once I wire it up to do AJAX?
[17:52] <abentley> deryck: Is there a better way to set/unset the "unseen" class?
[17:54] <deryck> abentley: ok, so re: testing with AJAX, look at Y.Mock.  http://developer.yahoo.com/yui/3/test/#mockobjects  And lib/lp/soyuz/javascript/tests/lp_dynamic_dom_updater.js is an example.
[17:55] <deryck> abentley: and as for the unseen stuff, I think that's fine what you have.  I think I would call it toggle_unseen, or something like that, just to be clear what it does.  But it's a fine approach to do it that way.
[17:55] <deryck> we always use add/removeClass
[17:56] <abentley> deryck: I wouldn't call it toggle_unseen, because "toggle" to me means that it changes the state to the opposite every time you call it.  This one sets the state.
[17:57] <deryck> abentley: ok, but it is unsetting unseen, i.e. making the thing seen if needed, yes?
[17:57] <abentley> deryck: Yes.  The state is the presence or absence of the "unseen" class on the element.
[17:59] <deryck> abentley: so that you can use one function to turn the class on or off, right?  set_unseen, to me, implies we're only ever making the thing unseen.  Maybe toggle isn't the right word, but I think the name could be clearer.
[17:59] <deryck> abentley: but this is a minor thing, obviously.
[18:00] <abentley> deryck: I'd like to make the name clearer, but it's hard to express what it does succinctly.
[18:00] <deryck> abentley: fair enough
[18:01] <deryck> set_or_remove_class_unseen_depending_on_state ;)
[18:01] <deryck> but since it's js, we can call it -- sorcudos
[18:01] <abentley> deryck: he he.
[18:03] <abentley> deryck: I could invert the logic and call it set_visibility.
[18:04] <deryck> indeed.  that would work.
[18:05] <deryck> so much  nicer than my name.
[18:12] <abentley> deryck: done.
[18:12] <abentley> What about mocking the DOM for those Y.one calls?
[18:12] <abentley> deryck: ^
[18:13] <deryck> abentley: on call now, sorry
[18:13] <abentley> deryck: ack.
[18:28] <deryck> abentley: so mocking the DOM.... do you mean using Y.Mock, or just having some similar HTML in the test html file to interact with?
[18:29] <abentley> deryck: Oh, I see.  I should be able to just plunk the same code in the test html file, and then interrogate the test file's DOM.
[18:30] <deryck> abentley: yes, exactly.  That's how we usually do it.
[18:30] <abentley> deryck: Great.
[18:31] <abentley> deryck: btw, there's already a function to add/remove arbitrary classes on Y.Node: toggleClass.
[18:31] <deryck> abentley: ah, nice.  I didn't even know that.  so much there.
[18:32] <abentley> deryck: By default, it changes the state to the opposite, but you can specify True or False.
[18:32] <deryck> cool
[18:32] <lifeless> moin moin
[18:35] <lifeless> allenap: hey
[18:35] <lifeless> allenap: is 12584 ok now?
[18:36] <lifeless> allenap: if not, how long are you proposing we wait to be confident ?
[18:36] <lifeless> deryck: are you able to qa rev 12586 ?
[18:37] <deryck> lifeless: yes, going to get it before I EOD today.  starting in about 10 minutes on it.
[18:40] <lifeless> deryck: :)
[18:42] <ToyKeeper> I'm not sure if it was mentioned by number, but I'm hoping to resolve bug #734995 soonish for a project this week.
[18:42] <_mup_> Bug #734995: access denied for group branches (canonical-isd-hackers/oops-tools/isd-oops) <Launchpad itself:New> < https://launchpad.net/bugs/734995 >
[19:51] <thumper> deryck, danilos: I really wanted to get to add a "lp:user:loggedin" event
[19:52] <thumper> with the idea that we had a single check point
[19:52] <thumper> and the rest of the code just used that event
[19:52] <deryck> yeah, that would be cool
[19:52] <thumper> then, if we ever got around to it
[19:52] <thumper> we could have an ajax login
[19:52] <thumper> and have the page morph
[19:54] <sinzui> Let's change login to sign in first so that the link matches the words on the SSO pages
[19:58]  * thumper goes to make a mega-coffee
[20:04] <deryck> sinzui: I haven't had a chance to review that email you sent.  Long queues today of reviews, questions, etc.  I'll look tonight or early AM tomorrow.
[20:04] <sinzui> deryck: thanks. rvba is looking for confirmation that my suggestion is sane.
[20:04] <deryck> ah
[20:04] <leonardr> sinzui, thanks so much for chasing down those test failures. i'm looking at the code now
[20:06] <deryck> later on, everyone!
[20:07] <sinzui> leonardr: I think I should have sent my changes to ec2. I hope I did not break anything in the so-called fix
[20:07] <leonardr> sinzui: ec2 land?
[20:08] <leonardr> those test failures don't look related to the bug that was filed. i'll try to reproduce
[20:19] <sinzui> leonardr: `utilities/ec2 test launchpad=devel` will test and send you the report.
[20:20] <leonardr> sinzui: the remaining error is a problem in the way the test is written
[20:20] <leonardr> you are explicitly passing in None for the 'version' argument
[20:22] <sinzui> \o/ I suck
[20:24] <leonardr> sinzui: http://pastebin.ubuntu.com/580280/
[20:24] <leonardr> want me to review the rest of your changes?
[20:24] <sinzui> leonardr: I should have known to pass the version...I told users on #launchpad to do that last week
[20:25] <sinzui> leonardr: sure
[20:25] <leonardr> sinzui: well, you fixed a ton of bugs i never would have been able to fix, so don't feel bad
[20:26] <sinzui> leonardr: I *think* I fixed an oopse, but I could not find an example. The change I made to the bug nomination view implies if there is ever a validation error on the view, it will oops instead of  showing the user how to fix the data.
[20:27] <sinzui> I should look again before you land the branch
[20:29] <lifeless> matsubara-afk: ping (oops-tools)
[20:32] <leonardr> sinzui: problem #1. it looks like we both added the same lines to security.cfg?
[20:33] <sinzui> oops
[20:33] <leonardr> i put mine in a block at the bottom because it seemed really specific to the one task
[20:33] <leonardr> and you intermixed yours with all the others
[20:33] <leonardr> i could go either way but we need to pick one
[20:35] <lifeless> flacoste: 7574479
[20:35] <lifeless> flacoste: https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-categories.html
[20:36] <thumper> mwhudson: ping
[20:38] <leonardr> sinzui: why did you remove the entirety of bugtask-target-link-titles? is it redundant with another test?
[20:38] <leonardr> ah, you wrote unit tests instead
[20:38] <leonardr> ok
[20:38] <mwhudson> thumper: pong
[20:39] <thumper> mwhudson: want to review a blueprint branch for me?
[20:39] <mwhudson> thumper: how complicated is it?
[20:39] <thumper> pretty simple, https://code.launchpad.net/~thumper/launchpad/blueprint-dependency-vocabulary/+merge/53192
[20:39] <allenap> lifeless: I think it's okay. I've heard nothing all day, and I've been around various bits of qastaging. I'll mark it qa-ok.
[20:41] <mwhudson> thumper: yeah alright i'll take a look
[20:41] <thumper> mwhudson: thanks
[20:41] <mwhudson> my lp tree is a bit out of date and i want to look at it in meld, so i'll be a few minutes
[20:41] <thumper> mwhudson: for some reason, no-one likes blueprints
[20:41] <mwhudson> prod me if i seem to have forgotten :)
[20:41] <leonardr> sinzui: what does changing the layer from LaunchpadFunctionalLayer to DatabaseFunctionalLayer accomplish? is it just cleanup?
[20:42] <mwhudson> thumper: i can't possibly imagine why, the code quality is so amazing!
[20:42] <thumper> mwhudson: what? not even hacking on LP for fun?
[20:42] <sinzui> leonardr: yes, I had to disamantle the test to discover which conditions were not valid with sane sample data and factory.
[20:42] <sinzui> leonardr: the tests run faster when they do not setup, clean, and teardown the librarian
[20:43] <lifeless> allenap: thanks
[20:44] <sinzui> leonardr: also that doctest I removed was also being run twice because it was implicitly loaded by test_doc, and explicitly loaded in the module I added the replacement test. Everything ran much faster once I test exactly what the view did
[20:44] <leonardr> yeah, i noticed that duplication
[20:45] <leonardr> sinzui: why did you remove the "Handling IntegrityError" doctest?
[20:45] <sinzui> leonardr: doctests do not test error condition. That is the domain of an implementation test...
[20:46] <sinzui> leonardr: we cannot get to that DB integrity error when the view ensures valid data..We do not permit integrity errors, so there should not have been a test to demonstrate the view was unfinishd
[21:02] <mwhudson> huh, my launchpad repo just hit 100k revs i think
[21:02] <mwhudson> the repack is taking a while...
[21:03] <lifeless> sinzui: we had a doctest checking the view was unfinished? /me facepalms
[21:04] <sinzui> lifeless: yes, it was quite a surprise. leonardr's branch that validates data before we apply revealed a lot os badness
[21:05] <leonardr> sinzui: on closer inspection of the diff, i think there are only 2 duplicate entries in security.cfg: binarypackagebuild and binarypackagename for [processmail]
[21:05] <lifeless> hmm
[21:05] <lifeless> I wish I could close popup diffs :)
[21:06] <sinzui> leonardr: just remove my additions. Sorry about the confusion
[21:06] <leonardr> np
[21:11] <thumper> I wonder if any one actually uses the +deptree view
[21:11] <thumper> leonardr: mumble?
[21:12] <leonardr> sinzui: ok, i think this is ready: lp:~leonardr/launchpad/sinzui-106338
[21:12] <leonardr> thumper: yes
[21:16] <thumper> lifeless: can you tell me if anyone ever goes to a blueprint +deptree page?
[21:17] <leonardr> sinzui: take a look, and i'll try landing again? (it can wait until tomorrow if you want your test to finish first)
[21:17] <sinzui> leonardr: I am looking now
[21:17] <leonardr> great
[21:18] <lifeless> thumper: ppr over a month should be a decent indicator
[21:18] <lifeless> thumper: https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-monthly-pageids.html
[21:30] <sinzui> leonardr: r=me with these trivial changes: http://pastebin.ubuntu.com/580310/
[21:32] <huwshimi> Morning
[21:33] <poolie> hi huwshimi
[21:33] <poolie> hi flacoste?
[21:34] <flacoste> hi poolie
[21:34] <flacoste> poolie: call time?
[21:34] <huwshimi> jml: Good evening
[21:35] <jml> huwshimi: hi
[21:35] <jml> huwshimi: I'll just grab some yoghurt & will be right with you.
[21:35] <huwshimi> jml: Sure
[21:43] <poolie> flacoste, yes, hi
[21:44] <flacoste> poolie: i'm on skype
[21:45] <poolie> hm
[21:46] <thumper> sinzui: still around?
[22:01] <wgrant> :( We are turning into Java.
[22:01] <lifeless> wgrant: we are?
[22:02] <wallyworld> wgrant: my irc client decided to disconnect so i missed the lead up to your java comment - why do you say we are turning into java?
[22:02] <wgrant> lifeless: We now have external projects included in our source tree with Launchpad-specific changes.
[22:02] <lifeless> wgrant: which project?
[22:02] <wallyworld> why is that java-esque?
[22:02] <wgrant> lib/lp/contrib/javascript/yui3-gallery/gallery-accordion/
[22:03] <wgrant> wallyworld: Java projects are notorious for including all their dependencies in their trees.
[22:03] <lifeless> move it to lazr-js ?
[22:03] <lifeless> wgrant: so are c++, C, python, ruby projects IME
[22:03] <wallyworld> wgrant: not the ones i've worked on :-)
[22:03] <jelmer> lifeless: btw, did the multiple versions of python packages discussion go anywhere?
[22:04] <wallyworld> bac: hi brad, are you able to +1 the recent mp you looked at for me now that i have done the requested changes?
[22:04] <bac> wallyworld: thanks for the reminder.  i'll look now.
[22:04] <wallyworld> thanks
[22:04] <lifeless> jelmer: no, I didn't manage to get the thought leaders to step out of their worldview
[22:04] <jelmer> lifeless: :(
[22:04] <lifeless> jelmer: feel free to jump in on debian-python
[22:05] <bac> wallyworld: done.
[22:05] <wallyworld> bac: thank you!
[22:05] <lifeless> I've shelved it for now, will probably come back to it, or perhaps we should migrate more massively and just avoid the issue entirely
[22:09] <wgrant> lifeless: The big problems for Ubuntu are Java projects. And Chromium.
[22:35] <poolie> hi wgrant, lifeless
[22:35] <lifeless> hi poolie
[22:36] <poolie> did i understand you correctly in my last message on bug 716174?
[22:36] <_mup_> Bug #716174: api error messages should be machine-readable <Launchpad itself:Triaged> < https://launchpad.net/bugs/716174 >
[22:37] <sinzui> hi huwshimi do you want o mumble today?
[22:38] <wgrant> Morning poolie.
[22:42] <lifeless> poolie: oh bah, I was reading mail and just closed it again
[22:42] <lifeless> poolie: hadn't seen your irc comment
[22:42] <lifeless> poolie: we may be talking past each other; voice?
[22:45] <thumper> james_w: ping
[22:46] <poolie> lifeless, sure!
[22:47] <poolie> pots or skype or mumble?
[22:48] <lifeless> skype is easiest
[22:49] <thumper> mwhudson: can you think of any current blueprints that have linked bugs?
[22:49] <mwhudson> thumper: not off the top of my head, no
[22:49] <thumper> hmm... ok
[22:49] <thumper> mwhudson: did you take a look at the vocab branch?
[22:49] <mwhudson> thumper: yes, bzr is distracting me
[22:49] <mwhudson> thumper: i'll have a review in a few minutes
[22:51] <huwshimi> sinzui: Sorry I completely missed your message
[22:51] <thumper> mwhudson: ok, thanks
[22:52] <huwshimi> sinzui: Have you already finished?
[23:00] <mwhudson> thumper: how can  _is_valid_candidate be called with something that isn't a spec?
[23:01] <thumper> mwhudson: shitty url traversal?
[23:01] <thumper> mwhudson: it handled the None case well
[23:01] <thumper> probably never
[23:01] <mwhudson> thumper: did you look at how _spec_from_url works?
[23:01] <mwhudson> (it's horrible, yes, but it will only return a spec)
[23:01] <thumper> only briefly cause it looked shitty
[23:02] <thumper> probably paranoia on my part
[23:02] <mwhudson> ok
[23:02] <mwhudson> can you remove that please? :)
[23:02] <thumper> I originally had just the none check
[23:02] <thumper> sure
[23:04] <poolie> i'm getting a 'please try again' page talking to lp
[23:04] <poolie> in fact https://bugs.launchpad.net/bzr/+bugs?field.searchtext=winsshd&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= is per
[23:04] <poolie> sistently timing out
[23:06] <wgrant> poolie: Timing out, or "please try again"ing?
[23:06] <wgrant> It's working for me.
[23:06] <wgrant> (although it's slow... 9s)
[23:07] <wgrant> We are mid-rollout, but it shouldn't happening that much...
[23:12] <mwhudson> thumper: revewied
[23:12] <thumper> mwhudson: thanks
[23:13] <mwhudson> thumper: usual nit-picking :)
[23:13] <thumper> :)
[23:19] <poolie> wgrant, both oopsing and giving the proxy error page
[23:19] <poolie> huwshimi, just a thought on the private bug thing
[23:20] <poolie> which is that the stackoverflow ribbons are point-in-time notifications, and after you've read them it's reasonable to dismiss them
[23:20] <poolie> whereas if something's a static property of a bug
[23:20] <poolie> and potentially coming up on every bug page you look at all day
[23:20] <lifeless> poolie: back
[23:20] <poolie> it may get annoying
[23:21] <poolie> lifeless, let me just finish this post
[23:23] <poolie> wgrant, timed out again
[23:23] <poolie> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1899K1764
[23:23] <wgrant> Thanks.
[23:23] <wgrant> Confirmed.
[23:25]  * wgrant is waiting for it to sync.
[23:30] <poolie> lifeless, curl -v https://code.staging.launchpad.net/~maria-captains/bzr/diffoptions/+merge/52325
[23:32] <poolie> cOOPS-1899STAGING65
[23:32] <poolie> OOPS-1899STAGING65
[23:40] <wgrant> lifeless: I think your FTI changes have made bug searches significantly slower. See poolie's OOPS (it's finally synced)
[23:41] <lifeless> poolie: 'X-Lazr-OopsId
[23:41] <lifeless> wgrant: that would be win, wouldn't it
[23:42] <lifeless> wgrant: Time: 3684.797 ms (staging)
[23:43] <wgrant> lifeless: The cost estimate with Bug.fti is 10x the one with BugTask.fti.
[23:45] <wgrant> I guess it has to load a lot more Bugs.
[23:45] <lifeless> wgrant: which is freaking odd as it was an || before
[23:45] <lifeless> wgrant: 2606.15..2606.16
[23:46] <lifeless> (I'm looking at the count(*) to start with
[23:46] <wgrant> I am too.
[23:46] <lifeless> Index Scan using bug_fti on bug  (cost=0.00..2306.35 rows=42 width=12) (actual time=134.970..469.008 rows=2 loops=1)
[23:46] <lifeless>                Index Cond: ((fti)::tsvector @@ '''winsshd'''::tsquery)
[23:47] <wgrant> Oh, it's doing that first?
[23:47] <wgrant> On mawson it does bugtask first, and both are <400ms once the cache is hot.
[23:48] <lifeless> yes, it does bug_fti first
[23:50] <wgrant>          ->  Index Scan using bug_pkey on bug  (cost=0.00..54.26 rows=1 width=12) (actual time=0.015..0.015 rows=0 loops=2709)
[23:50] <wgrant>                Index Cond: (bug.id = public.bugtask.bug)
[23:50] <wgrant>                Filter: ((bug.duplicateof IS NULL) AND ((bug.fti)::tsvector @@ '''winsshd'''::tsquery) AND ((NOT bug.private) OR (SubPlan 1)))
[23:52] <lifeless>          ->  Index Scan using bugtask__product__bug__key on bugtask  (cost=0.00..6.24 rows=1 width=16) (actual time=0.033..0.034 rows=1 loops=2)
[23:52] <lifeless>                Index Cond: ((public.bugtask.product = 1186) AND (public.bugtask.bug = bug.id))
[23:52] <lifeless>                Filter: ((public.bugtask.status = 10) OR ((public.bugtask.date_incomplete IS NOT NULL) AND (public.bugtask.status = 15)) OR (public.bugtask.status = 15) OR (public.bugtask.status = 20) OR (public.bugtask.status = 21) OR (public.bugtask.status = 22) OR (public.bugtask.status = 25))
[23:52] <lifeless> wgrant: \d bug
[23:52] <lifeless> wgrant: \di+ bug_fti
[23:52] <wgrant> lifeless:     "bug_fti" gist (fti)
[23:53] <wgrant> No similar index on bugtask_fti, though...
[23:53] <wgrant>  Schema |  Name   | Type  |  Owner   | Table |  Size  | Description
[23:53] <wgrant> --------+---------+-------+----------+-------+--------+-------------
[23:53] <wgrant>  public | bug_fti | index | postgres | bug   | 575 MB |
[23:53] <lifeless> wgrant: indeed, it was missing on prod a few months back
[23:53] <lifeless> wgrant: one of the first hints that fti was whack
[23:54] <lifeless> wgrant: the query doesn't use bugtask_fti now, does it ?
[23:55] <wgrant> lifeless: I doubt it.
[23:55] <wgrant> Well, the new query couldn't use it.
[23:55] <wgrant> The old one could have. I don't know if it did.