[00:33:56] <Krinkle>	 anomie: I believe https://gerrit.wikimedia.org/r/#/c/281238/ is redundant with your recent commits. Can you confirm?
[01:59:18] <anomie>	 Krinkle: It should use atomic sections with ATOMIC_CANCELABLE rather than SavepointPostgres, but the general idea is still something that should be done.
[13:34:14] <anomie>	 addshore, DanielK_WMDE_: Would any recent RevisionStore change result in undeletions converting null ar_len to 0 rev_len, or null rev_len to 0 ar_len? Relevant to T192189.
[13:34:15] <stashbot>	 T192189: Some revisions incorrectly shown as "empty" - https://phabricator.wikimedia.org/T192189
[13:34:48] <addshore>	 anomie: at a guess there might be an intval somewhere
[13:35:53] <DanielK_WMDE_>	 anomie: i'm not aware of a more recent change being deployed than the one 4 months ago. But as addshore said, it is possible that this is related to RevisionStore, yes.
[13:36:48] <DanielK_WMDE_>	 RevisionRecord *should* calculate the revision size if it's null in the database.
[13:38:58] <addshore>	 the only thing that sticks out to me would be https://github.com/wikimedia/mediawiki/blob/master/includes/Storage/RevisionStore.php#L1768
[13:39:20] <addshore>	 *reads the ticket*
[13:39:25] <DanielK_WMDE_>	 anomie: RevisionStore::listRevisionSizes() has:
[13:39:31] <DanielK_WMDE_>	 $revLens[$row->rev_id] = intval( $row->rev_len );
[13:39:53] <DanielK_WMDE_>	 this method bypasses all the magic in RevisionRecord and SlotRecord
[13:40:18] <addshore>	 yup, looks like the ticket relates to lists of revisions so that's probably it
[13:40:21] <DanielK_WMDE_>	 addshore: ah, i see you are way ahead of me :)
[13:40:28] <addshore>	 heh, second time an intval has thrown me today ;)
[13:42:59] <anomie>	 Looks like it's undeletion specifically.
[13:43:15] <addshore>	 hmmm
[13:51:49] <anomie>	 addshore: https://github.com/wikimedia/mediawiki/blob/master/includes/Storage/RevisionArchiveRecord.php#L87
[13:52:44] <addshore>	 that'll be the one
[13:52:45] <DanielK_WMDE_>	 anomie: yes, that is probably it. I wonder why I did it correctly for ar_sha1, but not for ar_len?...
[13:53:05] <DanielK_WMDE_>	 oh, i know why.
[13:53:09] <DanielK_WMDE_>	 tables.sql has:
[13:53:46] <DanielK_WMDE_>	 "ar_len int unsigned". I may have turned the absense of DEFAULT NULL into NOT NULL in my mind
[13:54:14] <DanielK_WMDE_>	 actually, ar_sha1 *does* have NOT NULL, but defualts to ''.
[13:54:37] <DanielK_WMDE_>	 so Line 88 should probably check !empty() instead of isset()
[17:40:41] <no_justification>	 legoktm: A little birdie told me you wanna hold off on REL1_31?
[19:56:21] <legoktm>	 no_justification: well no, I'm just worried about whether requiring PHP 7 is going to be possible/realistic
[19:56:37] <no_justification>	 Oh, so not a blocker to branching, but possibly release?
[19:56:49] <legoktm>	 yeah
[19:58:19] <James_F>	 :-(
[20:16:53] <no_justification>	 We'll branch today as planned :)
[20:18:08] <no_justification>	 James_F: You happy with ed84cd9c424e8ee66aa94d572e6e892c781ba02c as the branch point?
[20:18:26] <no_justification>	 (also: fun undocumented process we do for release....I ask James if he likes the branch point? We've done this a few times)
[20:19:21] <legoktm>	 not 69257de17fc899c447c9f1229b6ed319bc05d316 ? today's l10n-bot run
[20:28:28] <no_justification>	 Fatal error: Class undefined: JobExecutor in /srv/mediawiki/rpc/RunSingleJob.php on line 64
[20:28:32] <no_justification>	 Ruh roh
[20:29:35] <no_justification>	 Yes, you're right
[20:36:26] <no_justification>	 legoktm: Core branched, doing extensions/skins/vendor now
[20:36:35] <legoktm>	 <3
[20:36:59] <no_justification>	 I want to use branch.py cuz it's fast, but it's kinda buggy still
[20:37:11] <no_justification>	 So had to checkout the old make-extension-branches that I (I guess prematurely) deleted.
[20:37:55] <no_justification>	 Then I'll build the core commits for adding submodules & version changes
[20:38:22] <no_justification>	 make-extension-branches busted too?
[20:38:23] <no_justification>	 Uh
[20:42:43] * James_F laughs.
[20:43:33] <no_justification>	 Actually, branch.py is mostly ok for the non-core stuff
[20:43:38] <no_justification>	 Except REST api is being lame :\
[20:43:41] <James_F>	 no_justification: Yeah, what legoktm said, 69257de17 is a good point.
[20:44:00] <no_justification>	         _get_client().put(
[20:44:00] <no_justification>	             '/projects/%s/branches/%s' % (
[20:44:00] <no_justification>	                 repository.replace('/', '%2F'),
[20:44:00] <no_justification>	                 branch.replace('/', '%2F')),
[20:44:00] <no_justification>	             data={'revision': revision}
[20:44:00] <no_justification>	         )
[20:46:36] <no_justification>	 cf: https://gerrit.wikimedia.org/r/Documentation/rest-api-projects.html#create-branch
[20:48:17] <no_justification>	 Oh duh.
[20:49:26] <no_justification>	 requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://gerrit.wikimedia.org/r/a/projects/mediawiki%2Fskins/branches/REL1_31
[20:49:29] <no_justification>	 Progress!
[20:49:37] <no_justification>	 (better than 404)
[20:53:42] <no_justification>	 Ahhh, data= should be json=
[20:55:34] <no_justification>	 What is this? https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/ArticleMetaDescription,branches
[20:55:52] <no_justification>	 Just created in Feb. No valid HEAD breaks mah script
[20:56:22] <James_F>	 Lame.
[20:56:49] <no_justification>	 I'll hack around it
[20:57:34] <James_F>	 From https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests/Archive/2018 they wanted to import from https://github.com/Wikia/app/tree/dev/extensions/wikia/ArticleMetaDescription but haven't yet.
[20:57:58] <James_F>	 Maybe I should do it for them? Eh.
[20:58:13] <legoktm>	 I suspect there are more repos with no valid branches
[20:58:23] <no_justification>	 Well, just HEAD not pointing to one
[20:58:31] <James_F>	 `git filter branch` is a fair bit of work to do without checking with them first.
[20:58:38] <legoktm>	 ED checks there's at least one branch now before including the repository because there were so many empty repos
[20:58:56] <no_justification>	 BlueSpiceMenues
[20:59:10] <no_justification>	 Actually, I think I can limit my search
[21:00:01] <no_justification>	  /projects/?b=master
[21:00:07] <no_justification>	 Since we're branching from that
[21:02:40] <no_justification>	 Ok, doing that now
[21:03:05] <no_justification>	 Yep, worked
[21:06:04] <James_F>	 no_justification: Can I waste your time briefly? Is there a line length we're aiming for with the release notes? Right now they're all over the place. If you say "76" or "80" I can write a quick patch cleaning REL1_31's up.
[21:06:46] <no_justification>	 I don't care.
[21:07:07] * James_F grins. OK.
[21:12:37] <no_justification>	 Bleh got to the W's
[21:12:42] <no_justification>	 One of the repos won't let me create branches
[21:13:16] * bd808 assumes we have 500 repos named wiki*
[21:13:33] <no_justification>	 WikibaseQualityConstraints to be specific. Weirdly, the UI let me create it
[21:13:36] * no_justification reruns script
[21:22:05] <no_justification>	 Branches done!
[21:24:10] <legoktm>	 yay! https://gerrit.wikimedia.org/r/427262 is the ED update whenever you have time
[21:29:09] <no_justification>	 https://gerrit.wikimedia.org/r/#/c/427264/
[21:29:18] <no_justification>	 for the submodule add + version bump
[21:30:20] <legoktm>	 > 1.27.0-rc.0 bump
[21:31:11] <legoktm>	 no_justification: any reason .gitmodules is not alphasorted?
[21:32:28] <no_justification>	 The last few of them fucked up the first time, so added them after.
[23:43:59] <TimStarling>	 about requiring PHP 77
[23:44:04] <TimStarling>	 or PHP 7 rather
[23:45:01] <Platonides>	 hehe, requiring PHP 77 would be quite restrictive :D
[23:45:06] <TimStarling>	 can't we just give an error in the installer?
[23:45:55] <TimStarling>	 is it necessary to give an error in wfEntryPointCheck()?
[23:48:28] <TimStarling>	 I don't know what the point of erroring out is when there is verifiably nothing that depends on PHP 7+
[23:49:33] <James_F>	 TimStarling: Sure, we can do that, though it's a bit of a mess to have a function that claims to check PHP 7 but doesn't.
[23:50:55] <TimStarling>	 where does it claim that?
[23:51:22] <TimStarling>	 PHPVersionCheck only says that it will "display something vaguely comprehensible in the event of a totally unrecoverable error"
[23:54:05] <TimStarling>	 just looking at T172165, it was pretty clear that the deadline was April 1
[23:54:06] <stashbot>	 T172165: Require either PHP 7.0+ or HHVM in MW 1.31 - https://phabricator.wikimedia.org/T172165
[23:55:02] <TimStarling>	 it would be reasonable at this point to just merge James_F's change
[23:56:19] <James_F>	 TimStarling: We were going to merge it before the weekend, but unfortunately one last bit of CI doesn't work on PHP7 yet.
[23:56:43] <James_F>	 TimStarling: It shouldn't break production (he says), but we'd be unable to merge any code anywhere, which is… not great.
[23:57:06] <James_F>	 I suppose we could temporarily not check in PHPVersionCheck and so that it passes, as you say.