I would be interested to know if the use of CouchDB or Couchbase has
been/is being investigated to support MediaWiki as an alternative to
MySQL, Postress and SQLite?
Thank you.
jfc
Hi, I would appreciate your help with wrestling Tidy into submision:
I have a revision, https://gerrit.wikimedia.org/r/#/c/80578/ which
allows to disable TOC in ParserOutput. Because now only a marker
instead of full TOC passes through Tidy, it gets sometimes wrapped in
<p> tags. I tried various stuff like trying different types of marker,
but Tidy is stubborn. Does anyone know a way to work around this?
--
Best regards,
Max Semenik ([[User:MaxSem]])
Commons mobile app updates are in staging now...
Wikimedia Commons for Android 1.0beta12 should appear in Google Play within
a few hours. It can also be installed directly from
http://dumps.wikimedia.org/android/wikimedia-commons-1.0beta12.apk
Android version includes various smaller bug fixes, and now displays
license info for previously-uploaded photos.
Wikimedia Commons for iOS 1.0.9 has been released to registered beta
testers; if nothing explodes we'll push to Apple for review Thursday or
Friday.
iOS version includes support for iOS 7 visual style, many many many UI
improvements and bug fixes, and is generally just awesome! Users can also
now select from CC-BY-SA 3.0, CC-BY 3.0, or CC-Zero license options instead
of being always forced to CC-BY-SA 3.0.
-- brion
Hi,
during the summer I've worked on making dumps of page and revision
information for Wikimedia wikis incremental [1].
This includes both server (faster updating of dumps) and client
(download only changes since last dump) sides.
The project was successful, though there remain some issues that have
to be fixed before this goes into production [2].
I've had fun working on this, and I plan to continue with that, as time permits.
I would like to thank to my mentors, to Tyler Romeo, and especially to
Ariel T. Glenn for being there for me.
Petr Onderka
[[User:Svick]]
[1]: https://www.mediawiki.org/wiki/User:Svick/Incremental_dumps
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=54633
Within mediawiki there is a split between returning false/null and throwing
exceptions. There is also the Status class used by the wikitext parser(the
Status class is somewhat closely tied to the parser reducing reusability
though). essentially there are 3 kinds of error handling used within
mediaiki.
We talked amongst the Flow team and agreed that we prefer false/null over
exceptions, mostly due to issues where exceptions can short-circuit the
expected execution path just about everywhere in a non-obvious manner(a big
enough issue that java uses checked exceptions, another world of pain).
During code review we spend a reasonable amount of time just ensuring that
functions that can return false/null are actually checked.
Moving forward, the Flow team is considering using a php implementation
that follows the ideas of the haskell Maybe monad(
https://github.com/schmittjoh/php-option ). This is, in concept, rather
similar to the Status class the wikitext parser returns. We would like to
use this library as a way to more explicitly handle error situations and
reduce the occurrences of forgetting to check false/null. This particular
pattern is very common in Functional languages.
I do believe this method of error handling is friendlier to programmers
memory, easier to code review, and more explicit about what happens in the
error condition. Are there any concerns with the Flow project moving
forward and utilizing this as our primary error handling mechanism rather
than returning false/null?
Erik B.
Hi everyone,
I'm excited to announce that Ori Livneh will be moving into Platform
Engineering as Senior Performance Engineer. This work is riffing off
of the work that he's done with the Growth (nee E3) team, where a big
part of his job was instrumenting new features to measure their impact
on editor retention.
In his new role, Ori will be responsible for many aspects of site
performance. There are a couple of different things one can optimize
for when optimizing site performance: hardware cost or end-user
experience. The best optimizations do both, but for some
optimizations you need to choose which is more important (e.g. buying
new hardware in order to increase responsiveness). Ori will mainly be
focusing on the end user experience, and will be doing so in an
end-to-end fashion (even looking at rendering performance on end-user
machines).
Ori's day-to-day tasks will involve instrumenting the site such that
developers can see the impact of their work on site responsiveness.
He'll also work closely with our TechOps team, making recommendations
on site configuration that can have a big impact. He's also going to
spearhead the investigation and likely implementation of
performance-related technology on our cluster. There will also be a
lot of smaller changes that it'll make sense for Ori just to tackle
rather than waiting for someone else to do them, so he'll likely spend
a chunk of his time doing that as well.
Ori has done tremendous work in the year and a half he's been here in
bootstrapping the Growth team, and we're really excited to see what he
will achieve in this new role. Welcome, Ori!
Rob
Hello,
Daniel Zahn and I will be rebooting gallium which is the Jenkins master.
The reboot is scheduled on Oct 10th at 8am and we last for a couple
hours while the server is busy fscking the huge disks.
Jobs will not be processed while the server is busy, I will retrigger
them manually.
Sorry for the inconvenience.
--
Antoine "hashar" Musso
Hi everyone,
Registration for the MediaWiki Architecture Summit is now open, and
will close Tuesday, October 22, 17:00 UTC (10am PDT). Here is the
essential event information:
January 23-24, 2014
SPUR - 654 Mission Street
San Francisco, CA, USA
Please put your name/information on the following wiki page to sign up:
https://www.mediawiki.org/wiki/Architecture_guidelines/Meetings/Architectur…
NOTE: even if you've previously RSVP'd (having received an early
invitation as we were picking dates), please sign up on the page
above. We're requesting information that will help shape the event.
The target audience of this event are mainly project maintainers and
other developers involved in Requests for Comment and, in general, the
future evolution of MediaWiki and related software components. All
participants must specify their current involvement in the MediaWiki
project, the RFC(s) that are promoting and the main future topics they
want to discuss. We are tentatively aiming to have around 50-60
people and we have some budget to sponsor travel for accepted
participants.
Rob
Hello everyone,
This summer, I was working on the project "ZIM incremental updates for
Kiwix<https://www.mediawiki.org/wiki/User:Kiran_mathew_1993/ZIM_incremental_updat…>"
as part of GSoC 2013, under my mentors Emmanuel Engelhart and Tommi
Mäkitalo
The tools zimdiff and zimpatch- used for incremental updates to a zim
file- has been created. Zimdiff is used to create a "diff" file between two
versions of a zim file, and zimpatch is used to obtain the final version of
the file using the diff file and the original file. These tools have been
added as classes in the existing zimlib library(part of openzim project).
Some integration into Kiwix has been done, mostly on the server side.
Some parts of the client- side integration is still left, and I am working
on it.
https://github.com/kiranmathewkoshy/kiwix_mirrorhttps://github.com/kiranmathewkoshy/openzim
Its been a great experience working with my mentors, and I intend to stick
around for more.
--
Kiran Mathew Koshy
Electrical Engineering,
IIT Patna,
Patna,
India.
FYI
---------- Forwarded message ----------
From: Core operations via RT <core-ops(a)rt.wikimedia.org>
Date: Tue, Oct 8, 2013 at 12:14 PM
Subject: [wikimedia #5912] Upgrade PHP throughout the cluster to
5.3.10-1ubuntu3.8+wmf1 on Thursday 2013-10-08
To: akosiaris(a)wikimedia.org
Scheduling an upgrade of PHP through the cluster to from 5.3.10-1ubuntu3.6+wmf1
to 5.3.10-1ubuntu3.8+wmf1. The changes are three CVEs
CVE-2013-4635
CVE-2013-4113
CVE-2013-4248
and bug #63055 per RT #5209 (which was not solved due to one more bug)
The packages have been built and tested on beta and test.wikipedia.org and no
problems have arisen. The upgrade is expected to not be noticeable.
--
(ticket has been created)
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>