[08:02:06] 6MediaWiki-Core-Team, 10MediaWiki-General-or-Unknown, 7Upstream: Using PCRE Nested named refs do not work - https://phabricator.wikimedia.org/T27986#1161461 (10hashar) Seems fine to close this bug. From the bug report it has been introduced in PCRE release 8.01 and fixed end of 2010 with release of 8.11 (10-... [10:30:46] 7Blocked-on-MediaWiki-Core, 10MediaWiki-extensions-Translate, 7I18n, 3LE-Sprint-85, 5Patch-For-Review: Not able to mark big pages for translation at mediawiki.org - https://phabricator.wikimedia.org/T90704#1161778 (10Arrbee) [10:31:08] 7Blocked-on-MediaWiki-Core, 10MediaWiki-User-preferences, 10MediaWiki-extensions-ContentTranslation, 5ContentTranslation-Release5, and 2 others: CX beta-feature does not stay enabled - https://phabricator.wikimedia.org/T92232#1161780 (10Arrbee) [11:23:35] 6MediaWiki-Core-Team, 6operations, 5Patch-For-Review: Store unsampled API and XFF logs - https://phabricator.wikimedia.org/T88393#1161994 (10fgiunchedi) also note that fluorine has another 300+GB free in the vg ``` root@fluorine:/a/mw-log/archive# vgs VG #PV #LV #SN Attr VSize VFree vg0 2 1... [14:04:09] morning [15:01:20] Nikerabbit: what's the latest status on your two blocked tasks? Who can I try to convince to work with you? [15:06:30] bd808: I think there is three ;) [15:08:09] bd808: https://phabricator.wikimedia.org/T92232 is most urgent... https://gerrit.wikimedia.org/r/#/c/199554/ needs review, I'm not very comfortable just +2in it myself [15:10:02] https://phabricator.wikimedia.org/T90704 had three patches, Aaron had merged one +1ed the other two... one of the two needs someone from ops to +2 I believe [15:10:40] *nod* I was hoping anomie would +2 that first one. I think it is doing the right things but I'm not very familiar with that code [15:11:20] bd808: What were you hoping I'd +2? [15:11:25] https://phabricator.wikimedia.org/T54728 is the least important, has one patch and then needs approval from Tim/Pringle to re-enable that page or instructions what still needs to be done [15:11:27] This one -- https://gerrit.wikimedia.org/r/#/c/197920/ -- can go out in SWAT [15:11:44] anomie: https://gerrit.wikimedia.org/r/#/c/199554/ -- assuming it is "right" now [15:11:53] * anomie looks [15:13:03] 197920 is supposed to go with https://gerrit.wikimedia.org/r/#/c/197919/ [15:13:29] Nikerabbit: do we need to have the dedicated runner before switching on $wgTranslateDelayedMessageIndexRebuild ? [15:13:55] bd808: it can go alone as well, but then we might get complaints from users if the delays for the job are long [15:14:24] I don't know exactly what kind of delays there are usually, whether it will be a big problem or not a problem at all [15:14:25] Ok. I'll see if I can get some ops attention for the puppet change first then [15:14:33] Where complaints reads "utter panic" [15:15:26] well, not quite but almost [15:15:45] bd808: +2ed [15:15:45] they expect it to happen immediately, few minutes would be reasonable and hours are unnacceptable [15:16:25] thanks anomie [15:18:41] Nikerabbit: The mw-config change can go in a SWAT window. Just add it on https://wikitech.wikimedia.org/wiki/Deployments to a time slot. Probably could go in the "evening" window today. [15:18:59] I'm not sure how to verify it once it is deployed [15:19:55] godog is deploying the jobrunner change right now. [15:22:18] ^demon|sick, manybubbles: Is it ok if I exclude the "Search backend error during *" errors from the logstash fatalmonitor dashboard's most frequent errors list? [15:22:48] hmmm [15:22:52] I'd add a count for them in the timeline histogram [15:23:06] can link me [15:23:16] but not toggle that search in the top terms report [15:23:22] manybubbles: https://logstash.wikimedia.org/#/dashboard/elasticsearch/fatalmonitor [15:24:24] My only reasoning is that these seem to not be actionable errors for deployers [15:25:11] bd808: evening swat is past midnight for me, perhaps tomorrow morning swat? [15:25:26] Yeah, whatever works for you [15:25:44] * bd808 is just trying to keep things moving [15:28:08] bd808: https://logstash.wikimedia.org/#/dashboard/elasticsearch/search%20backend%20error doesn't look too alarming [15:28:53] manybubbles: yeah it's not crazy pants. [15:29:10] obviously we're not serving the guy doing all the ORs very well [15:29:14] Looks like there was a burst right around the time I started looking at it [15:29:35] and those ' ' ones are a pita and we've never fully tracked them down - but all rare [15:29:49] *nod* I know I've seen them before [15:29:55] are they weird whitespace? [15:30:49] bd808: yes, tyal [15:31:25] manybubbles: I'll leave it all alone in the dashboard. If it gets to be annoying for some reason there's an easy dashboard change that I can setup [15:31:28] bd808: its weird - there are lots of layers of parsing between where they query is just whitespace and where we get the strings and we've never been able to reproduce it [15:31:35] (that is, thank you a lot) [15:31:36] bd808: cool [15:31:44] Nikerabbit: I grokked that :) [16:36:14] legoktm: https://gerrit.wikimedia.org/r/200598 [16:36:39] good morning to you too! [17:47:54] anomie: (re: AuthManager) there are a lot of places where you're using User, but don't have a type hint because it could be a UserValue (or something else) in the future. what are you thinking of for keeping back-compat in that situation? Would UserValue make sure to have all the same methods as User? or...? [17:48:35] legoktm: I'm hoping things mostly won't be using the methods on User that we wouldn't have on a hypothetical UserValue... [17:50:21] hmm, alright [17:51:53] I think I've looked at every file at some point now [17:53:22] Or even better that we can somehow move all the crap out of User into someplace more sensible, deprecate all the stubs that are left to call the someplace, then remove it instead of pretending to keep "User" around. [17:53:50] s/remove it/remove the stubs/ [17:54:02] Because "UserValue" is a stupid name. [17:54:09] bd808: As PO, would you be the person to make a decision about T32788? (I'm still trying to wrangle the Needs Review column into submission) [17:54:57] "make a decision"? :) [17:55:56] meeple27: anomie has -1'd his own patch so my decision is that it is stalled I guess [17:56:23] That probably means it is not really in review anymore [17:56:36] and is instead back in todo [17:57:00] and presumably unassigned as well [17:57:12] doesn't seem stalled, though. just still open? [17:57:28] also, could I get a review on https://gerrit.wikimedia.org/r/#/c/200338/ ? trivial really [18:01:40] meeple27: I wouldn't get too OCD about the current mw-core board. "We" need to evaluate each task and find it a new home soon [18:01:58] * bd808 thinks that is the royal we rather than the sarcastic we [18:06:46] 6MediaWiki-Core-Team, 6Collaboration-Team, 10Flow: Avoid use of merge() in Flow caches - https://phabricator.wikimedia.org/T94029#1163552 (10DannyH) [18:06:58] legoktm: I wonder whether any of the other E_*ERROR constants should get the same treatment. Which may make "error" somewhat misnamed if it's left with mostly warnings... [18:08:25] anomie: hmm, stuff like E_COMPILE_ERROR ? [18:08:58] I'm not really sure...I just want stacktraces for normal fatals :/ [18:09:11] bd808: For sure. Just trying to sort things out so I can move forward. Learning, learning. [18:09:38] legoktm: Yeah. Really all the ones that end in _ERROR except E_USER_ERROR and E_RECOVERABLE_ERROR are basically fatal, aren't they? [18:10:06] Or are we considering "fatal" as in "Zend doesn't give you any chance of catching them" [18:10:49] 6MediaWiki-Core-Team, 7Epic: MediaWiki multi-datacenter investigation and work - https://phabricator.wikimedia.org/T88445#1163576 (10Mattflaschen) [18:10:55] I think that. [18:12:39] According to http://php.net/manual/en/function.set-error-handler.php, E_ERROR, E_PARSE, E_CORE_ERROR, and E_COMPILE_ERROR can't be handled by the error handler. Not that we'd even see most of those? [18:13:41] if we eval() some bad stuff maybe? [18:15:29] so that leaves E_USER_ERROR and E_RECOVERABLE_ERROR [18:15:34] anomie: https://gerrit.wikimedia.org/r/#/c/200630/1/includes/User.php [18:17:33] 6MediaWiki-Core-Team, 6Collaboration-Team, 10Flow: Avoid use of merge() in Flow caches - https://phabricator.wikimedia.org/T94029#1163637 (10Mattflaschen) [18:18:11] legoktm: https://gerrit.wikimedia.org/r/#/c/200631/1/includes/User.php cleanup [18:18:52] 6MediaWiki-Core-Team, 6Collaboration-Team, 10Flow: Spike: Avoid use of merge() in Flow caches - https://phabricator.wikimedia.org/T94029#1163659 (10DannyH) [18:21:52] anomie: so...I think we should just mark all of those as 'fatal' even though we can't catch them, and deal with 'error' being poorly named in another patch? [18:22:09] Errors are "fatal", and warnings are "error"! ;) [18:22:18] legoktm: works for me [18:23:41] updated the patch [18:23:52] 6MediaWiki-Core-Team, 7Epic: MediaWiki multi-datacenter investigation and work - https://phabricator.wikimedia.org/T88445#1163711 (10aaron) [18:25:05] I think in the future we can have one 'error' log stream and just use the structured logging/level system for this: error/fatal would be $logger->error(), warnings would be $logger->warning(), etc. [18:28:50] * legoktm is off to find food [18:35:55] * aspiecat wonders wtf betafeatures calls saveSettings() on every getPreferences hook... [18:39:16] aspiecat: it's evil and terrible. when you visit Special:Preferences it updates what features you're auto-subscribed to [18:39:32] I see that pattern in other exts too [18:43:06] 6MediaWiki-Core-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: Code review CentralAuth's GlobalUserMerge and related UserMerge code before SUL finalization mass usage - https://phabricator.wikimedia.org/T961#1163871 (10brion) I'm giving the updated extension a first-pass review now... [18:52:44] <_joe_> is the meeting up this evening? [18:52:53] <_joe_> because I thought mwcore was over :) [18:53:39] The meeting may continue zombie-like for a while, until all the new teams figure out their own meetings and when they meed with robla. [18:54:46] hopefully that meeting can be repurposed (with much smaller attendance) after next week [19:13:47] <_joe_> anomie: ok, I'm gonna pass... it's 11 PM for me :) [19:13:53] <_joe_> (the meeting, I mean) [19:30:42] marktraceur: The UI/UX column here is a place to start looking -- https://phabricator.wikimedia.org/tag/mediawiki-extensions-oauth/board/ [19:31:01] OK! [19:31:22] I'll cherry-pick some of these over to the api-team board [19:31:42] The epic is at https://phabricator.wikimedia.org/T86869 [19:31:45] bd808: If you're already on it, I'm going to start with investigating https://phabricator.wikimedia.org/T91825 at least, probably be able to do something about it [19:32:08] Sounds good to me [19:35:18] bd808: Do we have a "Blocked-on-MediaWiki-API-Team" thing in Phab yet? [19:35:34] I don't think there is yet, no [19:36:05] That was on my list for all the new teams but hasn't been done [19:36:19] When we do, will it be named exactly that? Or something slightly different? [19:36:36] I think that would be the current naming convention [19:36:53] The SoS board has gotten a bit wacky honestly [19:37:08] There are tags and columns [19:37:20] that purport to describe the same thing [19:37:32] but which are of course managed independently [19:37:32] anomie: If I were going to test E:OAuth locally, is there an app that I can use that's easy to test all the features with? [19:38:02] marktraceur: You can pull code from the oauth-hello-world project on labs and modify to point to your local machine [19:38:06] Neat. [19:38:23] Maybe that should get squished into the mw-vagrant role [19:38:47] setting up a test consumer app [19:39:18] bd808 or anyone else: Any objection before I file a task and patch to have wikibugs spam this channel with MediaWiki-API-Team tasks like it already does for MediaWiki-Core-Team? [19:39:30] works for me [19:39:59] looks like we are spamming -dev right now via the default rule [19:43:22] Doesn't MediaWiki-anything go to -dev anyway? [19:45:00] it should yes [19:45:55] 6MediaWiki-API-Team, 10MediaWiki-API, 5Patch-For-Review: Clean up core API data formats for new formatversion - https://phabricator.wikimedia.org/T87053#1164266 (10Anomie) [19:46:13] tgr: If you got excited about looking at a backend oauth issue, I think https://phabricator.wikimedia.org/T74469 is our top external ask. We need to at least try to find a solid reproduction case for it so we ca start diving into what's going wrong with auto-creation (presumably) [19:46:39] 6MediaWiki-API-Team, 10MediaWiki-API, 5Patch-For-Review: let list=logevents use the new LogFormatter to format its output - https://phabricator.wikimedia.org/T35235#1164277 (10Anomie) [19:46:40] also, lol: https://phabricator.wikimedia.org/T94471#1164243 [19:47:08] 6MediaWiki-API-Team, 10MediaWiki-API, 5Patch-For-Review: API: Add jsconfigvars to action=parse - https://phabricator.wikimedia.org/T67015#1164279 (10Anomie) [19:47:39] 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#1164282 (10Anomie) [19:47:54] 6MediaWiki-API-Team, 5Patch-For-Review: Have wikibugs spam #mediawiki-core with MediaWiki-API-Team tasks - https://phabricator.wikimedia.org/T94471#1164285 (10Legoktm) 5Open>3Resolved a:3Legoktm [12:45:55] !log tools.wikibugs Updated channels.yaml to: b2c38567b32d82881baab5c3227f14a9b8e9fff5 S... [19:48:08] 6MediaWiki-API-Team, 10MediaWiki-API, 5Patch-For-Review: Clean up ApiResult and ApiFormatXml, create new formatversion - https://phabricator.wikimedia.org/T76728#1164289 (10Anomie) [19:48:17] 6MediaWiki-API-Team, 5Patch-For-Review: Have wikibugs spam #mediawiki-core with MediaWiki-API-Team tasks - https://phabricator.wikimedia.org/T94471#1164291 (10Legoktm) For the record, the channel is `#mediawiki-core`. [19:48:33] 6MediaWiki-API-Team, 5Patch-For-Review: Have wikibugs spam #mediawiki-core with MediaWiki-API-Team tasks - https://phabricator.wikimedia.org/T94471#1164294 (10Legoktm) a:5Legoktm>3Anomie [19:49:19] Yay, bugspam! [19:49:41] 6MediaWiki-API-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: Back-fill log entries from GlobalRenameQueue renames that promoted to a global account - https://phabricator.wikimedia.org/T93214#1164296 (10Legoktm) [19:50:10] 6MediaWiki-API-Team, 10MediaWiki-API, 10MediaWiki-extensions-ApiSandbox: Merge ApiSandbox extension into core - https://phabricator.wikimedia.org/T89386#1164298 (10Anomie) [19:51:12] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: OAuth: Authorisation should not fail because you don't have an account on central wiki - https://phabricator.wikimedia.org/T74469#1164304 (10Tgr) a:3Tgr [19:53:42] 6MediaWiki-API-Team, 10MediaWiki-API, 10MediaWiki-extensions-ApiSandbox: Merge ApiSandbox extension into core - https://phabricator.wikimedia.org/T89386#1164307 (10Anomie) [19:54:16] 6MediaWiki-API-Team, 10MediaWiki-API, 10MediaWiki-extensions-ApiSandbox: Merge ApiSandbox extension into core - https://phabricator.wikimedia.org/T89386#1035105 (10Anomie) This isn't technically blocked by T92893, but since I'm using oojs-ui to do the major rewrite it may as well be. [19:55:27] 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#1164319 [19:55:28] tgr: The other thing that would be great to have you look into is the metrics side of https://phabricator.wikimedia.org/T91701 [19:56:55] marktraceur: I think the biggest WTF was " would like to have basic access on your behalf" [19:57:28] Even having read the list of permissions, I'm not sure what "basic access" really means to be honest [19:57:52] bd808: Traditionally, have you been the one who has gone through the Done column and marked tasks Resolved? [19:58:24] Sort of. I've been doing that after the team meeting for the last couple of months [19:58:26] bd808: "basic access" is stuff like 'read' that you need to access the wiki at all, plus random other stuff that "we" (sarcastic) didn't think needed explicit granting. [19:58:36] and then dragging everything to the hidden archive column [19:59:54] anomie: yeah, but the words are not very descriptive :/ "read pages" might be better but like you said there are other rights lumped in there [20:01:07] bd808: Ok. Beware that something could be in our done column but not be ready to be resolved because it still requires actions from another team (like getting deployed) [20:01:12] 6MediaWiki-Core-Team, 10SUL-Finalization: Run MassMessage to contact user talk pages of all affected accounts - https://phabricator.wikimedia.org/T90820#1164340 (10Keegan) 5Open>3Resolved [20:01:40] bd808: I see https://phabricator.wikimedia.org/T69082 has more information about it, yeah [20:01:46] I'm working on that one now [20:02:11] bd808: Full list: autoconfirmed, autopatrol, autoreview, editsemiprotected, ipblock-exempt, nominornewtalk, patrolmarks, proxyunbannable, purge, read, skipcaptcha, torunblocked, unblockself, writeapi. [20:02:20] Does it basically boil down to read and write pages? [20:02:30] No, writing pages is separate. [20:02:44] ah. "writeapi" sounds like write pages [20:03:12] "writeapi" is the ability to use API calls that write the database, but you still need "edit" or whatever to actually write stuff. [20:04:03] *nod* I think this is where the confusion starts to be confusing to us mortals who have no idea what the individual rights really mean [20:04:40] * anomie points to https://en.wikipedia.org/wiki/Special:OAuth/grants in case that hepls [20:04:54] That's what I'm reading :) [20:05:04] anomie: err, we give everyone torunblocked? [20:05:38] legoktm: For OAuth, "granting" a right just means the client can make use of the right if your account already has it [20:05:40] so that part is confusing too. No, we did not, but if you have that right then the oauth app inherits it [20:05:43] ah [20:05:43] ok [20:05:56] But if you lack say 'delete', granting the app "delete" doesn't mean it suddenly can. [20:06:25] right [20:06:55] I think we need descriptions for humans more like these -- https://developer.github.com/v3/oauth/#scopes [20:07:43] I think our "basic access" corresponds roughly to github's "(no scope)" [20:07:55] That's what the descriptions on the "grants" are intended to be, and mere mortals aren't supposed to have to care about the specific rights. [20:08:32] * anomie calls "not it" on figuring out how to reword grant descriptions [20:09:18] This is the screen shot of one confusing thing -- https://phab.wmfusercontent.org/file/data/odh5fexlsdt3ak5chrlr/PHID-FILE-yl2fmbw6ioyavfkawflr/iwnb4kxrkvzyzsjf/Screenshot_from_2014-10-09_18%3A32%3A24.png [20:09:51] somewhere I have an equivalent screen shot for github and it is much more clear [20:09:56] * bd808 tries to find that [20:10:14] it's made more confusing by phabricator files being unshareable [20:10:17] ^ [20:10:28] heh [20:10:36] Click "continue" and you see the screenshot. Or at least I did. [20:10:43] In the body of https://phabricator.wikimedia.org/T598 [20:10:50] oh that's silly [20:11:07] BTW, Phab's OAuth-to-MediaWiki could use T88757 once that gets merged and deployed, which might make things less confusing. [20:13:17] "basic access" basically means that the app can tell who you are, right? [20:13:37] and read pages you can read [20:13:40] I think [20:13:43] tgr: Also that it can read pages and a few other basic things. [20:14:43] well yeah, but it can do that anyway as long as the wiki is not private [20:15:07] With only "basic access", you can read public pages, purge pages, and skip captchas if somehow you were to manage to see one without being able to edit. And be not-blocked if your account has ipblock-exempt or torunblocked. [20:15:54] my point is, from the user's point of view these are not really meaningful rights [20:15:56] The rest of the stuff in "basic access" looks to be useless without additional grants, e.g. "editsemiprotected" is useless without "edit" I believe. [20:16:40] the user is going to ask, what am I authorizing this application to do that it couldn't do if I did not click OK? [20:16:57] bd808: It's not even "read pages you can read", since it'll lack the rights for viewing deleted pages. [20:17:05] for basic rights, that's pretty much to tell who you are logged in as and what your email address is [20:17:32] anomie: Are you working on this or just musing? [20:17:35] tgr: Can't get your email, actually. That needs the 'viewmyprivateinfo' right. [20:18:00] marktraceur: Answering questions, since I'm one of the three that worked on OAuth the first time around. [20:19:16] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: OAuth permission screen needs redesign for better usability and comprehension - https://phabricator.wikimedia.org/T75062#1164426 (10bd808) As a random comparison, here's what github's authorization screen looks like when travis-ci asks to access your account:... [20:23:49] Right [20:25:57] 6MediaWiki-API-Team, 6Collaboration-Team, 10MediaWiki-extensions-Renameuser, 10SUL-Finalization, and 3 others: Move more log types to new user name when renaming a user (for example thanks logs) - https://phabricator.wikimedia.org/T78575#1164472 (10Legoktm) a:3Legoktm [20:26:46] bd808: can we call the "Ready" column "Next"? since that's what CI and a few other workboards call it, or does this have a different meaning? [20:27:06] works for me [20:27:07] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Only show grants that the user has permission to use, to avoid confusion - https://phabricator.wikimedia.org/T94478#1164494 (10MarkTraceur) 3NEW a:3MarkTraceur [20:27:43] "next" would imply a grooming meeting we haven't had but really so does "ready" [20:27:45] Does the column really mean "we're going to do this next"? If so, "Next" is fine with me if you want. [20:27:56] If not... I'd say no. [20:28:03] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Message describing OAuth activities is confusing to end user (in context of Wikidata Game) - https://phabricator.wikimedia.org/T69082#1164512 (10MarkTraceur) > Martha has at this point never heard the name "Widar" before, and will probably never hear it again.... [20:29:13] such good process questions to discuss with our TPG liaison :) meeple27 ^ [20:30:23] If we were doing a grooming meeting I (wearing PM hat) would expect to drag some things over and then have the team say "looks good", "we can do more" or "hell no that's one is not ready" [20:31:36] at the end of the meeting the column would be the things that the team actually thought they could accomplish by the end of the iteration (however long that may be) [20:33:11] 6MediaWiki-API-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: Code review CentralAuth's GlobalUserMerge and related UserMerge code before SUL finalization mass usage - https://phabricator.wikimedia.org/T961#1164527 (10Legoktm) [20:33:12] 6MediaWiki-API-Team, 6Collaboration-Team, 10Echo, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: "User must be logged in to view notification!" exception during global merge - https://phabricator.wikimedia.org/T78423#1164529 (10Legoktm) [20:33:14] 6MediaWiki-API-Team, 10SUL-Finalization, 10Wikimedia-General-or-Unknown: Invalid usernames on Wikimedia web sites - https://phabricator.wikimedia.org/T5507#1164533 (10Legoktm) [20:33:16] 6MediaWiki-API-Team, 6CA-team, 6Commons, 10SUL-Finalization, 6operations: db1068 (s4/commonswiki slave) is missing data about at least 6 users - https://phabricator.wikimedia.org/T91920#1164532 (10Legoktm) [20:33:17] 6MediaWiki-API-Team, 10MassMessage, 10SUL-Finalization: MassMessage sent twice to local user talk - https://phabricator.wikimedia.org/T93049#1164531 (10Legoktm) [20:34:03] * anomie organized the MediaWiki-API tag as "Someone needs to figure out WTF to do here" versus "We know WTF to do, someone needs to do it", plus "blocked" and a few variations of "not it" [20:34:36] 6MediaWiki-API-Team, 10MediaWiki-Configuration: Support "ResourceModuleSkinStyles" in ExtensionProcessor - https://phabricator.wikimedia.org/T91566#1164542 (10Legoktm) [20:34:37] 6MediaWiki-API-Team, 10Librarization, 5Patch-For-Review, 7Upstream: Composer autoloader is slow - https://phabricator.wikimedia.org/T85182#1164540 (10Legoktm) [20:34:38] 6MediaWiki-API-Team, 10MassMessage, 5Patch-For-Review, 7Wikimedia-log-errors: Invalid parameter for message "logentry-massmessage-failure" - https://phabricator.wikimedia.org/T93110#1164541 (10Legoktm) [20:34:39] 6MediaWiki-API-Team, 10GlobalUserPage: Wikilinks from global user pages should point to the central wiki - https://phabricator.wikimedia.org/T89916#1164543 (10Legoktm) [20:34:41] 6MediaWiki-API-Team, 10Librarization: Move includes/password into includes/libs (library-ify) - https://phabricator.wikimedia.org/T89742#1164546 (10Legoktm) [20:35:06] yay for batch edit [20:37:02] 6MediaWiki-API-Team, 10Librarization, 10utfnormal, 5MW-1.25-release, 5Patch-For-Review: Bring in utfnormal library with composer and create backwards-compat layer - https://phabricator.wikimedia.org/T90825#1164547 (10Legoktm) a:3Legoktm [20:37:27] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Only show grants that the user has permission to use, to avoid confusion - https://phabricator.wikimedia.org/T94478#1164550 (10Anomie) Chris could correct me here, but I expect a requirement then is that the app wouldn't even be granted the grants they hadn't... [20:44:22] 6MediaWiki-Core-Team, 7Epic: Audit and fix extensions that call saveSettings() to lazy-set preferences when loaded - https://phabricator.wikimedia.org/T94480#1164598 (10aaron) 3NEW a:3aaron [20:44:26] 6MediaWiki-Core-Team, 10CirrusSearch, 10Wikimedia-Site-requests, 7Easy: Remove "this wiki is using a new search" - https://phabricator.wikimedia.org/T77920#1164605 (10Legoktm) [20:45:06] 6MediaWiki-API-Team, 6Engineering-Community, 10Wikimedia-General-or-Unknown, 7Epic: Central Code Repository for code used on wikis (Templates, Lua modules, Gadgets) - https://phabricator.wikimedia.org/T1238#1164626 (10Legoktm) [20:45:21] Are we going to be talking about world domination in the meeting today or can I stay outside for it [20:45:25] It's so bearable outside [20:45:34] 6MediaWiki-Core-Team: [Bug 71773] Get rid of lazy-loading of unattached accounts from CentralAuth - https://phabricator.wikimedia.org/T744#1164634 (10Legoktm) [20:45:50] 6MediaWiki-API-Team, 10MediaWiki-extensions-CentralAuth: Get rid of lazy-loading of unattached accounts from CentralAuth - https://phabricator.wikimedia.org/T73773#763005 (10Legoktm) [20:46:12] 6MediaWiki-Core-Team: [Bug 70851] Global renames should leave local log entries on affected wikis - https://phabricator.wikimedia.org/T740#1164643 (10Legoktm) [20:46:13] 6MediaWiki-Core-Team, 10MediaWiki-extensions-CentralAuth, 5Patch-For-Review: Global renames should leave local log entries on affected wikis - https://phabricator.wikimedia.org/T72851#1164644 (10Legoktm) [20:46:27] 6MediaWiki-Core-Team: [Bug 70623] Add ajax check for name availability to Special:GlobalRenameRequest - https://phabricator.wikimedia.org/T739#1164646 (10Legoktm) [20:46:53] marktraceur: I was thinking about meeting from my deck as well [20:47:13] Deck party for the remoties! [20:47:18] * marktraceur fetches headset [20:47:37] It's ~24C here with a nice breeze [20:47:52] * bd808 converted that on google just for marktraceur [20:48:12] Yay [20:48:16] But also damn, it's 13 here [20:48:28] * marktraceur looks impatiently at the calendar [20:48:33] 4 days 'til I can drive that way. [20:49:01] West of the Rockies is had the warmest winter on record in most places I pay attention to [20:49:20] It's going to be a nasty fire season in Idaho [20:50:27] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Only show grants that the user has permission to use, to avoid confusion - https://phabricator.wikimedia.org/T94478#1164659 (10MarkTraceur) @Anomie I wasn't sure if there was a database of rights that had actually been granted, or if it was just a switch "this... [20:50:43] bd808: I'm thinking of skipping today's core meeting, do you want me there? [20:50:58] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Only show grants that the user has permission to use, to avoid confusion - https://phabricator.wikimedia.org/T94478#1164662 (10MarkTraceur) If the latter then there are schema changes to make and I should unassign myself as a pedestrian database person at best. [20:51:23] greg-g: skip away. Do you have any escalation things for us? [20:51:46] nothing I know about [20:52:08] cool beans [20:55:21] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Only show grants that the user has permission to use, to avoid confusion - https://phabricator.wikimedia.org/T94478#1164676 (10Anomie) `oauth_accepted_consumer` column `oaac_grants` holds the grants that were actually accepted.