| cody-somerville | lifeless, 108 queries/external actions issued in 1.91 seconds | 00:08 |
|---|---|---|
| cody-somerville | AJAX Log ↓ | 00:08 |
| lifeless | cool thanks | 00:09 |
| nigelb | woah, https://code.launchpad.net/~launchpad-pqm/launchpad/devel just timeout'd for me | 00:24 |
| wgrant | nigelb: Probably got caught on a branch scanner lock. | 00:24 |
| wgrant | :( | 00:24 |
| nigelb | wgrant: want the OOPS-ID? | 00:24 |
| wgrant | There's already a bug, and it will show up on the reports in an hour. | 00:25 |
| nigelb | okay | 00:25 |
| nigelb | "oh-oh-pick-me-pick-me" heh, interesting branch name :) | 00:26 |
| nigelb | I call today a success. I wrote a test case entirely on my own without help :D | 00:32 |
| nigelb | I was about to ping wallworld :/ | 00:34 |
| nigelb | Could someone review https://code.launchpad.net/~nigelbabu/launchpad/spec-sub-sort/+merge/63315 for me please? :) | 00:35 |
| wgrant | He's still around. | 00:36 |
| wgrant | We're on a call at the moment. | 00:36 |
| nigelb | Okay, I'll wait for later :) | 00:37 |
| jelmer | mwhudson: yep, that's the only failing test left | 00:47 |
| jelmer | mwhudson: I don't think anything significant has changed | 00:47 |
| mwhudson | jelmer: do you understand what the test is trying to test? | 00:49 |
| jelmer | mwhudson: I think I understand what it's trying to do, but the actual result surprises me | 00:51 |
| mwhudson | jelmer: me too i guess! | 00:52 |
| mwhudson | jelmer: as james_w said, has there been any change like breaking locks silently when there is no process with that pid any more? | 00:52 |
| jelmer | mwhudson: I missed James' comments, but that sounds plausible | 00:53 |
| mwhudson | although | 00:53 |
| mwhudson | i don't think that actually applies here | 00:54 |
| nigelb | wallyworld: hey | 00:56 |
| wallyworld | nigelb: hi. otp. will be finished soon | 00:56 |
| nigelb | cool | 00:57 |
| mwhudson | jelmer: ui factory changes might also affect this | 00:58 |
| mwhudson | PullerWorkerUIFactory.get_boolean is a thing of ... something | 00:59 |
| mwhudson | debugging integration test failures is always such a pain | 00:59 |
| jelmer | mwhudson: that's a good point | 01:00 |
| mwhudson | although i'd naively think that changes would result in the other test failing, i.e. not breaking the lock when it should be broken | 01:01 |
| lifeless | mmm | 01:02 |
| lifeless | so we're moving soon to multiple bzr+ssh servers | 01:02 |
| lifeless | we can't assume a pid lookup on the machine is authoritative | 01:02 |
| jelmer | mwhudson: I bet it's confirm_action, which now defaults to true | 01:02 |
| mwhudson | jelmer: yes | 01:02 |
| mwhudson | jelmer: i've just found the same code :) | 01:03 |
| wallyworld | nigelb: available now :-) | 01:03 |
| mwhudson | jelmer: it looks like there might be a saner mechanism to achieve the desired results too, perhaps | 01:03 |
| nigelb | wallyworld: could you review https://code.launchpad.net/~nigelbabu/launchpad/spec-sub-sort/+merge/63315 ? :) | 01:03 |
| mwhudson | jelmer: this confirmation_id thing | 01:03 |
| mwhudson | jelmer: does this mean that break_lock() will unconditionally break now in a script? | 01:04 |
| jelmer | mwhudson: seems likely, SilentUIFactory (which the UI factory the puller code installs derives from) has a confirm_action implementation that returns True | 01:04 |
| mwhudson | i wonder if that's an intended consequence | 01:05 |
| * wallyworld shakes fist at irc - keeps disconnecting | 01:07 | |
| jelmer | mwhudson: hmm, seems like this roughly the right place.. now I have a hanging twisted "thing", which is presumably caused by waiting for the lock to go away | 01:22 |
| mwhudson | jelmer: the lock holding process should be killed | 01:24 |
| mwhudson | jelmer: the callback called 'cleanup' in _run_with_destination_locked | 01:24 |
| jelmer | mwhudson: my neck is twisted from trying to follow everything that's going on here; thanks for the help so far, I'll have a closer look tomorrow | 01:34 |
| mwhudson | jelmer: yeah, it's very confusing | 01:34 |
| mwhudson | partly that's fairly inherent in what's being tested, but i'm sure it goes above and beyond what's required | 01:34 |
| mwhudson | this was the first difficult code i wrote for canonical btw :) | 01:35 |
| nigelb | wallyworld_: run lint, meaning run the tests? | 01:36 |
| nigelb | wallyworld_: I ran the test I added | 01:38 |
| jelmer | mwhudson: :) well, it is neat this sort of thing is actually tested | 01:38 |
| mwhudson | jelmer: yeah, and it seems like it caught a genuine issue too! | 01:39 |
| wallyworld_ | nigelb: sorry, was otp again. lint checks that the code syntax etc is as expected. you run bin/lint | 01:50 |
| wallyworld_ | nigelb: the output will highlight issues with adherence to the coding standards | 01:51 |
| nigelb | wallyworld_: ahh, doing that now | 01:51 |
| wallyworld_ | nigelb: it will detect which files have changed and only run against those | 01:51 |
| wallyworld_ | nigelb: also, there's a jslint for any javascript stuff you do | 01:52 |
| nigelb | aha | 01:54 |
| nigelb | wallyworld_: okay, I updated the branch with lint changes and the other changes you mentioned | 01:57 |
| wallyworld_ | nigelb: thanks. looking now. | 01:58 |
| wallyworld_ | nigelb: thanks for doing those changes. for next time you would then include the lint output in the merge proposal description, along with the other sections from the template as discussed. i just need jtv to sign off on it now since i'm only an apprentice reviewer | 02:04 |
| nigelb | wallyworld_: awesome, thanks. Could you also land it once its signed off? I'm not Canonical......yet. | 02:05 |
| wallyworld_ | nigelb: no problem at all. will do :-) | 02:05 |
| nigelb | lifeless: Updated the code for readability as you suggested. | 02:27 |
| lifeless | thanks | 02:27 |
| wallyworld_ | sinzui: i'm confused. i'd love a chat if you had 5 minutes. otherwise i'll ping you later | 02:33 |
| === almaisan-away is now known as al-maisan | ||
| LPCIBot | Project windmill-db-devel build #359: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill-db-devel/359/ | 03:18 |
| sinzui | wallyworld_: I am back now | 03:18 |
| wallyworld_ | sinzui: mumble? | 03:19 |
| lifeless | http://research.microsoft.com/en-us/projects/trinity/ is interesting | 03:24 |
| sinzui | wallyworld_: I think the windmill test failures are still caused the broken spinner I reported. Either my fix failed, or it is not being tested on jenkins yet | 03:59 |
| wgrant | sinzui: It's in jenkins now. | 04:02 |
| wgrant | AssertionError: Failure in lp/registry/javascript/tests/test_structural_subscription.html.test_title_ellipsisification: test_title_ellipsisification: failed. | 04:03 |
| LPCIBot | Project windmill-devel build #169: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/169/ | 04:03 |
| wgrant | Aha. | 04:03 |
| sinzui | wgrant: test_title_ellipsisification failed because the header and title were reversed. I think I fixed that | 04:04 |
| wgrant | Apparently not :( | 04:04 |
| sinzui | wgrant: oh good, it does not have my branch yet | 04:06 |
| wgrant | sinzui: Hm? Build #169 had your "Use standard events [...]" rev. | 04:08 |
| sinzui | wgrant: I do not see how test_hide_comment and test_personpicker can reliably work since they are missing the complete signal in the test | 04:19 |
| wgrant | Heh | 04:20 |
| === al-maisan is now known as almaisan-away | ||
| sinzui | Looks like the complete signal is broken in test_picker after a merge | 04:26 |
| nigelb | heh, I did think that lifeless's first mail looked sparse. | 04:30 |
| jtv | hi wallyworld_! | 04:41 |
| jtv | Any reviews today? | 04:42 |
| wallyworld_ | jtv: hi. there's one so far and one oops tools branch i'm not too familiar with so it's hard to offer anything constructive | 04:42 |
| jtv | In that case, ask lots of questions! | 04:43 |
| jtv | You'd be amazed how smart you can look by asking the right stupid question. :) | 04:43 |
| jtv | Ever read Surely You're Joking Mr Feynman? | 04:43 |
| wallyworld_ | jtv: ok. the review requested it be done by a member of the oops tools dev team. is it ok that i do it? | 04:43 |
| wallyworld_ | no, haven't read that :-) | 04:43 |
| jtv | I don't think we're part of the oops tools dev team, no. | 04:44 |
| jtv | You must read Feynman's autobiographies. He worked on the Manhattan Project. | 04:44 |
| wallyworld_ | sounds interesting | 04:44 |
| jtv | He was a bit of a junior type then, but when it was discovered that due to army secrecy rules, the uranium factory hadn't been told about things like "for heaven's sake don't stack it all up, and not on the other side of the wall either!" they just sent him. | 04:45 |
| wallyworld_ | hah | 04:45 |
| jtv | So there he went, young scientist, knowing nothing of industrial processes and construction. "What, me, little Richard!?" — "Yes you, little Richard." | 04:45 |
| jtv | And at the factory, he's the first Manhattan Project scientist they ever see. | 04:46 |
| jtv | So they think he's some kind of inhuman genius who knows everything. | 04:46 |
| jtv | And they show him the blueprints to the factory, in rapid-fire succession. | 04:46 |
| jtv | He thinks he recognizes a recurring mark on the blueprints. May be a valve. | 04:46 |
| jtv | But by that time he's several blueprints in, so he can't very well ask "so what's this then, a valve?" | 04:47 |
| jtv | Instead, he bluffs. | 04:47 |
| jtv | Points at one, goes "what happens when this valve here gets stuck?" | 04:47 |
| jtv | —expecting them to say "er… Mr Feynman, you know that's a door, right?" | 04:47 |
| jtv | Instead, they go "well, in that case…" | 04:48 |
| jtv | (trace conduit onto other blueprint) | 04:48 |
| jtv | (scratch heads) | 04:48 |
| jtv | (argue) | 04:48 |
| jtv | (sweat) | 04:48 |
| jtv | "Gee Mr Feynman, you're right! When that valve blocks, everything goes!" | 04:48 |
| jtv | Anyway, better let the oops-tools review lie then. | 04:50 |
| jtv | At least we got a nice story out of it. :) | 04:50 |
| wallyworld_ | jtv: as long as he didn't say "wonder what this big red button does, let's find out..." | 04:58 |
| jtv | Well he did some of those in his life as well, in his way. | 04:59 |
| jtv | He also came up with this neat trick: | 04:59 |
| jtv | Science conference. Late to book. All hotels are full. | 04:59 |
| jtv | So he booked himself and another professor into a room at a hotel that, er, specialized in short stays. | 04:59 |
| jtv | As in, "you want to stay a _whole_ _night_!?" | 05:00 |
| jtv | wallyworld_: what's the last you saw? | 05:01 |
| wallyworld_ | jtv: last review request? | 05:01 |
| jtv | No I mean, what was the last thing you saw before your IRC connection blinked? | 05:02 |
| jtv | StevenK, wgrant: mind if I delete all DSDJobs on dogfood and restart the app server? | 05:02 |
| wallyworld_ | jtv: it's been blinking all day for some reason :-( | 05:03 |
| wallyworld_ | the last thing was At least we got a nice story out of it. :) | 05:03 |
| jtv | Probably because I gave up on wifi and stopped blinking. Someone has to do it. | 05:03 |
| jtv | Ah OK, I'll leave the other story for another time then. Or you can read the book. :) | 05:03 |
| wallyworld_ | s/book/ebook | 05:04 |
| wgrant | jtv: I just killed the appserver and deleted all the PackageCopyJobs to let the DB patches apply. I'm dealing with the DB directly now, so you can start it up. | 05:05 |
| jtv | wgrant: can you delete all dsdjobs while you're at it? Or I can do it if that's more convenient. | 05:05 |
| wgrant | jtv: I'm currently in the middle of fti.py, so not really convenient for me to do that right now. | 05:06 |
| jtv | OK I'll do it | 05:06 |
| jtv | And done. | 05:06 |
| jtv | And I'll start the app server. | 05:07 |
| wgrant | Hm, doesn't seem to be running? | 05:08 |
| wgrant | Oh, you're making? | 05:09 |
| jtv | Trying. | 05:11 |
| jtv | Failing. | 05:11 |
| jtv | KeyError: u'../images/mute.png' | 05:11 |
| jtv | A file that does seem to exist — but not in branches on my own machine. | 05:14 |
| wgrant | That was added recently... what was it that filed? Spriteutil? | 05:15 |
| wgrant | failed. | 05:15 |
| wgrant | HM, indeed. | 05:17 |
| wgrant | jtv: Works now. | 05:18 |
| wgrant | jtv: I moved icon-sprites.positioning out of the way. | 05:19 |
| wgrant | It rebuild it and completed OK. | 05:19 |
| * wgrant makes start. | 05:19 | |
| wgrant | It's up. | 05:20 |
| jtv | Thanks. | 05:20 |
| jtv | How did you know how to fix that? | 05:21 |
| wgrant | I saw the new sprites added this morning, guessed that one of the caches was out of date. | 05:22 |
| jtv | Then I wonder why "make" didn't see that. | 05:29 |
| wgrant | No idea. | 05:29 |
| wgrant | Our Makefile is a bit crap. | 05:29 |
| * wallyworld__ just had a kernel panic - lost a big loong email :-( | 05:30 | |
| wgrant | jtv: I need to bounce the appserver soonish. | 05:32 |
| jtv | wgrant: fine with me | 05:35 |
| wgrant | jtv: It's back. | 05:37 |
| jtv | thz | 05:37 |
| jtv | wgrant: mind if I sync some packages? | 05:38 |
| wgrant | jtv: Not at all. | 05:39 |
| jtv | Then let's find out if I broke that. | 05:39 |
| wgrant | wallyworld__: I've fixed the project picker to mostly work, I think. | 05:39 |
| wallyworld__ | wgrant: excellent | 05:39 |
| wgrant | wallyworld__: Have a look at https://bugs.dogfood.launchpad.net/launchpad/+bug/1234. It now uses icons, ranks properly, and doesn't search description, and puts exact name matches first. | 05:40 |
| _mup_ | Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 > | 05:40 |
| wgrant | So it's a bit less unusalbe. | 05:40 |
| wgrant | Although still ugly because of lazr-js's icon positioning. | 05:40 |
| * wallyworld__ looks | 05:40 | |
| === wallyworld__ is now known as wallyworld | ||
| wallyworld | wgrant: i'm searching for "firefox" and it's been going over a couple of minutes now with now result | 05:46 |
| wgrant | wallyworld: Took 3.2s for me. | 05:46 |
| wallyworld | hmmm. i'll try again | 05:46 |
| wgrant | DF is not the most stunningly reliable entity in the universe. | 05:46 |
| wgrant | We possibly still want affiliation. | 05:48 |
| wallyworld | yeah the gods are against me today. still no luck | 05:48 |
| wgrant | But like with team search, they are far more likely to be unique and searchable. | 05:48 |
| wgrant | Huh. | 05:48 |
| wgrant | Does 'launchpad' work? | 05:48 |
| wallyworld | i'll look | 05:49 |
| wallyworld | works in a fashion - "Too many matches, please narrow your search" | 05:49 |
| wgrant | Which picker is this? | 05:49 |
| wallyworld | project picker on https://bugs.launchpad.net/launchpad/+bug/1234/+choose-affected-product | 05:50 |
| _mup_ | Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 > | 05:50 |
| wgrant | WTF, which one is that. | 05:50 |
| wgrant | It's a different one. | 05:50 |
| wgrant | Try the one in the task row on the bugtask index. | 05:50 |
| wgrant | While I track down why we have two product pickers. | 05:50 |
| wallyworld | one uses "project" the other "product" | 05:50 |
| wallyworld | in the title | 05:51 |
| wgrant | Oh, no, they are the same vocab. | 05:51 |
| wgrant | But you were trying on production... | 05:51 |
| wgrant | And yes, they have different titles. | 05:51 |
| wgrant | That's fixed locally. | 05:51 |
| wallyworld | no luck with the dogfood one one the bagtask row | 05:52 |
| wgrant | Sure it's dogfood this time? :) | 05:52 |
| wallyworld | might just be me | 05:52 |
| wallyworld | yep :-) | 05:52 |
| * wallyworld has to run away for a bit to pick up the kid and buy dinner. wife is out so i can get whatever junk food i want :-D | 05:54 | |
| wgrant | Heh | 05:54 |
| wallyworld | mmmm. lasagne sounds good | 05:54 |
| wallyworld | wgrant: i've also found a couple of person picker implementations :-/ | 05:54 |
| wgrant | wallyworld: There are a few pillar pickers. | 05:55 |
| wgrant | Hm. | 05:55 |
| wgrant | Now the product picker is hanging for me too. | 05:55 |
| wgrant | Except it also hangs Chromium's developer console. | 05:55 |
| StevenK | wallyworld: How is lasagne junk food? :-) | 05:57 |
| wgrant | stub: We can't do FTI column rebuilds live, can we? | 06:19 |
| wgrant | wallyworld (when you're back): I tried a couple of quick changes to make the picker less ugly: http://people.canonical.com/~wgrant/launchpad/project-picker/before.png vs http://people.canonical.com/~wgrant/launchpad/project-picker/after.png | 06:35 |
| wgrant | StevenK: What do you think? | 06:36 |
| wgrant | It's possibly less easily scannable due to the lack of indentation on the summary. | 06:36 |
| wgrant | But I think it's better. | 06:36 |
| StevenK | I think slangasek has been asking me hard questions. | 06:37 |
| wgrant | Oh? | 06:37 |
| wgrant | Ah, there. | 06:37 |
| StevenK | wgrant: I prefer after | 06:37 |
| StevenK | It looks cleaner, but I share your concern. | 06:37 |
| wgrant | But the old one is fugly, so meh. | 06:38 |
| jtv | wallyworld: with a heavy heart I voted Disapprove on that MP. By the way, when you do a "code*" review, please always point out what the asterisk means! | 06:47 |
| nigelb | jtv: yeah, I noticed. | 06:54 |
| nigelb | jtv: I agree with your reason to disapprove, but this is part of 2 bugs I fixed sorting. This means both of them needs to be re-reviewed. The other one landed in production already. | 06:54 |
| wallyworld | jtv: i had no idea sorting was so involved | 06:54 |
| jtv | nigelb: I'm writing that email at the moment. It'd be nice to have this solved. | 06:55 |
| wallyworld | wgrant: i like the after shot - the way the description text is left aligned reall yhelps | 06:55 |
| wgrant | wallyworld: I'm also getting rid of the margin at the bottom. | 06:55 |
| wgrant | Needs some lazr-js CSS changes :( | 06:55 |
| wallyworld | wgrant: i think the preferred approach is to override the styles in lp | 06:56 |
| jtv | wallyworld: there's some weird stuff out there. Letters that you convert to upper-case and back to lower and they're not what you started with; scanning the string backwards for tie-breakers; letters that change position in the alphabet based on use-case; letters that need to be read in one order, written in another order, and sorted in yet another one. | 06:56 |
| wgrant | wallyworld: Probably. | 06:56 |
| wallyworld | jtv: so what's best preactice for sorting? | 06:57 |
| nigelb | I'm curious though, how'd we solve this for bug subscriptions. Aren't they also sorted alphabetically? | 06:57 |
| jtv | wallyworld: and my all-time favourite: i/I are not a lower-case/upper-case pair in Turkish. | 06:57 |
| wallyworld | wgrant: doing it that way was what curtis wanted for the badge styling | 06:57 |
| wgrant | wallyworld: Yeah, but this is probably slightly different. | 06:57 |
| wallyworld | jtv: wtf? how so? | 06:57 |
| wgrant | wallyworld: anyway, I can probably override this in LP using :empty. | 06:57 |
| wallyworld | wgrant: you then don't need to do a lazr-js mp :-) | 06:58 |
| wgrant | style-3.0.css makes me sad. | 06:58 |
| wallyworld | me too | 06:58 |
| jtv | wallyworld: there's no single solution, and the partial solutions all basically sort of hope that you won't be mixing languages. Good technical practice includes "don't try to deal with letters as such because you can't imagine the horrors in the dungeon dimensions beyond ASCII," "don't think you understand what .upper() and .lower() do," "don't talk to foreigners," and "let somebody else take care of it." | 07:00 |
| nigelb | Note to self: Don't touch sorting bugs. | 07:00 |
| wallyworld | i like the last one best :-) | 07:00 |
| wallyworld | nigelb: it all seemed so easy before jtv pointed out a few realities :-) | 07:01 |
| jtv | wallyworld: oh, about Turkish? They have a sensible but incompatible system where i/İ form a pair, and there's another pair without the dot that I can't figure out how to type right now. Note how in both pairs, one letter is ASCII and the other isn't. | 07:01 |
| nigelb | wallyworld: True that. I only just fixed one bug this way because it was tagged easy and then I went ahead and fixed specifcations too | 07:02 |
| nigelb | Now I have to re-fix the sorting bugs I've touched | 07:02 |
| nigelb | After we bikeshed on the best way to fix this :D | 07:02 |
| wallyworld | nigelb: well whoever tagged it as easy knows as little as you and me about the problem :-) | 07:02 |
| jtv | nigelb: /me nods emphatically :) | 07:02 |
| nigelb | true, that. | 07:02 |
| jtv | Somebody tagged this as easy? Amusing. | 07:02 |
| jtv | It _seems_ easy. | 07:02 |
| nigelb | Not this. Someone tagged sorting the sprints as easy | 07:03 |
| nigelb | From there I found the specifications one | 07:03 |
| wallyworld | jtv: so does keeping one's wife happy, but their both roads frought with danger | 07:03 |
| nigelb | I fixed both but without the lower(), so it wasn't really fixed | 07:03 |
| wallyworld | s/their/they're | 07:03 |
| nigelb | So, I refixed sprints with .lower() and this was an attempt to fix specifications | 07:03 |
| nigelb | Now I have to do this all over again :) | 07:04 |
| wgrant | jtv: For a proper solution we surely need to define a collation for each text field, and somehow use them all together nicely. | 07:04 |
| wgrant | That sounds like fun. | 07:04 |
| jtv | wallyworld: funny you should mention that, given that mine was born with a different script than I, but bilingual where one language is "officially" written in a script I had to teach her. | 07:04 |
| jtv | wgrant: not sure that doing it per field is the solution. I suspect we'll always have a bit of a weird mix, with some ordering coming out of the DB and other ordering happening in Python. | 07:05 |
| jtv | postgres now supports per-column collation, but I was one of the ones who did not support that idea. | 07:06 |
| jtv | I feel that basically, sorting for display and sorting for computer use are different tasks just like e.g. rendering integers as strings for both are. | 07:07 |
| jtv | But does anyone listen? No, and I can't blame them. | 07:07 |
| wallyworld | wgrant: do you hear anything? | 07:08 |
| * jtv presses caps lock and prepares to repeat | 07:08 | |
| wallyworld | :-P | 07:08 |
| === jtv is now known as jtv-aol | ||
| jtv-aol | I SAID… | 07:09 |
| === jtv-aol is now known as jtv | ||
| jtv | nigelb: truly sorry to be such a spoilsport; on the bright side, I hope we can get a better solution. | 07:10 |
| nigelb | jtv: that's what I'm thinking too :) | 07:12 |
| jtv | wallyworld: fwiw Turkish is apparently sort of the standard smoke-test language for locale handling. It's got just enough differences from ASCII to trip you up, but not enough to be completely alien to programmers who use mostly ASCII. | 07:12 |
| nigelb | jtv: I don't mind refixing things if its "THE FIX" :) | 07:12 |
| jtv | The email just went out. | 07:13 |
| wallyworld | hah. time to learm turkish | 07:13 |
| wgrant | Yay, qbzr works again. | 07:13 |
| StevenK | nigelb: THE FIX, NO I REALLY MEAN IT THIS TIME. | 07:13 |
| lifeless | jtv: fwiw there is other code with the collation limit defect you point out | 07:13 |
| jtv | Limit? | 07:13 |
| nigelb | StevenK: Yeah, that one. It would be the third fix for this bug :) | 07:13 |
| wgrant | lifeless: I think it's possibly everything else in Launchpad ever. | 07:14 |
| lifeless | jtv: so I don't think blocking this localised improvement for a global one is necessary | 07:14 |
| wgrant | wallyworld: extra-form-buttons... do you know why the height: 3em is there? | 07:14 |
| wallyworld | is stles-3.0.css? | 07:14 |
| wgrant | Yes. | 07:14 |
| wgrant | You added it in 12641.6.30 | 07:14 |
| wallyworld | wgrant: not sure now. to make it work :-) | 07:15 |
| wgrant | I guess I'll just remove it and check both users. | 07:15 |
| jtv | lifeless: we could go there, but then we'd want to make the sort order determinate again, and before you know it we're still re-inventing the wheel. | 07:15 |
| lifeless | jtv: huh? | 07:16 |
| wallyworld | wgrant: sorry i can't recall exactly. i guess without it it would have rendered too squashed or something | 07:16 |
| lifeless | jtv: I don't follow | 07:16 |
| wallyworld | or too tall | 07:16 |
| lifeless | jtv: we have *identical* (barring variable names) code to the code nigelb proposed elsewhere. | 07:16 |
| lifeless | jtv: how is accepting his patch tied to wheel reinvention ? | 07:16 |
| nigelb | lifeless: sprints | 07:17 |
| jtv | lifeless: sorting a bunch of strings is hairy, but determinate. Converting to lower case and then sorting is simple, but indeterminate. It's not disastrous, but if you test for sorting "a" vs. "A"… | 07:17 |
| nigelb | at least that I know of. | 07:17 |
| lifeless | jtv: I accept that assertion. I don't follow the chain of causation | 07:18 |
| lifeless | nigelb: loggerhead, mailman, sprints, persons, branches | 07:19 |
| lifeless | at least | 07:19 |
| nigelb | woah. | 07:19 |
| nigelb | that's a lot. | 07:19 |
| lifeless | maybe | 07:19 |
| lifeless | 7 call sites a *truely trivial* grep found | 07:19 |
| lifeless | I didn't look for multiline sorts | 07:19 |
| lifeless | so I'd expect more - maybe 15 or 20 | 07:19 |
| lifeless | not huge in the scheme of things, but there may be more where its not obvious that we've done a lower() | 07:20 |
| nigelb | hrm, just a doubt though. How often are the strings of the kind that we have a problem with? | 07:20 |
| nigelb | Like, are all the fields UTF-8 in the db? | 07:20 |
| lifeless | most are yes | 07:21 |
| lifeless | some have narrower constraints | 07:21 |
| jtv | There's plenty of ascii-only identifiers, even if the columns may be Unicode. | 07:21 |
| lifeless | dispaly names are generally free form, the url components are all tightly limited subsets of ascii | 07:22 |
| lifeless | anyhow | 07:22 |
| lifeless | its 6:30 pm | 07:22 |
| lifeless | I'm not really here | 07:22 |
| lifeless | I just don't think we should block a temporary improvement for a larger change we haven't yet made that may require reversing this patch at that later date. | 07:23 |
| lifeless | unless it would be *worse* today, (in which case its not a temporary improvement) | 07:23 |
| wgrant | wallyworld: Ah, turns out you just converted it from inline styles. | 07:24 |
| wallyworld | wgrant: right. makes sense | 07:24 |
| jtv | lifeless: it's better in some ways, worse in others — and to some extent we just don't know. General good practice says "don't do this." | 07:31 |
| jtv | But see the mailing list. Martin's got some good comments. | 07:31 |
| nigelb | so we write a wrapper and then fix this problem systematically? | 07:34 |
| nigelb | fix the wrapper step by step I guess | 07:34 |
| stub | wgrant: We can. What fti change where you thinking of? | 07:35 |
| wgrant | stub: Dropping product.description from product.fti. | 07:35 |
| wgrant | AFAICT it's as deprioritised as it can get, and it's still bad. | 07:37 |
| wgrant | Dropping it yields better results. | 07:37 |
| wgrant | name/displayname/title/summary should cover all the important data. | 07:37 |
| wgrant | description is more of a homepage. | 07:37 |
| stub | Why is converting a string to lowercase and sorting indeterminate? | 07:40 |
| stub | I don't think any lower() functions invoke random() | 07:40 |
| wgrant | stub: lower('foo') == lower('Foo') | 07:40 |
| stub | ok | 07:41 |
| stub | So the correct thing to do in most cases would be to sort by (lower(foo), foo)? | 07:41 |
| jtv | Well it wouldn't work for Thai, for instance. | 07:42 |
| lifeless | or not worry | 07:42 |
| stub | or in en_GB locale we trust? | 07:42 |
| jtv | Exactly. | 07:42 |
| jtv | If we use en_GB, or en_US, it's fine. | 07:42 |
| stub | jtv: Why would that give indeterminate results with Thai? | 07:42 |
| jtv | But currently we seem to use C, which isn't. | 07:42 |
| jtv | stub: not indeterminate in that case, just wrong. | 07:42 |
| stub | Sure, but any collation will be wrong when sorting a set of strings in mixed languages, which is what Launchpad needs to do most of the time. So we have to make a best attempt. | 07:43 |
| jtv | Yes, and I think the best attempt is what you say: use en_GB or some other human-readable locale. | 07:43 |
| jtv | Instead of trying to simulate its properties by hand. | 07:43 |
| stub | en_GB is just insensitive sorting or maybe sorting on (lower(foo), foo) under the hood, or at least it seems that way under Linux. | 07:44 |
| jtv | It also falls back on unicode collation. | 07:45 |
| stub | but using locales for sorting was bad in the past, because they only cared about their native alphabets and you ended up with stupid things like 'all japanese strings compare equal' | 07:45 |
| jtv | en_US.UTF-8 gives me correct sorting for a bunch of non-English strings: | 07:45 |
| jtv | กา เก คา เค a A b B Ξ ξ Ω ω б Б г Г | 07:45 |
| wgrant | wallyworld__: Does U1 still use lazr-js, or are we down to just L[SP]? | 07:46 |
| stub | Cool. If they have fixed that now, we should probably switch to en_?? locale when we migrate to PG 9.x | 07:46 |
| jtv | What's the connection to the PG upgrade? | 07:46 |
| jtv | (I forgot most of this discussion) | 07:47 |
| stub | jtv: We have to rebuild all the databases etc. | 07:47 |
| jtv | Why? | 07:47 |
| stub | jtv: I'd rather do that once rather than twice :) | 07:47 |
| jtv | Indexes? | 07:47 |
| stub | Actually, we might not have to rebuild if pgmigrator works for us. But we still need to wait if we go that route as we would need locale specific indexes rather than rebuilding the database in a particular locale. | 07:48 |
| stub | So we either dump and restore with a new locale, or rebuild all our indexes with our preferred locale and keep the DB itself in the C locale. I think :) | 07:49 |
| jtv | Could we get away with changing the python collation separately? | 07:49 |
| stub | I don't think we want to do all our sorting client side. | 07:49 |
| jtv | No, but I wonder how much user-visible sorting of freeform strings we do in the DB. | 07:50 |
| stub | Most places it won't matter as the field we are sorting on is restricted to lowercase ascii. | 07:50 |
| jtv | Exactly. We care here about user-visible sorting of freeform strings. | 07:51 |
| stub | So maybe we should stick to C locale in the DB for speed :-) (although we would need to measure that - what was slower 5 years ago may no longer be the case) | 07:52 |
| jtv | Maybe this is actually one of those applications for per-column collations. :) | 07:53 |
| jtv | (But that's 9.0 I think) | 07:53 |
| jtv | I suspect fully-collated sorts will still be slower, but maybe we should treat DB sorting more as being for machine consumption. | 07:55 |
| jtv | With a few exceptions such as batching queries. | 07:55 |
| stub | wgrant: That one is a 'possibly, but very problematic'. We need to drop and recreate a trigger, which is fast enough if we manage to grab a lock but grabbing the lock is problematic. And then we need to apply a db patch *to the slaves only* during the next rollout that updates the trigger. | 07:55 |
| lifeless | wgrant: relatedly isd have deropped lazr.restful | 07:56 |
| wgrant | lifeless: Oh really? | 07:57 |
| lifeless | jtv: stub: I think we could tolerate different collations in db and python - for a given dataset we're only going to sort in one of (db, python) I expect. | 07:57 |
| stub | jtv: I think we will shoot ourselves in the foot if people need to remember to set the default collation order before issuing a query, and I'm not sure if it is possible to do something like ORDER BY name IN LOCALE C, displayname IN LOCALE en_US (or if we would want to do that) | 07:57 |
| jtv | I agree — I think any problems from that are going to be more along the lines of the symptom that led to nigelb's patch. | 07:57 |
| stub | lifeless: Yes. Apart from case insensitive, the vast majority of the time nobody will even notice. | 07:58 |
| stub | jtv: Which I haven't followed :) | 07:58 |
| jtv | stub: see launchpad-dev list | 07:58 |
| jtv | I suspect we're going to run into this very rarely with database queries: we tend to rely on different orderings there anyway. | 08:00 |
| stub | Ordering by distribution may be an issue when we have lots from derived distros (AAALinux). Person.displayname is the only other issue, and we should really be ordering using the functional index for that purpose to strip out punctuation etc. (>> l33t d00d <<) | 08:05 |
| lifeless | yes | 08:05 |
| lifeless | however | 08:05 |
| stub | If it is really only those cases, yer. I guess stick with C locale and override for the rare cases. | 08:06 |
| lifeless | subscribers-to-an-object - small # | 08:06 |
| lifeless | person vocabs - huge #'s | 08:06 |
| lifeless | huge #'s we need db sort for | 08:06 |
| stub | Functional indexes win there if they have fixed the bug I reported in... erm... 8.1? 7.4? | 08:07 |
| wgrant | Grar embedded copies of YUI. | 08:07 |
| wgrant | STAB | 08:07 |
| stub | (ORDERING BY displayname_sort(displayname) would hit the functional index, but there is a deeply embedded but that caused displayname_sort(displayname) to be reevaluated for every retrieved row. | 08:08 |
| stub | Need to retest with modern PG... | 08:09 |
| lifeless | stub: it will still do that | 08:10 |
| lifeless | stub: remember the performance hit on package versions functional index | 08:10 |
| jtv | That overhead of functional indexes still hasn't gone away? | 08:10 |
| jtv | Or is there a gotcha like "you must declare your function as pure or else"? | 08:11 |
| lifeless | I think its tied to the same node-may-differ thing that makes from-index queries impossible | 08:11 |
| stub | jtv: I need to check. It was confirmed as a bug, but deeply entrenched and Tom wasn't sure how to fix it. It was still there at least one release later. | 08:12 |
| stub | (check by creating a stable function with a RAISE NOTICE in it, and seeing if the messages are spit out to the logs when queries are hitting the functional index) | 08:13 |
| stub | lifeless: Thinking of PG 9.1 rather than 8.4. | 08:14 |
| stub | Lots of juicy bugfixes and features coming up | 08:14 |
| jtv | I wonder if maybe the re-evaluation is tied to the liveness check (where you need to access a tuple in the table just to see whether it's visible, even if the index has everything else you need) | 08:17 |
| lifeless | stub: ah yes | 08:17 |
| lifeless | jtv: thats what I was referring to ;) | 08:17 |
| jtv | Oh | 08:17 |
| lifeless | jtv: I forgot the terminology | 08:17 |
| stub | jtv: I don't know. My eyes just glaze over at a certain point :) | 08:17 |
| jtv | lifeless: that's alright, I don't know the terminology either | 08:18 |
| jtv | Oh blast. PQM merge failure: test_bug_views.py | 08:18 |
| wallyworld__ | wgrant: i thin kU1 may use lazr-js but not sure, sorry | 08:20 |
| wgrant | wallyworld__: You broke the lazr-js build :( | 08:20 |
| wgrant | Traceback (most recent call last): | 08:20 |
| wgrant | File "bin/yuimeta", line 17, in <module> | 08:20 |
| wgrant | import lazr.js.meta | 08:20 |
| wgrant | File "/home/wgrant/Development/lazr-js/trunk/src-py/lazr/js/meta.py", line 9, in <module> | 08:20 |
| wgrant | from lazr.js.build import SRC_DIR | 08:20 |
| wgrant | ImportError: cannot import name SRC_DIR | 08:20 |
| wgrant | From a fresh make. | 08:20 |
| wallyworld__ | huh? works locally i swar | 08:20 |
| wallyworld__ | i'm using it in lp now | 08:20 |
| * wallyworld__ checks | 08:20 | |
| wgrant | wallyworld__: This is outside LP. | 08:21 |
| wallyworld__ | hmm. ok. still waiting for editor to start. having computer issues today | 08:22 |
| wgrant | Any hints on running its tests? | 08:23 |
| wgrant | I s/SRC_DIR/DEFAULT_SRC_DIR/ and it built, but doesn't seem to work very well. | 08:23 |
| wallyworld__ | wgrant: that import is indeed wrong | 08:24 |
| wgrant | wallyworld__: There are also some bugs in your new linkfication code. | 08:28 |
| wgrant | And I think we might need to entirely customise the rendering anyway. | 08:28 |
| wallyworld__ | what bugs? | 08:28 |
| jtv | gmb: you seem to have a devel/db-devel merge conflict with Gary. | 08:28 |
| wgrant | wallyworld__: "<a class = '" + css + "' href=javascript:void(0)></a>"); | 08:28 |
| wgrant | wallyworld__: Odd spacing around the class, you're using string concatenation rather than addClass, no quotes around the href, and the href should probably be the real value. | 08:29 |
| wgrant | li_title.appendChild(' (') | 08:29 |
| wgrant | Entities need to end with a semicolon. | 08:29 |
| wallyworld__ | wgrant: i don't want href as the real value. | 08:29 |
| wallyworld__ | i use an onclick handler to open the link | 08:30 |
| wgrant | Oh? | 08:30 |
| wgrant | Sure. | 08:30 |
| wgrant | But it's going to look bad in the status bar. | 08:30 |
| wallyworld__ | it all seems to work in practice | 08:30 |
| wgrant | Having the right href there won't hurt, and it will make it clearer what it's doing. This point is arguable. | 08:30 |
| wgrant | The quotes are not :) | 08:30 |
| wgrant | I'm trying to think how to implement my prettification properly. | 08:31 |
| wgrant | It needs the image to be part of the title a/span. | 08:31 |
| wgrant | And needs a custom class on that a/span. | 08:31 |
| wgrant | And needs the margin reduced. | 08:31 |
| wgrant | Which seems incompatible with not breaking landscape. | 08:31 |
| wallyworld__ | wgrant: i've merged in the compile fix. i'll do the other things a bit later - i have to take the kid to his violin concert. lord have mercy on my soul | 08:32 |
| wgrant | Haha. | 08:32 |
| wgrant | Thanks. | 08:32 |
| wallyworld__ | my ears hurt already | 08:32 |
| wgrant | (brave, letting a child learn the violin) | 08:32 |
| wallyworld__ | thanks for the input on the js | 08:32 |
| wallyworld__ | yep | 08:32 |
| StevenK | I love the sound of the violin. | 08:37 |
| jtv | Peacefully crackling in an open fire. | 08:43 |
| StevenK | No! | 08:45 |
| gmb | Anyone dealing with that PQM failure? | 08:55 |
| wallyworld__ | StevenK: i like the sounds of a violin played *well*. not by a 10 year old. have you ever heard a cat being strangled? it's worse than that. now off to my ears' implending doom | 08:55 |
| gmb | Ah, looks like it's mine and Gary's code fighting. | 08:56 |
| gmb | And jtv just saw the same thing. | 08:56 |
| * gmb goes to fix it. | 08:56 | |
| === almaisan-away is now known as al-maisan | ||
| LPCIBot | Project windmill-devel build #170: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/170/ | 09:43 |
| poolie | lifeless: so the reason i didn't truncate it is it wasn't obvious | 10:02 |
| poolie | firstly if you can just truncate it and still attach it as a message | 10:02 |
| poolie | secondly how to do that in python | 10:03 |
| lifeless | well | 10:03 |
| lifeless | perhaps I'm being naive | 10:03 |
| lifeless | I would take the incoming mail as a string | 10:03 |
| lifeless | take the first 64K which is pretty sure to get all the headers | 10:03 |
| lifeless | and attach that as a original.txt file | 10:03 |
| poolie | that could work | 10:03 |
| poolie | avoids the issue of what would be valid as a mime message | 10:04 |
| poolie | fyi it has already been stored to the librian by the time this crash occurs | 10:04 |
| poolie | there might be some other higher limit there | 10:05 |
| lifeless | it has ? | 10:05 |
| lifeless | I looked at fromEmail which things it may not have been | 10:05 |
| lifeless | librarian can store ISOs | 10:05 |
| lifeless | brb | 10:05 |
| gmb | Apologies for the continuing breakage on db-devel. I've fixed the conflict but am now getting test failures. | 10:34 |
| === jkakar_ is now known as jkakar | ||
| gmb | Oh, obvious failure is obvious. | 11:37 |
| * gmb facepalms, fixes. | 11:37 | |
| === al-maisan is now known as almaisan-away | ||
| stub | I've been in Thailand too long. "I've not really succeed in describing it in understandable English." | 11:47 |
| nigelb | So, what's the consensus on the sort thing that jtv raised on the list? | 11:52 |
| nigelb | On reading the mail threads, I couldn't really find a consensus. | 11:53 |
| stub | nigelb: I think consensus was that we should be running our Python stuff in a known locale and using locale aware sort routines. | 12:07 |
| nigelb | stub: hrm, so I can act on that information and update my MP? | 12:07 |
| stub | nigelb: Not sure how that applies to your immediate problem ;) | 12:07 |
| nigelb | hah | 12:07 |
| stub | Might want to confirm that my consensus is not just an over inflated opinion :) | 12:08 |
| stub | jtv has dropped off though. lifeless might still be alive. | 12:08 |
| nigelb | Nah, I think I'll pick this up again tomorrow morning | 12:09 |
| nigelb | Or, reply to the thread :) | 12:09 |
| wallyworld_ | wgrant: the cleaned up js has now merged. it includes the change to show the href in the status bar | 12:35 |
| === mrevell is now known as mrevell-lunch | ||
| wgrant | wallyworld_: Ah, great, thanks! | 12:36 |
| wallyworld_ | wgrant: well, i should never have did it like that in the first place | 12:37 |
| wgrant | wallyworld_: http://people.canonical.com/~wgrant/launchpad/project-picker/after.png is what it actually looks like now (previous one was hacked in Chromium), but I need to work out how best to do it without breaking Landscape. | 12:37 |
| wgrant | That will be a job for next week, I suppose. | 12:38 |
| wallyworld_ | wgrant: also, i am redoing the link rendering, but in a lp override of the renderUI method. the lazr-js version is a "well it works generically" thing. | 12:38 |
| wgrant | wallyworld_: Ah, so we can easily override that? | 12:38 |
| wgrant | wallyworld_: That will make things easier. | 12:38 |
| wallyworld_ | wgrant: yes, i wrote it so that it worked "out of the box" in lazr-js but easily overridden in lp | 12:39 |
| wallyworld_ | wgrant: the new screenshot loks good | 12:39 |
| wgrant | Excellent. | 12:39 |
| wgrant | Yeah, I removed the excess padding and restricted the description to one line and used the custom icon if present and aligned the icons like normal links | 12:40 |
| wgrant | Looks a bit less scrappy. | 12:40 |
| wallyworld_ | wgrant: i'm doing a base lp picker implementation which overrides lazr-js picker and provides the extra rendering. person picker and friends will use that instead of the lazrjs one | 12:40 |
| wgrant | wallyworld_: Great. | 12:41 |
| wallyworld_ | ui work takes to much time / tweaking :-) | 12:41 |
| wgrant | It does, but it makes us look less pathetic. | 12:41 |
| wallyworld_ | can't argue there | 12:44 |
| jelmer | mwhudson: thanks for the hints yesterday, managed to nail down the issue - properly implementing confirm_action seems to've done it. | 12:45 |
| LPCIBot | Project windmill-db-devel build #360: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-db-devel/360/ | 13:01 |
| === bac changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: wallyworld* (jtv), bac | Critical bugs:208 - 0:[######=_]:256 | ||
| === bac changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: bac | Critical bugs:208 - 0:[######=_]:256 | ||
| === almaisan-away is now known as al-maisan | ||
| === mrevell-lunch is now known as mrevell | ||
| deryck | Morning, everyone. | 14:08 |
| flacoste | morning deryck! | 14:36 |
| danilos | matsubara, hi, I wonder if you've managed to uncover any terrible issues with staging code regarding bug subscriptions? (as asked about by Gary) | 14:56 |
| matsubara | danilos, I didn't start the ET yet. | 15:06 |
| * danilos ponders a few seconds before he figures out that ET is extra-terrestrial... nor, ETA with a missing A... but exploratory-testing :) | 15:07 | |
| danilos | is not* | 15:07 |
| danilos | matsubara, ok, thanks | 15:08 |
| LPCIBot | Project db-devel build #609: FAILURE in 34 min: https://lpci.wedontsleep.org/job/db-devel/609/ | 15:23 |
| sinzui | wallyworld: I approved picker-click-item-detail | 15:35 |
| jcsackett | sinzui: i saw the bug on yui tests; it's assigned to me now, and today is largely clear to take care of it. | 15:38 |
| sinzui | jcsackett: I just forwared you an email. wallyworld is concerned that he isworking in lazr picker and you create a new one. | 15:40 |
| wgrant | I am leaving my further picker improvements until one of your implementations wins :/ | 15:41 |
| sinzui | jcsackett: I think we want to investigate these failures: https://lpci.wedontsleep.org/job/windmill-db-devel/359/#showFailuresLink | 15:42 |
| sinzui | I think we should invite deryckto adjudicate | 15:42 |
| jcsackett | sinzui: agreed. also, i now need to check my source tree, because my windmill tests are not running. | 15:42 |
| jcsackett | i ran layer=windmill and got no failures; this should have been picked up. :-/ | 15:43 |
| sinzui | jcsackett: did you see the tests actually run? | 15:43 |
| jcsackett | sinzui: i saw many tests run. | 15:43 |
| jcsackett | it looked like all yui/windmill tests had run and passed. | 15:43 |
| * jcsackett considers whether the personpicker link in branch should just be rolled back. | 15:44 | |
| sinzui | Is saw lp/app/javascript/tests/test_picker.html pass, but it does not now. the test is different after the merge beause other people also worked on that file | 15:45 |
| wgrant | sinzui: When I checked a month ago that passed everywhere except Windmill. Even in the same browser, it passed fine if not run under Windmill. | 15:46 |
| wgrant | That may not still be the case. | 15:46 |
| sinzui | bugger. I think I need to investigate pywebkit again as an alternative browser to run yuitest | 15:50 |
| jcsackett | sinzui: which do you think works better for us? prepare a branch to fix stuff that may take a bit, or roll back the link-in? | 15:52 |
| jcsackett | (assuming doing so fixes some of these tests). | 15:52 |
| sinzui | jcsackett: does rolling back mean you concede your implementaion? Isn't your design the one recommended by deryck? | 15:54 |
| jcsackett | sinzui: deryck thought that creating a proper widget would be easier than shimming picker.create. i think that's still true. | 15:54 |
| jcsackett | i'm not rolling back the creation of the personpicker; just rolling back the changes that plug it into the UI, pending the problems brought up. | 15:54 |
| jcsackett | alternatively, we just need more branches to patch these holes. | 15:55 |
| jcsackett | but it would seem that there's a level of brokeness currently introduced we should rollback before plugging things back in. | 15:55 |
| sinzui | jcsackett: lets rollback then | 15:56 |
| jcsackett | sinzui: dig. | 15:56 |
| jcsackett | sinzui: bit of time to chat? might be quicker to make sure i'm on the same page. :-) | 15:56 |
| gary_poster | matsubara, hi. did my email make sense? any confusions? | 15:58 |
| matsubara | gary_poster, yes, it made sense. I'm testing right now. found some small issues, I'll put everything on the wiki once I'm done | 15:59 |
| gary_poster | awesome, thanks matsubara | 15:59 |
| jcsackett | hm. sinzui, nevermind the rollback. i misread some email. the second person-picker branch didn't land, so anything wrong with the picker is not yet in the tree. | 16:00 |
| jcsackett | or rather, not yet in the YUI in the tree. | 16:00 |
| jcsackett | so i'll see about fixing some of this today in a new branch. | 16:00 |
| jcsackett | lord, i fail at typing. "not yet in the web UI in the tree." there. that's right. | 16:01 |
| sinzui | jcsackett: I cannot see anyone's typing errors :) | 16:08 |
| * sinzui is not sure he see conjugation | 16:09 | |
| * jcsackett laughs. | 16:13 | |
| jcsackett | so, sinzui, have a bit of time to chat? | 16:14 |
| sinzui | in a moment | 16:15 |
| jcsackett | sure. | 16:17 |
| sinzui | jcsackett: I can talk now | 16:26 |
| === al-maisan is now known as almaisan-away | ||
| bac | hi matsubara | 16:42 |
| matsubara | hi bac | 16:42 |
| flacoste | bac: do you feel like reviewing a largish branch (lots of delete on it)? | 17:01 |
| flacoste | it's over 1500 lines | 17:02 |
| flacoste | the core changes is less than 500 lines | 17:02 |
| flacoste | a permission change that had a lot of tests fallout | 17:03 |
| === deryck is now known as deryck[lunch] | ||
| timrc | abentley, thanks for the quick turn around time on those api changes! | 17:11 |
| abentley | timrc: no problem. Enjoy.' | 17:11 |
| matsubara | gary_poster, danilos: I broke the +subscriptions page heh | 17:20 |
| danilos | matsubara, it probably wasn't you! ;) | 17:29 |
| danilos | matsubara, (iow, we broke it :)) | 17:29 |
| danilos | anyway, I am out for the week, file bugs and I'll be looking at them on Monday | 17:29 |
| matsubara | danilos, https://bugs.launchpad.net/launchpad/+bug/792445 | 17:31 |
| _mup_ | Bug #792445: It's possible to create the same subscription over and over again <exploratory-testing> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/792445 > | 17:31 |
| gmb | Any bzr-savvy people know what this means? "bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:d34f39faee56e120a83e7cec4fe01c4fd5fd32f6',)] | 17:39 |
| gmb | " | 17:39 |
| gmb | It's what caused the latest build failure on db-devel. | 17:39 |
| matsubara | gary_poster, I wrote down some of my findings in https://dev.launchpad.net/QA/ExploratoryTesting/BugSubscriptionFeature at the bottom (Second round of testing). there were 3 other issues when I did the initial testing but they were fixed after the staging update. I'm going for lunch now and will continue testing later on and file bugs, etc | 17:40 |
| === matsubara is now known as matsubara-lunch | ||
| === salgado is now known as salgado-lunch | ||
| === deryck[lunch] is now known as deryck | ||
| gary_poster | matsubara, cool, thanks | 18:27 |
| gary_poster | subscribe/unsubscribe for anonymous is good catch | 18:27 |
| gary_poster | Creating multiple identical subscriptions is not a problem in my book | 18:28 |
| gary_poster | If you don't allow it, then you get into weird situations | 18:29 |
| gary_poster | like disallowing modification of a subscription because it would make it just like an existing one | 18:29 |
| gary_poster | and that might even just be a transitional step while you adjust things | 18:29 |
| gary_poster | batching is a separate aspect of this | 18:29 |
| gary_poster | Having many, many pertinent subscriptions is a broken use case IMO; supporting it gracefully is a low priority IMO | 18:30 |
| bac | flacoste: sure, i'll be glad to look at it | 18:31 |
| flacoste | bac: thanks a million | 18:32 |
| flacoste | bac: https://code.launchpad.net/~flacoste/launchpad/bug-365098/+merge/63305 | 18:32 |
| flacoste | bac: important changes are in canonical.launchpad.security, lib/lp/registry/model/sourcepackage.py, lib/lp/registry/interfaces/sourcepackage.py andlib/lp/registry/tests/test_sourcepackage.py | 18:35 |
| bac | thanks flacoste. just reading your MP | 18:35 |
| flacoste | rest are tests fallout | 18:35 |
| === salgado-lunch is now known as salgado | ||
| deryck | abentley, did you spend any interrupt time on the burn down lists today? | 19:33 |
| abentley | deryck: no, not yet. | 19:34 |
| deryck | abentley, I just caught them all up. if you could take a quick peak before you EOD, they should be good for yellow squad next week. | 19:34 |
| abentley | deryck: cool. | 19:34 |
| deryck | thanks, man! | 19:34 |
| flacoste | deryck: didn't somebody fix something similar to bug 410864 recently? | 19:49 |
| _mup_ | Bug #410864: 'choose a source package' suggests undefined when search has too many results <LAZR Javascript Library:Triaged> < https://launchpad.net/bugs/410864 > | 19:49 |
| flacoste | or sinzui? | 19:49 |
| deryck | flacoste, yes, henning did. | 19:50 |
| flacoste | deryck: could he or you validate that this one is also fixed and mark it as so? | 19:50 |
| flacoste | as such | 19:50 |
| deryck | flacoste, sure. | 19:51 |
| deryck | flacoste, I'll try to look today, and if not, ask him Monday. | 19:51 |
| deryck | flacoste, looking at his diff, I would imagine it covers all pickers. he changed picker.js in our tree. | 19:53 |
| deryck | flacoste, yeah, I did some qa. it's definitely fixed. | 20:16 |
| SpamapS | flacoste: So, I can't file bugs against the packages in principia | 20:17 |
| SpamapS | "haproxy" does not exist in Principia Ensemble. Please choose a different package. If you're unsure, please select "I don't know" | 20:17 |
| SpamapS | flacoste: is this because its checking to see if there is at least one build? | 20:17 |
| flacoste | SpamapS: yes, that's bug 781993 | 20:19 |
| _mup_ | Bug #781993: cannot file bugs on source packages that have not been published <bugs> <escalated> <not-pie-critical> <principia> <stakeholders> <Launchpad itself:In Progress by flacoste> < https://launchpad.net/bugs/781993 > | 20:19 |
| SpamapS | flacoste: "me too'd" and subscribed, thanks. | 20:20 |
| timrc | lifeless, I submitted a merge proposal for #724740, I currently have cody-somerville taking a look, but is there someone within the LP org that will also need to review? | 20:35 |
| _mup_ | Bug #724740: setting a ppa private cannot be done over the API <api> <oem-services> <ppa> <Launchpad itself:In Progress by timrchavez> < https://launchpad.net/bugs/724740 > | 20:35 |
| cody-somerville | timrc, I imagine lifeless might be sleeping right now. | 20:36 |
| cody-somerville | timrc, However, the answer is probably yes. | 20:36 |
| timrc | cody-somerville, he never sleeps | 20:37 |
| abentley | timrc: if he's asleep at 7:37 his time, he's sleeping in. | 20:37 |
| cody-somerville | I'm always asleep at 7:37. | 20:38 |
| timrc | cody-somerville, that's because you go to bed at 5 | 20:38 |
| lifeless | it is saturday ;) | 20:45 |
| lifeless | cats have been running rampant for an hour now | 20:45 |
| lifeless | timrc: yes, one of the LP reviewers will need to review | 20:45 |
| statik | lifeless: since you are here, a very quick question: the GPG validation microservice that you asked for prototype implementations of, I would like clarification of the exposed API | 20:46 |
| lifeless | shoot | 20:47 |
| statik | "takes crypt text in and returns the signer, cleartext". Does that mean that the service is expected to have the private keys available to it? | 20:47 |
| lifeless | oh | 20:47 |
| statik | i'm mixed up about whether this is a decryption service or a gpg validation service | 20:47 |
| lifeless | so thats a lingo thing | 20:47 |
| lifeless | the crypt text is the signed document | 20:48 |
| statik | perfect | 20:48 |
| statik | and the cleartext is the content that was wrapped in the signature? | 20:48 |
| lifeless | or for detached sigs (but I don't think we do them today) it would be (the signature, text) tuple. | 20:48 |
| lifeless | statik: yes, thats right | 20:48 |
| statik | lifeless, thanks! I'll update the wiki | 20:48 |
| lifeless | thank you | 20:49 |
| abentley | lifeless: AIUI, documents can have multiple signed parts. Maybe you want a list of signer/cleartexts? | 20:51 |
| lifeless | abentley: for our use cases today I believe that that would be an error | 20:51 |
| lifeless | they are - coc, source package uploads, control-of-signature proof. | 20:52 |
| lifeless | s/signature/key/ | 20:52 |
| maxb | This is very weird. bac just closed bug 296365. The bug is linked to question 75760. LP sent me an email about linked bug status changing, but the textual message included in the email is not the one bac entered as comment #8, it's the one sinzui entered as comment #5 two years ago! | 20:58 |
| _mup_ | Bug #296365: oops when responding to merge proposal review via email <email> <lp-foundations> <oops> <Launchpad itself:Invalid> < https://launchpad.net/bugs/296365 > | 20:58 |
| abentley | deryck: I'm doing the interrupt stuff now, and it's mostly very clean, but I think you forgot about RT. | 20:59 |
| deryck | abentley, I looked. it looked like all spam to me, and I didn't see instructions on how to deal with it.... | 20:59 |
| bac | maxb: that is odd | 20:59 |
| deryck | abentley, so I made a note to ask mrevell next week. | 20:59 |
| abentley | deryck: Oh. I've been hitting "resolve" and setting the status to "deleted". | 21:00 |
| deryck | abentley, ah, ok. that makes sense. | 21:00 |
| deryck | abentley, I'll do that as well from now on. | 21:00 |
| lifeless | deryck: what was the relevation ? | 21:15 |
| deryck | lifeless, that critical is not drop-everything-and-do-it-now but do-next. | 21:15 |
| lifeless | right | 21:15 |
| deryck | or rather do-fist when pulling new work | 21:16 |
| lifeless | uhm, I guess we failed to really communicate that change | 21:16 |
| deryck | yeah, I think so. | 21:16 |
| lifeless | critical as drop-everying-work-24-hours doesn't really make sense | 21:16 |
| deryck | I sort of knew it, but it didn't make sense. | 21:16 |
| deryck | we've ingrained critical as don't-stop-til-it's-fixed work for so long, it's hard to get free of that. | 21:17 |
| lifeless | fwiw as I understand Ubuntu's use of critical it is identical to ours | 21:17 |
| lifeless | *incidents* are don't stop :) | 21:17 |
| lifeless | but they are often not code bugs | 21:17 |
| deryck | it makes perfect sense when you realize the high bugs list is so long it's useless. you need a real high category. that's how I think of it now. | 21:18 |
| lifeless | yeah | 21:18 |
| deryck | useless is a bit strongly worded, but I hope you get my meaning | 21:18 |
| lifeless | does this interact with that hi pressure discussion we had last week? | 21:18 |
| deryck | yes, I feel better about marking ui regression bugs critical now, given that understanding of critical. | 21:19 |
| lifeless | cool | 21:19 |
| deryck | I would bet I am not allow in lp devs in not understanding this, too. | 21:20 |
| deryck | I think about bugs and statuses a lot and missed the direct meaning. | 21:20 |
| lifeless | we updated our docs when we shuffled this around back in oh feb | 21:21 |
| lifeless | perhaps you could check that its clear enough to carry the message, and perhaps even mail the list with pointers ? | 21:21 |
| lifeless | I'd hate for other folk to be unnecessarily stressed | 21:21 |
| deryck | sure. | 21:21 |
| deryck | I think its the way "burn the list to 0" meshes with the status that is confusing. | 21:22 |
| deryck | we beat the drum of clearing the list, as if this is don't-stop work, but in reality we're queuing up the next queue. | 21:22 |
| deryck | now I understand the next queue needs to be small enough to manage. I'm not arguing over that. | 21:22 |
| deryck | and FWIW, people don't get meaning from wiki pages much. it's more the day to day conversations. | 21:23 |
| lifeless | So the idea is that normally there will be approximately nothing in critical | 21:23 |
| lifeless | but if we have to queue jump some task, it will go into critical | 21:23 |
| lifeless | and get picked up by the next free engineer in a maintenance squad | 21:24 |
| deryck | sure, I get that. but that's more in line with a stop-the-line and do this work flow, then what we have now. | 21:24 |
| deryck | it's the world 3-5 months from now, not now. ;) | 21:24 |
| lifeless | right | 21:24 |
| lifeless | we gotta clear the decks | 21:24 |
| deryck | sure, agreed. | 21:24 |
| lifeless | lots of bird poop piled up :) | 21:24 |
| deryck | indeed :0 | 21:24 |
| deryck | :) | 21:24 |
| flacoste | SpamapS: nice blog post on ensemble! | 21:42 |
| flacoste | we now really need to fix these LP bugs as people will report bugs on principia! | 21:42 |
| SpamapS | Heh, yeah. | 21:44 |
| SpamapS | Maybe I should change the pre-bug-report text to make it clear you can't report against a formula yet? | 21:44 |
| LPCIBot | Project windmill-db-devel build #361: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/361/ | 22:48 |
| === bac changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs:208 - 0:[######=_]:256 | ||
| === matsubara is now known as matsubara-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
