[00:11:04] Amir1: https://phabricator.wikimedia.org/T219342#5060747 Looks like something might be broken there for the ORES js [06:52:17] Krinkle: oh thanks. I know what's wrong. I don't have a good solution for it though. I'll check [19:53:54] anomie: I noticed that $secureCookie is unused in CentralAuthLogin (initially added and used in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralAuth/+/72657/6/specials/SpecialCentralLogin.php). What should happen with that variable now? Looks like its usage was removed in b1908c5ada1e21. [19:55:06] I'd imagine a setForceHTTPS call() perhaps [20:02:54] AaronSchulz: Looks like it was previously used for the call to setCookie(), which now happens inside CentralAuthSessionProvider instead. So probably it's no longer needed in SpecialCentralLogin. [20:38:49] I have a question on Strip marker https://www.mediawiki.org/wiki/Strip_marker : They continuously cause confusion, e.g., T219443 are there any plans from the core team to implement an alternative to the strip marker concept. For me, it seems that strip markers are something, that is not a common design pattern in 2019. [20:38:50] T219443: Math rendering on Wikiversity produces UNIQ--postMath-00000001-QINU - https://phabricator.wikimedia.org/T219443 [20:48:39] physikerwelt: i believe parsoid doesn't have them :) [21:55:15] do we have a policy about removing un-used code? Does it have to be soft deprecated/hard deprecated or can it be straight up removed from the code base? [22:05:06] dmaza: I don't think the deprecation policy touches that aspect: https://www.mediawiki.org/wiki/Deprecation_policy [22:05:22] dmaza: https://www.mediawiki.org/wiki/Deprecation_policy -- theoretically at least any PHP class/method/interface that is public and has been in a tarball release previously should go through the deprecation cycle [22:05:23] Maybe I'm wrong but I don't see it there. If the code is unused, you can just remove it [22:05:47] I agree with bd808 [22:06:01] but there is a bit at the end about a way to remove via public announcement if deprecation is somehow too hard/impossible [22:06:15] There are some edge cases for code that was introduced but never ever used. Maybe that is what dmaza is asking, I don't know [22:11:33] If it was in a public release, it needs to follow the policy. There is no mention of being used, because we're not the only consumer of MW :) [22:12:12] Yes, I remember this is how my own case was handled [22:12:15] The quickest normal way is to add wfDeprecated and remove entirely after the 1.34 branch cut . [22:12:20] dmaza: ^ [22:12:50] An even quicker way is to notify wikitech-l and remove directly. But unless keeping the old code is a problem, seems fine to just leave around for a few months. [22:30:28] xSavitar, Krinkle, bd808: Thank you. I'm specifically talking about https://gerrit.wikimedia.org/r/c/mediawiki/core/+/499594 [22:30:59] it felt unnecesary to soft-deprecate, then hard-deprecate and then remove the method. [22:33:08] this is a very simple deprecation so I'll suggest Krinkle approach of wfDeprecate and remove on 1.34 [22:34:05] "public function isValid()" -- seems like that qualifies for deprecation. Its been in the codebase since 2008-09-21 [22:34:17] dmaza: Yeah, going straight for hard deprecation is fine. The policy allows that. We encourage it for popular code or code of which you recently found at least 1 usage, so that we can allow some time to find them and make sure. This because deprecation warnings will fail PHPUnit tests, and may block the train. [22:34:30] encourage it = soft deprecation. [22:35:05] perfect.. thank you guys [22:35:09] More specifically, we require soft deprecation for Wikimedia-deployed code and encourage it for other widely-used code. [22:36:09] 👍 [23:10:03] James_F: 23:06:37 The module 'wikibase.mediainfo.filePageDisplay' must not have target 'mobile' because its dependency 'mediawiki.action.edit.editWarning' does not have it [23:10:10] any ideas what's up there? [23:10:16] https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/41980/console [23:10:33] looks like mediainfo is fail-y... how did it get merged?