[08:33:08] [[Tech]]; Mdia12; /* Specific CSS and Javascript in a template */; https://meta.wikimedia.org/w/index.php?diff=15307305&oldid=15305831&rcid=7340459 [11:06:33] [[Tech]]; Mdia12; /* Specific CSS and Javascript in a template */; https://meta.wikimedia.org/w/index.php?diff=15307500&oldid=15307305&rcid=7340815 [14:23:48] Krenair, thanks for uploading the file [14:24:15] there are 2 more ;o) https://phabricator.wikimedia.org/T125461 https://phabricator.wikimedia.org/T125467 [15:08:32] yannf, done [15:08:40] in future note that you can send them all as one request [15:09:11] preferably in an archive with all the correct filenames and .txt files already saved [15:09:34] Krenair, thanks a lot! actually the record is created by https://tools.wmflabs.org/video2commons/ [15:10:29] may be zhuyifei1999_ needs to be informed [15:11:11] Krenair, there will be more ;) [19:39:53] 503 from phabricator (diffusion), known? [19:44:08] https://phabricator.wikimedia.org/T125701 [21:58:40] starting https://phabricator.wikimedia.org/E138 at the top of the hour in #wikimedia-office [21:58:56] Expiring watch list entries [22:00:28] TimStarling is chairing today [22:00:50] oops...meant to say that in #wikimedia-office :-) [22:23:30] Dear channel, how can I determine if (or when) was (or will) this change be deployed on commons? https://phabricator.wikimedia.org/T124257 [22:39:17] yurb, click on the link to the patch in gerrit [22:39:35] yurb, expand the 'included in' section in the gerrit UI [22:40:02] yurb: in the projects list on the task, you should see WMF-deploy...., and it says wmf.12, which means it'll be deployed with the wmf.12 deployment train [22:40:07] yurb, see which wmf/ branches is lists, compare against https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap [22:41:02] Krenair, mobrovac: thank you [22:41:03] commons is part of group 1 [22:41:46] stuff without a wmf/ branch listed there will be included in the next wmf branch to be created, you would have to check the repository's branch list [22:44:02] we should write this down somewhere easy for wikimedia users to find [22:44:09] with links and stuff [23:05:14] Krenair: Well, with the move to Phabricator for code hosting and review I have hopes about making it clear on tasks what the deployment state of them is. [23:05:38] "hopes". :-) [23:07:00] oh right [23:07:32] yurb, so there's a bot that goes around tagging tasks with the first wmf branch to include each of their patches [23:07:58] with the date being when it hits group 0 [23:08:12] James_F: seems plausible. certainly more plausible than many expected outcomes [23:09:56] Krenair: yeah, I noticed it, but I interpreted the date as "probably this is when it will go live" [23:10:05] well yeah [23:10:08] that's when it goes live on some wikis [23:10:10] like mediawiki.org [23:10:16] robla: Yeah. Ideally, rather than weekly dumps of code, I'd like us to deploy individual commits or groups (where there are dependencies) after some testing, assess how well they work in production, and either revert or continue. I can dream. :-) [23:12:47] having a weekly train seems like a good way of working with committers who prefer the "commit and forget" model. whether or not "commit and forget" is a good thing or a bad thing is left as an exercise for the reader ;-) [23:15:47] > robla: Yeah. Ideally, rather than weekly dumps of code, I'd like us to deploy individual commits or groups (where there are dependencies) after some testing, assess how well they work in production, and either revert or continue. I can dream. :-) [23:15:51] yes, I think that's the right model [23:16:12] "commit and forget" is a bad thing [23:16:27] Krenair: Except for the dates for wmf.11 and wmf.12 :-) [23:16:59] okay, predicted dates? :p [23:17:07] So something like a separate "production" branch? [23:17:09] "Aspirational dates". [23:17:38] yurb: Or just a repo called 'production' with git sub-modules for each component. [23:17:49] James_F++ [23:17:50] ori: sure, but 24x7 support from RelEng is also a bad idea, and I don't think we're at the point where we can support someone committing something at 7pm-ish PT on Saturday night [23:19:55] robla, ori: I didn't mean C+2 in master -> immediate deployment, though; more like an hourly train that takes patches from -48 hours or more from staging and applies them to production, run during "business hours" or something similar. [23:21:12] (If nothing else, we want to be able to put things in staging for a while and fix them if found problematic; holding up all deploys just because one thing got merged a little prematurely wouldn't be great, but at the same time liberal reverting-on-sight of slightly-broken patches is pretty disheartening for most humans, and especially so for volunteers and 'non-core' developers.) [23:21:42] Anyway. This is a bit of a hobby-horse of mine, but talking about it doesn't help so much. :-) [23:24:38] if we had a "postpone" style revert, that might be a little socially better. Taking something that is due to be part of wmf7 and moving it to wmf8 would be an easier revert to do socially than removing it from wmf7 and saying "try again" [23:26:46] granted, it would give us a passive aggressive way of saying "no" to something. We could continually postpone commits [23:27:06] I think we end up being less resilient because our deployment process keeps developers at an arm's length from production. Getting individual developers more involved with the deployment of their changes will, in my opinion, not only improve accountability, but will make it easier for developers to learn how to write code that behaves well in prod. [23:28:15] ori: except not everybody wants or needs to be as invested to understand prod ;) [23:28:38] committing something in the MW repo !== deploying in WMF prod [23:30:15] the fact that the two are distinct technical challenges (writing code so it works well in core, and writing it so it runs well in wmf's prod environment) is itself a reflection of the gap between the two [23:30:43] but yeah, point taken [23:31:25] ori: i'd be all for your devops-type suggestion, but i fear that would deter potential committers [23:31:50] and i'm guessing beginners would have a really hard time [23:31:57] but, we may be going off topic here [23:32:12] let's bring Lua template authors into the mix! [23:32:15] :-)