[05:44:11] anomie: Hm.. we could move '$this->getSkin()->setupSkinUserCss( $this );' from OutputPage::output to OutputPage::getRlClient() [05:44:30] Which is essentially the logical point where it was before, but in a way that doesn't retroactively change the module queue unpredictably [05:44:40] It's messy but reflects the mess we had implicitly before this change. [05:44:47] (my ClientHtml refactoring) [13:16:15] tgr|away: I'm slightly wary of magic in the password field, but other than that I have no objection. It'd be nice to have someone from Security look it over. [13:19:46] Krinkle: People are expecting that action=parse gives headhtml output similar enough to a view or preview to function. How exactly we accomplish that I don't have any opinion on right now, since I haven't looked into it. [17:22:50] tgr: anomie I'm going to shrink today's meeting instance to 30 mins, with a start in 38 mins [18:09:05] tgr: anomie sorry, don't know why the connection has gone from bad to worse [18:10:31] tgr: anomie anyhow, regarding q2 fy 2016-2017 goals: as i recall we had a few things as potential: multi-content revision project support, multiple watchlist, ores+pageview data. any updates on those things that would move us one direction or the other? [18:10:36] so, nothing urgent (I still need to fix Sentry on beta and figure out why the OAuth notification config does not work, the first does not effect production and the second just makes a new feature roll out later so neither is an emergency) [18:11:21] dr0ptp4kt: There's been some movement on the ORES front, I'm eagerly watching for either code to review or questions to answer or other things to do there. [18:11:55] thx anomie [18:12:14] re: TemplateStyles, i think the current status is coren plans to work on it, so nothing yet required from us [18:12:51] TemplateStyles is blocked on fixing how the CSS tokenizer coren wrote handles escape sequences [18:12:55] dr0ptp4kt: I haven't seen much on the multi-content revisions stuff lately, still watching that one too for something I can contribute. [18:13:08] it does not seem terribly hard and he intends to work on it [18:14:01] re: ORES, I'm not sure if Aaron's team wants to work on it or they are expecting us to write the API module [18:16:13] multiple watchlists probably should not be done in parallel with the cross-wiki watchlist project IMO, so maybe not the right thing for Q2 [18:16:44] unless you mean some app feature backed by the K-V API [18:19:51] i'm still working from the assumption that the discussion for fulfilling the android app's needs was moving toward the _underscore userjs notion in the short turn and multiple watchlists rfc activity in the medium run. maybe i should ping brion though and check on that? [18:21:31] dr0ptp4kt: the underscore thing still seems like an unnecessary hack to me [18:22:01] it wouldn't be much easier than a dedicated endpoint, just a lot less clean [18:22:30] but yeah, it would be good to clarify that [18:22:30] tgr: i can ask on the ores epic task about the implementer. i think our involvement is probably more on architectural guidance and code review. [18:22:32] underscore thing? [18:23:34] anomie: brion suggested at some point to make userjs-* options with an underscore profix not included in the options hash by default [18:23:53] and so work around the problem that everything gets included on every pageview [18:24:01] hacky. [18:25:07] hacky, and the options API would still require new parameters since now you can't query individual options, so not that much of a difference from writing a new module [18:25:27] just with more tiptoeing around legacy code [18:26:27] in any case, someone (or another IRC round) will have to decide that before we can move forward [18:31:01] anomie: anything for SoS? [18:31:14] tgr: Nothing from me. [18:32:15] tgr: anomie i just emailed with halfak and catrope and amir1 about the ores portion. we'll see if we should meet to discuss further [18:32:48] i'll email brion and cc you anomie and tgr about the key-value, userjs, multiple watchlist stuff [19:14:52] hello AaronSchulz tgr Krinkle I got a fresh CentralAuth patch https://gerrit.wikimedia.org/r/#/c/306021/ that caused a fairly large spam of notices when pushing 1.28.0.wmf-17 [19:14:55] so I have rollbacked [19:14:57] https://gerrit.wikimedia.org/r/#/c/306021/ [19:15:16] and the task is https://phabricator.wikimedia.org/T144307 "Undefined index: mVersion in /srv/mediawiki/php-1.28.0-wmf.16/extensions/CentralAuth/includes/CentralAuthUser.php on line 494 [19:15:17] " [19:15:20] hashar: yeah, saw it, should be fine to revert [19:15:25] I am merely wondering if we can "just" revert it [19:15:37] and should we revert in both master and the wmf branch ? [19:16:07] tgr: aaron got a patch :] [19:16:12] apparently similar to another issue hehe [19:16:15] hashar: I'd rather put a change in wmf17 [19:16:30] up to you really [19:16:43] my point is if it is easier to revert than fix, lets revert [19:16:45] just an isset() [19:16:48] if a fix is easy, lets fix it :] [19:17:02] (I havent even looked at the code :((( ) [19:18:54] * AaronSchulz already sees 78189b004d235440f9d023bef005d3cdda8fa081 [19:19:26] oh, duh, the cache miss message code still reference it ;) [19:19:58] Aug 30 19:19:42 mw1244: #012Notice: Undefined index: mVersion in /srv/mediawiki/php-1.28.0-wmf.16/extensions/CentralAuth/includes/CentralAuthUser.php on line 494 [19:19:59] got one again [19:20:07] though code is not supposed to be around anymore [19:20:13] I guess you are testing it :D [19:20:53] hashar AaronSchulz [19:20:53] Wikipedia's W.svg [19:20:53] Free [19:20:53] Open source, Wikimedia commitment to freedom. [19:20:57] woops [19:21:01] sorry [19:21:04] wrong paste [19:21:09] https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/wmf/1.28.0-wmf.17/includes/CentralAuthUser.php#L494 [19:21:12] that one [19:21:37] hashar: https://gerrit.wikimedia.org/r/#/c/307563/ [19:21:51] AaronSchulz: where is the test!!!! :]] [19:22:07] AaronSchulz: that is a nice one [19:22:24] heh, I *thought* I already managed that...forgot about the logging, heh [19:22:28] I should have read the code reallyl [19:22:48] no problem [19:22:53] I have just freaked out [19:23:26] Strange i doint see that line here https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/wmf/1.28.0-wmf.17/includes/CentralAuthUser.php#L494 [19:24:21] Thats because it is in wmf/1.28.0-wmf.16 [19:24:31] hashar was the error in wmf/1.28.0-wmf.16 ? [19:24:53] yeah [19:24:59] Ok [19:25:00] but triggered by code in wmf.17 [19:25:12] Thanks for replying [19:25:21] AaronSchulz: thank you very much. [19:26:05] * AaronSchulz goes from defcon back to looking at some random task T139893 [21:13:51] MaxSem: are you free to cr stuff? [22:10:07] I think NewParserTest is going to become a small wrapper for ParserTest, and command line processing in ParserTest will move into a new Maintenance subclass [22:10:43] I've been pondering which one to delete, but NPT calls PT and not the other way around, so it makes sense to get rid of NPT [22:11:19] Hi im wondering could someone review https://gerrit.wikimedia.org/r/#/c/193434/ please? [22:11:21] there's a couple of nice features in NPT that aren't in PT, such as the use of MockFileBackend, so those will be copied across to PT [22:17:43] class MockFileBackend extends MemoryFileBackend [22:17:49] I remember writing the later for fun [22:18:38] maybe we should have a MockFileRepo as well, and avoid even setting up the image table [22:21:38] I see only two methods with global in FileRepo, and writes could go to the mock backend [22:21:45] *globals [22:22:33] there's a lot of code in MediaWikiTestCase that I haven't really looked at yet [22:23:04] it's a bit awkward when both MediaWikiTestCase and ParserTest are trying to set up services [22:23:24] TimStarling: you mean haven't looked at ever? [22:24:44] I'm sure it has at least scrolled rapidly by in vim [22:24:50] maybe some part of my brain registered it [22:25:17] so it's terrible then? [22:26:08] it's... variable, like most testing code [22:27:06] some bits presumably added by legoktm that look pretty bulletproof [22:27:46] I've also been reading the source of PHPUnit itself [22:28:21] it's a weird combination of careful engineering and terrible eye-watering hacks [22:29:07] MediaWikiTestCase is terrible. [22:29:15] It's probably some of the worst MW code I've ever written [22:29:32] TimStarling: I apologize in advance, a good part of that cruft in phpunit / parser tests is my fault. [22:29:45] you introduced NewParserTest didn't you? [22:29:53] Probably, or at least did a good bit of work on it [22:30:02] The idea was to move all of the parser test stuff to phpunit [22:30:30] yeah, the trouble is, phpunit is not a particularly elegant framework [22:30:39] Yeah. It was slower, and people still liked parserTests.php, so I kinda left the project half-baked [22:31:03] for example we have static methods and static data in NewParserTest, just because phpunit needs to call things statically [22:31:16] Problem with MediaWikiTestCase is it does *too much* setup and tear down. [22:31:35] Ideally, most tests become truly unit and can subclass PHPUnit_TestCase or w/e it's called directly. [22:32:17] on my laptop phpunit --group Parser was taking 2 minutes, and parserTests.php was taking 20 seconds [22:32:26] I was curious about that, so I looked into it [22:32:53] most of the overhead was MySQL SELECT queries, specifically NewParserTest was attempting to add all the articles on every test [22:33:08] so it would check for article existence, and skip the article because it was already inserted [22:33:26] this was something like 150k queries overall [22:33:46] fixing this brought the runtime down to 30s [22:38:07] who introduced the eval() in MediaWikiParserTest.php? git blame is being difficult [22:38:40] I think I can get rid of it easily enough [22:39:43] phpunit lets you override the group list and class name in PHPUnit_Framework_TestCase subclasses [22:58:22] [ed421d8bc0c75ed122a509d9] Exception Caught: The content format json is not supported by the content model wikitext. [23:08:02] never mind