Tim Starling | 26 Nov 05:10 2014

RFC meeting this week

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

* MediaWiki HTTPS policy

* Extensions continuous integration

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

-- Tim Starling

Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
James Forrester | 26 Nov 03:45 2014

Phabricator migration part II: Replacing gitblit with Diffusion

Hello all,

*TL;DR*: Reminder to please bike-shed at

Just when you thought it was safe, there's the next stage in our migration
of developer tools over to Phabricator: moving all our code into the
Diffusion module <https://www.mediawiki.org/wiki/Phabricator/Diffusion>.

This is *not* about doing code review in Phabricator; that task will be
left for another time. However, it does establish some immutable URLs and
so there's a lot of scope for discussion and verification about how exactly
we want to do things.

We currently use gitblit to provide our service at git.wikimedia.org ; it's
a down-stream, read-only, HTTPS service for browsing all our git repos.
We'd like to replace this service with the single platform of Phabricator
because (a) we need to make these decisions anyway for the code review
workstream, (b) fewer tools makes for a simpler learning environment for
newbies, and (c) more integrated tools makes for fewer hacky bots and "work
arounds" for everyone.

To explore what Diffusion looks like, compare:

   - GitBlit:
   - GitHub: https://github.com/wikimedia/visualeditor
(Continue reading)

Mark A. Hershberger | 26 Nov 01:19 2014

Composer and the end user of MediaWiki

SMW's introduction of Composer for installation has provided us with
real world examples of how the average person who installs a wiki
responds when faced with using composer.[1][2][3]

The response leads me to think that Composer is a great tool for
developers, but a horrible tool for end users.

This is frustrating because it takes care of versioning, dependency
management and installation.

Is there any app (desktop, web-based, or even mobile) that we could
point users to so that they could handle composer-based software
management without the frustration that we are currently seeing?

[1]  http://article.gmane.org/gmane.comp.web.wiki.semediawiki.user/15429

[2]  http://article.gmane.org/gmane.comp.web.wiki.semediawiki.user/17216

[3]  http://article.gmane.org/gmane.comp.web.wiki.semediawiki.user/17203


Mark A. Hershberger
NicheWork LLC

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

Legoktm | 25 Nov 06:07 2014

Skin tarballs now downloadable from mediawiki.org


There is now a Special:SkinDistributor[1] on mediawiki.org that will
allow you to download tarballs of skins that are hosted on gerrit. Since
skins have moved out of the core repository and handled like extensions
as of 1.24, it's now possible to provide an easier way to download them.

In addition, I discovered that the tarball generator (for both
extensions and skins) was including .git subdirectories in the tarballs
it was creating, causing extremely large tarballs depending on the
history. It no longer does that[2], shrinking tarballs by over 100MB in
some cases!

Thanks to Chad and Yuvi for helping with code review and the deployment!

-- Legoktm

[1] https://www.mediawiki.org/wiki/Special:SkinDistributor
[2] https://gerrit.wikimedia.org/r/#/c/174777/

Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Mark A. Hershberger | 25 Nov 04:13 2014

Final RC for 1.24

Hello everyone,

I am happy to announce the final release candidate for MediaWiki 1.24.0.
Download links are given at the end of this email.  There won't be any
more RC candidates before a final release on Wednesday unless someone
finds a really critical error.

== Changes since 1.24.0-rc.2 ==
* The composer.json file has been renamed to composer.json.sample after
  Jamie Thingelstad reported that his composer.json was overwritten by
  the tarball.

Public keys:


GPG signatures:

Mark A. Hershberger
(Wiki Release Team)

(Continue reading)

Adrien Maglo | 24 Nov 11:25 2014

Open source mobile image recognition in Wikipedia


I am not sure this is the right mailing list to introduce this project 
but I have just released Displee. It is a small Android app that allows 
to search for images in the English Wikipedia by taking pictures:
It is a kind of open source Google Goggles for images from en.wikipedia.org.

I have developed Displee as a demonstrator of Pastec http://pastec.io, 
my open source image recognition index and search engine for mobile apps.
The index hosted on my server in France currently contains about 440 000 
images. They may not be the most relevant ones but this is a start. ;-)
I have also other ideas to improve this tiny app if it has an interest 
for the community.

Displee source code (MIT) is available here:
Pastec source code (LGPL) is available here:
The source code of the Displee back-end is not released yet. It is 
basically a python3 Django application.

I will be glad to receive your feedback and answer any question!

Best regards,


Adrien Maglo
Pastec developer
(Continue reading)

Amir E. Aharoni | 24 Nov 10:46 2014

dropping bug title prefixes such as "VisualEditor:" after moving to Phab


In Bugzilla some projects used prefixes in bug titles. I guess that it was
done to make sure that people understand to what project does the bug
pertain as quickly as possible. The one that I ran into most frequently is
"VisualEditor:", and there may be others.

In Phab I see that bug (task?) lists and search results always have a
project (briefcase) tag near them. If these tags indeed appear every time
the bug title is shown, then the prefixes are redundant.

Does any object to start removing them?

(Also, I don't remember that "Phab" was ever declared as an official
abbreviation of "Phabricator", and I like it when such things are declared.
So here, I declare that "Phab" is an abbreviation of "Phabricator". Please
protest if you disagree.)

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
Quim Gil | 24 Nov 08:41 2014

Bugzilla-Phabricator migration (almost) completed

Happy Monday!

We did it. https://phabricator.wikimedia.org now contains all the Bugzilla
reports. If you need to check the original Bugzilla, it can be found at
https://old-bugzilla-wikimedia.org (never mind the certificate warning, it
will go away today or so).

Important notes:

    * If your Bugzilla activity still hasn't been assigned to you, just
wait. bzimport is processing the data of about 800 users. It assigns tasks
first, then comments. Don't be surprised if you see a task assigned to you,
while your comments still belong to bzimport.
    * Another ongoing background task: after injecting 73k tasks, it is
possible that not all the content is indexed yet, so some search results
might still be missing.
    * Join and watch the projects that matter to you. We have almost 700
new projects imported that nobody is watching currently. This is especially
relevant if you were "default CC" in Bugzilla components. Details:
and https://phabricator.wikimedia.org/T75699
    * Do not change project names and policies for now. You may break links
in Phabricator and mediawiki.org. See
    * Bugzilla URLs redirect to Phabricator (most of them) or old-bugzilla
(some). Details:

If you find bugs, please report them under the "Phabricator" project. If
you need support, ask in #wikimedia-devtools.
(Continue reading)

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)