[00:17:54] <^d> robla: +1 to current job desc. draft [05:38:58] 6MediaWiki-Core-Team, 10OCG-General-or-Unknown, 7HHVM, 7Wikimedia-log-errors: OOM reported at SpecialPage.php:534 due to large output from Special:Book - https://phabricator.wikimedia.org/T89918#1091228 (10jeremyb) [06:14:29] 6MediaWiki-Core-Team, 7HHVM: HHVM with FastCGI does not support streaming output - https://phabricator.wikimedia.org/T91468#1091253 (10tstarling) The output functions in execution-context.cpp can be made to stream their output to the transport, I have a patch for that. But then the transport allocates an unbou... [06:16:41] what a big pile of fail [06:18:30] imagine writing your own async I/O library and not bothering to include write buffer limits or any way to wait for the write buffer to not be full [06:20:26] just guarantee that all writes will succeed due to them being stored in infinitely large queues [06:21:27] just because your use case this month happens to involve writing relatively small amounts of data relatively slowly [06:21:56] imagine if your outbound network was saturated! it's a whole-server infinite queue [06:22:39] every HHVM worker would segfault or be killed, cluster-wide [07:06:22] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Pluggable inline values - https://phabricator.wikimedia.org/T90131#1091289 (10Smalyshev) So I tried to make a quick hacky patch to com.bigdata.rdf.internal.impl.extensions.DateTimeExtension to make it use our previous model (date as long... [11:00:19] 6MediaWiki-Core-Team, 10Datasets-General-or-Unknown, 6Services, 10Wikimedia-Hackathon-2015, 7Epic: Improve Wikimedia dumping infrastructure - https://phabricator.wikimedia.org/T88728#1091784 (10Qgil) [16:00:59] manybubbles: I wonder if we should figure out how to backport PSR-3 logging to 1.24. [16:01:36] at least to make it somehow non breaking for things like that Cirrus issue [16:01:38] I dunno. I know cirrus has at least 3 "active" external users. As in they file bugs and stuff. [16:01:57] and they run 1.24 [16:02:02] I wanted it (PSR-3) in 1.23 :/ [16:02:07] yeah [16:02:42] I can see this causing lots of other LTS backport issues [16:02:52] <^d> lol lts [16:03:24] ^d: careful. I think you own LTS management now ;) [16:03:37] <^d> I own the release, yes [16:03:43] <^d> I shall make no further claims of LTS [16:03:59] <^d> 1.23: the once and only LTS :D [16:04:20] we only deploy twice a day in prod. Each version is stable for up to what 16 hours between deploys? [16:04:42] should be enough for anybody! [16:04:47] bd808: 14 hours - don't kid yourself [16:04:53] heh. right [16:05:25] <^d> bd808: We could pull a Phab and just say "run from master or gtfo" [16:05:26] <^d> :) [16:06:12] sure. We could switch to open core and get some revenue too... [16:06:29] * bd808 is trolling [16:07:42] <^d> Anyway, 1.25 release is May as planned. [16:07:54] <^d> Beyond that I don't have an evil-plans.txt yet [16:08:41] * bd808 remembers when having a .plan file was actually useful on the internetz [16:09:48] John Carmack wrote a "blog" in his plan file that you could read via finger [16:11:24] heh. Some uber nerd actually managed to archive them -- http://floodyberry.com/carmack/plan.html [16:12:32] oh. the uber nerd is Carmack himself [16:14:09] * ^d wanted to figure out why he had so much packet loss this morning [16:14:14] <^d> But no, it's time to play with zuul [16:16:54] :/ [16:19:32] manybubbles, bd808: you could have a class in Cirrus that just does if ( class_exists( 'MWLoggerFactory' ) { ... } else { wfDebug( ... ); } [16:20:10] legoktm: yuck [16:20:41] it's how most extensions support back compat :P [16:21:11] Is it bad form to backport large features to a stable branch? [16:21:24] s/large/not tiny/ [16:21:26] <^d> Usually, but we can make exceptions [16:21:39] typically backports are for bug fixes, not new features. [16:21:40] The config is 100% back compat [16:21:44] <^d> bd808: If only you knew the guy in charge of the releases now ;-) [16:22:14] bd808: this would mean 1.23 is dependent upon Psr/Log, and iirc that branch still has a composer-example.json in it... [16:22:42] Yeah, we'd have to jam PSR-3 into core in 1.24 [16:23:01] but just the 3 or so classes we use [16:23:18] and we wouldn't need the monolog stuff [16:23:29] just the psr-3 legacy logger [16:23:34] and the logger factory [16:23:43] oh wait, 1.24 or 1.23? [16:24:11] ummm.. the LTS which ever one that is [16:24:42] 1.23 [16:24:43] <^d> Actually 1.19.x is still LTS too [16:25:02] which I guess would mean 1.24 as well [16:25:31] I... 1.19 dies in 2 months [16:25:37] <^d> EOL for 1.19 in May yeah [16:26:25] I can at least take a shot at a 1.23 backport so folks could see what it would look like [16:26:35] I think I can keep it pretty small [16:27:08] <^d> EOL for 1.23 isn't until May 2017 [16:27:21] <^d> Having the new logging there will make life way easier. [16:27:31] yeah [16:27:46] at least having something that works as a bridge [16:31:13] https://phabricator.wikimedia.org/T91653 [16:31:57] stealth for the moment; I didn't link it to well known projects [17:14:03] 6MediaWiki-Core-Team, 10MediaWiki-Authentication-and-authorization: Audit extensions for use of $wgAuth - https://phabricator.wikimedia.org/T91303#1092609 (10Anomie) AuthPlugin-implementing extensions: * LdapAuthentication * CentralAuth * Auth_remoteuser (not WMF deployed) * MediaWikiAuth (not WMF deployed, ev... [17:18:47] MediaWikiAuth is a pretty fantastic extension :P [17:46:42] 6MediaWiki-Core-Team, 10CirrusSearch: CirrusSearch: * or ? at the start of a word is ignored - https://phabricator.wikimedia.org/T91666#1092721 (10Manybubbles) 3NEW [18:02:37] 6MediaWiki-Core-Team, 10MediaWiki-Maintenance-scripts: namespaceDupes not handling deleted namespace redirects as desired - https://phabricator.wikimedia.org/T91401#1092772 (10greg) [18:02:58] bd808: I just added MWCore to that ^, help appreciated [18:03:10] Core PM help, that is [18:03:47] Was this related to the bug that Tim was looking at a couple weeks ago? [18:04:41] manybubbles, standup [18:07:41] greg-g: TimStarling was working on something that looks related a couple weeks ago -- https://phabricator.wikimedia.org/rMW64765720b0b5cf4290a9d8f22bc10f13e3b7c101 -- https://phabricator.wikimedia.org/T87645 [18:08:57] 6MediaWiki-Core-Team, 10MediaWiki-Authentication-and-authorization: Audit extensions for use of $wgAuth - https://phabricator.wikimedia.org/T91303#1092792 (10Anomie) An evaluation of AuthPlugin methods: * AuthPlugin::userExists( $username ) ** AuthManager will probably need this. Do we also want to support que... [18:10:25] bd808: hmm, yeah, those changes from tim were made before chad ran the script, so... [18:12:09] <^d> I'm not sure what people mean by redirects here [18:12:33] <^d> We removed the namespace and there was no pages left there (including redirects...) [18:12:41] <^d> So unless we define a namespace alias... [18:13:21] <^d> Oh crud I did exclude redirects [18:13:26] <^d> Hmm, I see [18:18:18] ^d: so is this an operational thing or more bugs in the script? [18:18:34] <^d> I don't think the script knows how to handle this case at all [18:20:11] k. Is it worth poking t.im to see if he can make it handle the case? [18:20:36] <^d> Yep, basically what the script does (and Tim did make fixes here) is to handle cases where pages are /not/ in a namespace because it was freshly added or /should be in a different namespace/ than they are [18:21:06] <^d> It doesn't handle the case of "the page is currently in an orphaned namespace that we have no name for" [18:23:53] <^d> It's fixable from where we're at...hmm [18:28:28] ^d: Does https://gerrit.wikimedia.org/r/#/c/190416/ have anything to do with it? (probably not) [18:30:06] <^d> Not really no [18:30:22] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Pluggable inline values - https://phabricator.wikimedia.org/T90131#1092926 (10Manybubbles) 5Open>3Resolved Stas proved this works. [18:30:23] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Verify features work - https://phabricator.wikimedia.org/T90124#1092928 (10Manybubbles) [18:43:04] <^d> bd808: I think it could be bolted onto namespaceDupes [18:44:04] <^d> Use existing --add-prefix and --dest-namespace, have --source-pseudo-namespace accept something like an int to check [18:46:02] * bd808 nods as though he understands the problem or the solution [18:46:38] bd808: good PM skillz there [18:46:55] So it sounds like there is a code change task here that we could write up in phab and then I could shop around for somebody to work on it [18:48:27] bd808: which is basically that task [18:48:45] true enough [18:49:56] ^d: can you dump your analysis into T91401? I can copy-pasta the irc too I guess [18:50:13] <^d> I've got a WIP patch [18:50:25] sweet [18:55:55] :) [19:11:51] <^d> Halfway working. [19:11:56] <^d> I'll put my WIP up [19:19:35] <^d> bleh, this was never meant to happen like this [19:20:42] <^d> bd808: https://gerrit.wikimedia.org/r/#/c/194570/ [19:23:34] <^d> Checking prefix "350" vs namespace 0 [19:23:35] <^d> id=1 ns=350 dbk=Main_Page -> 350-_Page (no conflict) DRY RUN ONLY [19:23:50] <^d> I wasn't joking. 350-_Page is a shit page name [19:24:26] <^d> Although maybe I'm trying to shoehorn this script into doing something it wasn't meant to [19:27:03] see also: MediaWiki [19:30:10] <^d> Well halfway through my patch I started wondering if I just needed a new script [19:57:19] <_joe_> manybubbles: I can surely get you more disk space on labs, I'll do that tomorrow [19:57:30] thanks! [19:57:34] <_joe_> sorry for missing the meeting today, I was deep into codfw [19:57:55] <_joe_> the dallas dc [20:06:38] np [20:06:56] I hear the weather is bad there - but I assume you are reaching through the internet [20:39:25] csteipp-ish: https://www.mediawiki.org/wiki/OAuth/For_Developers#Application_Approval That still says that stewards do the approval [20:39:33] but that's not true... shall we change it? [20:39:42] Keegan: legoktm ^ [20:40:01] hoo: Change the wiki, or the approval process? [20:40:04] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Validate AST rewrite - https://phabricator.wikimedia.org/T90128#1093422 (10Manybubbles) 5Open>3Resolved I consider this feature validated :) [20:40:05] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Verify features work - https://phabricator.wikimedia.org/T90124#1093424 (10Manybubbles) [20:40:06] * legoktm has no idea [20:40:26] csteipp-ish: Well, either update the doc. to reality or the reality to the docs, I don't mind either way [20:40:37] Probably updating the doc. is more realistic [20:41:14] Let's update the docs for now, and update the process soon. I think the only issue is the move to meta.. [20:41:31] yeah, stewards would want to do it on meta [20:41:51] Also they'd need an easy how to, because htey probably don't know what oauth is or how it works [20:42:04] s/how to/intro/ [20:42:18] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Operational issues - https://phabricator.wikimedia.org/T90103#1093434 (10Manybubbles) [20:42:19] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Plan for no downtime upgrade - https://phabricator.wikimedia.org/T90445#1093431 (10Manybubbles) 5Open>3Resolved a:3Manybubbles Resolved. We'll want to perform rolling restarts in beta while we're performing updates to validate it.... [20:42:22] I have no strong opinion [20:42:26] strong [20:42:35] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Verify features work - https://phabricator.wikimedia.org/T90124#1093436 (10Manybubbles) 5Open>3Resolved [20:42:36] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Confirm selection of BlazeGraph for wikidata query - https://phabricator.wikimedia.org/T90101#1093438 (10Manybubbles) [20:42:39] * Keegan hopes legoktm got his reply [20:43:53] Updated the doc [20:47:40] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Wikidata Query: Experiment with RDF exports - https://phabricator.wikimedia.org/T91691#1093446 (10Manybubbles) 3NEW a:3Smalyshev [20:47:47] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Wikidata Query: Experiment with RDF exports - https://phabricator.wikimedia.org/T91691#1093455 (10Manybubbles) p:5Triage>3High [20:56:19] ori: jupyter.wmflabs.org [20:56:21] :D [20:56:45] I’ll switch it to Wikitech OAuth in the next few days or something [21:27:54] 6MediaWiki-Core-Team, 10MediaWiki-Authentication-and-authorization: Document state machine for authentication flow - https://phabricator.wikimedia.org/T91698#1093611 (10bd808) 3NEW a:3bd808 [21:29:19] 6MediaWiki-Core-Team, 10MediaWiki-Authentication-and-authorization: Start gerrit patch to outline public interfaces of authentication system - https://phabricator.wikimedia.org/T91699#1093621 (10bd808) 3NEW a:3Anomie [21:30:31] manybubbles: I tweaked https://office.wikimedia.org/wiki/Job_descriptions/Software_Engineer_(Search) Tomasz is going to take a look by EOD today [21:30:47] thanks [21:31:36] thank you! It looks a lot better than before you took a buzzsaw to the old one. [21:39:29] ^d: looks like I'm going to do lunch on monday with a newbie. and we'll do conference practice around that. I'll find you when I arrive in the office? [21:39:46] <^d> that works [21:42:04] sweet. we'll have time to catch up during the conference I imagine. Looks like they are having two parties in three days.... [21:44:50] anomie: is there an API action to create a new account? [21:44:56] bd808: action=createaccount [21:45:15] bd808: What legoktm said [21:45:32] thanks [21:45:33] https://www.mediawiki.org/w/api.php?recursivesubmodules=1 is the best [21:46:25] there's a few screens of information there for sure [21:46:37] * bd808 was being lazy [21:48:56] 6MediaWiki-Core-Team, 10Analytics, 10MediaWiki-Authentication-and-authorization: Create dashboard to track key authentication metrics before, during and after AuthManager rollout - https://phabricator.wikimedia.org/T91701#1093688 (10bd808) 3NEW [21:49:28] csteipp, anomie: ^ add metrics to the list there if there are some that are missing [21:50:01] Maybe we need some on captcha success/fail rates too? [21:57:17] 6MediaWiki-Core-Team, 10Analytics, 10MediaWiki-Authentication-and-authorization: Create dashboard to track key authentication metrics before, during and after AuthManager rollout - https://phabricator.wikimedia.org/T91701#1093732 (10csteipp) Adding captchas would be good: * Captcha presentation * Captcha sol... [22:04:41] 6MediaWiki-Core-Team, 10Analytics, 10VisualEditor, 10VisualEditor-Performance, and 3 others: Apply Schema:Edit instrumentation to WikiEditor - https://phabricator.wikimedia.org/T88027#1093918 (10Krenair) >>! In T88027#1045283, @gerritbot wrote: > Change 191221 had a related patch set uploaded (by Alex Monk... [22:06:30] 6MediaWiki-Core-Team, 10SUL-Finalization, 10Wikimedia-Site-requests: Run sendConfirmAndMigrateEmail.php for all unconfirmed emails on all wikis - https://phabricator.wikimedia.org/T73241#1093921 (10Keegan) This has been done. @Legoktm wanted to double check before closing. [22:06:46] 6MediaWiki-Core-Team, 10SUL-Finalization: Update CentralAuthUser::chooseHomeWiki() - https://phabricator.wikimedia.org/T91703#1093922 (10Legoktm) 3NEW a:3Legoktm [22:07:08] 6MediaWiki-Core-Team, 10SUL-Finalization, 10Wikimedia-Site-requests: Run sendConfirmAndMigrateEmail.php for all unconfirmed emails on all wikis - https://phabricator.wikimedia.org/T73241#1093931 (10Legoktm) 5Open>3Resolved [22:10:05] 6MediaWiki-Core-Team, 10MediaWiki-Configuration, 5Patch-For-Review: doMaintenance.php creates ConfigFactory::getDefaultInstance() before Setup.php is run - https://phabricator.wikimedia.org/T90680#1093947 (10Legoktm) a:3Legoktm [22:15:10] 6MediaWiki-Core-Team, 10SUL-Finalization, 5Patch-For-Review: Update CentralAuthUser::chooseHomeWiki() - https://phabricator.wikimedia.org/T91703#1093958 (10Legoktm) [22:19:20] 6MediaWiki-Core-Team, 10MediaWiki-extensions-ConfirmEdit-(CAPTCHA-extension), 5Patch-For-Review, 7Performance: Improve performance of Captcha extension on edit forms - https://phabricator.wikimedia.org/T88661#1093962 (10Anomie) 5Open>3Resolved a:3Anomie Should be deployed in 1.25wmf21. [22:22:06] anomie: the merging of that will make the 150% VE target harder ;) [22:22:44] aspiecat: The merging of what? [22:23:12] the change for T88661 above [22:23:52] What's a "150% VE target"? [22:25:39] csteipp: could you review https://gerrit.wikimedia.org/r/#/c/194709/ ? it implements https://office.wikimedia.org/wiki/User:Keegan_%28WMF%29/SUL_messaging/Schema_announcement [22:28:33] anomie: did you see the metric meeting today? [22:29:00] aspiecat: I missed it [22:30:36] * anomie looks at slides [22:31:33] Ah. A goal of only being 50% slower than wikitext. [22:34:28] The problem with being metric driven is that metrics are often easy to game [22:34:50] bd808: usleep() to the rescue :) [22:34:56] heh [22:35:03] I've seen that IRL [22:36:02] And the classic collusion between QA and Eng to find and fix zillions of bugs but planting them purposefully [22:36:50] and burn down / burn up chart gaming. Lots of that at $DAYJOB-1 [22:38:44] It is extremely important to know where you are and where you're going, but when things escalate to tying salary to knobs that are easily changed ethics are sometimes the loser [22:44:44] legoktm: Isn't Keegan's list supposed to be an ordered list? [22:45:22] As is, you chose the winner by edit counts if they happen to be in the list [22:45:35] Or maybe I misunderstand the requirement [22:46:33] legoktm: Oh wait, nevermind. [22:46:37] You have it right [22:48:38] :) [22:54:06] legoktm: I'm fixing my centralauth install, then I'll merge if testing works [22:54:18] ok :) [22:54:55] csteipp: meaning you are running `vagrant destroy -f && vagrant provision" I hope [22:55:36] bd808: nah, I'm actually using a web browser at the same time, so vagrant crashes everything... need to upgrade to 1.7 so I can try out lxc. [22:55:51] yes! do that [22:56:15] It feels fast on the labs host I've been testing it on [22:56:38] * bd808 is a stinking mac user so he can't run it directly on his laptop [22:56:57] What's the page on fixing up skins for a git repo? I apparently haven't used my centralauth wikis in a while... [22:58:26] I expected something on https://www.mediawiki.org/wiki/Manual:Upgrading but don't see it [22:58:39] hmm [22:58:57] csteipp: you mean your custom skins? https://www.mediawiki.org/wiki/Manual:Skin_autodiscovery probably [22:59:32] I bet he means he doesn't have vector [22:59:35] csteipp: if you mean default skins, then just update MediaWiki, and it will give you an error message with some instructions after you refresh [22:59:58] clone the mediawiki/skins/Vector repository into skins/ in mediawiki/core [22:59:59] MatmaRex: just default skins [23:00:21] then add a require_once() for it in LocalSettings [23:00:24] just like extensions [23:04:40] <^demon|busy> who needs a skin anyway? [23:07:28] yes, you can run mediawiki without any skins. [23:07:47] bd808: http://tinyurl.com/dayjob-1 [23:08:00] looks like https://en.wikipedia.org/?useskin=fallback . almost usable. [23:08:19] ori: :) [23:08:47] * ori tries to find correlates [23:08:55] I slipped a few times and said the one true name too [23:09:52] Which is funny because when I do I actually say the brand name of the product that I worked on rather than the name of the entity that provided my pay checks [23:10:54] what was it? [23:10:58] Kount [23:11:07] Dracula [23:11:17] *Drakula [23:11:21] which is a brand/subsidiary of Keynetics [23:11:43] and a sibling of ClickBank [23:12:00] no idea why they didn't slip more K's in there [23:13:22] hmm, so my gerrit login keeps dropping and the CI tests all fail on hhvm [23:13:24] While I was at Keynetics I also worked on CredMe and ... some DNS based content filtering product that I can't remember the name of [23:13:27] must be a bad day [23:13:55] <^demon|busy> MatmaRex: "Whoops! The default skin for your wiki, defined in $wgDefaultSkin as vector, is not available." [23:13:57] <^demon|busy> It is! I'm just using fallback! [23:14:25] patches welcome [23:14:36] but multiplying that messages doesn't sound useful [23:14:45] maybe we should disallow useskin=fallback [23:14:50] but no one cared so far [23:15:08] * ^demon|busy sets his skin to fallback in the db [23:15:32] ?useskin=fallback&i-know-but-i-like-it=true [23:15:55] when you scroll down it's not too terrible...I still remember the early 1990s [23:16:37] * aspiecat still remembers the sound of that modem by heart [23:18:01] bd808: On a slightly related note, is there a way to get rid of [memcache] and [resourceloader] messages from my default log? [23:18:30] set them to false in $wgDebugLogGroups [23:18:41] or send them somewhere else [23:18:51] * ^demon|busy looks around for an AaronS [23:19:29] any [...] logs are from wfDebugLog() and only going into the default log if there is no specific config for them [23:52:59] csteipp: no +2? :) [23:54:11] bd808: I guess l10nupdate is still not working? I'll just backport the localisation update commits to get new messages... [23:55:25] It should be working when scap is run manually. The cdbs are still not being shipped to the wikis each night for sure. [23:56:05] But I think there was a scap this morning so if you aren't seeing strings then there must be some problem [23:56:50] If this is for new strings that would land today then yeah you should backport and scap [23:57:14] https://github.com/wikimedia/mediawiki-extensions-WikimediaMessages/commit/2fe5bcdde43d6352b31e3c1883f8f905007552cb showed up 2 hours ago [23:58:31] ok. So there are 3 things that could be done I think: [23:58:35] backport and scap [23:58:49] wait for l10nupdate to run and scap [23:59:00] force an l10nupdate run and scap [23:59:21] I'll go with #2