On Wed, Nov 13, 2013 at 03:41:33PM -0800, Matthew Walker wrote: I haven't looked at your document yet, but a quick note on that: I have nodejs 0.10 backported packages ready for about 10 days now. We typically avoid running multiple versions of the same package across the infrastructure (and our apt repo isn't split like that, thankfully), so I'd like to upgrade the existing users to 0.10. These are parsoid, statsd, perhaps the not-production-yet limn, etherpad-lite and of these, parsoid is the one with the most impact. As such, we've agreed with Gabriel -which needed node 0.10 for rashomon anyway- to test the new version under the parsoid RTT suite & subsequently in the Parsoid Labs instance, before we go and upgrade production. (The packages have been in parsoid.wmflabs.org's /root/ since). I haven't heard since but as they don't /need/ a new Node version right now, I guess this is low priority for them (and we, ops, don't care much either). I think this would happen anyway before the PDF service would ever reach production, but I think we can prioritize it a bit more and make sure it will. Gabriel, what do you think? Regards, Faidon

Marcin Cieslak wrote: Matthew replied on-wiki, but I'll add that there's a dream within the MediaWiki tech community to be able to simply do "apt-get mediawiki" or similar on a spun-up virtual machine and everything will quickly and easily be set up for you. There's a contrasting view that MediaWiki should only serve as the platform for Wikimedia wikis (large, high-volume sites) and that it's overkill for any small wiki setup. This view also usually advocates not focusing on third-party support, naturally, which removes Jimmy the casual MediaWiki user from the equation. Whether either of these ideas (and many more) should guide architectural design decisions is, of course, a matter of debate. :-) MZMcBride

And I'll add that there's another axis: gwicke (and others?) have been arguing for a broader "collection of services" architecture for mw. This would decouple some of the installability issues. Even if PDF rendering (say) was a huge monster, Jimmy MediaWiki might still be able to simply install the core of the system. Slow progress making PDF rendering "more friendly" wouldn't need to hamper all the Jane MediaWikis who don't need that feature. These issues cross-couple. Making a really super-easy "giant VM blob" that contained an entire complicated MediaWiki setup with all bells and whistles might as a side-effect make it less pressing to decouple the services and simplify the installation -- so long as the giant blob worked, no one needs to know what darkness lay beneath the hood. (Is that a good or a bad thing?) Conversely, making 'apt-get install mediawiki mediawiki-pdf' Just Work would make it less relevant whether 'mediawiki-pdf' was a separate service or a tightly-coupled mediawiki extension. In practice, what is needed most are people to actually work on making the process friendly, one way or another. (I've done my part by aggressively patching extension READMEs as I come across them to keep them up to date and accurate.) --scott (http://cscott.net)

The objective is to get buy in and comments on what is proposed. If it was as simple as adding a few fonts and other dependecies, would the previous iteraton of the software have remained broken? Sadly, it is a wee bit more complicated. Thanks, GerardM Op 17 nov. 2013 15:30 schreef "Jeremy Baron" <jeremy(a)tuxmachine.com>om>: