| poolie | huwshimi, hooray for starting somewhere | 00:40 |
|---|---|---|
| huwshimi | poolie: Haha. | 00:41 |
| huwshimi | poolie: For too long I've been paralised by Launchpad not having the infrastructure to do things properly. | 00:43 |
| huwshimi | poolie: Making the infrastrucuture right has resulted in a trade-off for good UX in Launchpad | 00:44 |
| huwshimi | poolie: Now I don't care about the infrastructure, I just want the UX to be good | 00:44 |
| huwshimi | *flame war, GO!* | 00:46 |
| lifeless | infrastructure for its own sake is waste ;) | 00:53 |
| lifeless | huwshimi: I totally applaud reasoned cutting-of-gordian-knots, which I think you are doing here. | 00:57 |
| huwshimi | lifeless: And likewise, I'm all for proper infrastructure | 00:58 |
| huwshimi | I actually really can't stand doing things poorly. I've just gotten to the point that I'd rather do things poorly than not at all at the moment | 01:01 |
| lifeless | huwshimi: One thing launchpad has gotten stuck on in the past is defining 'right' - and ended up with bells and whistles we don't need. | 01:03 |
| lifeless | We also tend to focus too much on doing it all ourselves, IMO | 01:03 |
| * poolie cheers | 01:05 | |
| poolie | i still like the idea of accumulating even just a set of screenshots of things we think were done right | 01:06 |
| poolie | by way of a cheap style guide | 01:06 |
| huwshimi | lifeless: Also as this is the web we should be architecting for change | 01:06 |
| lifeless | huwshimi: of course! you've seen my slides, right :) | 01:07 |
| wgrant | Launchpad has never done any sort of, well, design or architecture. | 01:07 |
| wgrant | Except when it designs things too much and badly. | 01:07 |
| lifeless | wgrant: you may find yourself stepping on toes if you don't qualify things a little :) | 01:08 |
| huwshimi | lifeless: Are they slides from Dallas? | 01:08 |
| huwshimi | or dublin | 01:08 |
| lifeless | huwshimi: prague and dallas | 01:09 |
| huwshimi | lifeless: Are they online somewhere, I remember your talk, but don't remember all the details | 01:09 |
| lifeless | let me get you a link | 01:09 |
| lifeless | there is one in the wiki under ArchitectureGuide, but also .. | 01:09 |
| lifeless | https://docs.google.com/present/edit?id=0AR8DGdpwOJuiZGdwZGNmbjlfMTFoY2Nwcm1ocw&authkey=CMiPvu0F | 01:10 |
| lifeless | and | 01:10 |
| lifeless | https://docs.google.com/a/canonical.com/present/edit?id=0AR8DGdpwOJuiZGdwZGNmbjlfNGZkNDZmZ2N6&authkey=CJWpj5EN&hl=en_US | 01:10 |
| lifeless | blargh, if either don't work let me know :) | 01:10 |
| huwshimi | lifeless: They, work. Just taking a look | 01:11 |
| poolie | huwshimi, the question came up the other day of: why do the importance labels look like "tags" or labels | 01:16 |
| poolie | not sure if you were here for it but i'm curious if you know | 01:17 |
| huwshimi | poolie: There's no real science behind it. It's a very common design pattern for representing importance or status. Both importance and status were displayed like that in early mockups | 01:18 |
| poolie | it's ok with me | 01:27 |
| lifeless | wgrant: sob | 01:52 |
| lifeless | wgrant: 'TypeError: Could not serialize object set([u'OOPS-ABCDEF1234']) to JSON'. | 01:53 |
| lifeless | wgrant: is this just cruft - e.g. if I list() it, its good ? | 01:53 |
| lifeless | [list works] | 01:54 |
| wgrant | omg optus finally fixed it. | 01:56 |
| wgrant | lifeless: Yep, listing it should work fine. | 01:56 |
| StevenK | wgrant: It's only taken them until 1pm | 01:58 |
| wgrant | It's apparently been broken since 3am or so. | 01:58 |
| StevenK | So 10 hours of international routing being broken. Epic. | 01:59 |
| wgrant | Only for most of Europe. | 01:59 |
| wgrant | Which nobody cares about, I guess. | 01:59 |
| lifeless | and with that, oops-prune is dead. | 02:09 |
| lifeless | I need a hero^Wreviewer https://code.launchpad.net/~lifeless/launchpad/bug-888375/+merge/81928. | 02:15 |
| huwshimi | wallyworld_: Not sure if you saw my last message yesterday about that javascript I was working on. I changed the io events and also fixed things up so they use classes instead of styles for show/hide. Do you want to give that one last look? https://code.launchpad.net/~huwshimi/launchpad/tag-cloud-removal-709009/+merge/81689 | 02:15 |
| wallyworld_ | huwshimi: looking now | 02:16 |
| huwshimi | wallyworld_: Thanks, no hurry | 02:16 |
| wallyworld_ | lifeless: i'll look at your mp too :-) | 02:16 |
| lifeless | thanks | 02:18 |
| wallyworld_ | huwshimi: looks good. were you going to write or update any yui tests? | 02:19 |
| huwshimi | wallyworld_: Erm, I didn't look | 02:19 |
| huwshimi | wallyworld_: I guess I'll need to have a look as I've moved this code around (I didn't write most of it, just fixed it up) | 02:20 |
| wallyworld_ | huwshimi: understood. it's was naughty for it to be approved without any questions about tests :-) | 02:20 |
| huwshimi | wallyworld_: :) | 02:21 |
| wallyworld_ | lifeless: do we want to make the search interval half closed as is common with date/time based searches? | 02:32 |
| lifeless | wallyworld_: I don't think we care | 02:33 |
| wallyworld_ | or allow one of the start/end dates to be None, perhaps with a sensible default to disallow too broad an interval | 02:33 |
| lifeless | I think thats overthinking it | 02:33 |
| wgrant | SIGH | 02:34 |
| wgrant | It is broken again. | 02:34 |
| wallyworld_ | i would care because if you want all oops for a particular day, you would normally do 1/1/2009 00:00 <= date < 2/1/2009 00:00 for example | 02:34 |
| lifeless | our replication strategy alone means the former wouldn't be sufficient and the latter is unneeded - oops will always care about exact end dates as they won't be pruning very new things | 02:34 |
| wallyworld_ | ok | 02:35 |
| lifeless | wallyworld_: between is fully open | 02:36 |
| lifeless | wallyworld_: a BETWEEN x AND y | 02:36 |
| lifeless | -> | 02:36 |
| lifeless | a >= x AND a <= y | 02:36 |
| wallyworld_ | hmm. i checked the online. the example given was fully closed | 02:36 |
| lifeless | wallyworld_: so naive use will Just Work anyhow (subject to replication lag etc etc if we ever get the API running on slaves) | 02:36 |
| wallyworld_ | but it could be wrong | 02:36 |
| lifeless | http://www.postgresql.org/docs/8.4/static/functions-comparison.html | 02:36 |
| wallyworld_ | should there be asserts / ValueError checks to catch None dates being passed in then? also context_params is not checked for None. do we care? | 02:36 |
| lifeless | 'addition to the comparison operators, the special BETWEEN construct is available: | 02:37 |
| lifeless | a BETWEEN x AND y | 02:37 |
| lifeless | is equivalent to | 02:37 |
| lifeless | a >= x AND a <= y | 02:37 |
| lifeless | ' | 02:37 |
| lifeless | context_params is internal code only | 02:37 |
| lifeless | date ranges are the only thing clients are permitted to influence | 02:37 |
| lifeless | if they pass none in, it will do date between NULL AND <other> | 02:37 |
| wallyworld_ | internal code can still be buggy :-) but fair enough | 02:38 |
| lifeless | which will match nothing (as null operator foo -> false) | 02:38 |
| lifeless | wallyworld_: it can be, which is why there are two ws tests that test the product and distribution glue is correct | 02:38 |
| wallyworld_ | ok. thanks for clarifying :-) | 02:39 |
| lifeless | wallyworld_: I will teak the interface docstring | 02:39 |
| lifeless | wallyworld_: to avoid folk getting confused and thinking its like a slice vis-a-vis None | 02:39 |
| wallyworld_ | cool. that would be good, since what's there is open to assumptions :-) | 02:39 |
| wallyworld_ | lifeless: i can't see the replacement pruning functionality. there's apis to search for oopses but the pruning capability has been deleted ans there's no replacement in this mp? | 02:54 |
| lifeless | thats right | 02:55 |
| lifeless | its no longer a launchpad concern | 02:55 |
| lifeless | it should never have been part of the LP tree anyway :) | 02:56 |
| wallyworld_ | sure. just checking that we weren't losing expected functionality | 02:56 |
| wallyworld_ | s/expected/required | 02:56 |
| lifeless | oh we are | 02:56 |
| lifeless | just it won't be coming back to the LP tree | 02:56 |
| lifeless | separate project now | 02:56 |
| wallyworld_ | and it's ready to go? or will we go without pruning for a bit? | 02:57 |
| lifeless | python-oops-datedir-repo | 02:57 |
| lifeless | its about an hours work | 02:57 |
| lifeless | :) | 02:57 |
| wallyworld_ | ok | 02:57 |
| wallyworld_ | famous last words :-) | 02:57 |
| lifeless | getting it deployed will take longer | 02:57 |
| wallyworld_ | so we can afford not having oops pruning for X interval till it gets done i guess | 02:58 |
| lifeless | yes | 02:58 |
| lifeless | carob suffers before the appservers do | 02:59 |
| huwshimi | Does a + in one of our urls signify a static path (as opposed to dynamic data e.g. launchpad.net/dynamic/+static/)? Do all our URLs follow this pattern? | 02:59 |
| lifeless | and right now, for staging oopses, it has no pruning, because this APi isn't here, but they are using the amqp oops path | 02:59 |
| wallyworld_ | thanks. i'm quite ignorant of our deployment requirements, so just wanted to check :-) | 02:59 |
| lifeless | huwshimi: the + indicates a view of an object | 02:59 |
| huwshimi | lifeless: Oh | 03:00 |
| lifeless | huwshimi: so /~person/+index is the actual url for /~person | 03:00 |
| lifeless | huwshimi: its a bit bong | 03:00 |
| lifeless | huwshimi: it has a few reasons behind it, but it gets in the way too | 03:00 |
| huwshimi | lifeless: So in a hypothetical world where we would map bugs.launchpad.net to a new URL would it be launchpad.net/launchpad/bugs or launchpad.net/launchpad/+bugs? | 03:01 |
| lifeless | huwshimi: there are plenty of options | 03:01 |
| lifeless | huwshimi: bugs.l.n has a distinct view from code.l.n, but you could do launchpad.net/+bugs-index and launchpad.net/+code-index | 03:02 |
| lifeless | for instance | 03:02 |
| huwshimi | lifeless: OK thanks, it's not a problem now, I was just trying to understand how the +s work | 03:03 |
| lifeless | de nada | 03:03 |
| wgrant | huwshimi: + is mostly used to disambiguate system- and user-controlled path segments. Since it's not permitted as the first character of a Launchpad name, we can support paths like /PROJECT/SERIES and /PROJECT/+bug/BUG without conflicts. It's also used in view names (eg. +bugs, +index), for similar reasons. | 03:08 |
| wgrant | So yes, basically what you said. | 03:09 |
| wgrant | There are some old paths where that doesn't hold true. | 03:09 |
| wgrant | eg. /bugs/BUG | 03:09 |
| wgrant | But it applies to most places. | 03:09 |
| huwshimi | wgrant: Great, good to know. | 03:09 |
| lifeless | /bugs/BUG was deliberate | 03:11 |
| lifeless | we don't need to use it for new stuff, though it is a safe default | 03:11 |
| huwshimi | lifeless: I imagine if we did map our subdomains then bugs.launchpad.net/ would become launchpad.net/bugs/ so /bugs/BUG would make even more sense | 03:15 |
| lifeless | huwshimi: if we consolidate, I'd really love to see the namespace not deepend | 03:15 |
| lifeless | huwshimi: would launchpad.net/$project -> homepage; click on bugs there, be ok ? I think google code basically do this.. | 03:16 |
| lifeless | huwshimi: or perhaps make 'bugs' subordinate to the project context :) | 03:16 |
| huwshimi | lifeless: Sorry, I'm not quite sure what you mean? | 03:19 |
| huwshimi | lifeless: I would imagine you would have something like launchpad.net/launchpad/+bugs, launchpad.net/launchpad/+translations etc. | 03:19 |
| huwshimi | lifeless: I was saying launchpad.net/bugs/ would become a homepage for bugs like bugs.launchpad.net is now (if we decided we still wanted it) | 03:20 |
| huwshimi | lifeless: Is that what you were asking? | 03:20 |
| wgrant | That's how it was originally, actually. | 03:20 |
| wgrant | until 2006ish. | 03:20 |
| huwshimi | wgrant: April, 2006 | 03:21 |
| wgrant | huwshimi: How'd you work that out? | 03:22 |
| huwshimi | wgrant: http://www.markshuttleworth.com/archives/30 | 03:23 |
| wgrant | A-ha. | 03:23 |
| nigelb | What happened to Applications on subdomains? :) | 03:24 |
| wgrant | nigelb: That's what we have now. | 03:25 |
| lifeless | huwshimi: I thought you meant e.g. bugs.l.n/launchpad/+bugs?field.. -> l.n/bugs/launchpad/+bugs?field.. | 03:25 |
| wgrant | And have had for several years. | 03:25 |
| lifeless | huwshimi: which I think would be ugly | 03:25 |
| nigelb | wgrant: Ah. Launchpad applications. Right. | 03:25 |
| nigelb | I confused that with projects. | 03:25 |
| huwshimi | lifeless: Oh, yeah, not at all. Let's make the project the base and tack the app url on after that somehow | 03:25 |
| lifeless | huwshimi: I think that makes a lot of sense | 03:26 |
| huwshimi | lifeless: :D | 03:26 |
| huwshimi | wgrant: It's funny, there's a few things I think we got right a few years ago that I would like to revert to :) | 03:31 |
| wgrant | huwshimi: Yeah... | 03:31 |
| lifeless | wgrant: can you check I transcribed your fix for bug 884265 correctly ? | 03:32 |
| _mup_ | Bug #884265: req_vars header values may cause crash in dboopsloader <python-oops-tools:Triaged> < https://launchpad.net/bugs/884265 > | 03:32 |
| mwhudson | let's all go back to arch! | 03:32 |
| wgrant | mwhudson: A sound plan. | 03:32 |
| lifeless | wgrant: and if so, approve my MP ? | 03:32 |
| wgrant | lifeless: Your MP being rye's? | 03:33 |
| lifeless | no | 03:34 |
| lifeless | t'other one | 03:34 |
| wgrant | Ah. | 03:34 |
| wgrant | Which was created after I last looked. | 03:34 |
| wgrant | approvated | 03:35 |
| poolie | huwshimi, "a normal ux" | 04:09 |
| poolie | awesome | 04:09 |
| poolie | i think even google seems to be going away from having separate subdomains? | 04:09 |
| lifeless | can has review? https://code.launchpad.net/~lifeless/python-oops-tools/bug-888866/+merge/81933 | 04:10 |
| poolie | it's hard to tell | 04:10 |
| poolie | but the calendar is now google.com/calendary | 04:10 |
| nigelb | huwshimi: I like this going back to no subdomains thing ;) | 04:12 |
| poolie | me too | 04:12 |
| wgrant | It's also pretty damn easy to move away from subdomains. | 04:12 |
| poolie | i would like to see a mockup of what the navigation ought to look like | 04:12 |
| wgrant | We've had so many different navigation UIs over the years. | 04:12 |
| wgrant | None of them have worked :/ | 04:12 |
| poolie | huwshimi, one interesting thing from gdd was their stuff about breadcrumby/back-stack navigation in android | 04:12 |
| wgrant | And now GitHub has basically reproduced LP 2.0 | 04:12 |
| poolie | it does not map totally directly | 04:12 |
| poolie | but there are some ideas | 04:13 |
| poolie | is that good or bad? | 04:13 |
| poolie | specifically they have a plain 'back', crossing application or other activity boundaries | 04:13 |
| poolie | and also an 'up' | 04:13 |
| nigelb | wgrant: heh, yeah. | 04:13 |
| poolie | taking you towards the top level of that particular application | 04:13 |
| poolie | obviously for us its complex because there is browser back, and also going back towards the lp app root vs the pillar root | 04:14 |
| poolie | but, perhaps we want to emphasize the latter | 04:14 |
| lifeless | can has review ? https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-888866/+merge/81937 | 04:50 |
| lifeless | well, EOD for me. | 04:51 |
| lifeless | EOW even | 04:52 |
| poolie | cheerio lifeless | 05:20 |
| poolie | wgrant, ok, the package style is a bit more modern now | 05:20 |
| StevenK | Does it make use of dh 7 yet? | 05:23 |
| wgrant | hardy doesn't have dh7, but cat should if you want it. | 05:41 |
| StevenK | Oh, drat. Hardy | 05:43 |
| micahg | hardy-backports has dh7 :) | 06:25 |
| poolie | it doesn't | 06:33 |
| poolie | that doesn't seem high on the list of issues | 06:33 |
| poolie | should i add this to just launchpad-dependencies, or something more specific? | 06:35 |
| poolie | which one is used to run tests i wonder | 06:35 |
| poolie | developer dependencies apparently | 06:37 |
| huwshimi | Have a good weekend all! | 06:38 |
| poolie | you too | 06:38 |
| wgrant | poolie: launchpad-developer-dependencies, probably. | 06:42 |
| poolie | yep, done and pushed | 06:43 |
| poolie | do i _have_ to update the ec2 image for new dependencies? | 06:50 |
| wgrant | Yes. | 06:51 |
| poolie | can't it just install them when it boots? | 06:51 |
| wgrant | It doesn't apt-get upgrade | 06:51 |
| StevenK | No | 06:51 |
| poolie | could it? | 06:51 |
| poolie | so, to me it really does look like it does an apt-get upgrade | 07:03 |
| poolie | but that may be a decoy | 07:03 |
| StevenK | poolie: The only case that does is the AMI upgrade path | 07:46 |
| poolie | yeah, but istm i can, and might as well, just do it when a real test is booting | 07:47 |
| StevenK | I don't like that idea. | 07:47 |
| StevenK | Some tests on ec2 are fragile enough without adding more changes. | 07:47 |
| poolie | mm | 07:48 |
| poolie | but this is fairly determinisitic | 07:48 |
| poolie | and brings the tests closer to what people will experience elsewhere | 07:48 |
| StevenK | We have been on rev 522 for over one month | 07:49 |
| StevenK | And given it takes about an hour to make a new AMI, I don't think the cost is high at all. | 07:50 |
| poolie | !! | 07:50 |
| poolie | i think an hour of avoidable works' pretty high | 07:51 |
| StevenK | It isn't an hour of work. It's one command and wait an hour | 07:51 |
| StevenK | Much like our test suite | 07:51 |
| poolie | that's worth cutting down too | 07:51 |
| poolie | an hour of latency is also worth cutting out | 07:51 |
| StevenK | I would seriously prefer you just make a new AMI and bring up changing it on the mailing list. | 07:52 |
| poolie | i am running my test in this now | 07:52 |
| poolie | which seems equivalent | 07:52 |
| StevenK | And I submit that changing it and then announcing it is as much akin to what you almost accussed me of with +personal. | 07:53 |
| poolie | oh | 07:53 |
| poolie | i'm just going to put up an mp | 07:53 |
| poolie | i'm not going to just change the ami | 07:53 |
| poolie | in fact i'm pretty sure i am not trusted to change the ami, which is another reason i looked at just updating the single machine | 07:54 |
| poolie | and i did ask about it here | 07:54 |
| StevenK | poolie: Have a look at lib/devscripts/ec2test/account.py, line 25 on. | 07:55 |
| poolie | as i suspected, it's out of date :) | 07:56 |
| poolie | wrt henninge | 07:56 |
| StevenK | We don't remove people | 07:56 |
| StevenK | And I suspect adding your ID there would not cause much of an issue | 07:57 |
| poolie | yeah i could | 07:57 |
| StevenK | We can probably remove henning, salgado, jml | 07:57 |
| poolie | i think current staff who are no longer on the lp team is a bit different | 08:00 |
| poolie | but, maybe still least privilege | 08:00 |
| === wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 275 | ||
| jml | actually, that reminds me, I need to delete my LP image | 08:44 |
| jml | it's costing me US$0.53 and £2 each month in Amazon & then bank fees. | 08:44 |
| StevenK | 2GBP is a bit steep | 08:55 |
| mrevell | Hello | 09:14 |
| danhg | Morning Everyone | 09:18 |
| adeuring | good morning | 09:20 |
| === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugtasks: 275 | ||
| jam1 | I thought the new fast-oops was deployed. I got an OOPS trying to list my branches in a project page, but the oops (with a hash) hasn't shown up after about 10 min | 11:17 |
| === jam1 is now known as jam | ||
| jam | https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-55ae33da0714197906011068d73e95f3 if people care | 11:17 |
| rvba | jam: fast-oops is not yet deployed in production. | 11:17 |
| jam | ah, I thought robert said that it will show up once we switch to hash-based ids | 11:19 |
| jam | anyway, https://bugs.launchpad.net/launchpad/+bug/889042 | 11:19 |
| _mup_ | Bug #889042: OOPS while viewing branch listing for ~user/project <Launchpad itself:Triaged> < https://launchpad.net/bugs/889042 > | 11:19 |
| jam | browsing to a per-user branch listing tracebacks | 11:20 |
| rvba | jam, hum, that's related to the new branch menu recently introduced, I think it's worth disabling the flag until the problem that you just had is solved… I'll take care of that… | 11:22 |
| jam | rvba: thanks. code.lpn/~jameinel works but code.lpn/~jameinel/project doesn't | 11:25 |
| * nigelb wonders what mrevell was testing | 11:33 | |
| mrevell | nigelb, hmm? | 11:36 |
| mrevell | nigelb, Oh, the mailing list archive seems to be delayed by a couple of days | 11:36 |
| nigelb | ah, nice :) | 11:36 |
| nigelb | I did ask wgrant about it some days ago. | 11:37 |
| nigelb | err weeks | 11:37 |
| nigelb | Back then it was hours, not days. | 11:37 |
| rvba | jam: the flag has been removed so this should be back to normal, thanks for reporting this. | 11:46 |
| jam | rvba: confirmed, my ~user/project page loads now | 11:47 |
| deryck | Morning, all. | 12:49 |
| rick_h | morning | 12:53 |
| rvba | Hi adeuring, would you have time to have a look at this MP? https://code.launchpad.net/~rvb/launchpad/bug-889042/+merge/81988 | 14:26 |
| adeuring | rvba: sure | 14:26 |
| flacoste | mrevell, sinzui, gnuoy, allenap: i realy doubt that the delays in mail being sent out is related to the delays in mail archiving | 14:27 |
| rvba | adeuring: thank you. The diff should be available shortly… | 14:27 |
| flacoste | mailman is using separate queue runner for all these aspects | 14:27 |
| sinzui | flacoste, as wgrant remarked, there is a lot of list traffic in ubuntu-x-swat maybe | 14:28 |
| flacoste | that's a more likely explanation | 14:28 |
| flacoste | in the past we had issues with the xmlrpc calls timing out, but that was fixed i think | 14:29 |
| flacoste | is mailman the bottleneck or our stmp server? | 14:29 |
| flacoste | also, mrevell tests seem to have been near instantaneous | 14:29 |
| gnuoy | flacoste there is no backlog in exim | 14:29 |
| flacoste | is there a backlog in mailman? | 14:29 |
| mrevell | Daviey, Is there still a backlog for the openstack list? | 14:30 |
| mrevell | Daviey, I mean delay | 14:30 |
| deryck | adeuring, https://dev.launchpad.net/QA/ExploratoryTesting/CustomBugListings | 14:33 |
| deryck | abentley, https://dev.launchpad.net/QA/ExploratoryTesting/CustomBugListings | 14:33 |
| Daviey | mrevell: The archive doesn't seem to be showing recent mail, https://lists.launchpad.net/openstack/ | 14:35 |
| Daviey | regarding actual mail, i'm not sure. | 14:35 |
| sinzui | Why are there always 3 new bugs? I have checked for private new bugs that we might be be subscribed too, but there are none in production | 14:42 |
| flacoste | Daviey: right, mailing list archives isn't expected to work, a work around is to visit mail-archives.org | 14:42 |
| flacoste | all your lists are archived there in real-time | 14:42 |
| Daviey | flacoste: for the nosey, why is that? | 14:46 |
| flacoste | actually, it's mail-archive.com | 14:47 |
| sinzui | excellent, staging is broken in the same way. | 14:47 |
| flacoste | Daviey: because originally we didn't want to host archives ourself, because there is no good software for it | 14:48 |
| Daviey | ah | 14:48 |
| flacoste | down the line we decided to do a dirt-cheap solution | 14:48 |
| flacoste | but that's what we have now | 14:48 |
| flacoste | dirt-cheap | 14:48 |
| flacoste | that doesn't work most of the time | 14:48 |
| deryck | Seems odd to me we have the same yuixhr failure in both devel and db-devel. | 14:48 |
| * deryck is investigating build failures | 14:49 | |
| Daviey | flacoste: thanks | 14:49 |
| === matsubara is now known as matsubara-lunch | ||
| adeuring | rvba: r=me | 15:05 |
| rvba | thank you adeuring. | 15:06 |
| gnuoy | flacoste, there doesn't seem to be a backlog in mailman | 15:16 |
| flacoste | gnuoy: ok, so we think the delay problem is solved? | 15:17 |
| gnuoy | flacoste, no, sorry, I was just answering your question from an hour ago | 15:17 |
| flacoste | well, if we don't have a queue, there shouldn't be delays :-) | 15:18 |
| gnuoy | unless the thing putting them on the queue it the problem | 15:18 |
| gnuoy | s/it/is/ | 15:18 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === matsubara-lunch is now known as matsubara | ||
| deryck | abentley, lines are up again if you need to land stuff. | 15:55 |
| abentley | deryck: Cool, thanks. | 15:55 |
| deryck | matsubara, we using mumble for the call? or skype? | 16:00 |
| matsubara | deryck, skype so danhg can join us | 16:00 |
| deryck | ok | 16:01 |
| abentley | matsubara: online now, as aaron_bentley | 16:02 |
| deryck | matsubara, I'm ready to go too. | 16:03 |
| deryck | adeuring, you want in this call? | 16:03 |
| matsubara | abentley, thanks. skype is taking forever to find your user id | 16:03 |
| adeuring | deryck: sure. skype? | 16:04 |
| deryck | adeuring, yup. and tell matsubara your skype id if he doesn't have it. | 16:04 |
| matsubara | deryck, can you host? I suppose you have aaron and abel already in your list? | 16:04 |
| deryck | matsubara, sure. | 16:04 |
| matsubara | do you see me online? | 16:04 |
| adeuring | matsubara: adeuring on skype. give me two minutes to śtart a machine where skype is installed | 16:05 |
| === salgado is now known as salgado-lunch | ||
| === beuno is now known as beuno-lunch | ||
| flacoste | deryck: with spurious test failures, don't cross fingers, disable tests :-) | 16:14 |
| allenap | gmb: Do you what's happening/happened with bug relationships? | 16:38 |
| gmb | allenap: Not since I handed in the draft of the LEP. mrevell and flacoste will likely know where it's at. | 16:39 |
| flacoste | allenap: your squad is likely to work on it | 16:40 |
| flacoste | allenap: once gary squad is done with test suite parallelizatin | 16:40 |
| allenap | flacoste: So something for 2012 then. Ta. | 16:40 |
| flacoste | allenap: it's not clear what the exact scope will be yet | 16:40 |
| flacoste | allenap: yep | 16:40 |
| flacoste | early 2012 is what is on our agenda | 16:40 |
| deryck | flacoste, sorry was otp. I wasn't confident it was spurious enough to disable. if it happens again, I will. | 16:45 |
| allenap | Does anyone know why I can't find more than 1207 bugs at https://bugs.qastaging.launchpad.net/ares (via advanced search), even though I know that there are 1515 bugs, and launchpadlib confirms it? I assume it's something to do with bugs/bugtasks, yet they are all newly created tasks from an import. | 17:15 |
| deryck | allenap, private bugs? | 17:16 |
| allenap | deryck: There's one private bug. Checking anonymously via launchpadlib yield 1514 bug tasks. | 17:16 |
| deryck | hmm, weird. I remember something like that with a bug import for me. either private bugs or closed bugs. | 17:17 |
| allenap | deryck: I sense that I've figured this one out before, but I cannot quite access the memory. | 17:17 |
| deryck | heh, yeah | 17:17 |
| deryck | allenap, do you know what the user sees? | 17:18 |
| deryck | allenap, also, expired maybe? | 17:19 |
| * deryck is guessing :) | 17:19 | |
| allenap | deryck: The user and I see the same things: just 1207 bugs (well, he sees 1206). Ah, I have an inking... | 17:19 |
| allenap | deryck: I've figured it out! There are 308 tasks with Unknown status, and that's not given as an option in the advanced search page. | 17:20 |
| === beuno-lunch is now known as beuno | ||
| deryck | allenap, ah ha! :) | 17:20 |
| allenap | deryck: Thanks for prodding in the right direction :) | 17:21 |
| deryck | allenap, np! | 17:21 |
| === salgado-lunch is now known as salgado | ||
| lifeless | allenap: evening | 18:06 |
| rvba | Hi lifeless! | 18:11 |
| lifeless | hi rvba | 18:11 |
| lifeless | sad news about the oopses! | 18:11 |
| rvba | yeah, but that's fixed, the branch is in ec2. | 18:12 |
| lifeless | cool | 18:22 |
| sinzui | lifeless, do you know if the process that manages BugSummary ever pruges/rebuilds the stats? I am trying to understand why /launchpad always has three new bugs that the db says is not true | 18:37 |
| * rvba EODs | 18:39 | |
| rvba | lifeless: I've got a perf related question on this MP, maybe you could have a look next week… https://code.launchpad.net/~rvb/launchpad/builders-timeout-bug-887078-eager-load/+merge/82008 | 18:42 |
| * rvba really EODs now. | 18:42 | |
| lifeless | sinzui: it doesn't no. There is obviously a bug. | 18:58 |
| sinzui | yes. I think one something odd gets into the data, it is stuck | 18:58 |
| sinzui | lifeless, http://pastebin.ubuntu.com/735551/ show one of the bugs has a patch. I have been looking for such a bug in Lp. They are pretty rare. | 18:59 |
| lifeless | sinzui: could you file a bug ? | 19:00 |
| lifeless | I meant to last time I noticed, but I got distracted | 19:00 |
| sinzui | lifeless, I will | 19:00 |
| * micahg hugs sinzui for cleaning up null bug tasks | 19:23 | |
| sinzui | thank you. | 19:24 |
| === salgado is now known as salgado-brb | ||
| === salgado-brb is now known as salgado | ||
| === matsubara_ is now known as matsubara-afk | ||
| deryck | rick_h, ping. you around? | 21:16 |
| deryck | abentley, would you like to review my integration branch, which gets toggling of fields working? | 21:36 |
| abentley | deryck: sure. | 21:36 |
| deryck | abentley, thanks! https://code.launchpad.net/~deryck/launchpad/listing-config-widget-integration/+merge/82024 | 21:37 |
| deryck | abentley, I also did a little drive by to clean up some of that CSS/design stuff we've been discussing. | 21:37 |
| abentley | deryck: ah, okay. | 21:37 |
| deryck | abentley, when we're nearly done, I'll do a pass to consolidate/polish CSS rules, and perhaps simplify. But that should be closer to the mockup, and let everyone see we can get it right. | 21:38 |
| abentley | deryck: It looks like you're specifying field visibility rather than using the values from LP.cache. Is that right? | 21:41 |
| deryck | abentley, yes, I'm getting the value from when the form overlay is submitted. | 21:42 |
| abentley | deryck: I mean BugListingConfigUtil.field_visibility_defaults | 21:43 |
| deryck | abentley, ah, yes. I hard coded them in the widget. so it echos the browser code. | 21:43 |
| abentley | deryck: What is the purpose of echoing the browser code instead of using the values generated by the browser code? | 21:44 |
| deryck | abentley, to me it seemed better because the widget can work in isolation of the cache. or rather, I did build it separate from the cache.... | 21:46 |
| deryck | abentley, so there's no harm in pulling from cache in a later pass and not leaning on the hard coded defaults. | 21:47 |
| abentley | deryck: I think this is a DRY violation. If we change only one, then the bug listings (client-side or server-side) and the widget will disagree about which fields are displayed. | 21:49 |
| deryck | abentley, I agree. Does it matter for the sake of this branch, though? Can I change that when I fix the persistence issue? | 21:50 |
| abentley | deryck: And consider that the browser code will probably start setting these values according to query variables, per the LEP's URL requirements. | 21:50 |
| deryck | right | 21:50 |
| deryck | abentley, I'm completely agreed with you. Just wondering if fixing is a subsequent branch is ok. | 21:52 |
| abentley | deryck: I guess you could, but I don't understand why you'd want to. Violating DRY takes more effort then following it. | 21:52 |
| deryck | abentley, because, it's a larger change, and I want to think about how best to do it. Assuming you don't have other issues, this could land now, and at least get the interaction live for people to see. | 21:53 |
| abentley | deryck: It's not just a one-line variable assignment? | 21:54 |
| deryck | abentley, ah, you mean just in the page hook up? I was thinking refactoring so the hard coded ones weren't there at all. fixing tests, etc. | 21:55 |
| abentley | deryck: Oh, I see. | 21:56 |
| abentley | deryck: Well, if the tests are holding it back, I guess that's okay then. I just didn't understand your reluctance. | 21:57 |
| deryck | abentley, ok, thanks. I would like to fix it altogether, so the widget can't work without getting data from the cache. | 21:58 |
| abentley | Right. And then you could have a factory function for testing. | 21:58 |
| deryck | it's pedantic I guess, but it makes more sense to me if the test describes what you should do with the widget. | 21:58 |
| deryck | abentley, right | 21:58 |
| deryck | I meant my reluctance is pedantic, not your suggestion, abentley :) | 21:59 |
| abentley | deryck: r=me. | 22:03 |
| deryck | abentley, thanks! | 22:04 |
| rick_h | deryck: pong, been afk most of the day | 22:04 |
| abentley | deryck: We should also look at the module naming. I see "lp.bugs.buglisting" and "lp.buglisting_utils" and they don't match. And I'm not sure whether ListingNavigator shouldn't also be a utility. | 22:05 |
| deryck | abentley, yeah, I agree. I'm not crazy about my namings of this and configutils.BaseConfigUtil. | 22:07 |
| abentley | I'm not entirely sure what the style is supposed to be. I've seen a lot of different things. | 22:07 |
| deryck | we're inconsistent indeed. I think everything should just live under lp, a la Y.lp.module. | 22:18 |
| deryck | and probably a listings module and a utilities modules would let us divide these pieces up nicely. | 22:18 |
| deryck | abentley, can you mark the mp approved too please? | 22:19 |
| deryck | Later on, everyone. Have a nice weekend. | 22:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!