Re: [Wikitech-l] Faidon Liambotis promoted to Principal Operations Engineer
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
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
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
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
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
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
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
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
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
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
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
> > 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
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
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
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
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
