[01:16:26] <legoktm>	 no_justification: ack, the Linter one was my fault. But as Reedy said it should be gone with 12 everywhere?
[01:16:39] <no_justification>	 Yeah
[01:16:40] <no_justification>	 It went away
[01:16:53] <Reedy>	 Yay for less code to prevent bugs
[01:18:43] <legoktm>	 Amir1 was submitting patches to convert other extensions over to PSR-4 autoloading :)
[01:19:05] <Reedy>	 I thought you said Tim was scripting it?
[01:19:28] <legoktm>	 Tim is scripting the process of unnamespaced classes -> namespaced classes
[01:19:37] <Reedy>	 Ah
[01:19:41] <legoktm>	 but some of our extensions are already namespaced
[01:21:11] <legoktm>	 https://gerrit.wikimedia.org/r/#/q/topic:psr-4
[01:21:48] <Reedy>	 MaxSem did one earlier too i think
[01:22:35] <legoktm>	 https://gerrit.wikimedia.org/r/#/c/398320/
[01:22:44] <legoktm>	 fixed his topic :D
[01:22:56] <Reedy>	 heh
[01:35:26] <Reedy>	 01:27:26 [cf178215e7370999e4e22008] [no req]   MWException from line 167 of /home/jenkins/workspace/mwext-testextension-hhvm-jessie/src/includes/Hooks.php: Invalid callback AdvancedSearch\Hooks::onResourceLoaderTestModules in hooks for ResourceLoaderTestModules
[01:35:49] <Reedy>	 Oh
[01:35:50] <Reedy>	 File name
[01:50:30] <Reedy>	 legoktm: If we come up with a list of namespaced extensions... We might be able to GCI task this
[01:52:12] <legoktm>	 Reedy: grep for "namespace" ? we should also make sure the two PHPCS sniffs that enforce PSR-4 compliance are enabled in those repos
[01:52:29] <legoktm>	 one per class per file, and class name matches filename
[01:52:45] <Reedy>	 Hmm. Good idea
[01:55:10] <Reedy>	 lol, articleplaceholder
[01:55:11] <Reedy>	 	<rule ref="./vendor/wikibase/wikibase-codesniffer/Wikibase" />
[01:55:18] <legoktm>	 also https://phabricator.wikimedia.org/T178725 is the main reason why class name matches filename sniff is disabled
[01:56:21] <legoktm>	 yeah :(
[01:56:22] <legoktm>	 https://github.com/wmde/WikibaseCodeSniffer
[01:56:29] <legoktm>	 it's pretty far behind MW-CS
[01:56:45] <Reedy>	 		"mediawiki/mediawiki-codesniffer": "0.8.1"
[01:57:28] <legoktm>	 that was released in May
[01:58:26] <legoktm>	 but now that Wikidata is starting to follow the normal MW extension process I'm hoping that's one of the separate/duplicated things we can get rid of
[01:58:27] <legoktm>	 https://phabricator.wikimedia.org/T164653
[02:05:57] <Reedy>	 FundraisingEmailUnsubscribe/vendor/predis/predis/src/Protocol/Text/RequestSerializer.php:namespace Predis\Protocol\Text;
[02:06:00] <Reedy>	 All of the false positives
[02:06:14] <Reedy>	 LifeWebCore/resources/script/jquery-1.10.2.js:		event.namespace = namespaces.join(".");
[02:07:26] <legoktm>	 nothing like extensions bundling their own copies of jquery
[02:08:40] <Reedy>	 Why do we host this crap?
[02:09:16] <Reedy>	 It doesn't even use it
[15:55:05] <anomie>	 Reedy: When you updated T170971, did you mean to change the version to "1.30.0-wmf.12" or should that have been "1.31.0-wmf.12"?
[15:55:06] <stashbot>	 T170971:  iconv(): Detected an illegal character in CentralAuthUser - https://phabricator.wikimedia.org/T170971
[17:36:29] <joal>	 Hi AaronSchulz - milimetric told me you could the person to ask about data-question
[17:38:05] <joal>	 AaronSchulz: I'm investigating analytics numbers on user creation, and found that for Japanese wikipedia at end of 2016 (from July to December), there had been a lot of newusers logging actions with deleted-flag set to 5 (action and user deleted)
[17:40:01] <joal>	 AaronSchulz: I checked the user table for the users whose creation was the logging-lines in question, and they exist, with a lot of blank fields (no password, no real name, no email, and a lot of NULLs in other fields)
[17:40:43] <joal>	 I wondered if there is a convention about users being "deleted/inactive" if some fileds or so are not set
[17:40:47] <joal>	 AaronSchulz: --^
[17:40:59] <joal>	 AaronSchulz: Thanks in advance :)
[17:45:55] <AaronSchulz>	 You mean the password field is empty? I'm not sure that should happen ever.
[17:51:11] <no_justification>	 AaronSchulz: Some ancient bug maybe, but no modern reason yeah
[17:51:20] <no_justification>	 (that'd be nasttttyyyy if so)
[17:57:46] <AaronSchulz>	 Do they have any edits?
[18:00:41] <AaronSchulz>	 I'm not aware of some rule.
[18:03:57] * no_justification shrugs
[19:26:10] <joal>	 Sorry guys, I was away for diner
[19:26:50] <joal>	 AaronSchulz, no_justification: This data is not that old - 2016-07
[19:26:54] <joal>	 I can provide examples
[21:58:45] <legoktm>	 the password field should be empty for all post-SUL created users
[21:59:00] <legoktm>	 we don't store local password hashes anymore unless they're already there
[22:33:26] <tgr>	 real name we don't use at all
[22:33:54] <tgr>	 email shouldn't be empty though, CentralAuth updates it to the current email occassionally
[22:34:52] <tgr>	 FWIW revdeleting the log entry for user registration has no effect whatsoever on the user account itself