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