[03:46:00] TimStarling: it was recommended that you are the right person to look at this: https://phabricator.wikimedia.org/T187147 I don't think it is blocking the PHP7 deploy but it is something that neeeds a long term fix [03:46:21] Daniel mentioned it yesterday [03:46:55] if it's not urgent then I guess we can schedule it for after the current two projects? [03:51:01] okay, I'll confirm the urgency of it [06:42:15] TimStarling: re: ExtensionRegistry cache keys/REST router, that seems reasonable as long as you're OK with plenty of false positive cache invalidations. [06:42:55] the WIP patch just has md5(json_encode($routes)) [06:43:17] I guess I'll benchmark it, but it will be a while before we have hundreds of routes [09:36:34] <_joe_> hi, anyone with decent wikitext chops around? [09:37:59] <_joe_> I'm trying to understand what precisely https://fr.wikipedia.org/wiki/Mod%C3%A8le:Tableau_rang_commune_de_France does, context is https://phabricator.wikimedia.org/T216664 [09:41:17] <_joe_> AIUI, it's exanding another template, D-Nbcom, which loads Données_Nbcom, which has a lot of data in it [13:48:29] _joe_, it is a giant switch statement (4500 cases). [13:48:42] <_joe_> ok, so as I imagined [13:48:49] sorry .. https://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Donn%C3%A9es_Nbcom2006&action=edit is the switch. [13:48:55] <_joe_> subbu: I think we need to fix that template [13:48:57] <_joe_> yes [13:49:02] <_joe_> there are 4 of them [13:49:13] <_joe_> used AIUI in a lot of french localities pages [13:49:24] <_joe_> that needs to be fixed I guess [13:49:48] <_joe_> but we got a repro case for the parser perf regression on php7 at least [13:52:37] there are 8 of those giant-switch templates referenced in that Tableau_rang_commune_de_France template. [13:53:13] they need a hash table .. not sure why it isn't in lua. [13:53:37] i suppose because no one has converted it. [13:54:31] I guess, it's worked fine for 6 years... [13:54:40] Technical expertise varies between communities, people have varied interests [13:55:21] in general, what i've noticed is that many of the large pathological pages on wikipedias are basically wikipages used as a hash table or database table. [13:55:32] Reedy, makes sense. [13:55:54] That ones a relatively simple case... You could basically convert it with a regex find and replace [13:56:37] anyway, i think if someone converted that to lua (i haven't written lua templates and hooked them up with invoke wrappers to do it myself readily without going in and learning a bunch of stuff), this would probably get fixed. [13:57:59] Modèle:Données_Nbcom2006 (and 1968, 1975, 1982, 1990, 1999, 2009, 2013) [13:59:13] You can basically developer the module in whatever the module namespace is, test it outside, and then just replace the Modele pages to be invoking the scribunto module [13:59:23] s/developer/develop/ [14:00:01] the lua module is just return the value if the key exists in the hashmap... else return some default [14:00:17] I'd almost suggest it was "easy" worthy for someone with a bit of lua knowledge [14:00:37] * subbu greps lua hashtable :) [14:00:45] *facepalm* .. googles [14:00:47] not greps [14:01:47] https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#table [14:01:58] https://www.lua.org/pil/11.5.html [14:12:16] subbu: https://phabricator.wikimedia.org/P8512 [14:12:21] That would be a very naieve attempt at doing the lua [14:13:39] I created https://www.mediawiki.org/w/index.php?title=User:SSastry_(WMF)/Module:Lua_Test&action=edit .. but I wonder, whether I can invoke lua modules from anything other than the module namespace ... unlike templates. [14:14:57] subbu: you need to use the scribunto wrapper stsuff [14:15:21] local p = {} [14:15:21] function p.hello( frame ) [14:15:21] return "Hello, world!" [14:15:21] end [14:15:21] return p [14:15:37] ok. [14:15:43] see my example :) [14:15:46] /paste [14:16:07] https://www.mediawiki.org/wiki/Module:FormatText [14:16:47] I dunno if {{#invoke}} can be used to point at non Module NS [14:17:09] probably not. [14:18:14] yeah, it doesn't [14:18:55] Might need the right content model [14:19:36] but is there a user sandbox space for trying out modules .. anyway, will have to read up and learn more before trying this ... but, hungry ... breakfast time. as i said, quicker for someone who has already written this stuff before. [14:21:23] even so, i guess on frwiki, it will need someone with the right perms to probably edit and replace those templates .. maybe worth pinging Benoit? [14:22:07] subbu|away: Just stick it in the right ns? :P [14:22:07] https://www.mediawiki.org/wiki/Module:Nbcom2006 [14:22:40] <_joe_> I guess if we manage to fix that [14:22:48] And as such https://www.mediawiki.org/wiki/User:Reedy/Lua [14:22:50] <_joe_> we can just ping hte main author of that template [14:23:03] <_joe_> and ask them to change it by pointing them to the task [14:23:09] ["A011"] = 107, [14:23:53] Don't even need to do that [14:24:04] They pages aren't protected [14:24:08] I can do it with my volunteer account [14:26:55] https://fr.wikipedia.org/wiki/Module:Donn%C3%A9es_Nbcom2006 [14:27:03] That's the scribunto module transferred [14:28:53] Yup, it works [14:31:50] https://fr.wikipedia.org/wiki/Utilisateur:Reedy/Brouillon [14:32:12] using https://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Donn%C3%A9es_Nbcom2006/Test&action=edit [14:32:19] which uses https://fr.wikipedia.org/wiki/Module:Donn%C3%A9es_Nbcom2006 [14:34:48] https://fr.wikipedia.org/w/index.php?title=Saint-Girons_(Ari%C3%A8ge)&diff=156875793&oldid=156712123 doesn't fail now [14:37:51] <_joe_> it fails under php7 [14:38:21] <_joe_> I guess till hitting the memory limit [14:38:26] <_joe_> *still [14:38:42] stupid global preferences [14:38:43] <_joe_> why though [14:39:19] <_joe_> Reedy: https://fr.wikipedia.org/wiki/Utilisateur:GLavagetto_(WMF)/test_france is a minimal repro case [14:40:11] _joe_: it calls Nbcom numerous times [14:40:14] So it calls those other ones [14:40:18] So as subbu said above... [14:40:25] <_joe_> oh right you just modified one [14:40:28] [14:57:59] Modèle:Données_Nbcom2006 (and 1968, 1975, 1982, 1990, 1999, 2009, 2013) [14:40:36] Yeah, give me a bit to modify the rest and we'll see how things look :) [14:40:54] <_joe_> I don't think the old ones are there, 1968 to 1999 is just one table IIRC [14:43:03] https://fr.wikipedia.org/wiki/Mod%C3%A8le:Donn%C3%A9es_Rang1968 [14:43:08] These are the same too [14:58:00] _joe_: the 1968 one of that template... has 38000 lines [14:59:30] https://fr.wikipedia.org/w/index.php?title=Module:Donn%C3%A9es_Rang1968&action=history [14:59:33] feck [15:06:41] Reedy, well, i always hesitate a bit modifying templates with my staff account ... it took me a while ot work up the "boldness" when we were replacing Tidy and then I updated a ton of those on lots of wikis ... but, i've been out of practice for many months now :) [15:06:54] I'm doing it with my volunteer accoutn :) [15:07:06] i should probably create one for myself at some point. [15:08:07] <_joe_> well not if you're working for the wmf while changing a template [15:08:24] <_joe_> as in [15:08:34] <_joe_> it shouldn't be needed :) [15:09:32] If you use your staff account, it's to fix things for security/perf reasons that you couldn't edit otherwise [15:09:54] <_joe_> subbu: I think this is clearly a pathological (ab)use of wikitext, we could reflect that on the ticket [15:10:21] Magic [15:10:22] https://fr.wikipedia.org/wiki/Utilisateur:GLavagetto_(WMF)/test_france works [15:10:34] And it's quick! [15:10:42] <_joe_> wtf [15:10:43] <_joe_> ahahaha [15:10:52] <_joe_> it loaded in like 10 ms [15:11:02] _joe_, indeed. [15:11:03] <_joe_> I'm very happy [15:11:05] That'll do [15:11:08] <_joe_> can we close that ticket? [15:11:17] <_joe_> thanks Reedy [15:11:30] I bet we'll find worse shit than this :) [15:11:31] _joe_, maybe one of you should document the fixes there first. :) [15:11:52] "don't do stupid stuff with wikitext" [15:12:05] <_joe_> Reedy: at every transition we find weird shit [15:12:05] I'd be interested to see how much memory it takes now to process [15:12:10] but, it is nevertheless worth exploring why php7 uses 1 GB vs hhvm using 200MB on those templates. [15:12:12] <_joe_> Reedy: let's see [15:12:18] <_joe_> subbu: without doubt [15:12:22] subbu: php sucks, duh :) [15:12:28] lol [15:12:31] <_joe_> let's create a separate task maybe? [15:12:34] yes. [15:12:37] <_joe_> that's not a blocker to the migration [15:12:46] just nerd sniping [15:13:49] all languages have their wart .. but i am glad we are porting parsoid to php7.2 not php5. [15:13:53] *warts [15:13:54] heh [15:14:02] I guess a handful of them didn't need converting (because of the amount of data) [15:14:11] i am really happy about the types and strict typing option. [15:14:12] But might aswell do them for consistency if nothing else [15:14:48] <_joe_> subbu: well hack had them as well [15:15:01] <_joe_> we could've gone the hack way [15:15:03] <_joe_> :D [15:15:24] i am not going to wade into these debates. :) [15:16:01] I think that's trolling, not debating ;) [15:16:13] :) [15:16:31] i cannot keep track of who supports what languages for what reasons. [15:17:48] * Reedy turns on php7 as a global preference [15:30:24] https://fr.wikipedia.org/wiki/Module:Donn%C3%A9es_Rang1968 [15:30:34] Why is there no syntax highlighting? [15:30:35] Size of the page? [15:30:45] I guess so, because https://fr.wikipedia.org/wiki/Module:Donn%C3%A9es_Nbcom1982 has it [15:42:17] <_joe_> subbu: oh yes that was trolling clearly [15:42:27] <_joe_> Reedy: how can I turn that on as a global pref? [15:42:34] <_joe_> I thought beta features couldn't [15:42:50] https://fr.wikipedia.org/wiki/Sp%C3%A9cial:GlobalPreferences#mw-prefsection-betafeatures [15:43:02] Tick the most left box next to PHP7, then save [15:45:07] <_joe_> noice [16:04:07] Wondering if someone could review https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Tabs/+/509435/ please? [18:50:52] Reedy: You feeling keen to finish https://github.com/cssjanus/php-cssjanus/pull/19 per K.rinkle's last review? It's nominally the last PHP7 blocker (until we find the next one). No pressure. ;-) [18:51:05] I didn't write the patch :P [18:51:14] I just posted it to github :P [18:52:09] And which damn-fool made the mistake of posting it on GitHub and becoming responsible? ;-) [18:53:51] https://github.com/cssjanus/php-cssjanus/blob/master/test/suites/CSSJanusTest.php#L62 [18:54:17] So it actually needs to go in there, presumably? [18:54:18] https://github.com/cssjanus/cssjanus/blob/master/test/data.json [18:56:22] Also, the test case... [18:56:23] https://raw.githubusercontent.com/PrestaShop/PrestaShop/452ca0ff1d314b7c2e3f3824fb0a32cfea8a7d8b/admin-dev/themes/new-theme/public/theme.css [18:56:42] It's hardly a narrowed test case [18:56:45] Yeah, the request is for https://github.com/cssjanus/cssjanus/ to be updated (and a version released) with the new issues. [18:56:58] I generally shy away from cssjanus mess nowadays. [18:57:27] I mean, we could technically use https://github.com/cssjanus/php-cssjanus/pull/13#issuecomment-355574605 [18:57:36] And check it doesn't just fail [18:57:36] :P [18:58:09] I think we'd want the performance to be checked as well, but yes. [18:58:23] Honestly, this isn't a feature change, it's an "unbreak on an environment" change. [18:58:58] So really this should be a change to the Travis environment file to confirm it works on php7, which fails on master and works with your/anomie's changes, or whatever. [19:00:00] https://github.com/cssjanus/php-cssjanus/runs/61733181 [19:00:42] https://github.com/cssjanus/php-cssjanus/pull/19/checks?check_run_id=61841916 [19:04:17] it sounds like all Krinkle is asking for is test cases that exhibit the problem and fail without this patch, and pass with it [19:04:47] and https://github.com/cssjanus/php-cssjanus/pull/13#issuecomment-355574605 is basically that, though paring it down to a minimum repro case would be good [19:04:54] https://phabricator.wikimedia.org/T215746#4944830 [19:04:55] Yes, and that those patches are in the JS-land test files. [19:05:09] >That 300k line at the end of the test CSS file is apparently too much for it to deal with, with that pattern fragment as written. [19:05:28] I mean, 300k is better than a whole file.. but still [19:06:16] Ideally we'd have one repo with the different language versions. The magic of hindsight. [19:11:45] https://github.com/reedy/php-cssjanus/commit/9df2d31e80b5a9873011589e8cd8d889f287926a [19:12:10] Let's see what travis says ;P [19:14:11] I guess the params need swapping for expected/actual [19:14:17] i'm paring it down [19:14:28] ori: Is today 20% time? :) [19:15:44] it's "procrastinate desperately, doing absolutely anything except what I'm supposed to be doing" [19:17:01] https://superuser.com/a/216476 is useful for bisecting the css [19:23:39] getting closer: https://dpaste.de/sXkr/raw [19:23:58] though the test would be brittle if it hinges on the phpjit stack limit being set to a particular value [19:25:00] ori: That 2KiB string breaks cssjanus? Neat simplified test. [19:25:34] silly phpcs failure [19:26:19] but https://travis-ci.com/cssjanus/php-cssjanus/jobs/199314927 [19:26:23] it fails on php 7 :P [19:30:03] Reedy: It also fails on HHVM… https://travis-ci.com/cssjanus/php-cssjanus/builds/111406413 [19:30:38] James_F: [20:25:34] silly phpcs failure [19:30:48] Oh, Kk. [19:30:51] :) [19:34:51] $css = str_repeat(".x{right:0}", 249); [19:34:55] ^ that breaks [19:36:26] That's a pretty narrow case :) [19:42:01] if you ini_set('pcre.backtrack_limit', 1000000) it should be consistent [19:44:24] consistent? [19:44:37] I mean, it will reliable fail [19:44:56] you don't want the test case to pass just because someone has 'pcre.backtrack_limit' jacked up to a higher value [19:45:11] 1000000 is the default [19:45:24] makes more sense with context ;) [19:45:26] *reliably fail [19:45:31] Want to make a PR with the test? [19:45:52] I dunno if it makes more sense to have a separate PR, or just put it ontop of brad's patch fixing it [19:46:10] on top of brad's patch probably [19:47:07] If only we did this in gerrit, we could put the test underneath the patch to prove directly that it fixes it, then squash them. [19:47:10] Or does it make more sense underneath? [19:47:24] if you rebase and stikc it first... [19:47:34] travis will fail the first commit, pass the second [19:47:36] If it's a separate PR it's unlandable (as by definition it's a breaking test). :-) [19:47:51] It should be one commit, I think [19:48:45] and since that's the case it's probably best if you do it, Reedy, since I don't think I'd be able to update your PR, and Krinkle would probably want to preserve the discussion [19:49:06] I think maintainers can modify PRs, but not "random" people [19:50:15] Krinkle: How do you want it? :P [19:50:41] ori: Could still do a separate PR (and close it) to prove the tests fail without the fix [19:50:43] I'm upstreaming the test case into the main CSS Janus repo now. [19:50:58] And watch everything break [19:51:03] Gives a bit of an audit trail [19:51:57] "some men just want to watch the world burn" [19:52:26] It's a good job burning stuff doesn't cause global warming [19:52:35] /github.com/cssjanus/cssjanus/pull/72 [19:53:33] See if it passes there :D [19:54:04] It does. [19:55:21] Fun [19:55:30] So that needs merging... A release tagging (1.3.2?) [19:55:46] Then https://github.com/cssjanus/php-cssjanus/issues/20 doing [19:55:51] Both for tests and any other changes needed.. [19:57:03] Yes. [19:57:20] And then we'll upgrade MW to use cssjanus 1.3.2. [20:00:17] Oh, and whether we're going to make the changes to the canonical repo too... https://github.com/cssjanus/php-cssjanus/pull/19#issuecomment-462479819 [20:01:51] Do we need test cases for those ones too? The long content test case from ori doesn't break in the JS repo, so clearly that code isn't triggered there… [20:04:25] James_F: Interestingly, some are already upstream [20:04:25] https://github.com/cssjanus/cssjanus/blob/master/src/cssjanus.js#L101 [20:05:30] Oooh, so some of this is 1.3.x+ compat? [20:07:52] James_F: I think the upstream changes are just s/?/+/ [20:07:54] I'll make a patch [20:08:20] Reedy: Put it on top of https://github.com/cssjanus/php-cssjanus/pull/23 ? [20:08:28] nooo [20:08:34] a patch to the canonical [20:08:36] not to php- [20:08:44] Oh, for 1.3.2? Sure. [20:10:24] https://github.com/cssjanus/cssjanus/pull/73 [20:11:46] Your 1.3.1 bump fails :( [20:12:09] Yes, and it should. [20:12:26] I did a bump for tests without a bump for logic. If it didn't fail there'd be problems.:-) [20:15:19] So this change to the regex, it is essentially an optimisation (liberally speaking, from horribly inefficient to decent), or would it also change behaviour on a theoretical system with infinite resources? [20:15:41] I keep looking for a test case that would break the JS version without the updated reggex [20:15:48] but that's not possible, is it? [20:16:43] looking at the change, seems like it should be possible to observe the differnence, but it might be a case that is invalid anyway. [20:17:04] does the ecmascript spec specify backtrack limits? [20:18:26] incidentally I think there's also a case to be made for having simple wrapper functions for preg_replace and preg_replace_callback that checks preg_last_error() and emits a warning/error. [20:18:36] *that check [20:20:41] I don't know, might make the code too accessible, and deal with pull requests. [20:20:45] (Yes, good idea!) [20:21:34] I think I can break the lookAheadNotClosingParenPattern pattern. [20:21:40] not sure about the first one yet. [20:24:30] https://travis-ci.com/cssjanus/cssjanus/jobs/199327021 wheee apparent invalid regex [20:28:17] Right. That makes sense actually [20:28:24] the embedded regex part already ends in * [20:28:30] so it is currently *? [20:28:55] I don't know what we want there exactly, functionality wise, but maybe it needs +?, but *+ seems odd indeed. [20:29:56] my brain is hurting [20:33:59] refreshing my brain on greedy/lazy, it seems like lazy would perform better and avoid certain bugs functionality-wise as well (e.g. not match a huge unexpectedly to skip over). So removing the ? there seems undesirable. What am I missing? [20:34:50] anomie: Remember your fix(es) to the cssjanus regexes? :) [20:35:33] Reedy: I was reading the backscroll, so I re-read T215746#4944830 a little bit ago. [20:35:34] T215746: Checkup on cssjanus PHP 7 compat - https://phabricator.wikimedia.org/T215746 [20:44:35] I haven't found a case that only fails with or without it. There are cases where it'll behave differently indeed. But it's limited to how much it will redundantly match negatively for cases where it's meant to do nothing anyway. And given that each flip rule does its own matching from start to end, making it skip over something in one pattern doesn't affect other rules. [20:46:48] Krinkle: "*+" is a possessive quantifier, which after a quick web search I don't think JavaScript has. If you have a "greedy" regex fragment like "foo*", it'll start by matching "foooooo", then backtrack to "fooooo", "foooo", "fooo", "foo", and "fo" (to match following fragments) before giving up. A "lazy" fragment like "foo*?" will try those possibilities in the reverse order, "fo" first and "foooooo" last. A "possessive" fragment like "foo*+" [20:46:49] will try "foooooo" and then fail if the rest of the regex doesn't match, no backtracking. (But note it could still be retried if earlier fragments backtrack, and/or with a different starting 'f' in the string). [20:46:49] Krinkle: In T215746#4944830 I analyze the regular expressions involved, and as far as I can tell the three fragments involved can only ever match one way. Two are basically "a run of certain non-')' characters (or escapes) followed by a ')'" and the other is "a run of certain non-'{' characters (or quoted substrings) followed by a '{'". [20:46:50] T215746: Checkup on cssjanus PHP 7 compat - https://phabricator.wikimedia.org/T215746 [20:48:28] Okay, wasn't able to find what "*+" is ("star plus regex" didn't help), but that makes sense. [20:48:36] and yeah, JS doesn't have that, at least not in ES5. [20:49:47] In PCRE you can also do more complicated possessive groupings with a "(?>" group, like "(?>foo*)", BTW. [20:50:46] right. [20:51:38] so what is the reason that the lazy one is allowing itself to grow its match that far? On its own I'd expect the non-greedy to not be as.. greedy. Maybe it's the pattern after that, which matches \s* in a greedy way. [20:55:28] The problem, IIRC, is just that it has to backtrack through thousands of possibilities and runs out some internal stack limit. If it's a no-match return, lazy and greedy would both fail. The possessive quantifier fixes it by not doing the backtracking, it either matches the whole of what the fragment greedily matches or it doesn't match without trying the thousands of shorter matches in between. [21:00:18] And part of the problem is complexity of the quantified fragment. For "foo*bar" it's just 'o's and probably doesn't need a stack (and, maybe, it's so simple that it even recognizes that there's no point in backtracking the star in "o*b"). But the actual regexes here are complicated groups with alternation inside. [21:02:54] Hm.. okay, so I think I'm starting to understand why it would bother matching this. [21:03:15] I guess the idea is that this sequence of ".x{left:0" could itself be a url. [21:03:48] e.g. url(somethingsomething-left}.x{left:0} [21:04:44] yeah, it's allowing curly braces in the url literal. [21:04:55] Although they're only valid in a quoted url, that can also be the case. [21:05:40] but for that the pattern could be much smarter, rather than trying to do both. E.g. without quote: stop much much earlier, with quote, only look for non-escaped end quote. [21:07:00] Anyway, I guess for now we can diverge the two a little bit. I'll keep a FIXME in the code to summarise some of this. [21:24:25] anomie: does this sound correct? https://github.com/cssjanus/cssjanus/pull/74/files [21:24:55] https://github.com/cssjanus/cssjanus/pull/74/files?diff=unified * [21:45:48] Krinkle: No, most of that is wrong. The non-greedy and greedy versions shouldn't matter because the patterns are run-of-not-X followed by X. That's why using the possessive quantifier is safe to do. [22:02:00] Krinkle: Did you want to land anything else as part of 1.3.2 beyond that? [22:39:32] anomie: Hm.. greedy would mean it could match "non-X lots of stuff including X, lots of stuff, X" right? [22:39:42] I documented that unrelated to the backtrack issue [22:40:05] for functional correctness [22:40:10] or could that not happen? [22:41:29] James_F: I'd like the documentation of the backtrack issue and the test case for it to be in the same release :) [22:41:56] Krinkle: Yes, that's why I'm not making a release. :-) [22:42:04] Anyway, if I can't figure this out, I can simplify with a url and figure out later. [22:42:38] Let's do that. This is blocking a quarterly goal. [23:21:29] James_F: The logged-in sidebar at https://travis-ci.com/cssjanus/php-cssjanus/builds/111427570 is quite nice [23:21:35] especially the "Running (..)" tab [23:21:43] some PHP 7.2 fixes in that composer/semver update too [23:21:45] showing the CI queue and all for that org [23:22:23] We have some PHP 7.1+ deprecation warnings as well, but nothing that affects the runtime. [23:22:42] May still want to patch as well to avoid warnings in prod, or have to supress in ResourceLoader. [23:23:33] Krinkle: Yes, the sidebar is nice. They had it before but only (?) on the "root" page for the org, I think. [23:23:43] yeah, indeed. [23:23:50] and that one didn't show breakdown of individual builds only the jobs. [23:23:55] or hte otherway around [23:24:26] Reedy: Yeah, will C+2 the /vendor patch when it passes CI. [23:24:35] I spotted an HHVM failure a minute ago, but I cancelled that build as I noticed a rebase mistake. Let's hope it won't appear again [23:24:36] James_F: Can't, codesniffer conflicts [23:24:46] Eurgh. [23:24:49] making a patch [23:24:55] so will have to wait for the next release of that [23:25:47] Oh, yes, the famous "bug" people complain about in npm that's magically absent in composer so you have conflicting requirements. Fun. :-) [23:28:11] Reedy: You doing a MWCS release? [23:28:21] Maybe [23:28:28] Just noticed spdx-licenses is out of date too [23:29:18] You write it, I'll merge it. [23:29:48] Doing ;) [23:30:04] Will need to bump in mw core too eventually [23:31:28] Version 26 or 25.1? [23:33:26] https://gerrit.wikimedia.org/r/509543 [23:36:59] 26 I guess [23:38:49] Yeah, 26, it's breaking for people who using the wrong kind of licence tag for SPDX. [23:39:03] https://github.com/wikimedia/mediawiki-tools-codesniffer/blob/master/HISTORY.md [23:39:09] What's the trick for generating the log entries? [23:39:12] git log oneline thing? [23:39:17] Also MW has a way to go for getting PHP8. [23:39:50] Reedy: git log --format='* %s (%aN)' --no-merges --topo-order [23:40:24] Oh, hah, use utils/gen-changelog.sh Reedy [23:40:47] apparently I'm blind [23:41:13] That... sort order is weird [23:41:14] * Enable sniff to check for newlines between functions (Umherirrender) [23:41:14] * Update composer/semver from 1.4.2 to 1.5.0 (Reedy) [23:41:14] * Update composer/spdx-licenses from 1.4.0 to 1.5.1 (Reedy) [23:41:14] * Upgrade PHP_CodeSniffer to 3.4.2 (Umherirrender) [23:41:24] alpha/ [23:41:27] meh [23:41:28] --topo-order is "order it was merged into the repo". [23:41:50] Default order is significantly worse for repos written by more than 1 human. [23:42:12] (For Wikimedia-style code management. GitHub branches fare a lot better.) [23:42:15] gen-changelog.sh [23:42:16] git log --format='* %s (%aN)' --no-merges --reverse $(git describe --abbrev=0)...HEAD | sort [23:42:21] | sort ? srsly? [23:42:29] Oh, right, there's a patch removing that. [23:42:45] lol [23:42:46] I said to use --topo-order instead, it's languishing in C+1 land. [23:42:55] https://gerrit.wikimedia.org/r/c/mediawiki/tools/codesniffer/+/488227 [23:46:07] https://gerrit.wikimedia.org/r/#/c/mediawiki/tools/codesniffer/+/509544/ and then can tag it [23:46:53] ta [23:47:13] I guess https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/509539 etc. will have to upgrade both together? [23:47:49] James_F: https://github.com/cssjanus/php-cssjanus/pull/27 [23:47:51] Can do spdx, codesniffer and semver in one patch in core, yeah [23:48:22] Krinkle: Not dropping 5.x entirely? [23:48:25] I'll sort the lot [23:49:08] James_F: Yeah, wanted to keep it compat with 5.6 for now for old MW branches if we need to for some reason (without branching cssjanus), and because it's only been dropped relatively recently. [23:49:17] * James_F sighs. [23:49:20] But next next release we can probably go for PHP 7.2+ [23:49:31] dropping those that were discontinued in 2019. [23:49:35] I'm going around trying to drop PHP7.1 and below, and you're trying to support 5.6. :-P [23:49:59] cssjanus likes to be different [23:50:26] thx [23:50:31] release coming up [23:50:39] 1.3.0 (I know, it's weird) [23:55:43] https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/509540/ [23:55:49] Let's see what phpcs goes lolno to [23:57:58] https://github.com/cssjanus/php-cssjanus/releases/tag/v1.3.0