[11:02:37] tgr: T257879 all sounds good to me (your last comment) - about the backporting thing, just to double check, you mean that it'd allow future cherry picks to selectively use new syntax. I didn't think about that. I was thinking not about the syntax we'd be allowed to introduce in cherry picks but rather the general cherrypick-ability of patches. as I understand it most patches would likely not apply cleanly given REL1_35 is going out [11:02:37] without any 7.3 syntax. and in mastr we'd likely adopt all that as soon as WMF upgrades, right? [11:02:38] T257879: Drop PHP 7.2 support in MediaWiki 1.35 - https://phabricator.wikimedia.org/T257879 [11:03:32] I'm not concerned about cherry picks either way. But if you had something in mind to make that even easier, then perhaps I didn't understand fully. Let me know :) [11:07:01] Krinkle: yeah, if someone goes berserk and rewrites everything to 7.3 that will break cherry-picks just the same. But e.g. backporting a change that creates new classes will be a bit easier. I agree this is not a big deal either way, especially with the syntax differences not being that large. [11:08:29] Also, some extensions don't follow the branch compability model and want their master to be compatible with older core versions, so this would allow them to adopt 7.3 features sooner. Although I don't know if the authors would care or would rather prefer to forego them to be compatible as far back as possible. [18:53:05] legoktm: hello! [20:09:21] legoktm: hm.. wondering if there is or should be a connection between lib-cookiecutter-library and lib-up? [20:09:40] maybe we don't need cookiecutter-library anymore? [20:09:45] https://phabricator.wikimedia.org/diffusion/MCCL/repository/master/ [20:10:07] (also https://github.com/wikimedia/generator-wikimedia-php-library [20:57:40] Krinkle: Thanks! [20:58:20] Amir1: could use your review on HtmlFormatter as well if you have a minute, will do a release next in that case. [20:59:53] Krinkle: sure, where is the patch? [21:06:22] in general, I'd like to move them back in core and have a mono-repo (liberalized) similar to symfony, wikibase is doing something similar [21:09:46] https://gerrit.wikimedia.org/r/c/HtmlFormatter/+/616299/1 [21:25:26] Hi there, seems like I ran into trouble updating mediawiki from 1.27.7 to 1.31.7. After installing new mediawiki version and updating php to 7.3 I tried running "php update.php". On first try it went for a while, then complaining about "error: relation 'profiling' does not exist". When giving it another try it now breaks early wit "error: relation 'change_tag_ct_id_seq' already exists". How would I proceed to get that databse upgraded? Its [21:25:28] postgres 11 BTW [21:34:13] Why are you only upgading to 1.31.7? [21:34:23] Also, postgres support is somewhat iffy, unfortunately [21:40:33] Reedy: I have been using Postgres with Mediawiki in multiple installations for maybe 15 years now. Chose Postgres back then due to my personal preference. Never had any issues... so far ;) [21:41:11] Reedy: I just found https://phabricator.wikimedia.org/rMW4fbaa0b822033c8d85ccf07ecaa411cebf224b4f which tells me you might be right ;) No patch for Postgres updater :/ [21:42:56] But that's 2012... [21:43:08] 1.27 is from 2016 [22:04:00] Problem seems to be a little different. Those failing db upgrades date back to VERY early mediawiki versions. Seems that update.php doesn't respect $wgDBmwschema (="mediawiki") and thats the reason why it wont find matching tables [22:34:31] Reedy: IMHO postgres 11 breaks mediawiki postgres updater [22:34:54] It wouldn't surprise me [22:36:19] MW CI runs with 9.6.17 [22:54:12] Reedy: its getting more interesting, rolled back to my postgres 9.6 db, same effect o_O