Wikitech-l July 2018

wikitech-l@lists.wikimedia.org

82 participants
67 discussions

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 18 Jun '24

18 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

2 2

bluejeans
by Jeremy Baron 22 Feb '23

22 Feb '23

Hi, On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote: > We will be holding this brownbag in 25 minutes. The Bluejeans link has > changed: > > https://bluejeans.com/396234560 I'm not familiar with bluejeans and maybe have missed a transition because I wasn't paying enough attention. is this some kind of experiment? have all meetings transitioned to this service? anyway, my immediate question at the moment is how do you join without sharing your microphone and camera? am I correct thinking that this is an entirely proprietary stack that's neither gratis nor libre and has no on-premise (not cloud) hosting option? are we paying for this? -Jeremy

9 16

New DB_REPLICA constant; DB_SLAVE deprecated
by Aaron Schulz 04 Jul '20

04 Jul '20

As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA instead of DB_SLAVE, with the old constant left as an alias. This is part of a string of commits that cleaned up the mixed use of "replica" and "slave" by sticking to the former. Extensions have not been mass converted. Please use the new constant in any new code. The word "replica" is a bit more indicative of a broader range of DB setups*, is used by a range of large companies**, and is more neutral in connotations. Drupal and Django made similar updates (even replacing the word "master"): * https://www.drupal.org/node/2275877 * https://github.com/django/django/pull/2692/files & https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023… I don't plan on doing anything to DB_MASTER, since it seems fine by itself, like "master copy", "master tape" or "master key". This is analogous to a master RDBMs database. Even multi-master RDBMs systems tend to have a stronger consistency than classic RDBMs slave servers, and present themselves as one logical "master" or "authoritative" copy. Even in it's personified form, a "master" database can readily be thought of as analogous to "controller", "governer", "ruler", lead "officer", or such.** * clusters using two-phase commit, galera using certification-based replication, multi-master circular replication, ect... ** https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_… *** http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium… -- -Aaron

4 3

Life hack: Working with production content in your local wiki
by Jon Robson 13 Dec '18

13 Dec '18

I've been meaning to document this for a while. If you're finding yourself visiting Special:Export/Import often for the purpose of MediaWiki development there is a much better way to get content into your local wiki for testing purposes. This short video explains how MobileFrontend extension provides tooling to help you debug live on-wiki content via $wgMFContentProviderClass [1] https://youtu.be/uRQzjN0hBlY Hope it saves someone lots of time! [1] https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/maste… -- Jon Robson Senior Software Engineer

1 1

Re: [Wikitech-l] [Wikidata-tech] Normalization of change tag schema
by Amir Sarabadani 29 Nov '18

29 Nov '18

Hello, One update regarding this. We enabled using the new table for Special:Tags in several large wikis which caused a massive improvement in the performance of the page. For example loading Special:Tags on Wikidata used to take around a minute and now it takes less than a second. English Wikipedia is down from ten seconds to less than one and so on. There is a lot of work needs to be done and maintenance scripts is being ran to backpopulate the ct_tag_id column in change_tag table (If you want to follow the progress, see https://phabricator.wikimedia.org/T193873) and then we need start reading from the new table in mediawiki and finally we can drop ct_tag column entirely. If you want to help in review, writing code or anything, just let me know. Best On Wed, 27 Jun 2018 at 15:15, Léa Lacroix <lea.lacroix(a)wikimedia.de> wrote: > Hello all, > > Our team is refactoring some code around the change tags on Recent > Changes. This can impact people using the database on ToolForge. > > Currently, the tags are stored in the table change_tag in the column > ct_tag. > > In the next days, we will add a column ct_tag_id with a unique identifier > for these tags. A new table change_tag_def that will store the tag id, > the message, and more information like how many times this tag is used on > the local wiki. > > On the long term, we plan to drop the column ct_tag since the tag will be > identified with ct_tag_id. > > This change will happen on: > - French Wikipedia: Monday July 2nd > - All other wikis: from July 9th > > If there is any problem (trouble with saving edits, slow down of recent > changes…) please create a subtask of T185355 > <https://phabricator.wikimedia.org/T185355> or contact Ladsgroup > <https://www.wikidata.org/wiki/User:Ladsgroup>. > > Cheers, > -- > Léa Lacroix > Project Manager Community Communication for Wikidata > > Wikimedia Deutschland e.V. > Tempelhofer Ufer 23-24 > 10963 Berlin > www.wikimedia.de > > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. > > Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg > unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt > für Körperschaften I Berlin, Steuernummer 27/029/42207. > _______________________________________________ > Wikidata-tech mailing list > Wikidata-tech(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata-tech > -- Amir Sarabadani Software Engineer 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/029/42207.

4 7

Video output changing to WebM VP9/Opus soon
by Brion Vibber 12 Oct '18

12 Oct '18

In the next couple weeks I'm planning to start switching our video transcode output from WebM VP8/Vorbis to the newer WebM VP9/Opus profile, which saves us about 38% on file size and bandwidth while retaining the same quality. This will not affect what kinds of files you upload; only the scaled transcoded output files used for playback will change. All modern browsers that support VP8 support VP9 as well, and our player shim for Safari and IE will continue to work. All the details: https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/VP9_transition Comments and questions welcome! -- brion

5 17

Roadmap for CX?
by Strainu 06 Sep '18

06 Sep '18

Following the recent outage, we've had a new series of complaints about the lack of improvements in CX, especially related to server-side activities like saving/publishing pages. Now, I know the team is involved in a long-term effort to merge the editor with the VE, but is there an end in sight for that effort? Can I tell people who ask "look, 6 more months then we'll have a much better translation tool"? Is there a publicly available roadmap for this project and more generally, for CX? Thanks, Strainu

5 8

Tidy removed on all Wikimedia wikis (final update)
by Subramanya Sastry 17 Aug '18

17 Aug '18

Hello everyone, On 6th July 2017, we made an announcement [1] about our plans to replace Tidy with RemexHtml on the Wikimedia cluster. On 5th July 2018, we made the final switchover from Tidy [2]. For those of you interested, we published a blog post [3] documenting the process and steps in this project. What next? ---------- RemexHtml is the default in MediaWiki since 1.31. We are in the process of removing all traces of Tidy from Wikimedia's configuration files and from MediaWiki itself. We'll keep the ParserMigration extension enabled in its current form for another couple of months. After this period, the ParserMigration extension will be disabled completely alongwith all associated Tidy configuration. It will be re-purposed at a later time as required to compare impacts of other parser changes. We haven't figured out the timeline yet, but at some point in the coming weeks, we'll disable most of the high-priority linter categories that only make sense in the context of replacing Tidy. If you have any thoughts about retaining or dropping these categories, please leave a note on mw:Help_talk:Extension:Linter [4]. Thanks! ------- As noted in the blog post [3], this was a collaborative effort between the several teams at the Wikimedia Foundation and volunteer editing communities on various wikis. Everyone involved played important and specific roles in getting us to this important milestone. An active embrace by various wikis of this effort has let the Foundation make this much-needed and important upgrade of a key piece of our platform. In that context, I want to take this opportunity to specifically name and thank some of these individuals. Tim Starling, C.Scott Ananian, Kunal Mehta, Arlo Breault, and yours truly did all the technical work in core, Parsoid, and the extensions. Erica Litrenta and Sherry Snyder helped develop the community engagement plan with various wikis and specific editors. Sherry, in particular helped a lot in the final months as we were trying to get more wikis to fix pages. James Forrester helped review and provide feedback at various stages, especially with the phased deployment. A number of other developers and staff were involved in review, feedback, during RFC discussions, and in helping with fixing templates where I couldn't do so myself. Here is a subset of users across several wikis that I had an opportunity to interact with and observe who helped in various ways: developing bots and gadgets, writing help pages, asking clarification questions, providing feedback, reporting bugs on wiki and Phabricator, and fixing lots of pages and templates on their home and other wikis. User:Daimano Eaytoy, User:Sakretsu, User:Anamalocaris, User:Izno, User:Lsj, User:xaosflux, User:PerfektesChaos, User:Lómelinde, User:Ikhitron, User:星耀晨曦, User:Deryck Chan, User:Sunpriat, User:Stryn, User:MawaruNeko, User:NicoV, User:Bdijkstra, User:Skalman, User:Shakespearefan00, User:Billinghurst, User:MarcoSwart, User:Mackensen, User:Andriy.v, User:Jonesey95, User:TheDJ, and the anonymous wiki user whoever you are. :-) Obviously, there were a number of others users involved in this effort. Please feel free to raise your hand or recognize other's contributions on this thread! My thanks to you all! Subbu. 1. https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2017-July/001625… 2. https://phabricator.wikimedia.org/T175706#4399641 3. https://blog.wikimedia.org/2018/07/09/tidy-html5-replacement/ 4. https://www.mediawiki.org/wiki/Help_talk:Extension:Linter

3 2

Making PolyGerrit the default ui for gerrit
by Paladox 06 Aug '18

06 Aug '18

Hi, i have created this task [1] with i have uploaded this patch [2] to make polygerrit the default ui. The reason why is upstream are preparing to remove the gwtui very soon. In matter of fact upstream have disabled the gwtui on *.googlesource.com. Upstream already have this change [3] to remove the ui. Making PolyGerrit the default ui will get new users use to the new ui. GWTUI will still be available with ui switcher in the footer or you can append the url like https://gerrit.wikimedia.org/r/?polygerrit=0 PolyGerrit is stable, secure and also fast. It also has features that you cannot see in gwtui like user status, naming your patchiest (description), cc feature and also being able to tell who added you as a reviewer. This email is advanced notice before we change the default ui. any bugs todo with polygerrit / gerrit can be filled at https://phabricator.wikimedia.org/project/view/330/ and we can forward it upstream. [1] https://phabricator.wikimedia.org/T196812 [2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/439444 [3] https://gerrit-review.googlesource.com/c/gerrit/+/116790

2 6

Next RFC meeting: Modern Event Platform - Choose Schema Tech
by Tim Starling 01 Aug '18

01 Aug '18

In the TechCom committee meeting yesterday, it was decided that next week's RFC meeting will discuss T198256 "Modern Event Platform - Choose Schema Tech" https://phabricator.wikimedia.org/T198256 This relates to the choice between Avro and JSONSchema for the next iteration of EventLogging. The meeting will be at 1pm Wednesday PST in #wikimedia-office. -- Tim Starling

1 1

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