Yusuke Matsubara | 23 Nov 15:19 2014

Tagging edits by reviewers (was: changing edit summaries)

> On Sun, 23 Nov 2014, at 19:25, Anthony Cole wrote:
>> On Wed Nov 12 01:05:26 UTC 2014 I asked this list if the technical team
>> could help the patrollers of recent changes to Wikipedia's medical articles
>> “...tag the log entry of revisions ... as having been reviewed for
>> policy/guideline compliance by a trusted editor.” [1]
>> I am quite technically illiterate and may have misunderstood, but judging
>> by Yusuke Matsubara's description, the extension he mentions above seems
>> like it might fit our needs. Will it enable patrollers to add a comment to
>> the edit summary? Does anyone know if it works on en.Wikipedia?
>> 1.https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079418.html

I don't think it is promising to use the RevisionCommentSupplement
extension for a kind of revision tagging in the manner described. For
example, the extension doesn't have the functionality of filtering
RecentChanges by appended summaries. The intended use case is
re-explain the individual edit so that humans (readers) can better
understand it.

A more promising approach might be (re-)using "tags" [1] - AbuseFilter
and a few other tools (such as HHVM) add tags to revisions, and
RecentChanges can (already) be filtered by tags. Is there an
implementation that allows editors with certain privilege to
add/remove a certain tag to a chosen revision? Is it easy to create

[1] https://www.mediawiki.org/wiki/Manual:Tags

(Continue reading)

Thomas Mulhall | 22 Nov 14:33 2014

Help with adding A skin to jenkings

 Hi could I have some help to add git.wikimedia.org/summary/mediawiki%2Fskins%2FMetrolook to
jenkings so that it can check for errors please. like the vector skin does.
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Mark A. Hershberger | 22 Nov 00:59 2014

Release candidate for 1.24.0

Hello everyone,

I am happy to announce the (hopefully) final release candidate for
MediaWiki 1.24.0.  Download links are given at the end of this email.

== Changes since 1.24.0-rc.1 ==
* Setting $wgAllowSiteCSSOnRestrictedPages to true is necessary if you
  want to use on-wiki CSS modifications (e.g MediaWiki:Common.css) on
  Special:UserLogin or Special:Preferences.

Public keys:


GPG signatures:

Mark A. Hershberger
(Release Management Team)


Mark A. Hershberger
(Continue reading)

Rob Lanphier | 20 Nov 19:57 2014

RFC meeting wikignoming (Re: RFC meeting this week)

On Mon, Nov 17, 2014 at 10:20 PM, Tim Starling <tstarling <at> wikimedia.org> wrote:
> In the next RFC meeting we would like to discuss the following RFC:
> * Text extraction
> <https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction>
> The meeting will be on the IRC channel #wikimedia-office on
> irc.freenode.org at the following time:
> * UTC: Wednesday 21:00
> * US PST: Wednesday 13:00
> * Europe CET: Wednesday 22:00
> * Australia AEDT: Thursday 08:00
> Please note that the time has changed. It is an hour earlier so that
> it will be easier for people in Europe to attend.

We (collectively) need to get a lot better about not merely signaling
what is coming up, but what the results of these decisions are.  If
you look here:

...you could be forgiven for thinking the RFC meetings are something
we do anymore.  Basically, you have to be subscribed to this mailing
list, and then, if you miss the time, fish through the logs here:

...and hope that some glitch hasn't wiped out the logs, since I don't
think there are any service level expectations for those logs.

(Continue reading)

Chad | 20 Nov 01:13 2014

Re: Feature request.

On Wed Nov 19 2014 at 3:50:02 PM Nathan <nawrich <at> gmail.com> wrote:

> Why not just interleave or nest the conflicted edit in the history of the
> page? So if you are editing revision 1, and conflict with someone elses
> revision 2, save your revision as 2 and the next person's revision as 3?
> There's some ugliness in the revision history to resolve (like timestamps),
> and potentially other ways it could be done, but I see no reason not to
> slot the conflicted edit into the history while prompting the user to merge
> into a current revision.
Except since rev_id auto-increments you'd end up with an out-of-place
rev_id in the history. In your example you'd end up with something like:

[[Page]] history:
- Latest rev by Joe (rev_id 2)
- Previous rev by Jane (rev_id 3) <- This was the edit conflict, inserted
after the fact
- First rev by Jim (rev_id 1) <- This one was the one Jane and Joe both
began editing from

Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Rob Lanphier | 20 Nov 00:21 2014

Fwd: New in Platform Engineering: James Douglas and Stas Malyshev

Hi everyone,

We have two new people starting this week in Platform Engineering.

James Douglas
James started yesterday as the second member of our newly formed
Services group. "Services" in this context are standalone software
components that often run on their own machines and have very specific
jobs, such as "generate a PDF from this article". Much of our
infrastructure isn't that specific, so you'll hear us talking a lot
over the next year about moving toward "Service Oriented
Architecture", which basically means taking our general purpose
software and breaking it up into more focused components. James
working closely with Gabriel Wicke on bringing new services online,
such as RESTbase[1].

James comes to us from Versal, an organization he co-founded, and
where he was responsible for building out a Scala-based online
education platform. He lives here in San Francisco, and he'll be
sitting beside Gabriel on the south end of 3. You can find a wealth of
writings about his work with Scala as well as other software
development topics on James' personal website[2].

Stas Malyshev
Stas joins us from SugarCRM, where he was Software Architect since
2010. Prior to working at Sugar, Stas worked at Zend (makers of PHP),
where he was employee #1, and build the first version of their
website. In debugging problems on the website, he eventually got
slurped into fixing bugs and eventually doing much more with the PHP
runtime itself. If you're a php developer (or maybe even if you're
(Continue reading)

Quim Gil | 19 Nov 20:00 2014

Bugzilla-Phabricator migration: 21 Nov at 00:30 UTC

We are polishing the last details before starting the Bugzilla migration to
Phabricator on 21 November at 00:30 UTC.


You can find all the details of what will happen next in the timeline at



Basically, Bugzilla access will be restricted to read-only, Phabricator
will be pulled, and we will start the migration. If all goes well, by
Monday 24 Phabricator will be back with about 75k tasks, and Bugzilla will
be archived in old-bugzilla.wikimedia.org.

During this period, we will redirect users to a page asking them to
postpone their bug reporting unless it is so urgent that it cannot wait
until Monday. In that case, they can use  #wikimedia-bug2phab on IRC and
mediawiki.org's Support Desk.

If you registered in https://phabricator.wikimedia.org before the
migration, your Bugzilla activity will be probably assigned to you by the
time you check the site. Otherwise, you will still be able to register and
claim your activity, which will be assigned to you within a couple of hours
or a couple of days, depending of the queue.


We are confident about the stability of Phabricator and also about the
(Continue reading)

Tim Starling | 18 Nov 07:20 2014

RFC meeting this week

In the next RFC meeting we would like to discuss the following RFC:

* Text extraction

The meeting will be on the IRC channel #wikimedia-office on
irc.freenode.org at the following time:

* UTC: Wednesday 21:00
* US PST: Wednesday 13:00
* Europe CET: Wednesday 22:00
* Australia AEDT: Thursday 08:00

Please note that the time has changed. It is an hour earlier so that
it will be easier for people in Europe to attend.

-- Tim Starling

Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Legoktm | 17 Nov 22:46 2014

composer validate now running for all extensions and skins


With some help from bd808 and hashar, all extensions and skins now[1]
have a "php-composer-validate" job, which will run "composer
validate"[2] if your extension/skin's composer.json file is edited.

Some extensions are still not passing validation, so I've uploaded[3]
some changes to make them all validate. Reviews appreciated :)

-- Legoktm

[1] https://gerrit.wikimedia.org/r/#/c/173457/
[2] https://getcomposer.org/doc/03-cli.md#validate

Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Antoine Musso | 17 Nov 20:57 2014

RFC about extensions continuous integration


I have published a draft RFC about testing MediaWiki core and the
extensions all together in a single job.  As a first step limited to the
extensions deployed on the Wikimedia cluster.

That would let us catch tricky dependencies such as an incompatible
change in Mantle breaking Flow and MobileFrontend.  Currently, a change
made to Mantle does not run the tests of other extensions depending on
it.  The RFC aims to solve it

From the RFC:

We will first present how Zuul establish states of repositories for a
given patchset, then the utility that makes it trivial to reproduce such
a state on a Jenkins slave taking for example the mediawiki/core and
mediawiki/vendor tight integration that is being used today. Finally we
will propose to extend such system to all MediaWiki extensions deployed
on the Wikimedia cluster.

The link:



Antoine "hashar" Musso

Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
(Continue reading)

Amir E. Aharoni | 17 Nov 12:43 2014

broken server-side SVG rendering of a VisualEditor icon


I uploaded the following file to Commons:

The file is taken form the VisualEditor repo:

If it's viewed on the above file description page, the appearance is
broken: I see a partial circle and a rectangle.

If I view it directly in my browser then it appears correctly as a circle
with a diagonal line:

I guess that either something is broken in the SVG file or in MediaWiki's
server-side SVG to PNG rendering.

Any ideas?


Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
(Continue reading)