[00:02:24] No, there's task for dumping the contents on-wiki too. [00:02:40] T188407 [00:02:41] T188407: Document clear method for users to access historical data from the education extension - https://phabricator.wikimedia.org/T188407 [00:03:01] But of course with no proper owner there's no-one to allow us to Decline. [00:04:41] Not that any of that is helped by the "abstraction" the extension actually does to display anything [00:06:52] I wonder if html dumping it would just be the easiest way here too [00:10:13] does that normally stop us from declining something? [00:10:55] We could do with the extension being broken in a way that it can't be fixed without a load of effort [00:10:58] Then just undeploy it [00:11:00] problem solved [00:12:28] can't be too difficult to make the case that it's already 'broken' [00:13:22] It's how you deal with the couple of very vocal users that think it's very important [00:17:03] Or can we just get the wayback machine to archive it for us? :P [00:20:50] -- This is somewhat based on the (core) revision table and is meant to serve [00:20:50] -- as a prototype for a more general system to store this kind of data in a visioned fashion. [00:20:50] CREATE TABLE IF NOT EXISTS /*_*/ep_revisions ( [00:20:51] much lols [00:23:19] a visioned fashion [00:24:01] I wonder what really should be done in this situation [00:24:22] The fact the replacement didn't/wouldn't budget for import/export is mindboggling [00:24:31] Surely it's their fault/problem, not everyone elses [00:24:57] I'd like to say try telling that to the people complaining to you about it [00:25:14] heh [00:25:15] But I know that wouldn't actually work so [00:25:28] It's not our fault that no one cares enough to work on it [00:26:53] could set a deadline [00:27:17] extract all data still needed, or convince project to fund a proper export/import, before x [00:27:32] https://phabricator.wikimedia.org/T125618#4006817 [00:27:49] and change the line that includes the extension to only run if date is less than x [00:28:40] https://lists.wikimedia.org/pipermail/education/2018-February/thread.html [00:28:56] https://phabricator.wikimedia.org/T188407#4456497 [00:29:02] "I proposed a migration plan (both last year, and this year) for importing that data to Programs & Events Dashboard, but the Education team did not have the budget for it." [00:29:05] That says it all [00:29:12] The people who should care about it, apparently don't [00:30:18] https://outreach.wikimedia.org/wiki/Education/News/January_2018/Education_Extension_scheduled_shutdown [00:30:23] "Summary: The Education Extension will be shut down by June 2018." [00:30:26] Part of me is like JFDI [00:30:34] yeah [00:30:45] if it were up to me I'd get rid of it [00:30:53] James_F: Thoughts? :P [00:31:19] I don’t even know who at WMF to ask. [00:31:38] https://www.mediawiki.org/wiki/User:VMasrour_(WMF) ? [00:33:13] this is the person who wrote 'Summary: The Education Extension will be shut down by June 2018.' ? [00:33:17] just get rid of it [00:33:35] they even said 'On June 30, 2018, the Education Extension will be shut down.' - it's long past time [00:33:54] It was authored in January [00:33:57] So that's like 5 months notice [00:34:14] not to mention this has been obvious for a lot longer than that [00:34:22] Yeah. [00:34:45] I definitely want to make sure the sql dumps are at least available before turning it off [00:35:01] are they in the replicas? [00:35:14] They are, but apparently that's "too hard" or something [00:35:30] you don't sound convinced by that argument [00:35:38] :) [00:35:46] Reedy: James_F: I talked with Ben at the airport post-Wikimania, and he was pretty confident that it was OK to just turn it off [00:35:56] "lego said to do it" [00:35:57] so why are you trying to appease it? [00:36:35] OK, if we’ve got the DB dumps somewhere let’s just do it. [00:36:57] They're dumped, I need to look over them, then get them onto the dumps server [00:37:12] Job for post sleep IMHO [00:37:12] how much data are we actually talking here? [00:37:16] yes :) [00:37:48] Can we get it in writing on one of the tasks that it's goot to turn it off? :P [00:38:49] who do you need it in writing from? [00:39:10] Whoever Ben is? :P [00:39:29] Rather than just "lego said that Ben said..." [00:40:13] Reedy: https://phabricator.wikimedia.org/T125618#4449413 [00:40:36] <3 [00:40:38] "or publishing them somewhere so that anyone can easily find them and analyze them." [00:40:51] That to me seems to suggest publish the dumps and then they can do what they awnt [00:40:58] Maybe we make GCI tasks to display the data :P [00:41:14] you could argue the replicas fulfill that one [00:41:18] Actually [00:41:19] https://phabricator.wikimedia.org/T125618#4476712 [00:41:23] Vjotech hasn't even replied [00:41:34] Nearly 2 months [00:41:50] Right, that's enough for me. I will be JFDI-ing it this week [00:41:55] It feels to me like this process has become far more drawn-out than it should've been allowed to become [00:42:06] Yup [00:46:34] I'll followup with SRE when I've slept to get them somewhere I can access (if they're not there already after leaving a comment) [00:47:25] Very exciting [00:53:06] Oh, there's this too [00:53:07] https://phabricator.wikimedia.org/T200391 [00:53:27] The ever present question of what we do about log entries [00:53:32] And potentially orphaned talk pages [00:56:37] Ah [00:56:41] Would be useful to get https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/448998/ merged [00:57:31] (maintenance script to empty out a user group_ [00:57:32] ) [02:38:11] Anyone use the MW debug toolbar? Could use feedback on https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/460613/ [04:34:50] bd808: Did a WikimediaDebug for the first in a long time (v2.0.0). Documented the process I used at https://github.com/wikimedia/WikimediaDebug#readme. Let me know what you think :) [12:26:42] Krenair: There's ~330M of data from EP [13:33:54] anomie: found an issue that seems somehow related to the new getQueryInfo code https://phabricator.wikimedia.org/T205432 [13:34:01] Error: 1054 Unknown column 'rc_actor' in 'on clause' (10.192.48.9) [13:34:07] Error: 1054 Unknown column 'actor_rev_user.actor_user' in 'on clause' (10.192.32.110) [13:34:45] Looking at Special:ActiveUsers now [13:35:27] DanielK_WMDE_: Are those current exceptions, or are they from last week before the actor migration stuff was turned back off? [13:36:07] DanielK_WMDE_: ActiveUsers is probably a duplicate of T204767. [13:36:08] T204767: Special:ActiveUsers fails with "Error: 1054 Unknown column 'rc_actor' in 'on clause' (10.192.32.110)" - https://phabricator.wikimedia.org/T204767 [13:36:25] DanielK_WMDE_: PageTriage is probably a duplicate of T204764. [13:36:26] T204764: DB error in PageTriage: Unknown column 'actor_rev_user.actor_user' in 'on clause' - https://phabricator.wikimedia.org/T204764 [13:36:38] anomie: i was looking at the last 7 days, so might be old. checking... [13:37:54] anomie: nothing in the last 24 hours [13:38:14] but nothign much happens on testwiki... [13:42:30] anomie: i tried hitting the relevant urls to see if i can trigger the error. i don't see it in the logs, so i guess it's fixed [13:44:23] anomie: when was the "actor stuff" enabled and disabled on testwiki? i don't find anything obvious in SAL [13:46:00] DanielK_WMDE_: Search for "ActorTableSchemaMigrationStage". Deployed 2018-09-17 at 16:18, reverted 2018-09-18 at 20:58. [13:50:05] found it, thanks. closing the ticket [14:22:19] anomie: SlotRoleHandler is ready for review. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/434544 [14:23:34] I'm not totally happy with the interface, mostly because too many things depend on the title. We had this discussion in Barcelona. But I'm ok with it as a compromise. Encapsulating most legacy behavior in a MainSlotRoleHandler feels right [14:54:09] James_F: https://dumps.wikimedia.org/other/educationprogram/ [14:54:28] Yay. [14:56:20] * Reedy turns off EP everywhere [14:56:47] James_F: Don't suppose I can get you to merge https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/448998/ ? [14:57:06] Reviewing it now [14:58:36] Reedy: thanks! [14:59:10] Reedy: Seen Niklas's comment? [14:59:19] I did... But didn't really understand it [14:59:37] And looked at many other maintenance scripts, only the minority seem to have a second parameter [15:01:07] 'msg' IIRC [15:03:31] Yeah. [15:03:37] I didn't either. [15:05:16] Reedy: Merged. [15:05:39] (Note that the train's already been cut if you wanted to use that this week.) [15:06:14] That's why I asked originally last night ;P [15:06:23] I can cherry pick it if we decide to fully undeploy this week [15:06:46] Sure. [15:07:00] Frankly we *have* fully undeployed DisableAccount. ;-) [15:07:30] I was meaning for EP usage [15:07:52] because of it's many user groups [15:10:13] Yeah. [15:11:07] Do need to decide what to do about the inactive group, for sure, but not really urgent [15:12:10] Aka "it doesn't affect the English Wikipedia, so people won't be screaming their heads off and making death threats about a minor annoyance". [15:12:15] lol [15:12:44] Have to poke people in the various private wikis to find out if they're actively using it [15:12:48] pun unintended [15:12:49] Sure. [15:14:37] It's gone [15:14:46] Yay. [15:15:42] Krinkle: thanks for the doc refresh on the debug add-on! [15:16:44] How long for people to notice? [15:17:11] Minutes, I imagine. [15:17:18] Krinkle: +1 to bd808's comments, thanks. [15:22:12] Now down to 178 extensions in prod, plus 8 skins. And Zero{Banner|Portal} will be going soon. [15:22:31] Heh [15:22:59] I suspect it's worth poking Dan in the near future to find out actual dates agreements expire [15:24:02] Last time I looked there were quite a few still active [15:24:21] Yeah, it's not happening this month, don't get too excited. [15:24:44] January 1st, 2019 is JFDI day for Zero [16:20:23] That's much sooner than I dared hoping! [16:21:16] (Added benefits of contracts pinned to the solar year: there's actually something to celebrate on Januari 1st.) [16:21:34] "The Wikipedia Zero program will end in 2018" [16:21:42] Therefore, 2019 is fair game [16:22:06] Ah, in that sense. I guess it's good enough for the celebrations. :) [16:31:51] DanielK_WMDE_: Hm.. regarding revision magic words, for stashing, what we did is to be predictive and if we get it wrong, re-parse afterwards. [16:32:30] DanielK_WMDE_: I guess the only problem with that for the actual save is if the revision row depends on something PST does, which I thought wasn't the case, but then I realised rev_len most certainly is dependent on that, right? [16:32:34] Anything else though? [16:35:18] Krinkle: PST handles subst, which doesn't use the predictive revision ID. we could have a predictive page id as well, but using it with subst would be dangerous. [16:35:46] the wikibase uswe case needs the *definite* page ID before the content blob is written to the db. ...or it needs to inject it on load [16:36:35] DanielK_WMDE_: Do we or do we not support {{subst:}} right now for REVISIONID and PAGEID in a way that will end up saving wikitext based on those magic words having been their real values? [16:37:19] we don't. [16:37:23] it'S empty [16:37:33] OK. Then I strongly we *never* support it. [16:37:37] suggest* [16:37:56] Self-identification can use the magic words at runtime, why through subst? [16:39:35] well, wikibase entity data needs to contain the id. we can't just inject it during rendering, because we also expose the data without rendering it [16:39:46] but yes, the id can still be injected [16:39:54] the current code just makes this hard. [16:42:36] James_F: https://phabricator.wikimedia.org/T188407#4615854 [16:43:27] Reedy: *sighs* [16:43:50] Noting they've not replied in 7 weeks to the last question for them... [16:44:37] DanielK_WMDE_: Not sure I follow. Are you saying the native content for a wikidata entity page revision wants to have a property that contains the revision/page ID of itself? [16:45:02] That seems odd to me. Certainly any MW-specific API exporting the data can wrap it to provide those meta data out of bound? [16:45:13] Why does it need to appear as if it was part of the content? [16:46:00] Given this isn't the case today, and given it adds an imho very significant complexity on how MW works, I don't think we can justify it for any use case. But I might think differently if I understand it better :) [16:50:02] James_F: Troll response is to link to https://dumps.wikimedia.org/other/educationprogram/arwiki.educationprogram.20180919.tar.gz [16:50:35] Reedy: You think I should respond to their response to me by repeating my link? [16:50:50] I'm honestly not sure what we should do here [16:50:55] They've had ~9 months notice [16:51:04] It's basically ~3 months after we said it should be removed [16:51:06] With a big shouty banner, from what I saw. [16:51:08] Krinkle: it's for MediaInfo. MediaInfoIds are defined to be "M" . $pageIdOfFIleDescriptionPage. This allows the meta-data to be looked up using a stable identifier that doesn't breakl when the file is renamed. This works very nicely, except when creating the very first revision of the file description page. [16:52:01] Krinkle: but conceptually, this isn't a problem. we can just inject the ID when we load the MediaInfoContent. It's just a problem in practice, because there currently is no good way to make the page ID known to the relevant code. [16:53:09] Hmm so it's about the page title about a secondary page we want to create at the same time as the file page with the file page id in the secondary pages title [16:54:09] Krinkle: not a secondary page. that'S how the mediainfo proof-of-concept works. but with mcr, mediainfo will live in a slot of the file page itself [16:54:11] Two thoughts: A) file page ids are not file ids. We approved an RFC to add file ids. B) i can't help but think, we just told Jade not to use page ids in titles [16:55:02] The current standard is to instead have different pages keep their name in sync, as for related pages in other name spaces. Not pretty, I know. [16:55:23] Krinkle: having proper file ids would be nicer. but if you want to block SDC on introducing that, it's a bit late now to plan for that. [16:55:36] Okay, mcr Sounds good [16:55:53] What is the non mcr mode for? [16:56:02] we can base mediainfo IDs on proper file IDs in the future, but we'd have to use a suffic or prefix to distinguish old-style ids from new-style ids [16:56:16] non-mcr mode was for testing and development before we had mcr :) [16:56:24] i wrote that nearly two years ago... [16:56:56] Okay. I assume it's not controversial to block SDC on MCR, and that avoids the need to have this title right? [16:57:16] I understand, very sensible. Just being brief. [16:57:27] anyway. we coudl also have auto-increment ids for mediainfo, just like we do for wikidata items. but then we'd have to maintain a mapping to file names. which is a pain. we did that for wikidata initially, and got rid of this because of performance issue4s [16:58:16] so, the situation is: the easiest way to allow stable lookup by a mediainfo id is to have the mediainfo id be the page id. and the serialization of a mediainfo entity should contain its own id. [16:58:54] no problem, except for the instance we need to save the first version of the page. then we don't know the id we need tio pu into the entity data. [16:59:06] Okay, you've lost me again. [16:59:20] that's what started the discussion. but it'S not a huge deal. for now, we can just use a second edit to add the mediainfo slot [16:59:30] Why do we need an M-thing if we use mcr. Why does it need to be in its own content? [16:59:59] Krinkle: sorry, got to go now. i can explain later. but the impartant bit is: there's no blocker and no fundamental problem. just a bit of awkwardness in the code. [17:00:30] Right. But sounds like complexity we could potentially avoid in its entirety [17:00:32] Krinkle: external URIs for the mediainfo. https://commons.wikimedia.org/entity/M12345 [17:00:37] And save future tech debt [17:00:44] Let's talk later [17:00:46] Thanks [17:08:49] greg-g: Any bright ideas what we do for this person complaining about EP being turned off? [17:12:13] :/ [17:41:33] AaronSchulz: hey, I have a question regarding function selectDB( $db ), Does it make sense to add a condition there to change db when it's actually changed ($this->mDBname !== $db) to avoid redundant calls [17:42:00] number of Com_change_db is pretty huge (enwiki says 380031804) [18:35:22] (FN are making some changes, let's see how effective they are) [19:14:59] Krinkle: re: substing and PST, see T194029 [19:15:00] T194029: Prevent substing of {{REVISION*}} - https://phabricator.wikimedia.org/T194029 [21:36:33] Amir1: probably, at some points in the call stack. [21:40:28] ��)�}��+]��L�r��u�֚BF��fL�3�KE�f��~6�6 [21:40:30] '�O:g��Z�t�\�)�D��p(|9�]�d�8\Y��)Yⱛ�lZ�� [21:40:33] �f̚Cے�x��s�P��L(�Q瞫�^_m�t|�eINk�2�u�fZ�� [21:40:35] ��)�_�\�U [21:40:38] �'X��Ի��4��)g*�s,��))��_ׅ_l~Y��k��Ý9. [21:46:40] ty Skizzerz [21:48:28] guess it wasn't wide enough for Sigyn to snipe him [21:51:52] Skizzerz, yeah [21:51:56] they just hit a bunch of other channels as well [21:52:16] so I imagine it's not long before FN boots them for that too [22:15:46] James_F: greg-g: https://phabricator.wikimedia.org/T188407#4617100 good outcome! :) [22:16:06] Success. [22:16:15] Can we mark it as Resolved then? ;-) [22:16:27] heh [22:17:18] Need to decide when I'm gonna undeploy it [22:17:23] Tomorrow is definitely too soon [22:17:38] But maybe thursday is ok [22:17:48] We're not going to be deleting the tables for a little while too [22:17:52] Yeah. [22:18:00] Not until after the switch-back, I assume. [22:18:17] That's probably a good time to re-evaluate [22:19:32] But not branching EP next week would be a nice win [22:29:09] Yeah. [23:07:10] James_F: https://phabricator.wikimedia.org/T74889 [23:07:29] 3.5 years later, the bug is still open after being fixed... [23:51:33] Reedy: :-( [23:51:54] I just cleared up most EP tasks and gerrit changes [23:52:17] I see. GJ.