[00:18] <wgrant> baaaaaaah
[00:19] <wgrant> No CREATE TABLE IF NOT EXISTS in 8.4
[00:19] <wgrant> Added in 9.1 :(
[00:21] <elmo> WGRANT, Y U NO CREATE TABLE IF NOT EXISTS
[00:22] <wgrant> Heh
[00:32] <wgrant> lifeless_: the temp journal flush is very slow because it calls a function for each row. Fixing it to do a bulk insert is still fairly slow, because of the bugsummaryjournal FKs and TRUNCATE being slower than DELETE for small tables like this.
[00:33] <StevenK> wgrant: I'm questioning if my IBug leak fix is really QAable :-/
[00:33] <wgrant> StevenK: Did the test suite pass?
[00:33] <wgrant> (yes, it did => qa-ok)
[00:33] <wgrant> Or untestable
[00:34] <StevenK> It's on qas, so both ec2 and buildbot did
[00:34] <wgrant> Indeed.
[00:48] <lifeless_> wgrant: the flush shouldn't block journal inserts though
[00:48] <wgrant> lifeless_: The flush is called as part of the trigger.
[00:48] <wgrant> temp journal flushes to journal within the trigger
[00:48] <wgrant> Then garbo rolls up the journal
[00:50] <lifeless_> ah, skimmed over the word temp
[00:50] <lifeless_> thanks for debugging
[02:15] <lifeless> not bad - 386 Exceptions
[02:49] <wgrant> lifeless: 100 more than normal :(
[02:49] <wgrant> hwdb crap, probably
[02:50] <lifeless> also 50 from oops-tools thyself
[02:50] <lifeless> touch 500.html -> -50
[02:50] <wgrant> Heh
[02:50] <wgrant> Yeah
[02:53] <wallyworld_> wgrant: what's the timeframe for the landing of the code to mirror data into the new access policy schema?
[02:53] <wgrant> wallyworld_: I expect the trigger will land in a few hours (just waiting for a branch to be merged from stable to db-devel)
[02:54] <wgrant> wallyworld_: But that doesn't include the sampledata updates.
[02:54] <wgrant> (and we need to create AccessPolicies on prod and dev before the triggers will do much)
[02:54] <wallyworld_> ok. i have a couple of options to do next. i'll wait for this stuff
[02:54] <lifeless> just don't use sampledata
[02:54] <lifeless> its deprecated anyhow
[02:55] <wallyworld_> i wasn't going to use sample data
[02:55] <lifeless> ah cool, I was misled :P
[02:55] <wgrant> lifeless: We have to update the sampledata
[02:55] <wgrant> Or none of the private bugs will be valid.
[02:55] <lifeless> wgrant: how many tests use private bug sampledata?
[02:55] <wgrant> Probably quite enough :(
[02:56] <lifeless> might be worth a check
[02:56] <wgrant> sampledata is also still critical for test performance, unfortunately.
[02:56] <wallyworld_> lifeless: above, i was talking about waiting for the triggers to land, not sample data
[02:57] <wgrant> wallyworld_: https://code.launchpad.net/~wgrant/launchpad/bug-mirror-access-policies/+merge/94722 is the MP, and it has tests which use normal factory methods.
[02:58] <wallyworld_> thanks
[02:59] <lifeless> wallyworld_: yes, I was misled by wgrant bringing in sampledata to the convo
[02:59] <wallyworld_> np :-)
[02:59] <wgrant> lifeless: Well, for most purposes this isn't useful without the sampledata updates.
[02:59] <wgrant> Perhaps for wallyworld it is :)
[03:01] <wallyworld_> perhaps
[03:01] <lifeless> wgrant: I would love it if you check and see what the effort to delete the private bugs would be from the sampledata
[03:02] <wgrant> lifeless: I have a sampledata vs. factory-ng battle experiment planned for next week.
[03:04] <lifeless> you had me at battle
[03:07] <wgrant> lifeless: Well, the current factory is reasonably awkward and extremely slow, so I'm going to attempt to improve it.
[03:13] <wallyworld_> lifeless: there needs to be some tal for the basic page chrome. the other tal that's there was from an earlier branch where john just put in sample data as a placeholder. it's totally replaced at runtime. i still see some value in retaining that
[03:38] <lifeless> wallyworld_: so, I'd love us to get rid of the duplication
[03:38] <lifeless> wallyworld_: how is up to you :)
[03:39] <StevenK> lifeless: Your DSL is still misbehaving
[03:39] <StevenK> ?
[03:41] <lifeless> StevenK: I sispect so
[04:34] <StevenK> wgrant: O hai, Mr OCR.
[04:35] <wgrant> Lies.
[04:36] <wgrant> wut
[04:36] <wgrant> how is it bad
[04:36] <wgrant> I ran it over THE WHOLE TREE two months ago
[04:37] <StevenK> Tell me about it
[04:37] <StevenK> I only thought to because Aaron added a whole of bunch of 'from x import (\nsingle module,\n)'
[04:45] <wgrant> Bah
[04:45] <wgrant> One of them is mine :(
[04:45] <StevenK> I also didn't notice the problematic codehosting import
[04:45] <StevenK> In the diff
[04:46] <wgrant> Most of those are now handled.
[04:46] <wgrant> by a # FIRST comment.
[04:46] <StevenK> Right.
[04:46]  * StevenK notes one is wrong and reverts it
[04:46] <wgrant> Oh?
[04:46] <StevenK> lib/lp/services/librarianserver/testing/server.py
[04:47] <wgrant> What's wrong with it, beyond the superfluous canonical import?
[04:47] <StevenK> It's been moved to the wrong place.
[04:47] <wgrant> It shouldn't exist in the first place.
[04:47] <wgrant> There's a few others around too.
[04:47] <wgrant> I've listed in them in my review that I'm about to finish.
[04:48] <StevenK> Right
[04:48] <wgrant> But in general anything importing anything from canonical is wrong, unless it's using __file__ to find icing.
[04:48] <StevenK> lib/lp/services/librarianserver/testing/server.py makes use of canonical.__file__
[04:49] <wgrant> Ah, it's possible they all do.
[04:49] <wgrant> But it seems unlikely.
[04:49] <wgrant> If they do still need them, fix the formatter to know that canonical is local.
[04:49] <wgrant> Reviewed, anyway.
[04:49] <StevenK> I've already pushed the change that does
[04:49] <wgrant> Hah
[04:49] <wgrant> Look at how it uses canonical.__file__
[04:49] <wgrant> 'tis stupid.
[04:49] <wgrant> Pls fix.
[04:50] <wgrant> :q
[04:50] <StevenK> To do what instead?
[04:50] <wgrant> It uses canonical.__file__ so it can get the root of the tree.
[04:50] <wgrant> Possibly use lp.__file__ instead.
[04:51] <wgrant> Most other cases are probably similar.
[04:51] <wgrant> Might as well wipe them all out now.
[04:51] <wgrant> canonical.launchpad.__file__ is usually valid, though, as it's used to find icing.
[05:10] <StevenK> wgrant: What do you think about http://pastebin.ubuntu.com/860097/ ?
[05:14] <wgrant> StevenK: Looks reasonable.
[05:16] <StevenK> wgrant: Recommendation for the use of canonical.__file__ in lib/lp/services/config/doc/canonical-config.txt?
[05:17] <wgrant> StevenK: s/canonical/lp/g
[05:21] <StevenK> steven@liquified:~/launchpad/lp-branches/format-imports-cleanup% bzr grep canonical.__file__ | wc -l
[05:21] <StevenK> 0
[05:25] <stub> wgrant, StevenK: I think config.root gets you the root better
[05:26] <wgrant> stub: It's testing config.root.
[05:26] <stub> oh :)
[05:26] <wgrant> I was going to say the same thing until I actually read the test.
[05:39] <wgrant> zomg
[05:39] <wgrant> it works
[05:40] <StevenK> Which bit?
[05:43] <wgrant> Bug searches without any joins at all.
[05:43] <wgrant> (including for security checks, which were the big remaining pain)
[05:45] <lifeless> wgrant: interesting
[05:48] <wgrant> Still waiting for DF to finish regenerating the data, but the plan looks good.
[05:55] <lifeless> whats the schema for that ?
[05:57] <lifeless> wgrant: ^
[05:58] <wgrant> Include AccessPolicyArtifact.policy and AccessArtifactGrant.grantee in arrays on BugTaskFlat. Not feasible to index, but a whole lot faster in a scan than joining against BugSubscription.
[05:58] <wgrant> Because we can calculate the policies and grantees to match against once at the start of the query.
[05:58] <lifeless> interesting
[05:58] <lifeless> I'm very glad you're spending time trying different htings
[06:02] <wgrant> Hmm
[06:03] <wgrant> Well, that's better than expected.
[06:03] <wgrant>  Seq Scan on bugtaskflat  (cost=0.00..958352572.67 rows=193926 width=4) (actual time=0.020..970.982 rows=91164 loops=1)
[06:03] <wgrant>  Total runtime: 1026.971 ms
[06:03] <wgrant> So even completely unindexed, as long as it's hot it only takes a second to do a full scan.
[06:03] <wgrant> I think that is a reasonable next victory.
[06:03] <wgrant> 'cause this table should be pretty damn hot.
[06:04] <stub> GIN and GIST indexes support array operations. Landscape are using them.
[06:04] <wgrant> stub: Yeah, but it's not too useful here.
[06:04] <stub> Not sure if they are the operators you need though (IS IN etc.)
[06:04] <stub> k
[06:04] <wgrant> It's possible we can get something out of BitmapAnding
[06:04] <wgrant> But in general this shouldn't be too bad.
[06:04] <wgrant> Because the arrays are all small
[06:05] <wgrant> Normally only one policy, and <5 grantees.
[06:05] <wgrant> The index may provide significant benefit if you're unable to see most of the bugs, eg. in a private project.
[06:05] <wgrant> But we'll see.
[06:06] <stub> Still pulling up 91k rows, which is a lot even if half the estimate
[06:06] <wgrant> (the above is a COUNT(*) of a default Ubuntu bug search, with bugs visible to me)
[06:06] <wgrant> So it's meant to be 91k rows
[06:06] <stub> ok
[06:06] <stub> And better than what we already have for sure :)
[06:06] <wgrant> Oh yes.
[06:06] <wgrant> Oh
[06:06] <wgrant> And it's still treating the CTEs as correlated.
[06:06] <wgrant> Huh
[06:06] <wgrant> It's not meant to do that...
[06:07] <wgrant> Ah, no it's not, just the top-level.
[06:24] <wgrant> need more rams
[06:26] <wgrant> Bah, forgot to include tags in this rebuild.
[06:29] <wgrant> Hmm
[06:29] <wgrant> But ideally need stats for tags
[06:29] <wgrant> Which means forcing them into a tsvector AFAIK :(
[06:32] <wgrant> Anyway, this will hopefully be fast enough for now, and we can easily garbo up a new fact table online later.
[06:34] <wgrant> Hmm, under-selective FTI is slow, even with GIN. Possibly just that DF can't really fit the full indexes and tables in cache.
[07:12]  * wgrant declares the experiment a great success and shall propose it tomorrow.
[07:12] <lifeless> awesome
[07:13] <lifeless> wgrant: if you have a test script I can run it on asuka
[07:17] <wgrant> lifeless: Are you around tomorrow?
[07:17] <lifeless> a
[07:17] <lifeless> yes
[07:29] <wgrant> lifeless: Great, will throw stuff at you then.
[07:36] <nigelb> 24
[07:36] <nigelb> ugh
[08:51] <lifeless> StevenK: perhaps 'make' should format imports
[08:51] <wgrant> That's a bad, bad precedent I think.
[08:55] <adeuring> good morning
[08:55] <wgrant> Lint could, though.
[08:55] <wgrant> Morning adeuring.
[08:59] <lifeless> wgrant: also, please to try doubling our data set with the flatbugtask perf tests
[08:59] <lifeless> wgrant: [estimate behaviour if we sit on it for a while after deploying]
[08:59] <wgrant> fuuuuu
[08:59] <wgrant> but OK
[08:59] <wgrant> still need to set up proper indexes and such tomorrow.
[09:00] <wgrant> But even with no indices it's largely better than we have now.
[09:00] <wgrant> Even on dogfood.
[09:00] <wgrant> Which can't fit the full table and indices in RAM
[09:00] <wgrant> (well, it could if there was nothing else running, but there is)
[09:01] <lifeless> yeah
[09:01] <lifeless> If you can honestly state you're not worried about behaviour with our dataset doubled, I will take your word on it.
[09:01] <lifeless> My point is that we need to make /some/ thought and assessment about it.
[09:01] <wgrant> A lot of sort and tag/fti filter cases still degrade to an in-memory sort, so yeah, I'm a little worried.
[09:02] <wgrant> But I've looked at it a bit.
[09:02] <wgrant> fti often turns into a BitmapAnd, which drops order, so when the result is large it gets bad.
[09:02] <wgrant> But it's still not more than 1.3s hot, even when it's sorting the whole set.
[09:03] <wgrant> I'm going to look tomorrow morning at throwing tags into the first iteration.
[09:03] <wgrant> But I don't have much hope because array stats aren't implemented.
[09:03] <wgrant> And stats matter for Ubuntu's tags.
[09:04] <mrevell> Mornin'
[09:04] <wgrant> Although it may not be so bad to always do a full scan for tag searches if they're inline.
[09:04] <nigelb> Mornin' mrevell
[09:05] <czajkowski> aloha
[09:05] <wgrant> Still, it no longer feels like bug search performance is entirely hopeless.
[09:10] <danhg> aloha vera
[11:24] <rick_h_> morning
[12:37] <salgado> StevenK, hey, do you know when you might have some time to finish the review of https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-migration-script/+merge/93883?  I'm happy to bug somebody else if you won't have time for it soon
[12:53] <mabac> I've proposed  the Work items UI if anyone is up for reviewing that: https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-widget/+merge/94790 :)
[14:31] <deryck> adeuring, abentley, rick_h_ -- I'm stuck on the phone with my bank. Can we hold standup until this completes please?
[14:31] <adeuring> deryck: np
[14:31] <rick_h_> deryck: gotcha
[14:31] <abentley> deryck: sure thing.
[14:32] <deryck> thanks, guys.  sorry.
[14:43] <czajkowski> lifeless: when you're about can you perhaps have a look over https://bugs.launchpad.net/launchpad/+bug/942523  please ?
[14:43] <_mup_> Bug #942523: [Wish] Add a section Trophees in launchpad profile with the Trophee linked to Launchpad & Ubuntu Community <accomplishments> <launchpad> <ubuntu> <Launchpad itself:New> < https://launchpad.net/bugs/942523 >
[14:45] <deryck> adeuring, abentley, rick_h_ -- sorry, almost done. let's hangout in 5.
[14:46] <abentley> deryck: ack
[14:52] <deryck> adeuring, abentley, rick_h_  -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
[15:18] <sinzui> jcsackett, do you have time to mumble
[15:30] <czajkowski> jtv: are you about?
[15:30] <jtv> czajkowski: I am
[15:31] <czajkowski> jtv: I dont fully understand the bug here. https://bugs.launchpad.net/launchpad/+bug/942645
[15:31] <_mup_> Bug #942645: Credit strings show up untranslated for kcm-gtk <Launchpad itself:New> < https://launchpad.net/bugs/942645 >
[15:31] <jtv> czajkowski: you know what "translation credit strings" are?
[15:32] <czajkowski> jtv: yes
[15:32] <jtv> Launchpad pretends that it has translations for those, but actually those are generated on the fly.
[15:33] <czajkowski> ah ok
[15:33] <jtv> For some reason, in this case, the Launchpad UI lapses in its pretense that it has translations for these strings.
[15:34] <jtv> If “lapses” is the right word.
[15:35] <jtv> Argh.  Look at the computed percentages here!  That ought to be fixed: https://translations.launchpad.net/ubuntu/precise/+source/kcm-gtk/+pots/kcm-gtk/de/+details
[15:36] <jtv> czajkowski: if memory serves, we had some mechanism for preventing this — in which case this needs investigation for which unfortunately I do not have time.  But it's also possible that this was never solved, in which case there's probably a duplicate bug.
[15:37] <czajkowski> jtv: nods no worries shall investigate further
[15:37] <czajkowski> thank you for the help
[15:37] <jtv> Thanks.
[16:06] <abentley> adeuring: I just noticed your lazr.jobrunner branch is lp:~adeuring/launchpad/lazr.jobrunner, not lp:~adeuring/lazr.jobrunner/foo.  Intentional?
[16:06] <adeuring> abentley: usual sloppyness...
[16:07] <abentley> adeuring: Oh, okay.
[16:23] <jcsackett> sinzui: changes to enum branch pushed.
[16:23] <sinzui> fab
[16:27] <sinzui> jcsackett, r=me
[16:27] <jcsackett> sinzui: thanks.
[16:48] <abentley> jcsackett: do you have a sec?
[16:48] <jcsackett> abentley: sure.
[16:48] <jcsackett> what's up?
[16:48] <abentley> You're a contributor to ec2 land, and I'm trying to harmonize it with lp-land.
[16:49] <abentley> jcsackett: A difference is that ec2 land updates the commit message.  Do you find that useful?
[16:49] <jcsackett> abentley: you mean the bit about setting the [r=] tags?
[16:49] <jcsackett> or the commit message option you can pass it?
[16:50] <abentley> jcsackett: I mean that it sets the [r=] tags etc on the merge proposal.
[16:50] <jcsackett> abentley: i find that useful, yes, in that i would never remember to set those tags myself.
[16:50] <jcsackett> abentley: i thought lp-land does the same thing, though ...
[16:51] <abentley> jcsackett: You wouldn't have to set them yourself.
[16:51] <abentley> jcsackett: It would already use them for submitting the proposal.
[16:51] <abentley> jcsackett: It's just whether it rewrites them onto the merge proposal.
[16:52] <jcsackett> abentley: oh! no, i do not find that useful. i actually find it kind of odd that the MP gets tagged with that stuff outside the actual landing.
[16:53] <jcsackett> and if you have an error with an ec2 land and run it again, i have noticed you can end up with two sets of the [r=] tags. which is vexing.
[16:53] <abentley> jcsackett: Really?  It was supposed to avoid duplication, but I guess it's buggy.
[16:53] <abentley> jcsackett: Okay, I'll leave that functionality out.
[16:54] <jcsackett> abentley: ok.
[16:54] <abentley> jcsackett: thanks.
[16:54] <jcsackett> abentley: you're welcome.
[17:55] <lifeless> czajkowski: hi; crazy bug yes.
[17:56] <czajkowski> lifeless: one for you then :)
[17:58] <lifeless> czajkowski: I'd just mark it low triaged
[17:59] <czajkowski> lifeless: ah so it may happen ?
[17:59] <lifeless> czajkowski: if someone were to add support, with appropriate security, and maintain it, we'd (probably) have no problem doing it, though we wouldn't do it ourselves
[17:59] <lifeless> probability 0 that someone will
[18:00] <lifeless> mrevell as product manager can say 'no way never' if he likes :)
[18:00] <czajkowski> heh
[18:01] <lifeless> I get to set the bar we need to reach when we do something, but for /what/ we do, thats up to gentle suasion!
[18:01] <czajkowski> grand job
[18:13] <lifeless> czajkowski: you should never be concerned about triaging wrongly: the worst that can happen is someone can use the [formal] escalation process to request the thing be prioritised
[18:13] <lifeless> czajkowski: if its wrong in a simpler manner (e.g. is a regression / isn't or whatever, one of your peers will probably just fix it up)
[18:13] <czajkowski> lifeless: true, but with that I jst wondered would there be further discussion on the topic given the amount of blogging about the topic and other mails
[18:13] <lifeless> oh there probably will be
[18:14]  * lifeless sadfaces
[18:23] <james_w> would someone help us out and do a release of oops_datedir_repo please?
[18:23] <james_w> I don't want to have to depend on the branch in another oops module
[18:24] <lifeless> sinzui: hey
[18:25] <sinzui> hi lifeless
[18:25] <lifeless> sinzui: I am sure you will know this
[18:25] <lifeless> sinzui: why do I get messages 'foo has deactivated registry from bar' every day
[18:25] <lifeless> james_w: sure
[18:25] <sinzui> :)
[18:25] <lifeless> sinzui: is it 'merge' or 'delete' ?
[18:25] <sinzui> I was thinking about that this morning
[18:26] <sinzui> It is delete
[18:26] <james_w> lifeless, thanks
[18:26] <lifeless> I need to write code; this week has had no code writing and I'm getting so very very deprived
[18:27] <lifeless> sinzui: so for delete, I'm guessing that that person wasn't involved at all, but the notification happens automagically
[18:27] <sinzui> There is some step I want to avoid in the merge process when merging with ~registry. I do not know what case is.
[18:27] <sinzui> lifeless, they do, but something is out of order...
[18:27] <lifeless> sinzui: separately, there was a bug we found where an admin approved a membership but the notification claimed someone else did
[18:27] <lifeless> sinzui: I wonder if it could be the same thing
[18:28] <sinzui> We remove super and subteams when deleting. by the point of the merge...there should be no memberships that could trigger that email
[18:28] <lifeless> well, a component of the same confusion
[18:28] <lifeless> sinzui: there is an owner
[18:28] <lifeless> sinzui: and presumably a creator. I wonder if we have fallback code
[18:28] <lifeless> crazy cracy fallback code
[18:29] <sinzui> lifeless, the person we see in the email is the one that initiated the merge job that performs the delete
[18:29] <lifeless> sinzui: ok, so 'foo deleted team bar' is what the mail should say (and it should perhaps go to the old members only)
[18:29] <sinzui> lifeless, No
[18:30]  * lifeless doth not understand
[18:30] <sinzui> There is a step missing. Only the owner user doing the action should get an email...but that is not the email we are seeing
[18:30] <sinzui> I think the act of merge/delete queue *2* jobs
[18:31] <sinzui> 1st job queues the membership changes which is the email we are seeing.
[18:31] <lifeless> sinzui: wouldn't it be confusing for the members to have the team disappear? That they were part of ?
[18:32] <sinzui> 2nd job queue the merge. The merge happens first, so that the email go out and report ~registry was removed when the team was never a member
[18:32] <lifeless> sinzui: ah, I see, you're saying that yes the members get a notification (perhaps 'removed from team' which is a little misleading); and separately we purge it
[18:34] <sinzui> lifeless, I looked at the staging memberships of the people reported in the email. They are the team owners and the team is not related to ~registry. So the email really is about ~fnord was deactivated from ~pting
[18:35] <lifeless> sinzui: unless registry gets put in fpting first
[18:35] <sinzui> lifeless, this is the *very odd* part merge will not take place is any memberships exist. I assume team participation are indeed complete, so the emails should be impossible to send
[18:37] <lifeless> james_w: done
[18:37] <james_w> thanks lifeless
[18:37] <lifeless> james_w: can you do me a favour and close off any fix-committed bugs?
[18:38] <james_w> zero open bugs
[18:38] <james_w> done!
[18:39] <james_w> plus moving LP to pymongo's bson and getting rid of the compatibility code is probably a good idea, given that the tests in datedir and amqp aren't checking against both implementations
[18:39] <james_w> one inconsistency I've found is that pymongo refuses to serialize things it doesn't know about
[18:40] <james_w> so you can't just put arbitrary objects in the oops
[18:40] <james_w> I don't know what the expected behaviour is there
[18:41] <lifeless> that would be nice
[18:41] <lifeless> we had a nasty bug where we tossed something bson didn't understand in
[18:41] <lifeless> and it just skipped it
[18:41] <lifeless> then oops-tools barfed
[18:41] <james_w> ah
[18:42] <james_w> skipped is clearly the wrong thing to do
[18:42] <james_w> I assumed it did repr or something
[18:49] <lifeless> sinzui: so, I think we should move all of _merge into the job
[18:50] <lifeless> sinzui: there could be a lot of work there, may need multiple transactions to avoid concurrency issues, and there is no UI except for 'yay I did it' or 'boo cannot be done'
[18:52] <lifeless> sinzui: (and, I think we should notify about deletes, but thats an orthogonal discussion)
[18:52] <james_w> the options seem to be to repr every value, or try and bsonify every value individually and repr if it fails
[18:53] <james_w> (we're trying to add task *args and **kwargs to the oops, and we don't know the types up front)
[18:53] <lifeless> james_w: I thought you said pymongo errors ?
[18:53] <james_w> it does
[18:53] <james_w> and I don't want it to
[18:53] <lifeless> james_w: I think that is great
[18:53] <james_w> I want to put the data in without caring about the type in this case
[18:54] <lifeless> safe_unicode them all ?
[18:54] <lifeless> I suspect that (with the exception of collections) is probably going to DWIM for you
[18:55] <james_w> where does safe_unicode live?
[18:55] <lifeless> createhooks
[18:57] <james_w> good idea, /me switches
[19:22] <rick_h_> lifeless: ping
[19:22] <lifeless> hi
[19:22] <rick_h_> howdy, I'm trying to figure out your comment in https://code.launchpad.net/~rharding/launchpad/watch_jsbuild/+merge/94379
[19:22] <rick_h_> about both the make target and buidlout template?
[19:23] <rick_h_> can you elaborate for the buildout impaired what I've done wrong/correct way to fix?
[19:23] <deryck> lifeless, hi.  I'll get in line behind rick_h_, but would love to get your review of a preload attrs for buglistings branch.
[19:24] <rick_h_> hah, my faster typing pays off
[19:25] <deryck> I let you win. ;)
[19:25] <rick_h_> I feel a monty python skit involving a black knight coming on
[19:29] <lifeless> deryck: url ?
[19:30] <lifeless> (OTP :P)
[19:30] <deryck> lifeless, https://code.launchpad.net/~deryck/launchpad/preload-tags-for-buglistings-901122/+merge/95023 (and thanks!)
[19:31] <lifeless> rick_h_: I made that comment on the initial diff
[19:31] <rick_h_> lifeless: ok, cool
[19:31] <lifeless> rick_h_: it looks sane now, but perhaps s/foo.py.in/foo.in/
[19:31] <rick_h_> lifeless: ok
[19:32] <lifeless> (e.g. I don't think the language is relevant for an executable interface)
[19:32] <rick_h_> right, ok nop
[19:32] <rick_h_> np that is
[21:42] <lifeless> deryck: reviewed
[21:43] <lifeless> with 2 comments (second coming in a sec)
[21:45] <deryck> lifeless, ok, thanks, man.
[21:52] <jcsackett> sinzui: i will be a few minutes late to standup.
[21:53] <sinzui> okay
[21:53] <thumper> hi people
[21:53] <thumper> is launchpad still using windmill?
[21:56] <lifeless> nup
[21:56] <lifeless> died in a fire
[21:57] <james_w> someone should put the smackdown on windmill on -tech
[21:59] <deryck> lifeless, so I've got the last branch up for review, but you don't have to review it now.  I'll add the scaling test in that final branch.
[21:59] <deryck> lifeless, but if you're curious: https://code.launchpad.net/~deryck/launchpad/adapt-badges-listing-item-901122/+merge/95063
[22:00] <deryck> thumper, we still have windmill tests lying around, with the hope they'll get ported to our new yuixhr framework.
[22:00] <deryck> thumper, but they haven't been running for some time.
[22:01] <deryck> if I ever need LOC credit for something I'm working on, I plan to delete them then. ;)
[22:03] <thumper> do what is the new magic?
[22:04] <lifeless> html5-browser
[22:06] <deryck> yeah, just plain ol' yui run headless with html5-browser.
[22:06] <deryck> I'm out guys.  catch you all later.
[22:51] <sinzui> wgrant, https://code.launchpad.net/~sinzui/launchpad/mailman-archive-0