[01:09:28] legoktm: Because upstream (me) landed that commit after I updated mediawiki, before tagging the actual release. I had a draft of that release in Gerrit based on upstream master for a while before that. [01:09:44] Also, I somewhat disagree with that code being in migrate because jquery-core has no intention of ever removing those shorthands. [01:10:08] So I don't want to emit deprecation logs across the wire for them and ruin our ability to lower the graphite graphs for js deprecation usage [01:10:14] ... which is blocking the removal of jquery-migrate [01:10:27] Stuff that doesn't rbeak when you remove jquery-migrate shouldn't be in jquery-migrate [01:10:37] but it's turning more into a jquery-dev mode thing. [01:10:42] This being the starting point of that. [01:11:10] I didn't land the commit that added the shorthands, but I did tag the release. [01:14:38] Krinkle: so uh, what would you recommend doing? just considering its removal to be a MediaWiki patch? [01:17:23] legoktm: I'm not sure yet. Do you think we can reproduce the other two changes without a patch? [01:18:20] We can just edit the committed jquery-migrate.js file and whenever someone tries to update it, they just have to reapply it manually I guess [01:19:19] legoktm: As it stands, adding those shorthands would make the deprecation warnigns useless, so then we might as well turn it off entirely. [01:19:40] The track-logging of deprecation warnings that is. [01:20:05] Maybe there's a way to filter them, but we'd have to perform more patches to instrument it to pass a key of sorts to the log method [01:20:21] E.g. migrateWarn('event-short-hands', ...); [01:20:27] and then filter the call of mw.track based on that.. [01:22:01] Maybe an upstream patch to let us do that and we can drop the hacks in the next upgrade? :) [01:22:14] Given how many files we exclude, and that we still need to manually list each file in Resources.php, I'm starting to think this use of 'npm' might be more maintainable if we do it in the form of a shell script that uses curl to fetch from cloud.npmjs.org/-/pgk/v1.123.tar, and then explicltly unpack and mv the files we want. That saves the indirection of using the 'npm' binary as requirement and gitignore. [01:22:33] It also makes explicit that we don't support dependencies right now, unless known, listed, pinned and deduplicated ahead of time. [01:23:46] That way, if something is missing, it's an explicit 404 (or shell error). It looks like me very clearly that npm isn't meant to be used this way given we're basically using it as a proxy for distributing a single file, which is what https://cdnjs.com/ is for instead. If we want that, we should use https://cdnjs.com/ instead of npmjs. [01:23:57] That's for non-modular distribution of single files. [01:24:38] Something like https://github.com/openstack-infra/zuul/blob/master/etc/status/fetch-dependencies.sh [01:24:56] :D (but without random third-party 'master' urls) [01:27:55] I think that's just jquery, in moment for example, we're using most of the files [01:37:45] Also I like using npm in the sense that it should be straightforward to use for most people, and should make a future effort to use npm better/more easier (theoretically) [01:48:54] https://github.com/harvesthq/chosen/blob/master/package.json#L78 <-- this is really nice. Every project should do this [01:50:11] https://github.com/harvesthq/chosen/issues/2945 and someone already filed the ticket I was going to :D [02:06:18] legoktm: Agreed, yeah, "files" is pretty good. It still won't solve it entirely because there is a logical conflict here between modular code vs single file distro. And typically only the modular files belong on npm (which we actually support in RL!), but for registration simplicity, it seems we prefer the single file distro, which only a small subset of packages publish on npm for reasons like we're using them, which I'm less sure [02:06:19] about. [02:06:39] So if we go the npm route, we should probably encourage use of "files" and registering them each in "scripts" for RL [02:06:51] vs encouraging addition of a single file where missing. [02:07:15] But yeah, "files" is a good reason to keep npm. We could also in the future potentially link that up to ResourceLoader [02:07:30] as a way of discovering which files should exist in resources/ for the module without dir globbing. [02:11:02] (hm.. that "files" is supposed to be in the top level, not in _extra, not sure what's going on there) [02:11:08] Cool, npm and php-dev are finally installable in Debian unstable at the same time again. [02:23:04] https://secure.php.net/manual/en/language.constants.php#114762 [02:23:08] Oh the manual comments, always a gift [02:35:46] anomie: damn, good job :D https://doc.wikimedia.org/cover-extensions/TemplateStyles/ [02:36:47] legoktm: Hmm. Looks like I have some cleanup for tomorrow. [02:37:18] :) [03:00:58] legoktm: Ok, I didn't wait. https://gerrit.wikimedia.org/r/408481 [03:01:05] haha [03:02:17] anomie: is there no way to fake the "don't allow " legoktm: Sigh. Now you challenged me. Time to hack crap up. [03:11:05] heh :) [03:11:19] I'm gonna have dinner now, I'll be back in a bit [03:50:03] 1/21 [06:06:08] legoktm: Hehe, calls for http://wiki.c2.com/?DontDoThat [14:52:33] Longer comments are re-enabled on test wikis. So far nothing's breaking like last time. [20:31:08] Warning: Division by zero in /srv/mediawiki/php-1.31.0-wmf.20/vendor/wikimedia/running-stat/src/Wikimedia/PSquare.php on line 159 (and 158( [20:52:41] Also: Notice: Undefined index: 1 in /srv/mediawiki/php-1.31.0-wmf.20/vendor/wikimedia/running-stat/src/Wikimedia/PSquare.php on line 151 [20:53:00] Catchable fatal error: Argument 2 passed to MWHttpRequest::factory() must be an instance of array, null given in /srv/mediawiki/php-1.31.0-wmf.20/extensions/ExtensionDistributor/includes/providers/GerritExtDistProvider.php on line 42 [20:53:05] legoktm: Last one us for you ^ :( [20:57:24] o.O [21:06:33] no_justification: https://gerrit.wikimedia.org/r/408619 [21:08:40] Walking dog I'll look when I'm back at my laptop [23:58:54] legoktm: Backporting now