[00:12:45] I'm still bitter over [] [00:13:28] So btw, looking at the big board, we've got 5 blockers, and 9 extension-bundling related requests. I think that's good enough for next rc. [00:18:53] no_justification: expect a ton of backports as people will commit a lot of PHP7 code next week [00:19:39] Backports just for the sake of using PHP7isms seem kinda silly [00:20:15] And if that starts next week, a tag before everyone breaks crap seems like a good idea [00:20:49] PHP7 backports should only be bugfixes. Not cleaning up techdebt [00:21:01] ^^ [00:21:10] ie stuff that doesn't work properly, warnings/errors/etc on PHP 7+ [00:21:19] Though, I'm pretty sure we've fixed most of those up already [00:26:24] legoktm: Do we have a test that makes sure all files with classes are in the autoloader, even via PSR-4? Eg. no extra files in the same directories in another namespace and/or other scenarios which we previously covered with the flatt autoloader file and test case that generates it in phpunit to compare. [00:28:21] I don't think so [00:28:32] We can write one though [00:28:51] It'd be good to have tests fail if a PSR-4 clean up commit breaks something [00:29:22] E.g. if one of the namespaced classes is actually in a different directory , and you remove it from the autoload.php file, the test should fail given the file wouldn't be discovered by the PSR-4 map etc. [00:30:24] What do we currently do that makes it not fail? It used to be that the autoload test required each class to be in a file and that pair to be in autoload.php. I guess something somewhere makes it tolerate psr-4 entries. [00:30:53] AutoloadGenerator excludes the PSR-4 directories [00:31:42] I regenerated autoload.php, and made sure it only removed the classes in the namespace when reviewing the diffs [00:33:16] But I'll write an integration/structure test for this [00:33:18] Pushed a signed rc.1 [00:33:21] I'll see about a tar [00:34:02] :D [00:48:39] Wait, why don't I clone everything in make-release with a depth of 1? [00:48:46] We don't need the damn history textbook [00:52:05] bytes are cheap! :P [00:52:26] Derp, depth=1 prevents the tags from being fetched :\ [00:52:46] Won’t git protocole v2 fix that so it dosent download all the refs? [00:53:24] It's not about refs, it's history depth [00:54:01] https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html?m=1 [00:55:06] -b with tags should work [00:55:10] But it's being dumb :p [00:56:06] A-ha [00:56:07] Can't do it [00:56:27] https://stackoverflow.com/questions/8932389/git-shallow-clone-to-specific-tag [00:56:41] tldr: --depth implies --single-branch which means --branch won't work [00:59:08] Ah, you have to use --no-single-branch with it [01:12:37] Ok, so the way to kinda do what I want is.... [01:12:38] `git clone --depth=1 --no-tags ` [01:12:38] `git fetch --depth=1 origin ` [01:12:46] Then `git checkout ` [01:12:56] Trick is in --depth=1 on the subsequent fetch [01:13:07] Otherwise, it'll fetch that refspec with full history!! [01:13:43] 18mb vs 117.09mb *before* ctrl+c [01:36:41] Krinkle: welp, I wrote the test and found an issue in one of the previous directories I just converted [02:01:20] Krinkle: https://gerrit.wikimedia.org/r/#/c/435078/ [10:28:28] class_alias( DBQueryError::class, 'DBQueryError' ); [10:28:32] Are they.. Not the same? [10:28:51] Oh. NS [10:56:30] $options = [[]]; [10:56:31] lol php [11:02:14] legoktm: Do we have it documented how long class_alias calls should be around for? [11:33:10] Reedy: that should folow the deprecation policy, i suppose [11:33:19] sadface [11:33:20] but I don't think it's mentioned explicitly. may be worth a note on the talk page [11:38:04] https://www.mediawiki.org/wiki/Topic:Udshhbynqffmjtc1 [11:38:16] I guess we should add @since/@deprecated tags too etc [17:10:50] Reedy: we should definitely start adding @deprecated calls to class_aliases [17:11:11] Maybe we can have the autoloader emit a warning if they get used for hard deprecation? [18:41:02] legoktm: I filed a TODO task for this :) [18:41:35] :D [18:43:24] https://phabricator.wikimedia.org/T195576 [18:47:57] Unfortunately, IDEs seem to ignore the @deprecated on the class alias calls (maybe it's worth a request to JetBrains to fix it) [18:48:09] But if we could encourage people to move away from them... [19:18:02] Most of us don't use IDEs anyway… ;-) [19:25:53] Well, that's just silly [19:25:55] And then you miss stuff [19:26:26] But stuff like @deprecated is only any use if you have something that takes note and tells you what is alreay deprecated, or if you're adding an extra call to something already deprecated [19:33:03] Or you manually search for @deprecated calls and try to kill the code off. [19:33:09] (Hi.) [20:26:05] or use the findDeprecated.php script... [20:42:36] Far too helpful, can't be using that. [21:04:49] Reedy: https://gerrit.wikimedia.org/r/#/c/435209/ is easy :) [21:25:41] ty :) [21:50:07] legoktm: Want a WTF? [21:50:08] https://phabricator.wikimedia.org/T195632 [21:50:50] Reedy: I already patched TemplateSandbox a few hours ago? [21:51:02] https://gerrit.wikimedia.org/r/#/c/435198/ [21:51:34] Not running master then :P [21:52:04] I don't understand https://gerrit.wikimedia.org/r/#/c/435290/ [21:52:10] There's already a use statement at the top of the file [21:54:49] Does a use statement actually affect a comment type hint? [21:55:14] yes [22:12:59] https://youtrack.jetbrains.net/issue/WI-42283