Wikitech-l July 2018

wikitech-l@lists.wikimedia.org

82 participants
68 discussions

+2 nominations for mediawiki/*
by Kunal Mehta 25 Jul '18

25 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Following comments from last time that we need some more volunteer +2'ers, I've filed multiple nominations for +2 rights in mediawiki/*: * Eranroz: https://phabricator.wikimedia.org/T199866 * Huji: https://phabricator.wikimedia.org/T199867 * Jack Phoenix: https://phabricator.wikimedia.org/T199868 * Matěj Suchánek: https://phabricator.wikimedia.org/T199865 And also for AbuseFilter: * Daimona Eaytoy: https://phabricator.wikimedia.org/T199869 Thanks, - -- Legoktm -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAltO8WoACgkQUvyOe+23 /KIWoA//difbevorl3FFiTlexfdwWMszkQmye+hLYyGGHbUThVTx4bgplc+VTsON D69Zbma8ydnpsgP0ZK0s6Vt1yCnGmobTGuCV99waPBfgeWqEskEK0vB8BWjXHwFU 9iwI6C/W1eEaiJPB62NVseR9MXE9oIOKEWk1HmNMmH/s42CZa592MNajtfsLYmAW wFUOGTwavuwffs4bW6s5Q2WPj+mTWkN61SJICTNdV27vsxsrUPOGIv8uKLSCvGAR Rxxv6TBvc+Xh9o8L+AFsQ67S8Bn+QoFuahXuWvytc+O7hEEBoKvPowcGskbcSEXX hWtSIDcT5DzmyM88vKB9GCa21/rPFnEjjBr6l8IIWCeDSyhePrIiz6JhF7ZXNFub GwLiyhUxDXsnaPULb7wMUlAiINP8jl6GxXClG0o71u81OlIReqsqzFKEBnhBMibQ 9Nz0NM92Zu3aoEkI/4CEyVSvGIsf3rTACWkCB3QQYRrtzTKkiLF40CoVYiSRbSiJ tQJmCkjGVMFZonEGL/Svux7C3yecgOCcoryZgIo+SVf0MNRjSoaLbZlJrq9x0gup 6Zc1G/K+YcQZ8ZC62VriZ12s6vPKIQILsYkE3AVQCNmhvgQ5vpBPbDO9BUvcqhpV 6DfHExlf9sCRiTq9aiq/GFEehBeBms/5pNYprd62AJExflc+Mpc= =srTo -----END PGP SIGNATURE-----

1 1

Proposal for removal without deprecation of OutputPage::addMetadataLink and OutputPage::getMetadataAttribute
by Aryeh Gregor 25 Jul '18

25 Jul '18

Patch to remove: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/447629 In the course of writing more tests for OutputPage, I came across the two methods addMetadataLink() and getMetadataAttribute() that didn't make sense to me. After a bit of digging, I found they were added in 2004 (22f8c4ce) to support output of Creative Commons and Dublin Core <link rel="meta"> tags. The only thing they do (compared to directly calling addLink()) is for some reason setting rel="alternate meta" instead of rel="meta" for the first link. I didn't find any reason why they should do that, but based on a nearby comment I speculate it was to work around bugs in some UAs that were around at that time. The functionality of outputting these <link> tags was moved to extensions in 2011 (27c3b22b), while the methods were left in core. Those extensions (CreativeCommonsRdf and DublinCoreRdf) now call addHeadItem() directly. A search found no other uses in core or extensions. Any callers could be trivially changed to use addLink() or another method. Legoktm points out that getMetadataAttribute() is marked public, and therefore strictly speaking can only be removed via the deprecation policy. (Although getMetadataAttribute() is really just a helper function, and the actual public interface is addMetadataLink() AFAICT.) Practically speaking, although they aren't hurting anything, I think this is useless cruft that it's virtually certain nobody ever used, so I suggest skipping the deprecation period in this case. Does anyone object?

2 1

Creation of new mediawiki/extensions/** group in gerrit
by Jay prakash 25 Jul '18

25 Jul '18

Hello Everyone, This is Jay. I have some questions and want to know that it is possible to apply on the ground. == Problems == * I work on the very trivial tasks. and even after working on the very trivial tasks, sometimes my patch does not merge even after 6 months has passed. Recently I have Abandoned my some patches due to be not merged after 6 months has passed.[1][2] * Recently there are many tasks created on phab to Archive the extensions. Those extensions have not maintained in the last 5 years. * And also We have lack of peoples for reviewing those extension's patches, which have not deployed on Wikimedia or any other big wiki. == Potential Solution == The potential solution is to create a new group on the Gerrit with +2 rights. This group will manage those extensions which have not maintained by the owner in last 1 year (if not, Maybe 2 years). This will save the extension from being unmaintained. There are many users who have good knowledge and They review patches like Mainframe98,[3] MGChecker, and others. So my question is why does we not create this type of group? so that users can managed those extensions which have not maintained in last 1 year. [1] https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/LanguageTag/+/40605… [2] https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Arrays/+/405057/ [3] https://gerrit.wikimedia.org/r/#/q/reviewedby:%22Mainframe98+%253Ck.s.werf%… Thanks

2 3

Wednesday: Technical Advice IRC Meeting
by Michael Schönitzer 23 Jul '18

23 Jul '18

Reminder: Technical Advice IRC meeting again **Wednesday 3-4 pm UTC** on #wikimedia-tech. The Technical Advice IRC Meeting (TAIM) is a weekly support event for volunteer developers. Every Wednesday, two full-time developers are available to help you with all your questions about Mediawiki, gadgets, tools and more! This can be anything from "how to get started" over "who would be the best contact for X" to specific questions on your project. In addition to the weekly meeting at 3 pm, we will have an additional meeting every first Wednesday of the month at 11 pm UTC, starting August 1st, 2018! If you know already what you would like to discuss or ask, please add your topic to the next meeting: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting Hope to see you there! Michi (for WMDE’s tech team) -- Michael F. Schönitzer Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen Wissens frei teilhaben kann. Helfen Sie uns dabei! http://spenden.wikimedia.de/ Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

1 0

AV1? (was Re: [Multimedia] Video output changing to WebM VP9/Opus soon)
by Jaime Crespo 23 Jul '18

23 Jul '18

Thanks to all people involved, I just read about this new video format in the making/released [0]. Of course, I am not asking to support this, as this seems like the future, and not the present, but being a complete noob on video formats and codecs, I would like to know if someone more knolegeble has some insight about this and if it is something to keep in mind/someone has tested it and has experiences to share/client and vendor support? -- Jaime [0] <url: https://blog.mozilla.org/blog/2018/07/11/royalty-free-web-video-codecs/> On Fri, Jun 29, 2018 at 6:46 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote: > Awesome sauce. Thanks Moritz! > > -- brion > > On Fri, Jun 29, 2018 at 7:39 AM Moritz Muehlenhoff < > mmuhlenhoff(a)wikimedia.org> wrote: > > > Hi all, > > > > On Thu, Jun 28, 2018 at 01:54:18PM -0700, Brion Vibber wrote: > > > Current state on this: > > > > > > * still hoping to deploy the libvpx+ffmpeg backport first so we start > > with > > > best performance; Moritz made a start on libvpx but we still have to > > > resolve ffmpeg (possibly by patching 3.2 instead of updating all the > way > > to > > > 3.4) > > > > I've completed this today. We now have a separate repository component > > for stretch-wikimedia (named component/vp9) which includes ffmpeg 3.2.10 > > (thus allowing us to follow the ffmpeg security updates released in > Debian > > with a local rebuild) with backported row-mt support and linked against > > libvpx 1.7.0. > > > > I tested re-encoding > > > > https://commons.wikimedia.org/wiki/File:Wall_of_Death_-_ > Pitts_Todeswand_2017_-_Jagath_Perera.webm > > (which is a nice fast-paced test file) from VP8 to VP9, which results in > > a size reduction from 48M to 31M. > > > > When using eight CPU cores on one of our video scaler servers, enabling > > row-mt > > gives a significant performance boost; encoding time went down from 5:31 > > mins > > to 3:36 mins. > > > > All the details can be found at > > https://phabricator.wikimedia.org/T190333#4324995 > > > > Cheers, > > Moritz >

2 1

QUnit, Promises and ArticlePlaceHolder
by Antoine Musso 23 Jul '18

23 Jul '18

Hello, The ArticlePlaceholder extension has QUnit tests run via nodejs. I am trying to port them to Special:JavaScriptTest. I am hitting a wall due to an OOUi widget not being found on the first test. Most probably because the window is opened asynchronously and the assertions are run before it opens. JavaScript Promises are not my thing and I know nothing about OOUi. If that is in your area of expertise, I could use a hand to finish up the port: https://gerrit.wikimedia.org/r/#/c/444936/6 Thank you! -- Antoine "hashar" Musso

4 3

Add modules=site.styles inline
by Nischay Nahata 21 Jul '18

21 Jul '18

Hi all, It seems the Common.css on my website is pretty small but Resource Loader loads it using a <link> tag in the head. I have read that it will be better to instead inline the styles or even load them later. What is the right way to go about this? Any suggestions are welcome. Also see https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery Regards, Nischay Nahata

2 8

TechCom radar 2018-07-18
by Kate Chapman 20 Jul '18

20 Jul '18

Hi All, Below are this week's TechCom minutes: * IRC Meeting Occurred: Unify various deletion systems <https://phabricator.wikimedia.org/T20493> * Meeting minutes: <https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.20…> * There is the question of how Special:Contributions and Special:DeletedContributions will work and how if required to provide feature parity. Further summary here: <https://phabricator.wikimedia.org/T20493#4436769> * New RFC: Partial blocks <https://phabricator.wikimedia.org/T199917> The Anti-Harassment team is asking TechCom to review a plan for implementing Partial Blocks which seeks to allow admins to block users from specific pages and/or all articles inside a namespace. * New RFC: Add a language agnostic build step to skins/extensions to our deploy process <https://phabricator.wikimedia.org/T199004> Currently requires developers to do the build step locally and check-in the results. This RFC proposes making a universal/repeatable process. * New RFC: Extension:JADE scalability concerns due to creating a page per revision <https://phabricator.wikimedia.org/T196547> RFC proposal still being developed * New RFC: Re-evaluate librsvg as SVG renderer on Wikimedia wikis <https://phabricator.wikimedia.org/T40010> This RFC is re-evaluating the use of librsvg to generate PNGs from SVG due to rendering issues and determining if there is a better alternative. * IRC Meeting scheduled for 2018-08-01 in the #wikimedia-office channel at 2pm PST(22:00 UTC, 23:00 CET) RFC: Modern Event Platform - Choose Schema Tech <https://phabricator.wikimedia.org/T198256> This RFC is looking at if Apache Arvo or JSONSchema should be used for the event schema and serialization method. * No IRC Meeting scheduled for July 25 You can also find our meeting minutes at <https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes> See also the TechCom RFC board <https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>. If you prefer you can subscribe to our newsletter here: <https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar> Thanks, Kate -- Kate Chapman TechCom Facilitator (Contractor)

1 0

Timeless Newsletter
by Isarra Yos 20 Jul '18

20 Jul '18

Hey all, For anyone not familiar, the Timeless skin has been available as an option on Wikimedia wikis since november or so, and development of the skin is now being funded by a Project Grant. If you're interested in receiving updates about this, I've created a newsletter which should be going out monthly. You can sign up for the newsletter here: https://meta.wikimedia.org/wiki/Timeless/Newsletter Or read the first issue: https://meta.wikimedia.org/wiki/Timeless/Newsletter/1 Timeless: https://www.mediawiki.org/wiki/Skin:Timeless?useskin=timeless The grant now funding this: https://meta.wikimedia.org/wiki/Grants:Project/Isarra/Timeless:_Post-deploy… Thank you to everyone for your interest and support thus far, and making all of this possible! -Isarra

1 0

hewiki dump to be added to 'big wikis' and run with multiple processes
by Ariel Glenn WMF 20 Jul '18

20 Jul '18

Good morning! The pages-meta-history dumps for hewiki take 70 hours these days, the longest of any wiki not already running with parallel jobs. I plan to add it to the list of 'big wikis' starting August 1st, meaning that 6 jobs will run in parallel producing the usual numbered file output; look at e.g. frwiki dumps for an example. Please adjust any download/processing scripts accordingly. Thanks! Ariel

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l July 2018