[00:26:38] bd808: oooh, you going to be here tomorrow? [00:26:40] or next week? [00:26:52] so many vehicles [00:33:54] https://codeascraft.com/2015/04/06/experimenting-with-hhvm-at-etsy/ [02:06:40] YuviPanda: next week. 14th-16th [04:20:58] bd808: yt? [04:21:40] sup? [04:22:43] so your e-mail to engineering sounds great. there is exactly one thing i can think of that would break as a result of the format change (apart from some aussie awk scripts) and that's mwerrors.py [04:23:09] https://github.com/wikimedia/operations-puppet/blob/production/modules/mediawiki/files/monitoring/mwerrors.py [04:23:29] hmm.. ok [04:23:30] is there any chance you could generate 5-10 lines of sample data for exception.log and fatal.log? [04:23:50] incidentally all that that script does is create a graph of the rate of errors in prod [04:24:01] so we could just kill it if you think logstash will be up for it soon [04:24:10] (it's in the topic of #wikimedia-operations) [04:24:31] yeah. I know the graph from that data. [04:24:48] it should be a pretty easy change [04:24:58] i also know the story of slow parse private wiki [04:25:13] I can probably figure out how the script would need to be updated. Shouldn't be too hard [04:25:33] there were plans to make the slow parse log public so interested users could see which templates need optimizing etc [04:25:39] ah [04:25:43] so to make it public the private wiki log would need to be scrubbed [04:25:50] *nod* [04:25:53] anyways no one looks at the slow parse log for private or public wikis [04:25:58] and no one ever will, in the case of private wikis [04:26:31] There are a bunch of logs that I sort of doubt are actually used [04:26:33] so the best solution there would be to just not log on private wikis [04:28:21] What I'd really like to do for the format is make all the logs json :) [04:28:49] And of course provide a "normalize" script to un-json things when desired [04:29:22] It would make a lot of things easier to do with the logs really [04:30:23] I'll try to imagine how to disable a log channel per-wiki [05:33:19] 6MediaWiki-Core-Team, 10MediaWiki-extensions-SecurePoll: SecurePoll should evaluate voting requirements globally for global elections - https://phabricator.wikimedia.org/T91432#1184735 (10tstarling) What exactly are the qualification rules for the Board election? As far as I know, the SecurePoll min-edits prop... [05:39:22] 6MediaWiki-Core-Team, 10MediaWiki-extensions-SecurePoll: SecurePoll should evaluate voting requirements globally for global elections - https://phabricator.wikimedia.org/T91432#1184741 (10Jalexander) >>! In T91432#1184735, @tstarling wrote: > What exactly are the qualification rules for the Board election? As... [05:52:46] bd808: I wish Flow boards had a like feature so I could like your comment in that discussion. [05:52:56] bd808: Or a LOL button. [06:11:53] 6MediaWiki-Core-Team, 10MediaWiki-extensions-SecurePoll: SecurePoll should evaluate voting requirements globally for global elections - https://phabricator.wikimedia.org/T91432#1184758 (10tstarling) >>! In T91432#1184741, @Jalexander wrote: > The final qualifications for this years election aren't 100% set yet... [06:12:33] 6MediaWiki-Core-Team, 10MediaWiki-extensions-SecurePoll: SecurePoll should evaluate voting requirements globally for global elections - https://phabricator.wikimedia.org/T91432#1184760 (10tstarling) p:5High>3Low [07:26:29] 6MediaWiki-Core-Team, 15User-Bd808-Test: Setup communication infrastructure for new Availability team - https://phabricator.wikimedia.org/T93941#1184824 (10Gilles) [07:26:31] 6MediaWiki-Core-Team, 6Project-Creators, 15User-Bd808-Test: Create Availability-Team project - https://phabricator.wikimedia.org/T94490#1184821 (10Gilles) 5Open>3Resolved a:3Gilles #availability [13:54:38] 6MediaWiki-Core-Team, 10Wikimedia-General-or-Unknown, 5Patch-For-Review: Existed pages without ability to reach and obviously wrong namespace - https://phabricator.wikimedia.org/T87645#1185562 (10Aklapper) [14:59:48] bd808, Krenair: We have AdHocDebug.log now? Can I use it too, for T92046 debugging? [15:00:49] Sure I guess [15:00:54] it's getting a lot of traffic at the moment [15:41:10] any idea when will we package hhvm 3.6? [15:42:12] ask Giuseppe [15:42:49] _joe_? [15:43:19] <_joe_> Nikerabbit: when we have fixed Tim's output streaming patch [15:43:30] <_joe_> if Tim is able to do it this week [15:45:33] _joe_: nice [16:13:15] legoktm: I haven't forgotten about your vendor patch, but SWAT is dragging on and I don't want to possibly make it worse by making Jenkins angry. Hopefully I can get to it this afternoon [16:14:32] ok :) [16:15:08] 6MediaWiki-API-Team, 10MediaWiki-Configuration, 5Patch-For-Review: Support "ResourceModuleSkinStyles" in ExtensionProcessor - https://phabricator.wikimedia.org/T91566#1186287 (10Legoktm) 5Open>3Resolved [16:15:28] 6MediaWiki-API-Team, 10MediaWiki-Configuration, 10MediaWiki-Maintenance-scripts, 5MW-1.25-release, 5Patch-For-Review: Update mergeMessageFileList.php to support reading extension/skin.json files - https://phabricator.wikimedia.org/T94756#1186289 (10Legoktm) 5Open>3Resolved [16:28:44] 6MediaWiki-Core-Team, 10MediaWiki-General-or-Unknown, 5MW-1.25-release: Drop PHP 5.3 support - https://phabricator.wikimedia.org/T75901#1186403 (10hoo) [16:31:30] 6MediaWiki-Core-Team, 6Project-Creators, 15User-Bd808-Test: Create Search-Team project - https://phabricator.wikimedia.org/T94493#1186414 (10Aklapper) 5Open>3Resolved a:3Aklapper Requested project has been created: #Search-Team Currently nobody is a member or subscribed to this team, so please **encou... [16:31:34] 6MediaWiki-Core-Team, 15User-Bd808-Test: Setup communication infrastructure for new Search team - https://phabricator.wikimedia.org/T94488#1186417 (10Aklapper) [16:35:40] did ya'll see https://phabricator.wikimedia.org/T95282 ? :) [16:39:26] greg-g: something not marked with @group Database? [16:39:46] or maybe it is [16:40:40] <^d> aude: It's like the core db is getting added but the tables were never created. [16:40:51] 6MediaWiki-Core-Team, 6Project-Creators, 15User-Bd808-Test: Create Search-Team project - https://phabricator.wikimedia.org/T94493#1186452 (10bd808) >>! In T94493#1186414, @Aklapper wrote: > Requested project has been created: #Search-Team > > Currently nobody is a member or subscribed to this team, so pleas... [16:48:49] <^d> aude: BlockTest [16:49:02] <^d> I threw a var_dump( $this ); above the addCoreDB call [16:49:52] isn't that a broken test? [16:49:56] <^d> Nothing special about that, it's just the first test in includes/ before delving into subdirs [16:50:07] we shouldn't have such thing of course [16:50:16] <^d> @group Database [16:50:18] <^d> @group Blocking [16:50:35] ok, not marked broken [16:51:10] shoudn't it call parent::addDBData? [16:51:14] maybe? [16:51:50] nah, it's empty [16:52:35] <^d> Yeah [16:52:52] really no idea [16:53:04] maybe something with the phpunit version used? [16:53:13] since jenkins doesn't object apparently [16:54:59] <^d> Either that or php version [16:55:11] <^d> But less likely I think [16:55:26] 6MediaWiki-Core-Team, 6Project-Creators, 15User-Bd808-Test: Create Availability-Team project - https://phabricator.wikimedia.org/T94490#1186526 (10Aklapper) [16:55:27] * aude gets a bunch of failures, though usual things like incompatibility with extensions [16:55:32] 6MediaWiki-Core-Team, 6Project-Creators, 15User-Bd808-Test: Create Search-Team project - https://phabricator.wikimedia.org/T94493#1186527 (10Aklapper) [16:55:37] not good but not new [16:55:43] <^d> The hhvm failure is just odd, but I'm more inclined to blame HHVM than us there [16:56:56] <^d> Again, weird to have not seen in jenkins though [16:57:00] <^d> should be same version roughly [16:58:06] 16:02:40 PHPUnit 3.7.37 by Sebastian Bergmann. [16:58:12] vastly different [16:58:20] <^d> Yeah [16:58:29] vagrant probably gets the latest via composer [16:58:39] I tested it with 3.7.37 and it was still failing for me in vagrant [16:58:41] which we obviously can't do on jenkins [16:58:44] oh [17:00:42] it's any test that requires db apparently: http://fpaste.org/208072/26029142/raw/ [17:01:22] * aude reminds folks https://gerrit.wikimedia.org/r/#/c/201142/ is probably good to have [17:01:31] but doubt it's related [17:01:42] aha [17:01:43] https://github.com/wikimedia/mediawiki-vagrant/commit/4e06a30240dbd87c7ce6629768e16517fb4ab7ca [17:01:46] ^d: ^ [17:02:37] look suspect [17:02:49] jzerebecki is saying all his pages are gone from his wiki in vagrant [17:03:04] maybe related? [17:03:39] https://gerrit.wikimedia.org/r/#/c/202440/ [17:04:34] <^d> Testing [17:05:22] csteipp: were you reviewing https://gerrit.wikimedia.org/r/#/c/201144/ ? [17:05:49] <^d> legoktm: merged [17:06:13] legoktm: I was, just hadn't tested.... I can test after I get out of this meeting [17:06:20] ok [17:07:36] 6MediaWiki-API-Team, 10MediaWiki-Unit-tests, 5MW-1.25-release, 5Patch-For-Review: Unit tests do not run on vagrant - https://phabricator.wikimedia.org/T95282#1185465 (10Legoktm) [17:14:04] aude: thx. that was exactly what caused my problem [17:14:39] :/ [17:16:52] jzerebecki: so is https://gerrit.wikimedia.org/r/202443 going to break it again? :/ [17:17:50] legoktm: yes [17:18:17] bd808: what would it take to spin http://sulfinalization.wmflabs.org/wiki/Main_Page back up? [17:18:25] <^d> Not sure it's resolved. [17:18:33] <^d> legoktm: There's a second bug here still [17:18:59] Keegan: It probably just needs an edit revert? [17:19:09] I'm in a meeting and can't look right now [17:19:15] ^d: what's the second one? [17:19:22] bd808: You're right. [17:19:30] If only I knew about these wiki things [17:19:37] they are hard [17:19:44] <^d> legoktm: I edited the paste, there's a failure before the failure from when I tried with hhvm [17:20:18] <^d> Fatal error: Class SomeJob contains abstract method (run) and must therefore be declared abstract or implement the remaining methods in /vagrant/mediawiki/vendor/phpunit/phpunit-mock-objects/src/Framework/MockObject/Generator.php(301) : eval()'d code on line 1 [17:21:50] ah [17:22:17] that only occurs with latest phpunit, 3.7.x doesn't have that issue [17:22:25] 6MediaWiki-API-Team, 10MediaWiki-Unit-tests, 5MW-1.25-release, 5Patch-For-Review: Unit tests do not run on vagrant - https://phabricator.wikimedia.org/T95282#1186629 (10Legoktm) 5Resolved>3Open [17:25:29] 6MediaWiki-API-Team, 10MediaWiki-Unit-tests, 5MW-1.25-release, 5Patch-For-Review: Unit tests do not run on vagrant - https://phabricator.wikimedia.org/T95282#1186644 (10Legoktm) a:5Legoktm>3None [17:52:42] bd808: do you think you you going to be able to extract yourself from the current meeting to get to the api mtg in 8 minutes? [17:53:09] Well when we lose the room I guess [17:56:32] meeple27: I think I'll be just barely late; my commute is pretty short :) [17:59:47] 6MediaWiki-API-Team, 10MediaWiki-API, 6WMF-Legal, 7Documentation, 5Patch-For-Review: Special:ApiHelp should include licensing information - https://phabricator.wikimedia.org/T93994#1152116 (10Anomie) [17:59:58] 6MediaWiki-API-Team, 10MediaWiki-API, 6WMF-Legal, 7Documentation, 5Patch-For-Review: Special:ApiHelp should include licensing information - https://phabricator.wikimedia.org/T93994#1186937 (10Anomie) a:3Anomie [18:10:31] <^d> bd808: I can't seem to run puppet from within my vagrant when ssh'ing in. `vagrant provision` works just fine. [18:10:56] <^d> sshing in and doing `puppet agent -tv` blows up with failed to resolve cert error [18:11:24] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: OAuth: Authorisation should not fail because you don't have an account on central wiki - https://phabricator.wikimedia.org/T74469#1186958 (10Legoktm) >>! In T74469#1175226, @Tgr wrote: > How much of the current logic is going to be discarded after the SUL fina... [18:11:35] ^d: yeah. that's expected [18:11:43] we are agentless in the VM [18:11:48] <^d> mmk [18:11:54] <^d> habit more than anything :) [18:12:00] vagrant provision is how you run puppet [18:12:41] anomie: anything else on https://gerrit.wikimedia.org/r/#/c/197978/ ? [18:14:10] <^d> Ok, so master's in pretty good shape actually. I only have one failure (glibc thing, long since known) [18:14:20] <^d> Can't test on hhvm right now, but that sounds like a phpunit version bug [18:14:50] burritocat: In a meeting, will look after [18:18:01] 6MediaWiki-API-Team, 10MediaWiki-extensions-CentralAuth, 10MediaWiki-extensions-OAuth: OAuth: authorization fails if the user never visited a foreign wiki - https://phabricator.wikimedia.org/T94885#1186980 (10Legoktm) >>! In T94885#1177066, @Tgr wrote: > * Lightweight: do account autocreation right after reg... [18:20:45] 6MediaWiki-API-Team, 10MediaWiki-Unit-tests, 5MW-1.25-release, 5Patch-For-Review: Unit tests do not run on vagrant - https://phabricator.wikimedia.org/T95282#1186994 (10demon) p:5Unbreak!>3Normal [19:08:43] 6MediaWiki-Core-Team: Memory stash BagOStuff wrapper that relays all writes - https://phabricator.wikimedia.org/T88342#1187070 (10aaron) 5Open>3declined [19:09:08] 6MediaWiki-Core-Team, 10RESTBase-Cassandra: Review restbase indexing proposal - https://phabricator.wikimedia.org/T729#1187071 (10aaron) 5Open>3Resolved [19:22:53] legoktm: I'm trying to test that patch, and hitting all sorts of issues with core (Title class being mucked with) [19:23:17] oh? [19:23:18] It looks safe.. do you need that merged asap? [19:23:52] csteipp: sooner rather than later...I was hoping to backport and deploy it either today or tomorrow [19:24:24] legoktm: So this isn't expected? [19:24:27] Exception encountered, of type "InvalidArgumentException" [19:24:27] [41e09102] /wiki_port83/en/index.php?title=Special:GlobalRenameRequest InvalidArgumentException from line 264 of /home/csteipp/UbuntuWWW/www/wiki_port83/en/includes/Title.php: Title::newFromText given something that isn't a string [19:24:27] Backtrace: [19:24:28] #0 /home/csteipp/UbuntuWWW/www/wiki_port83/en/includes/User.php(988): Title::newFromText(NULL) [19:24:29] #1 /home/csteipp/code/extensions/git2/extensions/CentralAuth/includes/GlobalRename/GlobalRenameRequest.php(416): User::getCanonicalName(NULL, string) [19:24:32] #2 /home/csteipp/code/extensions/git2/extensions/CentralAuth/includes/specials/SpecialGlobalRenameRequest.php(235): GlobalRenameRequest::isNameAvailable(NULL) [19:24:35] #3 [internal function]: SpecialGlobalRenameRequest->validateNewname(NULL, array, VFormHTMLForm) [19:24:47] err, definitely not. [19:25:24] I saw Krenair and Krinkle talking about Title::newFromText during swat... I assumed it had to do with that [19:26:28] It was due to different code. [19:26:39] But the same underlying issue. [19:26:46] csteipp: what did you enter for the new name? empty string? [19:26:56] Something is passing something other than a string to Title::newFromText [19:27:08] Yeah [19:27:16] This exception was added, but hasn't been deployed yet. [19:27:50] We realised a bunch of things rely on being able to pass null/false/other stuff (like NS_MAIN, looking at you csteipp) and not get an exception thrown [19:28:00] csteipp: Your original patch had the arguments the wrong way around (newFromText(NS_MAIN, "REDIR")) which creates [[Redir:0]] or [[0]], instead of [[REDIR]] [19:28:21] Krinkle: Which patch? [19:28:55] so it's mostly reverted in https://gerrit.wikimedia.org/r/#/c/202303/ with warnings that we might start throwing exceptions in the next release instead [19:29:03] 6MediaWiki-Core-Team: Support strategy #1 in PoolCounter classes - https://phabricator.wikimedia.org/T85026#1187157 (10aaron) 5Open>3declined Per https://gerrit.wikimedia.org/r/#/c/178903/ [19:29:15] csteipp, see https://gerrit.wikimedia.org/r/#/c/202299/ [19:30:43] Hmm.. I'm pretty sure I c&p'ed that code from somewhere else... [19:31:08] csteipp: https://gerrit.wikimedia.org/r/#/c/24026/ [19:32:01] csteipp: yeah, globalrenamerequest is totally broken on current master of core for me [19:32:08] csteipp, yeah you did [19:32:28] 6MediaWiki-Core-Team: Write design document for content/storage APIs - https://phabricator.wikimedia.org/T1124#1187167 (10aaron) What is the status of this? I'm not sure myself. [19:32:44] Krenair: is the title throwing exception patch deployed anywhere? [19:33:34] csteipp, I think you probably copied the Title::makeTitle call below and changed it to newFromText, changed 'AJAX' to 'REDIR', but didn't swap the param order [19:33:39] legoktm, no [19:33:44] This exception was added, but hasn't been deployed yet. [19:34:05] ok [19:34:28] I do suggest https://gerrit.wikimedia.org/r/#/c/202303/ is done before 1.26wmf1 branches though :) [19:34:33] and probably REL1_25 [19:34:58] +2'd [19:36:32] Krenair: Totally possible [19:36:53] legoktm, okay, just don't take this as an excuse not to fix centralauth eventually :p [19:38:24] 113 Warning: Invalid parameter for message "logentry-massmessage-failure": a:1:{i:0;s:13:"edit-conflict";} in /srv/mediawiki/php-1.25wmf23/includes/Message.php on line 1007 [19:38:48] we must send out a lot of messages with that to trigger so many edit conflicts so often :/ [19:39:55] <^d> That one annoys me [19:40:17] Krenair: I think it's people just viewing the borked log entries? [19:40:25] oh, yeah [19:45:17] * burritocat anomie https://gerrit.wikimedia.org/r/#/c/202470/ [19:46:06] csteipp: https://gerrit.wikimedia.org/r/202476 should fix the Title issues, and I rebased the logging patch on top of it [19:46:43] 6MediaWiki-Core-Team: Look into Maria 10 parallel-replication - https://phabricator.wikimedia.org/T85266#1187227 (10aaron) [19:48:15] 6MediaWiki-Core-Team, 6Availability-Team: Look into Maria 10 parallel-replication - https://phabricator.wikimedia.org/T85266#942877 (10aaron) [19:53:56] csteipp: thanks! [19:54:31] 6MediaWiki-API-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization, 7Easy, 5Patch-For-Review: Log promote to global renames in the global rename log - https://phabricator.wikimedia.org/T93235#1187271 (10Legoktm) 5Open>3Resolved [19:54:34] 6MediaWiki-API-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: Back-fill log entries from GlobalRenameQueue renames that promoted to a global account - https://phabricator.wikimedia.org/T93214#1187272 (10Legoktm) [20:04:41] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: OAuth: Authorisation should not fail because you don't have an account on central wiki - https://phabricator.wikimedia.org/T74469#1187305 (10Tgr) >>! In T74469#1175121, @Anomie wrote: >>>! In T74469#1175065, @Tgr wrote: >> One simple way to fix this would be t... [20:06:23] anomie: hey, do you think you could take a look at writing a script for https://phabricator.wikimedia.org/T93167 ? [20:07:27] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: OAuth: Authorisation should not fail because you don't have an account on central wiki - https://phabricator.wikimedia.org/T74469#1187308 (10Tgr) After SULF, do we need to support the old use cases forever since theoretically some third party could be using Ce... [20:08:00] legoktm: Script would do what, exactly? Delete those accounts? [20:08:43] anomie: yeah, CentralAuthUser::adminDelete( 'Empty account' ); or something [20:12:29] legoktm: What are these other comments on the task? Skip rows where some local account has an empty password, and run the auto-migrater after deleting? [20:21:25] anomie: so the script would have a dry run mode to list which global accounts are empty, and then it would have a --delete mode which would check if their are any unattached accounts with an empty user_password and skip if that's the case [20:21:58] anomie: and the auto migrate script is already written, someone (probably me) just needs to run it after we run the deletion script [20:23:44] legoktm: OTOH, if it's a simple function call to migrate the account right after deleting it, I may as well just do it. Or not? [20:26:56] anomie: yeah that should be fine, it'll just be a call to CentralAuthUser::storeAndMigrate( array(), false ) I think [20:33:23] legoktm: Skip all accounts with no password, or just the ones with no password and no email? [20:35:01] anomie: both probably [20:35:19] legoktm: So if it has an email set but empty password, delete? [20:36:44] I guess we'd want to check if they have a temporary password set in that case [20:37:10] but that should be fine since CA would never create an account with no password but put the emai [20:45:49] 6MediaWiki-API-Team, 10SUL-Finalization, 5Patch-For-Review: Prevent reserved users from being renamed - https://phabricator.wikimedia.org/T94804#1187469 (10Legoktm) p:5Triage>3Normal [20:56:12] 6MediaWiki-API-Team, 10SUL-Finalization, 5Patch-For-Review: Prevent reserved users from being renamed - https://phabricator.wikimedia.org/T94804#1187516 (10Legoktm) 5Open>3Resolved [20:57:13] ori: tgr and I want to record things into EventLogging from core. Is there a good way to do that today? Or is it a dumb idea in general? [20:57:49] The context is https://phabricator.wikimedia.org/T91701 [20:58:00] We want to instrument the auth funnel [20:58:32] legoktm: https://gerrit.wikimedia.org/r/202588 [20:58:51] bd808: Ok, so I assume you know about EventLogging::logEvent() in PHP and are asking specifically about Core [20:59:20] yeah. How should core use that? Or can it really? [20:59:48] anomie: woot, looking :D [21:00:06] legoktm: If it's not good, you'll have to wait for tomorrow ;) [21:00:09] typically WikimediaEvents just hooks into it? [21:00:32] bd808: You'll have to translate what I'm about to explain to the post-wfDebugLogGroup future, since I don't have that in my head yet [21:01:16] bd808: the way I would do this is to have a wfDebugLog( 'EventLogging', array( 'schema' => 'Foo', 'id' => 1234321, 'event' => array( ... ) ) [21:01:31] and make it possible to specify a class to handle a particular log bucket [21:01:44] then have a simple class in EventLogging handle that [21:01:46] using a logging bridge was tgr's instinct too. It sounded gross but ... [21:01:53] it's not gross at all [21:02:07] this is already the approach that we take in core javascript [21:02:24] we have mw.track( 'logBucket', data ); [21:02:31] s/gross/fragile/ [21:02:33] and mw.trackSubscribe( ... ) for registering consumers [21:02:39] I don't think it's fragile [21:02:53] I think core would generally benefit from having the same facility in PHP [21:02:57] wfTrack() [21:03:21] actually doesn't your logging work provide all the requisite infra for this? [21:03:26] *nod* some kind of client sounds good to me [21:03:38] it seems like a monolog eventlogging handler would be very little code [21:06:16] So if we did that, wfTrack() would delegate to the logging layer with a specific channel name and then we could document how to configure your log appenders to route the messages to EL [21:06:29] and of course do that for the WMF config [21:07:27] not sure what a log appender is [21:07:40] the thing that does work with a log event [21:07:46] Handler in monolog parlance [21:08:06] log4j calls them appenders [21:08:20] nod [21:12:18] tgr: Sounds like your instinct is better than mine on this :) [21:13:44] I like the idea of a wfTrack() function more than just hoping everyone uses the right debug logging channel name [21:14:22] Maybe something like 'TrackedEvent' for the channel name [21:14:29] no, I wouldn't do that [21:14:37] oh [21:14:45] that's just pretending to be loosely-coupled [21:15:00] the way i see this working is: [21:15:28] wfTrack( 'PageSave', array( 'id' => 123, 'anonymous' => false ), ... ); [21:15:39] no schema / id (contrary to what i suggested a few moments ago) [21:15:48] and then eventlogging would do something like [21:16:29] EventLogging:subscribe( 'PageSave', /* schema name and ID describing events */ ) [21:17:21] ah. So a mirror of the javascript setup really [21:18:20] I think so [21:18:42] what's the overall use-case? [21:19:40] Right now we want to instrument the authn funnel to track failed/successful logins and related funnel events [21:19:55] oh, that's a much easier problem to solve [21:19:55] but I could see this being used in a lot of places really [21:20:10] so, while i would be very happy to see what we just sketched out [21:20:15] you could get what you want with a lot less work [21:20:23] by just following the existing pattern for instrumenting things that happen on the server [21:20:46] namely: add a hook handler for the relevant hooks in WikimediaEvents [21:20:53] and have that call EventLogging::logEvent() [21:21:05] 6MediaWiki-API-Team, 10SUL-Finalization: Prevent reserved users from being renamed - https://phabricator.wikimedia.org/T94804#1187619 (10Ricordisamoa) [21:21:40] here's an example: https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/WikimediaEventsHooks.php#L50-104 [21:22:00] WikimediaEvents is the designated place for one-off, Wikimedia-specific instrumentation code like this [21:22:45] ok. That's what legoktm suggested I think [21:23:12] I like the wfTrack() thing but that is a bit of a diversion from the immediate goal [21:23:43] ori: You should make a phab task for your idea so it doesn't get lost. [21:23:44] could I ask you for a small favor then? Could you capture the wfTrack() bits from the conversation above in a phab task? [21:23:45] hah [21:23:53] samesies [21:23:53] jinx [21:23:55] meeple27: https://phabricator.wikimedia.org/T18691 I think [21:23:58] I can write it up [21:24:09] thanks! [21:24:23] I synced the privatewiki => false change btw [21:24:28] cool [21:25:59] legoktm: Was that in reponse to my micro-rant about linking to anchors? [21:26:06] meeple27: yes :P [21:26:31] 6MediaWiki-API-Team, 10Analytics, 10MediaWiki-Authentication-and-authorization: Create dashboard to track key authentication metrics before, during and after AuthManager rollout - https://phabricator.wikimedia.org/T91701#1187625 (10bd808) After a longish discussion on irc @ori suggested that the most direct... [21:27:19] legoktm: I might be misunderstanding, but I think that's different [21:27:31] meeple27: oh, what were you looking for then? [21:27:37] it seems like header/toc items are anchors that can be targeted [21:27:51] but i have this really long page which is likely to have 100 or so links to other stuff within this one page [21:28:17] sure would be nice to just say [#this] or [[#that]] instead of [[http://wikiname/page/subpage#this]] [21:28:33] [[#that]] should take you to the anchor "that" on the current page [21:28:55] oh, well that's what i wanted. i thought i tried it, but must have forgotten to sprinkle the magic dust [21:29:04] * meeple27 runs off to play with the new toy [21:29:15] :D [21:35:53] yay! thanks much! [21:36:34] hooray for microrants in comments on obscure phab tasks being noticed by random smart people [21:53:33] 6MediaWiki-Core-Team, 10MediaWiki-Page-editing, 7I18n, 5Patch-For-Review: Long edit comments get entirely removed instead of truncated (error in cutting multibyte chars?) - https://phabricator.wikimedia.org/T85700#1187702 (10Umherirrender) 5Open>3Resolved The problem with new too long comments is solve... [22:02:22] ori: Edit as appropriate -- https://phabricator.wikimedia.org/T95356 [22:02:47] bd808: oh, wow. I figured you'd just copy-paste a few lines from the buffer. Thanks a ton! [22:37:43] ori: https://gerrit.wikimedia.org/r/#/c/202601/ makes me sad [23:24:54] 6MediaWiki-Core-Team, 6Availability-Team: Look into Maria 10 parallel-replication - https://phabricator.wikimedia.org/T85266#1187960 (10aaron) Comparing https://tendril.wikimedia.org/host/view/db2016.codfw.wmnet/3306 and https://tendril.wikimedia.org/host/view/db1072.eqiad.wmnet/3306 suggest that the primary e... [23:47:07] legoktm: scap didn't break this time in beta cluster when classmap authoritative merged [23:47:24] * bd808 is going to send an email to eng-l