[Wikitech-l] Wednesday: Technical Advice IRC Meeting
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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] [Ops] MW Train status: Incomplete rollout, blocked on two issues
FWIW, I think the Babel bug was waiting for several days for review from Niklas, the extension owner, who wasn't at wikimania. But the folks who ended up taking action and doing the revert we're at wikimania -- I think it's a general matter of lack of communication during wikimania, with folks distracted and assuming someone else is responsible, rather than a specific "X person is at location Y". Wikimania just disrupts normal communications and work patterns. --scott (To be clear, I'm not trying to pass blame, I'm just pointing out that the disruption is not as simple of who is where or whether "enough" people are at home.) On Mon, Jul 23, 2018, 4:42 PM Greg Grossmeier wrote: > > > Deployments during the week of wikimania are always tough. I'm surprised > > we even tried to do that this year. > > There is/was sufficient coverage from both RelEng and SRE so there > wasn't an issue of site outage without available people to respond. IOW, > no one from RelEng nor SRE was attending Wikimania (sadly). > > There is the issue of not getting quick feedback and resolution on UBN! > bugs from attendees at the conference, though. (This was obviously > dependent on who was at the conference and only manifested itself in a > couple cases.) > > Greg > > -- > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | > | Release Team ManagerA18D 1138 8E47 FAC8 1C7D | > > ___ > Engineering mailing list > engineer...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/engineering > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Ops] [Engineering] MW Train status: Incomplete rollout, blocked on two issues
> Deployments during the week of wikimania are always tough. I'm surprised > we even tried to do that this year. There is/was sufficient coverage from both RelEng and SRE so there wasn't an issue of site outage without available people to respond. IOW, no one from RelEng nor SRE was attending Wikimania (sadly). There is the issue of not getting quick feedback and resolution on UBN! bugs from attendees at the conference, though. (This was obviously dependent on who was at the conference and only manifested itself in a couple cases.) Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | Release Team ManagerA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Ops] [Engineering] MW Train status: Incomplete rollout, blocked on two issues
Deployments during the week of wikimania are always tough. I'm surprised we even tried to do that this year. --scott On Mon, Jul 23, 2018, 7:23 PM Željko Filipin wrote: > Hi, > > This is the second ever train I am conducting and it has been very > interesting. I've been told that is not unusual. I have good news and bad > news. > > Good news is that some problems are resolved. I would like to thank to > everybody that helped. > > Bad news is that train is still blocked. :( Blocking tasks are: > > - T199941 Fatal MWException in Babel: "Language::isValidBuiltInCode must > be passed a string" > - T199983 Wikidata showing wrong language for page elements > - T200136 Does not work for change a log type drop down when the log type > specified by URL / argument @ 1.32.0-wmf.13 (360f7b5) > > I will cut the new branch tomorrow, but I will not be able to deploy it to > group 0 until blockers from last week are resolved. If you can help > resolving the current problems, please do. If you know that somebody can > help, please let them know. > > Željko > > > On Fri, Jul 20, 2018 at 7:19 PM Greg Grossmeier > wrote: > >> Hello, >> >> The 1.32.0-wmf.13 version of MediaWiki is rollout to almost all group0 >> and group1 wikis, but not group2. In plain wording: It is deployed to >> all non-wikipedias (Commons, wiktionaries, etc) except Wikidata. >> >> It was blocked from going to all wikis yesterday due to two issues found >> during the week: >> * Fatal MWException in Babel: "Language::isValidBuiltInCode must be >> passed a string" - https://phabricator.wikimedia.org/T199941 >> >> * Wikidata showing wrong language for page elements - >> https://phabricator.wikimedia.org/T199983 >> >> Assuming these issues are resolved before Monday we hope to resume the >> deployment of this version Monday during European working hours. >> >> The tracking task for this deployment: >> https://phabricator.wikimedia.org/T191059 >> >> A handy tool to see which wikis have which version: >> https://tools.wmflabs.org/versions/ >> >> Greg >> >> -- >> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | >> | Release Team ManagerA18D 1138 8E47 FAC8 1C7D | >> ___ >> Engineering mailing list >> engineer...@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/engineering >> > ___ > Ops mailing list > o...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/ops > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AV1? (was Re: [Multimedia] Video output changing to WebM VP9/Opus soon)
On Mon, Jul 23, 2018, 5:14 AM Jaime Crespo wrote: > 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? > AV1 is very much on my radar! It's the successor to VP8 and VP9, with encoding techniques borrowed from Xiph's Daala and Cisco's Thor. Client support is not yet widely rolled out, but there's broad industry support in the working group with the exception of Apple. Until AV1 reaches general usage many of the same companies are pushing VP9, including Microsoft which now fully supports VP9/Opus in Edge. I haven't integrated AV1 playback to ogv.js yet for Safari but it's worth trying; the bitstream format is frozen and the codec library is being improved. Somewhere a year or two down the road we will likely want to support AV1 for its even better compression, but have to wait for things to shake out first... it'll be even more demanding on the CPU so chunked encoding to better utilize our server farm would be good to have ready before that switch. -- brion > > -- > Jaime > > [0] https://blog.mozilla.org/blog/2018/07/11/royalty-free-web-video-codecs/> > > On Fri, Jun 29, 2018 at 6:46 PM, Brion Vibber > wrote: > > > Awesome sauce. Thanks Moritz! > > > > -- brion > > > > On Fri, Jun 29, 2018 at 7:39 AM Moritz Muehlenhoff < > > mmuhlenh...@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 > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] MW Train status: Incomplete rollout, blocked on two issues
Hi, This is the second ever train I am conducting and it has been very interesting. I've been told that is not unusual. I have good news and bad news. Good news is that some problems are resolved. I would like to thank to everybody that helped. Bad news is that train is still blocked. :( Blocking tasks are: - T199941 Fatal MWException in Babel: "Language::isValidBuiltInCode must be passed a string" - T199983 Wikidata showing wrong language for page elements - T200136 Does not work for change a log type drop down when the log type specified by URL / argument @ 1.32.0-wmf.13 (360f7b5) I will cut the new branch tomorrow, but I will not be able to deploy it to group 0 until blockers from last week are resolved. If you can help resolving the current problems, please do. If you know that somebody can help, please let them know. Željko On Fri, Jul 20, 2018 at 7:19 PM Greg Grossmeier wrote: > Hello, > > The 1.32.0-wmf.13 version of MediaWiki is rollout to almost all group0 > and group1 wikis, but not group2. In plain wording: It is deployed to > all non-wikipedias (Commons, wiktionaries, etc) except Wikidata. > > It was blocked from going to all wikis yesterday due to two issues found > during the week: > * Fatal MWException in Babel: "Language::isValidBuiltInCode must be > passed a string" - https://phabricator.wikimedia.org/T199941 > > * Wikidata showing wrong language for page elements - > https://phabricator.wikimedia.org/T199983 > > Assuming these issues are resolved before Monday we hope to resume the > deployment of this version Monday during European working hours. > > The tracking task for this deployment: > https://phabricator.wikimedia.org/T191059 > > A handy tool to see which wikis have which version: > https://tools.wmflabs.org/versions/ > > Greg > > -- > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | > | Release Team ManagerA18D 1138 8E47 FAC8 1C7D | > ___ > Engineering mailing list > engineer...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/engineering > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] QUnit, Promises and ArticlePlaceHolder
Well following the trail of links, leads me to this likely cause: https://phabricator.wikimedia.org/T180171#4236340 The extension relies on grunt-contrib-qunit which depends on > phantomjs-prebuild and run qunit tests with PhantomJS. The tests are under > tests/qunit: which indirectly is triggered by hashar's work on quibble I presume. DJ On Sat, Jul 21, 2018 at 6:05 PM Aleksey Bekh-Ivanov < aleksey.bekh-iva...@wikimedia.de> wrote: > Hi! > > Why did you start working on that? (Task description says nothing about the > reason) > > I express my personal opinion here: > I would like it to stay like it is (running in nodejs) - it is far more > developer friendly to run nodejs tests than Special:JavaScriptTest. > And, to be honest, I would want to migrate more JS test code supported by > WMDE to nodejs. > > > On 21 July 2018 at 00:13, Antoine Musso wrote: > > > 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 > > > > > > > > > > ___ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] QUnit, Promises and ArticlePlaceHolder
I'd like to share this relevant blog post[0] by Joaquin for work done on the Popups extension and upcoming plans for other repos. The post discusses some of the tradeoffs of Special:JavaScriptTest tests and Node.js headless QUnit tests. [0] https://phabricator.wikimedia.org/phame/post/view/96/fast_and_isolated_js_unit_tests/ On Sat, Jul 21, 2018 at 11:05 AM Aleksey Bekh-Ivanov < aleksey.bekh-iva...@wikimedia.de> wrote: > Hi! > > Why did you start working on that? (Task description says nothing about the > reason) > > I express my personal opinion here: > I would like it to stay like it is (running in nodejs) - it is far more > developer friendly to run nodejs tests than Special:JavaScriptTest. > And, to be honest, I would want to migrate more JS test code supported by > WMDE to nodejs. > > > On 21 July 2018 at 00:13, Antoine Musso wrote: > > > 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 > > > > > > > > > > ___ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] AV1? (was Re: [Multimedia] Video output changing to WebM VP9/Opus soon)
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] https://blog.mozilla.org/blog/2018/07/11/royalty-free-web-video-codecs/> On Fri, Jun 29, 2018 at 6:46 PM, Brion Vibber wrote: > Awesome sauce. Thanks Moritz! > > -- brion > > On Fri, Jun 29, 2018 at 7:39 AM Moritz Muehlenhoff < > mmuhlenh...@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 > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
