[00:12:26] the sample sizes obviously get very small if you try to cut it up too much [00:15:14] we could commit to providing security patches and critical bugfixes for the last PHP 5.3-compatible release [00:15:38] So make 1.26 a sort of LTS? [00:15:54] yeah [00:16:08] And 1.27 aswell? [00:16:23] maybe just one or the other [00:16:34] it'd be a bit like python 2.7 [00:18:20] I'd even be in favor of making the next release number be 2.0. [00:20:30] ori: please wash your mouth out with soap [00:21:14] I added an "analysis" sheet to the responses spreadsheet, this may possibly link to it: https://docs.google.com/spreadsheets/d/1kT4l4TiewtsJYNmx6UfX9xDqrhWBcpw1fKrgbd55oMc/edit#gid=675534802 [00:21:30] that is a breakdown of upgrade difficulty by PHP version [00:21:40] 1=easy, 4=very hard [00:21:55] well, I'll just replace those labels [00:27:29] Do we presume the 1.2 versions of MW in the table are a typo? [00:28:30] multiple responses within a few minutes suggets the same person [00:29:42] that is google spreadsheets interpreting 1.20 as a number [00:30:05] there was no free form text for that question, only "1.19 or earlier" [00:42:10] one thing that's interesting to me is the high rate of shared server usage, 24% [00:43:06] you know there has been some speculation as to whether anyone still runs MW on shared hosting, well there is your answer [00:43:51] I know there's 101 questions these things open up... [00:43:59] 30% if you include 1-click installation [00:44:11] Are they running a big site? Lots of users...? [02:07:26] woohoo [02:07:48] http://bit.ly/1N850L5 is a sparql query that shows extensions which are using deprecated hooks, and what version the hooks were deprecated in [02:08:58] that's very neat [02:09:07] note that I only imported extensions that have an extension.json file to start [02:09:11] :) [02:09:17] Did we turn on arbitrary wikidata access to mw.org yet? I wonder if we can just start using [[Q83]] [02:09:29] we did :D [02:09:29] (To save time on template updates when we release :P) [02:10:23] right now I'm working on importing Template:Extension so we can have ExtensionDistributor use the structured data [02:10:57] it should be doable with a lua module [03:12:33] ostriches: so on https://www.wikidata.org/wiki/Q83#P348, are we only going to keep current release tags? or are past tags going to stay? [03:13:30] Is there no way we can query only latest? [03:13:43] Or greatest # for top N branches? [03:13:52] Right now my plan is to sort by date [03:14:14] That'd work [03:14:15] Probably [03:16:15] * legoktm grumbles at printing tables in lua [03:42:30] > p.stuff() [03:42:30] 1.23.11 [03:42:30] 1.24.4 [03:42:30] 1.25.3 [03:42:30] 1.26.0 [03:42:36] progress! [04:57:36] legoktm: We added a pretty-printer thing at some point. [04:58:08] We did? [04:58:15] Do you remember what it was called? [05:00:09] who can keep track of names around here [05:06:34] https://static-bugzilla.wikimedia.org/show_bug.cgi?id=48173 mw.logObject() [05:10:54] thanks for reminding me Leah [05:23:42] =mw.getLanguage('en'):formatDate('Y-m-d', '+2015-11-00T00:00:00Z') [05:23:42] 2015-10-31 [05:23:45] hmm. [06:25:46] the release notes for NetHack 3.6 (http://www.nethack.org/v360/release.html) end with a nice Terry Pratchett quote, but I won't spoil it :) [07:37:02] bd808: I sketched up some mocking examples at https://www.mediawiki.org/wiki/User:Tgr_(WMF)/Mocking [07:43:40] I've never found phpunit mocking to be intuitive, and always copy-paste previous examples :/ [14:11:19] tgr|away: "best interface" out of which choices? For UI, whatever makes the most sense for a good UI, I just guessed when I wrote whatever is there now. For the User::newSystemUser() deal, the interface needs to be passing in a username with the end result being "that username can't authenticate here anymore", but we can adjust the exact semantics if necessary. [16:56:03] tgr|away: I think this is how Prophecy matches up to your matrix -- https://phabricator.wikimedia.org/P2383 [17:29:37] anomie, tgr: have you seen https://www.mediawiki.org/wiki/Talk:MediaWiki_1.26#AuthPlugin::initUser.28.29_.5B....5D_should_no_longer_replace_the_passed_User_object. ? [17:29:50] legoktm: looking [17:30:47] legoktm: I wonder what problems he's going to run into once AuthManager comes around, then. [17:31:33] :/ [17:32:01] I'm guessing it doesn't let you mangle usernames...I forget if ldapauth does that [17:33:43] There's currently no way to mangle usernames in AuthManager. OTOH, AuthManager no longer requires that the "username" field on Special:UserLogin match the user that actually gets logged in. [17:41:23] hmm, do you want to respond to them on-wiki then? :) [18:00:53] anomie: hangout? [20:24:05] what does one need to do to get rights on a wiki in beta? [20:24:32] i need to test move, delete, restore, and changes to revision visibility [20:25:07] Convince someone with the ability to grant rights on the wiki in beta that it would be a good idea to give you them? [20:25:41] urandom: what's your beta cluster wiki account? [20:25:49] bd808: Eevans [20:28:15] urandom: YOu chould have many superpowers now -- http://en.wikipedia.beta.wmflabs.org/wiki/Special:GlobalUserRights/Eevans [20:28:21] *should [20:28:31] bd808: awesome; thank you! [20:42:36] anomie: is the PageRenderingHash hook still the most proper / idiomatic way for an extension to alter the parser cache option hash key? [20:47:42] ori: An extension could either use that hook or $parserOptions->addExtraKey(), as far as I know. It's possible that a solution to T110269 would add a more targeted way to tell it to include a particular option in the key rather than those two rather untargetted mechanisms. [20:49:59] anomie: thanks, that's useful. If I were to go the route of $parserOptions->addExtraKey(), which hook is the best fit? [20:51:09] OutputPageParserOutput? [20:51:56] ParserFirstCallInit? [20:52:02] SomethingElseEntirely? [20:52:53] ori: What exactly are you trying do? [20:53:40] there's a new feature in mobilefrontend that suppresses srcset attributes on images and increases the jpeg compression level in thumb URLs [20:53:47] i want to make sure that the parser cache varies correctly [20:54:36] the modification of the output is done in ImageBeforeProduceHTML and ThumbnailBeforeProduceHTML [20:55:28] maybe updating the hash whenever the feature is used is easiest [20:57:16] ori: For something like that, I'd say you'd do better to use ParserOutput::recordOption() to record that the feature could have been used at all (e.g. don't trigger it on pages with no images), then check it in a PageRenderingHash hook function (the recorded options show up in the third parameter to the hook). [20:57:49] Also, ugh for yet another hack in the giant pile of hacks that is MobileFrontend... [20:58:36] why do you consider that a hack, in the pejorative sense? [20:58:59] it should be a canonical parser option, in core? [20:59:47] Ideally, we wouldn't need a MobileFrontend extension at all for core to be able to provide decent mobile-formatted webpages. [21:02:42] well, I don't disagree with that, obviously. I'm sorry you think this is making a bad problem worse. I think this particular feature should be implemented in core, but I think we need some experience with it first, so having it go in an extension seems appropriate. I know we've all been burned by the "it's only here *for now*" move, but.... it's only here *for now*. [21:03:21] but I don't blame you for being skeptical :) [22:05:52] AaronSchulz: thank you to have overhauled the tests for the PtHeartbeat patch ( https://gerrit.wikimedia.org/r/#/c/256875/ ) +1 ed it [23:41:39] tgr: qlow jpegs + no srcset is live, btw -- just set a NetSpeed=B cookie