Quim Gil | 22 Oct 03:45 2014

Now you can submit / claim Engineering Community tasks

Following the activity of the Engineering Community team has never been
simple, not even for ourselves. Proposing Engineering Community tasks
effectively was even more complex. Here is an attempt to change this:


Since the beginning of this month, we are using Phabricator to organize the
Engineering Community team work.


You can watch, comment, and get involved. You can also submit and claim
tasks. What should we be working on next month? How can we facilitate more
tech community work done by more people?

See you there.


Quim Gil
Engineering Community Manager  <at>  Wikimedia Foundation
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Quim Gil | 21 Oct 17:03 2014

Bugzilla after Phabricator (was Re: Phabricator for code review)

On Tue, Oct 21, 2014 at 4:34 AM, Gergo Tisza <gtisza <at> wikimedia.org> wrote:

> On Sun, Oct 19, 2014 at 5:44 PM, Brian Wolff <bawolff <at> gmail.com> wrote:
> > Well there are a lot of links to it first of all.
> >
> For which a redirect is a much better solution than sending the reader to a
> dead site and leaving them to figure out it's dead. At least for direct bug
> references it should be easy to set up a rewrite rule forwarding them to a
> Phabricator search on the bugzilla ticket number.

This is what will happen: https://phabricator.wikimedia.org/T40

The main reason for keeping Bugzilla up as long as possible would be, IMO,
> the personal details which won't be migrated but help people keep track of
> their bugs of interest, often across many years - votes, saved searches,
> personal whiteboards and such.

We have committed to keep Bugzilla in read-only mode after the Phabricator
launch, and we haven't decided on any date to decommission it. We don't
need to rush to decide that date. Bugzilla will be there until the day that
it doesn't make sense to keep it. Tracked in


Quim Gil
Engineering Community Manager  <at>  Wikimedia Foundation
(Continue reading)

Strainu | 21 Oct 10:01 2014

Expected behavior of templates when a parameter appears multiple time

Assume we have the following call of a template:


What is the expected value of {{{key1}}} when parsing the template?
From the docs I've read, I would expect it to be value3. If so, does
value1 appear anywhere?


Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Quim Gil | 21 Oct 02:40 2014

Phabricator is open for new project requests

If you need a new project in https://phabricator.wikimedia.org, now you can
request it.

Please follow the instructions at

Read the guidelines! If this is your first Phabricator project, they will
probably teach you something relevant you didn't know.


Currently the creation of new projects is restricted to teams migrating
from Trello and Mingle, as well as initiatives without any presence in
Bugzilla. Members of these new projects must be aware that Wikimedia
Phabricator will be inaccessible during several days in the following
weeks, due to the RT and Bugzilla migrations. They also need to understand
that the Phabricator maintainers have limited capacity to support them
while they are focusing on the Phabricator launch.


Quim Gil
Engineering Community Manager  <at>  Wikimedia Foundation
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
MZMcBride | 21 Oct 02:32 2014

Phabricator for code viewing


Splitting off from the Phabricator for code review thread, I'm trying to
figure out if Phabricator could be a code viewer (and perhaps a code
mirror for cloning...) and whether that would be a good idea as an
intermediate step toward using Phabricator for code review. I'm thinking
about either a Phabricator application similar to ViewVC or GitBlit. Or
the more advanced option would be closer to how we currently treat GitHub.

In other words, looking at <http://phabricator.org/applications/>, are
there gradations of Phabricator code integration between nothing and
installing Differential?

Apologies if this has been discussed elsewhere and I've just missed it.


Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Chris Steipp | 20 Oct 19:38 2014

Changing edit token length

Hi list,

tl;dr: If you use a fixed length buffer to store edit tokens, you'll
need to update your code.

I'm planning to +2 https://gerrit.wikimedia.org/r/#/c/156336/ in the
next day or so. That provides for two hardening measures:

* Tokens can be time limited. By default they won't be, but this puts
the plumbing in place if it makes sense to do that on any token checks
in the future.
* The tokens returned in a request will change on each request. Any
version of the token will be good for as long as the time limit is
valid (which again, will default to infinite), but this protects
against ssl-compression attacks (like BREACH) where plaintext in a
request can be brute-forced by making many requests and watching the
size of the response.

To do this, the size of the token (which has been a fixed 32 bytes +
token suffix for a very long time) will change to add up to 16 bytes
of timestamp (although in practice, it will stay 8 bytes for the next
several years) to the end of the token.

If that's a problem for anyone, please add a review in gerrit, or
respond here. Otherwise 1.25wmf5 will have the change included.

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

C. Scott Ananian | 20 Oct 18:52 2014

Parsoid and Visual Editor folks: XML vs HTML

As devotees of web standards are aware, HTML5 is no longer an XML
variant (nor is it SGML).

This occasionally leads to fun times in Visual Editor and Parsoid
land, as we try to work around various browser incompatibilities to
ensure that documents are parsed consistently.  Parsoid uses an HTML5
parser, but it uses its own non-HTML5-spec serializer (ie, not
document.body.outerHTML) in order to emit XML-compatible documents
that work around certain browser bugs (and use intelligent quoting to
reduce document size).  Visual Editor tries to parse parsoid output
using the browser's XML serializer due to bugs in Internet Explorer (I
believe) and then fixes up the output to match the HTML5 parser spec
for <pre> tags.  I'm not sure exactly how Visual Editor serializes its
documents to send them back to Parsoid.  I bet it's not quite the same
way Parsoid serializes them.

In any case, I filed bugs with the W3C months ago to try to fix some
of the specs.  In particular, there is no official spec algorithm for
serializing an HTML document as XML.  That may now be fixed!  See
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13410 (start at comment
13 if you are impatient).

It would probably be worth auditing VE and Parsoid's serialization
algorithms to ensure that they are compatible with the new draft
standard ( http://www.w3.org/TR/DOM-Parsing/#dfn-concept-xml-serialization-algorithm
), so that we can suggest improvements if we've got interesting corner
cases and weird hacks that turn out to be needed for interoperability
in the real world.

(And see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=25225 --
(Continue reading)

reporter | 20 Oct 05:00 2014

Bugzilla Weekly Report

MediaWiki Bugzilla Report for October 13, 2014 - October 20, 2014

Status changes this week

Reports changed/set to UNCONFIRMED:  6                             
Reports changed/set to NEW        :  26                            
Reports changed/set to ASSIGNED   :  20                            
Reports changed/set to REOPENED   :  9                             
Reports changed/set to PATCH_TO_RE:  75                            
Reports changed/set to RESOLVED   :  319                           
Reports changed/set to VERIFIED   :  6                             

Total reports still open              : 15708                         
Total bugs still open                 : 9532                          
Total non-lowest prio. bugs still open: 9125                          
Total enhancements still open         : 6176                          

Reports created this week: 256                           

Resolutions for the week:

Reports marked FIXED     :  200                           
Reports marked DUPLICATE :  25                            
Reports marked INVALID   :  24                            
Reports marked WORKSFORME:  24                            
Reports marked WONTFIX   :  42                            

Specific Product/Component Resolutions & User Metrics 

Created reports per component
(Continue reading)

Bryan Davis | 20 Oct 00:13 2014

Breaking change: \Psr\Log\LoggerInterface will be required by mediawiki/core

The structured logging implementation that I began work on in February
has been making progress through code review recently following the
completion of Jenkins and Zuul tooling changes which allow the test
infrastructure to cope with the introduction of the mediawiki/vendor
repository. The next patch in the series [0] will require that all
consumers of MediaWiki from the git repository either use Composer
directly or clone the mediawiki/vendor repository to provide the PSR-3
[1] interfaces and abstract classes [2].

For the WMF production cluster, the mediawiki/vendor repository [3] is
being included as a submodule on the wmf/1.25wmfX deployment branches.
This repository is also used on the *.beta.wmflabs.org and with the
Jenkins tests. The MediaWiki-Vagrant project includes Puppet
configuration that automates the installation of \Psr\Log with
Composer as defined in the mediawiki/core/composer.json configuration
file. Developers and other users of MediaWiki via git clone can pick
one installation option or the other as they prefer.

Starting with the 1.25 release cycle (which is several months away)
the tarball release process will need to be updated to either include
the mediawiki/vendor repository or provide the required external
classes via other means.

[0]: https://gerrit.wikimedia.org/r/#/c/119941/
[1]: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md
[2]: https://github.com/php-fig/log
[3]: https://git.wikimedia.org/summary/mediawiki%2Fvendor


(Continue reading)

Alisha Jain | 19 Oct 13:03 2014

Regarding Extensive and robust localisation file format coverage

I want to work on [0] project. I have worked on parsers using Flex and
Bison and done file translation of DXF file format and text format.
Because of my past working experience in parsers I have keen interest
in this project and want to contribute to this project. I have gone
through [0] and all other links mentioned in it. I want to know about
the future plans of the mentors regarding the project, so that I can
contribute to it with my programming skills.

[0] - https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Extensive_and_robust_localisation_file_format_coverage


Alisha Jain
blog - jainalisha14.wordpress.com
"Your Failure does not define you, but your determination does."

Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
Gerard Meijssen | 19 Oct 10:15 2014

Fwd: Phabricator

I understand that Phabricator is the place to be. My user for phabricator
thinks I use an old WMF profile. Can someone please change this to this
email address for me?

As it is I am stuck. I cannot change it.
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org