[00:00] Project db-devel build #764: STILL FAILING in 6 hr 2 min: https://lpci.wedontsleep.org/job/db-devel/764/ [00:17] jtv: you back on board yet? [00:56] wallyworld: hello, can you review https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 [00:57] and merge it if appropriate [00:58] poolie: sure [00:58] that one was marked as needing info for a while i think [00:59] it stalled for a bit [01:00] if people push and don't ask for more review it's easy for things to get stuck [01:12] which is https://bugs.launchpad.net/launchpad/+bug/745469 i guess [01:12] <_mup_> Bug #745469: please send notifications when merge page has been updated with new revisions < https://launchpad.net/bugs/745469 > [01:23] poolie: in the above case, i normally add a comment to the mp explaining what i did and why and how it relates to any previous request for change [01:23] this causes an email to be sent [01:23] yup [01:23] it's not obvious that you ought to do this though [01:23] ought/need [01:23] too true [01:39] fixing up aaron's incremental diff thing will address that - and get sensible incremental diffs with merges from trunk (which the loggerhead based diff thing does not do) [01:49] Project devel build #928: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/928/ [02:28] lifeless: can you +1 this? i'm not 100% familar with loggerhead etc but it seems reasonable and has had a lot of input already.... https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 [02:32] thanks wallyworld [02:33] to merge it, when you're ready, you should be able to just merge into lp:loggerhead [02:33] and i guess it would be good to deploy that to lp too [02:33] poolie: np. i'll clean up the lint first [02:34] poolie: i may need to ask for help deploying - i've had nothing to do with loggerhead so far :-) [02:46] np [02:46] i'm getting "lib/canonical/launchpad/icing/yui/yui/yui.js" in my lp checkout [02:47] oh, a broken symlink or something, isn't it [02:50] poolie: likely. a make clean will fix it [02:50] will || should [05:06] are there any tests of the personmerge view other than the doctest ? [05:41] Project db-devel build #765: STILL FAILING in 5 hr 40 min: https://lpci.wedontsleep.org/job/db-devel/765/ [05:49] hahaha [05:50] ? [05:50] -> ops [06:15] wgrant: are there unit tests for person.merge() ? [06:17] I doubt it. But let's see.. [06:17] I can't see any in test_person [06:18] There is a _do_merge in test_person. [06:18] Is that not relevant? [06:18] I haven't actually seen anything beyond its existence. [06:18] nothing in there looking for notifications that I can see [06:18] which is what I'm touching [06:18] :/ [06:29] and \o/ [06:33] can has review ? [06:33] https://code.launchpad.net/~lifeless/launchpad/bug-761874/+merge/69748 [06:44] wgrant: ^ or wallyworld ^ [06:44] wallyworld: I will look at the loggerhead thing monday; it requires some pagination [06:44] lifeless: ok, thanks. will look at your mp [06:44] wallyworld: deployment is the usual thing - update the version we use, and qa that once that commit hits qa-staging [06:44] ok === jtv-afk is now known as jtv === wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 240 - 0:[#######=]:256 [07:21] cheerio wallyworld [07:21] what's the idiomatic way to html-escape things in lp python code? [07:22] Don't do it. [07:22] poolie: i'll do that mp on monday when it gets +1ed [07:22] poolie: What are you trying to do? [07:22] Escaping is usually the wrong thing. [07:22] wgrant: you want to mentor: ://code.launchpad.net/~lifeless/launchpad/bug-761874/+merge/69748 ? [07:23] wgrant: test_scope_documentation_displayed is checking that the feature scopes are in the browser.contents [07:23] it's failing to find them, i think because the new one i've added contains angle brackets [07:23] Ah, so this is in a test? [07:23] Just use cgi.escape. [07:23] heh :) ok [07:24] Project devel build #929: STILL FAILING in 5 hr 34 min: https://lpci.wedontsleep.org/job/devel/929/ [07:24] i agree with not having random escaping and unescaping in production code [07:35] good morning [07:42] hi abel [07:42] could someone do a review for me, on https://code.launchpad.net/~mbp/launchpad/mail-scope/+merge/60281 [07:52] poolie: I'll look [07:53] thanks [07:55] wallyworld: still here ? [07:55] wallyworld: you asked for create to mention delete, but I do that in my patch already. [07:55] wallyworld: do you mean you want the interface to talk about implementation ? [07:55] * lifeless loads the question === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 240 - 0:[#######=]:256 [07:57] lifeless: could you have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/bug-739052/+merge/69625 [08:01] adeuring: hahha, on friday night no less. [08:01] adeuring: great stuff [08:01] lifeless: thanks! [08:12] morning [08:14] o/ === almaisan-away is now known as al-maisan [08:15] hallo there bigjools [08:26] ok, good night [08:41] adeuring: reviewed [08:42] lifeless: thanks! [08:52] adeuring: no probs [08:53] wgrant: need a chat with you [09:05] adeuring: morning! I have a lovely branch for you if you can take it please? [09:05] bigjools: sure [09:06] adeuring: https://code.launchpad.net/~julian-edwards/launchpad/utf-codes-in-emails-bug-817106/+merge/69758 [09:06] bigjools: Not entirely here, but what's up? [09:07] wgrant: I wanted to talk about the no-builds-in-progress check in the IDSJ, and whether/how we should fix the packagecopier [09:07] I am very concerned [09:08] Your concern is well-placed. [09:09] wgrant: so I'd rather mumble/skype. If now is bad, next week is ok. [09:09] bigjools: Next week is probably best, sorry. [09:09] not a problem [09:09] thanks [09:10] bigjools: the diff on the MP page shows a minor merge conflict [09:12] adeuring: ah I'll fix that, thanks [09:22] adeuring: conflict fixed, just waiting for the branch scanner [09:22] bigjools: thanks [09:38] bigjools: r=me [09:38] adeuring: thank you sir. Did the unicode stuff look ok? I figured you'd have more experience of that than me :) [09:39] bigjools: as I wrote in the MP, we used something like u'Lo\u2345c' and avoided the "coding: utf-8" line at the top [09:39] ah ok [09:39] bigjools: but [09:39] I thin k we can really switch to the way you did it [09:40] I took inspiration from a different python file in our tree [09:40] bigjools: even better then :) [09:40] Loïc looks better than Lo\u2345c huh? :) [09:40] there is a small risk that somebody uses an editor which does not understnd utf-8 [09:40] but I am not aware of any such editors... [09:41] yeah - I had issues with Vim but then it seems all ok with it today :/ [09:41] bigjools: and yeah, this '\u3456' looks really ugly and is sometimes hard to understand [09:42] indeed [09:42] lifeless: can you please merge: lp:~jml/python-fixtures/misc-fixes [09:43] I think Python supports also something like "LATIN_CAPITAL_A_WITHDIERESIS" with some escape mechanism but that's not much better than \u1234 [09:44] heh [09:44] it is a total minefield [09:47] bigjools: not such a big pitfall as some Qt unicode -> string conversion method (can't remember which one exactly) It gave you ISO8859-1 strings by default. Was quite annoying for any language spoken that did not originate in western europe [09:48] adeuring: nice. [10:14] https://dev.launchpad.net/LaunchpadPpa says "The current development series [...] (currently: natty)" and "The current release [...] (currently: maverick)" [10:15] should that be changed to oneiric and natty respectively now? [10:15] Indeed. It does work on oneiric. [10:17] launchpad-dependencies has versions 0.95~oneiric1, 0.95~natty1, 0.95~lucid1. lp:meta-lp-deps only has 0.95. Is that done by hand? How do you deal with different versions of dependencies in different releases? [10:17] jtv: the expander sections on the queue syncs look nicer now [10:17] oh, hm, https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand [10:17] bigjools: Thanks. Actually expanding does look more appropriate on an expander, does it not? [10:18] jtv: generally :) [10:18] BTW it looks like the other expanders don't get the colspan quite right. [10:19] My eye keeps expecting a link where the archive name is. Is there anything to link to? [10:19] cjwatson: Right, that recipe is used. The deps are identical between series these days, though, so the series-specific sources are unnecessary. [10:19] I guess I can use substvars to force the right versions of apt/python-apt [10:20] cleaner than series-specific sources [10:20] Slightly. [10:20] maverick doesn't have a sufficient version? [10:20] no [10:21] That is inconvenient. [10:21] bigjools has copied stuff into the PPA now (including maverick), but I assume that that won't necessarily get upgraded without forcing versions in lp-deps [10:21] Sometimes we force it, sometimes we don't... [10:22] Should I just not bother? [10:23] Probably not. Only the two buildbots + cocoplum really need it. [10:23] And we can ensure that those are correct easily. [10:23] And it avoids the substvar mess. [10:24] it's mildly inconvenient that cocoplum doesn't seem to have the Launchpad PPA in sources.list [10:24] Right, the DC machines use CAT. [10:24] We generally import stuff from the PPA into CAT. [10:24] so I should RT that? it's just for apt/lucid [10:24] Not sure. LOSAs ^^? [10:25] * mthaddon catches up [10:26] yeah, an RT asking for it to be uploaded to the -cat repos and installed would be good [10:26] OK [10:26] cjwatson: unf we can't install directly from PPAs on servers in the DC as that would basically mean a compromise of LP would root all DC servers [10:26] s/would/could/ [10:26] Erm... [10:26] You know what controls the Ubuntu archive, yeah? :) [10:27] well, that's true, but it's a slightly different case [10:27] The security of the primary archive is less tested, yes. [10:29] I'd normally use the ubuntu-platform@ RT address, but I assume I should use the launchpad@ address in this case ... === jtv is now known as jtv-eat [10:31] wgrant: assuming that the buildbots are up to date or will update, then https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152 could be landed now, I believe [10:32] cjwatson: Has it been through ec2 lately? [10:33] No [10:34] wgrant: can you help the dude in #launchpad? [10:45] mthaddon: done, RT#47110 [10:45] <_mup_> Bug #47110: [UNMETDEPS] php4-yaz links against old libmysqlclient < https://launchpad.net/bugs/47110 > [10:45] thx [10:47] cjwatson: do you know if this has been tested on staging/dogfood? [11:05] adeuring: Would you be able to review a mostly JavaScript branch for me? https://code.launchpad.net/~allenap/launchpad/localpackagediffs-filter-by-person-or-team-bug-798873-ui/+merge/69766 [11:05] allenap: sure [11:06] Thanks :) [11:06] adeuring: I am going to get some lunch now but I'll try to watch for pings. Is that okay? If not, leave it for later when I'm back. [11:07] allenap: then let me ytart my lunch break too before I start to look at the mp :) [11:07] adeuring: Cool :) [11:24] Project db-devel build #766: STILL FAILING in 5 hr 43 min: https://lpci.wedontsleep.org/job/db-devel/766/ [11:29] """Gina's changelog parser and muncher for great justice""" [11:53] am thinking of doing work to address / mitigate https://bugs.launchpad.net/launchpad/+bug/814725 [11:53] <_mup_> Bug #814725: No feedback between upload & acceptance/rejection < https://launchpad.net/bugs/814725 > [11:53] james_w suggested adding an API method for upload [11:54] any thoughts from folk here? bigjools? wgrant? StevenK? [11:54] jml: it's not a trivial problem [11:55] Until we have a message queue. [11:55] an API for upload is not going to work, it'll time out [11:55] Until then, best not to think about it :) [11:56] we need to decide what feedback people would be happy with [11:56] bigjools: so the timeout starts from 'request received'? [11:56] or rather, request started [11:56] rather than, say, request finished [11:57] jml: The processing itself can easily take many seconds. [11:57] jml: to make sure we're talking about the same thing, is that a webservice API? [11:57] s/seconds/minutes/ [11:57] bigjools: yes. [11:57] why minutes? [11:57] jml: ok, that will never work. we need a different transport [11:58] jml: the upload processor has to unpack the package [11:58] that can take a loooong time [11:58] why does it need to do that? [11:58] to verify its contents [11:58] It should never take minutes, but it can have to un-xz and un-bz2 a few hundred megabytes :/ [11:58] "should" :) [11:59] jml: at a stretch we could make poppy poke something into the database to say "pending uploads +=1" and then make the upload processor decrement that. Then the UI can show something. [12:00] not sure of the ramifications of that though [12:00] bigjools: well, there are other checks that are fast to do that the user would be well served to be told about sooner [12:00] e.g. permission checks [12:00] jml: yes, they are all done first [12:01] I have considered deferring the extraction to a job. [12:01] bigjools: yeah, but currently asynchronously [12:01] We could possibly get away with removing a couple of the pedantic checks on the extracted package. [12:01] jml: I think it doesn't try to unpack unless all the other stuff passes [12:01] I can't see any mention of tarfile in archiveuploader [12:01] And then do the file retrieval async. [12:01] jml: Hahah [12:01] dpkg-source [12:01] anyway - there's a load of bugs which means it'll just OOPS [12:01] Not that easy :) [12:01] wgrant: ah, ok. got it. [12:02] * bigjools has deja vu [12:02] archiveuploader is a bit special. [12:02] Not gina-special. [12:02] But still fairly special. [12:02] * bigjools found a horrible bug in gina [12:02] it doesn't help when the doctest that checks for output format doesn't have a -NORMALIZE_WHITESPACE :/ [12:03] afaict, the verification here is just for 'single directory', 'changelog' and 'copyright' [12:03] I guess dpkg-source might do verification that the code implicitly relies on. [12:04] bigjools: While you're there, want to fix archiveuploader's changelog_entry generation? [12:04] what aspect? [12:04] jml: Right. dpkg-source does a lot of checks. [12:04] why not check the first by listing the tarball contents, and get the other two by just extracting those files? [12:05] jml: But if we accept an invalid package, it will just fail to build, so it's not that bad. [12:05] Extracting those files how? [12:05] We'd have to be able to unpack all the source formats. [12:05] Untar + diff [12:05] Or untar + untar [12:05] Or whatever they come up with next. [12:05] accepting invalid packages to the build farm is nuts, don't do that [12:06] bigjools: They are rare and will just end up FAILEDTOBUILD. It's not *that* bad. [12:06] it's build time wasted [12:06] wgrant: hmm. I see. I guess you'd have to patch upstream to provide the feature. [12:06] disk space wasted [12:06] and crufty [12:06] bigjools: every successful check is wasted CPU too [12:07] reject early, reject often [12:07] jml: no, it's just getting deferred [12:10] the later you reject in a pipeline that has a lot of steps, the harder it is to produce a decent error message [12:11] Certainly failing early is good. [12:11] But if you are doing an expensive check early that is also implicitly done in later steps, you are penalizing successful cases to help the bad ones. [12:12] in this case I disagree; you're just pushing the penalty to later on [12:14] Perhaps we should get some data. [12:14] but it's actually making it take longer, isn't it? Or is the output of dpkg-source in the upload check saved so that the build farm doesn't need to run it? [12:15] I suspect it's very rare that dpkg-source fails. [12:15] wgrant: yeah, that'd be interesting to see. [12:15] funnel graphs [12:15] No, all the buildds have to rerun it. [12:15] so assuming most uploads are actually OK, then you're right. But yeah we need data on that. [12:16] I still think we need to check this stuff :) [12:17] I'm also not quite sure on how a webservice API would work here. [12:17] it wouldn't [12:17] I guess you'd upload files to the librarian and then fire off an MQ-based job. [12:17] It's doable, and should be done eventually :) [12:18] please not the librarian [12:18] They would have a <24h expiry. === bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Critical bugs: 240 - 0:[#######=]:256 [12:19] hola abel [12:19] still probably need a MQ though. [12:19] the way we do it is fine. We can make poppy send a message to something to kick off processing [12:19] I'd like to parallelise per archive (up to a max thread count) [12:20] Indeed. [12:20] It would be nice if Python did threads :/ [12:20] heh [12:21] Maybe by the time we have a MQ-based jobrunner we will have moved to PyPy. [12:21] * bigjools can't believe this changelog parsing bug has been in Gina so long [12:21] well [12:21] wgrant: haha [12:22] we'll see what I actually need to get my thing done. [12:23] jml: in lieu of a message, another solution would be to have some sort of pending upload indicator in IArchive which poppy increments and the upload processor decremements [12:23] jml: Recipes! [12:23] wgrant: I asked for in-page updates for async jobs for every feature LP did since January 2010. Including recipes. [12:23] jml: when we finish DDs, we'll be finishing *that* :) [12:24] bigjools: looking forward to it. [12:24] hellyes [12:24] Bug #628738 [12:24] <_mup_> Bug #628738: SourcePackageRelease.changelog_entry now incorrectly generated

< https://launchpad.net/bugs/628738 > [12:24] bigjools: That's the bug. [12:25] (also not caught because of NORMALIZE_WHITESPACE, IIRC) [12:25] yay [12:25] different problem to the one I am fixing though [12:25] doctests, yay [12:25] Yeah. [12:25] there's nothing like testable documentation [12:26] and our doctests are nothing like testable documentation [12:26] except maybe burgers with turds in them. [12:26] * bigjools blinks [12:28] allenap: r=me [12:28] Thanks adeuring :) [12:32] wgrant: do you know if iron is in NDT? [12:32] bigjools: It is. [12:32] mcmurdo too. [12:32] good [12:33] I love the way that someone thought that list.append(string) included a newline [12:33] ftpmaster, ppa, librarian, librarian2, mailman, codehosting are not in nodowntime. [12:33] Everything else is. [12:33] mailman might be as of 12 hours ago. I forget. [12:34] And codehosting will be on monday. [12:34] Shall be good. [12:34] woo === jtv-eat is now known as jtv [12:46] mthaddon: TTBOMK it has not [12:46] cjohnston: ok, I've added a note to the ticket that we should do that first, so we'll make it so [12:46] great, thanks [12:47] cjwatson: that's a new acronym for me. [12:47] excellent. no more learning required from me for the rest of the day. [12:53] * cjwatson prescribes jml alcohol [12:53] mthaddon: do I need to take that backlogged message seriously, or is it automatic irrelevancy? [12:54] cjwatson: it basically just means it hasn't been directly assigned to someone yet, but I've given in a priority, and if that needs bumping up it can be done at any time [12:54] s/given in/given it/ [12:54] cjwatson: with prescriptions like that, perhaps there's more to be said for private medical practitioners than I had previously thought! [12:54] mthaddon: ok, cool [13:08] Morning, all. [13:42] Hi bac! Free for a review? I've got this: https://code.launchpad.net/~jtv/launchpad/bug-818032/+merge/69791 [13:43] jtv: sure [13:43] Thanks. [13:45] jtv: did you have any pre-implementation discussions about this bug and branch? [13:45] bac: yes, hence the "pre-implementation notes" :) [13:45] With Julian, to be precise. [14:01] jtv: ok. since you didn't list any one in that section i wanted to find out. [14:04] bac: in retrospect I see I wasn't very helpful in that section, sorry. [14:04] jtv: looks good. thanks! [14:04] thank you. === stub1 is now known as stub [14:27] adeuring or bac: could you please review https://code.launchpad.net/~abentley/launchpad/fix-lpviews/+merge/69800 ? [14:27] abentley: i will [14:27] bac: you bebat me :) [14:27] bac: I have fixed the lint. [14:27] i did bebat you! [14:39] abentley: done. good catch. [14:40] bac: thanks. [14:40] i didn't realize we had pages using the zope default [15:04] sinzui: i see that you are working on 800361. i just unassigned myself from that in lp; shall i assign you? [15:06] jcsackett, I suppose [15:07] sinzui: is there a reason i shouldn't? i only unassigned myself b/c i'm not currently working further on it after UI tests and thought someone else might have the time to do it. which seemed to be you. [15:08] jcsackett, I have been very distracted the last two days and have made no progress. If I am distracted today, I will give up the work to wallyworld. This is critical path work and I not certain I should ever be on the critical path [15:08] sinzui: ok. leave it till monday and decide then? [15:09] jcsackett, I have been working to unblock others. I am participating in the product strategist interviews [15:09] sinzui: aaah. [15:09] jcsackett, do you have time to mumble? [15:09] sinzui: sure. [15:22] bigjools, is there anyone with a somewhat overlapping timezone to mine whom I can bother about a relatively simple soyuz question (https://answers.launchpad.net/launchpad/+question/166346 fwiw)? I'm sorry I've been bothering you a lot lately. [15:23] gary_poster: that doesn't look like a soyuz question [15:23] oh [15:23] project release stuff isn;t it? [15:23] * gary_poster feels dumber... [15:24] ok [15:24] bac...do you have any idea about https://answers.launchpad.net/launchpad/+question/166346 ? [15:24] gary_poster: oh and I think the answer is "no" anyway :( You've got 2 Aussies, and me. [15:25] bigjools, heh, ok, thanks === al-maisan is now known as almaisan-away [15:47] sorry, gary your message didn't get highlighted. maybe my client doesn't like "bac..." [15:50] gary_poster: i can't answer that question off the top of my head. i'm not familiar with how that pattern is used. i can look into it, though. [16:14] thanks bac. maybe on your CHR rotation. I'm not pursuing it === beuno is now known as beuno-lunch === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac | Critical bugs: 240 - 0:[#######=]:256 [16:28] mrevell: did you just put Welsh on the Launchpad blog? === deryck is now known as deryck[lunch] [16:50] hey guys [16:51] i got OOPS-2036MPJ10 from lp trying to generate a diff for my branch [16:51] i think it might be a bug in bzr or something [16:56] hi dobey [16:57] hmm, that OOPS hasn't synced yet [17:01] ok [17:01] jelmer: it probably says something akin to this, anyway: http://pastebin.ubuntu.com/654553/ [17:03] Project db-devel build #767: STILL FAILING in 5 hr 38 min: https://lpci.wedontsleep.org/job/db-devel/767/ === beuno-lunch is now known as beuno [17:17] dobey: that's a known bug [17:17] a 5 digit bug even [17:17] bug 82555 [17:17] <_mup_> Bug #82555: Merging to an empty branch doesn't work < https://launchpad.net/bugs/82555 > [17:20] wow [17:22] dobey: while you're here... :) [17:22] dobey: did you see my mps against lptools? [17:23] yeah, but i haven't had time to look at them. i guess poolie hasn't either [17:24] there's no hurry [17:29] that bug is interestingly odd [17:29] since it is possible to merge to an empty branch, but weird things can happen [17:30] if i just merge to the empty branch and commit straight away, it sort of 'rights' itself [17:33] so, this is interesting... [17:34] jelmer: http://pastebin.ubuntu.com/654630/ <- notice the revnos that are listed as negative :) [17:35] and log -n0 shows them as 1..5 [17:37] dobey: yeah, there seem to be multiple issues here [17:37] dobey: this sort of thing is tricky because of the way we do revno assignment, as you can see :) [17:38] sure [17:42] bac: I have a branch that needs reviewing, if you've got time: https://code.launchpad.net/~gmb/launchpad/remove-unused-potmsgsets/+merge/69841 [17:43] gmb: i do have time. [17:43] Thanks [17:43] Woah. [17:43] bac: Hang on. Bad diff. [17:44] bac: Should have submitted against db-devel. https://code.launchpad.net/~gmb/launchpad/remove-unused-potmsgsets/+merge/69842 === Ursinha is now known as Ursinha-lunch === deryck[lunch] is now known as deryck [18:07] gmb: review done with a couple of suggestions [18:08] bac: Thanks === Ursinha-lunch is now known as Ursinh === Ursinh is now known as Ursinha [19:00] abentley: I'll be ready for our call in about 3 minutes. Meet you in mumble then? [19:00] deryck: sounds good. [19:13] Project devel build #930: STILL FAILING in 6 hr 1 min: https://lpci.wedontsleep.org/job/devel/930/ === almaisan-away is now known as al-maisan [20:07] gary_poster: ping [20:08] abentley, hi [20:08] gary_poster: I'd like to talk about the jsoncache. Do you have a couple of minutes? [20:09] abentley, sure, in 5 ok? [20:09] gary_poster: sure. [20:09] cool, abentley, I'll ping [20:17] abentey, thanks, ready [20:17] I'd prefer skype === al-maisan is now known as almaisan-away [20:24] abentley ping :-) [20:24] * gary_poster has EoD in 5 [20:24] gary_poster: So that the Thunderdome, you expressed concern about the idea of reloading the whole JSONRequestCache as a means of updating pages. [20:25] yeah [20:25] at least as one to be applied as a blanket approach [20:25]