[00:09:08] sorry, Reedy, did you say something? [00:09:27] is there a specific type of programming that others are restricted from? [00:09:28] Nope [00:09:28] I believe that right is long deprecated [00:09:28] If you dig into DefaultSettings and uncomment something the good old friend AskSQL comes available for the 'developer' user group [00:09:28] I think it still works, but not recommended :P [00:09:29] Oh :P [00:13:46] thanks Reedy [00:14:18] I think I found the source of my confusion: https://bugzilla.wikimedia.org/describekeywords.cgi [00:14:49] apparently "wikidev" translates to shell access [00:14:58] don't know why though [00:15:11] heh [00:15:14] That's redundant [00:15:16] I'll tidy that up [15:36:53] *guillom pokes robla. [16:44:55] hi guillom: what's up? [16:46:28] robla, I was going to start organizing the migration of the content of the usability wiki to mediawiki.org, then I remembered we decided to retire the usability wiki and leave the content there, but with the wiki locked down as an archive. Just wanted to check with you this was still the plan, before opening a request in bugzilla. [16:47:27] <^demon> Might be useful to add usability.wm.o to mediawiki.org's import sources if we can [16:47:54] <^demon> Some of it might be worth pulling over, don't want to point people to docs outside of mw.org [16:48:04] <^demon> (at least I don't like having docs spread out) [16:48:24] guillom: sounds right to me. I believe Trevor had ambitions to go through the usability wiki and find pages, but I'm guessing he probably won't get around to it [16:48:47] <^demon> (Hence my suggestion, we can do it piecemeal as someone/anyone finds time) [16:48:48] We can add it to the import sources as ^demon suggests, so we can retrieve later pages if we find we need one [16:48:59] pages later* [16:49:02] <^demon> :) [16:49:27] But in the meantime I'd prefer to close the wiki to avoid it becoming abandoned to spammers [16:49:38] yeah, that sounds good [16:49:42] ok [16:49:50] Thank you both :) [16:52:29] np! [18:42:25] Does anyone here know much about client-side caching? Specifically why a file with Cache-Control header "private, s-maxage=0, max-age=0, must-revalidate" would be allowed to be reloaded from client-side cache by Safari? [18:42:52] ^ [18:42:53] and I assume Chrome as well [18:42:56] It shouldn't be AFAIK [18:43:09] But you can try Cache-Control: no-cache I guess [18:43:20] Take a look at... http://en.wikipedia.org/wiki/Main_Page?banner=20101231_JAFS024fader_CA [18:43:44] the second time you load it, http://meta.wikimedia.org/w/index.php?title=Special:BannerLoader&banner=20101231_JAFS024fader_CA&userlang=en&db=enwiki&sitename=Wikipedia will have an Age header [18:44:07] and will be loaded from client-side cache unless you shift-reload [18:44:37] why in the world would a file with max-age=0 be allowed to have an Age of whatever? [18:44:54] I'll try no-cache and see what happens [18:46:32] kaldari: Firefox behaves correctly here [18:48:53] actually, it looks like Firefox is doing the same thing as far as I can tell [18:49:12] I must be setting the header incorrectly [18:49:24] Time to review [18:52:08] looks like max-age isn't related to client-side cache age [18:52:30] but refers to the upstream cache age [18:53:07] There is dairy milk chocolate in the tech staff kitchen if anyone is interested. Got a few more bars if someone wants to take some upstairs or something [18:53:46] gimme some [18:54:19] kaldari: ? [18:54:35] I'm pretty sure max-age is for private caches, and the client cache is private [18:54:47] true [18:54:53] I guess I didn't understand that [18:56:01] so really, I need to be exempting the Special:BannerLoader cache headers from being overwritten by Squid as well and set it to no-cache. [18:56:43] I wish we had a X-Squid-Dont-Mess-With-My-Headers-I-Know-What-Im-Doing-Just-Go-Away: true header [18:57:00] I was assuming the existing headers didn't permit any caching, but that was my misunderstanding it seems [18:57:12] yeah, that would be awesome :) [19:15:02] RoanKattouw: So how do I actually set it to no-cache but still allow squid to cache it? [19:15:20] You want Squid to cache it? [19:15:31] private, s-maxage=0 are two directives telling Squid not to cache [19:15:40] So it wasn't (supposed to be) cached previously anyway [19:15:57] well, that's the cache header written by squid, not the one squid sees [19:16:01] Right [19:16:07] What does Squid see? [19:16:38] Cache-Control: public, s-maxage=600, max-age=0 [19:16:58] Right [19:17:03] No idea how to make Squid munge that [19:17:10] so I need squid to cache for 10 minutes, but absolutely no client-side cache [19:17:17] MW obviously has to send public and s-maxage=600 [19:17:22] for Squid to cache at all [19:17:33] hmm [19:17:49] I wonder what's rewriting it to private, s-maxage=0 in the first plac [19:18:00] That really ought to deter browsers from caching [19:18:19] nope, it only deters shared caches apparently [19:18:52] Ah sorry [19:18:57] The max-age=0 part ought to [19:19:12] not according to the spec [19:19:28] the max-age is what age the client is willing to accept from upstream [19:19:44] but doesn't control the clients cache itself [19:19:51] if I reading it correctly [19:20:00] I'm [19:20:45] so really I need a custom cache rewrite rule in squid I guess [19:23:17] maybe I need an Expires header [19:24:52] Right, and set it to the UNIX epoch or something [19:25:31] nope, max-age overrides Expires :( [19:25:52] this is surprisingly tricky apparently [19:26:08] Huh I really thought max-age worked for client-side caches [19:26:13] so did I [19:26:15] It sure seems to work that way in FF [19:26:34] Firebug has a Cache tab in the net panel that tells you when a cached resource expires [19:26:39] And it agrees with the max-age the server sets [19:26:54] looking... [19:30:10] You're sure your browser isn't just 304ing it? Have you looked at the actual headers? [19:30:32] yeah, that looks to be the case, although I'm not clear on what exactly the Expires applies to [19:31:26] 304ing it? [19:32:00] Check out http://en.wikipedia.org/wiki/Main_Page?banner=20101231_JAFS024fader_CA. What amount of money do you see having been raised in Firefox? [19:33:23] 16M [19:33:38] Or I did, checking again [19:33:38] ok, do a regular refresh and then a hard refresh [19:33:43] 15M now [19:33:49] I'm sorry, I answered before loading [19:33:52] the number should change on the hard refresh, but not on the soft refresh [19:33:57] When I cactually clciked the link it said 15 [19:34:01] OK, soft refreshing now [19:34:06] oops [19:34:15] 15M [19:34:19] let's start this experiment over [19:34:23] ok, 15M .... [19:34:33] I just hard refreshed and it said 15M [19:34:44] now soft refresh and then hard refresh [19:35:08] Soft refresh -> 15M [19:35:22] Hard refresh -> 16M [19:35:24] WTF [19:35:31] thus it seems to be client side caching [19:36:17] Straange [19:36:22] It's the meta.wm.o request, right? [19:36:29] yeah [19:36:38] http://meta.wikimedia.org/w/index.php?title=Special:BannerLoader&banner=20101231_JAFS024fader_CA&userlang=en&db=enwiki&sitename=Wikipedia&country=NL [19:36:42] yep [19:36:43] Cache-Control private, s-maxage=0, max-age=0, must-revalidate [19:36:47] yep [19:36:53] Last Modified Wed Jan 05 2011 20:39:35 GMT+0100 (CET) [19:36:55] Last Fetched Wed Jan 05 2011 20:39:35 GMT+0100 (CET) [19:36:57] Expires Thu Jan 01 1970 01:00:00 GMT+0100 (CET) [19:37:56] so I think I was not understanding the real meaning of max-age [19:38:12] at least as it relates to client-side caching [19:38:13] It has two meanings [19:38:25] One when sent by the client and one when sent by the server [19:38:32] AFAIK this *should* *work*, dammit [19:39:24] do you think it could be weird due to using a jsonp scheme somehow? [19:39:43] No [19:39:45] I wouldn't think that would affect the caching though [19:39:50] You're using the same URL every time [19:40:06] JSONP messes up caching when the callback name is in the URL, cause then the URL keeps changing [19:40:12] You seem to be doing everything right [19:40:19] I want to run this test again [19:40:29] Can you set it to 15 again? [19:40:41] Here's where you can change the value: http://meta.wikimedia.org/wiki/MediaWiki:Centralnotice-shared-2010-fundraising-value [19:40:52] You can set it to whatever you want since the fundraiser is over [19:41:27] Right, that's why I still have Jimmy staring me down with the old banners ^^ [19:41:40] This thing about the chapters controlling stuff is mildly annoying [19:41:53] yeah, for more than one reason [19:42:28] Oh look [19:42:31] I am now seeing the thank you banners [19:42:44] But for instance I never saw the editor appeal banners [19:43:06] probably because of the caching problems with Apache I imagine [19:43:19] No people in the US saw them alright [19:43:23] we just got that changed from 30 days to 4 days [19:43:25] For like a sweek [19:43:27] *week [19:43:29] Ooh [19:43:31] That [19:44:00] caching has been my bane for this fundraiser :P [19:44:35] Aha [19:44:39] It's Squid caching, not client side [19:44:46] X-Cache-Lookup: HIT from sq71.wikimedia.org:3128, HIT from amssq31.esams.wikimedia.org:3128, MISS from amssq43.esams.wikimedia.org:80 [19:44:56] ah [19:45:00] I was thinking, I *saw* my browser doing the request and get a 200 [19:45:11] What's the timeout set to, 300s? [19:45:19] ok, that makes sense [19:45:30] So that explains why it wouldn't instantly change for me [19:45:33] although doesn't explain this bug https://bugzilla.wikimedia.org/show_bug.cgi?id=26438 [19:45:50] And hard refresh sends Cache-Control: max-age=0 in the request to the server. Squid honors this, our current Varnish setup does not [19:45:57] ah, OK [19:46:17] OK that's just strange [19:46:18] so I just need to wait 10 minutes [19:46:28] 10 mins, OK [19:46:36] I'll try that [19:46:41] For that bug you seem to have *contradictory* cache entries [19:46:49] Which is very weird [19:46:58] It probably means each of the entires had a different URL [19:47:07] Did we run different banners that both displayed the number? [19:47:13] yes [19:47:45] but shouldn't any given URL be 10 minutes out of date at most? [19:49:05] it also could have been coding problems with individual banners [19:49:20] I didn't build most of them, so I'm not sure they all worked the same [19:50:27] Yep, waited 10 minutes and it worked [19:50:33] you were right [19:51:04] I think I'm going to have to mark that bug WORKSFORME [22:35:14] TrevorParscal: Hey could you review my RL fixes listed at https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/tag/1.17 (that's the full 1.17 merge queue, about half a dozen of those are RL-related)? [22:35:43] um [22:35:58] sure... i have 876 unread emails in my inbox [22:36:31] Right :) [22:36:36] *TrevorParscal temporarily turns attention to detail bit to 0 [22:36:38] First day back at work, right? [22:36:44] yes [22:37:04] OK well there's no terrible rush on it, but it needs to get done at some point [22:37:44] well, whatever you do, do not send me an email about it [22:37:50] that will only add to my pile [22:39:05] I won't, relax [22:39:18] I guess I'll add it to our 1.17 Etherpad task lits [22:39:25] http://eiximenis.wikimedia.org/1-17 [22:39:45] It's where I'm putting Reedy 's tasks now that I'm confiscating him for 1.17 work :) [22:39:58] <^demon> while( true ) { mail( 'tparscal@wikimedia.org', 'Hiii!', 'Hey hope you\'re feeling better!' ); } [22:40:58] *TrevorParscal is flooded with a stream of impolitely sent politely worded messages [22:43:31] TrevorParscal: Alright so just let me know when you get to it [22:44:12] the etherpad is bookmarked in a prominent place [22:44:21] Alright [22:44:22] I will let you know my progress when I have some :) [22:44:36] Thanks [22:44:52] Also, I guess robla should know I'm doing this, since he's really the 1.17 coordinator I guess [22:45:25] *robla reads backlog [22:46:05] robla: I've basically commandeered Sam's time and shifted it from API bug fixing to 1.17 tasks :) and put the task assignments in an Etherpad [22:46:20] by all means, yes [22:46:21] Hope that doesn't conflict with what you're doing; it's mostly a division of technical tasks though [22:46:27] Also, as I mentioned to Reedy in private [22:46:43] I'd like to have someone go through all unreviewed phase3 pre-branch revs and assign them to people [22:46:57] (where 'someone' may be multiple people of course) [22:47:22] *robla looks at the list [22:47:56] So that's status=new , path=/trunk/phase3 , revid < 77973 [22:49:17] <^demon> http://www.mediawiki.org/wiki/Special:Code/MediaWiki/status/new?path=/trunk/phase3&offset=77974 and everything after [22:49:32] Thanks [22:49:34] *RoanKattouw bookmarks [22:52:02] what's the best way to assign? [22:55:17] Etherpad? :P [22:55:23] CR doesn't have that feature currently [22:55:28] Or you could tag, I guess [22:55:30] That could work [22:55:46] oooh....tagging might be interesting [22:55:48] Tag it with the first name of the person you'd like to review it [22:55:55] That won't let you filter assigned revs from unassigned ones [22:56:06] But it allows the assignees to quickly get their review queue [22:56:42] In fact I'll tag the assignments I've been making in Etherpad [22:57:07] is there a separate etherpad doc you've been using for assignments? [22:57:44] The one you're on, 1-17 [22:57:54] I only started doing this like half an hour ago [22:58:08] So people will hopefully review stuff while I sleep [22:58:54] would it be helpful to get on a phone call or on Mumble and quickly dash through a bunch of assignments? [22:59:59] Not now, if you don't mind, it's midnight and I'm falling asleep [23:00:27] no prob...next question then: [23:00:41] is this something you want me or Reedy or someone else to take a shot at? [23:01:07] "this" being? [23:01:26] assigning CRs to reviewers [23:02:03] Yeah by all means [23:02:40] You can call on volunteers too, you don't need to be a ninja to do this, you just need to know who's an expert on what, really [23:03:35] And have a quick look over relevant extensions. Any maybe assign some of them for reviews [23:04:00] Go through fixme's too [23:04:28] Anything that encourages (or guilts :D) people into helping out with review or fixes is excellent [23:06:05] r77929 is probably Tim's still, since he reverted the original [23:08:04] Lot of JS changes too [23:08:19] Chad can probably review the installer parts and Trevor or I could review the JS parts, I guess [23:09:10] when I've been cherry picking at reviews, I've been doing odd random bits and pieces cause they are trivial [23:11:17] Alright, I'm gonna go to sleep. Thanks for supporting my late night impulsive review assignment push and hijacking of Reedy :P [23:12:35] great impulse! thank you! [23:12:37] :) [23:13:31] *robla is looking at r77908 [23:14:16] I guess I'll give that one to Trevor [23:16:05] ^demon: you want your tag to be "chad" (as assigned by Roan) or "demon"? [23:16:59] <^demon> chad is fine [23:18:00] k...I was going to blindly assign r77898 to you, then realized it was the one that Tim reverted. you're both on there for now [23:19:07] How much do we "care" about LQT fixmes? [23:21:19] <^demon> Hmm, my original concerns of being able to show/hide the boxes instead of just being popups has been addressed. [23:21:20] Reedy: I think it kinda depends [23:21:54] we care if the fixme is "this is a serious security hole" [23:22:26] if it's a UI issue that's going to be made obsolete by the next rev, probably not as much [23:22:32] <^demon> Fixmes for anything deployed on wmf sites should be a concern. [23:22:43] <^demon> Either fixed, reverted, or made harmless for the time being. [23:22:57] mhmm [23:23:16] 96 fixmes [23:23:26] 59 I see we "care" about to some respect [23:23:47] <^demon> We should make a pass on the list. [23:23:59] I've listed them on the etherpad [23:24:06] bar any post branch that are tagged 1.17 and fixme [23:24:15] Some of them are donation related, so we care, but maybe not so much [23:25:08] <^demon> I'm going to mark the iwtransclusion fixes are resolved. They've been ironed out by now [23:25:08] Reedy: how can i look at the fixmes? i can take a quick look at the donation related ones [23:25:13] <^demon> And they're functionally minor [23:25:20] <^demon> (And disabled on wmf sites :p) [23:25:27] http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/status/fixme&author=awjrichards [23:25:35] http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/status/fixme&author=kaldari [23:25:57] Some of the might have been dealt with, just forgotten about, which is good [23:26:07] *awjr takes a look [23:26:47] yeah, I imagine all of mine are dealt with and forgotten [23:27:03] hahaha mine havent been dealt with but have been forgotton [23:27:06] Feel free to mark as resolved/old/deferred if you think they are :) [23:27:08] :D [23:27:09] er forgotten [23:27:43] kaldari: cleaning up the i18n files in DonationInterface would take care of some of theese [23:27:45] Reedy:What's the difference between resolved and OK? [23:27:55] <^demon> resolved means there was a problem [23:27:57] <^demon> but it's fixed now [23:28:17] <^demon> sometimes people put it to ok in that instance. I prefer resolved so you can clearly see formerly broken stuff [23:28:23] Mhmm [23:28:28] that's what I thought at first, but not everyone seems to stick to that convention [23:28:31] It sorta depends what was up with it before [23:28:44] If it's very minor, style or that sorta thing, resolved isn't so much of a big deal [23:29:56] can we simply mark r77893 as deferred? it's a skin change that Roan backed out of 1.17, but is still in trunk [23:30:16] <^demon> It still needs fixing in trunk. [23:30:28] <^demon> If it still needs fixing/review, it shouldn't be deferred. [23:30:39] what do we mark as "deferred"? [23:30:43] on http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73554 I just don't want to implement Roan's suggestion. How do I mark that? [23:30:46] <^demon> Semantic extensions ;-) [23:30:49] Extensions we don't care about [23:31:02] <^demon> robla: I try to limit it to extensions we don't care about and i18n updates. [23:31:10] maybe add a comment and mark resolved? [23:31:17] kaldari, that seems sane [23:32:11] resolved doesn't seem entirely right either [23:32:36] I'll tag it for roan for now [23:33:56] r77886 css tweaks by Trevor... [23:34:31] I could add that to roan's pile, but is there anyone else who is a logical choice for css stuff? [23:34:42] Trevor maybe [23:34:56] I'd certainly say not Chad or myself :P [23:35:00] trevor can't review himself [23:35:04] ph [23:35:06] lol [23:35:06] yup [23:35:42] Either Roan... Or maybe see if jorm can..? [23:35:50] yeah, I was just thinking that [23:37:20] alright folks, just got rid of my last fixmes :D [23:38:18] awjr, that happens when you wait six months for answering xD [23:38:36] heh, blame the fundraiser [23:38:57] at least that's what i do [23:40:27] +// The path to Special Pages on the wiki that hosts the CentralNotice infrastructure [23:40:28] +$wgCentralPagePath = 'http://meta.wikimedia.org/wiki/'; [23:40:35] that doesn't point to a special page [23:40:45] robla, feel free to assign me some revisions if yo you wish [23:41:23] Platonides, some of the revisions are the problem :P [23:41:27] *your [23:41:32] OK, just need to clean out the i18n file for 75835, and then the rest of the fixmes all relate to a single issue, which should be easy to fix [23:41:39] Awesome :) [23:41:48] I'd think that wg should have 'Special:BannerLoader' after it or something ? Or is it used for more ? [23:42:11] wg? [23:42:24] look up 7 lines [23:42:34] <^demon> What's the state of LangConverter stuff? [23:42:43] <^demon> That was all over the place last April/May/June-ish? [23:42:58] Isn't there still a fixme or 2 on it? [23:43:03] <^demon> eg: r64876 is still fixme. [23:43:06] <^demon> That's by Tim [23:43:15] Platonides, ^ one you could look at :) [23:45:10] LanguageConverter, ouch [23:45:30] Krinkle: $wgCentralPagePath is currently set in the config files on the cluster rather than within CentralNotice. [23:45:44] same for $wgCentralDBname [23:45:47] kaldari, is it set to anything in the extension itself though? [23:45:51] ^demon: there's a couple of skin revs I'm going to assign to you because I think it's probably more of a security+new global thing that needs to be reviewed [23:46:01] Otherwise, that could be a register_global issue if used elsewhere [23:46:14] they should be set to null string in the extension [23:46:18] <^demon> robla: okies [23:47:12] r77741 and r77763 [23:47:17] is that the best way to handle it? [23:47:38] lol http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/stupid [23:48:03] amusing [23:49:04] <^demon> tbh, I can't even remember what the heck I had been testing. [23:49:15] what, no "facepalm" tag? [23:49:33] <^demon> Oh yeah, I was testing parsekit on 5.3 and I needed a syntax error. [23:49:38] I could start a fuckwhitespace tag [23:50:01] <^demon> whitespace commits annoy me. [23:50:09] <^demon> and mess with viewvc. [23:50:34] Platonides, www.mediawiki.orga/wiki/Special:Code/MediaWiki/77597 [23:51:57] http://enwp.org/.orga [23:52:27] it's the pig latin tld [23:53:06] http://fata.m.orga/na [23:53:10] What's the global var for "http://bits.wikimedia.org/skins-1.5/common" (or something close)? [23:53:20] $wgStylePath [23:53:26] thanks! [23:55:33] weird that it's just 'stylepath' in JS [23:55:42] must be a legacy name [23:59:28] Just like 'skin'