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
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
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
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.
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
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
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
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
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