[Wikitech-l] Codex code splitting: ResourceLoader now supports loading individual Codex components

[Roan Kattouw]

Hello everyone,

The Design Systems Team is pleased to announce that ResourceLoader now
supports basic code splitting for Codex
<https://www.mediawiki.org/wiki/Codex> components. The way this works is
similar to how Codex icons already work: you list the components you need
in your ResourceLoader module definition, and only the components you need
will be bundled. This should be helpful for performance, reducing the
amount of code that is loaded by loading only the components your feature
needs, not the entire library. Most new and existing uses of Codex should
be able to use this feature. If you maintain code that uses Codex, we
recommend trying this out!

There's documentation for how to use this feature on the Codex page on
mediawiki.org
<https://www.mediawiki.org/wiki/Codex#Requiring_Codex_components_in_MediaWiki_and_extensions>,
and you can also look at the CodexExample extension
<https://gitlab.wikimedia.org/repos/design-systems/CodexExample> for a more
complete example of how to use this feature. If you have any questions, or
run into any issues trying to use this feature, we're here to help, feel
free to reply to this email or post on the Codex talk page on mediawiki.org
<https://www.mediawiki.org/wiki/Talk:Codex>.

So far we have only implemented the most basic iteration of code splitting.
We plan on building some more advanced features to help with deduplication
of components as well. For more details about our plans, see the epic task
<https://phabricator.wikimedia.org/T349423> on Phabricator.

Roan Kattouw
Software engineer on the Design Systems Team at the Wikimedia Foundation
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Announcing Codex 1.0

[Roan Kattouw]

Today the Design Systems Team
 is announcing the
release of Codex 1.0!
What is Codex?

Codex  is the new design system
for Wikimedia. Over the past 2 years, the Design Systems Team and
contributors from the Wikimedia Foundation, Wikimedia Deutschland, and the
volunteer communities have collaborated to create a centralized design
system to serve Wikimedia projects. Codex provides more equitable
experiences for all Wikimedia movement participants, and makes it easier
and faster to design and build consistent user interfaces. With Codex, we
aim to enable more people to contribute to the mission.

Codex provides a library of design tokens
, user
interface components
, and
catalog of icons
 to use with
these components. Through the Codex Figma libraries, designers can reuse
these shared components

, tokens
,
and assets

in
their designs. For developers, Codex provides components built with Vue.js,
as well as some CSS-only components that do not require JavaScript to use.

Codex is already being used for Wikifunctions
, Vector 2022
,
the Growth Mentor Dashboard
 and Impact Module
, the New
Pages Feed

, MediaSearch ,
NearbyPages ,
QuickSurveys , and
ReadingLists .
Projects currently under development using Codex include Accessibility for
reading
 and
the Incident Reporting System
.

Codex provides a set of core components

that
cover a wide range of Wikimedia user interface needs, but does not
necessarily provide equivalents of all components in OOUI
. If you find that a component you
were expecting to use is missing, please talk to the Design Systems Team
 and
we'd be happy to help you. We strongly encourage contribution to Codex
, in
line with our vision of being a collaborative project guided by stewardship.
Why 1.0 now?

The Design Systems Team has been working towards this milestone for a
number of months now. Based on early feedback, we’ve already made
improvements to the developer experience of using Codex, like providing
ready-to-go example repos
 of using
Codex in a MediaWiki extension and changing our code snippets in the doc
site for easier copy-paste into non-TypeScript and MediaWiki-specific
projects.

We also dedicated significant time and effort ensuring accessibility of
Codex components and assets conform to WCAG 2.1 AA and other standards, and
plan to engage with groups like the American Foundation for the Blind for
further improvements.

We’ve been consolidating various design resources (like the design style
guide ) into Codex so there is a
single source of truth for Wikimedia front-end development and design
standards. This is to clarify Codex’s role not just as a UI library, but as
the design system for Wikimedia.
Who should use Codex?

Everyone! Some foundational elements like design tokens can and should be
used in all Wikimedia software going forward. Most of the MediaWiki code
that uses the older pre-token variables from mediawiki.ui has already been
migrated to use the Codex tokens instead. The Codex wiki documentation
 has more
information about using design tokens (and other elements) in MediaWiki.

At this time, Codex components are most suitable for client-side features
that don't have complex requirements for non-JavaScript support, or for
server-rendered interfaces that don't need much interactivity. Features
requiring both 

[Wikitech-l] Soliciting input on server rendering of user interfaces discussion (includes server-side rendering)

[Roan Kattouw]

Hello everyone,

In September, I submitted a proposal to the Technical Decision Making
Process called "Modern interfaces for all users" [1]. This proposal was
somewhat abstract, but it was about different ways we could render user
interfaces on the server, given that our server-side code is written in
PHP, but most UI code is written in JavaScript (including Codex[2], the new
library of shared UI components being developed by the Design Systems Team).

One solution that many people have been asking for for some time is Vue's
server-side rendering (SSR) feature[3]. Supporting Vue SSR in MediaWiki
will require in-depth architecture discussions, and I think that will
eventually be part of this TDMP too. However, there are also other
approaches for rendering UI components on the server which may be more
appropriate, depending on the situation. So before we delve into
architecture and implementation for Vue SSR, we should first discuss which
methods of rendering UIs on the server we want to use in which situations,
both to confirm that we really do need Vue SSR, and to inform the
architecture discussion.

To that end, I've started a discussion on a Phabricator task where I list
different server rendering methods and make a simple (probably too simple)
proposal for when to use which. If you're interested in this topic, please
go to https://phabricator.wikimedia.org/T322163 and participate in the
discussion there.

Roan Kattouw
Lead engineer on the Design Systems Team at the Wikimedia Foundation

[1] https://phabricator.wikimedia.org/T317270
[2] https://www.mediawiki.org/wiki/Codex
[3] https://vuejs.org/guide/scaling-up/ssr.html
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] MediaWiki now supports ES6

[Roan Kattouw]

The Vue migration team is pleased to announce that MediaWiki finally has
built-in support for writing modern JavaScript with ES6.

Up until now, all JavaScript code in MediaWiki has been written in ES5 (a
version of JavaScript standardized in 2009), because MediaWiki maintains
support for some browsers that don't support ES6. Over the years this has
become increasingly frustrating for developers, because ES6 (standardized
in 2015) adds new language features that make writing code easier and more
pleasant, but these features couldn't be used in MediaWiki. A lot of modern
code and tools are now written in ES6, and browsers that don't support ES6
have become obsolete. At this point, the only significant non-ES6 browser
that MediaWiki continues to support is Internet Explorer 11, whose usage is
relatively low, but not yet quite low enough for us to drop support for it.
In keeping with the IE11 announcement[1] from earlier this month, we will
continue to support IE11, but some new features will not support it.

What this means for developers is that you can now use ES6 code in
MediaWiki core, extensions, and skins, as long as it's in a feature that
doesn't need to support IE11. ResourceLoader modules that use ES6 code have
to be flagged as such, and you will need to put ES6 code in a separate
directory so that different eslint rules can be applied. For detailed
instructions on how to start using ES6 in your code, see
https://www.mediawiki.org/wiki/ResourceLoader/ES6 .

Unfortunately, ES6 code is not yet supported in on-wiki JavaScript
(Gadgets, user scripts, and site scripts), because we need to check that
these scripts are syntactically valid, and our current validator only
understands ES5 [2].

To make this possible, we added functionality[3] to ResourceLoader to allow
modules to mark themselves as ES6-only, and prevent those modules from
being loaded in browsers that don't support ES6. We also made significant
changes[4] to our JavaScript minifier[5] to support the minification of ES6
code, which previously generated invalid output[6] when confronted with ES6
syntax. And we updated our eslint ruleset[7] to add a linter configuration
for ES6 code[8]. Thank you to Timo Tijhof (Krinkle) and DannyS712 for code
reviewing the ResourceLoader and minifier changes, to Lucas Werkmeister for
finding a critical bug[9] in the minifier change, and to James Forrester
and Ed Sanders for code reviewing the linter changes and releasing new
versions of all these packages.

Roan Kattouw
On behalf of the Vue migration team (Anne Tomasevich, Eric Gardner, Volker
Eckl, and myself)

[1] https://www.mediawiki.org/wiki/Compatibility/IE11
[2] https://phabricator.wikimedia.org/T75714
[3] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657953
[4] https://gerrit.wikimedia.org/r/c/mediawiki/libs/Minify/+/664700
[5] https://github.com/wikimedia/Minify/
[6] https://phabricator.wikimedia.org/T26
[7] https://github.com/wikimedia/eslint-config-wikimedia
[8] https://github.com/wikimedia/eslint-config-wikimedia/pull/358
[9] https://phabricator.wikimedia.org/T277161
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How to invalidate a ResourceLoader URL that depends on user-generated content?

[Roan Kattouw]

Yes, it takes 5 minutes for just about everything to update in
ResourceLoader. This is also true for ResourceLoaderSiteStylesModule: when
you save an edit to e.g. MediaWiki:Common.css, you don't immediately see
the styles change. However, previewing edits to MediaWiki:Common.css does
work, because of some special handling.

When previewing, EditPage sets a content override (using
OutputPage::addContentOverride()) for the page being previewed, with the
text that's in the edit box. This content override is then propagated to
the ResourceLoaderContext object by OutputPage::getRlClientContext().
ResourceLoaderWikiModule checks these content overrides before accessing
wiki pages (which is how it gets the content from the edit box instead of
the content that's on the wiki page), and it also causes
shouldEmbedModule() to return true if there's a content override that
applies to it (which is how it avoids requesting the module from load.php
and instead embeds it as an inline 

Re: [Wikitech-l] Unbreak now! problem in this week train Watchlist

[Roan Kattouw]

This sounds like it could have been caused by
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/416198

‪On Thu, Mar 14, 2019 at 10:29 AM ‫יגאל חיטרון‬‎ 
wrote:‬

> Hello. There is a regression problem, that started on this week deployment.
> I can see it in group 1 from yesterday evening. I do not file a phabricator
> ticket, because there is no algorithm to reproduce the problem.
>
> From time to time the API post query "mark this revision as read" does not
> work. In these times, there is a reproducing algorithm:
> 1) Open Special:Watchlist.
> 2) Pick an unread revision.
> 3) Open the diff to last version, or the view mode of the page.
> 4) Expected: the revision, and the whole page, should be automatically
> marked as read.
> 5) Refresh the Special:Watchlist.
> 6) Got: the revision remains bold.
> 7) Open API query for unread revisions, the relevant one is still there.
> 8) Try partagraphs 5-7 every 5 seconds.
> 9) In about twenty minutes the data is updated correctly.
> I saw this yesterday at about 19:45 UTC, and it happens again just now.
> Thank you.
> Igal (User:IKhitron)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] Changes to SWAT deployment policies, effective Monday April 30th

[Roan Kattouw]

Will multi-file, single-directory syncs still be allowed? In other words,
can I deploy a change to the Foo extension that touches many files with
scap sync-dir extension/Foo ?

On Thu, Apr 26, 2018, 15:15 Greg Grossmeier  wrote:

> Hello,
>
> I have made two changes to SWAT policies today.
>
> First, we now disallow multi-sync patch deployments. See T187761[0].
> This means that the sync order of files is determined by git commit
> parent relationships (or Gerrit's "depends-on"). This is to prevent SWAT
> deployers from accidentally syncing two patches in the wrong order.
>
> Second, we are reducing the number of allowed patches from 8 to 4. This
> is to reduce stress on the SWAT deployer as well as set expectations for
> requesters on the pace of the windows. See the approximate best case
> time spent breakdown[1] for how we came to this number.
>
> I've updated the on-wiki documentation on wikitech[2][3].
>
>
> Thank you for flying scap,
>
> Greg
>
>
> [0] https://phabricator.wikimedia.org/T187761
> [1]
> * +2/Wait for Jenkins to merge - 2 min
> * prepare git on tin - 1 min
> * Deploy to mwdebug - 1 min
> * Verify on mwdebug - 3 min
> * Deploy to production - 1 min
> * Verify & wait/watch logs - 2 min
> [2]
> https://wikitech.wikimedia.org/w/index.php?title=SWAT_deploys=prev=1789212
> [3]
> https://wikitech.wikimedia.org/w/index.php?title=SWAT_deploys=next=1789212
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | Release Team ManagerA18D 1138 8E47 FAC8 1C7D |
>
> ___
> Ops mailing list
> o...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ops
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] First step for MCR merged: Deprecate and gut the Revision class

[Roan Kattouw]

Thanks!

Context for those who don't want to read a couple hundred lines of IRC
logs: I was cooped up in the house all day and noticed it was about to get
dark, so I really did take a walk (relatively abruptly) after dealing with
the worst of the issue. During this walk I thought things over and realized
what the explanation for the early symptoms of this bug was, and I
explained it to Adam on IRC when I got back.

On Fri, Dec 22, 2017 at 6:00 PM, C. Scott Ananian 
wrote:

> Having just read through T183252, I feel Roan deserves a big hand for his
> "I take a walk and become Sherlock Holmes" detective work and "I'm just
> like Indiana Jones, except with code not tombs and bugs not snakes" code
> archaeology.
>
> I love working with smart folks.
>   --scott
>
> On Fri, Dec 22, 2017 at 11:37 AM, Chad  wrote:
>
> > Considering the code just landed last night and a good number of us are
> > going to be gone for vacation--is rolling this out with the Jan 2nd
> deploy
> > a little aggressive? I'd love to see this sit on beta (with eyes on it)
> for
> > a little longer. Or a way to deploy to testwiki etc independent of major
> > sites?
> >
> > The first deploy after a holiday break is already pretty exciting, and
> > rolling this out feels like something that could use a dedicated window.
> >
> > (Otherwise, kudos to the MCR team for hitting this milestone)
> >
> > -Chad
> >
> > On Fri, Dec 22, 2017 at 2:27 AM Daniel Kinzler <
> > daniel.kinz...@wikimedia.de>
> > wrote:
> >
> > > Hello all!
> > >
> > > Addshore last night merged the patch[1] that is the first major step
> > > towards
> > > Multi-Content-Revisions[2]: it completely guts the Revision class and
> > > turns it
> > > into a thin proxy for the new RevisionStore service. The new code is
> now
> > > live
> > > on beta.
> > >
> > > This is our second attempt: The first one, on December 18th, thoroughly
> > > corrupted the beta database. It took us some time and a lot of help
> from
> > > Aaron
> > > and especially Roan to figure out what was happening. A detailed
> > > post-mortem by
> > > Roan can be found at [3].
> > >
> > > Anyway - this stage of MCR development introduces the new
> multi-revision
> > > capable
> > > interface for revision storage (and blob storage) [4]. It does not yet
> > > introduce
> > > the new database schema, that will be the next step [5][6]. While doing
> > the
> > > refactoring, I tried to keep the structure of the existing code mostly
> > > intact,
> > > just moving functionality out of Revision into the new classes, most
> > > importantly
> > > RevisionRecord, RevisionStore, and BlobStore.
> > >
> > > Beware that with the next deployment (due January 2nd) the live sites
> > will
> > > start
> > > using the new code. Please keep an eye out for any strangeness
> regarding
> > > revision handling. Adam greatly improved test coverage of the relevant
> > code
> > > (thanks Adam!), but it's always possible that we missed some edge case,
> > > maybe
> > > something about archived revisions that were partially migrated from on
> > old
> > > schema or something similarly fun.
> > >
> > > Exiting times!
> > >
> > > Cheers
> > > Daniel
> > >
> > >
> > > [1] https://gerrit.wikimedia.org/r/#/c/399174/
> > > [2]
> > > https://www.mediawiki.org/wiki/Requests_for_comment/
> > Multi-Content_Revisions
> > > [3] https://phabricator.wikimedia.org/T183252#3853749
> > > [4] https://phabricator.wikimedia.org/T174025
> > > [5] https://phabricator.wikimedia.org/T174024
> > > [6] https://phabricator.wikimedia.org/T174030
> > >
> > >
> > > --
> > > Daniel Kinzler
> > > Principal Platform Engineer
> > >
> > > Wikimedia Deutschland
> > > Gesellschaft zur Förderung Freien Wissens e.V.
> > >
> > >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> (http://cscott.net)
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Analytics] [Ops] stat1002 and stat1003 deprecated. Please use new stat boxes

[Roan Kattouw]

I would love to migrate to stat1006 from stat1003, but stat1006 is unusably
slow right now while stat1003 is snappy. Connecting to analytics-store from
stat1006 times out sometimes, and even when it doesn't, simple DESCRIBE
queries take 5-15 seconds. I just talked to Adam Wight on IRC and he's
experiencing similar issues.

On Tue, Jul 18, 2017 at 10:31 AM, Andrew Otto  wrote:

> Hi all!
>
> tl;dr: Stop using stat100[23] by September 1st.
>
> We’re finally replacing stat1002 and stat1003.  These boxes are out of
> warranty, and are running Ubuntu Trusty, while most of the production fleet
> is already on Debian Jessie or even Debian Stretch.
>
> stat1005 is the new stat1002 replacement.  If you have access to stat1002,
> you also have access to stat1005.  I’ve copied over home directories from
> stat1002.
>
> stat1006 is the new stat1003 replacement.  If you have access to stat1003,
> you also have access to stat1006.  I’ve copied over home directories from
> stat1003.
>
> I have not migrated any personal cron jobs running on stat1002 or
> stat1003.  I need your help for this!
>
> Both of these boxes are running Debian Stretch.  As such, packages that
> your work depends on may have upgraded.  Please log into the new boxes and
> try stuff out!  If you find anything that doesn’t work, please let me know
> by commenting on https://phabricator.wikimedia.org/T152712.
>
> Please be fully migrated to the new nodes by September 1st.  This will
> give us enough time to fully decommission stat1002 and stat1003 by the end
> of this quarter.
>
> I’ve only done a single rsync of home directories.  If there is new data
> on stat1002 or stat1003 that you want rsynced over, let me know on the
> ticket.
>
> A few notes:
> - stat1002 used to have /a.  This has been removed in favor of /srv.  /a
> no longer exists.
> - Home directories are now much larger.  You no longer need to create
> personal directories in /srv.
> - /tmp is still small, so please be careful.  If you are running long jobs
> that generate temporary data, please have those jobs write into your home
> directory, rather than /tmp.
> - We might implement user home directory quotas in the future.
>
> Thanks all!  I’ll send another email in about a months time to remind you
> of the impending deadline of Sept 1.
>
> -Andrew Otto
>
>
>
> ___
> Ops mailing list
> o...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ops
>
>
___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics

Re: [Wikitech-l] Wikis paused at 1.28.0-wmf.18 (was: Re: Upgrade of 1.28.0-wmf.19 to group 1 is on hold)

[Roan Kattouw]

What are your plans for when you'll deploy wmf.19, branch wmf.20 and deploy
wmf.20?

I ask because I have a patch lined up that I wanted to merge today right
after the wmf.20 branch cut, because I want it to spend the full week on
beta labs before it goes to production. I can merge that patch today and
have it go to beta, and have it go into wmf.20 once it gets cut, but I'd
only be willing to do that if I had a guarantee that wmf.20 would not be
cut before early next week. Because it's currently unknown when wmf.20 will
be cut, I don't know what's safe to do.

Unrelatedly, I also have a patch merged in master that fixes a regression
in wmf.19. Since wmf.19 is not deployed right now, the regression doesn't
affect production, but if wmf.19 is ever going to be deployed, then the fix
needs to be cherry-picked into it. Do you know if wmf.19 is going to be
deployed, or is it going to be skipped? Since wmf.19 is not deployed right
now, should I submit a cherry-pick to it for SWAT today so that it gets
unbroken in the event it ever gets deployed?

I understand that you are investigating and will reevaluate after, but it
would be nice to have these questions answered quickly so we have some
sense of what is and isn't going to happen, and aren't blocked by this
uncertainty for much longer,

On Tue, Sep 20, 2016 at 12:27 PM, Tyler Cipriani 
wrote:

> tl;dr: All wikis are staying at 1.28.0-wmf.18 for now
>
> Last week all wikis were rolled back to MediaWiki version 1.28.0-wmf.18
> due to several problems that were spotted on Friday (2016-09-16)[0][1].
>
> The problems with wmf.19 seemed resolved by Monday (2016-09-19). The
> plan was to roll wmf.19 out to all wikis yesterday afternoon and continue
> with the wmf.20 branch-cut today as scheduled.
>
> Late yesterday a large performance regression was discovered in
> wmf.18[2].
>
> We've paused the rollout of wmf.19 and the branching of wmf.20 to allow
> time to investigate the nature of this performance regression.
>
> After there is a better understanding of the performance regression, we
> will reevaluate our plans for branching and rollout of wmf.19 and wmf.20.
>
> -- Tyler
>
> [0]. https://phabricator.wikimedia.org/T111441
> [1]. https://phabricator.wikimedia.org/T145819
> [2]. https://phabricator.wikimedia.org/T146099
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] Canary Deploys for MediaWiki

[Roan Kattouw]

On Jul 25, 2016 16:12, "Bryan Davis"  wrote:
>
> I think Alex is "more right" here. If you are introducing a new $wmgX
> var you really should always sync-file the changed InitialiseSettings
> file first and then the CommonSettings that uses it. There's no really
> good reason to spew a bunch of "undefined X" warnings and there is no
> guarantee with sync-dir that the files will be sent in the proper
> order.
>

That's true, but sometimes (either because multiple changes are made, or
things are removed, or whatever) there is no sync order that does not
produce errors. This isn't common but I have had it happen. In those cases,
you'll now be forced to use sync-dir.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Ops] Canary Deploys for MediaWiki

[Roan Kattouw]

Note to deployers: when syncing certain config changes (e.g. adding a new
variable) that touch both InitialiseSettings and CommonSettings, you will
now need to use sync-dir wmf-config, because individual sync-files will
likely fail if the intermediate state throws notices/errors.

(It was a good idea to do this before, but it'll be more strongly enforced
now.)

On Jul 25, 2016 12:35, "Tyler Cipriani"  wrote:

> tl;dr: Scap will deploy to canary servers and check for error-log spikes
> in the next version (to be released Soon™).
>
> In light of recent incidents[0] which have created outages accompanied by
> large, easily detectable, error-rate spikes, a patch has recently landed in
> Scap[1] that will:
>
>1. Push changes to a set of canary servers[2] before syncing to proxy
> servers
>2. Wait a configurable length of time (currently 20 seconds[3]) for any
> errors to have time to make themselves known
>3. Query Logstash (using a script written by Gabriel Wicke[4]) to
> determine if the error rate has increased over a configurable threshold
> (currently 10-fold[5])
>
> Big thanks to the folks that helped in this effort: Gabriel Wicke, Filippo
> Giunchedi and Giuseppe Lavagetto, Bryan Davis and Erik Bernhardson (for
> their mad Logstash skillz)!
>
> It is noteworthy, that in instances where expedience is required—we're in
> the middle of an outage and who cares what Logstash has to say—the
> `--force` flag can be added to skip canary checks all together (i.e. `scap
> sync-file --force wmf-config/InitialiseSettings 'Panic!!'`).
>
> The RelEng team's eventual goal is still to move MediaWiki deployments to
> the more robust and resillient Scap3 deployment framework. There is some
> high-priority work that has to happen before the Scap3 move. In the
> interim, we are taking steps (like this one) to respond to incidents and
> keep deployments safe.
>
> Hopefully, this work and the error-rate alert work from Ori last week[6]
> will allow everyone to be more conscientious and more keenly aware of
> deployments that cause large aberrations in the rate of errors.
>
> <3,
> Your Friendly Neighborhood Release Engineering Team
>
> [0].
> https://wikitech.wikimedia.org/wiki/Incident_documentation/20160601-MediaWiki
> is the recent example I could find, but there have been others.
> [1]. https://phabricator.wikimedia.org/D248
> [2]. https://gerrit.wikimedia.org/r/#/c/294742/
> [3]. https://github.com/wikimedia/scap/blob/master/scap/config.py#L19
> [4]. https://gerrit.wikimedia.org/r/#/c/292505/
> [5]. https://github.com/wikimedia/scap/blob/master/scap/config.py#L18
> [6]. https://gerrit.wikimedia.org/r/#/c/300327/
>
> ___
> Ops mailing list
> o...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ops
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Mediawiki-api-announce] [BREAKING CHANGE] meta=notifications outputs array instead of object since 1.27.0-wmf.22

[Roan Kattouw]

As of 1.27.0-wmf.22 (deployed to WMF wikis April 26-28) and MediaWiki
release 1.27 (specifically, this change

in Echo), meta=notifications will return its result as an array rather than
an object.

Previously, the meta=notifications output looked like:

{
"query": {
"notifications": {
"list": {
"12345": {
"id": "12345",
"type": "edit-user-talk",
...
},
...
}



Now, it looks like:

{
"query": {
"notifications": {
"list": [
{
"id": "12345",
"type": "edit-user-talk",
...
},
...
]


My apologies for the late announcement, and thanks to APerson and Cienca Al
Poder for noticing  and
encouraging me to write this announcement.
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] [Mediawiki-api-announce] [BREAKING CHANGE] meta=notifications outputs array instead of object since 1.27.0-wmf.22

[Roan Kattouw]

As of 1.27.0-wmf.22 (deployed to WMF wikis April 26-28) and MediaWiki
release 1.27 (specifically, this change

in Echo), meta=notifications will return its result as an array rather than
an object.

Previously, the meta=notifications output looked like:

{
"query": {
"notifications": {
"list": {
"12345": {
"id": "12345",
"type": "edit-user-talk",
...
},
...
}



Now, it looks like:

{
"query": {
"notifications": {
"list": [
{
"id": "12345",
"type": "edit-user-talk",
...
},
...
]


My apologies for the late announcement, and thanks to APerson and Cienca Al
Poder for noticing  and
encouraging me to write this announcement.
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Wikimedia-l] Cross-wiki notifications beta feature now available on all wikis

[Roan Kattouw]

If by old notifications you mean notifications from other wikis from a
long time ago, you can dismiss those by clicking the X next to each
notification on the right-hand side. Once dismissed they shouldn't
come back. There's currently a bug with this though:
https://phabricator.wikimedia.org/T121930#2292278

We're also working through some bugs to do with notifications
sometimes not being displayed, and an issue with non-SUL wikis that's
causing notification counts to be wrong. I apologize for the
disruption. The task tracking all the fallout issues from yesterday's
deployment is https://phabricator.wikimedia.org/T135239 .

On May 13, 2016 11:39, "Fæ" <fae...@gmail.com> wrote:
>
> They don't. It's a bug.
>
> Fae
> On 13 May 2016 19:26, "Peter Southwood" <peter.southw...@telkomsa.net>
> wrote:
>
> > When do the old notifications go away?
> > Cheers,
> > P
> >
> > -Original Message-
> > From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On
> > Behalf Of Roan Kattouw
> > Sent: Friday, 13 May 2016 8:04 PM
> > To: wikimedia-l@lists.wikimedia.org
> > Subject: Re: [Wikimedia-l] Cross-wiki notifications beta feature now
> > available on all wikis
> >
> > Update: this has now graduated out of beta, and was enabled by default on
> > all wikis yesterday. If you don't want to see notifications from other
> > wikis on any given wiki, you can turn it off in your preferences (it's in
> > the "Notifications" tab).
> >
> > For more information and some background, see the blog post we published
> > yesterday: https://blog.wikimedia.org/2016/05/12/cross-wiki-notifications/
> >
> > On Thu, Mar 10, 2016 at 11:03 PM, Roan Kattouw <rkatt...@wikimedia.org>
> > wrote:
> >
> > > In late 2015 and early 2016, the Collaboration team worked on building
> > > a cross-wiki notification feature: listing notifications from other
> > > wikis in the notification panel. We made this feature available on a
> > > small set of wikis [1] initially, and about six hours ago we made it
> > > available on all wikis as a beta feature.
> > >
> > > You can enable cross-wiki notifications by clicking the "Beta" link
> > > [2] in the top right corner (or top left in RTL languages) and
> > > enabling the "Enhanced notifications" setting. The notification panels
> > > (accessible through the bell and speech bubble icons in the top
> > > right/left corner) will now display an additional item telling you
> > > which other wikis you have unread notifications on, and you can click
> > > this item to expand it and see those notifications [3]. For more
> > > information, see the documentation on mediawiki.org [4], with mostly
> > > complete translations in 13 languages at the time of this writing.
> > >
> > > Because we don't have cross-wiki preferences, enabling the beta
> > > feature on one wiki doesn't automatically enable it on any other wiki.
> > > However, you only have to enable the beta feature to see cross-wiki
> > > notifications on a wiki, not to get them from that wiki. For example,
> > > if you only enable the beta feature on the French Wikipedia, you will
> > > see notifications from the French Wikisource, the Spanish Wikipedia
> > > and the Upper Sorbian Wiktionary even if you haven't enabled the beta
> > > feature on those wikis. In fact, if you've had an account for a while,
> > > you are likely to see some very old notifications from wikis you
> > > haven't visited in years; Magnus Manske tweeted a screenshot of this
> > yesterday [5].
> > >
> > > Please try this out and let us know what you think! There's a talk
> > > page on mediawiki.org [6] where you can leave feedback. If you find a
> > > bug, please report it on Phabricator [7] or on the feedback page.
> > >
> > > Thanks a lot to the Collaboration team [8] as well as community
> > > liaisons Nick Wilson (Quiddity) and Benoît Evellin (Trizek) for their
> > > work on this over the past few months.
> > >
> > > --Roan Kattouw (User:Catrope)
> > >
> > > [1] All French wikis, all Hebrew wikis, Commons, Wikidata and
> > > mediawiki.org [2] Or go to [[Special:Preferences]] and click the "Beta
> > > features" tab [3]
> > > https://commons.wikimedia.org/wiki/File:Notification_panel_with_cross-
> > > wiki_notification.png [4]
> > > https://www.mediawiki.org/wiki/Help:Notifications/Cross-wiki
> > > [5] https://twitter.com/MagnusM

Re: [Wikimedia-l] Cross-wiki notifications beta feature now available on all wikis

[Roan Kattouw]

Update: this has now graduated out of beta, and was enabled by default on
all wikis yesterday. If you don't want to see notifications from other
wikis on any given wiki, you can turn it off in your preferences (it's in
the "Notifications" tab).

For more information and some background, see the blog post we published
yesterday: https://blog.wikimedia.org/2016/05/12/cross-wiki-notifications/

On Thu, Mar 10, 2016 at 11:03 PM, Roan Kattouw <rkatt...@wikimedia.org>
wrote:

> In late 2015 and early 2016, the Collaboration team worked on building a
> cross-wiki notification feature: listing notifications from other wikis in
> the notification panel. We made this feature available on a small set of
> wikis [1] initially, and about six hours ago we made it available on all
> wikis as a beta feature.
>
> You can enable cross-wiki notifications by clicking the "Beta" link [2] in
> the top right corner (or top left in RTL languages) and enabling the
> "Enhanced notifications" setting. The notification panels (accessible
> through the bell and speech bubble icons in the top right/left corner) will
> now display an additional item telling you which other wikis you have
> unread notifications on, and you can click this item to expand it and see
> those notifications [3]. For more information, see the documentation on
> mediawiki.org [4], with mostly complete translations in 13 languages at
> the time of this writing.
>
> Because we don't have cross-wiki preferences, enabling the beta feature on
> one wiki doesn't automatically enable it on any other wiki. However, you
> only have to enable the beta feature to see cross-wiki notifications on a
> wiki, not to get them from that wiki. For example, if you only enable the
> beta feature on the French Wikipedia, you will see notifications from the
> French Wikisource, the Spanish Wikipedia and the Upper Sorbian Wiktionary
> even if you haven't enabled the beta feature on those wikis. In fact, if
> you've had an account for a while, you are likely to see some very old
> notifications from wikis you haven't visited in years; Magnus Manske
> tweeted a screenshot of this yesterday [5].
>
> Please try this out and let us know what you think! There's a talk page on
> mediawiki.org [6] where you can leave feedback. If you find a bug, please
> report it on Phabricator [7] or on the feedback page.
>
> Thanks a lot to the Collaboration team [8] as well as community liaisons
> Nick Wilson (Quiddity) and Benoît Evellin (Trizek) for their work on this
> over the past few months.
>
> --Roan Kattouw (User:Catrope)
>
> [1] All French wikis, all Hebrew wikis, Commons, Wikidata and
> mediawiki.org
> [2] Or go to [[Special:Preferences]] and click the "Beta features" tab
> [3]
> https://commons.wikimedia.org/wiki/File:Notification_panel_with_cross-wiki_notification.png
> [4] https://www.mediawiki.org/wiki/Help:Notifications/Cross-wiki
> [5] https://twitter.com/MagnusManske/status/707712047065210882
> [6] https://www.mediawiki.org/wiki/Help_talk:Notifications
> [7]
> https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projectPHIDs=Notifications
> [8] https://wikimediafoundation.org/wiki/Staff#Collaboration
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Services] [Engineering] [Breaking Change] Scap change for deployers now live!

[Roan Kattouw]

Closing the loop from IRC:

'sync-common' is now 'scap pull'. All the other commands were just prefixed
with 'scap', e.g. 'sync-file' became 'scap sync-file'.

It would be nice if https://wikitech.wikimedia.org/wiki/How_to_deploy_code
and https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug#Staging_changes
could be updated to reflect these changes.

On Wed, May 11, 2016 at 11:21 AM, Tyler Cipriani 
wrote:

> tl;dr starting today:
>
> Use:
>   scap sync 'message for posterity'
> instead of:
>   scap 'message for posterity'
>
> Scap 3.2.0-1 is now alive and well in production which means scap
> subcommands are live.
>
> All subcommands are documented[0]. Additional documentation can be
> seen by running `scap --help` (or `scap [subcommand] --help`). If you
> have any questions feel free to ask them on-list or in IRC on #scap3
> or #wikimedia-releng.
>
> Thanks!
> Tyler Cipriani and the Deployment Working Group
>
> [0]. Mediawiki:
> https://doc.wikimedia.org/mw-tools-scap/scap2/commands.html Scap3:
> https://doc.wikimedia.org/mw-tools-scap/scap3/deploy_commands.html
>
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
___
Services mailing list
Services@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/services

[Wikimedia-l] Cross-wiki notifications beta feature now available on all wikis

[Roan Kattouw]

In late 2015 and early 2016, the Collaboration team worked on building a
cross-wiki notification feature: listing notifications from other wikis in
the notification panel. We made this feature available on a small set of
wikis [1] initially, and about six hours ago we made it available on all
wikis as a beta feature.

You can enable cross-wiki notifications by clicking the "Beta" link [2] in
the top right corner (or top left in RTL languages) and enabling the
"Enhanced notifications" setting. The notification panels (accessible
through the bell and speech bubble icons in the top right/left corner) will
now display an additional item telling you which other wikis you have
unread notifications on, and you can click this item to expand it and see
those notifications [3]. For more information, see the documentation on
mediawiki.org [4], with mostly complete translations in 13 languages at the
time of this writing.

Because we don't have cross-wiki preferences, enabling the beta feature on
one wiki doesn't automatically enable it on any other wiki. However, you
only have to enable the beta feature to see cross-wiki notifications on a
wiki, not to get them from that wiki. For example, if you only enable the
beta feature on the French Wikipedia, you will see notifications from the
French Wikisource, the Spanish Wikipedia and the Upper Sorbian Wiktionary
even if you haven't enabled the beta feature on those wikis. In fact, if
you've had an account for a while, you are likely to see some very old
notifications from wikis you haven't visited in years; Magnus Manske
tweeted a screenshot of this yesterday [5].

Please try this out and let us know what you think! There's a talk page on
mediawiki.org [6] where you can leave feedback. If you find a bug, please
report it on Phabricator [7] or on the feedback page.

Thanks a lot to the Collaboration team [8] as well as community liaisons
Nick Wilson (Quiddity) and Benoît Evellin (Trizek) for their work on this
over the past few months.

--Roan Kattouw (User:Catrope)

[1] All French wikis, all Hebrew wikis, Commons, Wikidata and mediawiki.org
[2] Or go to [[Special:Preferences]] and click the "Beta features" tab
[3]
https://commons.wikimedia.org/wiki/File:Notification_panel_with_cross-wiki_notification.png
[4] https://www.mediawiki.org/wiki/Help:Notifications/Cross-wiki
[5] https://twitter.com/MagnusManske/status/707712047065210882
[6] https://www.mediawiki.org/wiki/Help_talk:Notifications
[7]
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projectPHIDs=Notifications
[8] https://wikimediafoundation.org/wiki/Staff#Collaboration
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Analytics] Echo schema eventlogging

[Roan Kattouw]

On Wed, Mar 2, 2016 at 9:34 AM, Neil P. Quinn  wrote:

> *Schema:Edit contains no useful information that isn't already in the
>> database apart from which button people use to thank each other,*
>
>
> I assume you mean Schema:Echo? :)
>

YES. Yes. ECHO, not Edit.

I saw myself make this mistake in the other paragraph and fixed it, but
apparently I missed that one. I should write fewer emails at midnight.

Dear analytics people, please don't delete Schema:Edit or Neil will be
upset :) . But kill Schema:Echo with fire.
___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics

Re: [Analytics] Echo schema eventlogging

[Roan Kattouw]

[Reviving old thread]

I was looking at our EventLogging data today, and discovered that
Schema:Edit contains no useful information that isn't already in the
database apart from which button people use to thank each other, and if we
really care about that we can measure it separately without producing nine
gigs of unused data.

Feel free to delete the data associated with Schema:Echo (but not
Schema:EchoInteraction! We do use that one) with extreme prejudice. I've
also written a config patch to stop us from producing these events (
https://gerrit.wikimedia.org/r/#/c/274345/ ) which I will deploy in the
SWAT on Thursday.

I also found that a long-standing issue with duplicate events in
Schema:EchoInteraction wasn't fixed yet, so I wrote a patch for that too:
https://gerrit.wikimedia.org/r/274342

On Tue, Dec 15, 2015 at 11:16 AM, Jonathan Morgan 
wrote:

> Hi Nuria!
>
> Speaking for *my own particular scenario*, that solution sounds like it
> will be fine, since I don't plan on immediately performing research with
> these data.
>
> But it's obviously still the Collab team's call here--they likely have
> needs I know nothing about. Cc'ing Joe Matazzoni in case he's not following
> this already...
>
> J
>
>
>
> On Tue, Dec 15, 2015 at 9:50 AM, Nuria Ruiz  wrote:
>
>>
>> >We could blacklist this schema from the mysql database, and still keep
>> producing it.  It would be available in Hadoop either way.
>>
>> Right but I would also like to drop the table if it is not being used, if
>> data is not going to be looked at soonish there is no point in storing as
>> it will likely be deleted before it gets looked at.
>>
>> Thanks,
>>
>> Nuria
>>
>> On Tue, Dec 15, 2015 at 9:35 AM, Andrew Otto  wrote:
>>
>>> We could blacklist this schema from the mysql database, and still keep
>>> producing it.  It would be available in Hadoop either way.
>>>
>>>
>>> On Dec 15, 2015, at 12:22, Jonathan Morgan 
>>> wrote:
>>>
>>> Hi Nuria,
>>>
>>> FWIW: Although I'm not using this right now, but I could see it being
>>> useful for understanding the impact of new notification updates that are
>>> coming down the pike.[1][2]
>>>
>>> What are the costs involved in keeping this schema up?
>>>
>>> Best,
>>> J
>>>
>>> 1.
>>> https://meta.wikimedia.org/wiki/Research:Cross-wiki_notifications_user_research
>>> 2. https://phabricator.wikimedia.org/T116741
>>>
>>> On Tue, Dec 15, 2015 at 8:22 AM, Nuria Ruiz  wrote:
>>>
 Roan:

 The data for Echo schema(https://meta.wikimedia.org/wiki/Schema:Echo)
 is quite large and we are not sure is even used.

 Can you confirm either way? If it is no longer used we will stop
 collecting it.


 Thanks,

 Nuria

 ___
 Analytics mailing list
 Analytics@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/analytics


>>>
>>>
>>> --
>>> Jonathan T. Morgan
>>> Senior Design Researcher
>>> Wikimedia Foundation
>>> User:Jmorgan (WMF) 
>>>
>>> ___
>>> Analytics mailing list
>>> Analytics@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/analytics
>>>
>>>
>>>
>>> ___
>>> Analytics mailing list
>>> Analytics@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/analytics
>>>
>>>
>>
>> ___
>> Analytics mailing list
>> Analytics@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/analytics
>>
>>
>
>
> --
> Jonathan T. Morgan
> Senior Design Researcher
> Wikimedia Foundation
> User:Jmorgan (WMF) 
>
>
___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics

[Wikitech-l] Today's RFC meeting on IRC: Standardise on how to access/register JavaScript interfaces

[Roan Kattouw]

My apologies for the short notice. Normally we announce these more than one
hour in advance, but I forgot.

In today's RFC meeting, we will discuss the following RFC:

* Standardise on how to access/register JavaScript interfaces

>

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

* UTC: Wednesday 22:00
* US PST: Wednesday 14:00
* Europe CET: Wednesday 23:00
* Australia AEDT: Thursday 09:00

Roan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Analytics] Echo schema eventlogging

[Roan Kattouw]

If the data is going to be retained but would just become harder to query
(i.e. still in Hadoop but not in mysql), maybe we could nuke data that's
more than a year old (or 6 months old or something) from mysql?

On Tue, Dec 15, 2015 at 9:35 AM, Andrew Otto  wrote:

> We could blacklist this schema from the mysql database, and still keep
> producing it.  It would be available in Hadoop either way.
>
>
> On Dec 15, 2015, at 12:22, Jonathan Morgan  wrote:
>
> Hi Nuria,
>
> FWIW: Although I'm not using this right now, but I could see it being
> useful for understanding the impact of new notification updates that are
> coming down the pike.[1][2]
>
> What are the costs involved in keeping this schema up?
>
> Best,
> J
>
> 1.
> https://meta.wikimedia.org/wiki/Research:Cross-wiki_notifications_user_research
> 2. https://phabricator.wikimedia.org/T116741
>
> On Tue, Dec 15, 2015 at 8:22 AM, Nuria Ruiz  wrote:
>
>> Roan:
>>
>> The data for Echo schema(https://meta.wikimedia.org/wiki/Schema:Echo) is
>> quite large and we are not sure is even used.
>>
>> Can you confirm either way? If it is no longer used we will stop
>> collecting it.
>>
>>
>> Thanks,
>>
>> Nuria
>>
>> ___
>> Analytics mailing list
>> Analytics@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/analytics
>>
>>
>
>
> --
> Jonathan T. Morgan
> Senior Design Researcher
> Wikimedia Foundation
> User:Jmorgan (WMF) 
>
> ___
> Analytics mailing list
> Analytics@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/analytics
>
>
>
___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics

Re: [Wikitech-l] i would like that i need not set standart spacing in my code

[Roan Kattouw]

On Wed, Oct 14, 2015 at 10:23 AM, Jon Robson  wrote:

> All code standards are currently being enforced by jscs.
> They recently closed an issue to add auto-formatting
> https://github.com/jscs-dev/node-jscs/issues/516


There's also the --fix flag to jscs, which automatically fixes
whitespace-only failures.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[EE] 1.27.0-wmf.2 deployment update

[Roan Kattouw]

1.27.0-wmf.2 is being deployed to WMF wikis this week.

The highlights for Echo and Flow are:

   - User talk page notifications are now correctly marked as read
    when visiting the talk page.
   - The notifications popup no longer looks broken
    in right-to-left (RTL)
   languages.
   - The notifications popup now closes
    when the badge is clicked
   again.
   - Previewing a Flow board on Special:Undelete no longer displays
   controls that don't work .

wmf.2 will be rolled out according to the standard deployment schedule:

   - Tuesday 18:00-20:00 UTC: test wikis (mediawiki.org
   , testwiki ,
   test2wiki  and testwikidata
   )
   - Wednesday 18:00-20:00 UTC: non-Wikipedia wikis
   - Thursday 18:00-20:00 UTC: Wikipedias

Today's deployment to test wikis was rolled back because of a bug
, so wmf.2 is not currently live
anywhere.
___
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee

[EE] This list is being retired, please use wikitech-l

[Roan Kattouw]

The EE list is being retired. Any emails that were sent here should be sent
to wikitec...@lists.wikimedia.org instead.
___
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee

Re: [Wikitech-l] New RFC: better JS minification

[Roan Kattouw]

On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson  wrote:

> Thanks, I thought I was alone with being confused by this e-mail. As
> Jérémie correctly states we'll likely to get __less__ bugs with a more
> maintained library.


Less than zero? No one has managed to find a single bug in
JavaScriptMinifier.php since 2011.

I have nothing against moving to uglify (provided that source maps come
first), but don't use false arguments as a reason for migrating.

Roan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collaboration team reprioritization

[Roan Kattouw]

On Wed, Sep 2, 2015 at 6:51 AM, Risker  wrote:

> I am certain once the team has a chance to refocus, they may choose to
> examine workflows that are common across multiple Wikimedia projects that
> would benefit from improvement.  Off the top of my head, creating a
> "deletion" wizard in collaboration with a couple of large Wikipedias might
> be a starting point.


Obviously this work is still in very early stages, but deletion-related
processes are definitely on our radar. AfD on enwiki was one of our case
studies during early work on this, as you can tell from this slide in
Danny's Wikimania presentation:
https://wikimania2015.wikimedia.org/w/index.php?title=File:User%28s%29_Talk%28ing%29_-_Wikimania_2015.pdf=8


>   I suspect that the Collaboration team and the
> Community Tech team will find many overlaps in their work as they go
> forward.
>
>
Yes, we are aware that that is likely to happen, and we'll be talking to
them about that.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collaboration team reprioritization

[Roan Kattouw]

On Wed, Sep 2, 2015 at 6:21 AM, David Gerard  wrote:

> Did the stuff to port LQT threads/pages to Flow ever make it to
> production quality?
>
>
It was used to convert all LQT pages on mediawiki.org, including
[[mw:Support desk]] which is probably the largest LQT page that has ever
existed. So it meets the "WMF uses it" definition of production quality, at
least.

I don't think we currently have good documentation on how you can convert
your own wiki, but AFAIK "simply" running the convertAllLqtPages.php
maintenance script on a wiki that has both LQT and Flow installed should
work.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collaboration team reprioritization

[Roan Kattouw]

On Wed, Sep 2, 2015 at 11:20 AM, Roan Kattouw <roan.katt...@gmail.com>
wrote:

> I don't think we currently have good documentation on how you can convert
> your own wiki, but AFAIK "simply" running the convertAllLqtPages.php
> maintenance script on a wiki that has both LQT and Flow installed should
> work.
>

It turns out we do have some documentation:
https://www.mediawiki.org/wiki/Flow/Converting_LiquidThreads . It's a bit
more focused on how users will experience the conversion, but it does also
tell you which scripts to run.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimania-l] Q: Where to get Lucha Libre mask

[Roan Kattouw]

There were a lot of stands selling masks outside of Arena México (20 minute
walk from the Hilton) when we were there on Friday, but I suppose they
might only be there when there's a lucha libre event at the arena.
On Jul 19, 2015 14:46, Takashi OTA supertakot+wikima...@gmail.com wrote:

 Hi all,

 Quick question: does anyone know where I can get a Lucha Libre mask?
 I visited the night market in front of the Hilton, but failed to find one.
 Neither does the gift shop in Hilton.

 Thanks in advance,

 --Takashi

 ___
 Wikimania-l mailing list
 Wikimania-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikimania-l


___
Wikimania-l mailing list
Wikimania-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimania-l

Re: [Wikimania-l] Hotel wifi fast generally but very slow on Wikipedia

[Roan Kattouw]

Anecdotally, I can say that the hackathon network was very slow this
morning (I used the Hilton one since then), and that ssh to WMF servers on
the Hilton network had pretty bad latency.
On Jul 15, 2015 20:20, Brion Vibber bvib...@wikimedia.org wrote:

 On Wed, Jul 15, 2015 at 8:08 PM, Ralf Roletschek r...@roletschek.de
 wrote:

 I have _upload_ 7 pictures with 26 MB in 3 Minutes. (150 kB/s) but in the
 time, who are the most eating ;)

 https://commons.wikimedia.org/wiki/Special:ListFiles?limit=7user=Ralf+Roletschekilshowall=1


 Heh... on further poking, I can confirm that uploads run at the full ~500
 kbytes/sec for me, but the response download *on the same connection* is
 right back down to 20-30 kbytes/sec.

 Wird! :D  When I get back downstairs I'll retest on the hackathon
 network, see if that behaves different from the hotel one.

 -- brion



 Ralf

 2015-07-15 19:45 GMT-05:00 Brion Vibber bvib...@wikimedia.org:

 I'm seeing verry slow downloads from Wikipedia on the hotel wifi, on
 the order of 20-30 kbytes/sec, whereas I get a very respectable 500
 kbytes/sec to everywhere else.

 slow test URLs:


- https://en.wikipedia.org/wiki/Mexico
-

 https://upload.wikimedia.org/wikipedia/commons/transcoded/b/b7/How_Open_Access_Empowered_a_16-Year-Old_to_Make_Cancer_Breakthrough.ogv/How_Open_Access_Empowered_a_16-Year-Old_to_Make_Cancer_Breakthrough.ogv.360p.ogv

 vs fast downloads from my test site:


-

 https://brionv.com/misc/mjpeg/How_Open_Access_Empowered_a_16-Year-Old_to_Make_Cancer_Breakthrough.ogv.160p.mov

 or the speed test widget at http://speedtest.comcast.net

 Does anybody know if this might be some kind of throttling specific to
 Wikipedia (did they notice we're all using it? ;) or a technical problem
 between our servers and the hotel's ISP?

 -- brion


 ___
 Wikimania-l mailing list
 Wikimania-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikimania-l




 --
 --
 Ralf Roletschek
 https://commons.wikimedia.org/wiki/User:Ralf_Roletschek
 Fragen zum Fahrrad? - http://www.fahrradmonteur.de

 ___
 Wikimania-l mailing list
 Wikimania-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikimania-l



 ___
 Wikimania-l mailing list
 Wikimania-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikimania-l


___
Wikimania-l mailing list
Wikimania-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimania-l

Re: [EE] wmf13 deployment update

[Roan Kattouw]

On Wed, Jul 8, 2015 at 6:12 PM, Roan Kattouw rkatt...@wikimedia.org wrote:

 Over the next few days, wmf13 will be deployed to WMF wikis. We mostly
 worked on small fixes this week and on the cawiki deployment, so there
 aren't that many exciting things in wmf13. Some of the more noteworthy
 things new in wmf13 are:


Sorry, that was copy-pasted from the wmf12 email. We did in fact do
exciting things in wmf13, the TOC change was pretty big for example.
___
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee

[EE] wmf13 deployment update

[Roan Kattouw]

I try to send out these emails on Tuesdays, apologies for the delay.

Over the next few days, wmf13 will be deployed to WMF wikis. We mostly
worked on small fixes this week and on the cawiki deployment, so there
aren't that many exciting things in wmf13. Some of the more noteworthy
things new in wmf13 are:

   - The table of contents dropdown (Browse topics) in Flow was rewritten
   https://phabricator.wikimedia.org/T96890 and now looks a bit
   different. It also no longer appears in non-JS mode (where it already didn't
   work https://phabricator.wikimedia.org/T86844).
   - Flow diff views now have an undo link
   https://phabricator.wikimedia.org/T101738 that lets you undo an edit
   to a post (undo links were already present in the history view). Diff views
   also no longer have https://gerrit.wikimedia.org/r/#/c/222356/
   duplicate Older edit / Newer edit links.
   - Single lines in the grouped Recent Changes now have links
   https://phabricator.wikimedia.org/T104399 that let you patrol Flow
   posts, just like multi-line groups already did.

wmf13 follows the standard deployment timeline, which is as follows:

   - Tuesday 11am-1pm PDT: deployment to test wikis (group 0); for Flow,
   these are testwiki https://test.wikipedia.org/, test2wiki
   https://test2.wikipedia.org/ and mediawiki.org
   https://www.mediawiki.org/
   - Wednesday 11am-1pm PDT: deployment to non-Wikipedia wikis (group 1);
   for Flow, these are meta https://meta.wikimedia.org/, officewiki
   https://office.wikimedia.org/ and wikidata https://www.wikidata.org/
   - Thursday 11am-1pm PDT: deployment to Wikipedias (group 2); for Flow,
   these are the English https://en.wikipedia.org/, French
   https://fr.wikipedia.org/, Hebrew https://he.wikipedia.org/,
   Portugese https://pt.wikipedia.org/, Catalan
   https://ca.wikipedia.org/, Telugu https://te.wikipedia.org/, Russian
   https://ru.wikipedia.org/, Punjabi https://pa.wikipedia.org/ and
   Chinese https://zh.wikipedia.org/ Wikipedias

In other news, we also plan to convert most of the remaining LiquidThreads
pages on mediawiki.org to Flow soon, now that the last email spam bug
https://phabricator.wikimedia.org/T104087 is fixed. If everything goes
well, this will probably happen late Thursday / early Friday UTC. We have
already converted almost 300 pages; we plan to convert all remaining pages
tomorrow, except for the Support desk
https://www.mediawiki.org/wiki/Project:Support_desk and VisualEditor
Feedback https://www.mediawiki.org/wiki/VisualEditor/Feedback pages. See
the Phabricator task https://phabricator.wikimedia.org/T92303 for details.
___
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee

[EE] Weekly deployment update

[Roan Kattouw]

I try to send out these emails on Tuesdays, apologies for the delay.

Over the next few days, wmf12 will be deployed to WMF wikis. We mostly
worked on small fixes this week and on the cawiki deployment, so there
aren't that many exciting things in wmf12. Some of the more noteworthy
things new in wmf12 are:

   - Timestamp link in grouped recent changes now points somewhere useful
   https://phabricator.wikimedia.org/T102021
   - Topic history pages are now full-width
   https://phabricator.wikimedia.org/T93028

wmf12 follows the standard deployment timeline, which is as follows:

   - Tuesday 11am-1pm PDT: deployment to test wikis (group 0); for Flow,
   these are testwiki https://test.wikipedia.org/, test2wiki
   https://test2.wikipedia.org/ and mediawiki.org
   https://www.mediawiki.org/
   - Wednesday 11am-1pm PDT: deployment to non-Wikipedia wikis (group 1);
   for Flow, these are meta https://meta.wikimedia.org/, officewiki
   https://office.wikimedia.org/ and wikidata https://www.wikidata.org/
   - Thursday 11am-1pm PDT: deployment to Wikipedias (group 2); for Flow,
   these are the English https://en.wikipedia.org/, French
   https://fr.wikipedia.org/, Hebrew https://he.wikipedia.org/,
   Portugese https://pt.wikipedia.org/, Catalan
   https://ca.wikipedia.org/, Telugu https://te.wikipedia.org/, Russian
   https://ru.wikipedia.org/, Punjabi https://pa.wikipedia.org/ and
   Chinese https://zh.wikipedia.org/ Wikipedias

In non-wmf12-related news, we also enabled
https://phabricator.wikimedia.org/T99117 Flow in the Viquipèdia Discussió
namespace on Catalan Wikipedia yesterday. This happened between 21:55 and
22:15 UTC on June 30.
___
EE mailing list
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee

Re: [Mediawiki-api] [Mediawiki-api-announce] Changes to meta=siteinfo with formatversion=2

[Roan Kattouw]

On Tue, Jun 16, 2015 at 1:36 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
 wrote:

 Note that formatversion=2 is still considered slightly experimental, in
 that backwards-incompatible changes like this can still happen. If you see
 any other changes like this that should be made, please report them!

 Starting in 1.26wmf11, the following changes will be made in the output
 from meta=siteinfo when formatversion=2 is in use:

- Output from siprop=namespaces will be an array, rather than an
object indexed by namespace number. See T102645.[1]


This was reverted in https://gerrit.wikimedia.org/r/#/c/219514/ . The
output of siprop=namespaces will not change in 1.26wmf11.
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Multimedia] IE Wikipedia [Microsoft] (Ref# 741977)

[Roan Kattouw]

Actually copying in the multimedia mailing list correctly this time.

Note: this mailing list is open to the public, and any emails you send
to it will be publicly archived forever at
https://lists.wikimedia.org/pipermail/multimedia . This is standard
fare for Wikimedians, but the Microsoft people on this thread may not
be used to this.

On Wed, Nov 12, 2014 at 7:13 PM, Roan Kattouw rkatt...@wikimedia.org wrote:
 Copying in:
 * Multimedia team because this concerns video playback
 * Oliver because he maintains ua-parser
 * Erik Z because he maintains browser statistics
 * Timo because he cares about browsers and relationships with the browser
 communities

 On Wed, Nov 12, 2014 at 6:42 PM, Rob Macias (Axelerate)
 v-ro...@microsoft.com wrote:

 Hello All,



 As you may have heard, we rolled out a new Windows 10 preview build with
 significant IE interoperability updates and wanted to make sure our
 Wikipedia partners are in the loop. A major part of this update is the
 “Edge” mode platform, which seems to affect how IE is being detected – this
 is leading to Video playback errors when visiting the wikimedia.org domain.
 More info on ‘living on the edge’ exists here
 http://blogs.msdn.com/b/ie/archive/2014/11/11/living-on-the-edge-our-next-step-in-interoperability.aspx



 To our Wikipedia folks:

 Mind taking a look at this? Bug detail has been pasted below including
 steps to reproduce and developer notes. If you aren’t already a member of
 the Windows Insider Program, we recommend doing so OR you can download
 RemoteIE, which provides another option for testing your site in the latest
 version of IE.




 I'm not aware of us being a member. Timo, could you look into whether we
 are, and whether we should be?

 RemoteIE looks really useful. It doesn't seem to be available for Ubuntu
 though? Our engineering staff is split roughly 50/50 between Mac OS and
 Ubuntu / other Linux flavors, so if RemoteIE is only available for Windows
 and Mac OS on desktop, then it's only useful for about half our staff. But
 that's still a heck of a lot better than passing a Windows laptop around the
 office :)


 (Bug Specs)

 Reference #: 741977

 Description of the Problem: commons.wikimedia.org: Video is not being
 played

 Steps to Reproduce:

 1. Navigate to URL: http://commons.wikimedia.org/wiki/Main_Page.

 2. Scroll down to video window

 3. Invoke Play button to play video/ audio on the page.



 Actual Result:

 Video is not being played only black screen is displayed and instead of
 playing video, it is asking  to save the file.



 Expected Result:

 Video should load and play properly.




 Multimedia team, could you guys look into this?


 Developer Notes:

 With the introduction of the Edge mode platform, the site needs to account
 for the latest UA string changes. See below:



 Mozilla/5.0 (Windows NT 6.4; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
 Chrome/36.0.1985.143 Safari/537.36 Edge/12.0



 These changes help prevent IE from being (incorrectly) identified as an
 earlier version.




 Thanks for letting us know that the UA string changed.

 Timo, Oliver and Erik Z: you guys should know about this UA string change.
 It'll affect jquery.client, ua-parser, our browser stats, and probably other
 bits of code here and there that will presumably identify this UA as Chrome
 36 rather than IE 12.


 Please let me know if you have an estimated timeframe to address this
 issue, and if our team can further assist in this process.




 Most likely, someone on the multimedia team will file a ticket for this in
 our public bug tracker, which you can subscribe to.

 Roan

___
Multimedia mailing list
Multimedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia

Re: [Wikitech-l] [Wmfall] Marielle Volz joins Wikimedia as Software Developer

[Roan Kattouw]

On Mon, Oct 27, 2014 at 11:48 AM, Tomasz Finc tf...@wikimedia.org wrote:
 I am pleased to announce Marielle Volz joining the Wikimedia
 Foundation as a Software Engineer for the Editing team.

Welcome Marielle!

 and started developing a node.js service Citoid[5] to
 make it easy to insert citations using a URL/DOI/Title in VE/Wikitext.

To put that into perspective: she's working on a feature in VE that
will let you paste in a URL to, say, a New York Times article, and
will then automatically generate and insert a {{cite news}} template
for you with all the right information (title of the article, author,
date, etc.). Some of you may have seen the demo that she and Erik did
at a metrics meeting earlier this year. This is really exciting,
because it's a big step forward towards the goal of making even
relatively complex tasks like inserting citations more convenient in
VE than in wikitext.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC meeting this week

[Roan Kattouw]

On Tue, Oct 7, 2014 at 4:08 AM, Tim Starling tstarl...@wikimedia.org wrote:
 * Australia AEST: Thursday 07:00

Ironically, Tim miscalculated the time in his own timezone :D it's 08:00 AEST.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Mediawiki-i18n] Bug in JS implementation of plural?

[Roan Kattouw]

On Mon, Aug 25, 2014 at 12:50 PM, Jon Robson jdlrob...@gmail.com wrote:
 I think I found a bug and wanted to check if I'm doing it wrong, or if
 it is indeed a bug and if so if there is somewhere I can track it?

 {{PLURAL:$1|$3 started this topic|A|0=B|2=C|3=$3}}
 mw.msg( flow-topic-participants, 3 )
 'A'

 However
 {{PLURAL:$1|$3 started this topic|A|0=B|2=C|3=D}}
 mw.msg( flow-topic-participants, 3 )
 'D'

 Is there any workaround I can use?

I don't recognize the feature you are using. Was this added recently,
like in the last 2-3 years? If so, what's probably going on is that
the JS implementation of PLURAL simply predates this feature.

Roan

___
Mediawiki-i18n mailing list
Mediawiki-i18n@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n

[Wikitech-l] Tell my favorite conference about your Wikimedia tech

[Roan Kattouw]

The linux.conf.au conference, which I have presented to and love going
to, just opened up its call for talks: http://linux.conf.au/cfp . They
want talks about all kinds of open source programming stuff, not just
Linux: Trevor and I presented about ResourceLoader in 2012, and James
and I  presented about VisualEditor in 2014.

LCA 2015 will be 12-16 January in Auckland, New Zealand. That's summer
in the Southern  Hemisphere, and the climate there is very moderate,
so no sweltering heat like in Australia :)

LCA provides travel funding to some speakers, and Wikimedia funds TPS
grants for people going  to conferences to talk about
Wikimedia-related things: https://meta.wikimedia.org/wiki/Grants:TPS .
So you could even get to go for free.

LCA is basically my favorite conference - the talks are great and of
high quality, they treat speakers well, and their audience gets what
we're doing. This is a fun chance to show off your project. I
encourage you to suggest a talk, or tell someone else that they should
talk about their project.

Roan

P.S.: Thanks to Sumana for writing most of this email, and for talking
me into proposing a talk for LCA in the first place back in 2011

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tell my favorite conference about your Wikimedia tech

[Roan Kattouw]

On Jun 12, 2014 4:08 PM, Luis Villa lvi...@wikimedia.org wrote:
 I got a balloon ride the year I spoke. It was trumped the next year by a
 helicopter ride. Definitely an amazing trip.

Wow, when was that?! I got no such thing :)

In 2012 they did take all the speakers a show (and dinner) at a staged Gold
Rush town (which is the *the* tourist attraction in Ballarat), in 2014 it
was just a dinner at the local marina.

Roan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimania-l] Registration payment options

[Roan Kattouw]

On Jun 4, 2014 10:37 AM, Michael Snow wikipe...@frontier.com wrote:

 On 6/4/2014 10:14 AM, Joseph Fox wrote:

 Pretty sure the difference is that in the US, “debit cards” as we Brits
know them are rare.

 Not at all, debit cards are a routine feature for checking accounts in
the US. But yes, if your debit card has a logo for one of the big payment
processors, then most merchants displaying that logo should be able to
accept it, even if their transactions use a credit function rather than the
debit function.

The problem is that in many continental European countries, MasterCard/Visa
cards with 16-digit numbers etc are things that most people don't have.
Payments are made using chipPIN cards or bank transfer.

I've always been baffled by how hesitant UK-based individuals and companies
are to give me their bank account information (so I can send them money),
citing security concerns.

Roan
___
Wikimania-l mailing list
Wikimania-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimania-l

Re: [Wikitech-l] Bot flags and human-made edits

[Roan Kattouw]

On Mon, May 19, 2014 at 4:09 PM, Dan Garry dga...@wikimedia.org wrote:
1. When editing via the API, allows the user to choose whether or not to
flag an edit as a bot edit using the bot parameter.
I'm responsible for this part of the mess. I don't remember why it was
done this way though. I think the people that I took over the API edit
code from had put this feature in and I kept it.

What I think was going on is that no one could be bothered to figure
out how to represent I am a human editing using a bot account and I'd
like this edit to not be bot-flagged in the UI, so it wasn't done.
But in the API it was trivial (bot=1), so it was done.

That's just my recollection of it and it's probably flawed, this was
6-7 years ago.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [WikimediaMobile] [ve-tech] [spike] Determine where the performance problems are with VE

[Roan Kattouw]

On May 15, 2014 10:27 AM, Roan Kattouw rkatt...@wikimedia.org wrote:
 Ed has been fixing some things to do with shields and phantoms. I'll send
you some Gerrit links in a minute.

https://gerrit.wikimedia.org/r/#/c/133236/

https://gerrit.wikimedia.org/r/#/c/130823/

The former should address the importNode problem Jon mentioned and the
latter should improve CSS performance, as it addresses something similar to
a problem in MF that Jon reported.

As James said, new performance feedback after these changes (though in
fairness one of them was merged only this week) would be helpful. We think
we've quashed most of the things Jon flagged initially, but we may not have
done so adequately or new problems may now be surfacing.

Roan
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [ve-tech] [spike] Determine where the performance problems are with VE

[Roan Kattouw]

On Thu, May 15, 2014 at 3:58 PM, Jon Robson jrob...@wikimedia.org wrote:
 I'm still waiting for Kaldari or someone in mobile to merge
 https://gerrit.wikimedia.org/r/131892 before I can confirm the current
 state.

 It definitely seems to be marginally improved on desktop and mobile
 (with desktop benefiting most) after a few runs.

Cool. Earlier, you did some profiling and identified specific
culprits. Are those now gone/different?

BTW, I hear we're upgrading jQuery to 1.11, according to Timo this
made our unit tests run faster and should make everything run faster
in general.

Roan

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [Wikitech-l] [Wmfall] Rob Moen takes on new role in Growth team

[Roan Kattouw]

Thanks for all your work on VE, Rob, and best of luck on the growth team!

Roan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Roadmap and deployment highlights - Week of April 14th

[Roan Kattouw]

On Fri, Apr 11, 2014 at 4:15 PM, Greg Grossmeier g...@wikimedia.org wrote:
 * VisualEditor fixes:
 ** Adding a reference adds an empty one; editing a reference inserts a
new one
 ** fix JS error on opening redirect pages

+Enable VisualEditor on French Wikinews per community request

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimania-l] Setting ticket prices

[Roan Kattouw]

On Mar 23, 2014 3:30 PM, Manuel Schneider manuel.schnei...@wikimedia.ch
wrote:
 (how does the LinuxConf.au distinguish whether one is hobbyist or
 professional)?

They give additional perks to piratical l professional attendees, like more
swag, a listing on the web site (IIRC), employer name on badge (IIRC) and a
ticket to the Professional Delegates Networking Dinner. But mostly it's the
honor system: people are told that if their employer is paying for their
attendance, they are expected to get a professional ticket, so people
paying their own way can get a hobbyist or student ticket. In my experience
most companies respect this: the honor system seems to be working pretty
well for them.

Roan
___
Wikimania-l mailing list
Wikimania-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimania-l

Re: [Wikitech-l] Grrrit-wm down for a few hours

[Roan Kattouw]

On Mon, Mar 17, 2014 at 10:33 AM, Yuvi Panda yuvipa...@gmail.com wrote:
 Hello!

 I was a terrible maintainer, and forgot to migrate grrrit-wm to eqiad
 tools before the cutoff date. As a result, it will be down for a few
 hours as Coren does a batch migrate of all the things. Apologies for
 the disruption

The migration seems to have finished (for lolrrit-wm at least) 20
minutes ago. I kicked it and it now seems to be back up.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [WikimediaMobile] [ve-tech] Re: MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox - Build # 349 - Failure!

[Roan Kattouw]

On Feb 13, 2014 4:28 PM, Trevor Parscal tpars...@wikimedia.org wrote:

 I could, but I'm having DNS issues. Basically, you need to update
MediaWiki core, so you get the latest oojs-ui, which adds such support.

 In short - they are out of sync.

This is on beta labs, so while I suppose it's possible that things are out
of sync there, it seems unlikely.

I'll take a look later today.

Roan
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [Wikitech-l] [Wmfsf] Announcement: Kunal Mehta joins Wikimedia as Features Contractor

[Roan Kattouw]

On Thu, Dec 12, 2013 at 5:08 PM, Terry Chay tc...@wikimedia.org wrote:
 Hello everyone,

 It’s with great pleasure that I’m announcing that Kunal Mehta[1] has joined
 the Wikimedia Foundation as contractor in Features Engineering.

Sweet! Welcome, Kunal!

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Mediawiki-api-announce] [BREAKING CHANGE] Fwd: [Wikitech-l] Update to Echo api

[Roan Kattouw]

Fowarding on behalf of Benny and legoktm.

This change in the Echo API was announced on wikitech-l earlier, but
failed to make it to the API list.

it will be removed once ... from the message below has now happened:
https://gerrit.wikimedia.org/r/#/c/84870/ will be merged today, and
will be deployed to Wikimedia wikis in phases between December 12th
and December 19th.


-- Forwarded message --
From: Benny Situ bs...@wikimedia.org
Date: Mon, Nov 18, 2013 at 6:19 PM
Subject: [Wikitech-l] Update to Echo api
To: mobile-tech mobile-t...@wikimedia.org, Wikimedia developers
wikitec...@lists.wikimedia.org, mediawiki-...@lists.wikimedia.org,
Kunal Mehta lego...@wikimedia.org


Hello,

We made some change to Echo api recently. The api ApiEchoNotifications
mixed both read and write actions, we have migrated the 'markasread' action
to its own api module - ApiEchoMarkRead.  The 'markasread' function still
works in ApiEchoNotifications but it will be removed once all external api
calls have been migrated to the new API.

Example about how to use the new API is in here:
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FEcho.git/40ea204cdc64e4e6f4d3589e261baa5476e420e0/api%2FApiEchoMarkRead.php

Thanks,
___
Wikitech-l mailing list
wikitec...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] [Mediawiki-api-announce] [BREAKING CHANGE] Fwd: [Wikitech-l] Update to Echo api

[Roan Kattouw]

Fowarding on behalf of Benny and legoktm.

This change in the Echo API was announced on wikitech-l earlier, but
failed to make it to the API list.

it will be removed once ... from the message below has now happened:
https://gerrit.wikimedia.org/r/#/c/84870/ will be merged today, and
will be deployed to Wikimedia wikis in phases between December 12th
and December 19th.


-- Forwarded message --
From: Benny Situ bs...@wikimedia.org
Date: Mon, Nov 18, 2013 at 6:19 PM
Subject: [Wikitech-l] Update to Echo api
To: mobile-tech mobile-t...@wikimedia.org, Wikimedia developers
wikitec...@lists.wikimedia.org, mediawiki-api@lists.wikimedia.org,
Kunal Mehta lego...@wikimedia.org


Hello,

We made some change to Echo api recently. The api ApiEchoNotifications
mixed both read and write actions, we have migrated the 'markasread' action
to its own api module - ApiEchoMarkRead.  The 'markasread' function still
works in ApiEchoNotifications but it will be removed once all external api
calls have been migrated to the new API.

Example about how to use the new API is in here:
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FEcho.git/40ea204cdc64e4e6f4d3589e261baa5476e420e0/api%2FApiEchoMarkRead.php

Thanks,
___
Wikitech-l mailing list
wikitec...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Wikitech-l] Module storage is coming

[Roan Kattouw]

On Tue, Dec 3, 2013 at 12:30 AM, Ori Livneh o...@wikimedia.org wrote:
 We'll gradually enable module storage on all Wikimedia wikis over the
 course of the next week or two.
Ori deployed this to the live site earlier today :) . For reference,
the original post about module storage is archived at [1].

I tweeted an impressive graph from Ganglia [2] that Ori shared on IRC
a little while after the deployment, and consequently my phone is now
blowing up as lots of people are retweeting it and replying to it.
Turns out lots of people are interested in Wikipedia :)

However, while the graph was impressive, there were some caveats:
* It was of internal traffic into the Apache backends serving bits,
not the Varnish caches
* The Varnish traffic (that actually get all the traffic) dropped
suddenly but not very sharply, and the drop was insignificant compared
to time-of-day and day-of-week variance
* The drop occurred because ResourceLoaderLanguageDataModule had a bug
in its mtime computation, causing it to recache all the time; module
storage greatly dampened the impact of that bug. The bug was
identified later that day and fixed by Krinkle [3], in the commit with
probably the highest commit-message-to-diff ratio of all time.

Although it wasn't really responsible for the huge drop we saw in
the graphs, make no mistake, this is awesome. Thanks Ori, for working
on this and putting up with my code review slowness and nitpicking :)

One interesting response I got on Twitter [4] said we should avoid
localStorage in favor of indexedDB and modern async APIs. I suppose
we could look into that :)

Roan

[1] http://lists.wikimedia.org/pipermail/wikitech-l/2013-November/072839.html
[2] https://twitter.com/catrope/status/408018210529615872
[3] https://gerrit.wikimedia.org/r/#/c/99010/
[4] https://twitter.com/andreasgal/status/408108587320623104

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VE/Migration guide for gadgets developers

[Roan Kattouw]

On Tue, Sep 24, 2013 at 11:45 AM, Sumana Harihareswara
suma...@wikimedia.org wrote:
 Roan, how did that go? Any links? :-)

The code ended up being written and merged. The documentation ended up
not being written before Wikimania, and then Life happened. Some Time
Soon I hope to get around to actually writing this up properly.

In the meantime, https://gerrit.wikimedia.org/r/#/c/75270/ fixes a
ResourceLoader bug that fatally breaks VE's plugin infrastructure for
on-wiki scripts (Gadgets and user/site JS), so until that's merged and
deployed, the interface I'd be documenting doesn't actually work
anyway.

Another thing I'm gonna do soon is take the GSoC project code for Math
and SyntaxHighlight and move it out of the VisualEditor extension into
the respective extensions. That'll be a good showcase for the
extension plugin integration, which does already work. Right after I
get that done would be a good time to document this, because I'll have
just gone through the process and know the pitfalls etc. first-hand.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?

[Roan Kattouw]

On Wed, Sep 25, 2013 at 2:53 PM, Chad innocentkil...@gmail.com wrote:
 wmf-foo - 1.22wmf19
 wmf-bar - 1.22wmf20
 wmf-baz - 1.22wmf21
 wmf-foo - 1.22wmf22
 wmf-bar - 1.22wmf23

This looks like it's exactly the same concept as slot0/slot1/slot2 in
Ryan's git-deploy proposal.

The objection that I would have to this is that it makes the
cherry-picking workflow less intuitive. You have to know which of
wmf-{foo,bar,baz} to cherry-pick to, rather than being able to
cherry-pick to wmf23 or whatever. Also, because the wmfN tags can only
be created after they're no longer live (because only at that point do
we know they'll have stopped changing), you can't actually find the
*current* wmfN anywhere, because it won't have been tagged yet.

The motivation is to stop making new branches all the time, but tags
and branches are equally cheap. A tag is just a frozen branch that
can't advance. If you're trying to tag something but it can still
change, use a branch. And that's what our deployment branches are,
IMO.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?

[Roan Kattouw]

On Wed, Sep 25, 2013 at 3:46 PM, Chad innocentkil...@gmail.com wrote:
 I actually like this idea a lot and it's way less confusing than my idea.
 Unless anyone's got any objections I'm going to go ahead and do this
 for all the 1.20 and 1.21 wmf branches.

Sounds good to me.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimania-l] a thought: break events

[Roan Kattouw]

On Aug 15, 2013 8:20 PM, WereSpielChequers werespielchequ...@gmail.com
wrote:

 I've been to three Wikimanias but not the last two, so my comments may be
out of date. But the format where you have multiple concurrent threads each
with three talks run one after another between breaks quickly gets out of
sync. It really needs a strong session moderator in each room who can end
things on schedule, otherwise it can be very unfair to the third presenter
who sometimes finds that the first two have each taken a third of their
time. Also it is impossible to plan your day to attend multiple sessions
across threads, especially if between two breaks you want to see the first
session in thread 1 the second session of thread two and the third of
thread 3.

This one actually had explicitly scheduled talks. There were still
90-minute slots with 2 or 3 talks in them, but the schedule indicated
visually whether this was divided 60-30 or 45-45 or what have you.

I think this was an improvement over the 2011 model, and Deryck, who made
the printed schedule, agreed.

Roan
___
Wikimania-l mailing list
Wikimania-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimania-l

Re: [Wikimania-l] People staying on after Wikimania in Hong Kong?

[Roan Kattouw]

On Aug 11, 2013 12:18 PM, Yuvi Panda yuvipa...@gmail.com wrote:

 Hello! I'm staying on for an extra week in Hong Kong after Wikimania
 (yay vacations!), and wondering if there are more people staying on I
 could catch up with?

I'm here until Wednesday morning. Thinking of doing a day trip to Macau on
Tuesday.

Roan
___
Wikimania-l mailing list
Wikimania-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimania-l

Re: [Wikimania-l] Meet the VisualEditor team!

[Roan Kattouw]

On Fri, Aug 9, 2013 at 1:14 PM, Erik Moeller e...@wikimedia.org wrote:
 Wikimaniacs,

 if you'd like to meet with the VisualEditor team and talk to us about
 how to improve VE, we are doing daily workshops in N112 at 1-2PM (i.e.
 starting now). There will also be VE team members in that location
 most times of the day, so come hang out with us :-)

There is now a big banner with the VisualEditor logo showing the way
to our little VE lounge in N112. It's behind the lunch stands in the
main square, so come to our workshops at lunchtime, or drop in any
other time. Most of the VE team members are wearing light blue or
green t-shirts with VisualEditor logos, so we should be easy to find
:)

Roan

___
Wikimania-l mailing list
Wikimania-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimania-l

Re: [Wikitech-l] Git migration: complete

[Roan Kattouw]

On Fri, Jul 26, 2013 at 2:57 PM, Chad innocentkil...@gmail.com wrote:
 With the moving of pywikibot to Gerrit today, the last projects actively
 using SVN have
 been moved over to Git. As such, SVN is now a read-only service and the
 migration is
 done (of course any old SVN projects can always be migrated to Git/Gerrit,
 that's easy).

\o/

 Thanks to everyone for your patience, help, bug reports, blood, sweat,
 tears, firstborn
 children...whatever you gave to this monumental effort over the past year
 and a half.

And thank you, for giving this migration more blood, sweat and tears
than anyone else!

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimedia-l] Communication plans for community engagement

[Roan Kattouw]

Nathan nawrich@... writes:
 I think your anti-Americanism is misplaced. Let's look at some of the
 key people involved in the VisualEditor project. Erik is German, James
 F is British, Roan Kattouw is Dutch, Timo Tijhof is Dutch. If you were
 to skim the list of the engineering staff, they are extremely diverse,
 with many remote employees throughout Europe and a number of relocated
 Europeans (and others) working in San Francisco.

Fun fact: VisualEditor is a minority-American, majority-remote operation.

WMF's VisualEditor engineering team consists of:
* Trevor Parscal (SF office; from the US)
* Myself (SF office; from the Netherlands)
* Rob Moen (SF office; from the US)
* Timo Tijhof (remote from the Netherlands)
* Ed Sanders (remote from the UK)
* David Chen (remote from the UK)

Wikia's VisualEditor engineering team:
* Inez Korczyński (Wikia SF office; from Poland) 
* Christian Williams (Wikia SF office; from the US)

The Parsoid engineering team:
* Gabriel Wicke (SF office; from Germany)
* Subbu Sastry (remote from the US; originally from India)
* C. Scott Ananian (remote from the US)
* Marc Ordinas i Llopis (remote from Spain)

Google Summer of Code students mentored by the VisualEditor team:
* Moriel Schottlender (remote from the US; originally from Israel)
* Jiabao Wu (remote from Australia)
* Tongbo Sui (remote from China)

In various product and community liaison/advocacy roles, we have:
* James Forrester (SF office; from the UK)
* Philippe Beaudette (SF office; from the US)
* Maggie Dennis (remote from the US)
* Oliver Keyes (remote from the UK)
* Guillaume Paumier (remote from France)
* Jan Eissfeldt (remote from Germany)
* Keegan Peterzell (remote from the US)
* Erica Litrente (remote from Italy)
* Patrick Earley (remote from Canada)
* Sherry Snyder (remote from the US)

(I attempted to list people in the order they joined each team. Things are
moving fast, so I may have missed people; if I did, I apologize.)

Total # of people: 25 (not all of whom are full-time or work on VisualEditor
full-time)
# originally from the US: 8 (32%)
# living in the US: 14 (56%)
# working from the SF office: 8 (32%)



___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikitech-l] dirty diffs and VE

[Roan Kattouw]

On Wed, Jul 24, 2013 at 2:49 PM, C. Scott Ananian
canan...@wikimedia.org wrote:
 For what it's worth, both the DOM serialization-to-a-string and DOM
 parsing-from-a-string are done with the domino package.  It has a
 substantial test suite of its own (originally from
 http://www.w3.org/html/wg/wiki/Testing I believe).  So although the above
 is probably worth doing as a low-priority task, it's really a test of the
 third-party library, not of Parsoid.  (Although, since I'm a co-maintainer
 of domino, I'd be very interested in fixing any bugs which it did turn up.)

I didn't mean it as a test of Domino, I meant it as a test of Parsoid:
does it generate things that are then foster-parented out, or other
things that a compliant DOM parser won't round-trip? It's also a more
realistic test, because the way that Parsoid is actually used by VE in
practice is that it serializes its DOM, sends it over the wire to VE,
which then does things with it and gives an HTML string back, which is
then parsed through Domino. So even in normal operation, ignoring the
fact that VE runs stuff through the browser's DOM parser, Parsoid
itself already round-trips the HTML through Domino, effectively.

 The foster parenting issues mostly arise in the wikitext-parsoid DOM
 phase.  Basically, the wikitext is tokenized into a HTML tag soup and then
 a customized version of the standard HTML parser is used to assemble the
 soup into a DOM, mimicking the process by which a browser would parse the
 tag soup emitted by the current PHP parser.  So the existing test suite
 does expose these foster-parenting issues already.
Does it really? There were a number of foster-parenting issues a few
months ago where Parsoid inserted meta tags in places where they
can't be put (e.g. trs), and no one in the Parsoid team seemed to
have noticed until I tracked down a few VE bugs to that problem.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] dirty diffs and VE

[Roan Kattouw]

On Wed, Jul 24, 2013 at 3:10 AM, Marc Ordinas i Llopis
marc...@wikimedia.org wrote:
 As Subbu said, I'm currently working on improving the round-trip test
 server, mostly on porting it from sqlite to MySQL but also on expanding the
 stats kept (with things like performance, etc.). If you think of some other
 data we should track, or any new report we could add, we certainly welcome
 suggestions :) Please open a new bug or add to the existing one:
 https://bugzilla.wikimedia.org/show_bug.cgi?id=46659

Thanks for working on this! The Parsoid testing infrastructure is
pretty awesome.

There are a few things I wish it tested, but they're mostly about how
it tests things rather than what data is collected. For instance, it
would be nice if the round-trip tests could round-trip from wikitext
to HTML *string* and back, rather than to HTML *DOM* and back. This
would help catch cases where the DOM doesn't cleanly round-trip
through the HTML parser (foster-parenting for instance). It may be
that this is already implemented, or that it was considered and
rejected, I don't know.

Additionally, it might be helpful to have some tests looking for null
DSRs or other broken data-parsoid stuff (because this breaks selser),
and/or some sort of selser testing in general (though off the top of
my head I'm not sure what that would look like). Another fun
serialization test that could be done is stripping all data-parsoid
attributes and asserting that this doesn't result in any semantic
diffs (you'll get lots of syntactic diffs of course).

 Or just drop by #wikimedia-parsoid, I'm marcoil there.

The channel is #mediawiki-parsoid :)

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs

[Roan Kattouw]

On Tue, Jul 23, 2013 at 12:44 PM, Daniel Barrett d...@vistaprint.com wrote:
 Risker asks:
Why do you think those nowiki tags were added by the editors?

 I can't speak for the original poster, but the last time I used VE,
 it added unwanted nowiki tags by itself.
 You can see an example in my most recent bug report:
 https://bugzilla.wikimedia.org/show_bug.cgi?id=51829

Of course those nowiki tags weren't added by the editors, VE doesn't
let you do that directly. What I think Robert was talking about
(thanks for that analysis, BTW!) is edits where the user typed
something like [[Foo]] into the editor, and Parsoid, in order to
achieve a truthful rendering of [[Foo]], wraps it in nowiki tags.
That's a case of we did what the user asked us to do, although the
user probably didn't mean that. To counter this, there's a
notification bubble that appears as soon as you type something that
looks like wikitext. However, there's a bug that's causing this
notification to appear at the top of the page and so if you're
scrolled down more than a little bit, you'll probably never see it. We
intend to fix this today or tomorrow so that everyone who types in
wikitext will see this warning. It typically displays in the close
vicinity of, or even on top of, the save button, so it should be
pretty hard to miss once the positioning bug is fixed.

The heading bug where you get ==nowiki /== is a separate issue. This
happens when you blank a heading (or try to remove it but don't quite
succeed) and leave an empty heading behind. VE then sends an empty
heading to Parsoid, which very diligently puts in a nowiki tag so you
get the empty heading you supposedly wanted. These kinds of
technically-correct-but-probably-not-what-you-wanted issues are a bit
tricky. They're on our list of things to deal with though.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VE and nowiki

[Roan Kattouw]

Whoops, didn't realize this thread had been forked off while I was out
to lunch, and so I responded to the other thread. Sorry about that :(

On Tue, Jul 23, 2013 at 1:11 PM, Steve Summit s...@eskimo.com wrote:
 This is a likely enough mistake, and the number of times you
 really want explicit double square brackets is small enough, that
 it's worth thinking about (if it hasn't been already) having VE
 detect and DTRT when a user types that.

VE does detect this and warn the user, but there's a bug that makes
the warning bubble appear out of view if you're not scrolled all the
way up to the top. One of our team members is working on fixing that
right now.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VE and nowiki

[Roan Kattouw]

On Tue, Jul 23, 2013 at 2:14 PM, John Vandenberg jay...@gmail.com wrote:
 There is an enhancement for that.

 https://bugzilla.wikimedia.org/show_bug.cgi?id=51897

 IMO the current behaviour isnt correct.  There are so few instances
 that nowiki is desirable, that the current VE should refuse to accept
 wikitext (at least [[ and {{, and maybe ==, # and * at beginning of
 line, etc ), until at least such time as they have sorted out all the
 other bugs causing this to happen unintentionally.  If the user needs
 to input [[ or {{ they can use the source editor.  Or the VE could
 walk the user through each nowiki and either a) ask the user to
 confirm they want the obvious fix done automatically for them, or b)
 help them fix the problem.  Before saving.

We disagree on that one then. VisualEditor is meant to hide wikitext
entirely. The primary focus is on people that don't know wikitext. I
agree that we should keep nowiki-fication to a minimum and get rid of
the other bugs that cause this to happen, but I think the action we
currently take when a user types in wikitext (which is to warn them
and say this won't work) is appropriate. VE is meant to be a visual
editor, not a 
visual-except-with-weird-shortcuts-that-only-make-sense-if-you-know-the-legacy-markup-we-used-before-your-time
editor.

That's my opinion. Actual product direction is not something I'm in
charge of, that's James F's job, but AFAIK our current product
direction is similar to what I just said.

 nowiki is also being inserted at beginning of lines.

 https://es.wikipedia.org/w/index.php?title=Yacimiento_de_Son_Forn%C3%A9sdiff=prevoldid=68561708
 https://fr.wikipedia.org/w/index.php?title=Joel_Lindperecurid=5580501diff=95038161oldid=95037498

That's because the lines start with a space, which triggers a pre if
not nowiki-ed. Obviously the correct thing to do there is just remove
the space, but we haven't fixed that yet.

 instead of lists

 https://es.wikipedia.org/w/index.php?title=Jorge_Eslavadiff=68542729oldid=68451155

Once again that's people typing wikitext into VE, which is not supported.

 There are 24 open bugs for 'visualeditor nowiki'

 https://bugzilla.wikimedia.org/buglist.cgi?title=Special%3ASearchquicksearch=visualeditor%20nowikilist_id=219994

A lot of those are parts of symptoms of other bugs, and I'm pretty
sure a few of them are duplicates. nowiki often appears when
something else goes wrong and Parsoid attempts to fix things.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] VE/Migration guide for gadgets developers

[Roan Kattouw]

On Mon, Jul 22, 2013 at 9:51 AM, Eran Rosenthal eranro...@gmail.com wrote:
 Hi,
 When the ResourceLoader was deployed (or even before it) to production,
 there were migration development guides for gadget/extension developers:

-

 http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers
-
http://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader

 Such guides allowed easier adoption of ResourceLoader. We need something
 similar for the visual editor:

Yes we do :) . More generally, VE needs plugin infrastructure. Most of
it is already there, and I'm working on the last bits of it.

- Migration - What are the recommended steps to make gadget/extension
VE adapted? [with answers to questions such as: how to get the underlying
model - instead of $('#wpTextbox1').val() and what is this model [and what
modifications to the underlying model are supported/to be avoided by
gadgets/user scripts ] ]
- Development with the VE: guides with explanation for common editor UI
customization, and what is recommended API for it (for example: add custom
toolbar buttons).

These are excellent suggestions for documentation we should write once
the plugin infrastructure work is done. I intend to do this in the
next few weeks.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs

[Roan Kattouw]

On Mon, Jul 22, 2013 at 11:41 AM, John phoenixoverr...@gmail.com wrote:
 Minimal java-script load my ass,
Your language and tone are inappropriate. Please keep it civil.

 I guess you must be using a fiber-optic
 connection. Most pages already have a lag due to the amount of JS needed to
 run the site. Jumping pages have been a normal thing since resourceloader
 (caused by lagging JS issues)

The initial JS loaded for VisualEditor is a whopping 2.9KB gzipped.
I'd call that minimal. There is lots of other JS out there, but this
thread is about VisualEditor.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Alternative editor?

[Roan Kattouw]

On Fri, Jul 19, 2013 at 1:06 PM, Derric Atzrott
datzr...@alizeepathology.com wrote:
 Are there any extensions that make use of this hook?  Does
 VisualEditor?
No, VisualEditor doesn't use this hook. Instead, it uses JavaScript to
insert edit links and/or modify existing ones. The editor itself is
also entirely JavaScript-based. There is very little PHP code in the
VisualEditor extension and really all it does is load JavaScript code.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Australia (was Re: conferences, Hacker School, Code for America)

[Roan Kattouw]

On Fri, Jul 19, 2013 at 5:54 AM, Quim Gil q...@wikimedia.org wrote:
 CFP Extension Announced linux.conf.au 2014 - linux.conf.au !!!
 Now it's July 20.
 http://linux.conf.au/media/news/27


 ... and this is tomorrow.

Beware that because of Australia's far-east timezone, it's already
tomorrow there :)

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Git config trick.

[Roan Kattouw]

On Fri, Jul 19, 2013 at 10:40 AM, Ori Livneh o...@wikimedia.org wrote:
 In ~/.gitconfig, add:

 [url ssh://your_usern...@gerrit.wikimedia.org:29418/mediawiki/extensions/]
 insteadOf = ext:

 Now you can:

 git clone ext:UploadWizard

 !

! indeed. Sweet trick, dude, thanks!

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Mediawiki-api] Blacklisted?

[Roan Kattouw]

There was an API outage yesterday (Sunday July 14th) between roughly
12:00 and 14:00 UTC (5am-7am Pacific Time). As part of our
firefighting we blocked the IPs that were hitting the API the hardest
at the time. We didn't have time to do outreach because things were on
fire and falling over; I'm very sorry about that. We also should have
unblocked these IPs after the outage was over, but forgot (I was
mostly just trying to get things back up then go back to sleep).

For privacy reasons we can't disclose the IPs we blocked on Sunday. We
unblocked them just now, though, so if your bots are now working again
that would be it :)

I'm very sorry for the inconvenience and lack of follow-up. We
generally try to contact people, but when things are as bad as they
were yesterday we have to act quickly.

Roan


On Mon, Jul 15, 2013 at 10:50 AM, Alex Monk kren...@gmail.com wrote:
 Sending to wikitech-l instead, mediawiki-api is just for the MediaWiki API
 itself, not Wikimedia server stuff.

 Alex Monk

 On Mon, Jul 15, 2013 at 6:38 PM, Robert Crowe rob...@ourwebhome.com wrote:

 It looks to me like I was blacklisted for EN Wikipedia API requests.  My
 website has been using the API for awhile now, but suddenly I'm getting 403
 errors coming back.  I've tried to follow all the rules, but if I've missed
 something I'm happy to make changes.  What disturbs me most is that there
 was no attempt to contact me before being blacklisted to let me know there
 was a problem.  Where should I go to find out what the problem is?

 Thanks,

 Robert




 ___
 Mediawiki-api mailing list
 Mediawiki-api@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mediawiki-api



 ___
 Mediawiki-api mailing list
 Mediawiki-api@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mediawiki-api


___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Wikitech-l] [Mediawiki-api] Blacklisted?

[Roan Kattouw]

There was an API outage yesterday (Sunday July 14th) between roughly
12:00 and 14:00 UTC (5am-7am Pacific Time). As part of our
firefighting we blocked the IPs that were hitting the API the hardest
at the time. We didn't have time to do outreach because things were on
fire and falling over; I'm very sorry about that. We also should have
unblocked these IPs after the outage was over, but forgot (I was
mostly just trying to get things back up then go back to sleep).

For privacy reasons we can't disclose the IPs we blocked on Sunday. We
unblocked them just now, though, so if your bots are now working again
that would be it :)

I'm very sorry for the inconvenience and lack of follow-up. We
generally try to contact people, but when things are as bad as they
were yesterday we have to act quickly.

Roan


On Mon, Jul 15, 2013 at 10:50 AM, Alex Monk kren...@gmail.com wrote:
 Sending to wikitech-l instead, mediawiki-api is just for the MediaWiki API
 itself, not Wikimedia server stuff.

 Alex Monk

 On Mon, Jul 15, 2013 at 6:38 PM, Robert Crowe rob...@ourwebhome.com wrote:

 It looks to me like I was blacklisted for EN Wikipedia API requests.  My
 website has been using the API for awhile now, but suddenly I'm getting 403
 errors coming back.  I've tried to follow all the rules, but if I've missed
 something I'm happy to make changes.  What disturbs me most is that there
 was no attempt to contact me before being blacklisted to let me know there
 was a problem.  Where should I go to find out what the problem is?

 Thanks,

 Robert




 ___
 Mediawiki-api mailing list
 mediawiki-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mediawiki-api



 ___
 Mediawiki-api mailing list
 mediawiki-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mediawiki-api


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Announcement: C. Scott Ananian joins Wikimedia as Senior Features Engineer

[Roan Kattouw]

On Thu, Jul 11, 2013 at 3:24 PM, Terry Chay tc...@wikimedia.org wrote:
 Hello everyone,

 It’s with great pleasure that I’m announcing that C. Scott Ananian[1] has
 joined the Wikimedia Foundation as a Features Engineer.

Welcome! I'm excited to hear you're officially with us now.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [SOLVED] Re: ResourceLoader support question: how to construct a value in CSS from PHP

[Roan Kattouw]

On Wed, Jul 3, 2013 at 3:27 PM, Thomas Gries m...@tgries.de wrote:
 I found the solution ( $wgExtensionAssetsPath )
Why do you need this? You shouldn't need this. Paths relative to the
CSS file should be remapped automatically and should Just Work.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Australia (was Re: conferences, Hacker School, Code for America)

[Roan Kattouw]

On Sat, Jul 6, 2013 at 7:30 AM, Quim Gil q...@wikimedia.org wrote:
 I also think that linux.conf.au could be a good chance to spread our word in
 Australia. You are encouraged to apply.

I went to (and presented at) linux.conf.au in 2012, and I had an
awesome time. The quality of the talks and the number of high-quality
talks is amazing. I highly recommend it.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] PHPUnit tests fail from Jenkins but work fine locally

[Roan Kattouw]

On Fri, Jun 28, 2013 at 10:50 AM, Arthur Richards
aricha...@wikimedia.org wrote:
 Mobile web is trying to merge https://gerrit.wikimedia.org/r/#/c/69585/ but
 PHPUnit tests are failing when Jenkins executes them.

 What's weird is that we've executed PHPUnit tests on our various local
 machines - with no failures. We've been scratching our heads trying to
 figure out what might be causing the inconsistency.

 Anyone have any ideas what might be causing this?

Something that's tripped me up with VisualEditor a couple of times is
that Jenkins doesn't actually run the tests on your branch, it runs
them on a hypothetical merge with your branch into master. The process
is something like this:
* Attempt to merge the branch into master
* If there is a conflict, reject the commit with a message saying
something about a merge conflict, and abort
* If there was no conflict, there is now a local (to the Jenkins
server) merge commit that merges this branch into master
* Run tests on this merge commit

This means that if there was a recent change in master that broke your
code, but doesn't conflict directly (perhaps because an interface you
were using changed), the tests succeed in the branch but fail in the
merge commit. Jenkins correctly recognizes that merging your branch
would break master, and rejects your branch reporting the relevant
test failures, but this is not immediately obvious because the code as
committed worked fine.

The way I address this is to rebase the change onto master (and
because there is no conflict, you can even use Gerrit's rebase button
for this), at which point the tests will start failing locally as
well.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikimania-l] UK Visa Bond

[Roan Kattouw]

On Thu, Jun 27, 2013 at 12:19 PM, Nkansah Rexford
nkansahrexf...@gmail.com wrote:
 The news item:
 http://www.ndtv.com/article/india/after-india-protests-uk-says-no-final-decision-on-rs-2-7-lakh-visa-bond-384665

The government intends to run a pilot scheme for such bonds, tightly
targeted at a small number of visa applicants assessed to pose a high
risk of overstaying.

That suggests that they'll only ask for a bond from people that are
from those countries *and* are deemed to be high-risk, not from
everyone from those countries. I would guess that in the current
system (without bonds), these people would be very likely to have
their visa denied anyway.

That said, the news articles I've read about this aren't very clear,
which suggests the government hasn't been very clear about what its
plans are.

Roan

___
Wikimania-l mailing list
Wikimania-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimania-l

Re: [Wikitech-l] Brian Wolff's summer gig, with Wikimedia!

[Roan Kattouw]

On Mon, Jun 3, 2013 at 12:50 PM, Rob Lanphier ro...@wikimedia.org wrote:
 Hi everyone,

 Many of you already know Brian Wolff, who has been a steady
 contributor to MediaWiki in the the past several years (User:Bawolff),
 having gotten a start during Google Summer of Code 2010[1].

 Brian is back for another summer working with us, working generally to
 improve our multimedia contribution and review pipeline.  In addition
 to his normal GMail address, he's also available at
 bawo...@wikimedia.org, and is on Freenode as bawolff.

 Welcome Brian! (again! \o/)

Awesome! Welcome, Brian!

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias

[Roan Kattouw]

On Fri, Apr 26, 2013 at 9:42 AM, James Forrester
jforres...@wikimedia.org wrote:
 The report a problem link sends the report privately to a Parsoid
 server. From your video, it appears that the API call to do so failed
 - could you file a Bugzilla item with more details so we can
 investigate?

It's sending information to parsoid.wmflabs.org, and for now that's
intended behavior. We may change the way this information is collected
later, but for now it lives on labs, where the Parsoid developers
collect and analyze the information.

Even though Lukas's video shows a failed XHR request in the console,
the data was most likely submitted successfully. This is because we
use cross-domain AJAX to POST the data, and jQuery's attempt to read
the response (which is empty anyway) is blocked because of same-origin
restrictions, which causes the error you're seeing. At this point the
information has already been submitted, though, so the error is a red
herring. This behavior is clearly suboptimal and misleading, but it's
a minor issue at this point. It's tracked as
https://bugzilla.wikimedia.org/show_bug.cgi?id=42974 .

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias

[Roan Kattouw]

On Fri, Apr 26, 2013 at 11:37 AM, Claudia Müller-Birn
c...@inf.fu-berlin.de wrote:
 Hi James,

 Thanks for clarifying.

 I am just wondering why the two feedback mechanisms send to different targets 
 which I personally find a bit confusing. What has been the decision behind it?

They are different feedback mechanisms with different privacy
expectations. The Leave feedback flow collects general, free-form
feedback about the editor and posts it publicly. Only the text the
user types into the form is collected and published. The Something is
wrong flow is intended to collect data about cases where users see a
diff they don't expect. It collects a lot of information to help us
figure out what happened and why; this not only helps us find bugs,
but it also collects the information we need to track it down and fix
it. Because the information collected includes the text the user was
attempting to save but apparently chose not to save, we treat it as
private information.

So one flow collects general feedback and the text field is all we
collect, whereas the other collects data about a specific failure and
the text field just serves as a footnote on a lot of technical data we
collect along with it and is narrowly focused on the specific problem
at hand: what did the user do to trigger the bug. In the general
feedback flow, we communicate to the user that what they submit will
be public, and it's very easy to explain what will be public (the text
they put into the field). In the bad diff report flow, the data we
collect (editor contents with an unsubmitted edit, among other things)
is a bit more privacy-sensitive and it's hard to explain to the user
what we'll be collecting.

 And why is the Something is wrong or Etwas ist schief gelaufen a 
 privately sent feedback? Wouldn't be great to have here an open process and 
 not sending the feedback to a black hole?

This flow is mostly for reporting bugs, and the form asks them to
provide details about the specific bug they encountered rather than
general feedback. These comments wouldn't be particularly useful
without the associated debugging data. The debugging data isn't
particularly interesting to the general public, only to developers
(that's not an argument for why it shouldn't be public, just one for
why it doesn't hurt too much that it's not public). We feel like it
would be against the spirit if not the letter of the privacy policy to
publish this data without telling the user what we're publishing
(especially since unsaved editor contents are privacy-sensitive: there
is no expectation they'll be published because they're unsaved). But
it's also difficult to explain to the user what exactly it is that we
would be publishing.

Contrary to the confusion and other reports on this thread, I can
assure you that the data submitted through the Report problem
interface isn't sent to a black hole. It's being collected by the
Parsoid team, and they have in the recent past analyzed it and
discovered bugs in both Parsoid and VE.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias

[Roan Kattouw]

On Fri, Apr 26, 2013 at 3:05 PM, Lukas Benedix
bene...@zedat.fu-berlin.de wrote:
 I'm not a non-tech-user, but I don't like using bugzilla.
 here is the new bug: https://bugzilla.wikimedia.org/47755

Per my earlier post, I've closed that bug as INVALID (as feedback
collection does actually work), with a reference to the bug for making
it less sketchy.

 There are lines marked as changed in the diff that I never touched:
 http://lbenedix.monoceres.uberspace.de/screenshots/tlv5b64zcj_(2013-04-26_23.41.46).png
 http://lbenedix.monoceres.uberspace.de/screenshots/tlv5b64zcj_%282013-04-26_23.41.46%29.png

 Is this a (known) bug?

Not that I'm aware of. Looks like a bug in reference serialization.
Could you tell me which page you were editing there?

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deploying alpha of VisualEditor to non-English Wikipedias

[Roan Kattouw]

On Mon, Apr 29, 2013 at 4:36 AM, David Gerard dger...@gmail.com wrote:
 Cool, thank you :-) Every time I've used it lately, it's messing with
 the ref tags. Just now I literally moved a comma and it decided
 messing with the ref tags would be just the thing to do ...

Yeah, sorry about that :( . There was a bug where Parsoid duplicated
ref tags; Lukas's screenshot showed that too. The Parsoid team
deployed a fix for this just now, so the duplication bug should be
fixed now. There are rumors of other issues with ref tags, we're
looking into those still.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] VisualEditor on wikitech.wikimedia.org

[Roan Kattouw]

Because Faidon idly suggested that we should install VisualEditor on
wikitech as a way of dogfooding, I went ahead and did it.
https://wikitech.wikimedia.org/w/index.php?title=PowerDNSdiff=68284oldid=14633
is the first VE edit :)

Inside baseball note: this uses the Tampa Parsoid cluster, not the one
in eqiad, because the machine hosting wikitech (virt0) is in Tampa. If
and when things move to eqiad we can change that.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Temporarily disabling l10n update

[Roan Kattouw]

On Wed, Apr 10, 2013 at 1:14 PM, Max Semenik maxsem.w...@gmail.com wrote:
 Does that mean that scap is also prohibited?

Scap runs the same script to clear blobs. We can sabotage that script,
but that will cause all i18n updates to JS to propagate more slowly,
regardless of whether they came from a code deployment or l10nupdate.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] New git-review version revives year-old bug

[Roan Kattouw]

About a year ago, we were struggling with a git-review bug that caused
lots of bogus warnings to appear. When running git review, you'd get
a warning saying you're about to submit multiple commits, followed by
a list of lots of other people's commits that have already been
merged. I fixed this in https://review.openstack.org/#/c/6741/ last
year.

This bug is now back in the latest release of git-review that came out
over the weekend. I complained about this at
https://review.openstack.org/#/c/20450/ , which is the change that
reintroduced the broken behavior. We are suffering from it
disproportionately because we have defaultrebase=0 set on most of our
projects, and the bug only triggers when rebasing is disabled (using
either that setting or the -R flag).

The workaround is the same as last year: if git-review complains and
you see bogus commits in the list, respond no to abort, run git
fetch gerrit, then rerun git-review. This will ensure git-review has
an up-to-date view of the remote master.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Labs-l] Help needed with instance proxy

[Roan Kattouw]

2013/1/29 Silke Meyer silke.me...@wikimedia.de:
 Hi Ryan and all,

 you proposed me to try the instance proxy to access several web services
 on different labs instances via one IP address.

 I found https://labsconsole.wikimedia.org/wiki/Proxy - but that's still
 really short. How do I use it???

Generally, assuming you have a web service running on port 80 as
usual, you can go to http://instancename.instance-proxy.wmflabs.org/
, and it'll Just Work. For instance, I have an instance called
ve-change-marking (FQDN: ve-change-marking.pmtpa.wmflabs) running
MediaWiki and I access it at
http://ve-change-marking.instance-proxy.wmflabs.org/wiki/ .

You don't need any special setup for this. As long as the
instance-proxy instance (instance-proxy itself runs in a labs instance
:D) is able to connect to port 80 on your instance, these URLs will
work. Note that if you're running MediaWiki on the instance, you may
have to explicitly configure $wgServer =
'http://foobar.instance-proxy.wmflabs.org'; for it to work, otherwise
MediaWiki may get confused and try to redirect you to
http://foobar.pmtpa.wmflabs or something.

Roan

___
Labs-l mailing list
Labs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/labs-l

Re: [Labs-l] More Puppet questions

[Roan Kattouw]

On Tue, Jan 29, 2013 at 10:32 AM, Andrew Bogott abog...@wikimedia.org wrote:
 Nope!  puppetmaster::self causes puppet to use the local files in
 /var/lib/git/operations/puppet (aka /etc/puppet) rather than the official
 puppet files and manifests.  Once a change has been merged it becomes part
 of the official set and is applied to all systems.

 The configuration of self-hosting systems will lag behind since they are
 still using their local manifests and are more-or-less unaware to the
 official manifests.

Unless, of course, you put effort into keeping the local manifests
up-to-date by regularly running git pull (and, if you're using a
branch, merging or rebasing onto master) in
/var/lib/git/operations/puppet . If you disable puppetmaster::self,
then you will always have up-to-date manifests, but you won't be able
to customize the manifests locally.

Roan

___
Labs-l mailing list
Labs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/labs-l

Re: [Labs-l] Sumana Harihareswara as tools community liaison for Labs

[Roan Kattouw]

On Sun, Dec 23, 2012 at 3:43 PM, Robin Krahl m...@robin-krahl.de wrote:
 I have not requested Nova credentials yet, so I was not able to test
 everything. But even now I am missing some important information: Whom
 do I need to contact for Nova credentials? Special:NovaKey says: ‘Please
 ask a Nova administrator to create credentials for you.’ Well — where do
 I find a list of Nova admins?

If you get an error message that says something to the effect of no
Nova credentials found for your account, you may have to log out and
back in again. This is a known bug that was supposed to have been
fixed a few weeks ago.

Roan

___
Labs-l mailing list
Labs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/labs-l

Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia

[Roan Kattouw]

On Tue, Dec 11, 2012 at 10:55 PM, Lee Worden worden@gmail.com wrote:
 Very exciting - congratulations!

 I know these are early days for the VisualEditor, but is there a plan for
 extension developers to be able to hook in to provide editing for the things
 their extensions support?
Yes, absolutely! We've been working on cleaning up and rewriting
various internal APIs in VE such that they can reasonably be used to
write extensions. We've made progress, but we're not done yet, and
more recently it's received less attention because of yesterday's
release. We're gonna be picking that work back up in January, and once
it's done, we would be happy to work with willing guinea pigs to test
our APIs in the wild and work out the remaining kinks. As for when
that'll actually be scheduled to happen, I defer to James F.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia

[Roan Kattouw]

On Wed, Dec 12, 2012 at 11:32 AM, Daniel Barrett d...@vistaprint.com wrote:
 Will the method for hooking into VE be the same as for WikiEditor?  Or will 
 extension
 developers need to support both editors in two different ways?

It won't be the same as for WikiEditors, because the two are very
fundamentally different. WikiEditor gives you a toolbar that allows
you to insert and manipulate wikitext. VisualEditor gives you
something similar (a toolbar that allows you to insert and manipulate
rich content), but it also gives you inspectors with pop-up dialogs,
toolbar buttons that can change state depending on what's selected,
and much more. You can also add new *types* of content, change how
content is rendered, etc. The possibilities are endless compared to
WikiEditor.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Alpha version of the VisualEditor now available on the English Wikipedia

[Roan Kattouw]

On Wed, Dec 12, 2012 at 12:14 PM, Matthew Flaschen
mflasc...@wikimedia.org wrote:
 I would definitely be willing to serve as a guinea pig, working to
 integrate ProveIt (http://en.wikipedia.org/wiki/User:ProveIt_GT).

Awesome!

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Nobody Wikidata bugs: notify when you start working on a bug

[Roan Kattouw]

On Thu, Dec 6, 2012 at 10:07 AM, Quim Gil q...@wikimedia.org wrote:
 Hi, thanks to the metrics reports now we know that the top bug fixers in
 November were Nobody (228) and Wikidata bugs (83)... followed by Michael
 Dale (28), Roan Kattouw (23), etc.

 http://www.mediawiki.org/wiki/Community_metrics/November_2012#People

Those statistics don't actually measure who fixes bugs, they measure
who the fixed bugs were assigned to. Those aren't necessarily the same
person (although I imagine this is rare), but the larger issue is
that, as you say, most bugs have no human assignee. Another statistic
that is used in the BZ reports sent to this list is who closed the bug
(i.e. changed its status to RESOLVED FIXED), but this is also
suboptimal. For instance, in the VisualEditor team, James somewhat
frequently cleans up after developers who fix a bug but forget to
close it, or even mention the bug in the commit summary, so he's
probably the top bug fixer in VE by that metric, even though most of
that is just him taking paperwork off our hands. Another problem is
that bugs can bounce between REOPENED and FIXED multiple times, and
can be set to FIXED by different people each time.

So both metrics are noisy, although I imagine the latter would not
have a 50% signal-to-noise ratio like the former. Getting more
accuracy would be complicated: you'd probably have to look for Gerrit
links on the bug and identify their authors, or something like that.

Not saying the metric you used is wrong (it has advantages and
disadvantages), but I do think it's a bit misleadingly labeled.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Labs-l] labsconsole upgraded

[Roan Kattouw]

On Thu, Dec 6, 2012 at 8:12 PM, Hazard-SJ hazard...@yahoo.com wrote:
 Or we could use this as well since it will tell about other versions than
 1.21 as well.

This information also exists in a nicer format at
https://www.mediawiki.org/wiki/MediaWiki_1.21/Roadmap .

Roan

___
Labs-l mailing list
Labs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/labs-l

Re: [Wikitech-l] problems merging changes from master - remote branch

[Roan Kattouw]

On Fri, Nov 30, 2012 at 2:12 PM, Arthur Richards
aricha...@wikimedia.org wrote:
  ! [remote rejected] HEAD - refs/publish/esisupport/bug/41286 (change
 32896 closed)
It looks like https://gerrit.wikimedia.org/r/#/c/32896/ is a commit
that you submitted to esisupport at some point, then abandoned, and
are now trying to push in again. Gerrit doesn't like that very much.
To fix it, you can try restoring the change (click Restore Change on
the Gerrit page for the change; you may need the author or a Gerrit
admin to do this for you, I don't know if we've managed to give
everyone permission to restore yet), then trying to run 'git review'
again. That should introduce new changes for the things you're
submitting, and create a new patchset for the change that was giving
you trouble.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] WMF's webpage

[Roan Kattouw]

On Wed, Nov 28, 2012 at 4:21 PM, Chad innocentkil...@gmail.com wrote:

 On Wed, Nov 28, 2012 at 6:48 PM, Luke Welling lwell...@wikimedia.org
 wrote:
  Is there a reason not to use the Yahoo championed approach of embedding a
  version number in all static file names so you can set a very long cache
  expires time and just add new versions to the CDN when a change is made?
 

 That's what we used to do for CSS/JS--but we don't serve individual files
 like that anymore--they're all served together via the resource loader.

 ResourceLoader actually uses a somewhat more advanced version of the
version-number-in-filename approach: it dynamically computes the last
modified timestamp of the collection of resources it's requesting, and puts
that timestamp in the query string. If the timestamp is not available
dynamically, we omit the timestamp, and RL automatically serves the
resource with a short cache timeout (5 min) in that case.


 Also, it wouldn't have helped much in this case--the problem was that the
 HTML/CSS output changed in an incompatible way and we had old (or
 new, during the rollback) versions of the HTML still being served via
 Squid (they're cached for 30 days, unless something purges them like an
 edit).

 Don't change the HTML in incompatible ways is probably a good general
 rule to live by--but having an easy way to say start purging all pages on
 $theseWikis from Squid/Varnish would also be nice.

 Yes, the HTML and CSS changed in incompatible ways. The CSS cache
invalidated quickly (5-10 mins probably), but the HTML cache didn't.
Platonides probably misspoke when he said cached (skin) CSS had h5; I'd
imagine it was the Squid-cached HTML instead.

Either way, the CSS should be backwards-compatible with the old HTML, and
in this case it wasn't. That's the core of the problem.

Roan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Off-and-on CSS and rendering issues, Bits related?

[Roan Kattouw]

On Fri, Nov 16, 2012 at 12:34 PM, Andre Klapper aklap...@wikimedia.org wrote:
 * Missing Gadgets tab (also with Vector skin):
   
 https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Missing_Gadgets_Tab
This was fixed last night. It has nothing to do with bits, it was
caused by memcached corruption.

 * Maybe also: Edit conflict sometimes does not show the current
   text: https://bugzilla.wikimedia.org/show_bug.cgi?id=42163

I think it's very very very unlikely that this is because of a
front-end issue, it's almost certainly a backend issue.

 Speculation:

 Looking at the monthly stats on
 http://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Bits%20application%20servers%20pmtpam=cpu_reportr=hours=by%20namehc=4mc=2st=1353096306g=network_reportz=largec=Bits%20application%20servers%20pmtpa
 (click on Inspect) there is a drop of Out on November 5/6th.

 From http://wikitech.wikimedia.org/view/Server_admin_log#November_5 :
 21:54 aaron synchronized wmf-config/mc.php 'Switched all wikis to
 memcached-multiwrite.'
 21:54 logmsgbot_: aaron synchronized wmf-config/InitialiseSettings.php
 'Disabled spammy (with pecl memcached) memcached.log, the useful one is
 memcached-serious.'

The drop is strange, but could be explained by the memcached changes
and the logging changes, if similar drops were observed in the other
Apache clusters.

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] jQuery 1.9 will remove $.browser (deprecated since jQuery 1.3 - January 2009)

[Roan Kattouw]

On Thu, Nov 8, 2012 at 5:17 PM, Tim Starling tstarl...@wikimedia.org wrote:
 I can understand the rationale behind removing jQuery.browser:
 apparently most developers are too stupid to be trusted with it. Maybe
 the idea is to use per-project reimplementation of jQuery.browser as
 an intelligence test. The trouble is, I think even the stupidest
 developers are able to copy and paste.

Yes, there are legitimate reasons for using browser detection, in
cases where feature detection doesn't work. The Safari segfault is a
good example. In fact, VisualEditor uses browser detection to disable
itself in browsers with broken contentEditable support, because it's
very hard or impossible to feature-detect this. I believe Timo was
working on cleaning up a different UA detection plugin somewhere on
github and using that for VE's browser detection.

tl;dr: browser detection is evil, you should think twice before using
it, but sometimes you have to

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Creating custom skin based on Vector in MediaWiki 1.20

[Roan Kattouw]

On Tue, Nov 13, 2012 at 12:33 AM, Dmitriy Sintsov ques...@rambler.ru wrote:
 However, 'skin.vector' module includes both styles and scripts. And
 setupSkinUserCss() adds styles only. So 'dependencies' did not help, vector
 styles are loaded later, anyway. What can I do with that?

Unfortunately, addModuleStyles() and dependencies don't work well
together. You shouldn't use dependencies for CSS that is essential for
rendering the page.

 Also, I need to load remote google webfonts. Does ResourceLoader support
 this or I have to use old-fashionated methods of OutputPage() ?
Unfortunately RL doesn't support this directly. Although to load a
webfont, all you need is a stylesheet with an @font-face in it, right?

Roan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l