| wgrant | baaaaaaah | 00:18 |
|---|---|---|
| wgrant | No CREATE TABLE IF NOT EXISTS in 8.4 | 00:19 |
| wgrant | Added in 9.1 :( | 00:19 |
| elmo | WGRANT, Y U NO CREATE TABLE IF NOT EXISTS | 00:21 |
| wgrant | Heh | 00:22 |
| 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:32 |
| 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:33 |
| StevenK | It's on qas, so both ec2 and buildbot did | 00:34 |
| wgrant | Indeed. | 00:34 |
| 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:48 |
| lifeless_ | ah, skimmed over the word temp | 00:50 |
| lifeless_ | thanks for debugging | 00:50 |
| === lifeless_ is now known as lifeless | ||
| lifeless | not bad - 386 Exceptions | 02:15 |
| wgrant | lifeless: 100 more than normal :( | 02:49 |
| wgrant | hwdb crap, probably | 02:49 |
| lifeless | also 50 from oops-tools thyself | 02:50 |
| lifeless | touch 500.html -> -50 | 02:50 |
| wgrant | Heh | 02:50 |
| wgrant | Yeah | 02:50 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| wallyworld_ | thanks | 02:58 |
| 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 :) | 02:59 |
| 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:01 |
| wgrant | lifeless: I have a sampledata vs. factory-ng battle experiment planned for next week. | 03:02 |
| lifeless | you had me at battle | 03:04 |
| wgrant | lifeless: Well, the current factory is reasonably awkward and extremely slow, so I'm going to attempt to improve it. | 03:07 |
| 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:13 |
| lifeless | wallyworld_: so, I'd love us to get rid of the duplication | 03:38 |
| lifeless | wallyworld_: how is up to you :) | 03:38 |
| StevenK | lifeless: Your DSL is still misbehaving | 03:39 |
| StevenK | ? | 03:39 |
| lifeless | StevenK: I sispect so | 03:41 |
| StevenK | wgrant: O hai, Mr OCR. | 04:34 |
| wgrant | Lies. | 04:35 |
| wgrant | wut | 04:36 |
| wgrant | how is it bad | 04:36 |
| wgrant | I ran it over THE WHOLE TREE two months ago | 04:36 |
| 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:37 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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. | 04:51 |
| StevenK | wgrant: What do you think about http://pastebin.ubuntu.com/860097/ ? | 05:10 |
| wgrant | StevenK: Looks reasonable. | 05:14 |
| StevenK | wgrant: Recommendation for the use of canonical.__file__ in lib/lp/services/config/doc/canonical-config.txt? | 05:16 |
| wgrant | StevenK: s/canonical/lp/g | 05:17 |
| StevenK | steven@liquified:~/launchpad/lp-branches/format-imports-cleanup% bzr grep canonical.__file__ | wc -l | 05:21 |
| StevenK | 0 | 05:21 |
| stub | wgrant, StevenK: I think config.root gets you the root better | 05:25 |
| 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:26 |
| wgrant | zomg | 05:39 |
| wgrant | it works | 05:39 |
| StevenK | Which bit? | 05:40 |
| wgrant | Bug searches without any joins at all. | 05:43 |
| wgrant | (including for security checks, which were the big remaining pain) | 05:43 |
| lifeless | wgrant: interesting | 05:45 |
| wgrant | Still waiting for DF to finish regenerating the data, but the plan looks good. | 05:48 |
| lifeless | whats the schema for that ? | 05:55 |
| lifeless | wgrant: ^ | 05:57 |
| 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 | 05:58 |
| wgrant | Hmm | 06:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| wgrant | Ah, no it's not, just the top-level. | 06:07 |
| === stub1 is now known as stub | ||
| wgrant | need more rams | 06:24 |
| wgrant | Bah, forgot to include tags in this rebuild. | 06:26 |
| wgrant | Hmm | 06:29 |
| wgrant | But ideally need stats for tags | 06:29 |
| wgrant | Which means forcing them into a tsvector AFAIK :( | 06:29 |
| wgrant | Anyway, this will hopefully be fast enough for now, and we can easily garbo up a new fact table online later. | 06:32 |
| 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. | 06:34 |
| * wgrant declares the experiment a great success and shall propose it tomorrow. | 07:12 | |
| lifeless | awesome | 07:12 |
| lifeless | wgrant: if you have a test script I can run it on asuka | 07:13 |
| wgrant | lifeless: Are you around tomorrow? | 07:17 |
| lifeless | a | 07:17 |
| lifeless | yes | 07:17 |
| wgrant | lifeless: Great, will throw stuff at you then. | 07:29 |
| nigelb | 24 | 07:36 |
| nigelb | ugh | 07:36 |
| lifeless | StevenK: perhaps 'make' should format imports | 08:51 |
| wgrant | That's a bad, bad precedent I think. | 08:51 |
| adeuring | good morning | 08:55 |
| wgrant | Lint could, though. | 08:55 |
| wgrant | Morning adeuring. | 08:55 |
| 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. | 08:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| czajkowski | aloha | 09:05 |
| wgrant | Still, it no longer feels like bug search performance is entirely hopeless. | 09:05 |
| danhg | aloha vera | 09:10 |
| === almaisan-away is now known as al-maisan | ||
| rick_h_ | morning | 11:24 |
| === danhg_ is now known as danhg | ||
| 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:37 |
| 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 :) | 12:53 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| 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:31 |
| deryck | thanks, guys. sorry. | 14:32 |
| 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:43 |
| deryck | adeuring, abentley, rick_h_ -- sorry, almost done. let's hangout in 5. | 14:45 |
| abentley | deryck: ack | 14:46 |
| deryck | adeuring, abentley, rick_h_ -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup | 14:52 |
| sinzui | jcsackett, do you have time to mumble | 15:18 |
| czajkowski | jtv: are you about? | 15:30 |
| jtv | czajkowski: I am | 15:30 |
| 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:31 |
| czajkowski | jtv: yes | 15:32 |
| jtv | Launchpad pretends that it has translations for those, but actually those are generated on the fly. | 15:32 |
| 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:33 |
| jtv | If “lapses” is the right word. | 15:34 |
| 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:35 |
| 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:36 |
| czajkowski | jtv: nods no worries shall investigate further | 15:37 |
| czajkowski | thank you for the help | 15:37 |
| jtv | Thanks. | 15:37 |
| === al-maisan is now known as almaisan-away | ||
| === salgado is now known as salgado-lunch | ||
| === danhg_ is now known as danhg | ||
| 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:06 |
| abentley | adeuring: Oh, okay. | 16:07 |
| jcsackett | sinzui: changes to enum branch pushed. | 16:23 |
| sinzui | fab | 16:23 |
| sinzui | jcsackett, r=me | 16:27 |
| jcsackett | sinzui: thanks. | 16:27 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| jcsackett | abentley: ok. | 16:54 |
| abentley | jcsackett: thanks. | 16:54 |
| jcsackett | abentley: you're welcome. | 16:54 |
| === deryck is now known as deryck[lunch] | ||
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| lifeless | czajkowski: hi; crazy bug yes. | 17:55 |
| czajkowski | lifeless: one for you then :) | 17:56 |
| lifeless | czajkowski: I'd just mark it low triaged | 17:58 |
| 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 | 17:59 |
| lifeless | mrevell as product manager can say 'no way never' if he likes :) | 18:00 |
| czajkowski | heh | 18:00 |
| 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:01 |
| === deryck[lunch] is now known as deryck | ||
| 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:13 |
| * lifeless sadfaces | 18:14 | |
| 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:23 |
| lifeless | sinzui: hey | 18:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| * 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:30 |
| 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:31 |
| 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:32 |
| 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:34 |
| 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:35 |
| 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:37 |
| james_w | zero open bugs | 18:38 |
| james_w | done! | 18:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| james_w | skipped is clearly the wrong thing to do | 18:42 |
| james_w | I assumed it did repr or something | 18:42 |
| lifeless | sinzui: so, I think we should move all of _merge into the job | 18:49 |
| 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:50 |
| 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:52 |
| 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:53 |
| lifeless | safe_unicode them all ? | 18:54 |
| lifeless | I suspect that (with the exception of collections) is probably going to DWIM for you | 18:54 |
| james_w | where does safe_unicode live? | 18:55 |
| lifeless | createhooks | 18:55 |
| james_w | good idea, /me switches | 18:57 |
| === almaisan-away is now known as al-maisan | ||
| 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:22 |
| 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:23 |
| rick_h_ | hah, my faster typing pays off | 19:24 |
| deryck | I let you win. ;) | 19:25 |
| rick_h_ | I feel a monty python skit involving a black knight coming on | 19:25 |
| lifeless | deryck: url ? | 19:29 |
| lifeless | (OTP :P) | 19:30 |
| deryck | lifeless, https://code.launchpad.net/~deryck/launchpad/preload-tags-for-buglistings-901122/+merge/95023 (and thanks!) | 19:30 |
| 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:31 |
| 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 | 19:32 |
| === al-maisan is now known as almaisan-away | ||
| lifeless | deryck: reviewed | 21:42 |
| lifeless | with 2 comments (second coming in a sec) | 21:43 |
| === matsubara is now known as matsubara-afk | ||
| deryck | lifeless, ok, thanks, man. | 21:45 |
| jcsackett | sinzui: i will be a few minutes late to standup. | 21:52 |
| sinzui | okay | 21:53 |
| thumper | hi people | 21:53 |
| thumper | is launchpad still using windmill? | 21:53 |
| lifeless | nup | 21:56 |
| lifeless | died in a fire | 21:56 |
| james_w | someone should put the smackdown on windmill on -tech | 21:57 |
| 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 | 21:59 |
| 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:00 |
| deryck | if I ever need LOC credit for something I'm working on, I plan to delete them then. ;) | 22:01 |
| thumper | do what is the new magic? | 22:03 |
| lifeless | html5-browser | 22:04 |
| deryck | yeah, just plain ol' yui run headless with html5-browser. | 22:06 |
| deryck | I'm out guys. catch you all later. | 22:06 |
| sinzui | wgrant, https://code.launchpad.net/~sinzui/launchpad/mailman-archive-0 | 22:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!