[00:00:01] marktraceur: well said :D [00:00:16] Ain't nobody got time for that. [00:00:29] (thx again for that quip, TrevorParscal) [00:01:07] So I guess also I'll need to update the submodule. [00:01:12] Krinkle: Not Trevor's originally. :-) [00:01:17] I know [00:01:44] http://www.youtube.com/watch?v=zGxwbhkDjZM#t=0m20s [00:03:09] James_F: omg, they even put her in an ad. [00:03:26] a denist ad, or is that a spoof [00:03:38] New patchset: MarkTraceur; "Update junitdiff to latest" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/52732 [00:04:23] Merge, merge, merge! [00:04:33] Er, that is, Krinkle, would you be a dear and... [00:04:59] marktraceur: In integration we use git mostly as a log. Self-merge if you're not looking for feedback specifically –hashar [00:05:04] Ah. [00:05:19] New review: MarkTraceur; "Self-merge, per hashar" [integration/jenkins] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/52732 [00:05:19] Change merged: MarkTraceur; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/52732 [00:05:23] yeah post commit review just takes too much time :-D [00:05:36] hashar: You're up, if you don't mind deploying it for me [00:12:37] James_F: wow, this is a huge meme apparently. I'm telling you I thought it was from a movie or tv show or something. It's a friggin meme (well become, it was a news interview at first) [00:12:39] marktraceur: done :-] [00:13:07] totalling up to 50M views on the tube. crazy. [00:13:28] marktraceur: so basically, NEVER use npm on that box :-] [00:17:59] hashar: I've learned this. [00:19:19] Krinkle: Yes, it's a huge meme. :-) [00:49:59] hashar: Ok [00:53:32] hashar, Krinkle: If I were to put tests on Jenkins for the junitdiff tool, would it still be wise to keep the node_modules in the repository? [00:53:53] Why would it be different? [00:53:59] It seems like it might be too few steps to provide adequate protection for us, but I could be wrong. [00:54:16] I mean, if I push a patch that changes the node_modules, then without any review, the modules get pushed to Jenkins [00:54:37] Not if Joe Schmoe does the same, but...well, maybe that's good enough [00:54:51] But it is fixed in the repo, and pushed from your local machine. [00:55:05] Um... [00:55:08] Not npm install for every test 24/7 fetching god knows what from npmjs.org [00:55:12] Right [00:55:18] Oh, OK, fair enough. [00:55:22] if IP = wikimedia, server evil. [00:55:27] whatever [00:55:34] its an edge case, but there's a cut off point here. [00:55:44] Right. [00:55:50] no connections to the outside from the cluster. [00:55:55] so, caching as well. [00:56:04] and availability [00:56:36] Cool. [00:56:58] we might set up an internal npm repo, its opensource, similar (vaughly) to aptitude on ubuntu.wikimedia.org [00:57:02] Also, where are the tools deployed? I'm sure the answer is something that will make me feel ridiculous for not knowing. [00:57:16] marktraceur: integration/jenkins:tools/ ? [00:57:44] I mean, on gallium, where are they found [00:57:47] gallium:/var/lib/jenkins = integration/jenkins (with a bunch of untracked directories for jenkins current state) [00:57:50] Ah. [00:58:01] Cool cool [00:58:17] * marktraceur sets about making the Parsoid Jenkins tests *way* more sexy [01:06:42] marktraceur: I've cleaned up https://www.mediawiki.org/wiki/Continuous_integration/Jenkins and related pages. [01:07:45] Krinkle: Thanks! [01:07:56] If you're planning to improve any jobs, you'll first get to play with JJB. [01:07:57] The new tests run now, and appear to work! [01:08:14] JJB isn't run on the server, but locally. You run it locally and then you have it push to the Jenkins API directly. [01:08:25] marktraceur: what did you do just now? [01:08:55] Krinkle: I've had my jobs configured on the server for some time now...I guess I could convert it, I'll start reading the docs [01:09:13] so they're not in version control, but input via the GUI? [01:09:43] Yeeees.... [01:09:47] :/ [01:09:53] Krinkle: Yeah, I'll convert them [01:09:58] k [01:10:07] https://integration.mediawiki.org/ci/view/Default/job/Parsoid-parserTests-getResults/jobConfigHistory/showDiffFiles?histDir1=%2Fvar%2Flib%2Fjenkins%2Fjobs%2FParsoid-parserTests-getResults%2Fconfig-history%2F2013-03-02_00-47-47&histDir2=%2Fvar%2Flib%2Fjenkins%2Fjobs%2FParsoid-parserTests-getResults%2Fconfig-history%2F2013-03-02_00-47-48 [01:10:11] btw, there's diffs :) [01:10:13] even for the GUI stuff [01:10:19] and history [01:10:22] so you know :) [01:10:35] I do! [01:10:42] I have used it to minor success in the past. [01:36:01] marktraceur: Do you have the symlink to config set up yet/ [02:16:04] TimStarling: doing any cr today? [02:16:31] after lunch [02:17:09] I was working through Brad's list, since he has a big backlog [02:17:43] but I can do some of yours too if you like [02:18:41] heh, I was working through his list the last few days too [02:19:11] it probably takes two people :) [02:26:14] New patchset: MarkTraceur; "WIP: Add parsoid tests to the YAML configs" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/52750 [02:39:03] https://gerrit.wikimedia.org/r/#/c/52571/2/engines/LuaCommon/LuaCommon.php [02:39:16] anomie: how does not caching the expansion avoid expanding parameters? [02:39:58] Aaron|home- Because the only reason it was calling $frame->getArguments() was to construct the cache key. [02:41:57] I see [02:42:02] maybe that comment can be tweaked [02:42:25] since there is no getArguments() call anymore [02:55:31] Aaron|home- Feel free to fix the comment, I can't think of anything to change it to right now. [02:55:41] Otherwise I'll try again in the morning [02:56:27] ok [07:44:22] New review: Jeroen De Dauw; "We appear to be unable to get our shit together and have the tests pass on sqlite..." [integration/zuul-config] (master) C: -1; - https://gerrit.wikimedia.org/r/50178 [07:48:51] New patchset: Jeroen De Dauw; "Revert "trigger test pipeline for wikibase (non voting unit tests)"" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/52766 [08:05:37] may I have a wikimedia.org e-mail account? [08:05:59] may I have a wikimedia.org e-mail account? [08:06:19] sorry about the double thing [09:49:56] Do other people also have a problem with putting drafts in Gerrit? Asking as there's a bug report [09:50:12] average_drifter: as a volunteer? [09:50:21] andre__, I could a few days back [09:50:37] it's a bit of hidden feature, though [09:50:49] bug # ? [09:51:07] Platonides, I know. Just wondering if it also broke for anybody else [09:51:08] https://bugzilla.wikimedia.org/show_bug.cgi?id=45890 [09:56:43] successfully created draft at https://gerrit.wikimedia.org/r/52780 [09:58:01] thanks for testing [10:01:06] andre__: I'm a contractor [10:01:14] average_drifter, aha! :) [10:01:17] andre__: :) [10:01:43] average_drifter, maybe ask your manager, or in #wikimedia-staff ? no idea how to proceed [12:24:16] New patchset: Zfilipin; "Updated Cucumber Ruby gem" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/52790 [16:09:45] multichill, ping [16:09:56] qgil_: Pong [16:10:22] multichill, how would like to reflect "Wikimedia Hackathon" at https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013 ? [16:10:38] I'm about to advertise registration in social media etc [16:10:49] multichill, is renaming the page an option? Title? [16:11:07] qgil_: I hope to be sending out the email later this afternoon. No, please don't rename, already too many things pointing to it [16:11:27] multichill, there is something called redirects, as you probably know... [16:11:49] multichill, but I take what you actually mean and I won't touch it :) [16:12:30] multichill, and I will wait for your announcement to follow on social media [16:12:50] Great [16:15:25] multichill, still I think it would be good to edit the page to change "Amsterdam Hackathon" for "Wikimedia Hackathon" in the main title and the right box. Do you agree? [16:16:01] Wikimedia Hackathon, subtitle Amsterdam 2013 [16:16:05] ok [16:47:54] zeljkof, hi [17:05:38] hi qgil_ [17:05:43] can you talk on hangout now? [17:51:07] qgil_: About to send out an email [17:51:19] multichill, ok thanks [17:59:59] multichill, twitter, identica, G+, Facebook and mw.org homepage [18:00:01] done [18:09:35] qgil_: Can you check https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013/Scholarships ? [18:11:43] New patchset: MarkTraceur; "WIP: Add parsoid tests to the YAML configs" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/52750 [18:22:31] ^demon: https://gerrit.wikimedia.org/r/#/c/52880/ tiny change [18:26:25] New patchset: MarkTraceur; "Add parsoid tests to the YAML configs" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/52750 [18:30:37] multichill, looks good (sorry, I was in a meeting) [18:31:43] Ok. I updated https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013 . Now time to stalk people to get them subscribed ;-) [18:34:56] notpeter: xyzram: I opened a bug to review the lsearch-global.conf generated for beta. The [Database-Group] is definitely wrong :-] [18:34:57] https://bugzilla.wikimedia.org/show_bug.cgi?id=45908 [18:35:47] hashar: I'll take a look [18:36:15] xyzram: we are very close to have search setup on beta :] [18:37:01] Great! [18:37:18] multichill, the next would be a post in the tech blog. How does this sound? [18:37:31] like a plan :-) [18:37:44] multichill, have you posted there before? [18:37:46] Strange that that file doesn't use some standard format like YAML or JSON or even XML [18:38:29] hashar: Instead it has its own idiosyncratic syntax that is painfully parsed with regexes in Java. [18:39:19] xyzram: feel free to hack lucene-search-2 to make it recognize XML / YAML :-] [18:39:28] I have no idea how that syntax work :-( [18:39:49] hopefully there is a way to have a catchall group that will get all the index deployed on the lonely search box [18:44:24] Been a while qgil_ [18:44:40] I still have to write a post about the RCE upload too [18:45:42] multichill, fwiw http://meta.wikimedia.org/wiki/Wikimedia_Blog you can just draft there [18:56:43] ^demon: https://gerrit.wikimedia.org/r/#/c/52877/ another micro-commit [18:56:46] New patchset: MarkTraceur; "Add parsoid tests to the YAML configs" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/52750 [19:08:09] New patchset: MarkTraceur; "Add the JJB parsoid jobs" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/52883 [19:11:20] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/52883 [19:12:22] New review: Hashar; "deployed :-]" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/52883 [19:12:31] marktraceur: I got your zuul config deployed :-] [19:18:04] New patchset: Hashar; "jobs for admin tools extensions" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/52887 [19:19:40] Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/52887 [19:38:44] !g I9c4c5350ecab26515ebd8967414902dd7b5642ad [19:38:44] https://gerrit.wikimedia.org/r/#q,I9c4c5350ecab26515ebd8967414902dd7b5642ad,n,z [19:39:09] New patchset: Hashar; "triggers for admin tools extensions" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/52896 [19:39:17] New review: Hashar; "Zuul part https://gerrit.wikimedia.org/r/52896" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/52887 [19:39:39] New patchset: Hashar; "triggers for admin tools extensions" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/52896 [19:39:47] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/52896 [19:46:47] New patchset: Hashar; "mwext-GlobalBlocking-jslint now voting" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/52900 [19:47:00] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/52900 [19:55:07] Krenair, Ryan_Lane you might be happy to read this: http://www.mediawiki.org/wiki/User:Qgil/Contributors#One_wiki [19:56:48] yay [19:57:12] What tech development content do we have outside of mediawikiwiki/wikitechwiki? [19:58:00] Krenair, Meta has Wikidata and Mobile stuff, English Wikipedia has a lot about Bots & Gadgets (and now Lua) [19:58:02] ... [19:58:42] qgil: mailman is not integrated [19:58:48] that would be…. difficult [19:59:04] mailman doesn't really have a concept of users [19:59:07] just passwords for lists [19:59:08] Ryan_Lane, I know, but could it be? At meego.com we had it (but that was Drupal) and afaik it was useful to extract stats [19:59:22] * Ryan_Lane hates mailman [19:59:25] how did it integrate? [19:59:26] Ryan_Lane, although I might be mistaken and the stats were retrieved from non-integrated Mailman directly [19:59:41] jdlrobson: could you take a look at CentralNotice master and make sure it didn't break mobile -- we just merged in the work I did with you on monday -- so CN knows about the new variable but is only using it to not show to mobile -- I'm currently working on fixing adam's quibbles with the patch that makes centralnotice serve to mobile [20:00:02] jdlrobson: but I'll bug you about that separately when it's done [20:00:12] sure thing [20:00:14] i'll do that in 5 mins [20:00:21] *thumbs up* [20:00:27] Ryan_Lane, you could subscribe / unsubscribe to mailing lists from the Drupal interface, and from there I bvelieve the system could map your single sign-on with your activity in mailing lists [20:00:28] qgil: we also have hundreds of lists, most of which are community. I think they wouldn't be very happy to have things change [20:00:35] ahhhhhhh [20:00:36] that [20:00:37] I see [20:00:40] that could be interesting [20:00:49] I think we'd need to make an interface for that, though [20:00:59] anyway, not a top priority. Bugzilla comes clearly first [20:01:10] yeah [20:01:15] bugzilla can be done with openid [20:01:24] when we add an openid provider to wikitech [20:01:40] woop [20:01:43] (read: "openid") [20:01:46] hi [20:01:59] my shop has opened [20:04:29] I invite those of you who are interested to visit the new OpenID preference tab http://openid-wiki2.instance-proxy.wmflabs.org/wiki/Special:Preferences#mw-prefsection-openid [20:05:03] Wikinaut: can you publish that change? [20:05:10] there's nothing security related about it [20:05:18] it's always best to not use drafts, if possible [20:07:14] mwalker: no broken js so i think we are good... :) [20:07:22] whoo! [20:07:30] Ryan_Lane: hi [20:07:36] Wikinaut: hi [20:07:44] yes, but I will make somesmall changes [20:07:59] there's no reason to use a draft ;) [20:08:14] I found it very convenient for myself ! [20:08:15] for instance, I can't +1 [20:08:19] until I publish [20:08:36] well, don't ask for a review until you publish in the future, then ;) [20:08:56] jajaja [20:09:05] it's better to do work in the open. drafts are evil [20:09:10] jajaja [20:09:20] they are useful for hiding security work right before publishing, but that's about it [20:09:23] I need some tips from you [20:09:43] some people complaint about the xml business in OpenID.hooks.php [20:09:50] can you show me how I can do better ? [20:09:54] Ryan_Lane: are drafts not present in git refs fetched? [20:09:55] that xml is old stuff [20:10:07] I will improve, but need some guidance [20:10:10] pls. [20:10:12] one example [20:10:25] it's always best to not use drafts, if possible [20:10:26] TIA (thank you in advance) [20:10:31] also don't use drafts for security fixes [20:10:40] he ? [20:10:45] what else ? [20:10:51] Krenair: ^ [20:11:01] Krenair: I'm talking about using them as the last step [20:11:32] <^demon> saper: They shouldn't show up in the list of published refs on fetch... [20:11:44] <^demon> However, there's some other Freaky Magic that makes me not trust them. [20:12:13] specifically, get everything good in bugzilla via patches, get an email ready, send in the change as a draft, send the email, publish/merge [20:13:52] ^demon: do you think we could publish gerrit log somewhere? 80% of bugs reported need exception traces or soething :( [20:14:23] <^demon> saper: Most of it's probably fine. I'm afraid of it not being totally sanitized though. [20:14:43] ^demon: what could be dangerous there? [20:14:54] <^demon> Password or something? [20:15:42] I just checked [20:15:49] git fetch origin refs/changes/*:refs/changes/* [20:15:53] gives drafts as well [20:15:58] <^demon> Well that's just dumb. [20:16:10] <^demon> I think I'm being paranoid...I don't think I've ever seen a password in the log. [20:16:19] why shouldn't it [20:16:26] give drafts [20:16:51] objects need to be in git anyway, it's hard to tell git "those commits trees and blobs are private" [20:29:08] <^demon> saper: Well, gerrit should only announce things you have read access to :) [20:29:18] hashar: So it turns out, while Jenkins supports multiple SCMs, JJB only supports one per job. I'm now torn between hacking in the functionality I need and implementing it in JJB. [20:29:31] ^demon: It shouldn't even let you fetch a draft even if you know about its existence [20:29:40] <^demon> Indeed. [20:29:45] (which isn't hard to infer, because changes are numbered sequentially) [20:29:55] ^demon: doubt you can do JGit-level filtering; and frankly, I don't think it should be ever implemented. All this obscurity is wrong to me. [20:30:30] <^demon> Gerrit's supposed to do ref-level filtering... [20:30:38] <^demon> Since you can set READ on various branches, etc. [20:31:03] Gerrit is corporate enough with its bizantine permission system [20:31:42] let me try to take away READ on my instance [20:33:11] marktraceur: also consider #openstack-infra where you can get support regarding JJB :-] [20:33:24] marktraceur: and python and sphinx doc etc… They are nice peoples. [20:34:45] "we the peoples of the united nations" :) [20:51:28] New patchset: MarkTraceur; "Add parsoid tests to the YAML configs" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/52750 [20:52:06] New review: MarkTraceur; "Running on Jenkins now, so, that's good." [integration/jenkins-job-builder-config] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/52750 [20:52:23] hashar: Whenever you get back from lunch, a merge would be good ^^ [21:02:31] jdlrobson: wanna talk about skins today? [21:48:27] <^demon> saper: So, that NPE on drafts...lots of that part of the code has changed recently...I wonder if it's already fixed. [21:55:10] ^demon: WORKSFORME on my gerrit [21:55:29] <^demon> Which version are you running? [21:56:13] posted on bugzilla, w8 [21:56:27] 2.5.2-13 [21:56:29] er [21:56:39] 2.5.2-1365-g7609714 [21:58:31] looks like g.wm.org is 141 changes ahead of me [21:59:00] <^demon> Yeah, we're on 278aa9a. [21:59:04] ^demon: I'm sorry to bother you, but when is the next time you intend to go over the repo creation requests? [21:59:11] <^demon> This afternoon. [21:59:25] Great; thanks [21:59:34] vvv: In Soviet Russia git repositories create you [21:59:49] ^demon: can you paste the exception to the bug? [21:59:49] * vvv thinks about what timezone is that [21:59:52] <^demon> saper: I did, I thought. [21:59:54] <^demon> It was that NPE. [21:59:55] vvv: SF [21:59:59] PST [22:00:22] ah sorry didn't get a mail [22:00:43] I thought ^demon was east coast :) [22:00:48] <^demon> I usually am :p [22:01:22] <^demon> vvv: Your repo is ready [22:01:23] you TRAVEL! [22:01:29] ^demon: thanks [22:01:57] I'm trying to debug a ResourceLoader thing: I made a manual rtl change in a css file, which behaves well with debug=1, but in regular minimized mode, I get stale css as well as the new stuff. [22:02:12] what gives? Is RL caching even on my uncached dev box? [22:02:27] <^demon> awight: It caches by default :\ [22:02:30] ^demon: yeah, this code changed a lot, looks like a regression [22:02:33] thanks -- where? [22:02:47] it has not purged in over a day [22:03:25] omg stupid bug [22:03:53] <^demon> awight: Off the top of my head, can't remember. https://www.mediawiki.org/wiki/Manual:Config#Resource_loader might give you some options to make it cache less agressively. [22:05:47] dammit. The default cache is 30 days [22:06:21] <^demon> saper: If we can get it in upstream, I can get a new build out this afternoon. [22:06:48] There is some "versioned" attribute I should have paid more attention to. [22:07:51] ^demon: did you see "Cannot submit draft patch sets" in the log before the exception? [22:08:41] <^demon> Nope, nothing like that. [22:09:49] awight: What did you change exactly? [22:10:05] awight: It should just reversion based on the mtime of the file [22:10:20] Messed with a file in DonationInterface...gateway.css [22:10:32] Yeah i'm looking for how to set the RL Context version [22:10:46] You shouldn't need to [22:10:47] So I'm not supposed to bump anything... ok [22:10:55] Yeah it should Just Work [22:11:06] There is a 5-minute cache on the manifest with the timestamps though [22:11:13] Well... I believe I'm getting two versions of the file when debug=1 [22:11:24] But worst case if you touch the .css file , then wait 5 minutes and/or hard refresh, if should start working in debug=0 [22:11:25] Maybe that indicates a problem with how i'm including [22:11:32] debug=1 just serves the file straight from Apache [22:11:52] So if that screws up you're probably doing something weird [22:12:31] hehe, there it is: wgExtensionAssetsPath . '/DonationInterface/gateway_forms/css/gateway.css?284 [22:12:34] ^demon: or anything related to submit/submit results before? [22:12:46] looks like a workaround [22:13:21] Ahm, yeah [22:13:25] <^demon> saper: Nope, only thing before that was some annoying MINA IOExceptions. [22:13:29] If you are bypassing RL, don't be surprised if RL doesn't work [22:13:35] RoanKattouw: cool, thanks for the troutslap ;) [22:13:46] haha [22:14:31] ^demon: okay [22:17:25] AaronSchulz: are you in the office today? [22:19:21] ^demon: testing one-line patch :) [22:24:32] ^demon: fix already upstream :) [22:25:11] <^demon> I thought it was checking for null already. What commit fixed it? [22:25:34] https://gerrit-review.googlesource.com/#/c/42850/ [22:25:36] it is not [22:25:46] besides, master has much more null checks in that file [22:26:01] <^demon> *nod* [22:26:03] but also change some other stuff [22:26:26] * saper 's mvn clean [22:27:22] <^demon> I wanted to update to at least 414b058 anyway...current HEAD looks good and will grab all the fixes we need. [22:32:19] ori-l: where does that 'Your edit has been saved' code live now? [22:32:29] Extension:PostEdit [22:32:38] core:extensions/PostEdit [22:32:39] I might be stealing some of it for the 'thank' notification [22:32:51] does it have an API or anything? [22:33:13] no, sadly -- we were working on it precisely when the mw.notify JS API was undergoing a thorough re-write [22:33:25] but there is an API in core JS for notifications [22:33:36] ^demon: this change is only 7 commits away from the current wikimedia gerrit [22:36:55] New review: Hashar; "> Also, will it complain on the skin files which contain ?> html Change abandoned: Hashar; "(no reason)" [mediawiki/tools/codesniffer] (master) - https://gerrit.wikimedia.org/r/48602 [22:38:17] binasher: I was wondering if *you* were a while ago :) [22:38:39] i'm tricky like that :) [22:45:24] <^demon> saper: Just built 2.5.2-1611-g3f4a022, gonna test that out. [22:55:47] stupid jenkins does not merge :/ [22:57:51] Eh, what happened with gerrit? [23:02:40] vvv: upgrade? :) [23:03:06] not yet [23:03:34] qgil, hey, do you have any idea who can access the @mediawiki twitter account? [23:03:43] !b 45915 [23:03:43] https://bugzilla.wikimedia.org/45915 [23:04:26] Krenair, I'm one of them [23:04:33] Krenair: qgil: see https://bugzilla.wikimedia.org/show_bug.cgi?id=45915 [23:04:34] <^demon> Not upgrade, tried to push out auto-linking for CVEs. [23:04:50] (uh, did not see the lines above) [23:05:38] ok thanks, I'll discuss there [23:10:03] another gerrit config change is coming through [23:13:15] hashar: http://lists.wikimedia.org/pipermail/wikimedia-l/2013-March/124448.html [23:17:54] brion: http://www.thepoke.co.uk/2013/03/06/cats-being-total-jerks-for-no-apparent-reason/ [23:18:57] very nice [23:21:50] +1 [23:22:33] in German http://www.youtube.com/watch?v=KLSdOY-6R_U no cats [23:23:45] adn for Berlin fans: http://www.youtube.com/watch?v=CSSp6jOUnuM no visible cats [23:38:48] <^demon> saper: Heh, more refactoring there: https://gerrit-review.googlesource.com/#/c/43230/ [23:39:23] RoanKattouw: I see there is a RL module to pull files from the wiki... can I really store css and js on-wiki? [23:39:46] I don't see the $wgResourceModules syntax to cause such a thing to happen [23:40:19] Yes you can [23:40:27] yikes. I like. [23:40:28] You need to define a custom subclass of ResourceLoaderModule [23:40:40] In such a subclass you can generate JS and CSS however the hell you want [23:40:47] Hmm it looked like ResourceLoaderWikiModule was doing that already [23:40:52] The standard syntax defaults to ResourceLoaderFileModule [23:40:58] ok rad [23:41:00] And you can subclass ResourceLoaderWikiModule for your ends [23:41:18] Do you think the world would end if we had CentralNotice use RL to serve banners? [23:41:23] There are other extensions that do this already, grepping for RLWikiModule should find them [23:41:24] ^demon: I'm starting to appreciate prolog... [23:41:29] Operations-wise, probably not [23:41:36] thx [23:41:38] The RL servers aren't very loaded [23:41:41] <^demon> saper: Get out and get some sunshine, that can't be healthy ;-) [23:41:46] As long as you don't invalidate the cache all the time you'll be fine [23:41:53] * awight loads flash pan and points at less dominant foot [23:42:12] * awight takes a swig first [23:42:12] They're also clearly not ridiculously inefficient because we're already serving them from MW [23:59:05] New patchset: Hashar; "Add parsoid tests to the YAML configs" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/52750 [23:59:30] * marktraceur looks [23:59:31] New review: Hashar; "Congratulations :-]" [integration/jenkins-job-builder-config] (master); V: 2 C: -1; - https://gerrit.wikimedia.org/r/52750