[01:21:25] greg-g: vacation is scary! [01:28:27] legoktm: ah, I didn't see it in the "This week in WMF engineering" email [07:51:46] 6MediaWiki-Core-Team, 5Patch-For-Review: Fix various DB master warnings from dbperformance.log - https://phabricator.wikimedia.org/T92357#1181525 (10Gilles) I decided to parse dbperformance.log to see which ones are the biggest offenders. Here's my attempt: ``` cat /a/mw-log/dbperformance.log | grep 'masterC... [08:10:58] 6MediaWiki-Core-Team, 5Patch-For-Review: Fix various DB master warnings from dbperformance.log - https://phabricator.wikimedia.org/T92357#1181581 (10Gilles) Examining "75167 Block.php line 219 calls wfGetDB()" in particular, to start with one of the biggest. The main source of this seems to be Wikibase. I'll f... [08:21:44] 6MediaWiki-Core-Team, 5Patch-For-Review: Fix various DB master warnings from dbperformance.log - https://phabricator.wikimedia.org/T92357#1181620 (10Gilles) [08:29:38] 6MediaWiki-Core-Team, 5Patch-For-Review: Fix various DB master warnings from dbperformance.log - https://phabricator.wikimedia.org/T92357#1181632 (10Gilles) Looking at the biggest one, "Revision.php line 128 calls wfGetDB()", it's coming from Captcha.php in the ConfirmEdit extension. [08:34:17] 6MediaWiki-Core-Team, 5Patch-For-Review: Fix various DB master warnings from dbperformance.log - https://phabricator.wikimedia.org/T92357#1181635 (10Gilles) Actually, it's doing the right thing because it only fetches from master on POST. Rather than investigate each of these and finding out after digging thro... [10:53:49] 6MediaWiki-Core-Team, 10MediaWiki-Page-editing, 10Wikidata, 5Patch-For-Review: WikiPage: "Could not find text for current revision" - https://phabricator.wikimedia.org/T93976#1181878 (10Multichill) Just seemed to have hit this bug. Output from pywikibot: >>> Miklagard <<< Adding P641 --> [[wikidata:Q5377]... [10:57:11] 6MediaWiki-Core-Team, 10MediaWiki-Page-editing, 10Wikidata, 5Patch-For-Review: WikiPage: "Could not find text for current revision" - https://phabricator.wikimedia.org/T93976#1181885 (10aude) stacktrace for the error that multichill got: /w/api.php MWException from line 1783 of /srv/mediawiki/php-1.25wm... [14:42:06] 6MediaWiki-Core-Team, 10MediaWiki-Page-editing, 10Wikidata, 5Patch-For-Review: WikiPage: "Could not find text for current revision" - https://phabricator.wikimedia.org/T93976#1182177 (10daniel) Does this still happen despite Aaron's fix in I57eb41b463? Or isn't that deployed yet? [14:46:37] 6MediaWiki-Core-Team, 10MediaWiki-Page-editing, 10Wikidata, 5Patch-For-Review: WikiPage: "Could not find text for current revision" - https://phabricator.wikimedia.org/T93976#1182184 (10aude) @daniel just checked... apparently not deployed yet to Wikidata https://github.com/wikimedia/mediawiki/commits/wmf... [15:19:28] 6MediaWiki-Core-Team, 6Project-Creators, 15User-Bd808-Test: Create Search-Team project - https://phabricator.wikimedia.org/T94493#1182239 (10bd808) [15:20:34] 6MediaWiki-Core-Team, 6Project-Creators, 15User-Bd808-Test: Create Availability-Team project - https://phabricator.wikimedia.org/T94490#1182244 (10bd808) [15:41:38] 6MediaWiki-Core-Team, 6Project-Creators, 15User-Bd808-Test: Create Search-Team project - https://phabricator.wikimedia.org/T94493#1182331 (10bd808) a:5bd808>3None [16:06:26] 6MediaWiki-Core-Team, 10MediaWiki-Debug-Logging, 10MediaWiki-General-or-Unknown, 6Release-Engineering, and 2 others: Create a minimal backport of PSR-3 logging to MediaWiki 1.23 LTS - https://phabricator.wikimedia.org/T91653#1182430 (10bd808) [16:06:36] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7Design, 7Epic, 5Patch-For-Review: As a user authorising an OAuth tool to act on my behalf, I'd like the different permissions a tool can request to be explained to me using clear language so I can underst... - https://phabricator.wikimedia.org/T91825#1182432 [16:07:35] entify dumbassery [16:10:43] 6MediaWiki-Core-Team, 10MediaWiki-Debug-Logging, 10MediaWiki-General-or-Unknown, 6Release-Engineering, and 2 others: Create a minimal backport of PSR-3 logging to MediaWiki 1.23 LTS - https://phabricator.wikimedia.org/T91653#1182452 (10bd808) The patch must provide: * `MediaWiki\Logger\LoggerFactory::getIn... [16:16:01] @anomie: So with T97920 fixed, does that unblock everything, or are they now blocked on the new T95168? [16:16:41] erm..I think I got the numbers wrong, but hopefully you understand my intent [16:16:58] is the new tihng a blocker, or just something they'll deal with at their leisure? [16:17:34] meeple27: Same situation with T95168, merging before that's fixed will probably raise deprecation warnings but otherwise should work. There's also T94392 now, too. [16:17:38] oh. Phab already has the answer. blocker. [16:17:45] lovely [16:17:57] thanks [16:20:34] anomie: archcom can be a bit of a...um...."delay", so I'll try to help this one along [16:20:51] is T94392 ready for them to discuss, or is there anything else that needs to happen before they do? [16:21:16] I have no idea what Daniel might want to discuss there, although I have a baseless guess. [16:22:46] Did you sprinkle it liberally with ValueObject classes? [16:26:44] bd808: My baseless guess is that he wants a tree of ValueObject classes instead of an array as internal data storage. I told him "no" on that at Wikimania, but it's the only thing I can think of. [16:27:42] PHP and trees are not really friends [16:27:52] PHP loves arrays [16:28:16] But I know nothing of this area of the code base yet [16:29:30] I posted questions in the ticket, so hopefully we can find out what he wants [16:30:01] bd808: Speaking of API code stuff, do you know of a good way to make it a strong recommendation that our "MediaWiki API team" (meaning me, specifically) should be asked to code-review new api.php modules? [16:30:58] s/meaning me, specifically/probably meaning me, specifically, since no one else is terribly familiar with it either/ [16:31:10] Probably easiest to start with asking nicely on engineering-l [16:31:23] and then take other measures as needed [16:32:05] bd808: You're better at asking nicely than I am, hint hint. ;) Or should we discuss it in the meeting tomorrow first? [16:32:57] let's talk tomorrow to make sure we are all on the same page as to what authority and right we are asking for. But yeah I can write the email. :) [16:34:35] bd808: Sounds like a plan. Maybe we should have an agenda etherpad or google-doc (the latter having the advantage of being private) or something to throw stuff-needing-discussion onto so we don't forget it? meeple27, what do you think? [16:35:00] +1. This is one place where I prefer a gdoc [16:35:21] Then we don't have to worry about leaking sekrets [16:35:33] shhh! it's already out there! [16:36:07] generally I would favor an etherpad for meeting agenda, but it could use code words or refer to gdocs for secret cabal materials [16:36:25] but i'm ok with gdoc if that makes more sense [16:36:48] I was in a call the other day where someone deleted something that had been typed in an etherpad. I didn't bother to point out that all etherpad edits are in the pad history [16:37:02] right [16:37:29] I don't really want to put the exact days I'm going to be on vacation into an etherpad or wiki page to be honest :) [16:37:48] fair enough. gdoc it is [16:38:11] We don't necessarily need vacations in the gdoc like mw-core did/does, though. [16:38:35] 6MediaWiki-Core-Team, 5Patch-For-Review: Fix various DB master warnings from dbperformance.log - https://phabricator.wikimedia.org/T92357#1182547 (10Gilles) It's deployed and it's all GETs. I have the feeling that this was already accounted for elsewhere in the code :) Oh, well... [16:38:38] We could use an officewiki page, or probably a team calendar. [16:38:48] crazy pants! [16:38:50] :) [16:39:28] I'm cool with an etherpad as long as we don't put vacation days there I guess [16:39:33] * anomie suspects having it in the mw-core gdoc was because robla has way too many things to keep track of [16:39:44] i don't want to have to remember what I can or can't type in [16:39:44] * bd808 just counted up all the places that could be found out anyway [16:40:03] should it be shared with WMF or just specific people? [16:40:04] The other thing with an etherpad is if it's a security bug we'd have to refer to it only by task number, no detail. [16:40:17] yeah. gdoc is just easier [16:40:33] meeple27: all wmf is fine [16:40:42] ok, gdoc is fine. I just hate using proprietary google stuff more than needed. [16:41:06] If it's all-WMF, we'll still have to talk around security bugs. [16:42:03] Other than linking to the bugs we probably should be having documented discussion in phab anyway though right? [16:42:36] meh whatever I'm thinking about this too hard. Somebody pick something [16:42:39] Useful discussion in phab, anyway. But "Hey, we need to talk about this and figure out who's on the hook for fixing it", no. [16:43:49] gdoc seems to be the consensus so far. legoktm, marktraceur, tgr: We're discussing etherpad vs gdoc as storage for a basic agenda for our team meetings. Or, I suppose, we could do a wiki page on officewiki. Votes? [16:44:07] Ok I'll go with something for now and we can finalize in the mtg itself [16:44:29] I tend to prefer wikis over gdocs, but don't care that much [17:13:08] 6MediaWiki-API-Team, 6Collaboration-Team, 10Flow: Flow unit test needs update for Gerrit change 183315 - https://phabricator.wikimedia.org/T95187#1182641 (10Anomie) 3NEW [17:14:45] 6MediaWiki-API-Team, 10MediaWiki-API, 5Patch-For-Review: list=logevents tries to return both the creating user's and the created user's ids as "userid" - https://phabricator.wikimedia.org/T73020#766496 (10Anomie) [17:14:48] 6MediaWiki-API-Team, 6Collaboration-Team, 10Flow, 5Patch-For-Review: Flow unit test needs update for Gerrit change 183315 - https://phabricator.wikimedia.org/T95187#1182667 (10Anomie) [17:14:57] 6MediaWiki-API-Team, 6Collaboration-Team, 10Flow, 5Patch-For-Review: Flow unit test needs update for Gerrit change 183315 - https://phabricator.wikimedia.org/T95187#1182641 (10Anomie) [17:15:01] 6MediaWiki-API-Team, 10MediaWiki-API, 5Patch-For-Review: let list=logevents use the new LogFormatter to format its output - https://phabricator.wikimedia.org/T35235#1182668 (10Anomie) [17:47:57] 6MediaWiki-API-Team, 6Collaboration-Team, 10Flow, 5Patch-For-Review: Flow unit test needs update for Gerrit change 183315 - https://phabricator.wikimedia.org/T95187#1182798 (10EBernhardson) p:5Triage>3Unbreak! [17:52:08] 6MediaWiki-API-Team, 10MediaWiki-Configuration, 5Patch-For-Review: Support "ResourceModuleSkinStyles" in ExtensionProcessor - https://phabricator.wikimedia.org/T91566#1182807 (10Legoktm) p:5Triage>3Normal [17:52:20] 6MediaWiki-API-Team, 10MassMessage, 5Patch-For-Review, 7Wikimedia-log-errors: Invalid parameter for message "logentry-massmessage-failure" - https://phabricator.wikimedia.org/T93110#1182808 (10Legoktm) 5Open>3Resolved [17:52:27] 6MediaWiki-API-Team, 10MediaWiki-Configuration, 10MediaWiki-Maintenance-scripts, 5MW-1.25-release, 5Patch-For-Review: Update mergeMessageFileList.php to support reading extension/skin.json files - https://phabricator.wikimedia.org/T94756#1182810 (10Legoktm) p:5Triage>3Normal [17:52:56] 6MediaWiki-API-Team, 10Librarization: Move includes/password into includes/libs (library-ify) - https://phabricator.wikimedia.org/T89742#1182814 (10Legoktm) a:5Legoktm>3None [18:03:35] 6MediaWiki-API-Team, 10Librarization, 5Patch-For-Review, 7Upstream: Composer autoloader is slow - https://phabricator.wikimedia.org/T85182#1182902 (10Legoktm) mediawiki/extensions/DonationInterface/vendor maybe? [18:06:26] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Build a tool for synchronizing Wikidata changes into Blazegraph - https://phabricator.wikimedia.org/T89852#1182926 (10Manybubbles) [18:06:37] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Build a tool for synchronizing Wikidata changes into Blazegraph - https://phabricator.wikimedia.org/T89852#1047037 (10Manybubbles) [18:07:07] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Build a tool for synchronizing Wikidata changes into Blazegraph - https://phabricator.wikimedia.org/T89852#1047037 (10Manybubbles) [18:07:40] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Build a tool for synchronizing Wikidata changes into Blazegraph - https://phabricator.wikimedia.org/T89852#1047037 (10Manybubbles) [18:08:11] 6MediaWiki-API-Team, 10Librarization, 5Patch-For-Review, 7Upstream: Composer autoloader is slow - https://phabricator.wikimedia.org/T85182#1182939 (10Legoktm) >>! In T85182#1182902, @Legoktm wrote: > mediawiki/extensions/DonationInterface/vendor maybe? Submitted https://gerrit.wikimedia.org/r/#/c/202075/ [18:26:06] 6MediaWiki-API-Team, 10MediaWiki-API, 5Patch-For-Review: list=logevents tries to return both the creating user's and the created user's ids as "userid" - https://phabricator.wikimedia.org/T73020#1183011 (10EBernhardson) [18:26:09] 6MediaWiki-API-Team, 6Collaboration-Team, 10Flow, 5Patch-For-Review: Flow unit test needs update for Gerrit change 183315 - https://phabricator.wikimedia.org/T95187#1183009 (10EBernhardson) 5Open>3Resolved a:3EBernhardson [18:26:13] 6MediaWiki-API-Team, 10MediaWiki-API, 5Patch-For-Review: let list=logevents use the new LogFormatter to format its output - https://phabricator.wikimedia.org/T35235#1183012 (10EBernhardson) [18:29:40] https://codeascraft.com/2015/04/06/experimenting-with-hhvm-at-etsy/ [18:31:13] greg-g: a little lame they didn't give us any credit [18:31:16] they pinged us a lot with Qs [18:31:24] :/ [18:41:51] AaronSchulz: if someone edits an article, and then it is purged from varnish, the next page view will take a while, right? [18:42:09] we don't populate varnish automatically [18:46:11] anomie: , do you know? [18:49:03] ori: Not for sure, I'm half guessing here: Someone edits an article, then varnish should get purged then, then in many cases I'd think the person would be redirected to view the article they just edited. But it might hit the parser cache from the save they just made (depending on whether their prefs make it cacheable?) and so not take a full reparse for the view. Someone else coming along with different prefs might then have a long load. [18:49:39] right [19:38:47] 6MediaWiki-Core-Team, 5Patch-For-Review: Fix various DB master warnings from dbperformance.log - https://phabricator.wikimedia.org/T92357#1183201 (10PleaseStand) >>! In T92357#1182547, @Gilles wrote: > It's deployed and it's all GETs. I have the feeling that this was already accounted for elsewhere in the code... [19:41:38] bd808: I think we can re-try https://gerrit.wikimedia.org/r/202126 and see if it breaks beta again [19:47:40] ^d: save me! [19:48:06] what is the right thing to use instead of wgCanonicalServer but when you want /wiki/ urls [19:48:29] because sometimes the rewrite isn't setup and that has to work and stuff [19:53:09] manybubbles: is this in PHP? you should be using the Title class [19:53:13] yeah what's the right way to figure out what is the true wiki Url? [19:53:27] legoktm: this is in PHP in maintenance script [19:53:32] oh yeah! [19:54:05] Title::newFromText('FooBar')->getFullURL(); [19:54:17] also getLocalURL() [19:54:47] getLocalURL is the one that handles all the action paths stuff and fun things [19:54:48] legoktm: aha, will try that [19:54:50] thanks [19:56:34] <^d> legoktm beat me to it [19:56:38] * ^d is eating [19:57:18] legoktm: got it. I think getCanonicalUrl? [19:57:36] in my case it sounds better [20:00:31] bd808, I'm getting unknown class Monolog\Handler\AbstractProcessingHandler on Special:Version. apparently, it's because monolog/monolog is just suggested, but is used in code [20:01:53] legoktm: didn't work as expected: \Title::newFromText('EntityData', 'Special')->getFullURL(), produces http://localhost/wiki/EntityData but wgCanonicalServer is http://wikidata.wiki.local.wmftest.net:8080/ [20:02:33] the host name is wrong.... [20:02:38] MaxSem: I've had another report of that too. I'll try to figure out why the class is suddenly being loaded [20:03:59] this seems to work: wfExpandUrl(\Title::newFromText('Special:EntityData')->getLocalURL(), PROTO_CANONICAL) but I'm not sure if it's right [20:04:07] MaxSem: Oh. I bet it is the shims all being in one PHP source file :/ [20:30:36] legoktm: https://gerrit.wikimedia.org/r/#/c/201059/ [20:30:53] AaronS: where'd you go btw? [20:31:11] * AaronS is just sitting on a couch [20:32:03] AaronS: inquiring minds would like to know about the flowers on your desk! [21:04:11] 6MediaWiki-Core-Team, 5Patch-For-Review: High frequency of master queries on GET requests due to Flow - https://phabricator.wikimedia.org/T95232#1183751 (10aaron) 3NEW a:3aaron [21:04:58] 6MediaWiki-Core-Team, 5Patch-For-Review: High frequency of master queries on GET requests due to Flow - https://phabricator.wikimedia.org/T95232#1183751 (10aaron) [21:52:32] 6MediaWiki-Core-Team, 6Collaboration-Team, 10Flow, 5Patch-For-Review: High frequency of master queries on GET requests due to Flow - https://phabricator.wikimedia.org/T95232#1184043 (10Legoktm) [22:22:01] legoktm: What's the difference between rename and promote (https://gerrit.wikimedia.org/r/#/c/201144)? [22:22:32] I'm not exactly sure what you're calling "promote" [22:23:01] csteipp: rename is global --> global, promote is local unattached --> name change --> automatic globalization [22:23:22] https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/master/includes/LocalRenameJob/LocalRenameUserJob.php#L73 [22:23:42] legoktm: Ah, cool. Thanks! [22:24:47] It's kind of weird how we're using the term "promote" here [22:24:52] the user doesn't become any more important [22:27:30] > From Latin prōmōtus, perfect passive participle of prōmoveō (“move forward, advance”). [22:33:24] 'process' [23:07:10] anomie: EPL please. [23:12:31] bd808: :D [23:12:51] legoktm: /me has fingers crossed [23:13:34] marktraceur: aren't you supposed to be on vacation or something? [23:14:03] he's supposed to be driving, not chatting on IRC while driving [23:14:13] he should be somewhere in the mountains by now, I thin [23:14:15] k [23:14:47] Maybe he has hands free bluetooth irc ;) [23:15:57] bd808: Or something yes [23:16:06] We made it to Grand Junction and I decided to check IRC. [23:16:10] About ten people pinged me. [23:16:26] Only seven were about work though! [23:16:35] heh [23:16:55] are we going to karaoke when I'm in SF too? [23:17:16] I'll get in on Tuesday and leave Thursday evening [23:17:42] which I guess leaves a small window of off key singing opprotunity [23:22:49] bd808: I'm probably doing karaoke on Thursday. So we may miss our chance. [23:22:58] There's a karaoke thing on Tuesday that I probably will nix. [23:22:58] darn [23:27:36] bd808: 2 day trip? yay fun! :) [23:28:27] I could have stayed longer but it didn't seem worhwhile [23:28:34] *worthwhile [23:29:06] hotels in SF are not cheap [23:29:54] nope [23:30:03] bd808: I got an RV you can stay in up in Petaluma :) [23:30:36] If I want to camp in the woods I'll drive my jeep up the road behind my house thanks ;) [23:31:06] it's camping in a driveway, even better!