Re: [Wikitech-l] Developer Relations Weekly Summary

That "Wikimedia UI" thing looks good! Except it seems to require third-party javascript (myfontastic?), which is not allowed on Tools Labs, IIRC. And it wants to run Flash. Why??? On Thu, Nov 5, 2015 at 12:33 PM Quim Gil wrote: > Original web version: > >

[Wikitech-l] Developer Relations Weekly Summary

Original web version: https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary#2015-11-05 Help develop the next summary here ! Software - Wikimedia UI elements available in HTML + Bootstrap

Re: [Wikitech-l] MW support for Composer equivalent for JavaScript packages

The flat approach to NPM is a game changer for us, and a Bower killer. Timo? Had a lot of insight at the time, I'd like to see him be invoked in this decision. Any thoughts Timo? - Trevor On Thursday, November 5, 2015, Jon Robson wrote: > It's been a year now, over 3-6

Re: [Wikitech-l] MW support for Composer equivalent for JavaScript packages

It's been a year now, over 3-6 months. Volker can this be given a priority in the next frontend standards meeting. I think the lack of any standard is extremely damaging to the project. On Wed, Jul 22, 2015 at 4:21 PM, Bryan Davis wrote: > On Wed, Jul 22, 2015 at 12:24 PM,

[Wikitech-l] Superprotect is gone

Superprotect [1] was introduced by the Wikimedia Foundation to resolve a product development disagreement. We have not used it for resolving a dispute since. Consequently, today we are removing Superprotect from Wikimedia servers. Without Superprotect, a symbolic point of tension is resolved.

Re: [Wikitech-l] Superprotect is gone

Excellent, many thanks Quim!! On Nov 5, 2015 18:35, "Quim Gil" wrote: > Superprotect [1] was introduced by the Wikimedia Foundation to resolve a > product development disagreement. We have not used it for resolving a > dispute since. Consequently, today we are removing

Re: [Wikitech-l] MW support for Composer equivalent for JavaScript packages

As someone who now works in js/node primarily I might be able to add a little outside insight. IMHO bower was probably killed far before npm@3 came out. - npm has always been more advanced - bower's main isn't as reliable as it is in npm. Even if modules aren't forgetting to set it as much as

Re: [Wikitech-l] Superprotect is gone

I want to thank everyone who has made this possible. Developing software products for a big and unique movement like Wikimedia is a complex task (but no more complex than building free encyclopedias, dictionaries, etc.) I believe that shipping better features faster is one of the most important

Re: [Wikitech-l] MW support for Composer equivalent for JavaScript packages

Note that as part of https://phabricator.wikimedia.org/T114457 I'm experimenting with distributing mediawiki-core itself as an npm-installable package. It ought to be possible to package up extensions, including Parsoid and VE, using npm as well. --scott On Thu, Nov 5, 2015 at 11:32 AM, Trevor

[Wikitech-l] Update from the Wikimedia Performance Team

Hello, This is the first monthly report from the Wikimedia Performance Team. The purpose of these reports is to showcase our work, track our progress, and spark conversation. ## Who we are ## As the Wikimedia Foundation’s Performance Team, we want to create value for readers and editors by

Re: [Wikitech-l] [Wikimedia-l] Update from the Wikimedia Performance Team

On Thu, Nov 5, 2015 at 2:13 PM, Ori Livneh wrote: > Improving future-proof maintainability by taking thumbnail code out of > MediaWiki-Core and using a service instead to perform thumbnail operations. How does that affect third-party use of MediaWiki where people aren't

Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

Is this simply to support hosted providers? npm is one of the worst package managers around. This really seems like a case where thin docker images and docker-compose really shines. It's easy to handle from the packer side, it's incredibly simple from the user side, and it doesn't require

Re: [Wikitech-l] mediawiki-extension cli extension installer/updater released

Do you think this would work with https://github.com/cscott/node-mediawiki-express ? --scott On Thu, Oct 8, 2015 at 4:12 AM, Brion Vibber wrote: > Nice! > > -- brion > > On Thursday, October 8, 2015, Daniel Friesen

[Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

Architecturally it may be desirable to factor our codebase into multiple independent services with clear APIs, but small wikis would clearly like a "single server" installation with all of the services running under one roof, as it were. Some options previously proposed have involved VM containers

Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

That is just *all kinds* of awesome. -- brion On Thu, Nov 5, 2015 at 1:47 PM, C. Scott Ananian wrote: > Architecturally it may be desirable to factor our codebase into multiple > independent services with clear APIs, but small wikis would clearly like a > "single

Re: [Wikitech-l] MW support for Composer equivalent for JavaScript packages

Two other interesting pieces: 1. http://requirejs.org/ is still the goal-standard for async browser-type loading, AFAIK, and there are good packages (`npm install requirejs`) that allow interoperability with the "npm style". 2. The recently-completed ES6 spec contains a module format. You can

Re: [Wikitech-l] [Wikimedia-l] Update from the Wikimedia Performance Team

On Thu, Nov 5, 2015 at 12:17 PM, Brad Jorsch (Anomie) wrote: > On Thu, Nov 5, 2015 at 2:13 PM, Ori Livneh wrote: > > > Improving future-proof maintainability by taking thumbnail code out of > > MediaWiki-Core and using a service instead to perform

Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

2015. 11. 6. 오전 8:26에 "Ryan Lane" 님이 작성: > > Is this simply to support hosted providers? npm is one of the worst package > managers around. This really seems like a case where thin docker images and > docker-compose really shines. It's easy to handle from the packer side, > it's

Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

Using VMs does not take any "technical enlightenment". There are containerization tools that are relatively simple to use for non-scale environments, and learning them would take just as much time as learning how to use npm. (Note, I'm not arguing against this solution, which I think is pretty

Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

I view it as partly an effort to counteract the perceived complexity of running a forest full of separate services. It's fine to say they're all preinstalled in this VM image, but that's still a lot of complexity to dig through: where are the all the servers? What ports are they listening all?