[08:44:00] Hello [13:16:37] thedj: I added it, scribunto, and made you importer too. [13:17:36] thedj: templates with conditional styling will be interesting to fiddle with; conversion needs to add classes rather than style fragments, but that seems even nicer to me. [13:22:09] Coren: nice, i'll play a bit. [13:40:21] Things like box width are going to need to stay in style="", but at least they can be overriden with @media blocks. [13:40:37] (If needed) [14:16:30] Coren: can you also add MobileFrontend ? then we can test with ?useskin=minerva [14:18:40] thedj: Seems smart. :-) Gimme a sec. [14:20:24] thedj: {{done}} [14:21:08] cool. thanks for working on this stuff [14:21:34] i have to head out to my parents place, but i'll play around a bit more later tonight. [14:27:54] Thanks for testing this stuff. :-) [15:24:32] ostriches: has a date been set for 1.27 branching yet? [15:25:11] No, I was looking at the calendar this week. [15:25:16] Needs to happen $soon [17:09:36] twentyafterfour: thanks for stepping up on T129842! need any help on next steps? [17:09:37] T129842: Decide whether to have a "Code Review" committee / working group - https://phabricator.wikimedia.org/T129842 [17:21:53] robla: in a meeting, but I would of course welcome any help :) [17:22:21] I like the ideas you've borrowed from Rust's process [17:29:05] cool! gwicke gets the credit for introducing us to the Rust process. No rush, just pointing out that I'm available to help [17:29:44] whee, netsplit! [17:45:30] So #wikimedia-releng has already been working on the problem quite a lot, as you know. Most recently we have been working on proof of concept CI implementation and general understanding. [17:52:44] I think the position of #releng is that we shouldn't mandate a rigid code review regime but instead offer a couple of reccomended models with at bit of flexibility to adapt the process to each project or repository. I think that one the most important jobs for a code review working group would be to better document and evangelize best practices [17:55:46] so I don't know how we get from where we are now (an ad-hoc group of people interested in the subject, minimally organized) to a formal working group under the ArcCom umbrella ... I will do my best to push that forward though. [19:04:46] twentyafterfour: it's really really complicated stuff. we probably do need some sort of baseline standards for any code that gets deployed to the Wikimedia cluster, no? [19:07:57] Harri1, I saw your comment a while ago, about 3D. You might be interested in this new/experimental code https://www.mediawiki.org/wiki/Extension:3d (I'm not involved with it, I just know of it). Hope that helps. [19:09:58] robla: Yes but that doesn't have to dictate the exact process or tools used. We definitely won't be deploying directly from github, so whatever process people use, code needs to be on a WMF server before deploying. And we should require some sort of code review before new code is deployed but I don't see why we have to mandate every detail about how that gets done. [19:13:11] robla: For example, I don't see why some projects shouldn't be allowed to use post-commit review, as long as the review happens before merging into a deployable branch. Or if one team wants to use github pull requests and then have their github repo mirrored to phabricator, I'm sure we can figure out how to do that in an acceptable way. Maybe we should require deployed commits to be signed with a [19:13:13] pre-authorized key. Then it doesn't matter how the code makes it from developer to deployment, we can validate that someone trusted has signed off on that commit. [19:14:34] But... I do think we should limit the supported workflows to just a few, with a little room for flexibility. We definitely want to encourage uniformity and best practices [19:15:23] rather than proliferation of a bunch of different workflows and branching models which can lead to confusion and more cognitive overhead... [19:15:44] that is to say, we should stick with just a couple of widely accepted models not 'anything goes' [19:16:13] We should avoid allowing each different project to choose something wildly different [19:16:29] yeah [19:18:08] should probably make sure we don't end up with different workflowers per-wmf-team too [19:24:32] I think the latitude given corresponds to the trust that we have in the process for a given repository [19:39:12] that's why I think one of the most important jobs which still remains only partially finished is defining best practices and recommended workflows. [19:39:40] we've been doing a lot of that work but more remains.