[00:04:43] by the way, is it possible to request a tag to be inserted on a wiki? I wish I could add a font from Google Fonts this way, instead of using @import on CSS [00:11:40] Hello theburningprince! If you have any questions, feel free to ask and someone should answer soon. [00:13:52] Wikia/FANDOM junk on reception wikis that need to be deleted (my Rotten Websites Wiki and Terrible TV Shows Wiki leftover list was incomplete so this includes a few more leftovers): https://phabricator.miraheze.org/T6891 [00:13:53] [ ⚓ T6891 More Wikia junk to get deleted ] - phabricator.miraheze.org [00:22:54] Command sent from Discord by MarioMario456: [00:22:55] ... [00:48:44] @MarioMario456, thanks. Reception123 should be able to do that first thing in his morning. I've never seen an `.xz` compression format before, though. Higher compression than `.gz`, I gather? [00:58:10] Hi dmehus [00:58:52] hi, BurningPrincess1. Checking DMs [01:02:05] Freenode is dealing with a large number of spammers right now, including dm spam [01:02:23] I see that... [01:05:37] I have set mode +g [01:05:41] Or is it +G [01:05:56] +R [01:06:12] Prevents unregistered users from DMing you [01:14:08] +R is set by default on new connections according to FN staff for the time being [01:46:59] xz is a standard Linux compression format [01:47:08] on ubuntu, xz is installed by default [01:47:51] @MarioMario456, ah, ok. Yeah, gz used to be standard. Guess I'm a bit out of date. :P [01:48:42] i've not heard that before [01:49:27] i thought zip was the standard [01:49:57] for windows machines its pretty standard, but for unix I thought it was .gz [01:50:52] Zppix, ah, yeah, same [02:01:19] Same actually. [05:01:59] Yes, but does not the CSS extension already support that? [05:02:48] no the link should be in the [05:03:24] and @import done by CSS makes an http request so if I insert two fonts, would make two different (unnecessary) http requests [05:04:07] Oh, where did the extension end up rendering? [05:05:31] doing with extension CSS will only apply to the page the {{#css: is, on Common.css will apply to all pages, but still makes the request [05:51:17] So if I am understanding you correctly, basically, you want a to be rendered on every page. Is that correct, @Lake? [05:51:35] I think @Imports have to be approved [05:51:39] i think [05:51:42] i cant remember [05:52:16] Because of the CSP? [05:52:24] I cant recall if @import uses CSP [05:52:28] but i think it does [05:53:16] regardless if it does require CSP changes SRE would have to approve [05:54:00] I think Google Fonts can be approved if it has not already been. [05:54:05] It is widely used. [05:58:14] google fonts is probably already on CSP [05:58:19] let me look [05:59:06] url16: '*.google.com' [05:59:06] url17: '*.gstatic.com' [05:59:10] you should be good [06:10:57] I believe you need to use fonts.googleapis.com for Google Fonts. [06:54:40] @import does need approval because CSP [06:55:05] and google fonts are fine because googgleapis is approved iirc [11:31:24] I now got this error, even after directly importing Module:Arguments: Lua error in Module:Arguments at line 33: attempt to index a boolean value. Is that a problem with the module itself? If so, how can I fix it? [11:42:34] link? [11:47:28] Link to article proof: https://princesspictures.miraheze.org/wiki/SilverCity [11:47:28] [ SilverCity - Princess Pictures Wiki ] - princesspictures.miraheze.org [11:48:14] Link to module: https://princesspictures.miraheze.org/w/index.php?title=Module:Arguments&action=edit#mw-ce-l33 [11:48:16] [ View source for Module:Arguments - Princess Pictures Wiki ] - princesspictures.miraheze.org [11:51:50] i dont see any errors? [12:20:44] when is the next extension bump so I can get https://github.com/octfx/wiki-seo/commit/9135f129a67c3569760a187aa81d73743018f113 in managewiki? :-p [12:20:45] [ Add Naver site verification · octfx/wiki-seo@9135f12 · GitHub ] - github.com [12:34:39] i think dependabot runs every monday [12:54:00] I remember either Universal_Omega or paladox saying it is once per month now. [12:54:52] thats painful [12:55:03] :thistbh: [13:23:56] revi done [13:24:25] thx [13:24:39] (and monthly is definitely uh if true) [13:25:20] also wasn't me who said once per month [13:25:37] it was every monday at one point [13:27:09] Yes? I mean, tags are supposed to be in every page [13:27:15] unless you're making a static website [15:51:40] @R4356th and Zppix: it was me. Changed to once per month because once per week was causing issues. Some updates were unstable and therefore causing fatal errors, some of which took hours to discover. Therefore we did once a month to see how that works and if it works better we will keep it, otherwise will go back to per-week. [15:52:41] could do biweekly or something monthly just seems too long [15:54:35] Zppix: I looked at bi-weekly it seems it wasn't an option for dependabot. [15:55:18] so weekly or monthly are basically the options thats a oversight [16:08:52] I do agree with Zppix that monthly extension updates are too infrequent. A better solution would be to either (a) retain the weekly frequency, opting instead to merge the the updates much more slowly after several days and robust testing or (b) move to biweekly [16:12:21] wouldn't be better to classify each extension in a priority list? [16:12:45] there are extensions that are updated very frequently, but others take a lot of time to update [16:13:04] It’s quite ironic increasing to monthly to reduce errors is more likely to increase it because there would be more to review so less likely to get proper reviews [16:15:38] 💯 [16:16:12] JohnLewis, I see the irony. Good point. I don't really see decreasing our update frequency as the solution here; solution seems to be more a robust testing regime [16:18:48] dmehus: robust testing is hard [16:19:01] We can't unfortunately get MediaWiki to set itself up right [16:21:44] Creating a full CI suite is just not feasible for even testing - testing pre deployment is the solution not pre-merge. Only way to have robust CI is to create our own infrastructure that is more suited than free options [16:36:39] JohnLewis, to be clear, I wasn't meaning having a robust CI suite. I just meant creating like a 50 point inspection checklist for MWEs to follow when testing new extension updates [16:37:32] because defining all the rules for a CI to follow would be quite difficult, and it wouldn't necessarily be any better than manual testing [16:59:27] The '50 point checklist' is simply, "does it work?" no point creating a checklist for every extension because that would require more time than would spent testing it for that once in a blue moon update which only touches an i18n file [17:01:43] yeah, some of them are extremely minor updates [18:39:40] @R4356th, JohnLewis, and dmehus: the monthly updates were just a test to see how it'll work. If it doesn't, it will be reverted to weekly. We used to not do them all via dependabot. I see monthly as better then only at core upgrades. But I see your point. Likely will change back to weekly after this month. Reception123: thoughts? JohnLewis: the point was to not have to do that so frequently. When they were weekly, quite often [18:39:40] by the time we were done with previous week upgrades, next week's were added, and then we never end up getting to some of them, and reviewing was quite hard regardless, if that makes sense. Less frequently in my opinion, makes it more stable, and gives more time to review and deploy them all. [18:40:50] Yeah, I did initially agree to the change as I thought it made more sense than having them every week and having tons of mediawiki PRs to review [18:41:01] and of course there were some "incidents" [18:41:33] I didn't realize what John says, that making it monthly would mean even more to review [18:42:08] Yeah. Before there was times we had 99 PRs to review in a week. That's to much in a week [18:42:33] Monthly may have more to do but more time to do them. [18:56:48] > I see monthly as better then only at core upgrades. Yes, you just reminded me that there have been core "cherry-picked" updates which some users might find helpful. [18:57:50] But I do not believe they are usually pulled? [19:00:33] @R4356th: what do you mean? Do you mean mediawiki core updates or extension backports? If you mean core, we update that when the version is bumped (ie 1.35.0 to 1.35.1) as my point was before extensions were done weekly, they were only done when we update from a major core version to newest stable (1.34 to 1.35 for example) monthly like now is still better then that. But yeah after this month they may go back to weekly I guess. [19:11:19] Universal_Omega: I think we also might have to have a review of all the 'master' extensions and see which ones can be moved to REL1_35 [19:11:33] there might be ones that were just moved to master for one issue which is now fixed [19:11:38] I was talking about core, Universal_Omega. [19:11:59] Reception123: agreed. I can work on that over the coming weeks if you want? [19:12:20] Universal_Omega: sure :) [19:12:20] Alright thanks @R4356th [19:12:29] Will do Reception123 [19:13:07] Universal_Omega: yeah it's a bit difficult as we may not remember why we did it for each extension [19:13:15] but there's basically 3 categories: [19:13:24] 1) Extensions that don't use REL branches and are exclusively master [19:13:38] Reception123: DM? [19:13:49] 2) ShoutWiki extensions that have REL branches but do not use them [19:14:05] 3) Extensions that work with REL but we use master for different reasons (possibly a temporary reason) [19:14:07] Sario: sure [19:14:53] Reception123: yeah I'll compare the 2 versions code, and then also test the extensions. I'll work on this over the next few weeks/maybe a month or 2, since there is alot of them. [19:15:47] Universal_Omega: sounds good, perhaps I can help and do some too :) [20:12:11] > The '50 point checklist' is simply, "does it work?" no point creating a checklist for every extension because that would require more time than would spent testing it for that once in a blue moon update which only touches an i18n file [20:12:11] JohnLewis, true, but I just mean some things to check, like for StructuredDiscussions or Comments extension updates, any issues with internal links, external links, or interwiki links? Some guidelines in terms of what to test for basically [20:14:46] Potentially, sounds like something MWEs can work on if they feel it would be beneficial [20:21:46] yeah [20:37:56] Hi dmehus [20:40:44] BurningPrincess1, hi checking DMs [20:41:05] .tell BurningPrincess1 saw your DMs [20:41:05] dmehus: I'll pass that on when BurningPrincess1 is around. [20:48:04] * hispano76 greets