Re: [Wikitech-l] Faidon Liambotis promoted to Principal Operations Engineer

2014-02-10 Thread MZMcBride
Ryan Lane wrote:
>Congrats Faidon, you do great work and you're an awesome person to work
>with.

What he said. :-)

MZMcBride



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

[Wikitech-l] RFC discussion Friday 14 Feb: TitleValue

2014-02-10 Thread Sumana Harihareswara
This week, we're mostly discussing the TitleValue RFC -
https://www.mediawiki.org/wiki/Architecture_Summit_2014/TitleValue and
https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue have more
information.

https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-02-14says
that we may also poke at the Deprecating inline styles. You can add
another RFC to the agenda.

The discussion will be in #wikimedia-office at 13:00 UTC on Friday the
14th:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+review&iso=20140214T14&p1=37&ah=1

Pacific: 5am
US Eastern: 8am
Berlin, Germany: 2pm (14:00)
Sydney: midnight :( (sorry, Tim; I'll make sure you have opportunities to
comment before and after)


Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for Zürich Hackathon - getting close to a production-like Vagrant instance

2014-02-10 Thread Pavel Astakhov

aren't you lost this links? :-)

1 https://www.mediawiki.org/wiki/MediaWiki-Vagrant
2 https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014

11.02.2014 06:13, Arthur Richards пишет:

A few of us have been discussing how awesome it would be to use
MediaWiki-Vagrant[1] to create a portable production-like environment. This
would give Mediawiki engineers a common ground from which to develop core
code and/or extensions, and by coming close to mimicking Wikimedia's
production environment, would hopefully reduce the amount of friction
around getting features out to production. Also, this is something that we
would be able to pre-package this for new engineers - imagine handing a new
MediaWiki engineer a USB stick with an up-to-date MediaWiki-Vagrant
instance that closely mimics production at say, a future hackathon.

We started chatting about what it would take to get us there, and
identified some initial steps that we'd like to tackle at the Zürich
Hackathon - namely, turning a few puppetized production services into roles
that we could use in MediaWiki-Vagrant.

We've created a corresponding 'topic' on the Hackathon's topic page[2] to
describe what we'd like to achieve at the Hackathon. Please review,
comment, and certainly add yourself as an 'interested person' if this
catches your fancy and you plan to attend the hackathon.




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

[Wikitech-l] Proposal for Zürich Hackathon - getting close to a production-like Vagrant instance

2014-02-10 Thread Arthur Richards
A few of us have been discussing how awesome it would be to use
MediaWiki-Vagrant[1] to create a portable production-like environment. This
would give Mediawiki engineers a common ground from which to develop core
code and/or extensions, and by coming close to mimicking Wikimedia's
production environment, would hopefully reduce the amount of friction
around getting features out to production. Also, this is something that we
would be able to pre-package this for new engineers - imagine handing a new
MediaWiki engineer a USB stick with an up-to-date MediaWiki-Vagrant
instance that closely mimics production at say, a future hackathon.

We started chatting about what it would take to get us there, and
identified some initial steps that we'd like to tackle at the Zürich
Hackathon - namely, turning a few puppetized production services into roles
that we could use in MediaWiki-Vagrant.

We've created a corresponding 'topic' on the Hackathon's topic page[2] to
describe what we'd like to achieve at the Hackathon. Please review,
comment, and certainly add yourself as an 'interested person' if this
catches your fancy and you plan to attend the hackathon.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Outage report - Feb 6th - Math

2014-02-10 Thread Greg Grossmeier
FYI

-- Forwarded message --
From: Greg Grossmeier 
Date: Mon, Feb 10, 2014 at 3:25 PM
Subject: Outage report - Feb 6th - Math
To: Development and Operations engineers 


https://wikitech.wikimedia.org/wiki/Incident_documentation/20140206-Math

Important bits:

== Summary ==
https://gerrit.wikimedia.org/r/#/c/104991/ changed the parser cache keys
for pages with  in them, causing a spike in cache misses and thus
the cluster feel over.

This has been slowly rolling out on small wikis, mostly unnoticed since
math isn't widely used there. Rolling out today to larger wikis (dewiki,
etc) caused the cache stampede to be more obvious and cause downtime.
Reverting the change didn't work because of incompatibilities between
core + the extension, but was ok because we had mostly gotten through
the invalidation before the roll back.

This would've been a problem if we weren't having fatals, we would've
started invalidating to the old version again. We got lucky. Going back
to new version caused a little more invalidations, but seems reasonable
and should level off soon probably


== Conclusions ==
We really need to process through the backlog of Math extension
changesets from physikerwelt who's done great work on the extension but
is lacking review.


== Actionables ==
* wrap Math stuff in PoolCounter so it doesn't kill apaches so easily.
* More review on recent changes to Math. Be careful in rolling this
* release out further.
** PoolCounter: https://gerrit.wikimedia.org/r/#/c/111916/


--
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC: UploadWizard — scale to sister projects

2014-02-10 Thread Gryllida
Hi all,

Apologies for cross-posting; please read and share thoughts:
https://www.mediawiki.org/wiki/Requests_for_comment/UploadWizard:_scale_to_sister_projects

Gryllida

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

[Wikitech-l] RFC: UploadWizard — scale to sister projects

2014-02-10 Thread Gryllida
Hi all,

Apologies for cross-posting; please read and share thoughts:
https://www.mediawiki.org/wiki/Requests_for_comment/UploadWizard:_scale_to_sister_projects

Gryllida

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

Re: [Wikitech-l] ResourceLoader timing

2014-02-10 Thread Trevor Parscal
Steffen,

ResourceLoader guarantees the order of module execution if there are
dependencies, such that child always comes after parent, which always comes
after grandparent in a dependency chain. Due to the concatenation of
modules in the order requested, it's unlikely that modules will be executed
in a different order each load. They would probably have to be in separate
groups, and even then because of caching this wouldn't be repeatable
without clearing the cache.

Looking at the timeline when loading the page, it appears that it is
initially drawn incorrectly, and then there is something that causes a
reflow about a second later which corrects it. Without really looking at
your code, it would appear that this reflow may be caused by CSS coming too
late, but it's odd how it appears to be the same style only with different
dimensions.

But then I look at how the header cells have their width set in pixels.
They seem to have a max width (though not in CSS) and are adjusted down
when the browser is made too small to fit the table otherwise. This is
probably being done using a resize handler, and there's the most likely
culprit. Also, this is a very simple UI, but it takes more than a second to
render, and I'm using a very new and powerful computer.

My suggestion is to set the size of the table cells in CSS using 14.2%
(about 1/7th) for each column. Then perhaps setup a simple CSS grid, based
on such percentages, for the events being overlaid on the cells. This would
work by assigning a day-of-week and week-of-month class which would
modulate the left and top position, and all events would be 1/7th width to
match the columns. By specifying as much of the layout as possible in CSS,
you will get far more efficient and responsive layout.

In conclusion, I suspect that ResourceLoader has nothing to do with your
problem, but rather the way you are laying things out is inefficient and
depends on a resize event to happen right after you are done building out
the DOM. Depending on the browser, this may or may not happen, and in the
best case it happens rather latently.

Also, be very careful with resize handlers. Debounce them when possible,
and don't use them to change layouts unless you really have no other
option. They fire at a very fast pace, at a time when the page is being
constantly reflowed, and the events can queue up easily, leaving you with a
ton of events to process, when only the latest one (hopefully the last one)
needs to be addressed (or will really be visible in most cases).

Then again, I haven't seen the actual code, so I could be totally wrong. :)

- Trevor


On Sun, Feb 9, 2014 at 9:58 AM, Steffen Beyer  wrote:

> Hi,
>
> Hopefully this is the right place to ask...?
>
> I wrote a small event calendar extension¹ utilising the FullCalendar
> jQuery plugin. Sometimes it happens that the display is garbled, see
> attachment. My current dirty fix is to rerender the calendar after a
> timeout².
>
> My theory is that the outcome depends on the order of the JS and CSS
> resources being loaded, so it depends on server and network latency. Is
> this possible? Or can I be sure that all CSS is active when I init the
> calendar? If not, is there a ResourceLoader hook I can use? Other ideas?
>
> Live Demo:
>
> https://foodhackingbase.org/wiki/Events
>
> Sincerely,
> --
> Steffen Beyer 
>
> ¹ https://github.com/improper/mediawiki-extensions-yasec
> ²
>
> https://github.com/improper/mediawiki-extensions-yasec/blob/master/resources/ext.yasec.core.js#L9
>
>
> ___
> 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] Faidon Liambotis promoted to Principal Operations Engineer

2014-02-10 Thread Ryan Lane
On Mon, Feb 10, 2014 at 5:48 AM, Mark Bergsma  wrote:

> I'm pleased to announce that Faidon Liambotis has been promoted to
> Principal Operations Engineer.
>
>
Definitely deserved and far too late in coming! Congrats Faidon, you do
great work and you're an awesome person to work with.

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

Re: [Wikitech-l] Core unit tests passing under HHVM 2.4

2014-02-10 Thread Erik Bernhardson
On Sat, Feb 8, 2014 at 3:11 AM, Tim Landscheidt wrote:

> Antoine Musso  wrote:
>
> >> Can we maybe add this into Jenkins somehow? It'd be kind of nice if we
> >> could make sure from now on that no patches break unit tests in HHVM.
>
> > To get HHVM we first need a Debian package so we can get it installed on
> > Ubuntu and it is apparently a pain to get it packaged for the Ubuntu
> > version we are currently using (Precise).
>
> > [...]
>
> Are there no sources for the packages linked in
> http://www.hhvm.com/blog/2393/hhvm-2-3-0-and-travis-ci?
>
>
There is a script in the root of the hhvm checkout,
configure_ubuntu_12.04.sh, which travis uses to build 12.04 packages. This
script builds the various special dependencies and "should" just work,
although I havn't tried it on a plain precise install yet.

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

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

Re: [Wikitech-l] Testing changes to the Math extension before they get live at wikipedia

2014-02-10 Thread Chris McMahon
On Mon, Feb 10, 2014 at 5:31 AM, Moritz Schubotz wrote:

> Dear all,
>
> recently some changes were merged to Wikipedia that broke some math
> rendering for almost 2 days.
> I'm highly interested to avoid that this will happen again.
>

On 27 January an automated test on beta labs identified new missing
dependencies for Math: https://bugzilla.wikimedia.org/show_bug.cgi?id=60486.
This was fixed.

On 28 January an automated test on beta labs identified an error with Math
communicating with the Parser that prevented loading any page containing a
Math expression: https://bugzilla.wikimedia.org/show_bug.cgi?id=60546.
 This was fixed.

On 29 January Physikerwelt sent a message to Antoine Musso entitled
"effects on caching" saying "please be informed that recent changes in the
Math extension and core might influence the stability of large MediaWiki
instances due to  a change in the cache key".  That message does not appear
in the wikitech-l archives for January, although Physikerwelt seems to have
forwarded Antoine's message there.
http://lists.wikimedia.org/pipermail/wikitech-l/2014-January/


> As a reaction my goal is to develop the changes in a new branch called
> math2_0_0 that get's reviewed according to the WMF standards and is
> tested in a production like environment:  and reviewed by the community,

before the changes are merged to the master branch.


Beta labs is our production like environment.  It should probably be
possible to use beta labs for this.  However, beta does run only the master
branch of each extension, but does so before the master branch of each
extension is deployed to production.

In this case the root cause of the error seems to have been that the
message about Math's effect on caching was somehow lost.


> Is there a
> production like environment that could be used for that? Of course I
> could try to create a production like environment for Math by myself
> like I did with
> http://math-test2.instance-proxy.wmflabs.org/wiki/Main_Page ... but I
> want to avoid double work and I'm a volunteer... so my time is very
> limited.
>
> Best
> Physikerwelt
>
> --
> Mit freundlichen Grüßen
> Moritz Schubotz
>
>   Telefon (Büro):  +49 30 314 22784
>   Telefon (Privat):+49 30 488 27330
>   E-Mail: schub...@itp.physik.tu-berlin.de
>   Web: http://www.physikerwelt.de
>   Skype: Schubi87
>   ICQ: 200302764
>   Msn: mor...@schubotz.de
>
> ___
> 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] InstantClick

2014-02-10 Thread Dan Andreescu
>
> Hi,
>
> Today, I heard about a JavaScript library called InstantClick
> (http://instantclick.io/). Basically, it's based on the principle that
> latency is responsible for a lot of the Web's slowness. It also
> considers that there are about 250ms between hovering over and
> clicking on a link. Therefore, it starts pre-loading the page on
> hover, and then switches to it via AJAX when the user clicks the link.
> It can also do this on mousedown only, which causes no additional
> server load and still provides a performance boost, according to its
> website, similarly to Rails' turbolinks functionality.
>
> Is there any chance this could work on MediaWiki?
>
> Regards,
> -Kudu.
>

This is pretty neat.  Some a/b tests on mobile would help us understand
just how much extra data this would cause people to consume vs. how much
time it saves them.

On desktop, I bet a combination of this with something like cursor
proximity based events [1] would be interesting to look into.


[1] https://github.com/padolsey/jquery.fn/tree/master/proximity-event
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Faidon Liambotis promoted to Principal Operations Engineer

2014-02-10 Thread Martijn Hoekstra
Awesome! Congratulations!
On Feb 10, 2014 2:48 PM, "Mark Bergsma"  wrote:
>
> I'm pleased to announce that Faidon Liambotis has been promoted to
Principal Operations Engineer.
>
> From the very first week he was hired, Faidon has expressed great
interest in understanding and improving the complete infrastructure stack
of the Wikimedia Foundation, covering not only the domain of the Operations
team, but far beyond. I distinctly remember how, a few days after he was
hired (which at the time, I didn't take any part in), he approached me for
the first time on IRC and said:
>
>"Hi Mark! Nice to meet you. I see you just wrote this nice new
director for consistent URL hashing to backends in Varnish. Let me help you
get that upstreamed!"
>
> I believe in that same week he fixed some bugs in our nginx setup and
solved our scalability issues with Puppet's external (Nagios) resources,
amongst other things.
>
> Ever since, Faidon has taken on many projects, large and small, and
completed them in ways going far beyond his duties. He has spent enormous
amounts of time reviewing other people's patch sets, discussing their
ideas, and mentoring them in their work. He's instrumental in coordinating
efforts across multiple groups and making sure everyone arrives at the best
possible solution. In discussions he's noticed for being analytical and
methodical, and calmly working towards a common goal. This is reflected in
his architecting work too, where he contributes with sensible ideas and a
great knowledge of the open source software and solutions landscape.
>
> Outside of Wikimedia, Faidon has been active in Debian and other open
source projects since 2004. He cares deeply about our use of open source
solutions and helping our software extensions get upstreamed and made
available to others.
>
> I think it's only appropriate that we recognize his role with this
promotion.
>
> The biggest problem we may have with him is that he works too much and is
involved with almost everything. Fortunately that is a good fit for his new
role. :)
>
> Please join me in congratulating Faidon.
>
> --
> Mark Bergsma 
> Lead Operations Architect
> Acting Director of Technical Operations
> Wikimedia Foundation
>
>
>
>
> ___
> 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

[Wikitech-l] Faidon Liambotis promoted to Principal Operations Engineer

2014-02-10 Thread Mark Bergsma
I'm pleased to announce that Faidon Liambotis has been promoted to Principal 
Operations Engineer.

From the very first week he was hired, Faidon has expressed great interest in 
understanding and improving the complete infrastructure stack of the Wikimedia 
Foundation, covering not only the domain of the Operations team, but far 
beyond. I distinctly remember how, a few days after he was hired (which at the 
time, I didn't take any part in), he approached me for the first time on IRC 
and said:

   "Hi Mark! Nice to meet you. I see you just wrote this nice new director for 
consistent URL hashing to backends in Varnish. Let me help you get that 
upstreamed!"

I believe in that same week he fixed some bugs in our nginx setup and solved 
our scalability issues with Puppet's external (Nagios) resources, amongst other 
things.

Ever since, Faidon has taken on many projects, large and small, and completed 
them in ways going far beyond his duties. He has spent enormous amounts of time 
reviewing other people's patch sets, discussing their ideas, and mentoring them 
in their work. He's instrumental in coordinating efforts across multiple groups 
and making sure everyone arrives at the best possible solution. In discussions 
he's noticed for being analytical and methodical, and calmly working towards a 
common goal. This is reflected in his architecting work too, where he 
contributes with sensible ideas and a great knowledge of the open source 
software and solutions landscape.

Outside of Wikimedia, Faidon has been active in Debian and other open source 
projects since 2004. He cares deeply about our use of open source solutions and 
helping our software extensions get upstreamed and made available to others.

I think it's only appropriate that we recognize his role with this promotion.

The biggest problem we may have with him is that he works too much and is 
involved with almost everything. Fortunately that is a good fit for his new 
role. :)

Please join me in congratulating Faidon.

— 
Mark Bergsma 
Lead Operations Architect
Acting Director of Technical Operations
Wikimedia Foundation




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

[Wikitech-l] Testing changes to the Math extension before they get live at wikipedia

2014-02-10 Thread Moritz Schubotz
Dear all,

recently some changes were merged to Wikipedia that broke some math
rendering for almost 2 days.
I'm highly interested to avoid that this will happen again.
As a reaction my goal is to develop the changes in a new branch called
math2_0_0 that get's reviewed according to the WMF standards and is
tested in a production like environment and reviewed by the community,
before the changes are merged to the master branch. Is there a
production like environment that could be used for that? Of course I
could try to create a production like environment for Math by myself
like I did with
http://math-test2.instance-proxy.wmflabs.org/wiki/Main_Page ... but I
want to avoid double work and I'm a volunteer... so my time is very
limited.

Best
Physikerwelt

-- 
Mit freundlichen Grüßen
Moritz Schubotz

  Telefon (Büro):  +49 30 314 22784
  Telefon (Privat):+49 30 488 27330
  E-Mail: schub...@itp.physik.tu-berlin.de
  Web: http://www.physikerwelt.de
  Skype: Schubi87
  ICQ: 200302764
  Msn: mor...@schubotz.de

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

[Wikitech-l] Help me to avoid local patches

2014-02-10 Thread Niklas Laxström
On one of my wikifarms I only have one local patch to MediaWiki core
left. I'm hoping to have that merged as well, so let me bring this to
your attention: https://gerrit.wikimedia.org/r/#/c/98078/

On a related note, I'm using html templates and I am in need of a way
to deliver them with resource loader. Max Semenik has already made a
patch for that, so please have a look at that too:
https://gerrit.wikimedia.org/r/#/c/111250/

  -Niklas

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